Mikor érdemes nagyobb AI-modellt használni — és mikor nem?

Az elmúlt két évben szinte havonta jelennek meg újabb és újabb, egyre nagyobb mesterséges intelligencia modellek. A piaci kommunikáció szerint a nagyobb mindig jobb: több paraméter, több tudás, jobb eredmény. Ez a feltevés azonban, ahogy a DocAI-nál nemrég lefolytatott összehasonlító tesztünk megmutatta, egyáltalán nem mindig igaz.

Ebben a cikkben azt mutatom be, hogyan döntöttük el szisztematikusan, hogy érdemes-e egy négyszer nagyobb AI-modellre váltani a meglévő rendszerünkben. A válasz meglepő: nem érdemes minden feladat esetén, de van egy konkrét terület ahol megtérül. Az út, amelyen erre a következtetésre jutottunk, jó esettanulmány lehet minden cégvezetőnek, aki AI-fejlesztésről hoz döntéseket.

A kontextus: mit építünk és miért volt érdekes a kérdés

A DocAI egy magyar fejlesztésű dokumentumfeldolgozó platform, amely könyvelőcégek és magyar kkv-k számára automatizálja a számlák, szerződések és HR-dokumentumok feldolgozását, valamint a hozzájuk kapcsolódó üzleti elemzéseket. A rendszer alapja egy nagy nyelvi modell, amely a magyar nyelvű dokumentumokból strukturált adatokat nyer ki, válaszol kérdésekre, és segít az üzleti döntéshozatalban.

A jelenleg termelésben futó modellünk egy 35 milliárd paraméteres, magyar dokumentumokra finomhangolt rendszer, amely az iparágban már elismerten erős teljesítményt nyújt. A felmerülő kérdés természetes volt: ha létezik egy nagyjából négyszer nagyobb, 122 milliárd paraméteres modell ugyanebből a családból, vajon érdemes-e átállni rá? Az ügyfeleink kapnának-e érzékelhetően jobb minőséget cserébe a nagyobb futtatási költségért?

A kérdést nem hagyhattuk megválaszolatlanul. Egy téves döntés bármely irányba sokba kerülhet: ha indokolatlanul váltunk nagyobbra, hónapokon át fizetjük a többletköltséget; ha indokoltan kellett volna váltani, de nem tettük, az ügyfeleink kevésbé jó eredményeket kapnak, és előbb-utóbb egy versenytárshoz fordulnak.

Hogyan mérünk objektíven egy AI-modellt?

Az AI-iparban hihetetlen mennyiségű marketing-jellegű „benchmark” eredmény kering. Ezeknek a vállalati döntéshozatalban azonban nagyon korlátozott értékük van, mert a tipikus tesztek angol nyelvű, általános feladatokra mérnek, nem arra, amit a magyar üzleti életben ténylegesen csinálni kell.

A DocAI-nál ezért idén januárban kezdtünk építeni egy saját értékelési rendszert, amely az utóbbi hetekben érte el azt a szintet, ahol már megbízhatóan használható modell-választási döntésekhez. Két fő dimenzión mérünk:

Az első dimenzió a strukturált adatkinyerés: ki tudja-e olvasni egy magyar számla, szerződés vagy HR-dokumentum releváns mezőit. Ez a mindennapi DocAI-használat alapja, és itt a jelenlegi rendszerünk már gyakorlatilag tökéletes pontosságot ér el.

A második dimenzió a komplex üzleti elemzés: olyan többlépéses feladatok megoldása, amelyek emberi gondolkodást utánoznak. Ehhez öt új, magyar üzleti életből vett feladatot dolgoztunk ki, olyanokat, amelyek tipikusan egy senior pénzügyi elemző vagy könyvelési vezető asztalán végződnek, és több órás manuális munkát igényelnek:

Cashflow-gap előrejelzés: az elkövetkező 60 napban várható-e likviditási probléma, figyelembe véve a kintlévőségek esedékességét, a vevők múltbeli fizetési mintáit, a szállítói tartozásokat és az ismétlődő fix költségeket.
Beszállítói anomália-detekció: az elmúlt 12 hónapban melyik beszállítónknál mutatkozik szokatlan számlázási minta a korábbi két év baseline-jához képest — hirtelen árugrás, gyakoriság-változás, szokatlanul nagy egyedi tételek.
Vevői koncentráció-kockázat: mekkora kockázatot jelent a jelenlegi vevői portfólió-koncentráció, mely vevők jelentenek kritikus függőséget, és hogyan kell diverzifikálni.
Áfa-pozíció optimalizálás: a negyedéves áfa-pozíció bontása fordított adózású tételek külön kezelésével, és időzítési optimalizálási javaslatok.
Beszállítói külső kockázat monitorozás: a top 5 beszállító nyilvános hírek alapján történő stabilitás-vizsgálata, kockázati besorolás és intézkedési javaslatok.

Mindegyik feladatnak van objektív értékelési kritérium-rendszere: hány adatlekérést végzett a modell, milyen sorrendben, eljutott-e a helyes következtetésig, megfogalmazott-e konkrét cselekvési javaslatot. Az eredményeket emberi szakértő, esetünkben jómagam, is külön értékelte („eyeball” minőségbecslés), hogy a kvantitatív metrikákat tartalmi vélemény egészítse ki.

Az első meglepetés: a fő feladatkörön nem nyert a nagyobb modell

A nagy modellt teljes körű tesztelésnek vetettük alá. Az eredmény a strukturált adatkinyerésen, amit jelenleg a DocAI ügyfelek napi szinten használnak, egyértelmű volt: a nagyobb modell nem hozott javulást. A kisebb modell már majdnem tökéletes pontossággal dolgozik a magyar számlákon és tipikus üzleti dokumentumokon. Nyilvános a 35B vs 122B összevetés mérési adatai.

Az egyszerűbb chat-jellegű kérdéseken — „ki a top 5 szállítónk”, „mennyi volt a tavalyi bevételünk”, „mutasd meg a 10 millió forint feletti kintlévőségeket” — szintén egyenértékű teljesítményt mértünk. Tíz tesztfeladatból mindkét modell ugyanazon a kilencen sikerült, és ugyanazon az egyen bukott.

Mindeközben a nagyobb modell 2,6-szor lassabb lett. Egy átlagos felhasználói kérdésre, ahol most másodperces válaszidőt biztosítunk, négy-öt másodpercet kellett volna várni, ezt egyetlen felhasználó sem értékelné. Ráadásul a nagyobb modell hardvere és karbantartása is jelentősen drágább.

Ha csak ezeket a méréseket néztük volna, a döntés egyértelmű: maradni a jelenlegi modellnél. Szerencsére azonban tovább vizsgáltuk.

A második meglepetés: van egy konkrét terület, ahol viszont mérhetően jobb

A nagy modell igazi tesztje a fent leírt öt komplex üzleti feladat volt. Itt egészen más eredményeket láttunk: a nagyobb modell hat feladatból öt esetben jobb választ adott, vagy egyenértékűt, egyetlen feladaton sem teljesített rosszabbul.

A konkrét különbségek sokszor finomak, de gyakorlati szempontból jelentősek:

A cashflow-előrejelzés feladatánál mindkét modellnek nehézségei voltak, de a nagyobb modell legalább konkrét cselekvési javaslatot fogalmazott meg, míg a kisebb csak adatokat sorolt fel következtetés nélkül. Üzleti döntéshozási szempontból ez a különbség lényegi: egy vezetőnek nem adatlista kell, hanem konkrét, indokolt javaslat.

Egy másik tesztben, havi költés-trend kiszámolásánál, a kisebb modell rossz növekedési százalékot számolt, miközben a nagyobb pontosan. Ez különösen aggasztó: nem arról van szó, hogy a kisebb modell „valamit nem mond el”, hanem hogy magabiztosan rossz választ ad. Egy vezető, aki nem ellenőrzi a számokat, hibás döntést hozhat alapján.

A legérdekesebb felfedezés mégis a hatékonyság-mintázat volt. A nagyobb modell általában körülbelül ötször kevesebb adatlekéréssel jutott el ugyanahhoz a helyes válaszhoz, mint a kisebb. Másképp fogalmazva: a kisebb modell a komplex feladatokat „brute force” módon próbálta megoldani — egymás után rengeteg lekérdezést indított, sokszor ismételten ugyanazokat —, míg a nagyobb modell célzottabb stratégiával dolgozott. Egy emberi analógiával: olyan ez, mintha egy junior elemző tizenöt különböző Excel-fájlt megnyitna ahhoz, hogy egy kérdést megválaszoljon, miközben egy senior kolléga ugyanezt három riportból oldja meg.

Üzleti tanulság: megfelelő modell a megfelelő feladatra

Mit jelent ez konkrétan a DocAI gyakorlatában? Mindkét modellt használjuk, de teljesen különböző célokra.

A jelenlegi 35 milliárd paraméteres modell marad a mindennapi munka motorja: a dokumentumok strukturált feldolgozása, az ügyfelekkel folytatott interaktív beszélgetések, az egyszerű lekérdezések. Itt a gyorsaság, a jól bevált pontosság és a költséghatékonyság a fontos.

A nagyobb, 122 milliárd paraméteres modell viszont egy dedikált háttér-rendszerként fut, amely éjszakai és heti rendszerességű komplex elemzéseket végez. Ezekre a feladatokra olyan kérdések tartoznak, amelyekre egy senior pénzügyi vagy könyvelési szakértő több órán át dolgozna manuálisan, és amelyeknek az eredménye reggel egy átlátható, indokolt riport formájában érkezik az ügyfél asztalára.

Mikor érdemes egy ilyen háttér-folyamatra a nagyobb modellt használni? Saját tapasztalatunk alapján akkor, ha az adott feladat legalább három szempontnak megfelel a következők közül:

Több különböző adatforrásból kell információt összerakni, és a következtetés többlépéses gondolkodást igényel.
A válaszhoz számszerű következtetés kell — trendek, arányok, koncentráció-mértékek —, nem csak az adatok felsorolása.
Több időszak (legalább két év) vagy nagyszámú entitás (legalább öt partner) összehasonlító elemzése a feladat.
Hosszú dokumentumok elemzése — több éves pénzügyi adatok, vagy egyszerre több dokumentum.
Háttérfolyamatként fut, ahol elfogadható, ha 2-10 percet vesz igénybe a válasz.
Az eredmény végül emberi felülvizsgálatra megy, nem közvetlenül a végfelhasználóhoz.

Ez egy egyszerű, jól alkalmazható döntési szabály, és bármely olyan szervezet hasznosíthatja, amely most fontolgatja, hogy nagyobb vagy okosabb AI-rendszerre váltson.

A vezetői tanulság

Az AI-piacon ma uralkodó narratíva szerint a verseny a legnagyobb modellről, a legtöbb paraméterről szól. A nagy szereplők újabb és újabb behemótokat dobnak a piacra, és a hírek azt sugallják, hogy aki nem ezekre vált, az lemarad.

A valóság ennél árnyaltabb. A nagyobb modell drágább, lassabb, és gyakran nem ad érzékelhetően jobb eredményt a tipikus üzleti feladatokon. Ahol viszont valóban különbség mutatkozik — összetett, többlépéses elemzés, hosszabb dokumentumok feldolgozása, számszerű következtetés —, ott a nagyobb modell tényleg értéket teremt.

Az igazán jó AI-stratégia ezért nem azt jelenti, hogy mindig a legnagyobb és legdrágább modellt választjuk. Azt jelenti, hogy objektíven mérünk, megértjük, hogy a saját feladatainkra mi a megfelelő eszköz, és vállaljuk a kicsit komplexebb infrastruktúrát, amely több különböző modellt orkesztrál különböző célokra.

Ez a megközelítés egyébként nem csak az AI-ra igaz. Egy jól vezetett szervezet sem egyetlen szuper-szakértőt alkalmaz minden feladatra: van senior elemzője a stratégiai kérdésekre, van könyvelője a napi munkára, és van junior munkatársa a rutinfeladatokra. Az AI-rendszerek megfelelő használata is hasonló logikát követ.

A DocAI-nál ezt az elvet alkalmazzuk: két különböző modell, két különböző célra, mindegyik ott bevetve, ahol valóban a maximumot tudja hozni. A 122 milliárd paraméteres modellünk most már termelésben fut, és a komplex éjszakai elemzéseket az ügyfeleink reggel kapják meg.

És hogy mit tanultunk a folyamatból? Talán a legfontosabb azt, hogy a hype-pal szembe menni néha kifizetődő. Amikor mindenki „nagyobb, jobb, gyorsabb” jelszóval rohan, az értelmes mérés és a fegyelmezett gondolkodás versenyelőnyt ad.

A DocAI magyar fejlesztésű dokumentumfeldolgozó és üzleti elemző AI-platform. A cikkben bemutatott módszertan és modellek a saját produkciós rendszerünkben futnak. Bármilyen kérdéssel kapcsolatban — akár konkrét bevezetésre, akár stratégiai konzultációra van szüksége — szívesen állok rendelkezésre.

— Kiss Dániel, DocAI fejlesztő

Technikai melléklet — csak technikusoknak

Az alábbi szakasz nem üzleti olvasóknak szól, hanem mérnököknek és ML-szakembereknek, akik maguk is dolgoznak nyelvi modellek bevezetésén. A fenti cikk önmagában is teljes; ez a függelék azoknak ad konkrét fogódzót, akik hasonló projekttel állnak szemben.

Hardver és modell

A teszteket NVIDIA DGX Spark gépen futtattuk (GB10 chip, sm_121a architektúra, 128 GB unified memory). A nagyobb modell: Sehyo/Qwen3.5-122B-A10B-NVFP4. A 4 bites NVFP4 kvantálással a 122 milliárd paraméteres MoE-modell körülbelül 76 GB lemezterületet és nagyjából 72 GB futási memóriát igényel (a fő súlyok mellett külön extra_weights.safetensors fájl tartalmazza a multi-token prediction draft layer súlyait BF16-ban, erről lentebb külön). A kisebb (produkciós) modell: Qwen3.6-35B-A3B-FP8. Futtató környezet: vLLM (0.19.1rc1.dev328), eugr/spark-vllm-docker közösségi konténer-image alapján, amely a GB10 sm_121a architektúrára szabottan tartalmazza az NVFP4 MoE kerneleket. A standard vLLM cu130-nightly image ezeket nem tartalmazza, ez az első buktató, amibe minden Spark-felhasználó beleszalad.

Kritikus akadályok

--load-format=fastsafetensors OOM-kockázat unified memóriában. Diszkrét GPU-n a gpu-memory-utilization flag csak a VRAM-ot szabályozza, a betöltési mmap-peak nem számít bele. GB10 unified memóriáján viszont a két érték ugyanaz, a 72 GB-os modell mmap-peakje plusz a vLLM allokáció együtt OOM-killer-be fut már 0,85-ös beállításnál is. Megoldás: default safetensors loader + 0,75 gpu-memory-utilization.

FlashInfer NVFP4 MoE kernelek sm_121a-n nem támogatottak. A négy FlashInfer NVFP4 MoE backend (FLASHINFER_TRTLLM, FLASHINFER_CUTEDSL, FLASHINFER_CUTEDSL_BATCHED, FLASHINFER_CUTLASS) mindegyike NotImplementedError-ral leáll. Helyettük a VLLM_CUTLASS (default) vagy a MARLIN backend használható.

A Marlin MoE backend „no native FP4 support” warningja félrevezető. A figyelmeztetés azt sugallja, hogy a Marlin valamilyen rossz fallback-en megy. Valójában design szerint mindig weight-only path-ot használ, és sm_121a-n mégis gyorsabb, mint a VLLM_CUTLASS: méréseink szerint +2,3% decode és −7% TTFT a hat tipikus workloadon. Fontos kiegészítés: a Marlin csak teljesen kvantált MoE-modellel működik együtt, ha multi-token prediction (MTP) speculative decodingot is használunk (lásd lentebb), a BF16-os draft layer miatt a Marlin nem alkalmazható, és a vLLM auto-select a VLLM_CUTLASS + TRITON kombinációra esik.

A speculative decoding (MTP) súlyait egyes kvantáló pipeline-ok eltávolítják. A RedHatAI/Qwen3.5-122B-A10B-NVFP4 model card-ja dokumentálja a multi-token prediction speculative decoding támogatását. A gyakorlatban viszont a vLLM 0% acceptance rate-tel indult el (286 draft token → 0 elfogadva), mert a kvantálási pipeline lecsupaszítja a draft layer súlyait, és a vLLM csendben random-inicializál ezek helyett. A Sehyo/Qwen3.5-122B-A10B-NVFP4 ezzel szemben megőrzi ezeket BF16-ban egy külön extra_weights.safetensors fájlban (785 tensor, 4,4 GB). Itt az acceptance rate 74% átlag (JSON-strukturált outputon 100%, magyar prózán 60%), ami a decode-sebességet workload-tól függően 34-78%-kal gyorsítja. Az ár: a draft layer önmagában ~6 GiB-ot vesz el a KV-poolból (concurrency-csökkenés), és a cold-start körülbelül duplájára nő (~22 perc). Cron-feladatra mindkét költség elfogadható. Tanulság: a model card-ot ne hidd el, mérd.

KV-cache FP8 trade-off. A --kv-cache-dtype=fp8_e4m3 flag a KV-pool kapacitást +94%-kal növeli (12 GiB poolban 132 ezer helyett 296 ezer token fér el), ami long context use case-en kritikus. Cserébe a per-token dynamic scaling overhead miatt 10K-tokenes prompt TTFT-je +223%-kal romlik. Cron-jellegű háttér-feladatra ez lényegtelen, interactive chatre fájdalmas.

A KV-pool nem lineárisan skálázódik a max-model-len-nel. A vLLM max_cudagraph_capture_size autotune hosszabb context-en kisebb értéket választ (32 → 16 → 8), és a felszabaduló memóriát hozzáadja a KV-pool-hoz. Eredmény: a 262K context konfig több total KV-tokenű (1,06 millió), mint a 65K config (849 ezer). Ez ellentétes a naív elvárással.

Végleges futtatási konfiguráció

--max-model-len=262144
--max-num-seqs=4
--gpu-memory-utilization=0.75
--max-num-batched-tokens=16384
--attention-backend=FLASHINFER
--reasoning-parser=qwen3
--tool-call-parser=qwen3_coder
--enable-prefix-caching
--enable-auto-tool-choice
--kv-cache-dtype=fp8_e4m3
--speculative-config={"method":"mtp","num_speculative_tokens":2}

Szándékosan kihagyva: --load-format=fastsafetensors (OOM-kockázat unified memóriában), --kernel-config={"moe_backend":"marlin"} (a Sehyo MTP draft layer BF16, a Marlin csak teljesen kvantált MoE-re alkalmazható, a vLLM auto-select VLLM_CUTLASS-t választ a fő MoE-re és TRITON-t a draft layerre), VLLM_USE_FLASHINFER_MOE_FP4=1 (NotImplementedError sm_121a-n).

Mérési kulcsszámok

Concurrency 262K context-en: 1,83× MTP-vel (4,00× MTP nélkül — a draft layer ~6 GiB-ot vesz el a KV-poolból)
Decode sebesség: 25-30 token/s rövid strukturált outputon, 22 token/s hosszú magyar prózán (MTP-vel)
MTP acceptance rate: 74% átlag — JSON-KIE workloadon 100%, magyar prózán 60%
Cold-start indulás: ~22 perc tiszta lapról, ~5 perc cache-warm restart (a draft layer betöltése külön shard)
Latency arány a 35B-prodhoz képest: ~2,2× (a cikk főszövegében szereplő 2,6× az MTP aktiválása előtti snapshot — az MTP iteráció hozta le)
Tool-calling hatékonyság: a 122B átlagosan 4,7 tool-call/scenario, a 35B 8 tool-call/scenario — ötszörös hatékonyság-különbség a sikeres scenariókon

A teljes bring-up jegyzőkönyv (14 fázis, minden mérés eredménye, minden kudarc oka) belső dokumentációban elérhető. Aki hasonló projektet készít elő, és bármelyik ponton elakad, szívesen segítek tanácsokkal. Ennyi tanulás után már szinte erkölcsi kötelesség.