Ő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.
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ó →