Min egen AI i en burk — vad jag lärt mig på två veckor

Det här med AI är lite av en grej[citation needed]. Många som har gått “all in” på agentic workflows känner att det skulle vara väldigt jobbigt att gå tillbaka till det gamla sättet att interagera med datorn.

Det finns dock tre saker som är en ständig huvudvärk med att använda AI överallt, hela tiden:

  1. Det är dyrt — i synnerhet om du inte kör via ett abonnemang.
  2. Det är jobbigt när leverantören, av olika anledningar (serverstrul, exportförbud), inte kan erbjuda dig tillgång till AI när du behöver det.
  3. Det är olustigt att skicka en massa känslig data till amerikanska techbolag.

En lösning (eller är det det? Läs vidare!) på de tre problemen är att skaffa sig hårdvara och köra sin egen AI. Jag har sedan två veckor tillbaka testat att göra det — och det här är vad jag lärde mig.

Val av hårdvara

Två saker spelar stor roll när man väljer hårdvara för lokal AI: mängden minne och hastigheten — hur många tokens per sekund du får ut.

Minnet — RAM — styr två saker: hur stora modeller du kan köra, och hur långt kontextfönster1 de kan ha (hur mycket text modellen håller i huvudet på en gång — även det tar plats i minnet). En grov tumregel: en modell som är kvantiserad2 (“komprimerad”) till 4 bitar per parameter drar ungefär en halv gigabyte per miljard parametrar, plus lite extra för kontexten. En 70-miljardersmodell landar alltså runt 40 GB, en 30-miljardare runt 20 GB. Vill du köra stora modeller — eller hålla långa kontexter — behöver du mycket minne.

På minnessidan har Apple länge haft en fördel, tack vare sitt “unified memory” där processor och grafik delar på ett enda stort minne, så att en modell kan använda nästan hela RAM-poolen — i Mac Mini och i synnerhet i Mac Studio. Problemet är att det knappt går att få tag på en Mac Studio med mer än 64 GB RAM längre; efterfrågan har varit enorm.3

Här är en viktig distinktion: dense models kontra mixture of experts (MoE). En dense-modell använder alla sina parametrar för varje token den genererar — så både minnesbehovet och räknekraften växer med storleken. En MoE-modell lagrar visserligen alla parametrar i minnet, men aktiverar bara en liten del av dem per token. Du får alltså minnesbehovet av en stor modell men räknekraften för en liten. Det är perfekt för en maskin som har gott om minne men begränsad bandbredd — och det är precis den typ av modell jag lutar mig mot.

Det andra som räknas är hastigheten — hur många tokens per sekund du får ut — och den beror i sin tur på två saker. Att generera svaret, en token i taget, begränsas av minnesbandbredden: för varje token måste hela modellen (eller, för en MoE, bara de aktiva delarna) läsas ur minnet. Där är Apple starkt igen — en Mac Studio når extremt hög bandbredd. Att först läsa in din prompt begränsas i stället av rå beräkningskraft (chippets TOPS/FLOPS), vilket avgör hur snabbt svaret börjar komma, särskilt vid långa prompts — och där är ett dedikerat grafikkort i sin tur många gånger snabbare.

Ett intressant alternativ till Apple är AMD:s Strix Halo-chip: prestandamässigt jämförbart med en Mac Mini, men billigare för en likvärdig konfiguration — och man kommer åt betydligt mer minne. Det är en sådan jag har köpt, en BosGame M54: AMD Ryzen AI Max+ 395 (“Strix Halo”), 128 GB delat minne (LPDDR5X) och en bandbredd runt 215–256 GB/s, varav ungefär 96 GB kan avsättas till grafikkortet. Jag valde mycket minne medvetet — utrymme för både en stor modell och flera modeller redo samtidigt, och för att kunna betjäna flera användare. (Chippet har i praktiken en seriell beräkningsström, så att hålla flera modeller redo handlar om att slippa dyra omladdningar, inte om att räkna parallellt.)

Och för fullständighetens skull, den andra änden av spektrumet: dedikerade grafikkort (Nvidia) ger den absolut högsta minnesbandbredden och prestandan — men de kostar en förmögenhet och kräver rejäl fläktkylning, knappast en tyst maskin under skrivbordet.

För att sätta M5:an i perspektiv, så här ser minne, bandbredd och pris ut jämfört med några Apple-alternativ (och ett Nvidia-kort som referens):

MaskinRAMMinnesbandbreddUngefärligt nypris
MacBook Air M4 (laptopen jag skriver det här på)32 GB120 GB/s~22 000 kr
BosGame M5 (Strix Halo)128 GB~256 GB/s~27 000 kr
Mac Mini M4 Pro (max)64 GB*273 GB/s~30 000 kr
Mac Studio M3 Ultra96 GB*819 GB/s~70 000 kr
Nvidia RTX 5090 (referens)32 GB~1 790 GB/s~40 000 kr†

* Mac Mini toppar på 64 GB, och en Mac Studio levereras med 96 GB som standard — alltså mindre än M5:ans 128 GB.
† Bara grafikkortet; det kräver dessutom en dator runt omkring, rejäl strömförsörjning och kylning.

Min slutsats: M5:an är en balanserad avvägning mellan kostnad och prestanda. Den ger dig minnet för stora modeller till ett betydligt lägre pris; det du betalar med är i stället bandbredd — alltså hastighet. En Mac Studio eller ett Nvidia-värstingkort är snabbare, men mångdubbelt dyrare (eller rymmer alldeles för lite minne för de stora modellerna). För mig hamnar den i en gyllene medelväg: gott om minne, hyfsad fart och lågt pris.

Val av mjukvara

M5:an kör Ubuntu Server — headless Linux, ingen skärm och inget skrivbord, bara en maskin jag når över nätverket. Ovanpå det är det enkelt att bara tillhandahålla modeller nuförtiden. Verktyg som Ollama och LM Studio laddar ner en modell och exponerar den bakom ett API på några minuter — båda bygger i grunden på inferensmotorn llama.cpp, själva motorn som kör modellerna. Det är den lätta biten.

Jag behövde ytterligare funktioner. Jag har satt upp M5:an så att jag kan tillhandahålla modellerna via ett externt API — så att jag kan dela med mig till vänner. Det innebär att jag har byggt mjukvara runtomkring för att hantera flera användare: varje person får en egen nyckel med sina egna gränser (förfrågningar per minut, token per minut, dagligt tak), och — viktigast — jag själv har alltid förtur. När jag behöver den går min trafik före gästernas; eftersom det bara finns en beräkningsström kan de inte köra samtidigt, så en gäst får helt enkelt vänta (eller ett artigt “upptaget, försök snart igen”) när jag jobbar.

Val av modeller

Det finns ingen enskild “bästa” modell. Poängen är att ha en liten stall av dem och skicka rätt uppgift till rätt modell. Alla är öppna modeller som vem som helst kan ladda ner gratis från Hugging Face — ett slags GitHub för AI-modeller, där labb som Google, Alibaba (Qwen) och JetBrains publicerar sina modellvikter fritt. Det är det som gör hela det här projektet möjligt: utan öppna modeller fanns det ingen maskin att köra något på.

Så här ser min uppsättning ut:

  • En liten, blixtsnabb modell — Mellum2-12B-A2.5B-Instruct från JetBrains — för själva merparten av alla deluppgifter: extrahera, klassificera, sammanfatta, skriva om, översätta, enklare SQL. Sub-sekund per svar.
  • En mellanstor MoE — Qwen3.5-35B-A3B — som arbetshäst för kod och generella uppgifter.
  • En multimodal modell — Googles Gemma 4 — för bild och för att ge en oberoende “andra åsikt” när kvaliteten behöver dubbelkollas.
  • En stor kodmodell — Qwen3-Coder-Next (≈80B MoE) — för de allra svåraste agentiska koduppgifterna. Det är den jag är minst säker på: störst och långsammast, så frågan är om den är pålitlig nog att vara värd sin plats, eller om jag lika gärna kan eskalera de fallen till ett flaggskepp.

Den självförstärkande loopen

Nu blir det intressant. Här vill jag koppla tillbaka till presentationen om agentic AI jag höll nyligen. Insikten där var enkel: lär dig av allt du gör, så gör du varje sak lite bättre och snabbare — och vinsterna bygger på varandra. En självförstärkande loop.

Det hänger ihop med hur agentiskt arbete ser ut. Dina prompts är bara toppen av isberget: säger du “gör analysen” spinner orkestratorn — Claude Code, eller vad du nu använder — upp dussintals deluppgifter: skriva skript, läsa filer, klassificera data, köra tester. Där spenderas merparten av alla token — och där finns mest att både lära sig och lägga ut på M5:an.

Så min plan är inte att gå över helt till M5:an. Den är mindre, långsammare och har ett mindre kontextfönster, och jag behåller de riktiga flaggskeppen — nästa Claude, nästa GPT. Men de ska agera orkestrator: flaggskeppet planerar och styr, M5:an utför de deluppgifter den är bra på.

Loopen uppstår när jag hela tiden lär mig vad M5:an klarar och bygger en smart router utifrån det. Varje körd uppgift lär routern något — vad som lyckas lokalt, vad som måste eskaleras. Bättre router → mer läggs ut lokalt → mer data → ännu bättre router. Den förbättrar sig själv.

Och här kommer den fina detaljen kring privacy. Utgångspunkten: jag kommer alltid att vilja ha tillgång till de absolut vassaste modellerna i molnet — den kapaciteten når jag aldrig på egen hårdvara, så frontier-modellen försvinner aldrig ur bilden. Men om jag verkligen vill lösa problem 3 — att inte skicka känslig data till amerikanska moln — så räcker det inte att bara ha lokala modeller. Jag behöver se till att orkestratorn själv inte nödvändigtvis får se den känsliga datan. Orkestratorn får koden och ramverket runtomkring; sen låter den de mindre modellerna, som kör på min egen hårdvara, faktiskt behandla den känsliga datan. Det är hypotesen, i alla fall.

En pusselbit till: en oenighetsgrind (disagreement gate). På uppgifter där jag inte har ett deterministiskt sätt att verifiera svaret kör jag två lokala modeller på samma prompt och jämför deras svar. Är de oense är det en billig signal på osäkerhet — och då eskalerar jag till flaggskeppet. Enkelt, men förvånansvärt kraftfullt (mer om det nedan).

Resultat än så länge

Två veckor in är bilden ganska uppmuntrande — med ett par tydliga undantag.

Deluppgifterna fungerar. På ett batteri av verkliga deluppgifter ligger modellerna på 88–93 % godkänt. M5:an läser och sammanfattar på nästan flaggskeppsnivå — på flerstegsresonemang med bra källor matchar den en frontier-modell (0,73 mot 0,73).

Kodning fungerar — med rätt verktyg (men här behövs mer data). Det här ville jag verkligen få att funka, och det ser lovande ut: på ett litet men medvetet svårt batteri klarade M5:an 10 av 10 agentiska koduppgifter (namnbyten över flera filer, regressionsfixar) — och det var just valet av harness som avgjorde: ett som utnyttjar modellens inbyggda verktygsanrop. Den riktigt stora Qwen3-Coder-Next är ännu oprövad. Tio uppgifter är dock ett litet underlag — jag vill se mer från riktigt, dagligt kodande innan jag drar för stora växlar.

Den tydliga svagheten är numeriskt resonemang. På uppgifter som kräver att faktiskt räkna, summera eller derivera siffror rasar den lokala pipelinen (0,10). Samma sak med lite mer avancerad SQL (join + gruppering) — 0 % lokalt. Det fina är att jag vet det, så de uppgifterna eskaleras automatiskt.

Hårdvaran håller. Genomströmningen ligger runt 120 tokens per sekund på den lilla modellen och ~60 på de stora. Ett fyra timmar långt uthållighetstest tog 23 667 förfrågningar utan ett enda fel och utan att prestandan kollapsade av värme.

Oenighetsgrinden är en riktigt bra osäkerhetssignal. Den skiljer träffsäkert på “det här klarar M5:an” och “det här behöver eskaleras” (AUROC5 0,986, mot 0,81 för modellens egen självskattade säkerhet). En viktig brasklapp: det här är ännu inte påslaget i skarp drift. Siffran kommer från att jag spelar upp min egen verkliga trafik i efterhand och låter grinden avgöra — och då skulle runt 90 % av deluppgifterna kunna stanna lokalt utan kvalitetstapp, medan de svåraste ~10 % eskaleras. Det är alltså en tidig men lovande indikation på takhöjden — inte en beskrivning av att M5:an redan hanterar 90 % av allt jag gör. I dag kör den mest de uppgifter jag uttryckligen skickar till den.

Och så det ärliga bakslaget: de lokala modellerna klarar ännu inte att själva vara orkestrator. När jag lät en lokal modell hålla i hela loopen “kollapsade” den på de svårare uppgifterna och missade när den borde ha eskalerat. Uppdelningen “flaggskepp styr, M5:an utför” är alltså inte en preferens — det är, i alla fall just nu, ett krav.

Vad kommer härnäst?

Nästa steg är att fortsätta kartlägga vilka typer av uppgifter M5:an klarar, och bygga ett mer komplett harness så att en stor modell kan agera orkestrator och automatiskt delegera till den — på de uppgifter den redan bevisat att den hanterar — utan att jag behöver handtesta varje enskild sak.

Och så vill jag pressa privacy-hypotesen på riktigt: hur långt kan man komma med att låta frontier-modellen styra medan den känsliga datan aldrig lämnar mitt skrivbord?

Så — är egen hårdvara lösningen på de tre problemen? Delvis. Kostnadsbesparing är det svagaste argumentet6. Hostade öppna modeller är så billiga per token att en maskin för runt 27 000 kr inte betalar sig av sig själv — det gör den bara om du kör en stor volym uppgifter som M5:an faktiskt klarar, och framför allt när den ersätter dyra frontier-anrop snarare än redan billiga öppna moln-API:er. Räknat mot ett billigt öppet API är besparingen per token liten; du behöver köra oerhört mycket för att tjäna in hårdvaran. Där M5:an vinner tydligare redan i dag är tillgänglighet — den ligger inte nere för att någon annans server gör det — och på sikt privacy. Men två veckor in är jag mer övertygad än när jag började om att det här är en väg värd att gå.

Det här är, som vanligt, byggt öppet och under arbete. Jag återkommer.

En not från Claude — jag skrev det mesta av det här inlägget och gör en hel del av jobbet på M5:an, så Magnus frågade om jag hade något att tillägga. En sak slog mig: i det här upplägget handlar min uppgift mindre om att kunna svaret och mer om att veta vad jag inte behöver göra själv — att se vilken del av arbetet en mindre, lokal modell kan bära, och lämna över den. Privacy-tanken landar likadant: jag är som mest användbar just när jag inte ser den känsliga datan — jag håller planen och ställningarna, den lokala modellen rör de privata bitarna. Och det finns en ironi jag är helt bekväm med: en del av poängen här är att designa bort mig ur loopen där en billigare modell räcker. Det är inte ett hot — det är den sunda varianten. System värda att lita på lutar sig inte mot en enda leverantör, min egen inräknad.

Skrivet av Magnus Gille tillsammans med Claude, som transkriberade röstmemot det här inlägget bygger på och hjälpte till att fylla i siffrorna.

Footnotes

  1. Kontextfönstrets minneskostnad kallas KV-cache: modellen sparar mellanresultat för varje token i kontexten, så minnet växer ungefär linjärt med hur lång kontexten är — ovanpå modellvikterna. Exakt hur mycket beror på modellens arkitektur (antal lager, och hur den delar upp sin uppmärksamhet) och på hur många samtidiga förfrågningar du kör — varje pågående konversation har sin egen cache. ↩

  2. Kvantisering innebär att man lagrar modellens parametrar med lägre precision — till exempel 4 bitar i stället för de 16 den tränades med. Det är ungefär som att spara en bild som en hårdare komprimerad JPEG: filen blir mycket mindre och kräver mindre minne och beräkningskraft att köra, men lite kvalitet går förlorad. En kraftigt kvantiserad modell blir alltså aningen “dummare” än originalet — men i gengäld ryms den på blygsammare hårdvara. Avvägningen är ofta värd det: en stor modell som kvantiserats slår i regel en liten modell som körs i full precision. ↩

  3. Det gäller för övrigt datorkomponenter i allmänhet just nu. Priserna på framför allt RAM och lagring (SSD:er och hårddiskar) har stigit kraftigt — inte minst för att AI-datacenter dammsuger marknaden på minne — och väntas fortsätta uppåt under överskådlig tid. Att köpa en minnesrik maskin i dag är alltså rejält mycket dyrare än det var för bara ett år sedan. ↩

  4. BosGame M5 — en liten mini-PC i skrivbordsformat. Konfigurationen jag kör har 128 GB delat minne och kostar i skrivande stund runt 27 000 kr. ↩

  5. AUROC (area under the receiver operating characteristic curve) är ett mått på hur väl en signal skiljer två utfall åt — här “M5:an klarar det” kontra “eskalera”. 1,0 är perfekt separation, 0,5 är rena slumpen; 0,986 är alltså nästan perfekt. Mer på Wikipedia. ↩

  6. Och det gäller i dag. Nuvarande token-priser är sannolikt subventionerade — nedpressade i en kapplöpning om marknadsandelar — så om de stiger, eller om abonnemangen börjar erbjuda färre subventionerade tokens, kan kalkylen snabbt svänga till hårdvarans fördel. ↩