Gemma 3n E2B es la variante optimizada para móvil de Google de la arquitectura Gemma 3. La designación "E2B" hace referencia al recuento efectivo de parámetros —alrededor de dos mil millones de parámetros activos por paso hacia adelante— a través de una elección arquitectónica que permite al modelo cargar solo un subconjunto de sus pesos en RAM en un momento dado. El conjunto completo de pesos es más grande; la huella de tiempo de ejecución es amigable para móvil.
Si ha construido sobre Gemma 3 1B o 4B y necesita algo con mayor capacidad en hardware de clase teléfono, la familia 3n es lo que evaluar.
Por qué existe la arquitectura 3n
Los modelos densos estándar como Gemma 3 1B o 4B cargan el conjunto completo de pesos en RAM y usan todos los parámetros para cada paso hacia adelante. Eso funciona en hardware de servidor y en portátiles capaces; no funciona tan bien en teléfonos, donde la RAM está limitada y todo el dispositivo se comparte con otras aplicaciones.
La familia Gemma 3n aborda esto con la carga selectiva de parámetros. El modelo está estructurado de forma que diferentes entradas activan diferentes subconjuntos de parámetros, y el runtime puede intercambiar los pesos inactivos fuera de RAM sin interrumpir la inferencia. El efecto principal es que un modelo con sustancialmente más parámetros totales que Gemma 3 4B puede correr dentro de un presupuesto de memoria más cercano a lo que demandan los modelos de clase 2B.
Para los desarrolladores que distribuyen en productos móviles y embebidos, esta es la parte de la familia Gemma que aborda el conjunto de restricciones que esos productos realmente enfrentan.
La ventana de contexto de 8 192 tokens es más corta que la familia Gemma 3 estándar. Es una elección deliberada vinculada a la arquitectura y el objetivo de despliegue. La inferencia móvil con contexto largo es un problema térmico y de memoria; limitar la ventana mantiene la historia de despliegue manejable.
Para qué sirve el modelo
Tres patrones de carga de trabajo dominan los despliegues de Gemma 3n.
Asistentes en dispositivo que necesitan mayor capacidad de la que puede proporcionar Gemma 3 1B. La generación de texto conversacional, el resumen de contenido de longitud moderada y las tareas básicas de razonamiento se benefician del modelo subyacente más grande permaneciendo dentro de los presupuestos de memoria móvil.
Características multimodales en dispositivo. La familia Gemma 3n soporta entrada de visión, lo que abre flujos de trabajo de comprensión de imágenes que corren completamente de forma local. Lectura de capturas de pantalla, descripción de escenas para características de accesibilidad, tareas básicas adyacentes al OCR: todo funciona sin un ida y vuelta a la nube.
Cargas de trabajo sensibles a la privacidad donde los datos no deben salir del dispositivo. El mismo caso de uso que Gemma 3 1B pero con más capacidad. Las aplicaciones de salud y las adyacentes al sector legal se benefician cuando el modelo en dispositivo puede realmente abordar la pregunta del usuario en lugar de simplemente clasificarla.
Dónde falla
Profundidad de razonamiento pasado cierto punto. E2B es más capaz que Gemma 3 1B, pero el encuadre de parámetros efectivos tiene sus límites. Para razonamiento genuinamente difícil, los hermanos Gemma 3 más grandes en hardware más capaz son los destinos correctos.
Contexto largo. La ventana de 8 192 tokens es corta según los estándares actuales. Las cargas de trabajo que necesitan procesar documentos más largos necesitan estrategias de división en fragmentos, patrones de recuperación aumentada o un modelo completamente diferente.
Rendimiento predecible. La arquitectura de carga selectiva significa que la latencia de inferencia varía más entre diferentes entradas que en un modelo denso estándar. Para cargas de trabajo donde la latencia consistente importa —por ejemplo, interacciones de UI en tiempo real— la variabilidad merece atención de benchmarking antes de comprometerse.
Consistencia multiplataforma. La historia de despliegue en dispositivo depende del soporte del runtime para el patrón de carga selectiva. El soporte maduro existe en el propio MediaPipe de Google y en algunos runtimes de código abierto; la cobertura en todo el ecosistema móvil y embebido es menos completa que para los modelos densos estándar. Verifique el soporte en sus plataformas objetivo pronto.
La historia del hardware
El ecosistema de despliegue alrededor de la familia 3n es más joven que la historia estándar de Gemma 3 y las herramientas siguen madurando.
MediaPipe es la ruta de despliegue más madura. El propio framework de Google soporta la arquitectura de carga selectiva con limpieza, con un rendimiento razonable en dispositivos Android modernos y un rendimiento aceptable en iOS a través de las configuraciones de runtime soportadas.
El soporte de llama.cpp para la familia 3n existe pero es menos maduro que para las variantes Gemma 3 estándar. Las cuantizaciones GGUF están disponibles y funcionan, pero la optimización de carga selectiva no está completamente expuesta a través de todos los runtimes. Para los despliegues que necesitan llama.cpp específicamente, haga benchmarking en el hardware objetivo real en lugar de asumir que los beneficios arquitectónicos se trasladan.
El soporte de ONNX Runtime es similar. Funcional, con los beneficios de carga selectiva parcialmente realizados según la configuración específica del runtime.
Para el despliegue en dispositivo de mayor rendimiento, MediaPipe en Android con el runtime oficial de Gemma 3n es el camino de menor resistencia. Para otros objetivos de despliegue, espere algo de trabajo de integración y haga benchmarking cuidadosamente.
Frente al campo
El tier de 2B efectivo en dispositivo es donde la familia Gemma 3n define su posición. La competencia incluye la familia Phi-3 de Microsoft a escalas efectivas comparables, los modelos en dispositivo de Apple para despliegues específicos de iOS y las variantes más pequeñas de Qwen y Llama.
La posición distintiva de Gemma 3n es la propia arquitectura de carga selectiva. Para cargas de trabajo que necesitan más capacidad de la que proporciona un modelo denso de clase 2B pero que deben encajar en un presupuesto de memoria móvil, la familia 3n es una de las respuestas más limpias en el espacio de peso abierto.
La compensación es la madurez de las herramientas de despliegue. Los modelos densos tienen un soporte más amplio en todo el ecosistema; el patrón de carga selectiva sigue consolidándose. Para equipos que pueden apuntar al stack de despliegue de Google, esa compensación es aceptable. Para equipos que necesitan la máxima portabilidad del runtime, la familia Gemma 3 estándar en 1B o 4B es la opción más segura.
Para más contexto, consulte Gemma 3 1B y Gemma 3 4B.
Notas de despliegue
El auto-alojamiento y el despliegue en dispositivo son los únicos patrones de despliegue significativos para la familia 3n. La inferencia gestionada en la nube en E2B no tiene sentido dado que el punto de venta de la arquitectura es la historia de despliegue móvil.
La cuantización funciona en el tier 3n pero la interacción entre la cuantización y la carga selectiva es más compleja que para los modelos densos estándar. Haga benchmarking de la combinación específica cuantización-runtime en el hardware objetivo; no asuma que lo que funciona para Gemma 3 4B se traslada directamente.
El impacto en la batería en el uso continuo es la restricción del mundo real. La arquitectura de carga selectiva es más eficiente energéticamente por token de lo que sería ejecutar naïvemente un modelo de tamaño similar denso, pero la inferencia LLM en dispositivo a esta escala sigue siendo un consumo de energía significativo. Diseñe patrones de interacción que respeten los presupuestos de batería.
Para orientación más amplia sobre pipelines en dispositivo, consulte /usecases/local.
Cuándo elegirlo
Use Gemma 3n E2B cuando necesite:
- Más capacidad que Gemma 3 1B en hardware móvil.
- Características multimodales en dispositivo con entrada de visión.
- Despliegue a través del stack de runtime basado en MediaPipe de Google.
Migre a Gemma 3 4B cuando el hardware objetivo soporte el modelo denso más grande y la portabilidad del runtime importe. Migre a la variante 3n E4B más grande cuando se necesite más capacidad y el presupuesto de memoria lo permita.
Última revisión técnica: 2026-05-22 — Tokonomix.ai
