ARTEMIS vs Gemma 4 12B: en sele och en hjärna är inte samma köp

Googles ARTEMIS och Gemma 4 12B konkurrerar inte, och det snabbaste sättet att slösa bort en vecka är att sätta dem i en jämförelsetabell och välja en vinnare. ARTEMIS, som Google öppnade källkoden för i augusti 2026 under Apache 2.0, är ett automatiseringsramverk för Android: det tar en mening, styr en riktig telefon via ADB och rapporterar vad som hände. Gemma 4 12B, som släpptes av Google DeepMind den 3 juni 2026, är en tät multimodal modell med öppna vikter och 12 miljarder parametrar – en hjärna du kan köra på en laptop, inte ett system som kan trycka på en skärm. Den ena kan inte se, fatta beslut eller agera utan att den andra typen av sak är kopplad till den; den andra kan inte hålla i en enhet alls. Men jämförelsen är värd att göra, eftersom frågan under den är den som varje mobilteam just nu ställer: kan en liten öppen modell som du äger helt och hållet automatisera Android, eller behöver du en hostad frontier-modell bakom ett ramverk som ARTEMIS? Den frågan har ett riktigt svar, och det är inte det som någon av leverantörernas lanseringsinlägg antyder.

Först, kategorifelet, klart uttryckt.

ARTEMIS innehåller ingen modell. Dess egen bricka lyder ”Multi-Model — Gemini | Claude | GPT-4o | Qwen-VL”, och filen som avgör vilken du använder är code>config/artemis.jsonc/code>. Det är en kontrollslinga: en tillgänglighetsförst-lokaliserare, en säkerhetskontroll som rensar bort popup-fönster innan din tryckning landar, en sessionslogg som komprimerar gamla skärmbilder till visuella sammanfattningar, och två körningsprofiler — Flash på cirka 3–5 sekunder per steg, Pro på cirka 15–40 sekunder per steg med en Planner, en Operator och en skrivskyddad Checker. Allt den vet om världen kommer via en vision-språkmodell som den inte själv har skrivit.

Gemma 4 12B är ett objekt av motsatt slag. Det är en checkpoint. Den har ingen enhetsanslutning, ingen ADB, ingen tillgänglighetstjänst, ingen föreställning om att en tryckning är något som kan utföras. Ge den en skärmbild och fråga vad den ska göra härnäst, så svarar den — möjligen bra — men svarandet är hela omfattningen av dess handlingskraft. Allt mellan "modellen sa tryck på (540, 1180)" och "telefonen tryckte på (540, 1180)" är ARTEMIS uppgift, och det är det mesta av arbetet.

Så den ärliga inramningen av den här matchningen är inte ARTEMIS mot Gemma. Den är: vad ger en öppen 12B-modell dig som resonemangslager för en Android-agent, och när behöver du betala för något större?

Vad Gemma 4 12B faktiskt tillför

För en mellanstor modell är den ovanligt väl specificerad, och tre av dess egenskaper är viktiga för allt mobilt.

• Det är verkligen multimodalt i indatalagret.Text, bild, ljud och video går in; text kommer ut. Det är den första medelstora Gemma utan separata multimodala kodare, och den första i familjen som tar in ljud nativt — vilket inte är en UI-automatiseringsfunktion, utan en verklig sådan om dina testscenarier involverar röstmeddelanden, aviseringar som talar, eller tillgänglighetsvägar byggda på ljudsignaler.

• Det är en 12B du kan hålla. Artificial Analysis listar den med totalt 12B parametrar under Apache 2.0 — ingen intäktsgräns, ingen forskningsklausul, en licens som du kan bygga en produkt på utan att fråga någon — med ett 256K-kontextfönster, resonemang aktiverat och en uppmätt utdatahastighet på 109,2 tokens per sekund. Rapporter från communityn uppskattar vikterna till ungefär 13,4 GB vid SFP8 och cirka 6,7 GB vid Q4_0, vilket motsvarar en laptop med 16 GB minne.

• Den är billig, men inte det billigaste i sin klass. Artificial Analysis listar den till $0,10 per miljon indatatokens och $0,30 per miljon utdatatokens – och noterar i samma panel att detta är i det dyrare laget för en modell med öppna vikter av liknande storlek, där medianen ligger på $0,05 in och $0,15 ut. Cacheläsningar ligger nära $0,03.

Benchmarkbilden är den vanliga mellanstora röran och värd att redogöra för noggrant, eftersom siffrorna på trackerwebbplatserna inte stämmer överens med varandra. Artificial Analysis ger resonemangskonfigurationen ett Intelligence Index på 14 och placerar den på 21:a plats bland de 142 modellerna med öppna vikter i sin klass – vilket är en respektabel placering i mitten av tabellen och långt ifrån frontlinjen. Googles egen positionering är att 12B nästan matchar den större Gemma 4 26B-A4B och slår föregående generations Gemma 3 27B inom resonemang, vetenskap och dokumentuppgifter. Tredjepartsaggregatorer anger den till ungefär 72 % på LiveCodeBench v6 och 77,2 % på MMLU-Pro, där GPQA Diamond varierar mellan 66 % och 79 % beroende på vilken tracker och vilken konfiguration man läser. Det är respektabla siffror för en 12B. De är också ogranskade, självrapporterade aggregat, och när fyra webbplatser skiljer sig åt med tretton punkter bör du hålla dig till intervallet snarare än punktvärdet.

Vad ARTEMIS bidrar med, i ett stycke, eftersom det inte är ämnet här

ARTEMIS tillför allt som modellen inte kan: en dynamic-first-lokaliserare som använder tillgänglighetselementindex när de finns och faller tillbaka på vision och koordinater när de inte gör det, vilket innebär att ingen XPath behöver underhållas och inga ID:n blir inaktuella på en Compose- eller Flutter-yta. Den tillför ett Safety Net som fångar upp systempopupen som din tryckning var på väg att landa på, checkpoint-verifiering med fyra nivåer från code>off/code> till code>strict/code>, automatiska kraschstackar, keyframe-skärmbilder och diagnostikrapporter, en webbkonsol, ett Python-SDK för pytest och CI, och — anledningen till att det spreds så snabbt som det gjorde — en inbyggd MCP-server som exponerar hela alltet för Antigravity, Claude Code, Codex och alla andra MCP-kapabla assistenter som fem verktyg. Dess påstådda slutförandegrad på 99 %+ i Google Researchs AndroidWorld-benchmark placerar det på 99,1 % på den offentliga resultattavlan den 11 september 2026, mot 80 % för mänsklig prestation. Den siffran är självrapporterad och resultattavlan verifierar inte inlämningar, så behandla den som ett starkt leverantörspåstående snarare än en granskning.

Det enda stället där de två verkligen överlappar varandra

Det finns en verklig arkitektur där en liten Gemma utför hela jobbet, och den är värd att titta på eftersom den visar vad molnmodellen faktiskt betalar för. Ett ramverk för Android-agenter med öppen källkod som heter Orion körs helt på enheten: MediaProjection fångar skärmen, en kvantiserad Gemma-4-E4B-it som körs på Qualcomm Hexagon NPU via LiteRT-LM väljer nästa åtgärd, och Android Accessibility Service skickar tryckningarna. Inget moln-API, ingen faktura per token, och skärmen lämnar aldrig enheten. Den är validerad på en Galaxy S25 Ultra och är enligt sin egen beskrivning endast meningsfull på hårdvara med en Hexagon NPU – modellen behöver cirka 3 GB lagringsutrymme och ramverket riktar sig mot QNN HTP v79 på arm64.

Det är formen hos en Android-agent med liten modell som fungerar idag, och notera vad det kostar att komma dit. Modellen är kvantiserad och NPU-mappad. Handlingsutrymmet är pixlar, eftersom en modell som bara ser skärmbilder inte kan tolka "elementindex 12". Hela designen är en vertikal stack – modell, runtime, kisel, ramverk – vilket är anledningen till att det är ett ramverk och inte en direktersättare för din testsvit. Gemma 4 12B har ungefär tre gånger så många parametrar som E4B i den stacken och levereras inte i ett format som går att köra på en telefon; en 12B vid fyrabitars kvantisering är en arbetsstation eller en serverad endpoint, inte hemmahörande i en NPU.

Där var och en faktiskt vinner

• Kostnad i stor skala — en självhostad Gemma 4 12B har inget pris per token alls, jämfört med ett visionsanrop per steg för varje steg i en ARTEMIS-körning. I en regressionstestsvit med 500 tester som körs varje natt växer den skillnaden snabbare än något benchmarkgap.

• Integritet — Gemma 4 12B på din egen hårdvara skickar aldrig en skärmbild någonstans; ARTEMIS tillgänglighetshjälpmedel körs uttryckligen på enheten och skickar ingenting, men det modellanrop som det gör med varje skärmbild går till vilken leverantör du än har konfigurerat.

• Uppgiftstillförlitlighet i en riktig app — ARTEMIS, med stor marginal, eftersom det är ett testramverk med skyddsnät, kontrollpunktsverifiering och återställning. Inget i en bättre modell kan ersätta det.

• Ljud och långa dokument — Gemma 4 12B, med inbyggd ljudinmatning i det tekniska databladet och ett kontextfönster på 256K tokens. ARTEMIS har ingen åsikt om något av dem.

• Tid till första godkända testet — ARTEMIS, med en enorm marginal. Klona, code>./start.sh/code>, anslut en enhet med USB-felsökning, vänta på att den första uppgiften installerar tillgänglighetshjälpen. Att bygga motsvarande med enbart en checkpoint är ett projekt som tar flera månader, och Orion-exemplet ovan är hur det projektet ser ut när det är klart.

• Frihet att modifiera resonemangslagret — Gemma 4 12B, som är Apache 2.0-vikter du kan finjustera med din egen UI-vokabulär. ARTEMIS är Apache 2.0-kod, men resonemanget finns där din modell finns.

De versioner av den här kombinationen som faktiskt är tillgängliga idag

Var tydlig med vad du kan driftsätta den här veckan. ARTEMIS lista över testade backends är Gemini, Claude, GPT-4o och Qwen-VL — Gemma 4 12B finns inte med på den, och det finns ingen publicerad utvärdering av Gemma 4 12B som driver en ARTEMIS-session. Konfigurationsfilen tar en modellendpoint, så kombinationen är rimlig snarare än bevisad, och om du provar den gör du originalarbete i stället för att följa dokumentation. Värt att säga rakt ut: ARTEMIS färdplan har en post om "on-device lightweight VLMs", och modellen som fyller den kommer inte att vara en 12B.

Gemma 4 12B finns inte i vår katalog heller – vi routar de andra Gemma 4-storlekarna, Gemma 4 26B-A4B och Gemma 4 31B, och inte 12B, så om det är den checkpoint du vill ha får du den från leverantörens egen distribution och de vanliga tredjepartsvärdarna. Vad en routad katalog är till för är den andra halvan av det här problemet: om din plan är ARTEMIS på en hostad visionsmodell är den modellen en radpost som skalas med varje steg i varje körning, och den användbara hävstången är inte prislappen utan cachepriset. En Pro-körning läser om en växande kontext vid varje steg, så en modell med billig cacheläsning förändrar kalkylen mycket mer än en modell med billig ny indata. Det är också därför leverantörsfailover hör hemma i konfigurationen snarare än i din incidentlogg – en lång Android-session håller sin kontext på en endpoint, och en leverantörshicka vid steg 74 kostar dig körningen.

Vilket är ditt nästa drag

Om du har en mobilapp och en regressionssvit vill du ha ARTEMIS, och Gemma 4 12B är inte en ersättning för någon del av den – den är i bästa fall motorn du kan byta in senare, odokumenterat, på din egen tid. Om du bygger en produkt som måste köras på en handenhet utan nätverk och utan kostnad per anrop vill du ha en liten modell, och Gemma 4 12B är förmodligen för stor för den formfaktor du faktiskt har; titta på vad Orion gjorde med en Gemma i 4B-klass på en NPU innan du antar att en 12B kommer att få plats.

De två besluten krockar bara på ett enda ställe, och det är en fråga om kostnad snarare än om förmåga: hur många vision-anrop per dag är du villig att betala för? Svara ärligt på det – räkna dina tester, räkna dina steg, räkna dina nattkörningar – och valet mellan ett harness på en hostad modell och en egenhostad stack ger sig självt.

Vad en routad katalog är till för är den andra halvan av det här problemet: om din plan är ARTEMIS på en hostad visionsmodell är den modellen en utgiftspost som skalar med varje steg i varje körning