A NVIDIA publicou um guia prático pra rodar LLMs e VLMs grandes nos Jetson Orin Nano, Orin NX e Thor sem estourar a RAM unificada. O texto mapeia 5 camadas de otimização — do BSP até quantização — com ganhos medidos de até 10–12 GB. Inclui caso real do Reachy Mini rodando pipeline multimodal completo em 8 GB.
Guia raiz pra quem roda Jetson em robótica ou visão. Útil mesmo pra quem não tá em borda: o approach de "defina requisito, desce precisão progressivamente" serve pra qualquer pipeline de quantização.
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".
O guia organiza otimização em camadas, de baixo pra cima:
Dois controles principais:
sudo systemctl set-default multi-user.targetCarveouts 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:
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.
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).
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
Usando DeepStream como exemplo, mas os princípios se aplicam geral:
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.
O guia recomenda:
Pra borda, Llama.cpp e TensorRT Edge-LLM viraram default. Quem tentar subir vLLM cheio num Orin Nano vai sofrer — o paged attention pesa.
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:
| Modelo | Quantização | Memória recuperada |
|---|---|---|
| Qwen3 8B | FP16 → W4A16 | ~10 GB |
| Qwen3 4B | BF16 → INT4 | ~5,6 GB |
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.
Jetson tem hardware dedicado que tira carga da GPU:
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.
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:
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.
| Camada | Economia potencial |
|---|---|
| BSP e serviços de OS | ~1.025 MB |
| Pipeline | ~412 MB |
| Frameworks + quantização | ~5 a 10 GB |
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.
☕ gostou dessa?
Matérias favoritadas ficam no seu /favoritos e, se você tem o cafecomtech instalado, disponíveis offline — no metrô, no avião, na fila do café.
☕ comentários · 0