Paikallisesti ajettu kielimalli tuntuu usein tyhmemmältä kuin sen viralliset vertailuluvut lupaavat. Level1Techsin foorumilla julkaistu koesarja osoittaa, että syy ei yleensä ole mallissa vaan ajoympäristössä.

Testit kiersivät viikonloppuna laajalti kehittäjäyhteisössä. Ne mittaavat, kuinka paljon yksittäinen asetus muuttaa mallin tuottamia tokeneita ja milloin muutos kaataa työkalukutsun kokonaan.

Sama malli, eri tulos jokaisella koneella


Jokainen kielimallia ajava laitteisto- ja ohjelmistoyhdistelmä on hieman erilainen. Kotilaboratoriossa voi olla useamman sukupolven näytönohjaimia, joiden käskykannat laskevat seuraavan tokenin eri tavalla.

Ero syntyy jo matematiikan tasolla. Sama painotiedosto tuottaa eri logitit eri laitteistolla, koska liukulukulaskennan järjestys ja tarkkuus vaihtelevat. Logitit ovat mallin pisteet jokaiselle mahdolliselle seuraavalle tokenille.

Testaajan käyttämässä vLLM-ajoympäristössä oli yhdessä öisessä konttivedoksessa 734 pakettia. Jokaisella on omat bugit ja dokumentoimattomat erikoisuudet, ja oman asennuksen reitti tuon koodivuoren läpi on yksilöllinen.

Aloita siis perusasioista. Tarkista mallikortilta oikeat sampler-asetukset ja keskusteluformaatti, sillä ne vaihtelevat malleittain. Liian matala lämpötila on tavallisin syy siihen, että malli jää jumiin omaan päättelyynsä.



Kotilaboratorion avoin testipenkki, jossa eri sukupolvien näytönohjaimia ja sekaisia kaapeleita


Attention-backend vaihtaa tokenin kesken ajon


Ensimmäinen koe vertaili kolmea vLLM:n täyden attentionin backendia: FlashAttention 2, Flash Inference ja Triton. Malli oli Qwen3.6-27B virallisilla BF16-painoilla, ja kaikki muut asetukset pidettiin muuttumattomina.

Ensimmäisten tuhansien tokenien ajan kaikki kolme olivat samaa mieltä seuraavasta tokenista. Pidemmälle mentäessä backendit alkoivat eriytyä, ja erot kasautuivat ryppäiksi kehotteen sisällön mukaan eivätkä tasaisesti pituuden myötä.

Satunnaisuus suljettiin pois. Samalla backendillä toistetut ajot tuottivat bitilleen identtiset logitit, joten ero syntyy yksinomaan esikäsittelyn matriisilaskennasta.

Seuraus voi olla vakava. Yhdessä esimerkissä FlashAttention 2 osoitti työkalukutsun väärään Cisco-reitittimen liitäntään ja ajoi sen jälkeen väärää komentoa kahdesti. Tuotantoverkossa vastaava virhe voisi johtaa katkokseen.



Yksi valojuova haarautuu kahdeksi eriäväksi poluksi ja etääntyy horisonttia kohti


KV-välimuistin kutistaminen kaataa työkalukutsut


Toinen koe jätti painot ja aktivaatiot rauhaan ja kvantisoi pelkän KV-välimuistin. Se on tavallinen keino säästää näytönmuistia pitkillä konteksteilla, ja moni tekee sen automaattisesti asetuksia säätäessään.

Tulokset jakautuivat jyrkästi. Täysikokoinen BF16-välimuisti selvisi tehtävästä ongelmitta. Int8 ajautui virheeseen mutta onnistui toipumaan siitä. Int4 ei toipunut lainkaan, vaan työkalukutsu jäi kesken.

Tästä seuraa selkeä käytännön ohje. Jos agentti käyttää työkaluja pitkissä konteksteissa, KV-välimuistia ei kannata pudottaa neljään bittiin muistin säästämiseksi. Kontekstin lyhentäminen on turvallisempi keino kuin välimuistin tarkkuudesta tinkiminen.



Metalliketju ohenee ja katkeaa loppupäästään tummaa taustaa vasten


Näin valitset kvantisoinnin oikein


Kolmas koe vertaili viittä painovaihtoehtoa samalla täysikokoisella BF16-välimuistilla: virallinen BF16, virallinen FP8, yhteisön INT8, NVIDIAn NVFP4 ja AWQ-menetelmällä tehty neljän bitin versio.

Järjestys ei noudattanut odotuksia. Yhteisön INT8-versio päihitti sekä mallin tekijän oman FP8:n että NVIDIAn julkaisun. NVFP4 jäi viimeiseksi ja päätyi noin 50 prosentin tokenimuutoksiin 88 000 tokenin kohdalla.

Työkalukutsuissa jako oli vielä selvempi. Sekä NVFP4 että AWQ-versio epäonnistuivat kutsun sulkemisessa ja sekoittivat Cisco-komennon syntaksin. FP8 ja INT8 suoriutuivat samasta tehtävästä oikein.

Nyrkkisääntö on yksinkertainen. Agenttityöhön kannattaa valita kahdeksan bitin painot ja täysikokoinen KV-välimuisti. Neljän bitin kvantisointi säästää muistia mutta maksaa juuri siellä, missä agentti tarvitsee tarkkuutta eniten.



Viisi kooltaan pienenevää punnusta tarkkuusvaa'alla studiovalossa


Yhteenveto


Paikallinen malli ei ole tyhmä. Se ajaa eri koodipolkua kuin laboratorion referenssitoteutus, ja jokainen oikaisu muistinkulutuksessa siirtää tulosta kauemmas alkuperäisestä.

Tärkeintä on mittaustapa, ei yksittäinen luku. Aja omat pitkän kontekstin ja työkalukutsujen testit sillä kokoonpanolla, jolla oikeasti työskentelet. Kolme kehotetta nollalämpötilalla ei kerro mallin todellisesta käyttökelpoisuudesta mitään.