Mi történik, ha holnap duplázzák a tokenárat?

Ahhoz, hogy megírjam ezt a cikket, meg kellett néznem, mennyibe kerül egy kilowattóra, mert ugye kevesen tartják fejben az árakat.

A tokenárakat viszont fejből tudom, mert azokat figyelni kell.

Ennyi a különbség a két költségmodell között. A többi már csak matematika kérdése.

Miért most

Gonda Gábor, a Magyar Telekom vezérigazgató-helyettese a héten adott egy interjút a Portfolio-nak, amiben határozott véleményt fogalmazott meg: a ma látható AI-piaci és üzleti modell hosszú távon nem fenntartható. Ahogy ő mondta, a pénzügyi matek nem jön ki. Dollármilliárdok mennek adatközpont kapacitásba, miközben a technológia két-három évente akkorát lép, hogy a korábbi beruházások jelentős része elavulhat.

A számunkra érdekes rész viszont nem ez, hanem a következtetés. Szerinte a legnagyobb kockázat a tokenköltség: nem tudhatjuk, hogyan alakul. A nagyvállalatok, amelyek már élesben integrálták az AI-t, fél szemüket folyamatosan ezen tartják, és azt próbálják kiszámolni, mi történik, ha a szolgáltatók 10, 20 vagy akár 100 százalékos áremelést hajtanak végre. Megmarad-e a hatékonyságnövekedés, vagy elpárolog?

Erre nekem is válaszolnom kell, mert a DocAI is ebben a piacban él. Úgyhogy megnéztem a saját számainkat.

Nézzük, miről is szól pontosan ez a cikk.

Kétszer írtam már arról, miért futtatunk helyben: elsődlegesen az adat miatt, másrészt a GDPR és egyéb jogszabályi megfelelés miatt.

Viszont most nem ezen oldalakról fogjuk megközelíteni a témát. Ezen sorok között nincs GDPR, nincs adatszuverenitás, nincs AI Act. Egy másik tengelyen fogunk mozogni: ki szabja meg az árat, és mikor.

Kétfajta számla, és költség

Két költségmodell van, és a különbség nem az összegben van.

A változó költség, a token, a használattal skálázódik. Alacsony a belépési küszöb, nem kell előre fizetni, az elavulás kockázata a szolgáltatódé, de ami a legfontosabb, és talán a legveszélyesebb is egyben, az árat nem te szabod meg. Utólag kapod meg a számlát, és később sem lesz beleszólásod az árazás alakulásába.

A fix költség, az on-premise megoldás, nem skálázik a használattal. Magas a belépési küszöb, előre kell fizetni, és az elavulás kockázata a tiéd. Cserébe az árat egyszer szabod meg.

Fontos, hogy ezt tisztán lássuk: mindkét oszlopban vannak igaz állítások. Gonda pékség-analógiája — hogy a pékség a kemencéje mellé nem akar egy komplett szerverszobát is építeni csak azért, hogy legyen e-mail és számlázás — teljesen helytálló. A KKV-k ezreinek tényleg nem opció és nem is reális a saját szerverterem.

A kérdés nem az, hogy melyik modell a jobb, hanem az, hogy mikor melyiket kell választani, mérésre és számokra támaszkodván meghozva a döntést.

Első mért adat: a legolcsóbb tokenmegtakarítás nem az árban van

Mielőtt bárki tokenárról beszélne, érdemes megnézni, mennyi tokent éget feleslegesen.

Májusban szisztematikusan összehasonlítottunk egy 35 milliárd és egy 122 milliárd paraméteres modellt a saját magyar üzleti eval-harness-ünkön. Az eredmény nem az volt, amit vártam:

• A nagyobb modell nem nyert a strukturált adatkinyerésen. Semmivel sem mutatkozott jobbnak a kisebb "testvérénél".
• Ráadásul 2,6-szer lassabb is volt.
• A komplex, többlépéses elemzéseken viszont hat feladatból ötben jobb választ adott — és ötször kevesebb adatlekéréssel.

Mindkettő termelésben van nálunk, különböző célokra, és ez a titok nyitja!

A tanulság pedig általános, és felhőben is működik: a tokenszámlád nagy része nem az árról szól, hanem arról, hogy rossz méretű modellt használsz rossz feladatra. A legjobb megtakarítás a jól megalapozott, adatokon alapuló választás.

Második mért adat: magyar dokumentumon nem a nagyobb nyer

Áprilisban kiértékeltük a Gemma4-et a magyar számla-KIE korpuszunkon. A Qwen3.6 F1-értéke 0,983 volt, a Gemma4-é 0,890.

A 0,890 papíron nem hangzik rosszul. Nézzük meg, mik voltak a hibák:

• magyar karakterkódolási problémák
• hallucinált cégnevek
• csonkolt számlaszámok

Vagyis nem apró pontatlanságok. A rendszer kitalált egy cégnevet, levágta a számlaszám végét. Ezek egy könyvelési folyamatban nem 11 százalékos hibák. Minden ilyen hiba egy-egy tétel, amit valakinek manuálisan meg kell keresnie és ki kell javítania, amivel pont az veszik el, amiért az egészet csinálod. A megtakarítás.

A fent felsorolt pontatlanságok mellett ráadásként a Gemma4 single-stream decode-ja 30–80 százalékkal lassabb volt.

Ezek a hibák és adatok viszont csak akkor derülnek ki, ha a saját dokumentumaidon méred őket, nem a szállító demóján, ahol minden modell jól és hatékonyan működik.

Harmadik mért adat: mennyi munkát bír el egy Spark

Áprilisban felraktunk egy 122 milliárd paraméteres modellt egyetlen DGX Sparkra. A mért értékek:

• 30 token/s JSON-KIE-n, 100 százalékos MTP-elfogadással
• 64 token/s aggregát négy párhuzamos felhasználói szálon

Egy másik mérésben az MTP a 16 párhuzamos felhasználós stressz-teszten +24 százalék throughputot és −56 százalék TTFT-t adott, pont ott, ahol elméletileg negatívnak kellett volna lennie.

És most a lényeg, ami ezt üzletivé teszi: a Gree napi 30–70 iratot dolgoz fel. Ezt a terhelést egy asztali méretű gép elviszi. Nem majdnem, nem akadozva. Bőven elegendő számítási kapacitást nyújt ekkora mennyiségű adat kezeléséhez.

Ugyanakkor azt is hozzá kell tenni az őszinteség kedvéért: van, ahol megtörik a lendület! Ugyanabban a mérésben leírtuk, hogy a Spark elhasal a 100 ezer tokenes párhuzamos kontextusoknál, tehát nem mindenre használható jól. Csak arra, amire méreteztük.

És most a villanyszámla

Idáig minden korábbi állítás a már megjelent cikkekből van. Innentől jön az, amit ehhez a cikkhez mértem.

Két DGX Spark, 30 nap, Prometheus + DCGM. A GPU-vonalon:

A beta hézagja mode-váltásokból és rebootokból jön. Leírom, mert kellemetlen, és mert enélkül a szám nem lenne értelmezhető.

GPU-vonalon a két gép együttes fogyasztása ~15–17 kWh havonta. Céges nettó áramáron számolva nagyjából 65 Ft/kWh-val kalkulálhatunk. Ez havi ezerszáz forint körül alakul két gép esetén.

Ez viszont nem a teljes kép, és nem is állítom, hogy az. A DCGM nem méri a Grace CPU-t, a mindig táplált 128 GB LPDDR5X-et, a tárolót, a ventilátort és a tápegység veszteségét. A Spark 240 wattos táppal üzemel; idle-domináns profilnál a teljes gép reális átlaga csúcsfogyasztás esetén 60–90 watt, azaz 45–65 kWh/gép/hó. Két gép esetén tehát: nagyságrendileg 100-120 kWh havonta.

A fenti árakon számolva tehát: havi 5 900 és 8 500 forint között mozog a valós költség, ha nagyvonalúak vagyunk, számolhatunk nagyjából 6 500 forinttal.

Hangsúlyozom, hogy ezek becsült értékek és viszonyszámok. Az áramár Magyarországon meglepően bonyolultan áll össze, és a te számlád mást fog mutatni, de a nagyságrenden ez nem változtat: a teljes DocAI-infrastruktúránk áramköltsége nagyjából egy közepes mobilelőfizetés költségszintjén mozog.

Ez a teljes változó költségünk. Nem token. Nem lekérdezés. Nem szerződés. Áram.

És ha holnap megduplázzák a tokenárat, ez a szám akkor sem változik.

Nem azt állítom, hogy olcsóbb. Azt állítom, hogy nem változik. Gonda kérdése pontosan ez volt.

Amit ez a szám nem tartalmaz

Két dolgot ki kell mondani, különben nem becsületes az összevetés.

Az egyik: a token-számla nem csak számítást fizet. Egy szolgáltatást is: valaki más uptime-ját, a modellfrissítéseket, a supportot. Ez valódi érték, és nincs benne a 100 kilowattórában.

A másik: a két gép több cég adatát dolgozza fel, egymást kiegészítve. Ezért egy cégre vetített egzakt számot nem tudok adni, és nem is fogok úgy tenni, mintha tudnék. Ez a szám a rendszerről szól, nem egy ügyfélről. A cégre bontott mérés majd külön cikk lesz, egy dedikált gépen, egy ismert korpuszon.

A tétlenség majdnem ingyen van

Van itt valami, ami elsőre ellentmondásosnak tűnik.

A felhő klasszikus érve úgy szól: ne fizess tétlen kapacitásért. Ez az érv abból indul ki, hogy a tétlenség drága.

Nálunk a profil erősen idle-domináns: a GPU átlag 11–12 watton ketyeg, és csak feldolgozási burst-öknél ugrik 90–97-re. Vagyis a gépek az idő túlnyomó részében tétlenek.

És a tétlenség 11,56 wattba kerül. Havi nyolc kilowattóra. Nagyjából ötszáznegyven forint.

Ennyibe kerül készenlétben tartani egy AI-t, ami bármikor indul. Havi ötszáznegyven forint.

Egy apró technikai megjegyzés, ami sokat elmond: a GPU a gép fogyasztásának csak nagyjából 15–20 százaléka. Az idle-padlót nem a GPU adja, hanem a mindig táplált 128 GB memória.

A sáv

Itt jön ki a lényeg. Számoljuk össze a két végpontot:

• tétlen gép: ~60–90 W
• GPU csúcson, teljes gőzzel: nagyságrendileg ~150–180 W

Vagyis a semmittevés és a teljes terhelés között két-háromszoros a különbség, de fontos előnye, hogy a maximális terhelés mellett is megvan a költségplafon.

Token-modellben ugyanez a sáv nullától korlátlanig tart. A számla lineárisan skálázik a használattal, felső korlát nélkül.

1. ábra — A doboznak van plafonja. A tokenszámlának nincs.

Ebből következik valami, ami elsőre furcsán hangzik: minél többet használod a Sparkot, annál olcsóbb egy iratra vetítve a költsége. A token-modellben ez pontosan fordítva van.

A megtérülés

A villanyszámla önmagában féligazság lenne, mert a helyi AI-nak, és a hardvernek ára van.

A Gree Magyarországnál napi 30–70 irat megy át a rendszeren, négy közhiteles forrásból automatikusan ellenőrizzük a partnereket, és csak az utalási listák létrehozásán napi egy óra fölött spórolnak, a több napos jóváhagyási folyamatból pedig napon belüli ügymenet lett.

A megtérülés három-négy hónap volt.

Ez pedig kivesz egy lábat az elavulás-érv alól. Ha egy Spark, AI kombináció három-négy hónap alatt megtérül, akkor a „de két-három év alatt elavul” aggály matematikailag nem áll meg. Rég kitermelte magát, mire elavulna.

A teljes költségkép így néz ki:

• Capex: amortizálódik, 3–4 hónap alatt megtérül. Mérve, ügyfélnél.
• Opex: ~100 kWh/hó, két gépre. Mérve, 30 napon.
• A megtérülés után egy irat marginális költsége: áram.

„De elavul”

Ez a legkomolyabb ellenérv, és Gonda pontosan fogalmazza meg: a technológia két-három évente akkorát fejlődik, hogy a korábbi beruházások jelentős része elavulhat.

Igaz. A nagy nyelvi modellre, de ebben az esetben a hardverre nem.

Nézd meg ezt a blogot időrendben. Három hónap, egyetlen gép:

Négy modell, egy gép, három hónap, minden váltás megmérve.

A modellek valóban elavulnak, de ami fontos, hogy ingyen vannak. A hardver viszont marad.

És most jön az a rész, ahol nem értek egyet Gondával, pontosan egy állításban.

Ő azt mondja, a cserélhető modell, a technológia-agnosztikus architektúra kulcsfontosságú irány, és ebben teljesen igaza van. De hozzáteszi, hogy ehhez akkora skála kell, amekkorával a Magyar Telekom rendelkezik, és hogy a vállalkozásoknak érdemes ebbe az irányba elmozdulniuk, a házi barkácsmegoldások helyett.

Tisztelettel: nem kell akkora skála. Egy asztali méretű gépen csináltuk meg, és minden mérést publikáltunk. A negatívumokat is: két nap és hat óra Triton-tuning után a végén 5–7 százalékkal rosszabb konfigurációnál kötöttünk ki, és arról is írtunk egy cikket.

Ez a különbség a barkács és a mérnöki munka között. Nem az, hogy nincs kudarc. Hanem hogy megmérted, és leírtad.

Mikor NE csináld így

Ha a terhelésed kiszámíthatatlanul csúcsos. A fix költséget nem tudod a csúcsra méretezni, csak drágán. Ilyenkor a felhő olcsóbb, és nem is kicsit.

Ha nincs, aki üzemeltesse. Egy nem frissített, rosszul karbantartott saját infrastruktúra tényleg kockázatosabb, mint egy felhőszolgáltatás. Ebben Tanács Zoltán miniszternek, aki szintén erről beszélt a napokban, teljesen igaza van, és ezt a DocAI-nál is komolyan vesszük.

Ha a feladat publikus és alkalmi. Egy e-mail megfogalmazása, egy nyilvános dokumentum összefoglalása, erre nyugodtan használj nyilvános modellt. Nem minden feladat bizalmas.

Ha most kezded, és nem tudod, mennyi lesz. Kezdd felhőben. Mérj három hónapig. Aztán dönts.

A helyben futtatás nem hitvallás. Egy döntés, aminek mérhető feltétele van.

Öt kérdés, mielőtt AI-t veszel

1. Hány dokumentum megy át rajtad naponta? Ha nem tudod, ennek kiderítése az első feladat — nem az AI.
2. Mekkora a tokenszámlád ma, és mi történik vele, ha duplázódik? Ha ez a kérdés kellemetlen, az már egy válasz.
3. Ki szabja meg az árat jövőre? Benne van a szerződésben, vagy csak bízol benne?
4. Ha holnap kilépnél: mennyi idő alatt teheted ezt meg, és mit viszel/vihetsz magaddal?
5. A saját dokumentumaidon mérted meg, vagy a szállító demóján?

Zárás

Gonda kérdése jó kérdés: mi lesz, ha emelnek?

Nálunk a válasz nagyjából 100 kilowattóra és havi hatezer-ötszáz forint, és egyik sem függ attól, hogy mit döntenek Kaliforniában. Ez nem érdem, ez egy architekturális döntés következménye, aminek megvan a maga ára és a maga korlátja, és mindkettőt leírtam fentebb.

De a kérdésre csak akkor tudsz válaszolni, ha ismered a saját számaidat.

Ez az egyetlen dolog, ami rajtad múlik.

A cikkben szereplő mérések a DocAI saját infrastruktúráján készültek: két NVIDIA DGX Spark (GB10), Prometheus + DCGM Exporter, Grafana. A 30 napos fogyasztási adat nyers. A teljes gép fali fogyasztása becslés, a mért fali adatot egy következő cikkben közöljük. Az áramár nettó 65 Ft/kWh-val számolva, viszonyszámként.

Gonda Gábor idézett állításai a Portfolio 2026. július 16-i interjújából származnak: „Nem jön ki a matek: alapjaiban változhat meg minden, ha bejön az AI-cégek mesterterve”. Érdemes elolvasni egészben, több van benne, mint amennyivel én itt foglalkoztam.