Hur långt räcker 16 GB VRAM? Gemma 4 12B på ett RTX 5060 Ti

Jag köpte ett GeForce RTX 5060 Ti med 16 GB främst för att provköra AI lokalt. Frågan var enkel: hur mycket av min familjeassistent Freya kan jag flytta från GPT-5.5 till en lokal LLM via Ollama?

Det vore lätt att formulera testet som lokal AI mot cloud LLM. Det blir också ganska missvisande. En 12B-modell på ett konsumentkort kommer inte att matcha en frontier-modell som körs i ett datacenter. Så det intressanta är att hitta var gränsen går. Vilka uppgifter kan utföras med local AI, vad krävs för att de ska bli pålitliga och när behöver jag fortfarande skicka arbetet vidare till cloud LLM?

Efter att ha kört Gemma 4 12B genom benchmarks, svenska tool calls, OpenClaw och ett familjetest är svaret lite tydligare. 16 GB räcker till mer än en chatbot, men modellen är bara en del av systemet.

Utgångsläget: GPT-5.5 med en liten lokal fallback

I dagsläget delar två agenter på maskinens resurser. Det är ingen modern dator, utan en Intel i7 med 32 GB RAM och ett RTX 5060 Ti med 16 GB VRAM. Freya är familjens Telegram-bot och körs i OpenClaw. Muninn är ett experiment byggt med Hermes Agent för framtida uppgifter.

När testet började använde båda GPT-5.5 som primär modell. Den lokala fallback-lösningen var qwen3:4b, en modell som använder omkring 2,5 GB VRAM och genererar ungefär 98 tokens per sekund när den är varm. Den klarar native tool calling, men den är för liten för att bära hela Freyas personlighet, långa instruktioner och vardagliga uppgifter med bra marginal.

Det nya kortet gjorde det möjligt för mig att testa Gemma 4 12B. Gemma 4 kräver också en nyare runtime, Ollama 0.30.5 eller senare, så det första steget blev att uppgradera Ollama. Jag valde Ollamas Q4_K_M-version, som är 7,6 GB på disk och har stöd för 256K context enligt Ollamas modellkatalog. Google beskriver 12B-versionen som en modell för desktopdatorer och mindre servrar, med reasoning, function calling och multimodal input i översikten för Gemma 4.

För mig fanns ett krav som vägde tyngre än den allmänna kvaliteten på den dagliga chatten: modellen behövde kunna välja rätt verktyg även på svenska. Om den inte kan tända en Trådfri-lampa, läsa busstidtabellen eller välja rätt Sonos-system spelar det ingen roll hur trevligt den formulerar svaret.

Vad som faktiskt ryms på 16 GB

Första testet var positivt. Gemma 4 12B Q4_K_M kördes helt på grafikkortet och använde ungefär 8,1 till 8,5 GB VRAM beroende på hur Ollama rapporterade körningen. Det lämnade plats för desktopmiljön, embeddingmodellen och annan lokal AI utan CPU-offload.

Gemma är mer än dubbelt så långsam som qwen3:4b i ren generering, men 42 till 43 tokens per sekund känns fortfarande snabbt i en vanlig chatt. Det viktiga var att modellen fick plats med användbar context.

Det här blev också den första större utmaningen. Den gamla fallbacken körde med 4K context och kapade prompts på omkring 28 000 tokens utan att det syntes i chatten. Senare upptäckte jag samma typ av problem i OpenClaw, där Gemma i praktiken bara fick omkring 2 000 tokens trots att agentens prompt var mycket större. Modellen verkade då tappa instruktioner, verktyg och resultat, men grundorsaken var att systemet hade klippt bort dem.

Lösningen blev att sätta den verkliga gränsen explicit på båda sidor: contextTokens=65536 i OpenClaw och num_ctx=65536 i Ollama. Med 65 536 tokens låg modellen fortfarande runt 8,1 GB VRAM på den här setupen. Den stora contextkapaciteten var alltså inte problemet, men det var ett problem att låta runtime gissa detta värde.

De första svenska verktygstesterna såg nästan för bra ut

I det första testet fick Gemma fyra svenska frågor med Freya-liknande verktyg. Den valde rätt verktyg och rätt argument för tre actions, och svarade korrekt utan tool call på en faktafråga där inget verktyg passade. Resultatet blev 4 av 4.

Ett större isolerat test med Freyas riktiga instruktioner och nio verktyg gav 7 av 7. Modellen tände rätt lampa, valde rätt radiokanal, frågade efter avgångar från rätt hållplats och avstod när frågan inte krävde ett verktyg.

Det var tillräckligt för att bevisa att Gemma 4 12B kan göra native tool calling på svenska. Det bevisade dock inte att den kunde driva en riktig agent med dagliga uppgifter.

Muninn gjorde den skillnaden tydlig. Med 16 blandade MCP-verktyg tappade modellen bort filsystemverktygen som faktiskt fanns i prompten och gav upp. När jag minskade till tio fokuserade filsystemverktyg löste den samma uppgift med två korrekta tool calls.

Min första slutsats var att små modeller fungerar bättre med färre verktyg. Det är dock bara delvis sant. Freya visade att problemet är mer exakt än så. Ett mindre antal tydliga verktyg fungerar bättre än många överlappande verktyg med liknande schema. Det är tool ambiguity och storleken på context runt beslutet som kostar, inte bara antalet knappar modellen kan trycka på.

Muninn visade senare även en andra gräns, och den har inget med tool ambiguity att göra. Jag gav Gemma ett veckodigest-jobb: läs ett antal kända filer och sammanfatta veckan, en öppen uppgift i flera steg istället för en enskild action. Modellen loopade genom nio generiska planeringsanrop utan att läsa en enda fil och levererade ett förvirrat svar som frågade vad vi hade jobbat med tidigare. Verktygen var tydliga och fanns på plats, men uppgiften krävde att hålla en plan över många steg. Det jobbet körs nu som ett vanligt script som frågar en cloud LLM istället, så att digesten grundas i de faktiska filerna.

Ett godkänt tool call kan fortfarande ge ett farligt svar

När Gemma först fick köra på Freyas fulla produktionsyta gjorde den ett korrekt shell-anrop, läste resultatet och fortsatte sedan med helt orelaterade webbsökningar. Jag bytte då tillbaka till GPT-5.5 direkt för att få tid att fundera.

Det visade sig vara den tysta contextkapningen på omkring 2 000 tokens som låg bakom detta resultat. Efter att jag satt 65 536 explicit klarade modellen samma fortsättning korrekt. Men nästa fel var definitivt mer intressant.

Ett script för busstidtabellen saknade sina miljövariabler och returnerade ett tydligt fel. Gemma svarade ändå med trovärdiga avgångstider som inte kom från verktyget. Mer promptning räckte inte som säkerhetsmodell här.

Jag ersatte därför generell shellåtkomst med freya_ops, ett smalt verktyg för ett bestämt antal hushållsactions. Det accepterar bara validerade lampor, Sonos-spelare, hållplatser och habit-loggar. Resultatet är strukturerat som lyckat eller misslyckat, och ett fel stoppar körningen innan modellen får en ny chans att skriva en plausibel fortsättning. Ett live-test med ett ogiltigt enhetsnamn bekräftade beteendet: ett misslyckat tool call och ingen fortsättning från modellen.

Samma princip används nu för reminders. Gemma förstår en naturlig svensk begäran och väljer texten som ska skickas, men deterministisk kod äger tidszon, lagring, deduplicering och leverans. I ett test skapades timern korrekt och kördes vid rätt tid, men Telegram fick aldrig meddelandet. Systemet hade verifierat jobbet och modellsvaret, men inte att människan faktiskt tog emot resultatet.

Det ändrade min definition av en lyckad action: det räcker inte att agenten säger att något är klart. Det räcker inte ens att jobbet finns i databasen. Resultatet behöver verifieras där användaren faktiskt tar emot det.

Färre behörigheter behöver inte betyda en sämre assistent

Jag provade först att ge Gemma en bredare verktygsyta för att Freya skulle kännas mer som den GPT-drivna motsvarigheten. Det gav henne fler sätt att förvandla ett rimligt antagande till ett verkligt operativt fel.

Den nuvarande uppdelningen är smalare men mer användbar:

Gemma har inte exec, fri filskrivning eller generell cronåtkomst. Den kan däremot läsa godkänd privat kunskap, spara en avgränsad minnespost, sköta hushållsactions och skapa reminders genom kontrakt som går att verifiera.

Det är en viktig skillnad mot en vanlig fallback. OpenClaw byter modell när en provider ger ett fel eller en timeout, inte när den lokala modellen möter en uppgift som är för svår eller saknar ett verktyg. Svåra uppgifter behöver därför delegeras explicit till cloud modellen, idag GPT-5.6 efter en uppgradering från GPT-5.5 under testets gång. Jag kan inte bara lägga cloud LLM först i en fallbacklista och anta att det automatiskt tar över när Gemma blir osäker.

Hur känns det i vardagen?

För vanlig svensk chatt är kvaliteten bra. Tonen är varm och naturlig, med enstaka böjningsfel som köken istället för kök. Det känns inte som maskinöversatt svenska, även om tonen ibland kan vara lite stel.

Delay varierar kraftigt beroende på hur mycket arbete jag ber modellen att utföra. En första körning med full prompt hamnar ofta runt 10 till 15 sekunder. En varm följdfråga i samma konversation som skulle minnas ordet blåbär tog 946 millisekunder. När jag ställde in modellen på high thinking med ett komplext reminder-schema kunde en korrekt action ta flera minuter.

Det är därför thinking inte bara är en kvalitetsinställning. I det första benchmarktestet använde modellen hela sin korta outputbudget till dold reasoning och lämnade ett tomt synligt svar. Med thinking avstängt svarade den snabbt, men klarade inte automatiskt svårare tool calls bättre. Mer thinking hjälpte ibland, ibland inte, och kostade mycket latency. Just nu kör familjetestet med thinking satt till high, där jag accepterar den extra latencyn i utbyte mot bättre odds på de svårare tool calls.

Freya kör nu Gemma som primär modell i ett familjetest, med GPT-5.6 som första fallback för providerfel och som ett explicit val för svårare arbete. Det är inte samma sak som att Gemma har ersatt cloud LLM. Det betyder att rutinmässiga och privata delar kan hanteras av en lokal modell från början.

Samma kort kan också köra röst och spel

RTX 5060 Ti-kortet används inte bara av språkmodellen. På samma maskin kör jag Whisper large-v3 för lokal speech-to-text och Kokoro för engelsk text-to-speech. Den första kompletta voice-agenten tog 15 till 25 sekunder innan den kunde börja svara. Problemet var inte Gemmas maximala context, utan en generell agentprompt på omkring 18 000 tokens, nio verktyg, thinking och ett flöde som väntade på hela svaret innan talsyntesen kunde köras.

En separat, smal voice-väg med kort prompt, thinking avstängt och streamad text nådde sin första output efter 1,64 sekunder i mina tester. Det arbetet kommer att bli en egen artikel, men resultatet förstärker samma lärdom: det lokala systemets hårdvara betyder lika mycket som modellens storlek.

Kortet sitter också i en maskin som används för spel. Om OLLAMA_KEEP_ALIVE=-1 är aktivt ligger omkring 8 GB VRAM låst så länge modellen är laddad. Under testperioden var det användbart för snabba följdfrågor. Till vardags är en timeout på exempelvis tio minuter rimligare, så att VRAM frigörs när modellen varit inaktiv.

Jag fick även bekräftat hur viktigt det är att kontrollera GPU:n efter en omstart. Ollama såg frisk ut och svarade på API-anrop, men hade startat helt på CPU efter en race condition i Distrobox. Hastigheten föll från omkring 38 till 3 tokens per sekund trots att grafikkortets minne stod tomt. En health check som bara frågar om API:t svarar säger alltså inte att AI-systemet använder rätt systemresurser.

Vad 16 GB faktiskt köpte mig

RTX 5060 Ti blev inte ett litet datacenter. Gemma 4 12B slår inte GPT-5.5 på svår reasoning, breda tool calls eller dagligt underhåll. Att ge modellen fler behörigheter ändrar inte heller slutresultatet.

Men kortet driver en 12B-modell helt på GPU med 65 536 tokens context, svensk tool calling och plats kvar för resten av min lokala stack. Det ger Freya en bas som är privat, alltid tillgänglig och oberoende av kvoter och driftstörningar hos en provider. Det gör också qwen3:4b till den lilla reservmodellen istället för taket för vad maskinen klarar lokalt.

Min slutsats just nu är därför inte lokal LLM eller cloud. Gemma har visat sig vara en kompetent primär LLM för rutinmässigt och privat familjearbete under fortsatt test, medan GPT-5.6 finns kvar för den svåra delen och som providerfallback. Det som gör upplägget användbart är inte bara 16 GB VRAM. Det är kombinationen av tillräckligt context, tydliga verktyg, förutbestämda gränser, verifierade resultat och en medveten väg till en större modell.

Vad blir nästa steg?

Nästa test blir de nyare QAT-varianterna och Gemma 4 26B A4B. Den senare finns som en 16 GB QAT-fil i Ollama, men alla vikter måste fortfarande laddas och runtime plus context behöver också minne. Jag räknar därför med CPU-offload snarare än att den blir en bekväm ersättare för den nuvarande 12B-modellen på samma kort.

Det är kanske ett mindre romantiskt resultat än att flytta hela cloud LLM till källaren. Det är ändå ett system jag faktiskt kan använda till vardags. Det var en viktig lärdom från testet.