Vad är Strix Halo? Ett halvår med lokal AI på AMD-hårdvara

Du har säkert sett LinkedIn-inlägg om en Mac Studio med 128 gigabyte minne, eller om företag som kör Nvidia DGX Spark-lådor. De låter dig köra större öppna språkmodeller lokalt, och båda bygger på samma idé: enhetligt minne, som ger modellen gott om utrymme utan ett grafikkort i datacenterklass. Men det finns ett tredje alternativ som många inte känner till: AMD:s Strix Halo. Vi skaffade en för ett halvår sedan för att komplettera våra lokala grafikresurser. Här har vi samlat vad vi lärt oss om vad den klarar, var den skiljer sig från sina motsvarigheter och vem den passar för.

Tre sätt att köra stora modeller lokalt

Grovt sett finns det tre alternativ:

Separat grafikkort (dGPU). Snabbast, men minnet är knappt: 16-32 GB på ett konsumentkort, vilket begränsar modellstorleken. Stora modeller kräver flera kort, och grafikkort är inte billiga.
Apple Silicon (enhetligt minne). Mycket minne, och på de översta modellerna mycket hög minnesbandbredd, men ekosystemet är macOS/Metal.
Kompakta minidatorer med enhetligt minne. Ett stort delat minne i en liten låda, där processor och grafik sitter på samma krets. Till exempel Nvidias DGX Spark (GB10, ARM) och AMD:s Strix Halo (x86).

I praktiken styrs valet av tre faktorer: storleken på modellen du vill ha, hastigheten och budgeten för hårdvaran. Inget alternativ är bäst på alla tre; det avgörande är vilken faktor du sätter främst.

Vad Strix Halo är

Vår maskin är en Minisforum MS-S1 MAX (inköpspris omkring 2 700 € + moms): en AMD Ryzen AI Max+ 395 ("Strix Halo"), ett integrerat Radeon 8060S-grafikkort, 128 GB LPDDR5x enhetligt minne (omkring 256 GB/s bandbredd) och en 2 TB NVMe. Vi ersatte det medföljande Windows-operativsystemet med Ubuntu Server, och modellerna serveras med Ollama. Av minnet kan man ge grafiken omkring 100 gigabyte, så lådan rymmer en modell som annars skulle kräva ett datacenterkort, samtidigt som maskinen drar ungefär lika mycket ström som en bärbar dator: vi mätte att kretsen drar omkring 10 watt i viloläge och som mest omkring 130 watt vid tung inferens.

Skillnader mot motsvarigheterna, och de begränsningar som följer:

jämfört med Nvidia DGX Spark: Spark är ARM-baserad och för med sig CUDA-ekosystemet, som är det mognaste vad gäller programstöd. Halo är x86, alltså kör den vanlig Linux och vanliga verktyg utan särskilda anpassningar, och är klart billigare (Spark ligger för närvarande i prisklassen 4 500 € + moms). Minnesbandbredden är av samma storleksordning hos båda, så hastighetsprofilen är likartad.
jämfört med Mac (Apple Silicon): En topp-Mac kan erbjuda flera gånger minnesbandbredden, och därmed hastigheten, men vid motsvarande minnesmängd är priset märkbart högre. Halo är billigare och kör x86-Linux, men är långsammare i bandbredd.
Gemensam begränsning: alla lådor med enhetligt minne är bandbreddsbegränsade jämfört med ett grafikkort. Det finns gott om minne, men dess hastighet (inte mängd) avgör den praktiska prestandan.
Halos egen begränsning: programvarustacken (ROCm och Ollama på den här kretsen) är den yngsta och råaste av dessa, och versionerna skiljer sig i vad som laddas och hur mycket minne det tar. Att stanna på en gammal version är ändå inte det säkra valet, eftersom nya modellarkitekturer kräver nyare körtidsstöd, så varje uppdatering bör testas själv.

Hastighet: vad man faktiskt får ut

Bandbreddsbegränsningen syns tydligt i prestandan: att producera text (decode) är snabbt, men att läsa in indata (prefill) är långsamt, eftersom beräkningskraften ligger på integrerad grafiknivå.

Ett konkret exempel med den mest kända modellen med öppna vikter, OpenAI:s GPT-OSS 120B, som vi själva använt mest som allmän modell: textgenereringen ligger på omkring 36 token per sekund, och lättare modeller når nästan 60, vilket räcker väl för interaktiv användning. Vid behandling av lång kontext (stora filer, långa samtal) tar prefill däremot tid, och agentiskt arbete, som läser en växande kontext varje varv, lider mest av detta. I praktiken kan en kodningsuppgift som en frontier-molnmodell klarar på sekunder ta en minut eller två lokalt, till största delen just i behandlingen av indata.

Arkitekturen är avgörande. GPT-OSS är en Mixture-of-Experts-modell: den aktiverar bara en bråkdel av sina parametrar per token, så den är snabb trots att den som helhet är stor. En tät (dense) modell av samma storlek skulle läsa alla parametrar för varje token och sjunka till ett ensiffrigt antal token per sekund, i praktiken för långsamt. Därför lönar det sig att välja MoE-modeller för den här maskinen.

Vilka andra modeller som passar

Tack vare det enhetliga minnet är urvalet brett. Vi kör bland annat:

GPT-OSS 120B (ca 65 GB) som allmän modell och för tyngre resonemang.
Qwen3-Coder-Next 80B (ca 52 GB) för agentisk kodning.
Qwen 3.6 35B (ca 24 GB), Gemma 4 26B (ca 18 GB) och andra lättare modeller för datorseende och allmänna uppgifter.

Kvantiseringen är värd att välja med omtanke. Vi testade både fyrabitarsversionen (ca 52 GB) och åttabitarsversionen (ca 85 GB) av Qwen3-kodningsmodellen. Åttabitarsversionen var omkring 1,5-2 gånger långsammare utan märkbar kvalitetsvinst i kodning, så vi stannade vid fyrabitarsversionen. En väl vald medelstor modell slår ofta en större både i hastighet och praktisk användbarhet.

En alltid påslagen lokal ändpunkt, och varför användningen lönar sig att optimera

Det största praktiska värdet för ett företag är att maskinen alltid är på och erbjuder en bestående ändpunkt (Ollamas gränssnitt) som alla verktyg och tjänster i huset kan ansluta till. Samma lokala modell är ständigt tillgänglig för olika ändamål utan ett molnanrop.

En viktig verklighet: i praktiken är bara en stor modell laddad åt gången. Därför lönar det sig att optimera användningen: välj modell och konfiguration efter den användning du prioriterar, och försök inte hålla flera stora modeller laddade växelvis (att läsa in GPT-OSS 120B i minnet tog omkring 40 sekunder i vår mätning). Hos oss håller vi som standard en allmän modell varm, och specialmodeller (som den som bäst passar för agentisk kodning) tas i bruk när de behövs.

För närvarande kör maskinen bland annat ständigt aktiva agenter (som OpenClaw och Hermes) som sköter schemalagda och orkestrerade uppgifter, ett antal egenhostade interna tjänster samt behandling av projektdata från kunduppdrag när data inte ska delas utanför huset. Allt detta körs i säkert avgränsade och isolerade miljöer.

Kodning med lokala modeller: verktyget måste anpassas till modellen

Vi ville veta om lokala modeller klarar riktigt programvaruarbete. Det gör de, med rätt konfiguration och ärliga förväntningar. Lokala öppna modeller är sämre än frontier-molnmodeller på att följa instruktioner exakt, så det lönar sig inte att styra dem fritt utan begränsat: agenten körs på en isolerad kopia av koden, och automatiska tester avgör om resultatet duger att fogas in som en del av programvaran.

Vi har också testat flera terminalbaserade ramverk (harness) för kodningsagenter, bland annat Codex CLI, Qwen Code, Aider och OpenCode. Den tydligaste iakttagelsen var att det avgörande är agentramverkets redigeringssätt, inte om modellen är "av samma familj" som verktyget. Till exempel fungerar Qwen Code och OpenAI:s GPT-OSS bra tillsammans. Till slut landade vi i att mest använda OpenCode, eftersom det passade vårt arbetssätt bäst och fungerar med alla modeller. Någon annan kan föredra Aider, vars funktioner avviker något, men det är till stor del en smaksak, så länge verktyget och modellen passar ihop.

Det viktigaste att komma ihåg är att ställa in den agentiska stacken omsorgsfullt. De flesta "fungerar inte"-situationer var konfigurationsproblem, inte modellens gränser. En typisk fallgrop är kontextfönstrets standardvärde. Ollama ger modellerna som standard bara 4096 token, vilket är för litet för agentisk verktygsanvändning och får verktygsanropen att misslyckas. När kontexten höjs så att den passar modellen försvinner problemet.

Ärliga gränser, och var nyttan faktiskt uppstår

Lokala modeller är inte lika bra som de bästa frontier-modellerna, och valet av agentramverk ändrar inte på det. Uppgifter som kräver det tyngsta resonemanget lönar det sig att i mån av möjlighet lägga ut på frontier-modeller i molnet. Den största nyttan av en lokal maskin uppstår när lokala modeller placeras som en del av arbetsflöden där man vill hålla data i det egna huset, körningarna ofta är repetitiva eller långvariga, och de körs mycket. Då förändras kostnadsbilden avgörande: när en förfrågan inte går till molnet är driftskostnaden i praktiken elpriset. Ofta är det bästa mönstret en hybrid, där en extern frontier-modell orkestrerar uppgiften på hög nivå och en lokal modell utför dess återkommande, datakänsliga delar.

Vem passar då Strix Halo för? Om du vill köra ganska stora öppna modeller privat, förmånligt och med rimlig hastighet på vanlig x86-Linux är det det billigaste sättet att få omkring 100 GB modellminne till förfogande. Om du däremot behöver genomströmningen hos ett separat grafikkort, mycket långa kontexter, toppsnabb minnesbandbredd eller ett redan moget programvaruekosystem, titta hellre på en Mac, flera grafikkort eller molnet, eller komplettera Halo med dem. Hos oss har Strix Halo hittat sin plats: en del av den dagliga körningen sker på den lokala maskinen, och molnet används med omdöme för det som det är oöverträffat på.

Letar du efter expertlösningar? Upptäck Crestias professionella tjänster idag.