Cómo ejecutar Gemma 4 VLA en un Jetson Orin Nano Super: guía práctica

Qué es esta demo y por qué importa

La demo de Gemma 4 VLA muestra un asistente multimodal que decide autónomamente si necesita usar visión para responder a una pregunta. La cadena de procesamiento es simple y local: audio de entrada → STT (Parakeet) → Gemma 4 → (si es necesario, hace una foto con la webcam y usa la visión) → TTS (Kokoro) → salida por parlante. Todo corre en una NVIDIA Jetson Orin Nano Super de 8 GB.

Este enfoque no se basa en palabras clave ni en lógica rígida: el modelo evalúa el contexto y, si considera que necesita ver algo, activa la cámara, interpreta la imagen con su “vision projector” y responde considerando lo que vio. Para entornos donde la latencia y la privacidad importan —por ejemplo, kioscos de atención, dispositivos en campo o demostradores en ferias—, poder ejecutar todo localmente es una ventaja clara.

Hardware y software usados (resumen)

• Jetson Orin Nano Super (8 GB)
• Webcam Logitech C920 (micrófono integrado en el ejemplo)
• Parlante USB y teclado USB
• Repositorio con el script: https://github.com/asierarranz/Google_Gemma (archivo principal Gemma4_vla.py)

El script de la demo descarga en su primer arranque los modelos de STT/TTS y las voces desde Hugging Face. No están atados a hardware específico: cualquier webcam, micrófono USB y parlante reconocido por Linux pueden funcionar.

Preparación del sistema

1. Paquetes básicos: actualicen el sistema e instalen utilidades esenciales para compilar, manejar audio y video, y Python (herramientas como git, cmake, alsa/pulse, v4l-utils, ffmpeg y librerías de Python). En sistemas Jetson conviene incluir dependencias para compilación nativa si van a construir llama.cpp.

2. Entorno Python: creen un virtualenv, activenlo e instalen las librerías necesarias (OpenCV, onnx-asr, kokoro-onnx, soundfile, huggingface-hub, numpy, etc.). El script principal está preparado para conectar con los modelos en Hugging Face.

3. Scripts y código: pueden clonar el repo completo o descargar solo Gemma4_vla.py. Ese archivo orquesta el flujo de audio, llama-server y la cámara.

Manejo de memoria: por qué agregar swap y limpiar procesos

Una Jetson con 8 GB está bien para esta demo, pero quedan pocos márgenes cuando se cargan modelos potentes. Para evitar errores de falta de memoria (OOM) conviene:

• Crear un archivo de swap (por ejemplo 8 GB) para tener un colchón durante la carga de modelos. No acelera inferencia, pero evita que el sistema mate procesos en momentos críticos.
• Detener servicios pesados que no se requieren (Docker, containerd u otras aplicaciones en segundo plano) y cerrar pestañas o IDEs. Cada MB cuenta.
• Si aún falta memoria, bajar la cuantización del modelo (por ejemplo usar una versión Q3 en vez de Q4) reduce uso de RAM/GPU a costa de algo de capacidad.

En las pruebas, combinando swap y limpieza, la cuantización Q4_K_M funciona cómodamente en 8 GB; Q3 es una alternativa si el hardware ya está muy ocupado.

Servir Gemma 4: compilar y ejecutar llama-server

Para obtener el mejor rendimiento y tener control sobre el componente de visión, la guía recomienda compilar llama.cpp nativamente en el Jetson (con soporte CUDA si la placa lo admite). La construcción nativa suele dar mejor desempeño que contenedores precompilados y permite exponer el “vision projector” que Gemma utiliza para interpretar imágenes.

También deben descargar dos archivos clave al directorio de modelos:

• El archivo del modelo Gemma 4 en formato GGUF (nombre del ejemplo: gemma-4-E2B-it-Q4_K_M.gguf).
• El archivo del proyector de visión (mmproj-gemma4-e2b-f16.gguf), imprescindible para que Gemma pueda entender imágenes.

Al arrancar llama-server hay varias opciones que configuran memoria, tamaño de batch y el número de capas que se colocan en GPU. Un parámetro importante es el que indica cuántas capas del modelo dejar en GPU; en la guía se usó un valor que intenta colocar todas las capas en la GPU. Si hay problemas de memoria, bajar ese número hace que algunas capas se queden en CPU y puede resolver el problema.

Verifiquen que el servidor responde con una llamada HTTP local simple (por ejemplo un POST a /v1/chat/completions) y reciban JSON: si obtienen respuesta, el servidor está listo.

Configurar micrófono, parlante y webcam

• Micrófono: listarlo con las utilidades de ALSA (arecord -l) para identificar el dispositivo.
• Parlantes: listar sinks de PulseAudio/pipewire para elegir el output correcto.
• Webcam: comprobar con v4l2-ctl --list-devices y probar que aparece como /dev/video0 u otro índice.

El script de la demo pide grabar con la barra espaciadora: presiónen SPACE para iniciar la grabación y SPACE otra vez para detener. La cadena completa en tiempo real es: ustedes hablan → STT (Parakeet) → Gemma 4 decide si necesita ver → si necesita, toma una foto → procesa la imagen con el proyector → responde → Kokoro TTS reproduce la voz en el parlante.

Consideraciones prácticas y para Latinoamérica

• Disponibilidad y soporte: las placas Jetson y accesorios pueden ser más difíciles de conseguir en algunos países de la región; consideren proveedores locales y tiempos de importación. También revisen fuentes de energía y refrigeración: en entornos calurosos la gestión térmica es crítica.
• Privacidad y cumplimiento: si el dispositivo usa cámara en espacios públicos o privados, revisen normativas locales sobre grabación y consentimiento. Correr el modelo localmente reduce exfiltración de datos, pero siempre se debe informar a los usuarios.
• Casos de uso relevantes: atención en punto de venta, asistentes en ferias y eventos, prototipos en manufactura y control de calidad, herramientas educativas para aula. Ejecutar el flujo completo en un dispositivo embebido permite despliegues sin conexión o con latencia mínima.

Conclusión

La demo de Gemma 4 VLA en Jetson Orin Nano Super muestra que es posible tener un agente multimodal autónomo que decide cuándo usar visión, todo ejecutándose localmente en una placa de 8 GB. Siguiendo los pasos de preparación del sistema, manejo de memoria y compilación nativa de llama.cpp, pueden desplegar una prueba funcional con archivo Gemma4_vla.py y los modelos correspondientes.

Para equipos en Latinoamérica esta aproximación puede ser especialmente útil cuando la privacidad, la latencia o la conectividad son limitantes. Evaluar disponibilidad de hardware, optimizar memoria y cumplir regulaciones locales son claves para pasar de demo a producto.

Si quieren experimentar, el repositorio mencionado contiene el script y ejemplos para arrancar: revisen https://github.com/asierarranz/Google_Gemma y el archivo Gemma4_vla.py como punto de partida.