Őszinte, részletes technikai cikkek a DocAI fejlesztéséből: LLM inference tuning, GPU optimalizáció, dokumentumfeldolgozó pipeline-ok, vállalati MI architektúra. Negatív eredmények és tanulságok is. Hetente új poszt.
Hányszor kérünk meg egy 35 milliárd paraméteres modellt, hogy egyetlen szóval válaszoljon? Szeptember közepe óta legalább három döntési modell jelent meg, amely nem ír szöveget, hanem a megadott válaszokhoz rendel valószínűséget. Végigvesszük, mit ígér a Jev, a Laya és a Clef, és mit mond a modellkártyájuk: a Laya angol változata khmer nyelven 0,000-s pontosság mellett 0,952-es konfidenciát mutat. Saját mérés még nincs, a kérdés viszont megvan: kiegészíthető-e a már futó modellünk egy döntési fejjel?
Egyetlen mátrix 55 424 sorát skáláztuk 0,9-től 0,1-ig, és megmértük, mibe kerül magyarul és kínaiul. Két lépcső: a kínai képesség 0,7 és 0,6 között omlik, a magyar szövegbe csúszó kínai kockázata 0,8 alatt nulla. Köztük egyetlen használható dózis van, a magyar ár pedig konstrukcióból nulla.
Kijavítottuk a nemdeterminisztikus top-k kernelt, és ötven feladatból egy még mindig ingadozott. Az előző kör óta azt hittük, a hideg út a gyanús: pontosan fordítva van. A hibás ág a teljes gyorsítótár-találat, ha a közös előtagot egy más hosszúságú kérés írta be; a gyorsítótár kikapcsolása megszünteti, a már ismert „csupa nulla állapot” hiba javítása pedig bent van a rendszerben. A jelenséget egy teljesen másik összeállításon is reprodukáltuk, és egy 1600 tokenes blokkhatárra méretezve előre megjósolva elő is idéztük. Frissítés (09-14): megvan a gyökérok, a kérésütemező kihagyott állapotmentése, és egyetlen sor megszünteti: az eredeti bukó eset a javított kiszolgálón 10/10 bitre azonos. Ráadás: a determinisztikus kernel 21–28 %-kal gyorsabb a mostani megoldásunknál.
Temperature 0, azonos prompt, és a modell futásonként mást válaszol: 50 feladatból 13 instabil, ötnél a kinyert dátum vagy összeg is más. Ugyanez a checkpoint llama.cpp-n 0/50, tehát a hiba a kiszolgáló stackben van. Egyszerre egy kapcsolót billentve a QSA sparse-attention indexer persistent_topk kerneléig jutottunk, amely versenyhelyzetben futásonként más kontextust választ. A javítás egy fájl és egy env-változó, 1,35× prefill-áron: 0/50 instabil, és egy ponttal jobb eredmény. A determinizmus közben leleplezett egy addig véletlennek álcázott második hibamódot is, és egy kétperces szondát adott, amivel bármelyik stack ellenőrizhető.
Ha egy modell nem azt csinálja, amit szeretnénk, két kar van: betanítjuk, vagy megszűrjük a kimenetét. Magyar versen mértük meg, hol vonalzóval eldönthető, mi a jó eredmény. Ami mérhető, azt a szűrő olcsóbban megveszi, mint 64 perc GPU-idő — és harmadannyi kitalált szóval. A hangot viszont nem lehet megvenni: ott a szűrő meg sem mozdul (56,4% → 56,0%), a felismerhetőséget kizárólag a tanítás viszi 56%-ról 92%-ra. Plusz a tankönyvi mutató, ami rossz modellt választott.
Kipróbáltuk a kétszer akkora Llama-3.3-70B-t a produkciós Qwen3.6-35B-A3B ellen 100 valós magyar dokumentumon. A várt eredmény: 30 F1-pont hátrány és 26× lassulás. A nem várt: az egyetlen dimenzió, ahol a Llama jobbnak látszott, egy hibadetektor kimenete volt, és amikor visszanéztük a ground truth-t, kiderült, hogy a szám a fordítottját mutatja a valóságnak. Plusz a képlet, amivel öt perc alatt eldöntöd, hogy egy modell egyáltalán játékban van-e a te vasadon.
Egy gyártó „agent-ready” serving receptet ad ki a modellcsaládunkhoz. Lemértük mindhárom flagjét a saját FP8-as modellünkön: −2,2%, −2,4%, −3,6%, egyik sem került be. Az érdekes rész a harmadik kar: a hosszabb spekulatív draft JSON-kinyerésen +19%, rövid chaten −9%, mert a törésvonal az elfogadási arány mentén húzódik. Plusz egy kellemetlen önvizsgálat arról, hogy 8-as konkurencián mértünk, miközben a valóság 1–3.
Ugyanaz a modell NVFP4-ben: +40% átbocsátás, +69% egyszálú kinyerés — és mégis maradt a block-FP8. A bejáratott F1-mérésünk nem tudott dönteni (a normalizálás után 0,0001 a különbség), a beszélgetés-evalunk sem. A döntést egy harmadik mérés hozta meg: 100 valós dokumentumon a „melyik cég a miénk” hiba 7-ről 12–18-ra ugrott. Plusz egy módszertani önvizsgálat és egy jó hír: a hiba totális, tehát három sor kóddal 100%-ban elkapható.
Két gyártó, ugyanaz a DGX Spark, ellentétes indítási parancs ugyanarra a modellre — az egyik pont azt tiltja, amit a másik előír. Lemértük: a rossz backend 2,0–3,3× lassulás, 10 mérési pont, 0 keresztezés. Aztán a fordulat: ugyanaz a marlin backend NVFP4-en nyer, block-FP8-on veszít. A helyes backend nem a hardver tulajdonsága, hanem a hardver és a kvantálási formátum párosáé, és ezt egyik gyártói model card sem mondja ki.
Az elmúlt hónap DocAI-fejlesztései: a Partner 360 egyetlen képernyőn hozza a partner minden adatát, a cégadat-lekérdezés VIES-ellenőrzéssel bővült, a feltöltött bankszámlakivonatokat a rendszer automatikusan párosítja a számlákkal, új a szerződés- és bérjegyzék-nyilvántartás, a chat-asszisztens pedig már konkrét számlatételekre is válaszol. Plusz: NAV-független bizonylatok és Telegram-integráció.
Nyolc partnercég, egy nap a megszokott DocIT alapoktól a DocAI élő demójáig. Számtech óra az LLM-től az ügynökig, élesben futtatott spontán kérdések, egy kikapcsolva is figyelmet kapó DGX Spark, és egy ötlet, ami a beszélgetésből nőtt ki: a NIS2-audit modul, amibe még a nyáron belevágunk.
Egy 35 milliárd és egy 122 milliárd paraméteres modell szisztematikus összehasonlítása a DocAI saját magyar üzleti eval-harness-én. A nagyobb modell nem nyert a strukturált adatkinyerésen, és 2,6× lassabb, viszont a komplex, többlépéses elemzéseken hat feladatból ötben jobb választ adott, és ötször kevesebb adatlekéréssel. Mindkét modell termelésben, különböző célokra. Plusz a buktatók: NVFP4 sm_121a-n, FlashInfer MoE, KV-cache FP8 trade-off.
Gemma4 candidate eval a DocAI magyar számla KIE corpuson: F1 0.890 vs Qwen3.6 0.975, single-stream decode 30-80%-kal lassabb. De a sebesség-mérés mellékterméke felfedte, hogy az MTP acceptance rate JSON-KIE workloadon 99%, az előző cikk 72.5%-os globális száma ezt teljesen elrejtette. A DocAI workload az MTP architekturális best case-e.
Qwen3.5-122B-A10B NVFP4 single Sparkon, vLLM 0.19.2-vel, MTP-vel: 30 tok/s JSON-KIE 100% MTP acceptance-szel, 64 tok/s aggregate 4 párhuzamos felhasználón, és a stress test, ahol a Spark megtörik a 100K-s párhuzamos kontextusoknál. Production-relevant memory budget, prefix caching és a végén egy őszinte konklúzió: érdemes-e DocAI-be tenni.
Qwen3.6-35B-A3B-FP8 + MTP (multi-token prediction) benchmark DGX Sparkon, GB10 chipen. A vanilla modell ugyanolyan gyors mint a 3.5, de a 16-concurrent stress teszten az MTP +24% throughput-ot és −56% TTFT-t adott, pont ott, ahol a spec decoding elméletileg negatív kellett volna legyen. A unified memory architektúra és a spec decoding váratlan szimbiózisa.
Kétnapos vLLM + Triton MoE tuning maraton a DGX Sparkon, Qwen3.5-35B-A3B-FP8 modellel. A végén a production config 5-7%-kal rosszabb lett. Mit tanultam a pure-kernel vs serving benchmark különbségéről, és hat konkrét tanulság, amit átvehetsz.
A következő cikk már készül. Ha nem akarsz lemaradni, iratkozz fel a kapcsolati űrlapon keresztül, vagy nézz vissza jövő héten.
Üzleti szemmel — ugyanezek a mérések döntési nyelven: Útmutató →