Az első két évben, amióta a generatív mesterséges intelligencia (gen AI) bekerült a vállalati környezetbe, a legtöbb vállalat a hozzáférésre, a kísérletezésre és az alkalmazások bevezetésére koncentrált. Ahogy az ügynök‑alapú rendszerek élesednek, új kérdések kerülnek előtérbe: hogyan gondolkodjanak a vezetők olyan rendszerek gazdaságosságáról, amelyek költségei a használattal skálázódnak, nem csupán a felhasználók számával; és mi történik, ha információ, szoftver vagy akár kódolás is egyre inkább on‑demand, azonnal generált lesz? A döntés, hogy egy ügynököt széles körben bevezessenek, egyre inkább gazdasági kérdés, nem pusztán technikai.
Ezekről a témákról McKinsey Senior Partner Lari Hämäläinen David Tepperrel beszélt, a Pay‑i vezérigazgatójával és társalapítójával, aki az elmúlt három évben vállalati „agentic” rendszerek mérésére és gazdasági infrastruktúrájára épített megoldásokat. Tepper 19 évet töltött a Microsoftnál, ahol az Azure belső gen AI fogyasztási stratégiájáért is felelt, és van korai gen AI szabadalmi bejegyzése 2011‑ből.
A belső tapasztalat: mikor vált világossá a költségkülönbség a felhőhöz képest
Tepper elmondása szerint amikor a ChatGPT megjelent, ő az Azure belső gen AI fogyasztásának kezelését irányította. Osztályonként napi ~250 000 dolláros AI‑költségek és Excel‑alapú nyomon követés jellemezte a helyzetet. Egy egyszerű beavatkozással heti 300 000 dollár tartós megtakarítást jelentő lehetőséget talált — ez volt a felismerés pillanata: a gen AI pénzügyi dinamikája alapvetően különbözik a hagyományos felhőmodelltől. Míg a felhőnél a költség nagyjából előre tervezhető és új felhasználókkal lassan nő, a gen AI már az első hívástól fogyasztás‑alapú gazdaság.
A Pay‑i építése során további felismerés jött: bár a tokenárak csökkenhetnek idővel, a vállalatok rendszeresen növelték azt, amit a technológiától kértek, így a kimeneti összköltség nem feltétlenül csökkent. „A tokenek nem érték; a tokenek a számla. A számla megmutatja, mit költöttél, de nem azt, hogy érdemes volt‑e.” Ez a rés — a költés és a tényleges üzleti eredmény közötti hiány — az, amire a Pay‑i megoldásai fókuszálnak.
Miért fordulnak ma CFO‑k és CIO‑k Pay‑i‑hez?
Korábban mérnöki vezetők kértek költségmérést; ma egyre gyakrabban a CFO vagy a CIO jelentkezik azzal a problémával, hogy hogyan lehet igazolni a gen AI‑költségeket a vezetés felé. A gyorsan növekvő költségközpont menedzselése — talán a leggyorsabban növekvő vállalati költségcsoport az üzleti történelemben — komoly kihívást jelent.
Sok vállalat még nem építette ki azt a mérési architektúrát, amivel hiteles történetet lehet mesélni az igazgatóságnak. Elterjedt a „agent sprawl” (ügynök‑elterjedés): Copilot‑bevezetés, ügyfélszolgálati bot, több kódolási asszisztens és számos üzletági kezdeményezés, amelyekről a központi IT nem mindig tud. Gyakori jelenség, hogy mérnökök posztolják LinkedInen a 100 000 dolláros token‑számlákat mint büszkeségi jelet, de nincs egyértelmű mérés arról, mit hozott ez a vállalat számára.
A McKinsey tapasztalata szerint hat fő tényező hajtja az ügynök‑AI költségeit (a forrásoldali részletek az interjúban találhatók). Ugyanakkor sok telepítés valódi értéket állít elő — de gyakran nincs eszköz arra, hogy azt lássák és számszerűsítsék. Ez nem csak pénzügyi probléma: ha a mérnöki vezető nem tudja bizonyítani, hogy egy ügynök működik, nem tud védelmet adni egy roadmapnek vagy leállítani egy rossz prototípust.
A vállalatok már nem azt kérdezik elvontan, hogy „érdemes‑e az AI?”, hanem azt: „a 47 ügynököm közül melyik éri meg, és hogyan tudnám ezt megmondani?”.
Az ügynökök három kategóriája és miért számít ez
Tepper taxonómiája szerint fontos különbséget tenni:
- Workflow: hagyományos szoftver, amibe gen AI‑t illesztettek egy vagy több lépésnél. Hívásonként korlátos költség.
- Pipeline: előre meghatározott lépéssor, amely egy vagy több alkalommal meghív LLM‑et; a legtöbb chatbot ilyen. Korlátos a hívásszám alapján.
- Igazi agent: széles célt kap, rendelkezik eszközökkel és bemenetekkel, és futásidőben dönt arról, mit hívjon meg, milyen sorrendben és mennyi ideig. Kódolási asszisztensek a legelterjedtebb példák.
A különbség fontos, mert a költségek és az értékelés is másként viselkedik: egy igazi agent feladatonként gyakorlatilag korlátlan lehet, ezért ugyanarra a promptra akár 30‑szoros különbség is lehet az eredmények között. Emellett a hagyományos „LLM mint bíró” (LLM‑as‑judge) értékelés, amely referencia‑válaszokkal dolgozik, többnyire alkalmas workflow‑okra és pipeline‑okra, de megbukik az igazi agenteknél.
Miért bukik meg az „LLM‑as‑judge” az agenteknél?
Az LLM‑as‑judge módszer működik, ha fix bemenetek‑kimenetek és referencia‑válaszok léteznek. Az igazi agenteknél azonban a rendszerek futásidőben generálnak belső promptokat, több lépésben haladnak, és sokszor randomness (véletlenszerűség) épül be a folyamatba. Emiatt egy végső outputot pontozó bíró a rendszer legfontosabb részét — a döntési trajectory‑t — figyelmen kívül hagyhatja.
A gyakorlatban a tokenfogyasztás akár 30‑szoros szórást mutathat ugyanarra a promptra; a jel nagy része magában a trajectory‑ban lakik. Amikor egy ügynök hibázik, nem az utolsó lépésnél bukik meg, hanem három lépéssel korábban, és az utolsó lépés gyakran elfedi a korábbi hibákat. Ha csak a végső outputot pontozzuk, a „letakarást” minősítjük, nem a hibát.
A megoldás: a siker üzleti kimenetekhez való rögzítése. Ha egy agent eléri a definiált üzleti eredményt, akkor a teljes futás trace‑eiből ki kell nyerni a kulcsviselkedéseket, és ezekből egy folyamatosan karbantartott korpuszt építeni — akárcsak a jó prompt‑válasz adatbázisoknál. Ugyanezt meg kell tenni a sikertelen esetekkel, hogy lehetőség legyen kontra‑faktuális (counterfactual) hozadék‑hozzárendelésre. Mivel ugyanaz az agent ugyanazon input ellen holnap más trace‑t adhat, ez a korpusz folyamatos kurátort és verziózást igényel: prompt, modell és eszköz definíciókhoz kötve.
Az egyszerű képlet: mikor éri meg egy ügynök bevezetése?
Tepper egyszerű formulát javasol: egy ügynök értéket ad, ha a siker valószínűsége nagyobb, mint a verifikálás idejének és az elvégzés idejének aránya. Formálisan: P(siker) > T(verify) / T(do).
Konkrét példa: ha egy emberi feladat elvégzése két órát vesz igénybe (T(do)), de ugyanennyi munka ellenőrzése csak hat perc (T(verify)), akkor a verifikálás/elbírálás aránya ~5%. Az ügynöknek tehát csak 5%‑os sikerességi arányt kell elérnie, hogy nettó pozitív legyen. Sok vállalati feladatra ez a szám jóval engedékenyebb, mint az emberek gondolják.
A buktató ott van, amikor a hibának következménye van: egy hibás dokumentum kidobása kicsi veszteség; egy ügyfélszolgálati hibás visszatérítés viszont megváltoztatja a környezetet és helyreállítási költséggel jár. Ezt Tepper „agency tax” néven említi: verifikációs költség plusz rework költség, ami élesben ritkán nulla, és jelentősen megemeli a megbízhatósági küszöböt.
Ezért is logikus néha drágább, de képzettebb (frontier) modelleket használni: növelik P(siker)‑t és gyakran csökkentik T(verify)‑t, így a magasabb per‑token költség ellensúlyozható a jobb produktivitással. Tepper fontos hangsúlya, hogy a gen AI költsége nem egyetlen szám, hanem egy eloszlás valószínűségekkel és várható értékekkel.
Az árak csökkenése és a rejtett költségek
Pay‑i belső mérései szerint a fix modellmérethez kötött inferenciaárak körülbelül havi 6,67%-kal csökkennek 2022 óta, ami nagyjából 86%‑os visszaesésnek felel meg hasonló méretű modellek esetén — vagyis ha a képességet konstansan tartanánk, az ár valóban zuhan. A problémát az jelenti, hogy a képességet ritkán tartják konstansnak: az ügynökök többszörös API‑hívásokat tartalmaznak, átlagosan agent‑futtatásonként körülbelül 3,5 különböző modellt használva, gyakran több szolgáltatótól.
A Microsoft és a Stanford megállapítása, miszerint agentikus munkafolyamatok körülbelül 1000‑szer több tokent fogyasztanak, mint összehasonlítható kódchat és kódolási feladatok, összhangban áll a Pay‑i szintén produkciós telemetrián alapuló tapasztalataival. A kontextusablakok (context windows) mérete is jelentősen nőtt (kb. 250‑szeres növekedés GPT‑3 óta), és a költség nagy része a bemeneti tokeneken van — azaz az, amit a modelltől olvastatunk el, többe kerül, mint amit visszaad.
A háttérköltségek is összeadódnak: a cache‑elt input tokenek 75–90%‑kal olcsóbbak lehetnek, de csak akkor, ha a prompt úgy van felépítve, hogy a cache‑t találja; a legtöbb prompt nem ilyen. A „reasoning” tokenek (belső, láthatatlan gondolkodási lépések) akár el is nyomhatják a látható output költségét.
Mikor kell a kapacitásról, nem az árakról beszélni?
Tepper tapasztalata szerint a váltás nagyjából akkor történik, amikor évente mintegy 3 millió dollár koncentrálódik egyetlen szolgáltatónál egyetlen modellre. Ennél kisebb költésnél a megosztott infrastruktúra működik; felette időkorlátok, rate‑limitek és kapacitáshiányok kezdik érinteni a termelést, és a vállalat kénytelen előre lefoglalt (provisioned) kapacitásra váltani. Ez a váltás jelzi, hogy a gen AI alkalmazás missziókritikussá vált: a rugalmas, változó költségsor helyett fix költséggé alakul, tervezésre kényszerítve a szervezetet.
Gyakori hiba a szigetelés (siloing): mérnöki csapatok külön poolokat foglalnak le minden egyes use case‑hez, hogy elkerüljék az erőforrás‑versenyt. Ez azonban lerombolja a provisioning gazdasági logikáját, ami a változatos terhelések megosztásából és kiugrások lehúzásából él; sok ügyfélnél emiatt kétszer vagy háromszor annyi kapacitást fizetnek, mint amennyi ténylegesen kellene.
A szolgáltatóknál hirdetett TPM (tokens per minute) értékek általában becslések, nem valós terhelési specifikációk. A valódi kapacitás függ a bemenet‑kimenet aránytól, cache‑stratégiától és a szolgáltató által gyakran elhallgatott request‑per‑minute plafonoktól. Az egyetlen becsületes méretezési mód: valós terhelés alapján végzett load‑teszt.
Rövid, gyakorlati tennivalók a következő 2–4 negyedévben
Tepper rövid listája CIO‑k és CFO‑k számára:
- Készítsenek teljes körű leltárt az ügynökökről és osszák őket use case‑ekre. Sok vállalat nem tud pontos listát adni a termelésben lévő ügynökökről, az üzleti tulajdonosokról és a mozgatható KPI‑król.
- Definiáljanak számszerűsíthető KPI‑kat és üzleti eredményeket előre. Milyen óramegtakarításban, bevételben vagy hibaaránysűrűdés csökkenésben mérik a sikert? Szerezzék meg az üzleti szponzor aláírását indulás előtt.
- Instrumentáljanak minden üzleti hajtót, ne csak a költségeket. A token‑költés csapatonként alap, de nem elég. A legértékesebb metrikák az ügynök‑lépések szintjén adhatók ki, ahol költség, késleltetés és kimenet is köthető.
- Döntsék el, ki birtokolja a mérési architektúrát. Gyakori hiba a felelősség tisztázatlansága. Jelöljenek ki felelős személyeket és erőforrásokat (engineering, FinOps, pénzügyi partner, üzleti szponzor).
- Kezeljék a kapacitást portfólióként. Ne silo‑olják a provisioning‑t use case‑enként, kivéve ha szabályozás indokolja. Keverjék a terheléseket és alkalmazzanak spillover logikát tudatosan.
- Tartsanak negyedéves modell‑áttekintést. A frontier modellek 3–6 hónapos ciklusban mozognak; az első negyedéves döntések harmadik negyedévben elavultak lehetnek.
- Állítsanak fel közös működtetési csoportot pénzügy és mérnökség között, minden fontos ügynök mögé üzleti szponzort. Nélkülük a költést és a technológiát különböző keretrendszerekben védik, és az üzleti érték mérhetetlenné válik.
Egy évre előre: hogyan változik a beszélgetés?
Tepper szerint a közeljövőben kettészakadás (bifurcation) jelenik meg az ügyfél‑oldali metrikákban: a „Mythos‑osztályú” modellek bevezetésével nőni fog a különbség azon vállalatok között, amelyek képesek azokat élesíteni, és azok között, amelyek nem. Az igazgatósági kérdés elmozdul: „Használunk AI‑t?” helyett „A megfelelő AI‑t használjuk‑e?”.
Az observability és a FinOps réteg tipikus beszerzési tétellé válik — ahogy az APM kategória tette a 2010‑es években. A kategória pár éve nem létezett, most viszont tipikus sor lesz a vállalati stackben 18 hónapon belül.
A kódolást segítő agenteknél tapasztalható változások előfutárai annak, ami a többi fehérgalléros szakmában is történni fog: ahol „intelligencia van a tokenekben”, ott a token‑maximalizálás terjedni fog, ahogy a cégek és dolgozók felhasználják a lehetőségeket.
Végül Tepper szerint az AI „buborék” narratívája csendesen el fog enyészni: nem egy összeomlás következik, hanem egy olyan korszak, amelyben a vállalatok 95%-a nem tudja mérni hozamát, miközben az inferencia‑bevétel és a képesség gyorsan fejlődik. Akik most azt feltételezik, hogy „nem látunk ROI‑t, tehát nincs ROI”, ugyanúgy fognak visszanézni erre az időszakra, mint azok, akik 2014‑ben lemaradtak a felhőről.
Záró megjegyzés
David Tepper a Pay‑i vezérigazgatója és társalapítója; Lari Hämäläinen a McKinsey seattle‑i irodájának senior partnere. Az interjú szerkesztve lett a hossz és tisztaság érdekében. A megszólalók véleménye sajátjuk, és nem tükrözi a McKinsey & Company hivatalos álláspontját.
