
Gemma 3n E2B is Google's voor mobiel geoptimaliseerde variant van de Gemma 3-architectuur. De "E2B"-aanduiding verwijst naar het effectieve aantal parameters — ongeveer twee miljard actieve parameters per forward pass — door middel van een architectuurkeuze die het model in staat stelt om slechts een subset van zijn gewichten in het RAM te laden op elk gegeven moment. De volledige gewichtenset is groter; de runtime footprint is mobiel-vriendelijk.
Als je hebt gebouwd op Gemma 3 1B of 4B en iets nodig hebt met bredere capaciteit op telefoon-klasse hardware, dan is de 3n-familie wat je moet evalueren.
Waarom de 3n-architectuur bestaat
Standaard dense modellen zoals Gemma 3 1B of 4B laden de volledige gewichtenset in het RAM en gebruiken alle parameters voor elke forward pass. Dat werkt op serverhardware en op capabele laptops; het werkt niet zo goed op telefoons, waar RAM beperkt is en het hele apparaat wordt gedeeld met andere apps.
De Gemma 3n-familie pakt dit aan met selectief laden van parameters. Het model is zo gestructureerd dat verschillende inputs verschillende parametersubsets activeren, en de runtime kan inactieve gewichten uit het RAM wisselen zonder de inferentie te verstoren. Het belangrijkste effect is dat een model met substantieel meer totale parameters dan Gemma 3 4B kan draaien binnen een geheugenbudget dat dichter bij wat 2B-klasse modellen vereisen ligt.
Voor ontwikkelaars die naar mobiele en embedded producten shippen, is dit het deel van de Gemma-familie dat de beperkingen aanpakt waarmee die producten daadwerkelijk worden geconfronteerd.
Het contextvenster van 8.192 tokens is korter dan de standaard Gemma 3-familie. Dat is een bewuste keuze gekoppeld aan de architectuur en het deployment-doelwit. Mobiele inferentie bij lange context is een thermisch en geheugenprobleem; het begrenzen van het venster houdt het deployment-verhaal hanteerbaar.
Waarvoor het model bedoeld is
Drie workload-patronen domineren Gemma 3n-deployments.
On-device assistenten die bredere capaciteit nodig hebben dan Gemma 3 1B kan bieden. Conversationele tekstgeneratie, samenvatting van content van gemiddelde lengte, basale redeneertaken — allemaal profiteren ze van het grotere onderliggende model terwijl ze binnen mobiele geheugenbudgetten blijven.
Multimodale on-device functies. De Gemma 3n-familie ondersteunt vision-input, wat image-understanding workflows opent die volledig lokaal draaien. Screenshot-lezen, scènebeschrijving voor toegankelijkheidsfuncties, basale OCR-aanverwante taken — allemaal werken ze zonder een cloud-roundtrip.
Privacy-gevoelige workloads waarbij data het apparaat niet mag verlaten. Dezelfde use case als Gemma 3 1B maar met meer capaciteitsruimte. Healthcare- en juridisch-aanverwante apps profiteren wanneer het on-device model daadwerkelijk kan omgaan met de vraag van de gebruiker in plaats van deze alleen te classificeren.
Waar het tekortschiet
Redeneerdepte voorbij een bepaald punt. E2B is capabeler dan Gemma 3 1B, maar het effectieve-parameter-framing heeft zijn grenzen. Voor echt moeilijk redeneren zijn de grotere Gemma 3-siblings op capabelere hardware de juiste bestemmingen.
Lange context. Het 8.192-token venster is kort volgens huidige standaarden. Workloads die langere documenten moeten verwerken hebben ofwel chunking-strategieën, retrieval-augmented patronen, of een geheel ander model nodig.
Voorspelbare doorvoer. De selectieve-laad-architectuur betekent dat inferentielatentie meer varieert over verschillende inputs dan bij een standaard dense model. Voor workloads waar consistente latentie belangrijk is — bijvoorbeeld real-time UI-interacties — verdient de variabiliteit benchmarkattentie voordat je je committeert.
Cross-platform consistentie. Het on-device deployment-verhaal is afhankelijk van runtime-ondersteuning voor het selectieve-laad-patroon. Volwassen ondersteuning bestaat in Google's eigen MediaPipe en in sommige open-source runtimes; dekking over het volledige mobiele en embedded ecosysteem is minder compleet dan voor standaard dense modellen. Verifieer ondersteuning op je doelplatforms vroeg in het proces.
Hardware-verhaal
Het deployment-ecosysteem rond de 3n-familie is jonger dan het standaard Gemma 3-verhaal en de tooling is nog steeds aan het rijpen.
MediaPipe is het meest volwassen deployment-pad. Google's eigen framework ondersteunt de selectieve-laad-architectuur netjes, met redelijke prestaties op moderne Android-apparaten en acceptabele prestaties op iOS via de ondersteunde runtime-configuraties.
llama.cpp-ondersteuning voor de 3n-familie bestaat maar is minder volwassen dan voor standaard Gemma 3-varianten. GGUF-kwantisaties zijn beschikbaar en draaien, maar de selectieve-laad-optimalisatie wordt niet volledig blootgelegd door elke runtime. Voor deployments die specifiek llama.cpp nodig hebben, benchmark op daadwerkelijke doelhardware in plaats van aan te nemen dat de architecturale voordelen zich vertalen.
ONNX Runtime-ondersteuning is vergelijkbaar. Functioneel, met de selectieve-laad-voordelen gedeeltelijk gerealiseerd afhankelijk van de specifieke runtime-configuratie.
Voor de hoogst-performante on-device deployment is MediaPipe op Android met de officiële Gemma 3n runtime het pad van de minste weerstand. Voor andere deployment-doelen verwacht enig integratiewerk en benchmark zorgvuldig.
Ten opzichte van het veld
De on-device 2B-effectieve tier is waar de Gemma 3n-familie zijn positie uitsnijdt. De concurrentie omvat Microsoft's Phi-3-familie op vergelijkbare effectieve schalen, Apple's on-device modellen voor iOS-specifieke deployments, en de kleinere Qwen- en Llama-varianten.
Gemma 3n's onderscheidende positie is de selectieve-laad-architectuur zelf. Voor workloads die meer capaciteit nodig hebben dan een 2B-klasse dense model biedt maar die binnen een mobiel geheugenbudget moeten passen, is de 3n-familie een van de schoonste antwoorden in de open-weight ruimte.
De afweging is de volwassenheid van de deployment-tooling. Dense modellen hebben bredere ondersteuning door het ecosysteem heen; het selectieve-laad-patroon consolideert nog steeds. Voor teams die Google's deployment-stack kunnen targeten, is die afweging acceptabel. Voor teams die maximale runtime-portabiliteit nodig hebben, is de standaard Gemma 3-familie op 1B of 4B de veiligere keuze.
Voor bredere context zie Gemma 3 1B en Gemma 3 4B.
Deployment-opmerkingen
Self-hosting en on-device deployment zijn de enige betekenisvolle deployment-patronen voor de 3n-familie. Cloud-managed inferentie op E2B heeft geen zin gegeven dat het verkoopargument van de architectuur het mobiele-deployment-verhaal is.
Kwantisatie werkt op de 3n-tier maar de interactie tussen kwantisatie en selectief laden is complexer dan voor standaard dense modellen. Benchmark de specifieke kwantisatie-runtime-combinatie op doelhardware; neem niet aan dat wat werkt voor Gemma 3 4B zich direct vertaalt.
Batterij-impact bij continu gebruik is de real-world beperking. De selectieve-laad-architectuur is energie-efficiënter per token dan naïef een vergelijkbaar-groot dense model draaien zou zijn, maar on-device LLM-inferentie op deze schaal is nog steeds aanzienlijk stroomverbruik. Ontwerp interactiepatronen die batterijbudgetten respecteren.
Voor bredere on-device pipeline-guidance zie /usecases/local.
Het kiezen
Grijp naar Gemma 3n E2B wanneer je nodig hebt:
- Meer capaciteit dan Gemma 3 1B op mobiele hardware.
- Multimodale on-device functies met vision-input.
- Deployment via Google's op MediaPipe gebaseerde runtime-stack.
Ga naar Gemma 3 4B wanneer doelhardware het grotere dense model ondersteunt en runtime-portabiliteit belangrijk is. Ga naar de grotere 3n E4B-variant wanneer meer capaciteit nodig is en het geheugenbudget het toelaat.
Laatste technische review: 2026-05-22 — Tokonomix.ai
