Az elmúlt két évben sok vállalat, köztük pénzintézetek, saját GPU-farmokat vagy lefoglalt cloud node-okat vásárolt adat-szuverenitás, zárolás-ellenállás és hasonló okok miatt. Ennek ellenére a hardverhasználat gyakran alacsony: egy szingapúri adatközpontban például egy bank nyolc NVIDIA H100-at fizet, amelyek éjszakákon nagy részében várakoznak. Ez a jelenség szerzőnk kifejezésével a „GPU hangover".
Miért alacsony a kihasználtság? A memóriafal és a párhuzamosság hiánya
A hagyományos autoregresszív modellek (például a Llama-, Mistral- vagy GPT-család) tokenenként egy lépésben generálnak. A modellsúlyok a GPU nagy sávszélességű memóriájában maradnak, de maga a számolás kis on-chip memóriában történik, amely nem tudja egyszerre tárolni a többmilliárd-paraméteres modellt. Ennek következménye, hogy minden egyes tokenhez újra kell tölteni a súlyokat a gyorsítóról a számítási egységekre: ez a memória-sávszélesség korlátját hozza, nem a nyers aritmetikai kapacitást. Mért aritmetikai intenzitás (művelet per bájt mozgatva) batch méret egy esetén közel 1, míg a modern GPU-k százakra optimalizáltak. Ezért a chip „éhezik": a számítást végző egységek sokat állnak.
A megszokott megoldás a batching: egyszer beolvasod a súlyokat, és több kérés több tokenjét egyszerre számolod ki, így az egyetlen drága memóriaolvasás több munkát amortizál. Ez a technika magyarázza, miért olcsóak a nagyléptékű publikus API-k: hatalmas batch-ekkel magas throughputot és alacsony per-token árat érnek el.
Mely munkák nem batch-elhetők? A valós idejű, késleltetésérzékeny kérések
A kulcs az, hogy fel tudsz-e halmozni párhuzamos munkát. Egy éjszakai, offline várólista — például millió dokumentum feldolgozása KYC-hoz — könnyen batch-elhető, mert senki nem vár azonnal. Ezzel szemben egy fejlesztői kódkiegészítés, egy bankfióki ügyfél-betöltés vagy egy hitellevél tisztázása alatt álló ügyész nem enged várakozást: ezek az egyes kérések alacsony késleltésű, sorozatos (single-stream) fogyasztást igényelnek, ahol a batching áron van.
Az autoregresszív dekódálás ilyen single-stream esetben tokenenként memóriakorlátba ütközik, és sokszor csak néhány tíz token/s teljesítményt ér el, így több száz token kimenet több másodpercet vesz igénybe — még spekulatív dekódolással is csak 2–4× gyorsulás érhető el tipikusan.
Hol jön be a szöveg-diffúzió?
A text-diffúziós dekódálás az képgenerálásból ismert mechanizmust kölcsönzi: zajos vagy maszkolt tokenblokkot vesz, majd néhány denoising lépésben párhuzamosan finomítja az egész blokkot. Nem „írógép-szerűen" tokenről tokenre halad, hanem tömbösen dolgozik. Mivel minden átmenet valós aritmetikai munkát végez a teljes blokkra, a dekódálás compute-bound lesz még batch méret egy esetén is. Míg az autoregresszív intenzitás közel 1, egy összehasonlítható diffusion modell intenzitása a százak tájékán mozog — vagyis a GPU-t telíti anélkül, hogy számos beérkező kérelmet kellene felhalmozni.
Gyakorlati számok: az Inception Labs Mercury nevű modellről jelentették, hogy H100-on 1 100+ token/s teljesítményt értek el kódgenerálásnál; a Mercury 2 2026-os bejelentése szerint nagyjából 1 000 token/s-t mértek Blackwell-hardveren alacsony késleltetés mellett. A Google bemutatta a paradigmát a Gemini Diffusion-nal, az LLaDA pedig nyílt forrásból jelezte, hogy a diffusion modellek hasonló skálázási törvényeket követnek, mint az autoregresszív rendszerek.
Ez azt jelenti: egy szigorú, single-stream késleltetésű kérést diffusion akár nagyságrendekkel gyorsabban teljesíthet, mert az autoregresszív alternatíva memóriafalba ütközik és nem batch-elhető ki.
Nem mindenre ez a válasz: spekulatív dekódolás és MoE modellek
A diffúzióval való összevetéskor figyelembe kell venni, hogy az autoregresszív stratégiák is fejlődnek. A spekulatív dekódálás (és leszármazottjai, például Medusa és EAGLE) egy kisebb draft-modellt használ, amely több tokent javasol, majd a fő modell egy passzban ellenőrzi ezeket — ez 2–4× gyorsulást ad single-stream esetben minőségváltozás nélkül. A mixture-of-experts (MoE) modellek más úton csökkentik a memória-mozgást: tokenenként csak a súlyok egy részét aktiválják.
Tehát nem a „autoregresszív vagy diffusion" elvont kérdése a döntő, hanem hogy diffusion szerkezeti párhuzamossága tényleg meghaladja-e az adott spekulatív/autoregresszív fejlesztések nyereségét a konkrét munkaterhelésen.
Gazdaság: tokens per dollar és mikor nyer az owned compute
A gazdasági képlet egyszerű:
Effective cost per token = node cost per hour ÷ (throughput × utilization)
Egy publikus API-t jellemzően tokenalapúan áraznak és a konkurenciafüggetlenség miatt nincs idle büntetés. Az owned compute óradíjas, ezért per-token költsége a tényleges throughputtól és kihasználtságtól függ. Példák a cikkből: egy AWS p5.48xlarge (nyolc H100) on-demand ára körülbelül 55 USD/óra, egyéves Savings Plan-nel körülbelül 40% megtakarítással ~33 USD/óra adódik.
Egy olcsó publikus API, amely az olcsó modellgenerációt mondjuk kevesebb mint 1 USD/millió tokenért adja, majdnem mindig olcsóbb lesz az owned node-nál. A diffusion gazdasági előnye csak két helyzetben jelentkezik: (1) ha a token ára a publikus API-ban magas (például frontier vagy reasoning outputok, 5–15 USD/millió token), ahol a telített, saját node versenyképes per-token költséget kínál; vagy (2) ha az adat biztonsági/szuverenitási okokból nem hagyhatja el a szervezetet, tehát a versenyzés csak saját infrastrukúra között zajlik. A legtöbb szabályozott vállalat az utóbbi csoportba esik.
Példa: banki dokumentumfeldolgozás két módja
Ugyanannál a banknál két feladat látszólag hasonló, de teljesen eltérően viselkedik:
-
Éjszakai kötegfeldolgozás (milliós KYC-dokumentum-készlet): könnyen batch-elhető; egy standard autoregresszív modell kis folyamatos batch-el több ezer token/s-t képes feldolgozni egy node-on. Diffusion valamivel gyorsabb lehet, de nincs nagy gazdasági különbség, mert a batch már megoldotta a memóriafalat.
-
Valós idejű, késleltetésérzékeny feldolgozás (kliens az ablaknál, onboarding, letter-of-credit döntés): ezek single-stream kérések, ahol egy másodperces válaszidő a cél. Itt az autoregresszív modell kis batch mellett sok node-ot igényel a csúcsigény kiszolgálásához, míg a diffusion egy node-on sokkal több alacsony késleltetésű kérést képes kiszolgálni. A megtakarítás a node-ok számán jelenik meg: diffusionnál kevesebb gépre van szükség ugyanazon szolgálati szint eléréséhez.
Tehát a megtakarítás forrása nem az általános alacsony párhuzamosság, hanem az, hogy a késleltetés kiküszöböli a batching lehetőségét.
Korlátok és kompromisszumok
A diffusion nem ingyenes: minőség és gazdaságosság terén kompromisszumok vannak.
-
Pontosság: diffúziós modellek jellemzően a forrásadatok szerint nagyjából 85–95% szintjén teljesítenek a jobb autoregresszív alapokhoz képest; strukturált kimenetben versenyképesek, de kemény, magas-követelményű reasoning feladatokban 5–15 százalékponttal elmaradhatnak. Ezek az ipari és mellékszámozások forrás-ellenőrzést igényelnek a saját adathalmazra.
-
Compute-költség: a diffusion a magas intenzitással részben több teljes munkát végez per hasznos token, ezért a releváns mérőszám mindig a „token/milliárd forint (vagy $) elfogadható minőséggel" — nem pusztán a GPU kihasználtsága.
-
Eszköztámogatás és érettség: a diffúziós serving-ök 2026-ban még fiatalok; a nyílt forráskódú diffusion stackok ott tartanak, ahol az autoregresszív serving 2024 elején volt: működnek és gyorsan fejlődnek, de nem olyan kiforrottak, mint a vLLM vagy TensorRT-LLM környezetek.
-
Versenytárs fejlesztések: spekulatív dekódolás, jobb ütemezők és MoE modellek folyamatosan csökkentik a diffúzió relatív előnyét, így a diffusionnak egy mozgó célt kell legyőznie.
Gyakorlati ajánlás: kéttényezős routing-szabály
A döntéshez két tengelyt érdemes nézni:
- Batching lehetséges-e? (offline-toleráns vs. latency-bound)
- Mennyit ér egy token? (alacsony árú generáció vs. magas értékű reasoning)
- Ha a feladat latency-bound és sok dekódolást igényel (kódkiegészítés, valós idejű adatextrakció, agentic workflow lépések), és a minőségi gap elfogadható, a diffusion a sweet spot: kevesebb node, alacsonyabb per-token költség owned compute mellett.
- Ha a feladat magas értékű reasoning, ahol tévedés költséges, maradjanak frontier autoregresszív modelleken.
- Offline kötegfeladatoknál maradjon, amit a szervezet eddig jól működtet: a batching már hatékonnyá tette mindkét architektúrát.
Mindezt érdemes saját méréssel alátámasztani: cserélgetni a batch méreteket, a sorhosszt és a valós mintapéldányokat, valamint frissíteni a kalkulációt az aktuális API- és hardverárakkal.
Összegzés
A vállalatok által megvásárolt GPU-hardver önmagában nem volt rossz döntés: sokan adat-szuverenitás vagy lock-in-ellenállás miatt hozták meg a beruházást. A kihívás az, hogy a legértékesebb belső munkák — a késleltetésigényes, sorozatos kérések — soha nem érik el azt a párhuzamosságot, amelyen a cloud gazdaságossága alapul. A text-diffúziós dekódolás nem univerzális csodaszer, de precízen célozza azt a rést: a batchingre alkalmatlan, latency-bound feladatokat, ahol egy diffúziós modell egy node-on sokkal több alacsony késleltetésű kérést teljesít, mint egy autoregresszív alternatíva. Fontos azonban a token/money mérőszám, a minőségkritériumok és az egyre javuló autoregresszív optimalizációk figyelembe vétele; a tényleges döntést mindig saját mérésekre és naprakész költség-adatokra alapozva célszerű meghozni.
További források
A cikk forrásai között említik az Inception Labs „Mercury" és a Mercury 2 anyagait (2026), a Gemini Diffusion bejelentést, az LLaDA nyílt modelleket, valamint kutatásokat a spekulatív dekódolásról (Medusa, EAGLE) és az AWS P5 árazásról. A közölt teljesítmény- és pontossági számok mérnöki közelítések 70B osztályú modellekre; beszerzési döntés előtt saját méréseket kell elvégezni a saját batchméretekkel és szekvenciahosszokkal.
