Otimização de Memória no JetPack 7.2
O Jetson usa memória unificada, portanto o sistema operacional, cargas de trabalho de GPU, firmware de câmera e display, pesos de modelo, engines TensorRT, cache KV e serviços de aplicação competem pela mesma DRAM física. A otimização de memória, portanto, precisa cobrir tanto a plataforma quanto a carga de trabalho de inferência.
Este guia combina o material do JetPack 7.2 já disponível nesta coleção:
- o JetPack 7.2 Deep Dive, incluindo a redução medida de memória após carregar um modelo de 27B;
- o workflow NVIDIA Skills para diagnóstico do dispositivo, auditoria de memória e implantação sem monitor;
- o guia TensorRT Edge-LLM para inferência em FP16, INT8 e INT4 no JetPack 7.2.
As alterações de recuperação de memória em nível de BSP modificam o firmware de boot, device trees e configurações da linha de comando do kernel. Aplique apenas receitas validadas de headless, no-camera ou SWIOTLB em um dispositivo de teste recuperável. Mantenha o BSP original e confirme que o dispositivo pode ser regravado antes de fazer essas alterações.
Camadas de Otimização
Use a camada menos invasiva que resolva o problema.
| Camada | Ação típica | Risco | Reboot ou reflash |
|---|---|---|---|
| Medição | Registrar memória disponível e uso por processo | Baixo | Não |
| Configuração de inferência | Quantização, contexto mais curto, tamanho de lote 1, menor concorrência | Baixo | Não |
| Configuração de serviços | Alvo sem monitor, parar servidores de modelo duplicados, desabilitar serviços de usuário não utilizados | Médio | Normalmente reboot |
| Recuperação de memória no BSP | Desabilitar firmware e memória reservada de display ou câmera não utilizados | Alto | Recompilar e regravar |
| Ajuste de SWIOTLB | Reduzir o pool de bounce de DMA após medir o uso real | Alto | Recompilar e regravar |
1. Registrar uma Linha de Base Reproduzível
Confirme a versão de software e capture a memória antes de iniciar a aplicação:
cat /etc/nv_tegra_release
free -h
grep -E 'MemTotal|MemAvailable|SwapTotal|SwapFree|CmaTotal|CmaFree' /proc/meminfo
Monitore memória unificada, uso de GPU, temperaturas e potência enquanto carrega e executa o modelo:
sudo tegrastats --interval 1000
Em outro terminal, identifique os maiores processos e grupos de controle:
ps -eo pid,comm,rss,vsz,%mem --sort=-rss | head -20
systemd-cgtop
Registre pelo menos quatro estados:
- após o boot e antes de a aplicação iniciar;
- após o carregamento do modelo ou da engine TensorRT;
- durante o prefill do prompt ou o pico de pré-processamento de visão;
- durante a geração de tokens em estado estacionário ou a operação da aplicação.
Não compare apenas o valor used de free. Use MemAvailable, a lista de RSS por processo e o pico reportado por tegrastats em conjunto.
2. Usar Skills para Auditar Antes de Editar o BSP
O workflow orientado por skills deve começar com observação em vez de mudanças imediatas de configuração.
Diagnosticar o Dispositivo
Use jetson-diagnostic para coletar o módulo, versão JetPack/L4T, estado de memória, armazenamento, térmicas, serviços e endpoints de hardware visíveis.
Prompt de exemplo:
/jetson-diagnostic Confirm that this device is running JetPack 7.2 / L4T 39.2,
capture its idle memory baseline, and identify services or hardware subsystems
that consume memory before the inference application starts.
Auditar Pressão de Memória
Use jetson-memory-audit quando o modelo falhar ao carregar, o OOM killer encerrar um processo ou o uso de memória crescer de forma inesperada.
/jetson-memory-audit Compare idle, engine-load, prefill, and decode memory use.
Separate model weights, KV cache, application processes, filesystem cache,
desktop services, and reserved platform memory where possible.
A auditoria deve produzir evidências antes de recomendar uma mudança. Não desabilite um serviço apenas porque ele aparece perto do topo de uma lista de processos.
Converter Implantações de Appliance para Modo Sem Monitor
Se o Jetson roda sem um display local, use jetson-headless-mode para remover a sobrecarga de desktop no nível de serviços.
O target padrão do systemd é:
sudo systemctl set-default multi-user.target
sudo reboot
Confirme o acesso por SSH antes de reiniciar. Essa mudança em nível de serviço é separada da recuperação de carveouts de firmware de display no BSP.
Usar jetson-optimize-memory Apenas para Cenários de BSP Validados
A skill em nível de BSP oferece suporte a três workflows delimitados:
| Cenário | Implantação pretendida | Área de plataforma recuperada |
|---|---|---|
headless | Sem saída de display local | Firmware de DCE/display, framebuffer inicial e nós de kernel correspondentes |
no-camera | Sem CSI, GMSL ou outro pipeline de câmera | RCE, VI, ISP, NVCSI e carveouts de firmware correspondentes |
swiotlb | Uso medido do pool de bounce de DMA muito abaixo do pool reservado | Uma alocação SWIOTLB menor e diferente de zero |
Solicitações de exemplo:
/jetson-optimize-memory headless
/jetson-optimize-memory no-camera
/jetson-optimize-memory swiotlb
Para mudanças em carveouts, o MB1 BCT, os controles de carregamento do MB2, as referências AST do MB2 e os nós de device-tree do kernel devem permanecer consistentes. Zerar apenas uma entrada de carveout não é uma otimização válida. Para SWIOTLB, nunca configure um pool de tamanho zero e reverta imediatamente se io_tlb_used se aproximar de io_tlb_nslabs.
3. Reduzir o Uso de Memória de LLM e VLM
Escolher a Menor Precisão Suportada
O TensorRT Edge-LLM no JetPack 7.2 oferece suporte a FP16, INT8 e INT4 no Jetson Orin. Comece com FP16 para validar a correção e, em seguida, avalie checkpoints INT8 ou INT4 suportados pelo modelo selecionado.
| Precisão | Tendência de memória | Uso recomendado |
|---|---|---|
| FP16 | Maior entre os caminhos suportados no Orin | Linha de base funcional e cargas de trabalho sensíveis à acurácia |
| INT8 | Menor memória de pesos com compensações moderadas de acurácia | Avaliação de produção equilibrada |
| INT4 | Menor memória de pesos entre os caminhos suportados | Modelos grandes ou implantações com múltiplos serviços e DRAM limitada |
Não presuma que alterar um flag da engine quantiza corretamente um checkpoint FP16. Use um checkpoint e um caminho de exportação suportados pelo modelo e então reconstrua a engine TensorRT no JetPack 7.2.
Controlar Contexto, Cache KV e Concorrência
A memória de LLM não é determinada apenas pelos pesos do modelo. O cache KV cresce com o comprimento do contexto, tamanho de lote, tokens gerados e requisições concorrentes.
Comece com uma requisição conservadora:
{
"batch_size": 1,
"max_generate_length": 128,
"requests": [
{
"messages": [
{
"role": "user",
"content": "Summarize the current device status."
}
]
}
]
}
Em seguida, aumente uma dimensão por vez:
- comprimento do contexto de entrada;
- comprimento da geração;
- tamanho de lote;
- requisições concorrentes;
- serviços adicionais de visão ou robótica.
Se a memória subir abruptamente durante o prefill, encurte o prompt ou a janela de contexto. Se ela subir à medida que as sessões permanecem ativas, inspecione a retenção de cache KV e o tratamento de requisições concorrentes.
Evitar Carregamentos Duplicados de Modelo
Use um único servidor de modelo de longa duração quando várias aplicações precisarem do mesmo modelo. Scripts Python separados, notebooks, servidores de teste e serviços de produção podem cada um carregar outra cópia dos pesos ou da engine.
Antes de iniciar a inferência, verifique se já existem processos de modelo:
ps -ef | grep -E 'llm|triton|python|ollama' | grep -v grep
Pare apenas processos que sejam confirmadamente duplicados. Não encerre serviços de sistema apenas com base em uma correspondência de nome.
Manter Exportação e Build da Engine Fora do Alvo Sempre que Possível
O TensorRT Edge-LLM usa um host x86 com GPU para exportar o checkpoint e o Jetson para construir a engine de destino. A exportação pode exigir várias vezes o tamanho do checkpoint em RAM e VRAM, portanto manter a exportação no host preserva a memória do Jetson para validação e inferência.
Durante o build da engine, feche servidores de modelo não relacionados e registre o pico de memória separadamente da memória em tempo de execução. A pressão de memória durante o build não representa necessariamente o requisito de implantação em estado estacionário.
Tratar Swap como Ferramenta de Recuperação, Não como DRAM Livre
Swap pode ajudar a concluir uma conversão de modelo ou build de engine pontual, mas trocas sustentadas aumentam a latência e podem elevar o desgaste do armazenamento. Para inferência em tempo real, prefira um modelo menor ou quantizado, contexto mais curto, menor concorrência e menos serviços duplicados antes de depender de swap.
4. Validar o Resultado
Use o mesmo prompt, entrada, modo de potência e topologia de aplicação antes e depois de cada mudança.
| Métrica | Por que é importante |
|---|---|
MemAvailable em idle | Mede a sobrecarga do sistema e dos serviços |
| Memória após o carregamento da engine | Mostra o footprint do modelo e do runtime |
| Pico de memória no prefill | Expõe a pressão de contexto e de workspace temporário |
| Memória de decodificação em estado estacionário | Mostra cache KV e retenção de sessão |
| Tempo até o primeiro token | Detecta regressões causadas por swap ou workspaces restritos |
| Throughput de decodificação | Confirma que a menor memória não tornou a inferência inutilizavelmente lenta |
| Temperatura e potência da placa | Confirma que o resultado é estável, não apenas um pico curto |
O JetPack 7.2 Deep Dive registrou a memória após o carregamento de um modelo de 27B caindo de aproximadamente 24,6 GB no JetPack 6.2 para 14,7 GB no JetPack 7.2 na comparação da Seeed. Trate esse resultado como uma referência específica de carga de trabalho, não como uma redução garantida para todo modelo.
Ordem recomendada
- Meça a memória em idle, com carga de engine, prefill e decode.
- Remova processos de modelo duplicados e serviços de aplicativo desnecessários.
- Reduza o contexto, o comprimento de geração, o tamanho de batch e a simultaneidade.
- Avalie checkpoints INT8 ou INT4 compatíveis com TensorRT Edge-LLM.
- Use
jetson-headless-modepara implantações de appliances sem display. - Use
jetson-optimize-memory headlessouno-camerasomente quando o cenário de hardware corresponder exatamente. - Considere a redução de SWIOTLB somente após medir o uso real do bounce-pool de DMA.
- Execute novamente testes de correção, latência, throughput, térmica e estabilidade após cada alteração.
Rollback
- Restaure o target de serviço original se um desktop gráfico for necessário novamente.
- Restaure o BSP original e reflashe se uma alteração de carveout ou device-tree causar falhas de boot ou de periféricos.
- Reverta as alterações de SWIOTLB se erros de DMA aparecerem ou se o uso se aproximar do pool configurado.
- Mantenha o último engine TensorRT e configuração de modelo conhecidos como bons até que a configuração otimizada seja aprovada nos testes de aceitação.
Suporte técnico e discussão de produtos
Obrigado por escolher produtos Seeed Studio! Para suporte técnico e discussão de produtos, utilize os seguintes canais: