Gemma 3n E2B est la variante optimisée mobile de Google pour l'architecture Gemma 3. La désignation « E2B » fait référence au nombre effectif de paramètres — environ deux milliards de paramètres actifs par passe forward — à travers un choix architectural qui permet au modèle de charger uniquement un sous-ensemble de ses poids en RAM à tout moment donné. L'ensemble complet des poids est plus volumineux ; l'empreinte d'exécution reste compatible mobile.
Si vous avez développé sur Gemma 3 1B ou 4B et avez besoin de capacités plus larges sur du matériel de classe téléphone, la famille 3n est ce qu'il faut évaluer.
Pourquoi l'architecture 3n existe
Les modèles denses standards comme Gemma 3 1B ou 4B chargent l'ensemble complet des poids en RAM et utilisent tous les paramètres pour chaque passe forward. Cela fonctionne sur du matériel serveur et sur des ordinateurs portables performants ; cela fonctionne moins bien sur les téléphones, où la RAM est limitée et l'appareil entier est partagé avec d'autres applications.
La famille Gemma 3n résout ce problème avec un chargement sélectif de paramètres. Le modèle est structuré de sorte que différentes entrées activent différents sous-ensembles de paramètres, et le runtime peut évacuer les poids inactifs de la RAM sans perturber l'inférence. L'effet principal est qu'un modèle avec substantiellement plus de paramètres totaux que Gemma 3 4B peut s'exécuter dans un budget mémoire plus proche de ce que les modèles de classe 2B exigent.
Pour les développeurs qui déploient dans des produits mobiles et embarqués, c'est la partie de la famille Gemma qui répond aux contraintes réelles auxquelles ces produits font face.
La fenêtre de contexte de 8 192 tokens est plus courte que celle de la famille Gemma 3 standard. C'est un choix délibéré lié à l'architecture et à la cible de déploiement. L'inférence mobile à contexte long représente un problème thermique et mémoire ; plafonner la fenêtre maintient le déploiement gérable.
À quoi sert le modèle
Trois patterns de charge de travail dominent les déploiements Gemma 3n.
Assistants on-device nécessitant des capacités plus larges que ce que Gemma 3 1B peut fournir. Génération de texte conversationnel, résumé de contenu de longueur modérée, tâches de raisonnement basique — tous bénéficient du modèle sous-jacent plus large tout en restant dans les budgets mémoire mobiles.
Fonctionnalités multimodales on-device. La famille Gemma 3n supporte l'entrée vision, ce qui ouvre des workflows de compréhension d'image qui s'exécutent entièrement localement. Lecture de captures d'écran, description de scène pour fonctionnalités d'accessibilité, tâches basiques adjacentes à l'OCR — tout fonctionne sans aller-retour cloud.
Charges de travail sensibles à la confidentialité où les données ne doivent pas quitter l'appareil. Le même cas d'usage que Gemma 3 1B mais avec plus de marge de capacité. Les applications adjacentes à la santé et au juridique bénéficient lorsque le modèle on-device peut réellement traiter la question de l'utilisateur plutôt que simplement la classifier.
Où il échoue
Profondeur de raisonnement au-delà d'un certain point. E2B est plus capable que Gemma 3 1B, mais le cadre de paramètres effectifs a ses limites. Pour du raisonnement vraiment difficile, les frères et sœurs Gemma 3 plus grands sur du matériel plus performant sont les bonnes destinations.
Contexte long. La fenêtre de 8 192 tokens est courte selon les standards actuels. Les charges de travail nécessitant de traiter des documents plus longs ont besoin soit de stratégies de chunking, de patterns augmentés par récupération, soit d'un modèle différent.
Débit prévisible. L'architecture à chargement sélectif signifie que la latence d'inférence varie davantage entre différentes entrées que sur un modèle dense standard. Pour les charges de travail où la latence constante compte — par exemple, interactions d'interface utilisateur en temps réel — la variabilité mérite une attention benchmark avant engagement.
Cohérence cross-plateforme. L'histoire du déploiement on-device repose sur le support runtime du pattern de chargement sélectif. Un support mature existe dans le propre MediaPipe de Google et dans certains runtimes open-source ; la couverture à travers l'écosystème mobile et embarqué complet est moins complète que pour les modèles denses standards. Vérifiez le support sur vos plateformes cibles tôt.
Histoire matérielle
L'écosystème de déploiement autour de la famille 3n est plus jeune que l'histoire Gemma 3 standard et l'outillage mûrit encore.
MediaPipe est le chemin de déploiement le plus mature. Le propre framework de Google supporte l'architecture de chargement sélectif proprement, avec des performances raisonnables sur les appareils Android modernes et des performances acceptables sur iOS à travers les configurations runtime supportées.
Le support llama.cpp pour la famille 3n existe mais est moins mature que pour les variantes Gemma 3 standards. Les quantisations GGUF sont disponibles et fonctionnent, mais l'optimisation de chargement sélectif n'est pas complètement exposée à travers chaque runtime. Pour les déploiements nécessitant spécifiquement llama.cpp, benchmarkez sur du matériel cible réel plutôt que d'assumer que les bénéfices architecturaux se traduisent.
Le support ONNX Runtime est similaire. Fonctionnel, avec les bénéfices de chargement sélectif partiellement réalisés selon la configuration runtime spécifique.
Pour le déploiement on-device à plus haute performance, MediaPipe sur Android avec le runtime Gemma 3n officiel est le chemin de moindre résistance. Pour d'autres cibles de déploiement, attendez-vous à du travail d'intégration et benchmarkez soigneusement.
Face à la concurrence
Le tier 2B-effectif on-device est où la famille Gemma 3n se taille sa position. La concurrence inclut la famille Phi-3 de Microsoft à des échelles effectives comparables, les modèles on-device d'Apple pour des déploiements spécifiques iOS, et les variantes plus petites Qwen et Llama.
La position distinctive de Gemma 3n est l'architecture de chargement sélectif elle-même. Pour les charges de travail nécessitant plus de capacité qu'un modèle dense de classe 2B ne fournit mais qui doivent tenir dans un budget mémoire mobile, la famille 3n est l'une des réponses les plus nettes dans l'espace open-weight.
Le compromis est la maturité de l'outillage de déploiement. Les modèles denses ont un support plus large à travers l'écosystème ; le pattern de chargement sélectif se consolide encore. Pour les équipes qui peuvent cibler la stack de déploiement de Google, ce compromis est acceptable. Pour les équipes nécessitant une portabilité runtime maximale, la famille Gemma 3 standard à 1B ou 4B est le choix plus sûr.
Pour un contexte plus large, voir Gemma 3 1B et Gemma 3 4B.
Notes de déploiement
L'auto-hébergement et le déploiement on-device sont les seuls patterns de déploiement significatifs pour la famille 3n. L'inférence cloud managée sur E2B n'a pas de sens étant donné que l'argument de vente de l'architecture est l'histoire de déploiement mobile.
La quantisation fonctionne au tier 3n mais l'interaction entre quantisation et chargement sélectif est plus complexe que pour les modèles denses standards. Benchmarkez la combinaison quantisation-runtime spécifique sur du matériel cible ; ne supposez pas que ce qui fonctionne pour Gemma 3 4B se traduit directement.
L'impact batterie en utilisation continue est la contrainte du monde réel. L'architecture de chargement sélectif est plus économe en énergie par token que l'exécution naïve d'un modèle dense de taille similaire ne le serait, mais l'inférence LLM on-device à cette échelle représente encore une consommation d'énergie significative. Concevez des patterns d'interaction qui respectent les budgets batterie.
Pour des orientations plus larges sur le pipeline on-device, voir /usecases/local.
Le choisir
Optez pour Gemma 3n E2B lorsque vous avez besoin de :
- Plus de capacité que Gemma 3 1B sur du matériel mobile.
- Fonctionnalités multimodales on-device avec entrée vision.
- Déploiement via la stack runtime basée MediaPipe de Google.
Passez à Gemma 3 4B lorsque le matériel cible supporte le modèle dense plus grand et que la portabilité runtime compte. Passez à la variante 3n E4B plus grande lorsque plus de capacité est nécessaire et que le budget mémoire le permet.
Dernière revue technique : 2026-05-22 — Tokonomix.ai
