Mikä on Strix Halo? Puoli vuotta paikallisia kielimalleja AMD:n laitteistolla

Sinäkin olet varmaan nähnyt LinkedIn-postauksia Mac Studiosta, jossa on 128 gigatavua muistia, tai yrityksistä, joilla on käytössä Nvidian DGX Spark -laatikoita. Ne mahdollistavat suurien avoimien kielimallien ajamisen lokaalisti, ja molemmat perustuvat samaan ideaan: yhtenäismuistiin, joka antaa mallille paljon tilaa ilman konesalitason näytönohjainta. On kuitenkin kolmaskin vaihtoehto, jota moni ei tunne: AMD:n Strix Halo. Hankimme sellaisen puoli vuotta sitten täydentämään lokaalia näytönohjainresurssiamme. Kokosimme tähän kokemuksiamme siitä, mihin se pystyy, missä se eroaa verrokeistaan ja kenelle se sopii.

Kolme tapaa ajaa suuria malleja paikallisesti

Karkeasti vaihtoehtoja on kolme:

Erillisnäytönohjain (dGPU). Nopein, mutta muistia on vähän: kuluttajakortissa 16-32 Gt, mikä rajaa mallin koon. Suuret mallit vaativat useita kortteja, eivätkä näytönohjaimet ole halpoja.
Apple Silicon (yhtenäismuisti). Paljon muistia, ja parhaissa malleissa erittäin hyvä muistikaista, mutta ekosysteemi on macOS/Metal.
Kompaktit yhtenäismuisti-minikoneet. Iso jaettu muisti pienessä laatikossa, jossa suoritin ja näytönohjain ovat samalla piirillä. Esimerkiksi Nvidian DGX Spark (GB10, ARM) ja AMD:n Strix Halo (x86).

Käytännössä valintaa ohjaa kolme tekijää: ajettavan kielimallin koko, nopeus ja laitteiston hankintabudjetti. Mikään vaihtoehto ei ole paras kaikilla kolmella; ratkaisevaa on, minkä tekijän asettaa etusijalle.

Mikä Strix Halo on

Meidän laitteemme on Minisforum MS-S1 MAX (hankintahinta noin 2700 e + alv): AMD Ryzen AI Max+ 395 ("Strix Halo"), integroitu Radeon 8060S -näytönohjain, 128 Gt LPDDR5x-yhtenäismuistia (noin 256 Gt/s kaista) ja 2 Tt NVMe. Korvasimme mukana tulleen Windows-käyttöjärjestelmän Ubuntu Serverillä, kielimallit pyörivät Ollaman kautta. Muistista voi jakaa näytönohjaimelle noin 100 gigatavua, joten laatikkoon mahtuu kielimalli, joka muuten vaatisi konesalikortin, samalla kun kone kuluttaa sähköä suunnilleen kannettavan tietokoneen verran. Mittasimme laitteen kuluttavan lepotilassa noin 10 wattia ja raskaassa inferenssissä enimmillään noin 130 wattia.

Erot verrokkeihin, ja niistä seuraavat rajoitteet:

vs. Nvidia DGX Spark: Spark on ARM-pohjainen ja tuo mukanaan CUDA-ekosysteemin, joka on ohjelmistotuen kannalta kypsin. Halo on x86, eli se ajaa tavallista Linuxia ja tavallisia työkaluja ilman erikoissovituksia, ja on selvästi halvempi (Spark on tällä hetkellä hintaluokassa 4500 e + alv). Muistikaista on molemmilla samaa luokkaa, joten nopeusprofiili on samankaltainen.
vs. Mac (Apple Silicon): Huippu-Mac voi tarjota moninkertaisen muistikaistan ja siten nopeuden, mutta vastaavalla muistimäärällä hinta on tuntuvasti korkeampi. Halo on halvempi ja x86-Linux, mutta kaistaltaan hitaampi.
Yhteinen rajoite: kaikki yhtenäismuistilaatikot ovat kaistarajoitteisia näytönohjaimeen verrattuna. Muistia on paljon, mutta sen nopeus (ei määrä) ratkaisee käytännön suorituskyvyn.
Halon oma rajoite: ohjelmistopino (ROCm ja Ollama tällä piirillä) on näistä nuorin ja karkein: versioiden välillä on eroja siinä, mikä latautuu ja kuinka paljon muistia kuluu. Vanhaan versioon ei silti kannata jäädä, koska uudet malliarkkitehtuurit vaativat uutta ajonaikaista tukea, joten päivitykset kannattaa testata itse.

Nopeus: mitä oikeasti saa ulos

Kaistarajoite näkyy suorituskyvyssä selvästi: tekstin tuottaminen (decode) on nopeaa, mutta syötteen lukeminen (prefill) on hidasta, koska laskentateho on integroidun näytönohjaimen luokkaa.

Konkreettinen esimerkki tutuimmalla avoimien painojen mallilla, OpenAI:n GPT-OSS 120B:llä, jota olemme itsekin käyttäneet eniten yleismallina: tekstin tuotto on noin 36 tokenia sekunnissa, ja kevyemmät mallit yltävät lähes 60:een, mikä riittää vuorovaikutteiseen käyttöön hyvin. Sen sijaan pitkän kontekstin (isot tiedostot, pitkät keskustelut) käsittelyssä prefill kestää, ja agenttinen työ, joka lukee kasvavaa kontekstia joka kierroksella, kärsii tästä eniten. Käytännössä koodaustehtävä, jonka frontier-pilvimalli hoitaa sekunneissa, voi paikallisesti kestää minuutin tai pari, ja ajasta valtaosa kuluu juuri syötteen käsittelyyn.

Arkkitehtuuri ratkaisee. GPT-OSS on Mixture-of-Experts -malli: se aktivoi vain murto-osan parametreistaan kutakin tokenia kohti, joten se on nopea, vaikka on kokonaisuutena suuri. Vastaavan kokoinen tiheä (dense) malli lukisi kaikki parametrit jokaiselle tokenille ja putoaisi alle kymmeneen tokeniin sekunnissa, käytännössä liian hitaaksi. Siksi tälle laitteelle kannattaa valita MoE-malleja.

Mitä muita malleja koneelle mahtuu

Yhtenäismuistin ansiosta valikoima on laaja. Meillä on ajossa muun muassa:

GPT-OSS 120B (n. 65 Gt) yleismallina ja raskaampaan päättelyyn.
Qwen3-Coder-Next 80B (n. 52 Gt) agenttiseen koodaukseen.
Qwen 3.6 35B (n. 24 Gt), Gemma 4 26B (n. 18 Gt) ja muut kevyemmät mallit konenäköön ja yleistehtäviin.

Kvantisointi kannattaa valita harkiten. Testasimme Qwen3-koodausmallista sekä nelibittisen (n. 52 Gt) että kahdeksanbittisen (n. 85 Gt) version. Kahdeksanbittinen oli noin 1,5-2 kertaa hitaampi ilman havaittavaa laatuhyötyä koodauksessa, joten jäimme nelibittiseen. Hyvin valittu keskikokoinen malli päihittää usein suuremman sekä nopeudessa että käytännöllisyydessä.

Aina päällä oleva lokaali päätepiste, jonka käyttöä kannattaa optimoida

Suurin käytännön arvo yritykselle on siinä, että kone on aina päällä ja tarjoaa yhden pysyvän yhteyspisteen (Ollaman rajapinta), johon kaikki talon työkalut ja palvelut voivat ottaa yhteyttä. Sama lokaali malli on jatkuvasti saatavilla eri tarkoituksiin ilman pilvikutsua.

Tärkeä realiteetti: käytännössä vain yksi suurempi kielimalli on kerrallaan ladattuna. Siksi käyttö kannattaa optimoida: valitse malli ja kokoonpano sen käytön mukaan, jota priorisoit, äläkä yritä pitää montaa isoa mallia vuorotellen ladattuna (GPT-OSS 120B:n lataaminen muistiin kesti mittauksessamme noin 40 sekuntia). Meillä pidetään oletuksena yhtä yleismallia lämpimänä, ja erikoismallit (kuten agenttiseen koodaukseen sopivin) otetaan käyttöön kun niitä tarvitaan.

Tällä hetkellä koneella pyörii muun muassa jatkuvasti käynnissä olevia agentteja (esim. OpenClaw ja Hermes), jotka hoitavat ajastettuja ja orkestroituja tehtäviä, itse isännöityjä sisäisiä palveluita sekä asiakastoimeksiantojen projektidatan käsittelyä silloin, kun dataa ei haluta jakaa talon ulkopuolelle. Kaikki nämä ajetaan turvallisesti rajatuissa ja eriytetyissä ympäristöissä.

Koodaus paikallisilla malleilla: työkalu pitää sovittaa malliin

Halusimme tietää, pystyvätkö paikalliset mallit oikeaan ohjelmistotyöhön. Kyllä pystyvät, oikealla kokoonpanolla ja rehellisin odotuksin. Paikalliset avoimet mallit ovat frontier-pilvimalleja heikompia noudattamaan ohjeita tarkasti, joten niitä ei kannata ohjata vapaasti vaan rajoitetusti: agentti ajetaan eristetyssä kopiossa koodista, ja automaattiset testit ratkaisevat, onko tulos kelvollinen liitettäväksi osaksi ohjelmistoa.

Olemme testanneet myös useita terminaalipohjaisia koodausagenttien kehyksiä (harness), muun muassa Codex CLI, Qwen Code, Aider ja OpenCode. Selkein havainto oli, että ratkaisevaa on agenttikehyksen editointitapa, ei se, onko malli "samaa perhettä" työkalun kanssa. Esimerkiksi Qwen Code ja OpenAI:n GPT-OSS toimivat hyvin yhdessä. Itse päädyimme käyttämään eniten OpenCodea, koska se sopi parhaiten työskentelytapaamme ja toimii kaikilla malleilla. Joku toinen voi pitää enemmän Aiderista, jonka toiminnot poikkeavat hieman, mutta se on pitkälti makuasia, kunhan työkalu ja malli sopivat yhteen.

Tärkeintä on muistaa tehdä agenttisen pinon asetukset huolellisesti. Useimmat "ei toimi" -tilanteet olivat asetusongelmia, eivät mallin rajoja. Yksi tyypillinen sudenkuoppa on konteksti-ikkunan oletusarvo. Ollama antaa malleille oletuksena vain 4096 tokenia, mikä on liian pieni agenttiseen työkalukäyttöön ja saa työkalukutsut epäonnistumaan. Kun konteksti nostetaan mallille sopivaksi, ongelma katoaa.

Rehelliset rajat, ja mistä hyöty oikeasti syntyy

Paikalliset mallit eivät ole yhtä hyviä kuin parhaat frontier-mallit, eikä agenttikehyksen valinta vaikuta asiaan. Raskainta päättelyä vaativat tehtävät kannattaa mahdollisuuksien mukaan teettää frontier-malleilla pilvessä. Suurin hyöty paikallisesta laitteesta syntyy, kun lokaalit mallit asetetaan osaksi työnkulkuja, joissa data halutaan pitää omassa talossa, ajot ovat usein toisteisia tai pitkäkestoisia, ja niitä ajetaan paljon. Tällöin kustannusrakenne muuttuu ratkaisevasti: kun kysely ei mene pilveen, käyttökustannus on käytännössä sähkön hinta. Usein paras kuvio on hybridi, jossa ulkopuolinen frontier-malli orkestroi ylätason tehtävän ja lokaali malli suorittaa siitä toistuvat, datalle herkät osakokonaisuudet.

Kenelle Strix Halo siis sopii? Jos haluat ajaa suurehkoja avoimia malleja yksityisesti, edullisesti ja kohtuullisella nopeudella tavallisella x86-Linuxilla, se on edullisin tapa saada noin 100 Gt mallimuistia käyttöön. Jos taas tarvitset erillisnäytönohjaimen suoritustehoa, hyvin pitkiä konteksteja, huippunopeaa muistikaistaa tai valmiiksi kypsää ohjelmistoekosysteemiä, katso ennemmin Macia, useaa näytönohjainta tai pilveä, tai täydennä Haloa niillä. Meillä Strix Halo on löytänyt paikkansa: osa jokapäiväisestä ajosta tapahtuu paikallisella laitteella, ja pilveä käytetään harkiten siihen, mihin se on ylivertainen.

Tarvitsetko asiantuntijaratkaisuja? Tutustu Crestian palveluihin jo tänään.