[LocalXPU]

Results from two Arc Pro B60 24 GB cards, and the three things that were wrong or missing for that card in the Intel docs.

What

• docs/INTEL_ARC.md: two rows in "What has been run" (2x B60 with --layer-split, and one B60 with part of the experts mirrored in RAM), a short note on the B60 (PCI id, AOT target, setvars.sh under set -u, running without Docker, a misleading startup line on a layer split), and the host and software the rows were measured on.
• docs/COMMUNITY_BENCHMARKS.md and bench/results/2026-10-04-community-2x-arc-pro-b60/: the report in the template's format, with the server configs, engine logs and per-request timings.
• sycl/setup_intel.py: the B60 was listed as e221. Both cards here are 8086:e211 (lspci -nn), so setup called them Intel GPU e211 (xe) and guessed the VRAM from the BAR size. e211 is added. e221 stays: it is also a B60 (another B60 pair in this thread reports 8086:e221), so setup now knows both ids. (An earlier version of this description guessed from the kernel's id list that e221 was not a B60; that was wrong.) tools/test_setup_sycl.py has two new checks (8 tests pass; the new one fails without the table entry).

Numbers

2x Arc Pro B60 24 GB (456 GB/s each, PCIe 3.0 x8), Ryzen 5 5600, 64 GB RAM (62 GiB usable), Ubuntu 24.04, kernel 6.17 (xe), NEO 26.09.37435.12, oneAPI 2026.1.1. 6f32ec0 plus the compile fix and the ring-wait fix (separate PRs), AOT bmg-g21. Context 8,192, KV int8, --spec 4, greedy, one request at a time; every expert resident on both cards:

	decode	prompt (2,129 tokens)
Coder IQ1_M, --layer-split 24	56.6 tok/s	428 tok/s
Flash-Next IQ2_XS, --layer-split 25	58.6 to 61.3 tok/s	436 tok/s

Decode and prompt speed are the server's own timings per request. After 1.9K tokens of code context decode was 57.2 (Coder) and 55.5 (IQ2_XS). One B60, Coder IQ1_M, 4,042 of 12,288 experts mirrored: 11.9 tok/s. The report has every request, draft acceptance, VRAM per card, and what was not tested (streaming, tools, contexts above 2.2K).

Notes

• The INTEL_ARC.md sentence that nobody has run the 0.1.39 port on an Arc is now out of date for the B70 (Intel arc 0.1.39 + perf fixes #809) and for this report; I left the maintainers' sentence alone and said what ran where.
• docs/COMMUNITY_BENCHMARKS.md asks for results-only submissions to stay separate from engine changes. This one has three lines in setup_intel.py and a test; I can split them out if you prefer.
• sycl: enable Arc A770 inference and document measured performance #797 rewrites docs/INTEL_ARC.md and is marked do-not-merge; Intel arc 0.1.39 + perf fixes #809 touches docs/INTEL.md and setup_intel.py in a different place. I expect this to merge cleanly with Intel arc 0.1.39 + perf fixes #809 and to need a rebase over sycl: enable Arc A770 inference and document measured performance #797 if that one lands.

[MaineTim]

Second B60 pair — different box, llama-benchy numbers (engine 0.1.39-sycl)

Adding measurements from another 2x Arc Pro B60 machine for comparison with this PR.

Machine

• 2x Intel Arc Pro B60 24 GB (8086:e221, Battlemage, AOT bmg-g21), xe driver, oneAPI DPC++ 2026.1
• Linux 7.2.8, AMD Ryzen 5 5600XT, 64GB RAM ); cards in asymmetric slots — engine PCIe probes: 3.0 GB/s (card 0, a Gen3 x4 slot at its ~3.94 ceiling) and 7.7 GB/s (card 1, full-width)
• Strata at 6f32ec070f23ced9f50e704d854d775da52591ab, local SYCL AOT build; 3 local SYCL-mirror drift fixes, no engine changes

Model / config

• Coder IQ1_M (ISTA-DASLab/Qwen3.8-Flash-Next-GSQ-RCO-Coder-GGUF @ 5348543e), native pack (iq_pack), bundled expert-profile-coder.bin, MTP drafter (mtp_fetch/mtp_pack q2_0/mtp_rt)
• Serve mode, layer split auto → K=18 (layers 0-17 / 18-47+head), all 12,288 experts in VRAM (4,608 + 7,680), 10.4 GiB free after load; --spec 4 --spec-min-p 0.5, ctx 32,768, KV int8, --vram-reserve-mib 1024

Method

• llama-benchy (via uvx), --pp 2048 --tg 128 --depth 0 8192 32768 --runs 3 --warmup-runs 1 --no-cache --latency-mode generation --extra-body reasoning_effort=none (thinking off, per-request)
• Source text: Project Gutenberg Perf/gfx906 qsa query swizzle #1661, sha256 dbb03a4b... (in the JSON). Fresh prefix every run (engine log: 0 reused). One engine quirk: llama-benchy's pp_throughput/ttfr/est_ppt columns are meaningless against this server (it emits an initial SSE chunk before prefill, so those measure wire latency — 300k+ "tok/s"); prompt speeds below are the engine's own, e2e_ttft and tg are llama-benchy's (mean ± std, 3 runs; client wall-time vs engine timings agree within noise)

Results (llama-benchy table, cross-checked line-by-line against the engine log)

context depth	actual prompt tokens	engine prompt tok/s	tg tok/s (mean ± std)	e2e TTFT (mean)
0	1,694–1,871	559–591	40.8 ± 1.2	3.13 s
8,192	9,017–9,364	674–699	44.6 ± 1.0	13.37 s
32,768	31,455–31,931	773–779	42.8 ± 4.9	40.71 s

• Draft acceptance 65–75% of offered drafts; suffix drafts 44–100%. Engine placement prediction at load was 72.5 ms/window without drafts.
• At 32K, one run ended at 71/128 tokens (model EOS) — the 35.9 outlier in that row.
• Uncontrolled conversation for scale: 2,369 tokens at 38.2 tok/s with thinking on (drafts 1,133/1,656 accepted), coherent output.
• Same model single-card (card 0 alone): 3,670 experts spill into a pinned-RAM mirror over the 3.0 GB/s link → 2.37 tok/s. The split is the whole difference.

Cosmetic engine-log items on the SYCL port (in case they match anything on your side): WARNING: compiled with CUDA 12.8 headers but loaded a CUDA 0.2 runtime (#542 misreading the SYCL cudart stub), compute capability 20.1, and strata verify: captured the N-token window (upload <FIXME: Placeholder>, sync <FIXME: Placeholder>) — an unfilled format slot. Also: load builds a 15.18 GiB pinned-host mirror of the peer card's experts before that card's session carves its VRAM cache; with 100% residency it appears unused after load.

If you need the full config, engine log, and llama-benchy JSON, let me know.

Thanks to all who are making this happen!

[LocalXPU]

Thanks both. MaineTim, your cards being 8086:e221 settles it: e221 is a B60 too, so the note in this PR that it "suggests it is not a B60" was wrong. I've corrected the description and the docs line; the code change already keeps e221 and adds e211, so setup recognises both.

joeyjoe02, thanks for the kSpinMax run. Degenerate output at 200 whenever the host path is used confirms that lowering the bound only hides the host-visibility problem, so it should stay as it is until that is fixed.

[Niko1221]

Fixed in 0.1.40: merged, with the PCI ids e211 and e221 in setup_intel.py. The sentence saying nobody had run the 0.1.39 port on an Arc is rewritten: it did not compile unpatched, and the two B60 reports ran it with #784 and #866 on top.