A minap két H100-on is lefuttattam a Qwen3.8-27B-FP8-at, és az MTP-speculative decoding hozta a legnagyobb decode-gyorsulást (49 → 95 tok/s). De van egy bökkenő: a vLLM-ben az MTP és a prefix caching kölcsönösen kizárja egymást, szóval az volt a kérdés, hogy melyik konfigurációt érdemes élesben használni.

A választ úgy kaptam meg, hogy egymás ellen futtattam a két verziót: GPU0 no-MTP + prefix caching, GPU1 MTP (3 draft token). Mindkettő TP1-es, 262K maximum kontextus, FP8 KV cache, és egy LiteLLM proxy osztja el köztük a forgalmat. Az összes szám TTFT p50, hacsak nem írom másképp.

A múltkor azt írtam, hogy a 35B-A3B GPU-only üzemmódban elég jól megy az RTX 4090-en, de a 100k kontextus után eltalálja a VRAM falat. Gondoltam, kipróbálom ezt az új CPU-MoE feature-t a llama.cpp-ben, hátha ki tudom nyomni a 33 GB expert súlyt a system RAM-ba, és így marad hely a KV cache-nek a full 256k kontextushoz.

Bevallom előre: működik, de megvan az ára. Nem is kicsi.

Mit próbáltam?

A lényeg, hogy a --cpu-moe flaggel a modell MoE expert súlyait nem a GPU VRAM-jába töltöd be, hanem a rendszermemóriába. Minden decode tokennél a routing gate eldönti, melyik expert kell (ez 8+1 shared a 256-ból), és azokat on-the-fly DMA-zod át CPU-RAM-ból a GPU-ba.

A minap végre összegeztem az összes Qwen 3.6-os modellteszt eredményemet, amit az elmúlt napokban gyűjtöttem össze. Két modellt hasonlítottam össze részletesen: a Qwen3.6-35B-A3B-t (MoE, hybrid attention/delta) és a Qwen3.6-27B-t (dense, hybrid attention/delta). Mindkettőt turbo3 KV cache kompresszióval futtattam RTX 4090-en, llama.cpp szerverként.

Ha röviden akarnám összefoglalni: a 35B-A3B 3-4× gyorsabb mindenben, de a 27B jobb minőséget ad. Ez a klasszikus MoE vs. dense tradeoff, csak éppen számokkal alátámasztva.

Architektúra - mi a különbség?

A két modell ugyanabból a Qwen3.6 családból való, mindkettő hybrid Mamba/attention architektúrát használ, de a megközelítésük teljesen más: