Optimización de memoria en JetPack 7.2
Jetson utiliza memoria unificada, por lo que el sistema operativo, las cargas de trabajo de GPU, el firmware de cámara y pantalla, los pesos del modelo, los motores de TensorRT, la caché KV y los servicios de la aplicación compiten todos por la misma DRAM física. Por lo tanto, la optimización de memoria debe abarcar tanto la plataforma como la carga de trabajo de inferencia.
Esta guía combina el material de JetPack 7.2 ya disponible en esta colección:
- el JetPack 7.2 Deep Dive, incluyendo la reducción medida de memoria después de cargar un modelo de 27B;
- el flujo de trabajo NVIDIA Skills para diagnóstico del dispositivo, auditoría de memoria y despliegue sin pantalla;
- la guía de TensorRT Edge-LLM para inferencia FP16, INT8 e INT4 en JetPack 7.2.
Los cambios de recuperación de memoria a nivel de BSP modifican el firmware de arranque, los device trees y los parámetros de la línea de comandos del kernel. Aplica únicamente recetas validadas de headless, no-camera o SWIOTLB a un dispositivo de prueba recuperable. Conserva el BSP original y confirma que el dispositivo se puede reflashear antes de realizar estos cambios.
Capas de optimización
Utiliza la capa menos invasiva que resuelva el problema.
| Capa | Acción típica | Riesgo | Reinicio o reflash |
|---|---|---|---|
| Medición | Registrar memoria disponible y uso por proceso | Bajo | No |
| Configuración de inferencia | Cuantización, contexto más corto, tamaño de lote 1, menor concurrencia | Bajo | No |
| Configuración de servicios | Objetivo sin pantalla, detener servidores de modelo duplicados, deshabilitar servicios de usuario no usados | Medio | Normalmente reinicio |
| Recuperación de memoria del BSP | Deshabilitar firmware y memoria reservada de pantalla o cámara no utilizados | Alto | Reconstruir y reflashear |
| Ajuste de SWIOTLB | Reducir el pool de rebote DMA después de medir el uso real | Alto | Reconstruir y reflashear |
1. Registrar una línea base reproducible
Confirma la versión de software y captura la memoria antes de iniciar la aplicación:
cat /etc/nv_tegra_release
free -h
grep -E 'MemTotal|MemAvailable|SwapTotal|SwapFree|CmaTotal|CmaFree' /proc/meminfo
Supervisa la memoria unificada, el uso de GPU, las temperaturas y la energía mientras se carga y ejecuta el modelo:
sudo tegrastats --interval 1000
En otra terminal, identifica los procesos y grupos de control más grandes:
ps -eo pid,comm,rss,vsz,%mem --sort=-rss | head -20
systemd-cgtop
Registra al menos cuatro estados:
- después del arranque y antes de que la aplicación se inicie;
- después de que se cargue el modelo o el motor de TensorRT;
- durante el prefill del prompt o el pico de preprocesamiento de visión;
- durante la generación de tokens en estado estable o la operación de la aplicación.
No compares solo el valor used de free. Utiliza MemAvailable, la lista de RSS de procesos y el pico reportado por tegrastats en conjunto.
2. Usar Skills para auditar antes de editar el BSP
El flujo de trabajo basado en skills debe comenzar con la observación en lugar de cambios de configuración inmediatos.
Diagnosticar el dispositivo
Usa jetson-diagnostic para recopilar el módulo, la versión de JetPack/L4T, el estado de memoria, el almacenamiento, la temperatura, los servicios y los endpoints de hardware visibles.
Prompt de ejemplo:
/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 la presión de memoria
Usa jetson-memory-audit cuando el modelo no se cargue, el OOM killer termine un proceso o el uso de memoria crezca 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.
La auditoría debe producir evidencia antes de recomendar un cambio. No deshabilites un servicio solo porque aparezca cerca de la parte superior de una lista de procesos.
Convertir despliegues tipo appliance a modo sin pantalla
Si el Jetson se ejecuta sin una pantalla local, usa jetson-headless-mode para eliminar la sobrecarga del escritorio a nivel de servicios.
El target estándar de systemd es:
sudo systemctl set-default multi-user.target
sudo reboot
Confirma el acceso por SSH antes de reiniciar. Este cambio a nivel de servicios es independiente de recuperar los carveouts de firmware de pantalla en el BSP.
Usar jetson-optimize-memory solo para escenarios de BSP validados
La skill a nivel de BSP admite tres flujos de trabajo acotados:
| Escenario | Despliegue previsto | Área de plataforma recuperada |
|---|---|---|
headless | Sin salida de pantalla local | Firmware DCE/pantalla, framebuffer temprano y nodos de kernel correspondientes |
no-camera | Sin CSI, GMSL u otra canalización de cámara | RCE, VI, ISP, NVCSI y carveouts de firmware correspondientes |
swiotlb | El uso medido del pool de rebote DMA está muy por debajo del pool reservado | Una asignación SWIOTLB más pequeña y distinta de cero |
Solicitudes de ejemplo:
/jetson-optimize-memory headless
/jetson-optimize-memory no-camera
/jetson-optimize-memory swiotlb
Para cambios de carveout, el MB1 BCT, los controles de carga de MB2, las referencias AST de MB2 y los nodos del device tree del kernel deben permanecer coherentes. Poner a cero solo una entrada de carveout no es una optimización válida. Para SWIOTLB, nunca configures un pool de tamaño cero y revierte inmediatamente si io_tlb_used se aproxima a io_tlb_nslabs.
3. Reducir el uso de memoria de LLM y VLM
Elegir la precisión más pequeña compatible
TensorRT Edge-LLM en JetPack 7.2 admite FP16, INT8 e INT4 en Jetson Orin. Comienza con FP16 para validar la corrección y luego evalúa checkpoints INT8 o INT4 compatibles con el modelo seleccionado.
| Precisión | Tendencia de memoria | Uso recomendado |
|---|---|---|
| FP16 | La más alta de las rutas compatibles en Orin | Línea base funcional y cargas de trabajo sensibles a la precisión |
| INT8 | Menor memoria de pesos con compromisos moderados de precisión | Evaluación de producción equilibrada |
| INT4 | La menor memoria de pesos entre las rutas compatibles | Modelos grandes o despliegues multi-servicio con DRAM limitada |
No asumas que cambiar un flag del motor cuantiza correctamente un checkpoint FP16. Usa un checkpoint y una ruta de exportación compatibles con el modelo y luego reconstruye el motor de TensorRT en JetPack 7.2.
Controlar contexto, caché KV y concurrencia
La memoria de un LLM no está determinada solo por los pesos del modelo. La caché KV crece con la longitud del contexto, el tamaño de lote, los tokens generados y las solicitudes concurrentes.
Comienza con una solicitud conservadora:
{
"batch_size": 1,
"max_generate_length": 128,
"requests": [
{
"messages": [
{
"role": "user",
"content": "Summarize the current device status."
}
]
}
]
}
Luego incrementa una dimensión a la vez:
- longitud del contexto de entrada;
- longitud de generación;
- tamaño de lote;
- solicitudes concurrentes;
- servicios adicionales de visión o robótica.
Si la memoria aumenta bruscamente durante el prefill, acorta el prompt o la ventana de contexto. Si aumenta a medida que las sesiones permanecen activas, inspecciona la retención de la caché KV y el manejo de solicitudes concurrentes.
Evitar cargas duplicadas de modelos
Utiliza un único servidor de modelos de larga ejecución cuando varias aplicaciones necesiten el mismo modelo. Scripts de Python separados, notebooks, servidores de prueba y servicios de producción pueden cargar cada uno otra copia de los pesos o del motor.
Antes de iniciar la inferencia, comprueba si existen procesos de modelo ya en ejecución:
ps -ef | grep -E 'llm|triton|python|ollama' | grep -v grep
Detén solo procesos que sepas con certeza que son duplicados. No termines servicios del sistema basándote únicamente en una coincidencia de nombre.
Mantener la exportación y la construcción del motor fuera del objetivo cuando sea posible
TensorRT Edge-LLM utiliza un host GPU x86 para la exportación del checkpoint y el Jetson para la construcción del motor de destino. La exportación puede requerir varias veces el tamaño del checkpoint en RAM y VRAM, por lo que mantener la exportación en el host preserva la memoria de Jetson para validación e inferencia.
Durante la construcción del motor, cierra servidores de modelos no relacionados y registra el pico de memoria por separado de la memoria en tiempo de ejecución. La presión de memoria durante la construcción no representa necesariamente el requisito de despliegue en estado estable.
Tratar el swap como una herramienta de recuperación, no como DRAM libre
El swap puede ayudar a que finalice una conversión de modelo o construcción de motor puntual, pero el intercambio sostenido aumenta la latencia y puede incrementar el desgaste del almacenamiento. Para inferencia en tiempo real, prefiere un modelo más pequeño o cuantizado, un contexto más corto, menor concurrencia y menos servicios duplicados antes de depender del swap.
4. Validar el resultado
Utiliza el mismo prompt, entrada, modo de energía y topología de aplicación antes y después de cada cambio.
| Métrica | Por qué importa |
|---|---|
MemAvailable en reposo | Mide la sobrecarga del sistema y los servicios |
| Memoria después de cargar el motor | Muestra la huella del modelo y del runtime |
| Pico de memoria durante el prefill | Expone la presión del contexto y del espacio de trabajo temporal |
| Memoria de decodificación en estado estable | Muestra la caché KV y la retención de sesiones |
| Tiempo hasta el primer token | Detecta regresiones causadas por swap o espacios de trabajo restringidos |
| Rendimiento de decodificación | Confirma que la menor memoria no hizo que la inferencia fuera inaceptablemente lenta |
| Temperatura y potencia de la placa | Confirma que el resultado es estable, no un pico breve |
El JetPack 7.2 Deep Dive registró que la memoria después de cargar un modelo de 27B cayó de aproximadamente 24.6 GB en JetPack 6.2 a 14.7 GB en JetPack 7.2 en la comparación de Seeed. Toma ese resultado como una referencia específica de la carga de trabajo, no como una reducción garantizada para cada modelo.
Orden recomendado
- Mide la memoria en reposo, con carga del motor, de prellenado y de decodificación.
- Elimina procesos de modelos duplicados y servicios de aplicaciones innecesarios.
- Reduce el contexto, la longitud de generación, el tamaño de lote y la concurrencia.
- Evalúa checkpoints INT8 o INT4 compatibles con TensorRT Edge-LLM.
- Usa
jetson-headless-modepara despliegues de dispositivos sin pantalla. - Usa
jetson-optimize-memory headlessono-camerasolo cuando el escenario de hardware coincida exactamente. - Considera la reducción de SWIOTLB solo después de medir el uso real del bounce-pool de DMA.
- Vuelve a ejecutar las pruebas de corrección, latencia, rendimiento, térmicas y de estabilidad después de cada cambio.
Reversión
- Restaura el objetivo de servicio original si se vuelve a necesitar un escritorio gráfico.
- Restaura la fuente BSP original y vuelve a flashear si un cambio de carveout o de device-tree provoca fallos de arranque o de periféricos.
- Revierte los cambios de SWIOTLB si aparecen errores de DMA o el uso se aproxima al pool configurado.
- Conserva el último motor TensorRT y la configuración de modelo conocidos como correctos hasta que la configuración optimizada supere las pruebas de aceptación.
Soporte técnico y debate sobre productos
Gracias por elegir productos de Seeed Studio. Para soporte técnico y debate sobre productos, utiliza los siguientes canales: