Agenttipohjainen tekoäly törmää infrastruktuurin asettamaan seinään ennen älykkyyden rajaa

Mallit kehittyvät nopeammin kuin kykymme palvella niitä niiden vaatimalla tavalla.

Suurin osa keskustelusta tekoälyagenttien tulevaisuudesta koskee niiden kyvykkyyttä. Pystyykö malli suunnittelemaan luotettavasti? Pystyykö se korjaamaan omat virheensä? Voiko sille uskoa toimia, joilla on seurauksia?

Nämä ovat aiheellisia kysymyksiä. Ne eivät kuitenkaan ratkaise sitä, otetaanko agentteja laajasti käyttöön lähivuosina, sillä vastaan tulee lähempänä oleva rajoite — ja se lähestyy nopeasti. Agenttien tarjoaminen on taloudellisesti hankalaa, ja haaste kasvaa juuri niiden ominaisuuksien myötä, joita kaikki haluavat lisätä.

Keskustelubotti ja agentti ovat erilaisia kuormia

Keskusteleva pyyntö on yksi edestakainen kierros: kehote sisään, tokenit ulos ja yhteys poikki. Pyyntöjä voi käsitellä erissä, kehotteen alkuosan voi tallentaa välimuistiin, ja suorituskykyä voi arvioida yhden luvun perusteella.

Agenttipyyntö on istunto. Agentti kutsuu työkalua, odottaa, lukee tuloksen, päättää, mitä tekee seuraavaksi, kutsuu toista työkalua ja vastaa lopulta. Kohtuullisen yksinkertainen tehtävä voi vaatia kuusi tai kahdeksan mallikutsua, joiden välissä odotetaan.

Tällä erolla on merkitystä syystä, jolla ei ole mitään tekemistä älykkyyden kanssa. Vaiheiden välillä agentti ylläpitää tilaa — keskustelua, työkalujen tuloksia ja kertynyttä päättelyä. Mallin tarjoamiseen käytettävässä järjestelmässä tämä tila sijaitsee näytönohjaimen muistissa KV-välimuistina, ja se varaa muistia koko istunnon ajaksi, myös niinä sekunteina, kun agentti odottaa ulkopuolisen API:n vastausta.

Kapasiteetin mittayksikkönä ei siis enää ole ”pyyntöä sekunnissa”, vaan ”muistissa samanaikaisesti olevia istuntoja”. Järjestelmä, joka pystyi käsittelemään vaivatta tuhat keskustelupyyntöä sekunnissa, saattaa samoilla laitteilla pystyä palvelemaan vain muutamia kymmeniä agentti-istuntoja samanaikaisesti.

Odottaminen on kallis osa

Tässä on ongelman kiusallinen piirre: työkalukutsun aikana agentti ei tee mitään. Tokeneita ei tuoteta, eikä laskentatehoa käytetä. Näytönohjaimen muisti on silti varattuna, sillä kontekstin poistaminen muistista ja laskeminen uudelleen maksaisi enemmän kuin sen säilyttäminen.

Kallein laitteistosi on varattuna pyynnölle, joka juuri sillä hetkellä odottaa tietokantakyselyn tulosta.

Perinteisissä hajautetuissa järjestelmissä tämä ratkaistiin jo kauan sitten: resurssi vapautetaan ja työntekoa jatketaan vastauksen saavuttua. Mallien tarjoamisessa vastaava menettely tarkoittaa KV-välimuistin siirtämistä isäntäkoneen muistiin tai levylle ja sen palauttamista. Siirto maksaa niin paljon, ettei useimmissa järjestelmissä vaivauduta siihen. Tutkimusta juuri tästä aiheesta tehdään parhaillaan, koska ongelma on kallis.

Peräkkäinen suoritus tekee tilanteesta tarpeettoman hankalan

Lähes kaikki agenttikehykset suorittavat työkalukutsut peräkkäin. Malli pyytää hakemaan säätiedot, saa ne, pyytää tarkistamaan kalenterin, saa tiedot, pyytää etsimään lentoja ja saa tulokset.

Usein näillä kolmella kutsulla ei ole mitään riippuvuuksia toisistaan. Ne olisi voitu suorittaa samaan aikaan. Peräkkäin suoritettuna viiveet lasketaan yhteen; samanaikaisesti suoritettuna kokonaisviive vastaa pisintä niistä.

Tämä ei ole uusi havainto agenteista, vaan sama rakenteellinen periaate pätee kaikkiin järjestelmiin, joissa useita malleja tai palveluita suoritetaan yhden viivebudjetin puitteissa. Kokonaisviiveen pitäisi vastata riippuvuusgraafin pisintä polkua, ei kaikkien vaiheiden viiveiden summaa. Tämä on agenteille erityisen tärkeää siksi, että istunto pysyy näytönohjaimen muistissa koko suorituksen ajan. Siksi kuluneen ajan lyhentäminen ei ainoastaan paranna käyttökokemusta, vaan kasvattaa suoraan sitä, kuinka monta istuntoa laitteisto pystyy käsittelemään.

Kun istunnon kesto puolitetaan, samanaikainen kapasiteetti lähes kaksinkertaistuu samoilla näytönohjaimilla ilman muutoksia malliin.

Uudelleenyritykset kasaantuvat ennakoimattomalla tavalla

Agenttikehykset perivät uudelleenyritysten oletusasetukset niiden alla toimivilta HTTP-kirjastoilta. Tavallisesti yrityksiä on kolme.

Malli yrittää myös uudelleen omalla tavallaan. Kun työkalun tulos ei auta, päättelymalli kokeilee usein toista lähestymistapaa — eli yrittää uudelleen, vaikka kukaan ei ole määrittänyt tällaista asetusta.

Kun nämä yhdistetään, kolmen yrityksen käytäntö ja malli, joka päätyy itsenäisen päättelynsä kautta kokeilemaan kolmea muuta lähestymistapaa, muodostavat yhdeksän yrityksen käytännön, jota kukaan ei ole kirjannut. Jokainen yritys on täysimittainen mallikutsu, joka kuluttaa omat tokeninsa ja näytönohjaimen aikansa.

Kun riippuvuus hidastuu, tämä kerrannaisvaikutus muuttaa häiriön käyttökatkoksi. Yhden yrityksen kustannukset ovat tällöin useita kertaluokkia suuremmat kuin uudelleen yritetyn REST-kutsun.

Miltä seinä oikeastaan näyttää

Kyse ei ole kyvykkyyden ylärajasta, vaan arkisemmasta ongelmasta: yksikkötaloudellisesta kannattavuudesta, joka pysäyttää hankkeita pilottivaiheen ja tuotantokäytön välille.

Pilotti toimii. Käyttäjiä on kymmenen, viive on hyväksyttävä ja lasku on pyöristysvirhe. Sitten joku laskee kustannukset kymmenelle tuhannelle käyttäjälle, ja tarvittava näytönohjainten määrä vaikuttaa epärealistiselta — ei siksi, että malli olisi hidas, vaan koska kukin samanaikainen istunto varaa muistia koko kestonsa ajaksi, ja kestoon kuuluu myös odottaminen.

Tässä vaiheessa monet lupaavat sisäiset demot hiljalleen pysähtyvät.

Miten pullonkaulaa voidaan siirtää

Ei mitään eksoottista, vaan pelkkää infrastruktuuria mallinnuksen sijaan:

Suorita toisistaan riippumattomat työkalukutsut samanaikaisesti. Tämä on suurin yksittäinen hyöty, joka on saatavilla jo nyt eikä vaadi uutta laitteistoa.

Käytä istunnon kestoa kapasiteetin mittarina. Älä mittaa tokeneita sekunnissa. Älä mittaa näytönohjaimen käyttöastetta. Mittaa sitä, kuinka kauan tila pysyy muistissa ja kuinka monta istuntoa sinne mahtuu.

Mitoita uudelleenyritykset koko järjestelmälle, älä yksittäisille kutsuille. Yleinen yläraja – uudelleenyritysten pitäminen pienenä prosenttiosuutena kaikesta liikenteestä – estää edellä kuvatun kasautuvan vaikutuksen. Googlen SRE-käytännöt ylikuormitustilanteiden hallinnasta ja Envoyn uudelleenyritysbudjetit toteuttavat molemmat tätä ajatusta tekoälypinon ulkopuolella.

Erota päättely suorittamisesta. Käytä suunnitteluun suurta mallia ja mekaanisiin vaiheisiin paljon pienempää mallia. Suurin osa agentin tekemästä työstä ei vaadi huipputason mallia.

Tee kontekstin poistamisesta edullista. Käytä kvantisoitua KV-välimuistia, sivutettua huomiomekanismia sekä siirtomenetelmiä toimettomille istunnoille. Juuri tällä alueella tehdään nyt kiinnostavinta työtä päättelyn ajopalveluiden parissa.

Mallit kehittyvät edelleen. Tämä vaikuttaa varmalta. Se, tuleeko agenteista infrastruktuuria vai jäävätkö ne demoiksi, riippuu vähemmän näyttävästä asiasta: pystymmekö palvelemaan kuormaa, joka pitää kallista muistia varattuna odottaessaan, ja lopetammeko sekvenssin kaikkien vaiheiden yhteenlasketun ajan maksamisen silloin, kun voisimme maksaa vain sen pisimmän rinnakkaisen suorituspolun ajasta.

Julkaisin viimeksi mainitun ajatuksen taustalla olevan suoritusmallin – toisistaan riippuvaisten mallikutsujen samanaikaisen suorittamisen yhden viivebudjetin puitteissa – artikkelissa ”Asynkroninen päättelygraafin suoritus mallien reitityksessä koneoppimisjärjestelmissä”, International Journal of Computer Trends and Technology 72(10), lokakuu 2024. Generatiivisten mallien integroinnista erityisesti viiveherkkiin päätöksentekojärjestelmiin voit lukea artikkelista ”LLM-malleilla täydennetyt kaupankäynti- ja päätöksentekoalustat: generatiivisen älykkyyden yhdistäminen taloudellisiin päätöksentekojärjestelmiin”, Journal of Information Systems Engineering and Management 11(1s), 2026.