Tuttu havainto paikallisen mallin ajajilta: sama malli tuntuu kotona tyhmemmältä kuin virallisella palvelimella. Syyksi on totuttu epäilemään pakkausta. Level1Techsin foorumilla julkaistu mittaus, jonka kiinalainen 量子位 nosti lauantai-iltana uutiseksi, kertoo että syitä on useampia — ja että pakkaus ei ole niistä kiinnostavin.

Mittauksen tekijä ajoi Qwen3.6-27B:tä yhdellä työasemakortilla ja tallensi yli 100 000 tokenin ajosta täyden todennäköisyysjäljen: koko sanaston logit-arvot joka 32. tokenin kohdalta. Niistä hän laski kahden ajon välisen KL-etäisyyden ja sen, kuinka usein malli valitsi eri sanan, kaikki kaksinkertaisella liukulukutarkkuudella. Vertailu on siis paljon hienojakoisempi kuin tavallinen "sai testistä yhtä monta pistettä".

Ensimmäinen tulos on hätkähdyttävin. Kun ajossa vaihdettiin vain huomiokerroksen toteutus — FlashAttention 2, Flash Inference tai Triton — ja kaikki muu pidettiin identtisenä, mallit alkoivat pitkässä kontekstissa valita eri sanoja. Yhdessä työkalukutsussa Cisco-reitittimen liitäntä GigabitEthernet0/0/1.201 muuttui FlashAttention 2:lla muotoon GigabitEthernet0/1/4, ja malli ajoi sen jälkeen kaksi väärää komentoa. Saman toteutuksen toistoajot olivat bitilleen identtisiä, joten kyse ei ole satunnaisuudesta vaan siitä, missä järjestyksessä eri laskentaytimet summaavat samat luvut.

Toinen tulos koskee sitä säästöä, jota paikallinen ajaja käyttää kaikkein useimmin. Kun keskustelun välimuisti pakattiin, BF16 pysyi vakaana koko ajon, INT8 toipui virheistään, mutta INT4:llä väärien sanavalintojen osuus räjähti pitkässä kontekstissa niin, etteivät työkalukutsut enää palautuneet lainkaan. Välimuistin pakkaaminen neljään bittiin on juuri se temppu, jolla näytönohjaimen muistista puristetaan lisää kontekstia — ja mittauksen mukaan se maksaa eniten juuri siellä, missä pitkää kontekstia tarvitaan.

Kolmas tulos on nolo. Painojen pakkauksessa verrattiin viittä versiota, ja parhaan sanavalintojen yhtenevyyden sai yhteisön tekemä kalibroimaton kahdeksanbittinen versio — parempi kuin mallin tekijän oma virallinen FP8 ja parempi kuin Nvidian virallinen NVFP4. Syy on rakenteellinen: kalibroimaton versio säilyttää aktivaatiot täydellä tarkkuudella eikä pakkaa lainkaan tiettyjä projektioita eikä ulostulokerrosta. NVFP4 oli selvästi huonoin, ja 88 000 tokenin kontekstissa sen väärien valintojen osuus lähestyi puolta. Tähän liittyy tärkeä varaus, jonka tekijä kertoo itse: hänen käyttämässään kehitysversiossa näytönohjainpolku ei tukenut natiivia nelibittistä laskentaa, joten NVFP4 purettiin ajossa pelkäksi painojen pakkaukseksi — luku ei siis kerro, mihin muoto pystyy oikein toteutettuna.

Neljäs tulos on omalla tavallaan pahin, koska se ei liity pakkaukseen mitenkään. Täsmälleen samoilla pakkaamattomilla painoilla yhdellä kortilla ajettuna työkalukutsu onnistui, kahdella kortilla epäonnistui ja neljällä kortilla onnistui taas. Syy jäljitettiin korttien välisen summauksen numeriikkaan. Tästä ei ole paikalliselle ajajalle suoraa haittaa niin kauan kuin kortteja on yksi, mutta se tekee tyhjäksi ajatuksen, että sama malli olisi sama malli riippumatta siitä, miten se on levitetty raudalle.

Johtopäätös on kirjoitettu suoraan mallikorttien lukijoille. Kun mallin julkaisija ilmoittaa pienen KL-etäisyyden todisteena siitä, ettei pakkaus vahingoita mallia, luku ei tarkoita mitään ellei mukana ole vertailukohtaa, koko ajoympäristöä, arviointitekstiä, kalibrointidataa, kontekstipituutta, näytteenottokohtia, etäisyyden suuntaa ja sitä, miten sanasto on katkaistu ja tulokset laskettu yhteen. Tekijän lataamassa ajoympäristössä oli 734 pakettia, joista 252 Python-pakettia — ja kuten mittaus osoittaa, yhden niistä vaihtaminen riittää muuttamaan vastauksen.