Si vas a correr un modelo de lenguaje en un Jetson Orin Nano, los 67 TOPS son casi irrelevantes. La generación de texto está limitada por la velocidad a la que el equipo puede leer los pesos del modelo desde memoria, no por su capacidad de cálculo. Una medición independiente sobre el Orin Nano Super 8 GB encontró un ancho de banda real de 59,40 GB/s frente a los 102 GB/s teóricos, y una utilización promedio del hardware de cómputo de apenas 20,8%. Entender eso cambia por completo qué equipo comprar y qué modelo elegir.
Por qué el decode es un problema de memoria, no de cálculo
Para generar cada token, el modelo debe recorrer todos sus pesos. Un modelo de 8B cuantizado a 4 bits pesa unos 4,5 GB: para escupir un token hay que leer esos 4,5 GB. Con 102 GB/s de ancho de banda teórico, el techo aritmético es de unos 22,3 tokens por segundo. NVIDIA midió 19,10 en su tabla oficial, o sea el 86% de ese techo. No hay margen de optimización mágico: el límite es físico.
En jerga técnica, el decode autorregresivo opera a ~1 operación por byte leído, mientras que el punto en que el Orin Nano pasa a estar limitado por cómputo está en 20,48. Está unas 20 veces al lado equivocado. Por eso los tensor cores quedan ociosos.
Qué significa esto al elegir módulo
Acá está la consecuencia que más plata ahorra: el Orin NX 16 GB tiene exactamente el mismo ancho de banda que el Orin Nano Super: 102 GB/s.
Compáralo con la tabla oficial de NVIDIA: Qwen 2.5 7B en INT4 da 21,75 tokens/s en el Orin Nano Super 8 GB y 23,50 en el Orin NX 16 GB. Un 8% más, pese a que el NX declara 157 TOPS contra 67. Subir de módulo te compra capacidad —modelos más grandes, más contexto—, no velocidad proporcional.
Lo mismo explica el modo Super. En el Orin Nano el salto fue real porque el ancho de banda subió de 68 a 102 GB/s: las ganancias medidas por NVIDIA van de 1,37× a 1,64×. En el Orin NX el ancho de banda no cambió, y por eso su ganancia es de solo 1,11× a 1,26×.
Cuánta memoria tienes de verdad
Los 8 GB del módulo no son 8 GB para ti:
- ~7,3 GB visibles para el sistema tras el carveout de hardware.
- ~6,7–6,9 GB si arrancas sin escritorio gráfico.
- ~5,9–6,1 GB con el escritorio de Ubuntu corriendo. Desactivarlo libera unos 800 MB según la documentación de NVIDIA.
Y es memoria unificada: CPU, GPU, caché KV, buffers de visión y sistema operativo compiten por el mismo pozo. No hay VRAM aparte. Hay un caso reportado al soporte de NVIDIA donde una aplicación con VILA-7B usó 6,1 GB de 6,3 GB disponibles —el 97%— y murió por falta de memoria.
Qué cabe realmente en 8 GB
Un modelo de 8B en 4 bits sí entra. La tabla oficial de NVIDIA no tiene ninguna celda vacía para el Orin Nano 8 GB: Llama 3.1 8B corre a 19,10 tokens/s y Gemma 2 9B a 9,21. Pero el presupuesto queda así: pesos ~4,5–4,7 GB, RAM útil sin escritorio ~6,7–6,9 GB, y sobrante para caché KV, runtime y tu aplicación de apenas 2,0 a 2,4 GB. Con escritorio activo, entre 1,2 y 1,5 GB.
Traducido: el 8B entra, pero te quedas casi sin contexto y sin margen. Si además abres una cámara, un servidor web y una base vectorial, deja de ser viable.
Lo que definitivamente no cabe: cualquier modelo de 7B en FP16 (12,55 GiB de pesos) o en Q8_0 (6,67 GiB), LLaVA-13B y VILA1.5-13B —la documentación de NVIDIA lo dice literalmente—, y los modelos de visión sobre unos 4B.
Cifras que puedes esperar
De la medición independiente más completa que existe para el Orin Nano Super 8 GB, con metodología publicada (JetPack L4T 36.4.7, llama.cpp build b9292, contexto 2048, generación 256 tokens, mediana de 20 peticiones, perfil de 25 W):
- SmolLM2-135M Q4_K_M: 165,2 tok/s, primer token en ~80 ms
- Qwen2.5-0.5B Q4_K_M: 92,9 tok/s, ~200 ms
- Llama-3.2-1B Q4_K_M: 47,1 tok/s, ~350 ms
- Gemma3-1B Q4_K_M: 40,8 tok/s, ~400 ms
Para referencia, una persona lee a unos 20 tokens por segundo. Todo lo de arriba se siente instantáneo.
Tres ajustes que valen más que cambiar de modelo
1. El perfil de potencia. Un usuario reportó pasar de 8 tok/s a 21 tok/s en el mismo equipo solo con sudo nvpmodel -m 0 seguido de sudo jetson_clocks. Otro ganó 46–48% únicamente con jetson_clocks, un paso que no aparecía en las instrucciones que estaba siguiendo. Un benchmark de Jetson que no declara el modo de potencia no vale nada.
2. Los 25 W son el punto óptimo, no MAXN. El perfil de 25 W entrega entre 35% y 47% más tokens por segundo que el de 15 W consumiendo solo 34–42% más potencia, y resulta entre 9% y 23% más eficiente por joule que MAXN.
3. llama.cpp por sobre Ollama. En arquitecturas clásicas la diferencia es de apenas 3%, pero en modelos recientes con arquitecturas híbridas la brecha llega a 3,35× (79,8 contra 23,8 tok/s), porque Ollama incorpora una versión de llama.cpp varios meses más antigua. Y de paso, un mito que conviene enterrar: Ollama en Orin sí usa CUDA por defecto. La creencia contraria viene del Jetson Nano de 2019.
Precisiones que tu Orin no soporta
La documentación de NVIDIA es explícita: «Jetson Orin soporta precisión FP16, INT8 e INT4 en ejecución. No selecciones checkpoints FP8, MXFP8, FP4 o NVFP4 para Orin». FP8 requiere arquitectura Ada o superior y NVFP4 requiere Blackwell; Orin es Ampere.
Detalle fino que casi nadie menciona: el «INT4» de Orin es en realidad W4A16 — los pesos se guardan en 4 bits y se desempaquetan al vuelo para multiplicar en FP16. Otra razón por la que lo que compras es ancho de banda, no operaciones de tensor core.
Por qué nunca reproduces los números publicados
Este es el punto que más frustración ahorra. El arnés con el que NVIDIA midió su tabla oficial usa un prompt de entrada de 16 tokens y genera 128, promediando 3 corridas. Está documentado en el repositorio, pero no en el blog que todos citan.
Con un prompt de 16 tokens prácticamente no hay caché KV que recorrer. Con prompts reales de RAG, de 2.000 tokens o más, los números caen. Hay un reporte público de alguien que obtuvo ~19 tok/s donde se publicaban ~47, y otro que consiguió 25 tok/s donde la tabla decía 40,4; este último pidió a NVIDIA el detalle del montaje y nunca recibió respuesta. No es que mientan: es que las condiciones no son las tuyas.
Sobre la cuantización
Un detalle contraintuitivo: Q4_K_M castiga más a los modelos modernos. En LLaMA-1-7B costaba +0,0535 de perplejidad; en Llama-3.1-8B-Instruct cuesta +0,24, una penalización unas 4,5 veces mayor. En capacidades medidas, MMLU baja 1,07 puntos con Q4_K_M y solo 0,70 con Q5_K_M, mientras GSM8K y HellaSwag quedan dentro del ruido.
Si la calidad importa, Q5_K_M es el punto medio: cuesta 17% más bytes que Q4_K_M y recupera dos tercios de la perplejidad perdida.
Lo que nadie ha medido
Por honestidad, y porque conviene saberlo antes de comprometerse: no existe ninguna medición pública del tamaño de la caché KV ni del contexto máximo por modelo en un Orin Nano de 8 GB. Los valores de contexto que circulan son parámetros de configuración elegidos, no techos medidos. Tampoco hay tiempos de primer token publicados para el Orin NX 16 GB en ninguna fuente.
La única evidencia empírica de contexto largo en Jetson viene de un Orin NX de 16 GB: un modelo de 12,36 GiB dejó espacio para apenas ~5,5k tokens de contexto; bajando a 11,1 GiB se alcanzaron entre 22,9k y 64k. Y un dato que rompe la intuición: cuantizar la caché KV bajó el rendimiento en vez de subirlo (de 13,82 a 9,57 tok/s en un caso, de 20,80 a 7,85 en otro).
La recomendación corta
Para chat fluido: Llama 3.2 3B o Phi-3.5 3.8B en INT4 (43,07 y 38,10 tok/s). Para agentes con muchas llamadas cortas: Qwen3-0.6B, que da 72,8 tok/s de decode ocupando 1.889 MB y te deja casi 5 GB libres para el resto del sistema. Para resumen por lotes, donde nadie espera: Qwen 2.5 7B a 21,75 tok/s, la mejor calidad que entra en 8 GB. Y si necesitas un 7B con contexto útil o un modelo multimodal grande, el módulo correcto no es el Nano: es el Orin NX de 16 GB, por sus 16 GB, no por sus TOPS.