Fine-Tuning de Gemma 3: El Modelo Ligero de Google para Despliegue en Dispositivo

Ejecutar IA en un teléfono, una Raspberry Pi o un gateway IoT — sin nunca contactar un servidor — cambia lo que es posible. Sin latencia por viajes de red. Sin costos de API que escalan con los usuarios. Sin dependencia de conectividad a internet. Privacidad completa de datos porque nada sale del dispositivo.

Gemma 3 es la familia de modelos abiertos de Google construida específicamente para esto. Mientras Llama y Qwen fueron diseñados para inferencia del lado del servidor y luego comprimidos para hardware más pequeño, Gemma 3 fue arquitectado desde cero para entornos con recursos limitados. El resultado es un modelo que se ejecuta más rápido, usa menos memoria y maneja las restricciones de dispositivo de manera más elegante que sus competidores en conteos de parámetros equivalentes.

El modelo 4B es el objetivo para la mayoría de los despliegues en dispositivo. Con cuantización Q4_K_M, cabe en menos de 3 GB de RAM — bien dentro de las capacidades de un smartphone moderno, una Raspberry Pi 5 o una pestaña del navegador. Y cuando lo ajustas para una tarea específica, puede realizar esa tarea tan bien como modelos 5x su tamaño.

Tamaños de Modelo de Gemma 3

El modelo 4B alcanza el punto óptimo para dispositivo. Es lo suficientemente grande para manejar tareas significativas (clasificación, extracción, generación simple, detección de intención) mientras es lo suficientemente pequeño para ejecutarse en hardware que la gente ya posee.

El modelo 1B es para restricciones extremas — wearables, sistemas embebidos o escenarios donde necesitas la huella más pequeña posible. Maneja clasificación simple y tareas de formato corto pero tiene dificultades con cualquier cosa que requiera más que coincidencia básica de patrones.

Por Qué Gemma para Dispositivo

Optimizaciones de Arquitectura

Google diseñó Gemma 3 con inferencia en dispositivo en mente:

• Atención de ventana deslizante en capas alternas reduce el uso de memoria en 30-40% comparado con atención completa en longitudes de contexto equivalentes. Para dispositivo, esto significa que puedes procesar entradas más largas sin quedarte sin RAM.
• Atención de consulta agrupada (GQA) con ratio 1:4 comprime la caché KV, reduciendo la asignación de memoria durante inferencia. En un teléfono con 6 GB de RAM, esta es la diferencia entre ejecutarse y fallar.
• RMSNorm con escala aprendible en lugar de LayerNorm — marginalmente más rápido por capa, lo que se acumula sobre miles de millones de operaciones en hardware CPU/NPU.
• Soft-capping de logits estabiliza las probabilidades de salida, reduciendo la posibilidad de outputs degenerados en modelos cuantizados. Cuando estás ejecutando en Q4_0 en un NPU de teléfono, esta estabilidad importa.

Comparación de Velocidad de Inferencia

Gemma 3 4B vs modelos comparables en diferente hardware, todos en Q4_K_M:

Gemma 3 es 15-30% más rápido que modelos de tamaño equivalente en todos los objetivos de dispositivo. En el Apple Neural Engine del iPhone, la ventaja es particularmente pronunciada — Google optimizó la disposición de pesos para el hardware ML de Apple.

Huella de Memoria

Gemma 3 4B tiene un tamaño base ligeramente mayor que los modelos 3B (porque tiene más parámetros), pero su eficiencia de caché KV significa que la brecha se reduce en longitudes de contexto más largas. En contexto 4K, Gemma usa menos RAM que Phi-3.5 Mini a pesar de tener 200M más parámetros.

Ajustando el Modelo 4B

Requisitos de VRAM

Puedes ajustar Gemma 3 4B con QLoRA en una RTX 3060 12GB, una RTX 4060 8GB o una MacBook Pro M1 con 16 GB de memoria unificada. El entrenamiento es rápido — 500 ejemplos típicamente completa en 12-18 minutos en rango 16.

Estrategias de Dataset para Tareas en Dispositivo

Las tareas en dispositivo tienen restricciones específicas que deben dar forma a tus datos de entrenamiento:

Entradas cortas, salidas concisas. En dispositivo, cada token cuesta latencia y memoria. Entrena al modelo para producir outputs mínimos y estructurados:

{"instruction": "Classify intent", "input": "Where's my order?", "output": "order_status"}
{"instruction": "Classify intent", "input": "I want to cancel", "output": "cancellation"}
{"instruction": "Classify intent", "input": "How do I change my payment method?", "output": "account_settings"}

No así:

{"instruction": "Classify the customer's intent from the following message", "input": "Where's my order?", "output": "The customer's intent is to check their order status. Category: order_status"}

La versión verbosa desperdicia tokens tanto en entrada (instrucción más larga) como en salida (explicación que nadie pidió). En un teléfono generando a 28 t/s, cada token innecesario agrega 36ms de latencia.

Optimiza para patrones críticos de latencia. Si el modelo necesita responder en 200ms, tus outputs de entrenamiento deben tener menos de 15 tokens. Diseña tu formato de tarea en consecuencia. Clasificación de etiqueta única (output de 1 token) es ideal para dispositivo. Objetos JSON cortos (5-10 tokens) son aceptables. Generación de longitud de párrafo no es adecuada para uso en dispositivo sensible a latencia.

Incluye casos límite del uso real en dispositivo. Los usuarios móviles escriben diferente que los de escritorio — más errores de tipeo, más abreviaciones, más lenguaje informal. Incluye entradas del mundo real desordenadas en tus datos de entrenamiento:

{"instruction": "Classify intent", "input": "cant login pls help", "output": "authentication"}
{"instruction": "Classify intent", "input": "where tf is my package", "output": "order_status"}
{"instruction": "Classify intent", "input": "refudn pls", "output": "refund"}

Configuración de Entrenamiento

Configuraciones recomendadas para fine-tuning de Gemma 3 4B en dispositivo:

Establecer la longitud máxima de secuencia en 512 en lugar del valor predeterminado de 2048 acelera significativamente el entrenamiento y produce un modelo optimizado para las entradas cortas típicas del uso en dispositivo. Si tu tarea en dispositivo involucra documentos más largos, aumenta a 1024 o 2048 según sea necesario.

Exportación GGUF y Cuantización para Móvil

Después del fine-tuning, exporta al formato GGUF. El nivel de cuantización que elijas depende de tu objetivo de despliegue:

Para apps móviles en teléfonos de los últimos 2-3 años (6+ GB RAM), Q4_K_M es la recomendación predeterminada. Es lo suficientemente pequeño para caber junto al SO y otras apps, lo suficientemente rápido para respuestas en tiempo real, y la pérdida de calidad es insignificante para tareas de clasificación y extracción.

Para Raspberry Pi u otros dispositivos edge con memoria limitada, Q4_0 ahorra 400 MB de RAM, lo cual puede ser la diferencia entre ejecutarse o no. La caída de calidad es aceptable para tareas de clasificación simple.

Para despliegue en navegador vía WebLLM, Q4_0 o Q4_K_M — el modelo necesita descargarse al navegador y caber en la memoria GPU (que se comparte con el resto del navegador). Más pequeño es mejor.

Patrones de Integración

React Native + Modelo Local

Usa llama.rn para integración con React Native. La librería envuelve llama.cpp y proporciona una API JavaScript:

1. Empaqueta el archivo GGUF con tu app (o descarga en el primer lanzamiento)
2. Inicializa el modelo al iniciar la app (toma 2-4 segundos en iPhone 15)
3. Ejecuta inferencia a través del puente JS
4. El modelo permanece cargado en memoria hasta que la app pasa a segundo plano

Latencia típica de clasificación: 80-150ms incluyendo overhead del puente. Para comparación, una llamada API toma 600-1,200ms como mínimo.

iOS Nativo con Core ML

Convierte tu GGUF a formato Core ML usando las herramientas de conversión de Google. Los modelos Core ML se ejecutan en el Apple Neural Engine, que es más rápido y eficiente energéticamente que la inferencia GPU:

• iPhone 15 Pro: 32-35 t/s en ANE vs 22-25 t/s en GPU
• Impacto en batería: ANE usa aproximadamente 40% menos energía que GPU para la misma carga de trabajo
• Memoria: Core ML gestiona la memoria del modelo más eficientemente que llama.cpp

La compensación: la conversión a Core ML es un paso extra, y pierdes algo de flexibilidad (sin cuantización dinámica, tamaño de lote fijo). Vale la pena para apps iOS en producción; no vale la pena para prototipado.

Android Nativo con NNAPI

En Android, usa el backend NNAPI de llama.cpp para inferencia acelerada por hardware en NPUs Qualcomm, MediaTek y Samsung:

• Pixel 8 Pro (Tensor G3): 22-25 t/s en NPU
• Samsung S24 (Snapdragon 8 Gen 3): 26-30 t/s en NPU
• Batería: la inferencia NPU usa 50-60% menos energía que CPU

El soporte de NNAPI varía por dispositivo. Siempre incluye una ruta de respaldo por CPU.

Navegador vía WebLLM

WebLLM ejecuta modelos GGUF en el navegador usando WebGPU:

• Chrome en M2 MacBook: 15-18 t/s
• Chrome en laptop gaming (RTX 4060): 20-25 t/s
• Chrome en iPhone 15 Pro: 8-10 t/s

El modelo se descarga una vez y se cachea en el almacenamiento del navegador (IndexedDB). Las cargas subsiguientes son casi instantáneas. Bueno para apps web que necesitan capacidad offline o privacidad de datos.

Raspberry Pi vía llama.cpp

Para despliegues IoT y edge, ejecuta llama.cpp directamente en el Pi:

• Raspberry Pi 5 (8 GB): Gemma 3 4B en Q4_K_M, 6-7 t/s
• Raspberry Pi 5 (4 GB): Gemma 3 4B en Q4_0, 5-6 t/s (ajustado)
• Raspberry Pi 4 (8 GB): Gemma 3 4B en Q4_0, 2-3 t/s (utilizable para procesamiento por lotes)

Para el Pi 4, considera el modelo Gemma 3 1B en su lugar — se ejecuta a 8-10 t/s en Q4_K_M y maneja clasificación simple de manera confiable.

Benchmarks de Rendimiento en Dispositivos Reales

Gemma 3 4B ajustado (Q4_K_M) en una tarea de clasificación de intención de 12 categorías (500 ejemplos de entrenamiento):

Nota que la precisión es idéntica en todos los dispositivos — la cuantización afecta a todas las plataformas por igual. La diferencia es puramente latencia/velocidad. Cada dispositivo entrega respuestas en menos de un segundo para clasificación, lo cual es lo suficientemente rápido para funciones de cara al usuario en tiempo real.

Para contexto, una llamada API de GPT-4o para la misma tarea de clasificación promedia 850ms con un P99 de 3,200ms. El modelo en dispositivo en un teléfono de $200 supera a la mejor API del mundo en latencia por 10x.

Casos de Uso Reales

Validación de Formularios Offline

Una app de servicio de campo usó Gemma 3 4B para validar y corregir notas de técnicos ingresadas en tablets en áreas sin cobertura celular. El modelo revisa ortografía, marca campos requeridos faltantes y clasifica el tipo de trabajo — todo offline. Ajustado con 300 ejemplos de notas de técnicos, desplegado en Q4_K_M en tablets Android. Precisión: 92%. Latencia: 120ms.

Clasificación de Intención en Dispositivo

Una app bancaria usa Gemma 3 4B para clasificar mensajes de clientes en intenciones antes de enrutarlos al servicio apropiado. Ejecutarse en dispositivo significa que el texto del mensaje nunca sale del teléfono — un requisito de cumplimiento en varias jurisdicciones. Ajustado con 400 ejemplos, desplegado vía Core ML en iOS. Precisión: 95%. Latencia: 55ms.

Análisis de Sensores IoT

Un sistema de monitoreo industrial ejecuta Gemma 3 4B en gateways Raspberry Pi 5 para clasificar lecturas de sensores como normal, advertencia o crítico. Cada gateway procesa datos de 12 sensores. Ajustado con 500 ejemplos de patrones de datos de sensores, desplegado en Q4_0. Precisión: 97% en la clasificación de tres categorías. Procesamiento: 4 lecturas/segundo por gateway.

Procesamiento de Texto con Privacidad

Una app de toma de notas de salud usa Gemma 3 4B para estructurar y categorizar notas clínicas en el iPad del proveedor. Ningún dato de paciente sale del dispositivo. Ajustado con 350 ejemplos desidentificados. El cumplimiento HIPAA se simplifica porque el procesamiento de IA ocurre completamente en el dispositivo — sin nube, sin API, sin BAA requerido para el paso de inferencia.

---

Lectura Adicional

• Edge AI e Inferencia Local en 2026 — El panorama del despliegue de IA en dispositivo, incluyendo hardware, frameworks y datos de rendimiento del mundo real.
• Agentes de IA Offline: Edge Fine-Tuned — Cómo construir agentes de IA que funcionen sin conectividad a internet usando modelos edge ajustados.
• Optimización de Adaptadores LoRA para Despliegue Edge — Optimizando adaptadores LoRA para huella mínima en dispositivos edge.