GitHub:n tuotejohtaja Mario Rodriguez sanoi VentureBeatille, että oikean mallin valitseminen on tekoälytyökaluissa jo pelkkää perustasoa. Yhtiön perjantaina 4. syyskuuta julkistama HydraFusion yrittää siksi vastata toiseen kysymykseen: millä tavalla pyyntö kannattaa ratkaista.
Käytännössä järjestelmä valitsee jokaiselle koodauspyynnölle yhden kolmesta työtavasta. Yksinkertaisimmassa yksi malli tekee työn suoraan. Kaskadissa halvempi malli luonnostelee vastauksen ja laatuportti päättää, riittääkö se vai siirretäänkö tehtävä kalliimmalle mallille. Kritiikkitavassa toinen malli lukee ensimmäisen työn läpi ja alkuperäinen korjaa sen palautteen perusteella.
Kolmas tapa maksaa aina kahdesti.
“Reitittäminen oikealle mallille on nopeasti muuttumassa perusvaatimukseksi, mutta HydraFusion on erilainen siinä, että se vastaa kysymykseen ”mikä on paras tapa ratkaista tämä tehtävä” eikä kysymykseen ”minkä mallin pitäisi hoitaa tämä tehtävä”.”
Reititys on triagea, kaskadi on hoitokokeilu
Päivystyksessä potilas ei mene suoraan erikoislääkärille. Hoitaja arvioi ensin kiireellisyyden ja ohjaa eteenpäin, ja arvio kestää minuutteja siinä missä hoito tunteja. Mallien reitityksessä tehdään sama liike: pieni ja halpa luokitin katsoo pyynnön ja arvioi, kuinka vaikea se on.
HydraFusionin pohjalla oleva HyDRA-tutkimus kuvaa arvion tarkasti. ModernBERT-pohjainen luokitin antaa pyynnölle neljä erillistä pistemäärää: päättely, koodin kirjoittaminen, virheenjäljitys ja työkalujen käyttö. Sen jälkeen algoritmi valitsee halvimman mallin, joka yltää jokaisessa vaadittuun tasoon. Arvio kestää tutkimuksen mukaan tyypillisesti 86 millisekuntia tavallisella prosessorilla.
Kaskadi on eri asia kuin reititys, vaikka sanat menevät usein sekaisin. Reitityksessä päätös tehdään ennen työtä. Kaskadissa halpa malli tekee työn ensin, ja vasta tulos ratkaisee, tarvitaanko kalliimpaa. Päivystysvertaus jatkuu luontevasti: ensin kokeillaan särkylääkettä, ja jos kipu ei hellitä, potilas menee kuvantamiseen.
Halvempi joka testissä, yhtä hyvä vain yhdessä
GitHub vertasi HydraFusionia Claude Opus 5:n ja GPT-5.6 Solin varaan rakennettuihin verrokkeihin kolmessa koodausvertailussa. TerminalBench 2.1:ssä laatu parani 4,9 prosenttiyksikköä ja kustannukset laskivat 67 prosenttia. CheckpointBenchissä kulut putosivat 65 prosenttia, mutta laatu jäi 0,1 prosenttiyksikköä verrokista. DeepSWE:ssä säästö oli pienin, 36 prosenttia, ja laatu jäi 1,5 prosenttiyksikköä jälkeen.
Tulos on siis juuri se, mitä otsikko lupaa. Halvempi kaikissa, vähintään yhtä hyvä yhdessä. Järjestelmä on saatavilla tutkimusesikatseluna Copilot CLI:ssä /experimental-lipun takana, ja käyttö laskutetaan kunkin mallin normaalilla token-hinnalla.
Mistä tämän jutun luvut tulevat
Lähdeketju on lyhyt. Tarkistettuja lähteitä on viisi, mutta GitHub:sta riippumattomia niistä yksi: VentureBeatin uutinen. Kaikki vertailuluvut ovat GitHub:n omasta testauksesta, eikä ulkopuolinen taho ole toistanut mittauksia.
Taustalla oleva HyDRA-artikkeli on Microsoftin omien tutkijoiden kirjoittama, joten sekään ei ole riippumaton vahvistus. GitHub:n julkisessa changelogissa ei 7. syyskuuta ollut merkintää HydraFusionista, eikä Copilot CLI:n dokumentaatio mainitse /experimental-lippua. Julkistuksen yksityiskohdat lepäävät siis toistaiseksi yhden riippumattoman lähteen varassa.
Missä säästö muuttuu laatutappioksi
Kaskadin talous on yksinkertainen. Jos halpa malli riittää, pyyntö maksaa murto-osan. Jos se ei riitä, maksetaan sekä halvan mallin turha yritys että kalliin mallin oikea vastaus. Kehittäjä Awan Farz tiivisti asian VentureBeatille englanniksi: ”Maksat halvasta mallista jokaisella kaskadipyynnöllä.”
Säästö kääntyy tappioksi siinä kohdassa, jossa laatuportti erehtyy. Portti voi olla liian tiukka, jolloin turhia eskalaatioita kertyy ja säästö sulaa. Se voi olla myös liian löysä, ja silloin läpi menee vastaus, joka näyttää oikealta mutta ei ole. DeepSWE:n 1,5 prosenttiyksikköä tarkoittaa käytännössä, että sadasta tehtävästä puolitoista ratkeaisi verrokilla mutta ei HydraFusionilla.
Kuka sen huomaa? Ei kehittäjä siinä hetkessä, koska heikko vastaus on uskottavan näköinen. Virhe tulee vastaan koodikatselmoinnissa, testiajossa tai pahimmillaan tuotannossa, ja siihen mennessä säästetyt sentit ovat jo kirjautuneet laskuun. Yritykselle, joka ostaa satoja Copilot-lisenssejä, kahden kolmasosan pudotus token-kuluissa on isoa rahaa. Vastapainona on riski, joka ei näy laskulla vaan katselmoijien työmäärässä.



