Az Alibaba a héten bemutatta a Qwen 3.8‑Max modellt, és az indítókommunikációban a Claude Fable 5 mellett a második legerősebbnek pozicionálta. Ugyanakkor független mérések egészen más képhez vezettek: egy nyílt forráskódú teszthám, a VulcanBench által végrehajtott futtatásban a Qwen 3.8‑Max „best effort” (legmagasabb erőfeszítés) beállítása középső helyre került, alapértelmezett beállításban pedig az utolsó lett.
Mindkét eredmény jogosan állhat fenn. A különbség kulcsa a rendelkezésre álló idő- és tokenkeretben rejlik — olyan paraméterekben, amelyek ritkán jelennek meg a címszámokban, mégis meghatározóak a gyakorlatban.
Mennyit számít az idő- és tokentúllépés?
Az Alibaba lábjegyzetben közölt mérési részletei szerint a kódolási tesztekre akár ötórás timeoutot, a PaperBench futtatásokra pedig felül akár 12 órát is engedélyeztek. Ezzel szemben a VulcanBench által használt független testhámok 45–60 percnyi falióra-időkorlátot adtak. Az Alibaba által használt időkeret tehát 5–16-szor nagyobb lehetett, és ez magyarázza a mérési különbségek nagyságrendjét.
Ezért két dolgot kellene rutinszerűvé tenni a modellek kiválasztásakor:
- Használjunk költség per sikeres feladat (cost per successful task) metrikát: az összes kiadást számítsuk bele — beleértve a sikertelen kísérletek költségét is —, és osszuk el a ténylegesen átment feladatok számával.
- Tegyük explicitvé az elfogadási feltételeknél az idő‑ vagy tokenkeretet: ezek ne legyenek rejtett beállítások, mert alapvetően befolyásolják a sikerarányt.
Miért nem elég a tokenár alapján dönteni?
A korábbi, a Qwen 3.8‑Max körüli első összehasonlítások ár‑összehasonlítások voltak, mert csak az áradatok álltak rendelkezésre. A modellek azonban nem csak „kimeneti tokeneket” termelnek: a gondolkodás (reasoning) is tokeneket használ. Egy olyan modell, amely a tokenkeretének jelentős részét a belső érvelésre fordítja, elérheti a tokenlimitet, mielőtt tényleges választ adna — így üres vagy időkorlát miatti nullás eredményt kapsz, miközben a futás teljes költségét elszámoltad.
Példaként az Artificial Analysis mérése jól mutatja ezt: a DeepSeek‑V4‑Flash maximális erőfeszítésű futtatása 210 millió kimeneti tokent generált, miközben az osztály mediánja 100 millió volt. Mivel azonban ezek a tokenárak olcsók voltak, a pénzbeli költség alacsony maradt — de a túlzó verbose (hosszú) kimenet időben is költséges lehet, és ez bizonyos alkalmazásoknál kritikus.
A lényeg: olyan mutató kell, amely az összes költséget számba veszi (beleértve a „vakságba” befutott, token‑ vagy időkorlát miatt sikertelen próbálkozásokat) és a ténylegesen elkészült feladatok számát a megadott idő‑ és tokenkeretben.
A sikerráta egy része konfigurációs kérdés
Az, hogy egy futás hibás választ ad-e vagy egyszerűen kifut az időből, két különálló esemény, és más megoldást igényel. A legtöbb mérőeszköz nem különbözteti meg ezeket, és a legtöbb toplista sem közli az arányokat. A szerző saját agent‑benchmark építése közben szembesült ezzel: a harness csak „hibát” logolt, de nem jelezte az okot — ezért külön kellett vezetni a timeout és a rossz válasz eseteit.
A Long‑Horizon‑Terminal‑Bench vizsgálata (júliusban publikált) 17 frontier modellt futtatott 46 feladaton, egyenként 90 perces próbálkozással. A kifejezett időkorlátok a megoldatlan futások 79%-át adták, míg az önmaguktól leálló ügynökök 19%-ot, a harness hibák pedig 3%-ot. A szerzők óvatosan értelmezik az eredményt: a timeout‑ok nem feltétlenül voltak közel a befejezéshez (átlagos reward 0,10–0,35), tehát nem biztos, hogy több idő előrelépést hozott volna — de a tanulság világos: a benchmarkok implicit módon mérik a időhatékonyságot, akár elismerik, akár nem.
VulcanBench és Claude Opus 5: az erőfeszítés költség‑haszon viszonya
A VulcanBench riportjából (dátum: 2024. július 26.) kiderül, hogy a Claude Opus 5 esetében az alacsonyabb erőfeszítésű beállítás teljesített a legjobban: 23 feladatból 20‑at oldott meg alacsony erőfeszítéssel szemben a magas erőfeszítés 18 megoldásával. A magas erőfeszítés ezzel együtt a legkevesebb rossz (hibás) választ adta (1 rossz vs. 3 rossz), de a több gondolkodás miatt kifutott az időkeret, és a timeout nullapontot eredményezett. Két regresszió olyan feladatnál fordult elő, amelynél az alacsony erőfeszítés sikeres volt; korlátlan idővel a magas erőfeszítés csak döntetlenre jönne ki az olcsó beállítással, és a költsége 3,1× lenne.
Ez közvetlen kockázatot jelent olyan rendszerek számára, amelyek több‑lépcsős routing‑ot használnak: a szokványos stratégia olcsó próbálkozás után magasabb erőfeszítésre „lép fel” a jobb válasz reményében. Sok modell–feladat párosnál ez a feltételezés hamis lehet, így a rendszer a drágább lépcső ára miatt időkorlátba vagy cap‑be fut, anélkül hogy jobb eredményt adna.
Ki mér már így?
Az elmúlt hónapokban több csapat is a sikeres feladatra jutó költség (cost per successful task) bevonása felé mozdult el:
- VulcanBench már a korai riportjaiban is dollárban számolt megoldásonkénti költséget közölt.
- A Long‑Horizon‑Terminal‑Bench feladatokra lebontva közli a költséget és a pontosságot; például a GPT‑5.4 sorában körülbelül 26 dollár per feladat szerepel, alacsonyabb passzráta mellett, míg a Grok 4.5 körülbelül 11 dollárnál áll.
- A TestEvo‑Bench költségkorlátok mellett futtat: Claude Code teszt‑generálási eredménye 71%-ról 44%-ra esik szigorúbb költségplafon alatt.
Továbbá a kereskedelmi szereplők is alkalmaznak hasonló gondolatot:
- HubSpot áprilisban a Breeze Customer Agentet 50 cent per lezárt beszélgetésre állította át, korábban 1 dollár volt per kezeléssel.
- Zendesk per automatizált megoldásonként számláz.
- Fin 99 centet számláz kimenetenként, és csak a teljes végponti megoldásért számláz.
Ajánlott azonnali változtatások
A szerző javaslatai rövid határidővel bevezethetők és javítják a mérési átláthatóságot:
- Minden agent‑futtatásnál legyen kötelező a hibaok mező kitöltése: külön értékként szerepeljen a budget exhaustion (idő/token kifutás), verifier failure (ellenőrző bukása) és harness error. Amíg nem különítjük el a timeoutot a rossz választól, a passzráta két dolgot mér egyszerre.
- Számítsuk a költséget sikeres feladatra erőfeszítés szinten (nem csak modell szinten): az összes költés — beleértve a sikertelen próbálkozásokat — osztva az elfogadási feltételt teljesítő feladatok számával. Ezzel a sorrendek gyakran eltérnek a szolgáltatói árlistától, és az olcsóbb beállítás nyerhet.
- Amennyiben a rendszerben nem valódi szolgáltatási szintelvárás a késleltetés (latency), tokenkorlátot tegyünk meg falióra helyett. A wall‑clock cap a szolgáltató kiszolgálási sebességét is beleértékeli a modell minőségébe.
- Ellenőrizzük minden telepített modell alapértelmezett erőfeszítését. A Qwen 3.8‑Max esetében például, ha az effort mező nincs megadva, a modell a legmagasabb érvelési beállításon fut — és éppen ez a beállítás teljesített legrosszabbul a független tesztekben. A csapat, amely sosem módosítja ezt a paramétert, potenciálisan a legdrágább konfigurációt futtatja per sikeres feladat.
Összegzés
A Qwen 3.8‑Max körüli, látszólag ellentétes benchmark‑eredmények nem ellentmondásos csalás eredményei, hanem a mérési feltételek különbségéből fakadnak: elsősorban az idő‑ és tokenkeretekből. A döntéshozatalban és a benchmarkolásban a költség per sikeres feladat, az erőfeszítési szintek szerinti elemzés és a hibaokok kinyilvánítása javítja az összehasonlíthatóságot és megmutatja, hogy valóban mi fizetődik ki a gyakorlatban.
