Kun tekoälymalleja koulutetaan vahvistusoppimisella (RL), pinossa on kaksi pyörää, joiden täytyy pyöriä täsmälleen samaa vauhtia: kouluttaja (joka päivittää mallin painot) ja rollout-moottori (joka generoi mallin vastauksia ympäristössä). Jos näiden kahden välinen “totuus” alkaa ajautua erilleen, koulutuksen tulokset huononevat hiljaa ja salakavalasti. ServiceNow AI -tiimin tuore kirjoitus kertoo, miten he ratkaisivat juuri tämän ongelman päivittäessään vLLM-inferenssimoottorinsa versiosta 0.8.5 versioon 0.18.1.
Lähtökohta: kun uusi versio ei tuottanut samaa tulosta
Tiimi siirtyi vLLM:n vanhasta arkkitehtuurista (V0) uuteen V1-toteutukseen. Uusi versio oli huomattavasti nopeampi, mutta yksinkertainen vertailu paljasti ongelman: koulutuskäyrät erkanivat referenssinä toimineesta V0-versiosta. Häviö, KL-divergenssi ja palkkio kaikki kertoivat, että jotain oli pielessä.
Kiusaus oli ilmeinen: lisätään RL-tavoitteeseen korjaustermi, joka kompensoi eron. ServiceNow:n insinöörit valitsivat toisin — he päättivät korjata ensin moottorin oikeellisuuden ja vasta sitten harkita objektiivin tason muutoksia.
Neljä virhettä, jotka piilossa söivät tarkkuutta
Tiimi jäljitti eron systemaattisesti neljään lähteeseen.
1. Logprobien semantiikka muuttui. V1 palautti raakalogprobit ennen lämpötilaskaalausta, rangaistuksia ja top-k/top-p -suodatusta. V0 palautti käsitellyt logprobit. Korjaus: aseta logprobs-mode=processed_logprobs.
2. Ajoympäristön oletukset poikkesivat. V1 kytki oletuksena päälle prefiksivälimuistin ja asynkronisen ajoituksen. Välimuisti pystyi käyttämään uudelleen tilaa eri painopäivitysten välillä, mikä rikkoi RL-iteraatioiden välisen riippumattomuuden. Korjaus: poista nämä päältä eksplisiittisesti.
3. Painojen päivityspolku. V1:ssä painojen synkronointi rollout-moottoriin ei vastannut V0:n implisiittistä välimuistin invalidointimallia. Tiimi mittasi “lag”-arvon — kuinka vanhentuneilla painoilla rollout-moottori oikeasti generoi — ja huomasi sen pysyvän jatkuvasti korkeana. Korjaus: käytä tarkkoja pause_generation(mode="keep", clear_cache=False) -semantiikoita.
4. LM-pään tarkkuus oli liian matala. V1 laski lopullisen logit-projektion sekatarkkuudella, kun taas kouluttaja käytti fp32:ta. Pienet pyöristysvirheet kertautuvat policy-suhteiden ja KL-leikkauksen kautta näkyviksi koulutuseroiksi. Sama ilmiö on raportoitu MiniMax-M1- ja ScaleRL-tutkimuksissa. Korjaus: pakota fp32 LM-pään laskennassa.
Miksi tämä järjestys on tärkeä
Kun nämä neljä virhettä oli korjattu, V1-koulutuskäyrät asettuivat takaisin V0-referenssin päälle — kaikilla mittareilla: clip rate, KL, entropia ja palkkio. Lopullinen oppi ei ole pelkästään tekninen, vaan menetelmällinen.
Pinon pitää olla diagnoosissa kerroksittainen. Ensin: tarkoittavatko backendit logprobeillaan samaa asiaa? Sen jälkeen: kulkevatko samat kehotteet samaa polkua? Vasta sen jälkeen: pitääkö RL-tavoitteeseen lisätä korjaustermi?
Jos järjestys käännetään ja objektiivin tasolla yritetään paikata infrastruktuurin virheitä, tuloksena on sotketut kokeet: et tiedä, korjaako uusi termi oikeaa ongelmaa vai vain peittääkö virhettä, joka ilmenee jossain muualla myöhemmin.
Mitä tämä tarkoittaa muille tiimeille
Sama opetus pätee laajasti tekoäly-infrastruktuuriin:
Migraation tavoite kannattaa pitää kapeana. Kun siirryt vanhasta järjestelmästä uuteen, älä yritä samalla parantaa metodologiaa. Varmista ensin, että uusi pino tuottaa saman tuloksen kuin vanha — vasta sen jälkeen lisää uusia ominaisuuksia.
Mittaa lag, älä vain palkkio. RL-koulutuksessa on helppo katsoa pelkkää palkkiokäyrää ja olettaa että kaikki on hyvin. ServiceNow:n tapaus näyttää, että hienovaraiset versiomuutokset voivat tehdä koulutuksesta hitaampaa tai epävakaampaa ilman että lopullinen palkkio paljastaisi syytä.
fp32-pää on käytännössä pakollinen. Pienet logit-pyöristysvirheet kertautuvat RL-pinossa nopeasti merkittäviksi. Jos koulutus käyttää fp32:ta, myös rollout-moottorin pää kannattaa.
Yhteenveto
ServiceNow AI:n kirjoitus on harvinaisen rehellinen kuvaus siitä, mitä tapahtuu, kun “saman näköinen päivitys” rikkoo asioita hiljaa. Sen ydinviesti on yleistettävissä paljon vLLM:ää laajempaan kontekstiin: älä lisää korjauksia rikkinäisen pohjan päälle. Korjaa ensin se, mihin nojaat — vasta sen jälkeen rakenna uutta sen päälle.
Tekoälyn infrastruktuuri muuttuu nopeasti, ja jokainen kerros kutsuu lisää abstraktioita. Tämä artikkeli muistuttaa, että jokainen abstraktio on lupaus oikeellisuudesta — ja se lupaus on aina syytä mitata, ei olettaa.
Lähteet: