Viime vuodet AI-mallien kilpailu on näyttänyt melko suoraviivaiselta. OpenAI julkaisee uuden GPT-mallin, Anthropic vastaa Claudella, Google tuo uuden Geminin, avoimet mallit kirivät perässä ja käyttäjät vertailevat benchmarkeja, hintoja ja kontekstin pituutta.

Nyt rinnalle alkaa nousta toinen kilpailu.

Kuka osaa käyttää useita malleja parhaiten yhdessä?

Sakana AI:n Fugu ja OpenRouterin Fusion näyttävät samaan suuntaan. Käyttäjälle tarjotaan yksi API tai yksi mallinimi, mutta taustalla työ ei välttämättä synny yhden mallin suorana vastauksena. Mukana voi olla useita malleja, erillisiä rooleja, rinnakkaisia vastauksia, tarkistuksia ja arvioiva judge-malli.

Orkestrointimalli on malli tai järjestelmä, jonka päätehtävä on ohjata muita malleja.

Perinteinen mallireititys valitsee usein yhden mallin. Jos pyyntö on halpa ja yksinkertainen, käytetään pientä mallia. Jos pyyntö on vaikea, käytetään suurempaa mallia. Tämä on hyödyllistä, mutta edelleen melko yksinkertaista: yksi pyyntö menee yhdelle mallille.

Orkestrointi menee pidemmälle. Järjestelmä voi jakaa työn eri rooleihin, pyytää useaa mallia vastaamaan rinnakkain, tarkistaa vastaukset toisella mallilla, etsiä ristiriitoja ja koota lopullisen vastauksen usean lähteen perusteella.

Hyvä vertaus on toimitusprosessi.

Yksi henkilö voi kirjoittaa jutun alusta loppuun. Toinen tapa on käyttää tutkijaa, kirjoittajaa, faktantarkistajaa ja päätoimittajaa. Lopputulos voi olla hitaampi ja kalliimpi, mutta vaikeassa tehtävässä se voi olla luotettavampi.

Sama ajattelu on tulossa kielimalleihin.

Sakana AI kuvaa Fugu-tuotettaan lauseella “One Model to Command Them All”. Sen sivuilla Fugu esitellään “multi-agent system as a model” -ajatuksella. Käyttäjä kutsuu yhtä OpenAI-yhteensopivaa API:a, mutta taustalla Fugu koordinoi useita malleja ja agentteja.

Sakanan mukaan Fugu kokoaa eri malleja tehtäväkohtaisesti ja koordinoi niiden yhteistyötä. Se ei perustu vain siihen, että ihminen suunnittelee ennalta jokaisen roolin ja työnkulun. Sakanan omassa kuvauksessa järjestelmä oppii kokoamaan agentteja poolista ja käyttämään yhteistyökuvioita, joita ihminen ei välttämättä keksisi käsin.

Fugusta on kaksi versiota: Fugu ja Fugu Ultra. Fugu on tarkoitettu tasapainottamaan suorituskykyä ja latenssia esimerkiksi koodaukseen, koodikatselmointiin ja responsiivisiin chatbotteihin. Fugu Ultra painottaa laatua vaikeissa, monivaiheisissa tehtävissä. Sakanan mukaan sitä on käytetty esimerkiksi Kaggle-kilpailuihin, paperien toistamiseen, kyberturvallisuusanalyysiin sekä patentti- ja kirjallisuusselvityksiin.

Tuote ei ole tällä hetkellä saatavilla EU/EEA-alueella. Sakanan sivun mukaan yhtiö työskentelee GDPR:n ja EU-alueen sääntelyn vaatimusten kanssa.

Fugu nojaa Sakanan mukaan kahteen ICLR 2026 -paperiin: TRINITYyn ja Conductoriin.

TRINITY on “evolved LLM coordinator”. Paperin mukaan siinä käytetään kevyttä koordinaattoria, jossa on noin 0,6 miljardin parametrin kielimalli ja noin 10 000 parametrin kevyt pää. Koordinaattori ohjaa useita LLM:iä usean vuoron ajan ja antaa niille eri rooleja: Thinker, Worker tai Verifier.

Ajatus on kiinnostava. Koordinaattorin ei tarvitse itse osata kaikkea. Sen pitää osata päättää, mikä malli ajattelee, mikä tekee ja mikä tarkistaa.

Conductor-paperissa ajatus viedään toiseen suuntaan. Siinä malli opetetaan vahvistusoppimisella löytämään luonnollisen kielen koordinointistrategioita eri agenttien välille. Se voi suunnitella, miten agentit keskustelevat keskenään ja millaisia täsmäohjeita niille annetaan.

Suurin idea on tämä: agenttien työnjakoa ei tarvitse rakentaa vain käsin kirjoitetuilla säännöillä. Sitä voidaan myös oppia.

Tämä voi kuulostaa tekniseltä yksityiskohdalta, mutta sillä on iso käytännön merkitys. Moni yritys rakentaa nyt agenttijärjestelmiä, joissa ihmiset kirjoittavat käsin roolit: suunnittelija, toteuttaja, testaaja, tarkistaja, raportoija. Jos koordinointia opitaan datasta ja palautteesta, tulevaisuuden agenttijärjestelmät voivat parantaa työnjakoa itse.

Sakana Fugu ei ole ainoa esimerkki tästä suunnasta. OpenRouterin Fusion toimii samalla perusidealla, vaikka toteutus on erilainen.

OpenRouter Fusionia käytetään mallislugeilla openrouter/fusion. OpenRouter kuvaa sitä “multi-model deliberation as a model slug” -ratkaisuna.

Käytännössä Fusion antaa mallille pääsyn multi-model deliberation -työkaluun. Kun sitä käytetään, paneeli malleja vastaa promptiin rinnakkain. Sen jälkeen judge-malli vertailee vastaukset ja palauttaa rakenteisen analyysin.

Analyysi sisältää esimerkiksi:

Lopullinen vastaus kirjoitetaan tämän analyysin pohjalta.

OpenRouterin dokumentaation mukaan Fusionin paneeli- ja judge-kutsuilla on käytössä openrouter:web_search ja openrouter:web_fetch, joten mallit voivat hakea tuoreita lähteitä. Tämä tekee Fusionista erityisen kiinnostavan tutkimus-, vertailu- ja asiantuntijakritiikkitehtäviin.

OpenRouter itse suosittelee Fusionia tilanteisiin, joissa yksittäinen malli ei riitä: tutkimuskysymykset, asiantuntijakritiikki, “compare and contrast” -tyyppiset tehtävät ja tilanteet, joissa väärän vastauksen hinta on suurempi kuin muutaman lisämallikutsun kustannus.

Fugu ja Fusion kannattaa erottaa toisistaan.

Fugu on Sakanan tuotteistama mallirajapinta, jonka taustalla on opittua agentti- ja mallikoordinaatiota. Se pyrkii näyttämään käyttäjälle yhdeltä mallilta, vaikka taustalla toimii useamman agentin järjestelmä.

Fusion on OpenRouterin router- ja deliberation-kerros. Se antaa mallille työkalun, jolla useampi malli voidaan laittaa vastaamaan rinnakkain ja judge-malli voi analysoida niiden erot.

Yhteinen suunta on silti tärkeämpi kuin tekninen ero. Molemmat piilottavat käyttäjältä osan monimutkaisuudesta. Käyttäjä lähettää yhden pyynnön, mutta järjestelmä voi käyttää useita malleja ja työvaiheita ennen lopullista vastausta.

Tämä muuttaa yritysten AI-arkkitehtuuria.

Aiemmin yrityksen mallivalinta saattoi olla melko suora kysymys: käytetäänkö OpenAI:ta, Anthropiccia, Googlea, Mistralia, DeepSeekiä vai avoimia malleja omassa ympäristössä?

Orkestrointikerros muuttaa kysymyksen.

Nyt pitää kysyä myös:

OpenRouterin Fusion tekee tästä näkyvää kertomalla, että pyyntö hinnoitellaan taustalla ajettujen mallien mukaan ja että Activity-näkymästä voi katsoa, mitä malleja ajettiin. Sakanan Fugu puolestaan nostaa esiin mahdollisuuden rajata tiettyjä malleja tai tarjoajia pois perus-Fugun poolista. Fugu Ultrassa pooli on Sakanan FAQ:n mukaan kiinteä.

Tämä on hyvä esimerkki siitä, mihin AI-hankinta on menossa. Pelkkä “mikä malli on paras” ei riitä. Pitää ymmärtää myös ohjauskerros.

Orkestrointimallit voivat olla pienemmille AI-labeille ja SaaS-yrityksille kiinnostava mahdollisuus.

Kaikkien ei tarvitse kouluttaa omaa maailmanluokan perusmallia. Sen sijaan voi rakentaa paremman tavan käyttää olemassa olevia malleja.

Kilpailu voi siirtyä esimerkiksi näihin:

Sama näkyy jo agenttituotteissa. Moni käytännön AI-työkalu ei voita siksi, että sen taustamalli olisi paras mahdollinen. Se voittaa siksi, että työnkulku, muisti, työkalut, käyttöliittymä ja tarkistusvaiheet on rakennettu paremmin.

Monen mallin orkestrointi ei ole ilmainen parannus.

Ensimmäinen rajoite on kustannus. Jos yksi pyyntö ajaa viisi mallia ja yhden judge-kutsun, kustannus voi kasvaa nopeasti. Tämä voi olla järkevää vaikeassa tutkimustehtävässä, mutta turhaa yksinkertaisessa tiivistelmässä.

Toinen rajoite on latenssi. Rinnakkaisuus auttaa, mutta usean mallin vastaukset, arviointi ja lopullinen synteesi vievät silti aikaa.

Kolmas rajoite on läpinäkyvyys. Käyttäjä voi nähdä yhden API:n, mutta taustalla voi tapahtua paljon. Jos järjestelmä tekee virheen, pitää pystyä selvittämään, tuliko virhe alkuperäisestä mallivastauksesta, koordinaattorista, judge-mallista, web-haun lähteestä vai lopullisesta synteesistä.

Neljäs rajoite liittyy benchmarkeihin. Sakanan Fugu-sivulla on laaja benchmark-taulukko ja vahvoja tuloksia. Niitä kannattaa lukea tuotteen omana raportointina. Ne kertovat, mihin suuntaan järjestelmää on rakennettu, mutta artikkelin tai hankintapäätöksen pohjaksi tarvitaan myös riippumatonta käyttötestausta.

Jos yritys harkitsee Fugu-, Fusion- tai vastaavaa orkestrointiratkaisua, kannattaa kysyä ainakin nämä:

Viimeinen kysymys on tärkeä. Orkestrointi ei ole itseisarvo. Jos tehtävä on yksinkertainen, monen mallin prosessi voi olla hidas ja kallis tapa saada sama vastaus.

Mutta jos tehtävä on vaikea, kallis tai riskialtis, usean mallin vertailu ja tarkistus voi olla perusteltu investointi.

Yksittäiset mallit kehittyvät edelleen. Niiden konteksti pitenee, päättely paranee ja hinnat laskevat.

Silti käytännön työssä yhä useampi AI-järjestelmä alkaa muistuttaa tiimiä. Yksi osa suunnittelee, toinen hakee tietoa, kolmas kirjoittaa, neljäs tarkistaa ja viides kokoaa lopputuloksen.

Sakana Fugu ja OpenRouter Fusion ovat varhaisia merkkejä tästä suunnasta. Ne tekevät näkyväksi ajatuksen, jossa käyttäjä ei välttämättä valitse vain mallia. Hän valitsee ohjausjärjestelmän, joka käyttää malleja hänen puolestaan.

Tämä voi olla seuraava tärkeä kilpailualue: ei pelkkä mallin älykkyys, vaan mallien välinen työnjako.

AI:n seuraava iso käyttökerros voi löytyä mallien välistä.