A Qwen3.6 ott hozott, ahol nem kellett volna

Két hete írtam egy cikket arról, hogy 6 óra Triton MoE tuning után 10%-ot rontottam a saját production configomon. Az volt a poén, hogy a pesszimista vég. Most megjött a Qwen3.6-35B-A3B-FP8, és gondoltam, lefuttatom ugyanazt a benchmark szettet, hátha van miről írni.

Van. De nem ott, ahol vártam volna.

Aki csak a végét akarja: a Qwen3.6 ugyanolyan gyors mint a 3.5. Egy kivétellel. Az MTP (multi-token prediction) bekapcsolása a 16-concurrent stress teszten +24% throughput-ot, −56% TTFT-t adott — pont ott, ahol a spec decoding elméletileg NEGATÍV kellett volna legyen. A többi 5000 szó opcionális.

A setup, kicsit átnézve

Ugyanaz a DGX Spark mint előzőleg, ugyanaz a GB10 (Blackwell, SM 12.1, 128 GB unified LPDDR5x), csak most az új FP8 modellel. A cél: ugyanazt a 4-scenario benchmark szettet (single decode, prefill-bound, concurrent stress, chat profile) lefuttatni a 3.6-on is, és megnézni, megéri-e a váltás production-ra.

A tesztek ugyanazok mint az előző cikkben:

• A: single decode — 512 input, 512 output, batch=1
• B: prefill-bound — 8192 input, 256 output, 4 concurrent
• C: concurrent contention — 2048 input, 512 output, 16 concurrent
• D: chat profile — 2048 input, 256 output, 2 concurrent

Plus most minden non-A tesztet lefuttattam két seed-del (42 és 123), mert a phase7 cikkben a C teszt egyik seed-je outlier-t hozott. Kontrollált variancia, ahogy egy rendes benchmark kell.

A stack-ben viszont volt változás a két hét alatt, amit érdemes rögzíteni mielőtt bármit összehasonlítunk:

A driver egy minor patch, a vLLM ~100 commit-tel előrébb. Ezek együtt mozogtak, nem tudom szeparálni őket. De mielőtt a 3.6-ot vizsgálnám, először lefuttattam a 3.5-öt friss stack-en, hogy tiszta baseline legyen.

Phase 7-fresh: kontrollkísérlet a 3.5-ön

Kontrollcsoport nélkül nem működne a story. Ha a 3.6-ot friss image-en mérem, de a 3.5-öt a régin, akkor a különbség modell + stack keveredése lesz. Így ugyanaz a phase7 config, ugyanaz a 3.5 modell, csak friss driver + friss vLLM.

A boot log első meglepetése: a KV pool 174k tokenről 368k tokenre nőtt ugyanazon a gpu-memory-utilization=0.45-ön. 2.12× nagyobb. A VLLM_MEMORY_PROFILER_ESTIMATE_CUDAGRAPHS=1 pontosabb accountingot csinált, és a CUDA graph capture mode is újra bekonfigurálta magát — új hybrid FULL_AND_PIECEWISE mode jelent meg, 11 piecewise + 7 full graph.

A mérési eredmény:

A KIE workload prefill-ben 20%-kal gyorsabb lett. Két hét alatt, config változás nélkül. A driver+vLLM páros valamit összehozott, aminek a legnagyobb haszna a hosszú kontextus prefill-jére esik. Pozitív starting point a 3.6 teszthez.

Egy csúnya részlet: az A teszt P99 TTFT 176 ms-ról 705 ms-ra ugrott. A P95 208 ms, tehát ez egyetlen request kiugrása 20-ból — cold-path init a benchmark elején, amit a 3 warmup request nem takart le. Nem zavaró production-ban, de a JSON-ben ott van. Ezt a 3.6 tesztnél is figyeltem, és kiderült: ott is megvan (687 ms). Tehát ez benchmark-metodológiai, nem modell- vagy stack-hatás. Zárójel.

A főesemény első fele: Qwen3.6 vanilla

Ugyanazt a phase7 configot átviszem a 3.6-ra, csak a modell path változik meg. A docker-compose egyetlen érdemi módosítása: Qwen/Qwen3.5-35B-A3B-FP8 → Qwen/Qwen3.6-35B-A3B-FP8. Boot, figyelem a logokat.

Pár érdekes megfigyelés:

1. A vLLM a 3.6-ot is Qwen3_5MoeForConditionalGeneration-ként resolve-olja. Nem hiba — a HF model card is ezt adja, a config.json-ban is ez a model_type. Ez azt jelenti, hogy a 3.6 a vLLM szemszögéből lényegében a 3.5 architektúrája újra tanítva. Ugyanaz a loader, ugyanazok a kernelek (CUTLASS FP8, Triton MoE, GDN prefill), ugyanaz a Mamba cache align logika, ugyanaz az MoE config warning (E=256, N=512, device_name=NVIDIA_GB10 konfig továbbra sincs).

2. 42 safetensors shard vs 14. A checkpoint mérete ugyanannyi (34.89 GiB), de a 3.6 sokkal több fájlra van vágva. Következmény: a weights loading 87 sec helyett 289 sec. Cold boot-on 3.5 perccel hosszabb.

3. KV pool kicsit kisebb lett: 368k → 360k token (−2.3%). A 3.6 model card 256 Expert + 1 Shared architektúrát említ. A routed expert-ek száma (256) és mérete (512) ugyanaz, de az új shared expert minden token-re +1 dense FFN activation-t jelent a profiling során. A weights mérete nem nőtt, de a max-batch forward pass activation memóriája igen.

4. Minden más ugyanaz. Ugyanaz a FLASHINFER attention backend, ugyanaz a TRITON MoE, ugyanaz a Mamba align warning, ugyanaz a default sampling params a generation_config.json-ból.

A várakozásom: enyhe TPOT regresszió a shared expert miatt, minden más marad. Nézzük:

Szinte minden zaj. 24 metrikából 22 ±2%-on belül. A C teszt TPOT konzisztensen +1.1%-kal rosszabb — ez a shared expert csendes adója, pontosan akkora amekkora várható volt. A shared expert minden decode step-en +1 dense FFN-nyi extra compute-ot jelent. Ez token-szinten mérhető, throughput-szinten alig.

Na, itt tartanék a cikkel, ha nincs egy ötletem. Mielőtt leállítottam volna az instance-t, eszembe jutott, hogy a 3.6 a qwen3_next_mtp speculative decoding-ot built-in támogatja. A model card úgy említi, mint ajánlott production config a single-user path-okhoz.

Gondoltam, teszteljük meg azt is.

A főesemény második fele: MTP

Multi-Token Prediction: a modell 2-4 tokent „megjósol” minden decode step-ben, és a fő modell parallel verifikálja őket. Ha az acceptance rate magas, több ingyen token jön minden step-re. A hagyományos implementáció (EAGLE, Medusa) külön draft model weights-eket igényel — a Qwen3.6 viszont built-in MTP heads-ekkel érkezik, amik megosztják az embedding és lm_head súlyokat a fő modellel.

A konfig minimális:

--speculative-config '{"method":"qwen3_next_mtp","num_speculative_tokens":2}'

A vLLM rögtön javított: a qwen3_next_mtp metódust mtp-re renameolták egy nyugodt éjszakán, a HF doksi ennek megfelelően elavult, de az aliased redirect miatt működik a régi név is. Majd a docs-ot frissítik a Qwen srácok, remélem.

A boot log három új dolgot mondott, amiket érdemes rögzíteni:

Detected MTP model. Sharing target model embedding weights with the draft model.
Detected MTP model. Sharing target model lm_head weights with the draft model.

A draft model nem egy külön 35 GB — csak az MTP heads (~500 MB) töltődik be plusz, az embedding és lm_head megoszlik. A Model loading took 35.02 GiB memory — összesen +0.79 GiB az MTP miatt. Okos implementáció.

CUDAGraphMode.FULL_AND_PIECEWISE is not supported with spec-decode for attention backend FlashInferBackend
(support: AttentionCGSupport.UNIFORM_SINGLE_TOKEN_DECODE); setting cudagraph_mode=PIECEWISE

Rejtett adó: az MTP bekapcsolása automatikusan visszaváltja a CUDA graph mode-ot a gyengébb PIECEWISE-ra. A vanilla phase8 FULL_AND_PIECEWISE-t használt, ez egy hátrány indulás előtt.

GPU KV cache size: 323,456 tokens
Maximum concurrency for 131,072 tokens per request: 8.24x

A KV pool −10% a vanillához képest: 360k → 323k token. Az MTP heads memóriája, a padding layers, a PIECEWISE activation overhead együtt ~37k token-t zabálnak fel. A max-num-seqs=32 mellett még mindig elég, de egy újabb rejtett költség.

Tehát: +500 MB súly, PIECEWISE graph mode, kisebb KV pool. Az MTP nyeresége ezek ellen kell, hogy dolgozzon.

Az eredmények

Amikor elindítottam a benchmarkot, az A tesztnél minden 10 másodpercben bejött egy SpecDecoding metrics sor a logba. Reggel 5:00:39-kor ezt láttam:

Mean acceptance length: 2.50, Avg Draft acceptance rate: 74.9%

2.5 accepted token draft-onként (max lehetséges: 2, de az acceptance length a fő tokent is számolja, úgyhogy ez ~1.5 extra token per step). A stabil 70%+ acceptance rate szuper — a spec decoding elmélete alapján ebből jelentős throughput nyereség kell jöjjön.

Az A teszt teljes kimenete:

Acceptance rate (%):                     71.63
Acceptance length:                       2.43
Drafts:                                  4211
Draft tokens:                            8422
Accepted tokens:                         6033
Per-position acceptance (%):
  Position 0:                            81.81
  Position 1:                            61.46

A position 0 (az első spec token) 81.8%-os elfogadottsága mutatja, hogy a draft head jól van tanítva — a modell a következő tokent majdnem mindig el tudja találni. A position 1 már csak 61.5% — a második spec token sokkal bizonytalanabb. Ha csak num_speculative_tokens=1 lenne, magasabb per-token hatékonyság jönne ki, de abszolút számban a 2-tokenes spec több tokent nyer.

A futás után a Prometheus metrics endpoint is kiadta a globális aggregátumot:

Total drafts:           41,568
Total draft tokens:     83,136
Total accepted tokens:  60,298
Position 0 accepted:    33,909  (81.57%)
Position 1 accepted:    26,389  (63.48%)
→ Overall acceptance: 72.53%

Konzisztens a teszt-szintű számokkal. A 72.53% globális acceptance rate a spec decoding szempontjából kimagasló. 50% alatt overhead, 60% felett profitable, 70%+ az már tankönyvszerű eset. A Qwen team komoly munkát tett bele az MTP heads tréningjébe.

Most nézzük a throughput számokat:

Oké, álljunk meg. Ez négy teszt, négy különböző sztori.

A teszt: amit vártunk

Single decode, batch=1. A textbook eset a spec decoding-nek. +8.7% throughput, −8.4% TPOT, acceptance rate 71.6%. Ennyi. A P99 TPOT megnőtt (+9.8%), de ez is várható volt: amikor a draft reject-elődik, a teljes forward pass „elveszett”, tehát a tail latency kicsit romlik a mean javulásáért cserébe.

Ha single-user chatet szolgálsz ki, kapcsold be. 9% throughput szinte ingyen, a P99 adó elhanyagolható.

D teszt: a chat agent

2 concurrent user, 2k context, 256 output. +5% throughput, −30% TTFT. Mérsékelt, de következetes nyereség. Ez a „mindennapi chat” profile, ahol senki nem panaszkodna ha 5%-kal gyorsabb, és a user tapasztalat érezhetően javul a TTFT csökkenéstől.

Megjegyzés: a D teszt Mean ITL 55 ms, miközben a Mean TPOT csak 23.5 ms. A különbség az, hogy a TPOT a decode phase inter-token idejét méri (ignore-olva a prefill-t), az ITL pedig minden token-párok közötti időt, beleértve a spec decoding „burst”-ok közötti szüneteket. Amikor több token egyszerre érkezik (pl. 2 accepted spec), az egyik ITL 0 körül van, a következő hosszabb. A TPOT a simább, hasznosabb metrika ilyenkor.

B teszt: a katasztrófa, vagy mégse

Mean TTFT: −39%, Mean TPOT: +30.7%, Output tok/s: −7.2%.

Ez ellentmondásos. A TTFT (time to first token) javult, a TPOT (time per output token) romlott. Az összesített throughput mérsékelten negatív.

Mi történik itt? A B teszt 8k input, 256 output, 4 concurrent. A long context prefill-je komoly compute-igényű. Az MTP viszont per-token overhead-et ad: minden decode step-ben +1 draft forward, +2 spec verification. 4 concurrent request esetén a spec verification és a fő decode együtt több compute-ot igényel, mint a vanilla decode, és a Mamba/GDN state frissítés nem skálázódik jól. Eredmény: a decode phase lassabb, a prefill (ahol az MTP nem aktív) pedig kihasználja a kisebb contention-t, gyorsabb TTFT jön ki.

Van még egy csúnya részlet: a P99 ITL = 1053 ms, egy teljes másodperces spike. Mean ITL 120 ms. Ez nem zaj, a két seed mindegyike 1000+ ms P99-et ad (1063 és 1043 ms). Hipotézis: preemption esemény a 4 concurrent prefill-nél. Amikor mind a 4 request egyszerre megy prefill phase-be, a decode step-ek queueolódnak, és az MTP draft verification ezt rontja — a spec decoding kevésbé érzékeny preemption-re mint egy sima generate step.

Gyakorlati konzekvencia: ha a workload long context + concurrent prefill (pl. egy DocAI KIE pipeline amikor 4 dokumentumot dolgoz fel párhuzamosan), az MTP-t kapcsold ki. Vanilla gyorsabb lesz és stabilabb a tail-en.

C teszt: amire nem számítottam

Output tok/s: +24.2%. Mean TTFT: −56.7%. Mean TPOT: −17.1%.

Ez valami egészen más.

Az volt az elvárás, hogy a 16-concurrent stress teszt semleges vagy negatív lesz az MTP-vel. A concurrent batch-olás elméletileg már kihasználja a GPU-t — a spec verifikáció csak overhead, ami nem talál helyet a compute utilization-ben.

A C teszten ugyanazok a number-ök:

• Acceptance rate 72.9% — megfelelő, de nem kiugró
• Mean acceptance length 2.44 — stabil
• 13 400 draft per seed, 26 500 draft token per seed — bőven van minta

És az eredmény: +24% throughput, −56% TTFT, −17% TPOT. Minden irányban jobb.

Leültem és gondolkoztam egy sort. Honnan?

A válasz, azt hiszem, a GB10 unified memory architektúra. A DGX Spark nem dedikált VRAM-mal dolgozik, hanem 128 GB LPDDR5x-en osztoznak a CPU és a GPU. A 16-concurrent batch decode valószínűleg nem compute-bound, hanem memory-bandwidth-bound — a Triton MoE kernel 8 expert per token lekéri a súlyokat a LPDDR5x-ről, és ez a bandwidth szerializálódik. A compute-oldalon marad kihasználatlan kapacitás.

Az MTP verifikáció pont ezt a kihasználatlan compute-ot tölti ki. A spec tokens a következő step-ek draft hypothesis-eit párhuzamosan verifikálják, és mivel a memory transfer már folyamatban van (ugyanazok a súlyok), az extra compute lényegében „ingyen” van. A token-generation rate megugrik, a TTFT pedig csökken mert a párhuzamos request-ek kevesebb időt töltenek queue-ban (rövidebb a decode phase → hamarabb feldolgozódnak).

Ez DGX Spark specifikus. Egy H100-on vagy A100-on a 16 concurrent batch kitölti a compute-ot, és az MTP verifikáció már overhead lesz. A GB10-en a compute / memory ratio más, és ez az architekturális adottság teszi a spec decoding-ot ilyen aránytalanul hasznossá ezen a workload-on.

Ha ez igaz, az érdekes következmény: minél jobban memory-bandwidth-bound a workload, annál jobban nyer az MTP. A C teszt 2k context × 16 concurrent (= 32k aktív KV cache tokens per step) pont ez. A B teszt 8k × 4 (= 32k is, de hosszabb context → lassabb prefill → több scheduler contention) már másképp viselkedik.

A nagy kép

Nézzük együtt a négy tesztet, és alakítsunk belőle egy döntési táblát a cikk használhatóságához:

A C teszt meglepetése teszi a Qwen3.6 váltást megéri-való dolognak. Nem a nyers modell sebessége — a vanilla 3.6 és 3.5 gyakorlatilag azonos teljesítményt nyújt, ±1% különbséggel. Hanem a built-in MTP heads, amikkel a 3.5 nem tudott volna kijönni (nincsenek), és amikkel a 3.6 a production chat agent workload-on mérhetően gyorsabb.

Akkor most mit tanultam?

Hat tanulság, fontossági sorrendben:

1. A spec decoding GB10-on másképp viselkedik

A klasszikus bölcsesség szerint a speculative decoding single-user path-ra jó, concurrent load-ra rossz. A DGX Spark unified memory architektúráján ez fordítva van a középső concurrent tartományban. A 16-concurrent teszten +24%-ot hozott, amikor egy H100-on nulla vagy negatív lenne. A hardverre-specifikusan optimalizálódó serving config egy valódi dolog, és a közös GPU ajánlásoknak („spec decoding only helps single user”) a te hardvereden nem feltétlenül van igazuk.

2. A shared expert csendes adó

A 3.6 új shared expert-je minden decode step-re +1 dense FFN forward-ot jelent. Ez a C teszt TPOT-jában +1.1%-os regresszióként jelentkezik — pontosan akkora, amekkora architekturálisan elvárható. Senki nem méri ezt le, a Qwen model card sem említi. Ha a model card benchmarkjaid (SWE-bench, AIME, stb.) nem javulnak legalább 1%-os nagyságrenddel, a shared expert inkább adó mint befektetés.

3. A vLLM 3.6-ot 3.5-ként resolve-olja

A Qwen3_5MoeForConditionalGeneration resolve a 3.6 betöltésekor meglepett. A config.json-ban így van deklarálva, a vLLM így kezeli. Ez azt jelenti, hogy a 3.5-re írt optimalizációk (tuned MoE config, ha lenne, custom scheduler beállítások) a 3.6-on változtatás nélkül működnek. Ugyanakkor azt is, hogy a 3.6-specifikus architektúra-változások (shared expert) nem külön code path-on futnak, hanem implicit a súlyokon keresztül. Good news for drop-in replacement.

4. Az MTP memóriahatása várakoztat

+500 MB súly, PIECEWISE CUDA graph mode (visszalépés a FULL_AND_PIECEWISE-ról), −10% KV pool. A rejtett költségeket érdemes érteni, és ha a KV pool szoros volt, az MTP bekapcsolása előtt érdemes gpu-memory-utilization-t feljebb húzni, vagy a max-num-seqs-t lejjebb venni.

5. A TPOT és ITL nem ugyanaz, különösen spec decodinggal

A mean ITL 55 ms, a mean TPOT 23.5 ms a D teszten. A különbség az, hogy a TPOT a steady-state decode-ra vonatkozik, az ITL meg minden token-közti időt mér, beleértve a spec decoding burst-ok közötti „mélységeket”. Ha egy kliens UX-et mérsz (felhasználó szemszöge), az ITL érdekes. Ha a modell kapacitását méred, a TPOT. Spec decoding esetén ne használd őket felcserélhetően.

6. Mindig futtasd le a kontrollt

Ha csak a 3.6-ot mértem volna friss image-en, de a 3.5 phase7-es számait a 2 hetes image-ről hagyom, akkor az „MTP concurrent win” nem volt volna tiszta — keveredett volna az image változás hatásával. A phase7-fresh mérés 25 perce bőven megérte. Mielőtt a lelkes interpretációba belekezdesz, mérd meg, mi változott közben.

Az MTP acceptance rate anatómiája

Pár szám, amit érdemes tudni a Qwen3.6 MTP working-jéről:

A position 1 63%-os értéke érdekes. Ha num_speculative_tokens=1 lenne beállítva, a rendszer csak az első spec tokent verifikálná — 81.6% acceptance, de csak 1 potenciális extra token per step. A num_speculative_tokens=2 mellett 72.5% átlag, de max 2 extra token per step. Kérdés, hogy a 81.6% × 1 vagy 72.5% × 2 ad jobb throughput-ot. Első látásra a 2×-es a jobb (0.816 extra vs 1.450 extra tokens per step), de ez a compute cost-tól is függ — 2 spec token duplázza a verification work-et.

Nem teszteltem num_speculative_tokens=1-et. Legközelebbi iteráció dolga. Érzés szerint a 2 token közel az optimumon van a GB10-re, a 3 token már túl agresszív lenne (position 2 valószínűleg 40% körül lenne, ami éppen megéri a compute-ot).

Mit lehet még csinálni?

Pár ötlet ami felmerült, de nem próbáltam ki, mert a cikket valamikor le kell zárni:

• num_speculative_tokens=1 vs =2 vs =3 összehasonlítás: a fentiek alapján.
• MTP + max-num-batched-tokens kombinációk: az előző cikkben a 16k chunk ment a production configba. Érdekes lenne látni, hogy MTP-vel a 8k vagy 32k hogy viselkedik.
• Intelligence / output quality mérés: ez a cikk csak a sebességről szól. A 3.6 vs 3.5 modellintelligencia kérdését (magyar KIE accuracy, tool calling reliability, reasoning) egy külön eval harness-szel kell mérni, amit épp most tervezek felépíteni a DocAI-ra. Ha jön a 3.7 vagy a Gemma5, akkor kellenek az objektív számok, hogy megéri-e váltani. Ebből egy külön cikk lesz.
• Speculative decoding a 3.5-ön is?: a 3.5 nem támogat beépített MTP-t, de EAGLE-2 vagy Medusa utólag illeszthető. Érdekes lenne látni, hogy kontrollként ugyanilyen acceptance rate-et ad-e. Nem most.

Végső production config

A production-ba a 3.6 + MTP kerül:

--max-model-len 131072
--max-num-batched-tokens 16384
--gpu-memory-utilization 0.45
--max-num-seqs 32
--kv-cache-dtype fp8_e4m3
--enable-chunked-prefill
--enable-prefix-caching
--no-async-scheduling
--speculative-config '{"method":"qwen3_next_mtp","num_speculative_tokens":2}'

A chat agent, a KIE pipeline egyke-dokumentumos path, és a D-szerű concurrent chat workload mind jobban teljesít így. A B-szerű long context concurrent prefill (pl. 4 PDF párhuzamos feldolgozás) egyelőre ritka a DocAI workload-ban, de ha majd gyakoribb lesz, külön instance-on, MTP nélkül fut majd. Dual config, két port, split workload — a production egyszerűségének a vége, de érthető okból.

Tanulság

Az előző cikkem végén 6 órát elpocsékoltam Triton MoE tuninggal, és a production-om 5-7%-kal rosszabb lett. Kiírtam magamból a pesszimizmust. Most megjött a Qwen3.6, én simán futtattam rajta a benchmark-ot, kaptam egy kb. azonos eredményt, és aztán bekapcsoltam egy flaget — és egy olyan workload-on, ahol vártam, hogy ront (16-concurrent stress), +24% throughput jött.

Nem abban van a sztori hogy „kiváló új modell, váltsunk”. A vanilla 3.6 és 3.5 ugyanolyan gyors. A történet az, hogy az új modell új képességeket hozott, amik közül az MTP pont a GB10 architektúrával szimbiózisban működik, és ezt senki a Qwen csapatból, vLLM-ből, NVIDIA-ból nem tudta előre mondani a konkrét számokkal. Le kellett mérni.

A Qwen3.6 nem attól jó, hogy okosabb (a Qwen számok szerint igen, de azt más eval harness-szel kell majd leellenőrizni). Hanem attól, hogy két flag bekapcsolása után a DGX Spark concurrent throughput 24%-kal nő. És ha ez reprodukálható más Blackwell-generációs unified memory hardveren (Jetson Thor, DGX B200), akkor ez nem edge case.

Köszönetnyilvánítás

Az egész nyomozás közben Claude volt a partnerem a terminálba érkezett log-parser és kísérleti javaslat szerepben. A benchmark script paraméterezést, a docker-compose variáns készítést, az interpretáció-ellenőrzést ő csinálta — amikor a phase8-mtp eredményeit először ránéztem, az volt a reakcióm „hát a B tesztet elrontotta, a C-t meg a csoda tudja miért ilyen”. Claude volt az, aki kitartott amellett, hogy a C +24% nem mérési hiba, és felvetette a memory-bandwidth-bound hipotézist, amit aztán a számok megerősítettek.

Ha kétórás benchmark-maratonra kell partner a logok és JSON-ök fölé hajolva, jó választás.

---

Rendszer: NVIDIA DGX Spark, GB10 (SM 12.1), 128 GB LPDDR5x unified memory
Driver: NVIDIA 580.142, CUDA 13.0
Modell: Qwen/Qwen3.6-35B-A3B-FP8 (vLLM-ből ezen a napon Qwen3_5MoeForConditionalGeneration-ként resolve-olva, 40 layer, E=256 MoE + 1 shared expert)
vLLM: 0.19.1rc1.dev328+g18013df6a (cu130-nightly image, 2026-04-18 pulled, +pandas Dockerfile layer)
Benchmark eszköz: vllm bench serve (built-in)

Minden JSON eredmény, docker-compose fájl, MTP acceptance metrics, valamint a phase7-fresh kontrollcsoport mérése elérhető — ha érdekel a reprodukció vagy a részletes percentile-eloszlások, írj.