Add six measured single-card B70 results (vLLM, OpenVINO GenAI, Cascadia, llama.cpp)

[SergiioB]

What this is

Six benchmark results measured on my Arc Pro B70 rig (rig 6, "B70 Workstation"), all targeting one card via the component field since the rig is registered as 2× B70. Coverage: three models — Qwen3.8-27B (dense, GDN hybrid attention), Qwen3.6-27B (dense), Qwen3.6-35B-A3B (MoE, 3B active) — across four runtimes: vLLM XPU, OpenVINO GenAI, Cascadia, and llama.cpp SYCL.

File	Model / quant	Runtime	decode tok/s	Cell
2026-09-14-qwen3-8-27b-int4-vllm	Qwen3.8-27B / int4	vLLM	106.7	C1 p512/g128, MTP4
2026-08-30-qwen3-6-35b-a3b-int4-vllm	Qwen3.6-35B-A3B / int4	vLLM	170.91	C1 p512/g128, MTP4
2026-08-30-qwen3-6-27b-int4-vllm	Qwen3.6-27B / int4	vLLM	69.3	C1 p512/g128, MTP4
2026-09-14-qwen3-8-27b-int8-openvino-genai	Qwen3.8-27B / int8	OpenVINO GenAI	62.07	C1 p512/g128, MTP nat5
2026-09-11-qwen3-8-27b-int4-cascadia	Qwen3.8-27B / int4	Cascadia	4.97	C1 p128/g128, no spec
2026-09-14-qwen3-8-27b-q4-k-m-llamacpp	Qwen3.8-27B / q4_k_m	llama.cpp	20.01	tg128@p512, no spec

Measurement discipline

• Every decode number is a median of n=5 post-warmup samples at C1 (the llama.cpp entry is llama-bench engine-native tg, mean of 5 raw repetitions). No screening or single-sample numbers.
• Each file's notes carry the full claim: metric semantics (client post-first vs engine-native vs wall-including-prefill), cache state, speculation policy, sampling class, configured cap vs measured draw where available, checkpoint identity, image digests, and correctness scope. All runs are self-reported (E2) with published raw evidence in my cookbook.
• The OpenVINO and llama.cpp decode cells come from the same 2026-09-14 cross-engine sweep protocol (same filler task, same lengths), so they are directly comparable to each other.
• Deliberately excluded: n=3 screen cells (e.g. OpenVINO INT4-GDN8+MTP5 79.5 @512 — measured but provisional until a fresh n=5), two-card TP2 sweeps, and any number whose campaign is still marked provisional.

Notes on catalog mapping

• GPTQ-INT4 vLLM checkpoints are filed under the int4 boards, matching how the boards are defined for these models.
• Three more measured results are held back until their catalog entries exist: Nemotron-3.5-Lightning-30B-A3B GPTQ-INT4 (186.61 tok/s DFlash n7, n=5 — needs a gptq-4bit board on the model) and Muse-Glimmer-30B / Ornith-1.5-35B-A3B (need model entries). Happy to send a catalog PR for these if you want them.

All numbers were measured on my own hardware and are submitted as self-reported evidence-backed results, per the result-file schema and the ingestion check.

[vercel]

@SergiioB is attempting to deploy a commit to the Community Labs Team on Vercel.

A member of the Team first needs to authorize it.

[github-actions]

- results/SergiioB/2026-08-30-qwen3-6-27b-int4-vllm.json: imported (result 42)
- results/SergiioB/2026-08-30-qwen3-6-35b-a3b-int4-vllm.json: imported (result 43)
- results/SergiioB/2026-09-11-qwen3-8-27b-int4-cascadia.json: imported (result 44)
- results/SergiioB/2026-09-14-qwen3-8-27b-int4-vllm.json: imported (result 45)
- results/SergiioB/2026-09-14-qwen3-8-27b-int8-openvino-genai.json: imported (result 46)
- results/SergiioB/2026-09-14-qwen3-8-27b-q4-k-m-llamacpp.json: imported (result 47)
Merge ingestion completed. Rerunning this workflow will not duplicate these results.

Site / sign up · Workflow details and retry