vLLM og MTP på B70

Jeg skrev for et par dage siden om lokal LLM på Intel Arc Pro B70. Dengang kørte jeg llama.cpp med SYCL til hverdagen. Det virkede. Det var bare ikke hurtigt, når konteksten blev lang. Så skiftede jeg stak. Samme kort, samme hus — vLLM på XPU og en Qwen 3.8 27B INT4 med MTP. OpenWebUI og Hermes peger på den over Tailscale.

Hvad MTP er

Multi-Token Prediction. Modellen gætter flere tokens ad gangen, og den rigtige model tjekker dem. Når gættene rammer, får du flere tokens ud pr. GPU-tur. Det er derfor dense 27B pludselig føles brugbar på B70. Uden MTP ligger en model af den størrelse og kæmper med hukommelsesbåndbredden.

Hvad jeg får ud af vLLM

llama.cpp + SYCL var fint til korte prompts. Decode på en dense 27B lå i den lave ende — brugbart, ikke rap. vLLM rammer Intels W4A16-kerner på kortet. Kort kontekst målte jeg til omkring 42 tok/s. I Hermes med 128k kontekst lander jeg på omkring 26 tok/s. Det er stadig hurtigere end llama.cpp var for mig på samme hardware. 128k passer i de 32 GB VRAM med fp8 KV-cache. En kold 130k-prompt tager flere minutter at æde. Det er kortet, ikke CPU’en. Gentagelser med samme prefix er hurtigere. API’en er almindelig OpenAI-kompatibel. Hermes og OpenWebUI skal bare have en base-URL og model-id qwen38. Ingen data ud af huset.

Hvad jeg ikke gør

Der findes opskrifter der lover 70–80 tok/s med et BF16 MTP-hoved og en bunke patches. Det spiser VRAM, knækker nemmere ved opdateringer, og 128k bliver trangere. Til mit brug er 26 tok/s ved fuld kontekst godt nok. 24 GB system-RAM er det der strammer — ikke processoren. En ny CPU giver ikke flere tokens i chatten. Mere RAM ville mest gøre opstart og Docker mindre bøvlet.

Bottom line

Samme B70. Anden runtime. MTP er det der løfter dense 27B fra “det kører” til “jeg gider bruge det i Hermes”. vLLM er stadig mere bøvl at sætte op end llama.cpp. Når det først kører, er det den stack jeg bruger.