Testasimme yhden markkinoiden keveimmistä kielimalleista agenttisessa työssä. Vertasimme Liquid AI:n LFM2.5-mallia Googlen Gemma 4 -malliin rajatussa testikehyksessä. Tulokset olivat toisaalta ennalta arvattavia: isompi malli tuottaa luotettavammin hyviä tuloksia. Toisaalta Liquid AI:n pieni malli toimi yllättävän hyvin, vaikka siinä on vain 2,6 miljardia parametria Gemma 4:n 25,2 miljardia vastaan.

Kielimallien omalla koneella ajamisen rajoitteet

Kielimallit ovat isoja, usein kymmeniä miljardeja liukulukuja, tai jopa biljoonia liukulukuja. Kaikki nämä luvut pitää ladata muistiin, jotta kielimalli voi toimia.

Ehdimme kaikki tottua ChatGPT:n käyttöön, jossa kaikki nämä laitteistovaatimukset on ulkoistettu OpenAI:lle. Heidän laitteistonsa ottavat vastaan käyttäjän ChatGPT:lle syöttämän tiedon: kuvat, tiedostot, lähdekoodin, ja prosessoivat sen kielimallia varten, ja lopuksi tuottavat kielimallin vastaukset ja "älyn" loppukäyttäjälle.

Viime aikoina markkinoille on enenevässä määrin tullut keskikokoisia malleja, joiden ajaminen ei vaadi kymmenien tuhansien eurojen sijoitusta laskentakapasiteettiin, tai ison serverifarmin vuokraamista. Aiemmin omalla työasemalla tai läppärillä kielimallin ajaminen oli mahdotonta, mutta tämä on muuttumassa. Googlen Gemma 4 -mallissa on 25,2 miljardia parametria, joista kerrallaan on aktiivisena vain 3,8 miljardia. Kvantisoituna sen painot vievät levyltä 26 gigatavua.

Reilu viikko sitten Liquid AI julkaisi LFM2.5-2.6B-mallin, joka pyörii käytännössä kaikilla moderneilla laitteilla, jopa älypuhelimella. Tämä malli ei juurikaan tiedä maailmasta, eikä se tue kovin suurta määrää kieliä, mutta se on optimoitu agenttisiin työnkulkuihin, ja niistä se suoriutuukin ällistyttävän hyvin, ottaen huomioon sen koon ja muistivaatimukset. Me ajoimme testit näiden kahden mallin välillä.

Muistin osalta ero ei kuitenkaan ole niin suuri kuin parametrimäärät antavat ymmärtää. Parametreissa suhde on noin kymmenen yhteen, ajonaikaisessa muistissa vain noin neljä yhteen: konteksti- ja laskentapuskurit eivät pienene mallin mukana. LFM2.5:n 2,7 gigatavun painot tarvitsevat ajossa noin yhdeksän gigatavua muistia, ja Gemma 4:n 26 gigatavun painot noin 35 gigatavua. Pieni malli on silti niin halpa pitää muistissa, ettei sen paikallaan pitämisestä tarvitse juuri neuvotella.

Mihin 2,6 miljardin parametrin kielimalli pystyi?

Teimme tarkkaan kontrolloidun vertailun tehtävässä, jossa agentit joutuivat etsimään tietoa verkosta. Tyypillisesti tämä vaatii paljon erilaisten työkalujen käyttöä: agentti tekee verkkohakuja, lukee sisältöä verkosta, tekee muistiinpanoja, tekee lisää hakuja ja niin edelleen, ilman että agentti pysähtyy työn aikana. Tätä toistuvaa hakemisen, lukemisen ja uuden haun kierrosta kutsutaan työkalusilmukaksi. Tällaiset agenttiset ajot saattavat kestää jopa tunteja, ja tyypillisesti aiemmin pienemmillä kielimalleilla ajetut agentit eivät onnistuneet tällaisissa tehtävissä kovinkaan hyvin.

Ajoimme 29 kysymystä, jokaisen molemmilla malleilla ja kahteen kertaan, eli yhteensä 116 ajoa oikeaa tuotantoinfrastruktuuria vasten. Osa kysymyksistä oli tarkoituksella sellaisia, joihin verkosta ei juuri löydy vastausta. Ne olivat ansoja: halusimme nähdä, keksiikö malli lähteen silloin, kun sellaista ei ole.

LFM2.5-2.6B Gemma 4 (26B)
Parametreja 2,6 mrd 25,2 mrd (3,8 mrd aktiivisena)
Painot levyllä 2,7 Gt 26 Gt
Muistin tarve ajossa noin 9 Gt noin 35 Gt
Generointinopeus noin 71 t/s noin 41 t/s
Keksittyjä lähdeosoitteita 0 0
Toimimattomia linkkejä 3 % 1 %
Lähdeviitteitä raporttia kohti 2,5 3,3
Lähdeviite kesti tarkistuksen 51 % 33 %
Raportteja, joissa toimiva lähde 66 % 81 %
Tehtävän keskimääräinen kesto 104 s 107 s

Ansat eivät lauenneet kummallakaan mallilla. 116 ajossa pieni malli ei keksinyt yhtäkään lähdeosoitetta, ei yhtäkään verkkotunnusta, jota ei ole olemassa. Kielimallin hallusinointi, jota organisaatioissa usein pelätään, ei esiintynyt tässä lainkaan.

Myös perusmekaniikka toimi. LFM2.5 oli ollut samassa tehtävässä tuotantokäytössä noin kahden ja puolen vuorokauden ajan ennen varsinaista testiä, ja sinä aikana se käsitteli 1,46 miljoonaa tokenia. Yksikään työkalukutsu ei mennyt pieleen, eikä yksikään vastaus tullut ulos rikkinäisessä muodossa.

Tämä on isompi asia kuin miltä se kuulostaa. Agentin pitää muotoilla jokainen työkalukutsu täsmälleen oikein, tai koko ketju katkeaa kesken tehtävän. Juuri tämä on ollut pienten mallien perinteinen kompastuskivi, ja se näyttää nyt ratkaistun.

Miksi nopeampi malli ei ollut nopeampi

Pienen mallin ilmeisin etu on nopeus, ja se on mitattavissa: LFM2.5 tuottaa tekstiä noin 71 tokenia sekunnissa, Gemma 4 noin 41. Odotimme, että ero näkyisi lopputuloksessa. Ei näkynyt: tehtävän keskimääräinen kesto oli pienellä mallilla 104 sekuntia ja isolla 107 sekuntia.

Syy on siinä, mihin aika agenttisessa työssä oikeasti kuluu. Kun agentti tekee verkkohaun, se odottaa hakukoneen vastausta. Kun se lukee sivun, se odottaa sivun latautumista. Näitä odotusjaksoja kertyy yhden tehtävän aikana kymmeniä, ja ne ovat sekuntien mittaisia. Mallin oma tekstintuotto on tässä kokonaisuudessa pieni erä. Verkko määrää tahdin, ei malli.

Tällä on suora käytännön seuraus. Jos harkitset agenttista työnkulkua vaatimattomammalla laitteistolla, hitaampi kielimalli ei välttämättä tarkoita hitaampaa lopputulosta. Suosittelemme kokeilemaan ja mittaamaan sekä nopeuden että laadun omassa käyttötapauksessanne, ennen päätöksiä infrastruktuurivaatimuksista.

Mitä pieni malli jätti tekemättä

Pieni malli ei siis keksinyt lähteitä. Se teki jotain muuta, ja se kannattaa ymmärtää tarkasti, koska tämä virhetyyppi on selvästi hankalampi havaita.

Pitkien työkalusilmukoiden loppupäässä, vaikeimmissa kysymyksissä, LFM2.5 jätti lähteet merkitsemättä. 58 raportista 20:ssa ei ollut yhtäkään lähdeosoitetta. Raportit olivat hyvin muotoiltuja, sujuvasti kirjoitettuja ja itsevarmoja. Niitä ei vain voinut tarkistaa mitenkään.

Ero hallusinointiin on olennainen. Keksityn lähteen huomaa heti, koska osoitetta ei ole olemassa. Lähteetön raportti läpäisee minkä tahansa faktantarkistuksen, koska tarkistettavaa ei ole.

Kumpikaan malli ei täyttänyt vaatimustamme. Edellytimme jo ennen testin ajamista, että vähintään 95 prosentissa raporteista on yksi toimiva lähdeviite. Gemma 4 ylsi 81 prosenttiin ja LFM2.5 66 prosenttiin. Ero on todellinen, mutta molemmat jäivät saman rajan alle.

Kiinnostavin yksityiskohta on kuitenkin tämä: kun LFM2.5 merkitsi lähteen, merkintä kesti tarkistuksen useammin kuin kymmenen kertaa suuremmalla mallilla, 51 prosentissa tapauksista vastaan 33 prosenttia. Kyky perustella vastaus todelliseen lähteeseen on siis olemassa jo tässä kokoluokassa. Se, mikä rapautuu pitkän tehtävän aikana, on kurinalaisuus tehdä se joka kerta.

Suunnittelun kannalta tämä on olennainen huomio. Kurinalaisuutta ei välttämättä kannata yrittää korjata isomman mallin käytöllä, vaan työnkulun rakenteella: tarkemmilla ohjeilla ja automaattisella tarkistuksella, joka hylkää lähteettömän raportin ja pyytää agenttia tekemään työn uudelleen antaen agentille tarkemmat ohjeet kuin edellisellä kerralla.

Johtopäätöksemme

Tämän testin perusteella emme antaisi LFM2.5:lle valvomatonta tutkimustyötä sellaisenaan. Määrittelimme testiasetelman etukäteen, jotta tulos olisi luotettava.

Tavallisen työaseman tehokkuus ja muisti eivät silti ole enää este oman kielimallin ajamiselle. Eikä LFM2.5 ole ainoa vaihtoehto: esimerkiksi Bonsain 1-bittiset mallit ovat ajettavissa lähes millä tahansa modernilla laitteella. Tässä testaamamme LFM2.5 hoiti agenttityön perusasiat moitteetta: työkalukutsut menivät läpi virheittä, lähteitä se ei keksinyt, eikä nopeudesta tarvinnut tinkiä. Jos regulaatio, sopimukset tai tietosuoja edellyttävät datan pysymistä omassa hallinnassa, lähtökohta on selvästi parempi kuin muutama vuosi sitten.

Yhtä asiaa emme tässä mitanneet lainkaan: energiankulutusta. LFM2.5 tekee saman työn murto-osalla Gemma 4:n laskennasta, joten se todennäköisesti voittaa vertailun päästöissä selvästi. Kuinka selvästi, sen ratkaisee vasta seuraava testi.

Kielimallit eroavat toisistaan, ja valinta sitoo organisaation pidemmäksi aikaa kuin moni ajattelee. Työnkulku viritetään aina käytössä olevan mallin varaan: ohjeistus, työkalujen käyttötavat ja ne erikoisuudet, jotka on opittu kiertämään. Kun malli vaihtuu, työn jälki muuttuu, tai ainakin tapa, jolla se syntyy. Siksi riittävyys kannattaa mitata juuri siinä tehtävässä, johon mallia ollaan ottamassa, eikä valmistajan ilmoittamien lukujen perusteella.

Trail Openersilla autamme organisaatioita valitsemaan tekoälyarkkitehtuurin, joka vastaa sekä vaatimustenmukaisuuden tarpeita että käytettävissä olevaa laitteistoa. Haluatko tietää, riittääkö malli, jonka voitte oikeasti ajaa, teidän käyttötapaukseenne? Ota yhteyttä, niin selvitämme sen yhdessä.