NVIDIA Jetson ya corre modelos de razonamiento sin conexión

Ejecutar razonamiento e inteligencia artificial agéntica en el borde ha sido más difícil de lo necesario. Hasta hace poco, los modelos capaces de razonar en varios pasos eran demasiado grandes para correr localmente en hardware de borde, así que quienes construían agentes debían enrutar la inferencia a través de un centro de datos, con la dependencia de red, el costo y la exposición de datos que eso implica. Esa restricción se está levantando: varias familias de modelos liberadas durante el verano boreal marcaron en conjunto un punto de inflexión, y NVIDIA Jetson puede ejecutarlas hoy.

El escenario habilita asistentes embarcados en cabina, detección de anomalías en tiempo real y robots que operan en entornos hostiles o remotos. Los sistemas críticos pueden seguir funcionando cuando la conectividad es limitada o simplemente no existe.

La guía de NVIDIA usa dos modelos como ejemplo, Nemotron 3.5 Lightning y Qwen3.8-27B, y responde cuatro preguntas concretas: cómo elegir el modelo, qué aportan la cuantización NVFP4 y la decodificación especulativa, cómo servirlos con vLLM y cómo validar la configuración para cada aplicación.

¿Cómo elegir el modelo para Jetson?

Mejores métodos de entrenamiento y arquitecturas más eficientes explican el cambio. La destilación, por ejemplo, transfiere parte de las capacidades de Nemotron 3 Ultra al modelo más pequeño Nemotron 3.5 Lightning. Las arquitecturas también imponen compromisos distintos entre capacidad, uso de memoria y velocidad de generación.

Qwen3.8-27B es un modelo denso, por lo que activa sus 27.000 millones de parámetros en cada token. Nemotron 3.5 Lightning usa una arquitectura de mezcla de expertos: tiene 30.000 millones de parámetros totales, pero activa solo 3.000 millones por token. Eso los vuelve adecuados para cargas de trabajo diferentes.

La distinción importa sobre todo en agentes de larga duración. Un agente puede vigilar un sistema con datos de sensores en vivo y registros del equipo, ejecutar acciones correctivas aprobadas, verificar los resultados contra pruebas predefinidas y escalar a un especialista solo cuando corresponda. Todo eso corre localmente en el borde, sin conexión a internet y con latencia baja.

Nemotron 3.5 Lightning calza bien en flujos que exigen muchas respuestas, donde generar tokens más rápido acorta el proceso completo. Qwen3.8-27B rinde mejor en tareas con decisiones más difíciles y menos frecuentes, que permiten al agente dedicar más tiempo a cada respuesta.

Para Jetson Orin Nano, NVIDIA recomienda partir con Gemma 4 E4B. Para Jetson AGX Orin y Jetson AGX Thor, las opciones fuertes son Nemotron 3.5 Lightning y Qwen3.8-27B, familias que ya cuentan con checkpoints cuantizados de calidad y despliegues optimizados en los motores de inferencia más usados.

¿Qué aportan NVFP4 y la decodificación especulativa?

Son dos técnicas complementarias. La cuantización NVFP4 reduce el trabajo y la memoria que requiere cada operación del modelo, mientras que la decodificación especulativa permite aceptar varios tokens por cada paso de verificación.

Durante la decodificación, el modelo genera su respuesta un token a la vez y cada token suele exigir otra pasada completa. De ahí salen las dos vías de mejora: reducir el trabajo de cada pasada o producir más tokens por pasada.

La cuantización toma el primer camino. Los valores de menor precisión reducen la cantidad de datos que la GPU debe mover y procesar en cada pasada, y con un formato como NVFP4 se gana velocidad de generación y se baja el uso de memoria manteniendo una calidad cercana a BF16.

La decodificación especulativa toma el segundo. Un modelo borrador más pequeño propone varios tokens y el modelo principal los verifica en conjunto. La decisión final sigue siendo del modelo principal, pero si acepta varias propuestas, la generación avanza varios tokens en un solo paso de verificación.

Existen varios métodos para producir esos borradores, entre ellos MTP, DFlash y DSpark. Los tres corren en Jetson, pero generan y evalúan propuestas de manera distinta:

• MTP usa cabezales de predicción entrenados junto al modelo principal y ya funciona con familias masivas como Qwen, Gemma y Nemotron.
• DFlash emplea un modelo borrador basado en difusión que propone un bloque de tokens en paralelo. Es el que admite la selección más amplia de checkpoints compatibles.
• DSpark se construye sobre DFlash corrigiendo borradores y descartando temprano las propuestas débiles. Puede ser más rápido cuando existe un checkpoint que calce, pero soporta menos opciones.

La configuración especulativa más rápida no fue la misma para ambos modelos: Nemotron 3.5 Lightning rindió mejor con DSpark y Qwen3.8-27B con DFlash2. NVIDIA insiste en probar el método y el checkpoint borrador con el modelo que se va a desplegar, en lugar de suponer que una sola configuración funcionará siempre mejor.

Requisitos y comandos de despliegue

Antes de ejecutar los comandos hay que confirmar cuatro cosas:

• Una placa Jetson AGX Thor o Jetson AGX Orin.
• JetPack 7.2 con NVIDIA Container Runtime y Docker configurados.
• Almacenamiento suficiente para el modelo y los checkpoints borradores.
• Haber aceptado los términos de licencia de NVIDIA Nemotron y de Qwen3.8.

Primero se levanta el contenedor vllm/vllm-openai:v0.28.0:

docker run --pull=always --runtime nvidia --rm -it \
--network host \
--ipc=host \
-v ~/.cache/huggingface:/root/.cache/huggingface \
--entrypoint bash \
vllm/vllm-openai:v0.28.0

Dentro del contenedor, la configuración más rápida probada para Nemotron 3.5 Lightning combina NVFP4 con DSpark:

vllm serve nvidia/NVIDIA-Nemotron-3.5-Lightning-30B-A3B-NVFP4 \
  --reasoning-parser nemotron_v3 \
  --enable-auto-tool-choice \
  --tool-call-parser qwen3_coder \
  --max-model-len 128000 \
  --kv-cache-dtype fp8 \
  --gpu-memory-utilization 0.7 \
  --trust-remote-code \
  --max-num-batched-tokens 16384 \
  --enable-prefix-caching \
  --speculative-config '{"method":"dspark","model":"nvidia/NVIDIA-Nemotron-3.5-Lightning-30B-A3B-NVFP4-DSpark","num_speculative_tokens":5}' \
  --mamba-backend flashinfer \
  --mamba-ssm-cache-dtype float16 \
  --enable-mamba-cache-stochastic-rounding \
  --mamba-cache-philox-rounds 5 \
  --mamba-cache-mode align

Para Qwen3.8-27B se usa el mismo contenedor con la combinación NVFP4 más DFlash2:

VLLM_GDN_DECODE_KERNEL=triton vllm serve Inferact/Qwen3.8-27B-NVFP4 \
  --served-model-name qwen38 \
  --reasoning-parser qwen3 \
  --enable-auto-tool-choice \
  --tool-call-parser qwen3_coder \
  --max-model-len 50000 \
  --max-num-seqs 8 \
  --gpu-memory-utilization 0.85 \
  --trust-remote-code \
  --speculative-config '{"method":"dflash","model":"incoai/Qwen3.8-27B-DFlash2","num_speculative_tokens":7}'

¿Cuánto cambia el rendimiento según la tarea?

Una prueba a nivel de modelo sirve para identificar una buena configuración especulativa, pero cada aplicación genera texto distinto y el rendimiento cambia con la carga. Para medir ese efecto, NVIDIA fijó la configuración más rápida de cada modelo y probó cuatro categorías de SpeedBench: escritura, razonamiento, resumen y generación aumentada por recuperación.

El método más rápido se mantuvo igual para cada modelo en todas las categorías, pero el rendimiento igual varió. Nemotron 3.5 Lightning con DSpark osciló entre 123,01 y 138,02 tokens de salida por segundo, mientras que Qwen3.8-27B con DFlash2 se movió entre 27,69 y 34,44 tokens por segundo. La brecha de casi cuatro veces entre ambos es el costo de la arquitectura densa frente a la mezcla de expertos, y conviene tenerla presente antes de comprometerse con un modelo.

La recomendación es validar la configuración especulativa con indicaciones representativas de la aplicación real. Un conjunto de datos propio permite elegir el método y el checkpoint borrador que mejor funcionen para cada caso de uso.

¿Cuándo conviene entrenar un checkpoint propio?

Para la mayoría de las aplicaciones, lo razonable es partir de un checkpoint cuantizado existente y un modelo borrador ya disponible. Eso suele bastar para obtener buena exactitud y una aceleración útil sin entrenar nada. Antes de desplegar, hay que probar con indicaciones de la propia aplicación: las pruebas generales no dicen si un checkpoint conserva el comportamiento que importa para cada conjunto de datos.

Si la cuantización degrada la exactitud, NVIDIA Model Optimizer permite afinar el modelo cuantizado con entrenamiento consciente de cuantización o con destilación. El primero simula la precisión reducida durante el entrenamiento; la destilación suma además un modelo maestro de mayor precisión para que el modelo cuantizado retenga el comportamiento original. Ese ajuste extra rinde sobre todo en cargas especializadas donde pequeñas variaciones de exactitud sí importan.

Quien quiera seguir ese camino tiene disponible el tutorial de QAT y QAD de NVIDIA Model Optimizer.