# Qwen3.8-27B on one B70 — setup as of August 20, 2026

This bundle accompanies the rewritten [B70 article](/notes/intel-arc-pro-b70-inference-stack/). The historical measurements were collected on August 20; the article was rewritten on September 12. No fresh inference campaign was run for publication.

## Files

- `qwen38-20260820-runs.jsonl`: 24 reduced measured-run records, three for each of eight cells.
- `qwen38-20260820-results.json`: original cell statistics, output hashes, and the recorded correctness outcome.
- `qwen38-20260820-methodology.json`: pinned stack, benchmark controls, source hashes, and the differences between the measured lab configuration and deployed profile.
- `generate-b70-qwen38-figures.mjs`: exact source for the two plots and social-card SVG. From the website repository, run `node scripts/generate-b70-qwen38-figures.mjs`. SVG generation uses only Node built-ins. The PNG social card is a rasterization of that SVG using the repository's installed Sharp 0.33.5.

The older `selected-results.jsonl`, `rejected-mtp-result.json`, quality records, patches, figures, and generator are unchanged. They describe the earlier Qwen3.6/AutoRound/Gemma/GGUF chapter, not the August 20 Qwen3.8 stack.

## Attribution and pinned recipe

- Cookbook: https://github.com/SergiioB/intel-arc-pro-b70-inference-cookbook/tree/1378950ac875ab6962addd1ddaf44550d34c3103
- Recipe: `docs/qwen38-27/QWEN38-VLLM-XPU.md` at that commit.
- Model: `SergiioB/Qwen3.8-27B-GPTQ-Int4-sym-G128-MTP-BF16`, revision `9d189a60e4c0ad7f9f47cd94bfa393ca10b3924e`.
- Image: `vllm/vllm-openai-xpu@sha256:f01e24f6c7ff01f1e0662234255a1372297d1dbd89d003cf13c8fad3eab1ba4f`.
- Installed vLLM: `0.27.2rc1.dev77+gac7509e2b.xpu`; XPU kernels `0.1.12.3`.
- Required patches, in order: `patch_mtp_nightly.py`, then `patch_mtp_boundary.py`. Hashes are in the methodology file.

The recipe, checkpoint, and upstream patches are credited to their authors. Achu used GPT-5.6 Sol's help while working on vLLM. That personal account is not an experimental variable or a claim that every upstream patch was authored locally.

## What was measured

One B70, one client request at a time, 230 W power cap, FP16 target compute, BF16 draft, FP8 KV, XPU graphs. Exact prompt lengths were 16,384, 32,768, 65,536, and 130,560 tokens. Every measured completion contained 512 tokens. Each cell discarded one generic warmup and one full-output same-shape warmup before three measured requests. Temperature was zero, EOS was ignored, and the distinct entropy-first prompts recorded zero prefix-cache hits.

Both recipe modes allowed 64 server sequences, but the client used concurrency one. No-spec used GPU memory utilization 0.90; MTP4 used 0.88. The comparison is between these complete configurations, not a strict one-flag intervention. Configured sequence capacity is not a filled-context measurement.

Decode rate is `(completion_tokens - 1) / post_first_generation_s`, using client monotonic timing after the first generated token. Means and sample standard deviations use the three retained measured records per cell. TTFT includes more than isolated engine prefill, so dividing input tokens by TTFT is not a pure prefill-kernel rate. The latency chart splits mean wall time into mean TTFT and the remaining generation interval. No confidence intervals are claimed.

All 24 raw measured records were checked against the published summary before extraction: prompt/output counts, zero cache hits, decode formula, means, sample standard deviations, and output hashes. The three full-context MTP4 rates were 32.1055, 38.9409, and 38.4075 tok/s. The public reduced records preserve the numeric values without rounding; charts and article tables round for display.

## Correctness and deployment boundaries

The historical record reports 24/24 valid completions, including 12/12 MTP4, after mechanical checks and retained-output coherence review. That is not a coding benchmark, a broad quality evaluation, or a proof of distributional equivalence. Original prompt/completion text and raw operational captures remain private. The hashes identify retained outputs; without those outputs this public bundle cannot independently reproduce the semantic review.

The final production profile changed the server limit to one sequence and enabled exact-prefix caching. It retained the pinned image, model, patches, FP8 KV, BF16 MTP4 draft, and graphs. Its reported KV capacity was 140,530 tokens; the uncached lab MTP4 allocation reported 146,410. These are different startup configurations, not interchangeable measurements. The lab throughput table was not rerun as a full benchmark of the final cached production profile.

A separate prefix-cache canary recorded 39,936 cached tokens on an exact repeat of a 43,264-token chat prompt, with identical output token IDs. This is functional evidence only; full cache eviction/restart/tool-call coverage remains unqualified. The August 20 serving profile is text-only, with a configured tool-call parser and no enabled vision path.

The tested maximum is 130,560 prompt + 512 output = 131,072 total tokens. At that boundary MTP4 improves decode by about 1.52× but has about 171.59 seconds TTFT and no meaningful whole-request gain for the 512-token completion. Do not advertise the decode speedup as an equal end-to-end speedup.

This validates the full pinned compatibility bundle, not an individual patch, the removal of llm-scaler in isolation, all MTP implementations, or newer runtime images. It is not a drop-in installation recipe for an arbitrary host. Private deployment controls, addresses, credentials, model weights, and unrelated host configuration are intentionally excluded.