OpenVINO beats Vulkan on the Arc B60 — and we were wrong about SYCL

We publish corrections when we're wrong. This post is one of those, plus a real backend comparison that came out of it.

What we used to say

For months, our internal fleet notes — and our earlier blog post on budget Arc builds — carried this warning:

"Use Vulkan, not SYCL. SYCL produces garbage output on Battlemage."

That was based on a real observation: an ad-hoc llama.cpp SYCL build on our Arc Pro B60 produced broken output. We generalized it to "SYCL is broken on Battlemage, use Vulkan." It made it into our benchmark records' limitations sections. It sounded authoritative. It was also too absolute, and we should have tested the alternatives before publishing the claim.

What we actually tested this week

A reader pointed us at Intel's OpenVINO Model Server (OVMS) — specifically the openvino/model_server:2026.2.1-gpu container, which is Intel's curated serving stack for Arc Pro B-series hardware. We pulled it, loaded Intel's own demo model (OpenVINO/Qwen3-30B-A3B-Instruct-2507-int4-ov), and pointed it at the same Arc Pro B60 we'd been running Vulkan on.

The result, in the OVMS startup log:

Available devices for Open VINO: CPU, GPU
...
state changed to: AVAILABLE after handling: ValidationPassedEvent

OpenVINO's GPU plugin — which uses Level Zero, the same underlying Intel runtime that SYCL builds on — initialized cleanly on the Battlemage B60. No garbage output. No crashes. Validated and serving.

The difference: Intel's container ships a matched oneAPI + Level Zero + NEO driver stack, version-pinned and tested together. Our ad-hoc SYCL build was almost certainly a driver/runtime version mismatch on a fresh architecture — a classic SYCL pitfall, not a Battlemage limitation. The fleet note was measuring our broken build, not the hardware's capability.

The numbers: same B60, two backends

We ran the same 30B-A3B model class on the same Arc Pro B60 (Battlemage BMG G21, 24GB VRAM) under two backends:

Backend	Model	Generation (tok/s)	Prompt processing (tok/s)
llama.cpp Vulkan (Mesa ANV)	Qwen3-Coder-30B-A3B Q4_K_M	38.6	412.3
OpenVINO/OVMS 2026.2.1	Qwen3-30B-A3B-Instruct-2507 INT4	67.95	~630–1100

OpenVINO is roughly 1.76× faster on generation. Not a marginal win — a meaningful one. Full data in bm-012, with the Vulkan baseline in bm-001.

The honest caveats

The 1.76× is directional, not precise, because four things differ between those rows and we have to be honest about it:

1. Measurement protocol. llama.cpp has llama-bench — a purpose-built pp512/tg256 harness. OVMS has no equivalent, so we measured it via the OpenAI streaming API (time-to-first-chunk + generation rate from chunk counting). That's an approximation, not a strict match.
2. Model variant. Instruct-2507 vs Coder. Same 30B-A3B MoE architecture, different weights.
3. Quantization method. OpenVINO NNCF INT4 vs llama.cpp Q4_K_M are different INT4 schemes with different kernel implementations.
4. Prompt length. Our OVMS prompt tokenized to 229 tokens, not the 512 llama-bench uses.

A same-model, GGUF-vs-IR comparison would tighten this, and it's our documented follow-up. But the directional finding is clear: on Battlemage, OpenVINO is the faster path, and it works.

Why OpenVINO wins here

Two things likely contribute:

• INT4 KV cache compression. OpenVINO 2026.2 added INT4 KV cache for Intel GPUs, which cuts KV memory roughly in half vs INT8 and by two-thirds vs FP16. On long-context workloads, that's both a memory and a throughput win.
• Compiled-model caching + continuous batching. OVMS is built for serving — prefix caching, paged attention, dynamic batching. llama.cpp Vulkan is fast at single-stream inference but doesn't have the same serving-oriented optimizations.

If you're running a single prompt at a time for personal use, the gap may be smaller. If you're serving multiple agents from one B60, OVMS's serving features compound with the raw speed.

What we changed

Three things, all in this session:

1. New benchmark: bm-012 — the OpenVINO/OVMS measurement with full limitations documented.
2. Softened the "Vulkan is the only working Battlemage path" limitation on bm-007 and bm-008. Vulkan is what we tested, not the only thing that works.
3. Corrected our earlier blog post on budget Arc builds — the "SYCL produces garbage" line is gone, replaced with a pointer to this finding.

The takeaway

Two lessons, one for readers and one for us.

For readers with an Arc B60 (or considering one): OpenVINO Model Server is worth your time. Pull the 2026.2.1-gpu container, grab a model from the OpenVINO/...-int4-ov collection on Hugging Face, and you'll likely beat your current Vulkan numbers. The B60 is a more capable card than our earlier framing suggested.

For us: we should have tested before we generalized. "SYCL is broken on Battlemage" was a plausible-sounding conclusion from one broken build, and it sat in our docs for months. The fix wasn't expensive — half a day of container-pulling and benchmarking. The lesson: when a claim about a platform's capability rests on a single observation, that's a prompt to test harder, not to publish.

Want the full backend comparison with all caveats? See bm-012. For the broader mid-2026 Arc picture after a year on the bench, see Battlemage one year in. And if you want to check whether your target model fits the B60's 24GB before buying, Model Fit has the math.