How this compares with other Arc Pro B60 results

Other people are publishing numbers for Qwen3.8-27B on the Intel Arc Pro B60. This page puts them next to ours so you can see where each approach is strong. The raw rows are in data/peer-benchmarks.csv; the community-submitted ones are in COMMUNITY-RESULTS.md.

Read these numbers with care. They are self-reported, the backends differ (llama.cpp Vulkan, llama.cpp SYCL, OpenVINO), the speculative-decoding methods differ (DFlash2, MTP, none), the context depths differ, and the measurement tools differ (llama-bench versus server-reported speeds on a real prompt). Rows were collected on 2026-10-10 from public pages, most with one run per cell. Treat gaps under about 10% as noise.

The short version

• Generation (decode): 42.3 tok/s with a DFlash2 draft model (n=7) is above the highest peer figure we found for a single B60 running Qwen3.8-27B Q4_K_M. It is eval-suite throughput: generated tokens divided by total wall-clock over eight eval requests (seven coding tasks and one web page), with prompt processing and HTTP included, at shallow context. Peers report decode-only speeds, so the comparable figure for this repo is the per-request decode range of 47 to 58 tok/s (mean 53.3), from the same run in tune.txt. We keep 42.3 as the conservative headline. The closest rival is a self-reported 41.28 to 41.88 tok/s on custom lower-bit quants with embedded MTP (SYCL, shallow context, not like-for-like). At about 30K of context our agent turns still generate at 42.2 tok/s, against 32.3 tok/s for the llama.cpp numbers at 28.8K in marfrit/arcint#1.
• Prompt reading (prefill): we are not the fastest. At about 29K context the llama.cpp numbers in that issue read 589 to 638 tok/s; ours read 420 tok/s at 32K. Their OpenVINO runs read 657 tok/s at 32.8K, and 1,094 tok/s at 4K. The Intel FA kernel in this repo takes stock llama.cpp from 118 to 420 tok/s at 32K, but a faster prefill path clearly exists.
• Why the two differ so much: a coding agent re-reads a long conversation on every turn, so prefill matters as much as decode. The honest summary is that this repo is strongest on generation speed and on being reproducible and measured end to end (agent tasks, VRAM headroom, context safety), and not the leader on prefill.

Side by side at comparable depths

All rows are a single Arc Pro B60 and Qwen3.8-27B. The first two blocks are ours (compare-f16.txt, tune.txt, bench-history.csv).

What this tells you:

1. Speculative decoding is where the generation speed comes from. Without a drafter our B60 generates 16.05 tok/s at empty context. The same hardware reaches 42.3 tok/s with DFlash2. The strongest peer runs with MTP land between 31.9 and 41.9 tok/s at shallow context; other self-reported MTP runs on this card are lower (7.9 to 23.0 tok/s, see the full table below).
2. Prefill is the gap. The llama.cpp rows from marfrit read about 40% to 50% faster than ours at similar depth. They use a q8_0 KV cache while we use f16, and they are measured on a real prompt rather than llama-bench, so the comparison is not exact, but the direction is clear.
3. Depth hurts everyone. Decode falls from 36.6 to 32.3 tok/s between 4K and 28.8K in the llama.cpp rows, and from 31.9 to 17.4 tok/s between 4K and 32.8K in the OpenVINO rows. Ours stays near 42 tok/s across the agent turns, but that is a code workload where the drafter does well (573 of 877 drafted tokens accepted, 65%, on a single shallow-context code request in server-test.txt; acceptance was not logged for the agent turns). Expect less on text that drafts poorly.
4. Context budget differs. The marfrit runs used a 131K to 156K window, and we cap at 64K (57 to 61K while the PC is in use) to keep a drafter and f16 KV inside 24GB. Past 130K, an upstream issue reports instant end-of-sequence on this model (llama.cpp #27756), so long windows need their own testing.

Other cards

Two Arc Pro B70 (32GB) results exist for dense 27B models, with no drafter: 1,007 tok/s prompt and 23 tok/s generation (model not named, SergiioB cookbook), and 718 tok/s and 20.4 tok/s for Qwen3.5-27B on SYCL (PMZFX). Our no-drafter B60 figure is 16.05 tok/s. The B70's memory bandwidth is 608 GB/s against the B60's 456 GB/s, 1.33 times higher (gpu-comparison.csv), so the observed gap of 1.27 to 1.43 times (20.4 to 23 tok/s against 16.05) is about what bandwidth alone would suggest (ESTIMATE: different models and builds).

How to compare your own numbers fairly

Use the same tool and the same depths we do: bench/arc-bench.ps1 or bench/arc-bench.sh run llama-bench at depth 0, 16K and 32K with an f16 KV cache, and write a JSON file you can share (COMMUNITY-RESULTS.md). Then state the backend and build, the KV types, and whether a draft model was used.

Corrections are welcome. If a row here misstates your work, or you have a result that belongs in the table, open an issue.

All peer rows

Generated from data/peer-benchmarks.csv by tools/build_tables.py. "n/d" means not stated by the source. Quote notes as given by their authors.