Como espremer memória no NVIDIA Jetson pra rodar modelos maiores na borda

Modelos generativos open-source tão saindo do data center e indo parar em máquinas que operam no mundo físico: robôs autônomos, câmeras inteligentes, agentes de IA física. O problema é chato e conhecido: como você enfia um modelo de vários bilhões de parâmetros num device de borda com memória limitada?

A NVIDIA publicou um guia do time do Jetson (Anshuman Bhat e Aditya Sahu) mapeando 5 camadas de otimização de memória. Ganho total possível: 10 a 12 GB de RAM recuperada, mantendo precisão e features.

Pra quem opera Jetson Orin Nano de 8 GB na prática, esses 10 GB somados fazem diferença entre "modelo não cabe" e "pipeline multimodal rodando".

As 5 camadas da stack

O guia organiza otimização em camadas, de baixo pra cima:

1. BSP (Board Support Package) e JetPack — kernel, drivers, firmware
2. Pipeline de inferência — DeepStream e similares
3. Frameworks de inferência — vLLM, SGLang, Llama.cpp, TensorRT Edge-LLM
4. Quantização de modelo — FP16, FP8, W4A16, NVFP4, INT4
5. Aceleradores especializados — ISP, NVENC/NVDEC, PVA

Camada 1: BSP e JetPack (até ~1 GB)

Dois controles principais:

• Desativar desktop gráfico e serviços de UI: até 865 MB recuperados via sudo systemctl set-default multi-user.target
• Desativar rede e journaling não-essencial: até 32 MB

Carveouts

Carveouts são regiões de memória física reservadas no boot pra hardware engines e firmware. Não são acessíveis pelo Linux nem por apps CUDA. Dependendo do caso de uso, dá pra desabilitar:

• Display não necessário: libera 1 MB + 32 MB + 34 MB + 1 MB em carveouts relacionados (DCE_TSEC, DCE, DISP_EARLY_BOOT_FB, TSEC_DCE)
• Câmera não necessária: libera 32 MB (CAMERA_TASKLIST) + 1 MB (RCE)

Essas otimizações exigem editar device tree (tegra234-mb1-bct-misc-p3767-0000.dts) e re-flashar a board. Não é trivial, mas o guia traz os snippets prontos.

SWIOTLB

O Linux SWIOTLB (Software I/O Translation Lookaside Buffer) é fallback pra sistemas sem IOMMU de hardware. Como o Orin já tem IOMMU robusto, geralmente é redundante. Dá pra ajustar pelo boot arg swiotlb=N (cada slab tem 2 KB, então 4 MB = swiotlb=2048).

User space

Identifica processos consumindo mais memória com procrank (ordenado por PSS — Proportional Set Size):

git clone https://github.com/csimmonds/procrank_linux.git
cd procrank_linux/
make && sudo ./procrank

Suspeitos típicos: gnome-shell, Xorg, pulseaudio, processos python3 parados. Em deploy headless, desligar esses serviços de UI libera memória significativa.

Pra medir uso de memória de hardware (CUDA, buffers de vídeo via NvMap):

sudo cat /sys/kernel/debug/nvmap/iovmm/clients

Camada 2: Pipeline de inferência (até 412 MB)

Usando DeepStream como exemplo, mas os princípios se aplicam geral:

• Container vs bare-metal: até 70 MB
• Trocar Python por C++: até 84 MB
• Desabilitar Tiler/OSD e usar FakeSink: até 258 MB

O último item vale explicar: Tiler e OSD (On-Screen Display) existem pra visualização. Em produção headless, são overhead puro — remove e ganha memória + throughput.

Camada 3: Frameworks de inferência

O guia recomenda:

• vLLM — alto throughput via paged attention
• SGLang — workflows programáveis e flexíveis
• Llama.cpp e NVIDIA TensorRT Edge-LLM — otimizados pra ambientes com pouca memória

Pra borda, Llama.cpp e TensorRT Edge-LLM viraram default. Quem tentar subir vLLM cheio num Orin Nano vai sofrer — o paged attention pesa.

Camada 4: Quantização (5 a 10 GB)

Aqui mora o maior ganho. O guia é explícito sobre método: defina antes os requisitos (qualidade mínima aceitável, throughput/latência alvo, memória disponível) e desça precisão progressivamente. Para quando não atender mais a qualidade.

Números concretos citados:

Formatos cobertos: FP16 e FP8 (balanço), W4A16 (agressivo), NVFP4 (4 bits hardware-friendly da NVIDIA), INT4. Suporte varia por plataforma Jetson.

Se a queda de qualidade incomodar, o guia recomenda QAD (quantization-aware distillation — destilação com consciência de quantização) pra recuperar precisão.

Camada 5: Aceleradores especializados

Jetson tem hardware dedicado que tira carga da GPU:

• ISP — processamento de câmera
• NVENC/NVDEC — encode/decode de vídeo
• PVA (Programmable Vision Accelerator) — visão always-on, low-power (sentry mode, detecção de movimento, tracking)

O PVA tá disponível do Orin NX até o Thor. Bom pra workload de visão contínua onde GPU seria desperdício. O SDK cuPVA tá em Early Access.

Caso real: Reachy Mini Jetson Assistant

Pra fechar, o guia traz um exemplo concreto: robô conversacional on-device rodando em Orin Nano de 8 GB, sem cloud. Pipeline multimodal simultâneo:

• Cosmos-Reason2-2B (vision-language) quantizado em 4-bit (Q4_K_M GGUF) via Llama.cpp
• faster-whisper (small.en) pra STT
• Kokoro TTS pra voz
• SDK do robô + dashboard web ao vivo

Como couberam tudo em 8 GB: display manager desligado, headless, VLM no Llama.cpp (e não em framework Python pesado), quantização 4-bit, runtimes otimizados (CTranslate2 pra STT, ONNX Runtime pra TTS e VAD).

De modo geral, combinando 4-bit + runtime eficiente, dá pra rodar LLMs de até ~10B parâmetros e VLMs de até ~4B no Orin Nano 8 GB.

Somando tudo

Se tem uma coisa pra levar: escolhe a quantização certa. NVFP4, INT4 e W4A16 cortam memória e storage mantendo precisão aceitável pra maioria dos workloads de LLM. O resto ajuda, mas quantização é onde o ganho é ordem de grandeza.