Tim O’Brien szerint a tokenek könnyen számszerűsíthetők és a számlán is megjelennek, de ez önmagában nem árul el semmit arról, hogy az adott AI-munkaterhelés értéket hozott-e. A tokenek számolása hasznos lehet, de ha ez alapján mérünk teljesítményt vagy értéket, könnyen tévútra vezethetünk — különösen, ha valaki az egyéni tokenfogyasztást személyes termelékenység vagy siker mérőszámaként kezdi használni.
A költségkép és a célnélküliség problémája
A számla megmutatja, hány tokent használt egy rendszer, milyen modelleket hívt és ezek mennyibe kerültek. Amit viszont nem mutat meg, az az, hogy a rendszer elérte-e azt, amiért érdemes volt fizetni. Ez a jelenség az "AI-hangover" mögötti valóság: látható költés, de ismeretlen üzleti haszon.
Párhuzam az adatbázisokkal: a mérés nem helyettesíti a kontextust
A FinOps történetében mindig is volt egy vakfolt az adatbázisok körül. Tudjuk mérni a tárolást, a számítási kapacitást, a lekérdezéseket vagy a másolatokat, de ezek a számok önmagukban nem mondják meg, mire szolgál az adatbázis, miért úgy tervezték, és indokolt-e a költsége. Ugyanez igaz az AI-ra: egy drága komponens lehet teljesen fölösleges, de lehet egy kritikus tranzakciós út része is, amely magas rendelkezésre állást és alacsony késleltetést igényel.
Miért nem válthatóak fel a tokenek egymással
A tokenek különböző modellek esetében nem egyenértékűek: más-más „pénznemet” mérnek. Egy nap alatt több száz dollárt el lehet költeni AI-feladatra, de nincs általános módja eldönteni, ez drága-e anélkül, hogy tudnánk, mit próbál meg a rendszer elérni. Egy kódíró ügynök, amely órákat vált ki mérnöki munkából; egy egyszerű osztályozó, amely alacsony értékű dokumentumokat szortíroz; vagy egy koordinátor, amely tucatnyi leszármazott feladatot hangol össze — mind ugyanazt a napi számlát eredményezheti, de gazdaságilag nem összehasonlíthatók.
A "tokenomics" korlátai és a FinOps riasztó iránya
A tokenalapú elszámolás látható és mérhető, ezért van helye a riportokban. Azonban a tokenekre épített név ("tokenomics") nem tölti be a hiányzó kontextust. Nem elég belépni egy céghez, megnézni a tokenfogyasztást, majd kijelenteni: "Használjatok olcsóbb modellt" vagy "Használjatok Opust" — ez nem zárja le a problémát.
A FinOps piacán sok olyan szereplő van, aki épp ezt próbálja eladni: gyors, egyszerű optimalizációt tokenek alapján. Ez veszélyes, mert elrejti azokat a fontos kérdéseket, amelyek meghatározzák a költségek gazdaságosságát:
- Mit csinál a modell? (kódírás, dokumentumosztályozás, beszédfelismerés, ügynökkoordináció, emberi felülvizsgálatot igénylő döntések stb.)
- Egy olcsóbb modell több újrapróbálkozást (retry-t) eredményez-e?
- Csökkenti-e egy drágább modell a leszármazott munka mennyiségét?
- Mi történik, ha a modell hibázik?
Ezek a kérdések határozzák meg az „economics”-et; a tokenek egyenértékűségébe vetett hit tévút.
Modellek, rétegek és a teljes költségkép
Az AI-architektúrák rétegesednek: előfordulhat, hogy egy cég középső kategóriás modellt használ a koordinációra, egy frontier (élvonalbeli) modellt a nehéz feladatokra, helyi modellt érzékeny adatokra és specializált szolgáltatást beszédre. Egyes hívások tokenalapú számlázásúak, mások per perc, per felhasználó (seat) vagy lekérés alapon, sőt egy részük olyan hardveren futhat, amelyet a cég már birtokol.
Ez különösen fontossá válik olyan változások fényében, mint az iOS 27 kiadása és a lokális inference népszerűsödése: a jövőben a licencdíjak válhatnak nagyobb hangsúlyúvá, mint a tokenfogyasztás.
Gyakorlatias példák és mérlegelés
O’Brien konkrét példákat hoz: egy órányi fejlesztésen ráfordított 500 dollár egy Fable 5-hívásra lehet hasznos vagy pazarló — a döntéshez tudni kell, mit értünk el. Egy rendszer, amely felébred, átfésüli az e-mailt kulcsszavak után és megvizsgálja az időjárást, valószínűleg nem igényel 2 millió tokent OpenRouteren és egy Tavily-előfizetést; ilyen feladatra egy egyszerű Python-szkript is megfelelne, ami nem fogyaszt tokent.
Ha ügynökök hálózatát vezérlünk Hermes ügynökökkel, Pi-hámokkal vagy hasonló technológiákkal, megtanuljuk, hogy nem érdemes az egész folyamatot a legdrágább frontier-modellel futtatni — ez gyors bankrobbanáshoz (vagyis költségrobbanáshoz) vezethet. Egy milliárd token egyszerű feladatra Fable-en versus Luna-n vagy GLM-5.3-on sok tízezer dolláros hibát jelenthet. Nemcsak a modellválasztás számít, hanem a következtetési szint, a memória kezelése és az aggregálási stratégia is.
Mi a teendő? Kapcsoljuk össze a fogyasztást az üzleti eredménnyel
A következő lépés az AI költségkezelésében nem az, hogy elhagyjuk a token-mérést. Számoljuk a tokeneket. De a fogyasztást hozzá kell kötni a munkafolyamathoz, a végeredmény minőségéhez, az architektúrához és az üzleti kimenethez. A költségek értelmet nyernek csak akkor, ha a cél, a szerkezet és a hibák következményei ismertek.
O’Brien hangsúlyozza, hogy a FinOps közösségben hiányzik egy érdemi vita az "értékről" — mindenki a könnyű hatékonysági riportokat hajszolja, miközben a valódi kérdések megválaszolatlanok maradnak.
Mellékes megjegyzés: esemény és további források
A cikk említi az AI Codecon rendezvényt, amelyet hétfőn, augusztus 31-én tartanak: a téma az open-weight modellek, önállóan hosztolt stackek és az eszköztár lesz. Az IBM Research Gabe Goodhart előadása a helyi modellekre helyezett feladatok kiszervezéséről és az így elérhető költségcsökkentésről szól.
