TL;DR: the silicon is real, the software will eat your weekends, and under sustained compute load the card crashes in a way that no setting, driver update, or serving stack I tried can prevent. I pulled it from my fleet. If you're buying a GPU to serve LLMs, buy something else until Intel ships a fix.
Context #
I run a small self-hosted inference fleet for ModDog, an AI Discord moderation bot I'm building. Nothing exotic: a few consumer and workstation GPUs on a LAN serving 3B to 12B models with vLLM, sustained real traffic in the hundreds of messages per second across the fleet. The other cards are an NVIDIA RTX 3080 Ti and two AMD R9700s, which matters later.
The Arc Pro B70 looked great on paper: 32GB of VRAM for about $1,000, a price-per-gigabyte NVIDIA doesn't come close to. I wanted it as a serving card for quantized mid-size models. Solo peak throughput measured 633 messages per second on my 3B judge model, which would have made it the fastest card in the fleet.
Would have.
What worked #
I want to be fair here, because the failure is specific. In a gentle configuration (spiky pull-model traffic at 24 to 32 concurrent requests, idle gaps between bursts) the card served for weeks without a hiccup. Light duty is genuinely fine. If your workload is a desktop app doing occasional inference, you might never see any of this and wonder what I'm on about.
What broke #
Sustained load. Drive continuous chat completions at 32 to 96 concurrent and the card dies somewhere between 24 seconds and a few minutes in. The dmesg signature:
Tile0: GT0: Engine memory CAT error [5]: class=ccs, logical_mask: 0x1
... Engine reset: engine_class=ccs
... Engine reset: engine_class=bcs
The serving process gets UR_RESULT_ERROR_DEVICE_LOST
and that's that. I hit this ten times in one day across four different engine configurations.
Worse than the crash itself: the damage accumulates. After roughly three resets, load levels that previously ran clean start crashing too, and other processes on the same card destabilize. Only a full host reboot restores the card. On a later driver, the kernel log signature disappeared entirely while the crashes continued, so you can't even alert on dmesg reliably.
Stack at the time: Arc Pro B70 32GB, Ubuntu 26.04, kernel 7.0, libze1 1.28.6, libze-intel-gpu1 26.22, vLLM XPU backend on PyTorch 2.12+xpu.
Everything I ruled out #
I spent the better part of two weeks assuming this was my fault. In rough order:
Thermals. Chased this one hard because the community suspected a crash cluster around 60-65C. The card does die at 60C. It also dies at 58C when force-clocked down to 1400MHz, and that run diedfastest(55 seconds). Coolest run, quickest death. Not thermals.Power. 150W cap, 120W cap, no change in behavior. Quality shared PSU, and two AMD cards on the same rails ran heavy load all day, every day.Load pacing. I built a token-bucket throttle to hold the card inside its known-safe envelope (120 msg/s, 24 in flight). It still threw engine resets six minutes into a realistic traffic profile. Staying inside the envelope doesn't save you; the envelope moves.PCIe link. This one's embarrassing. I chased a phantom Gen1 x1 reading for a day before realizing Battlemage's internal virtual bridge ports report placeholder link caps. The real upstream link measured a healthy Gen3 x4 at ~1.9 GiB/s. Lesson learned about trusting lspci on this card.Driver and firmware updates. Upgraded compute-runtime 26.22 to 26.27 plus a GuC firmware update. Same DEVICE_LOST, roughly 90 seconds into the same test, except now without the kernel log breadcrumbs.Level Zero adapter flags.UR__USE_LEVEL_ZERO_V2=0
, copy-offload disabled, every combination. One flag turned an instant crash into a slower crash. Nothing survived a 30-minute soak.- And the crash timing is stochastic anyway: 55 to 385 seconds under identical conditions, indifferent to power, clocks, and temperature. The stable-load boundary drifts across days too. A config that passed one day crashed on first load another day. No soak test certifies anything on this card.
So, process of elimination: the open layers (kernel xe driver, userspace compute runtime) were upgraded independently with no change, and the failure signature shows up across totally different userspace stacks. What's left is the closed GuC firmware blob. I can't fix that. I can't even look at it.
The ecosystem made it worse #
The hardware bug is half the story. The other half is what your options look like when you try to route around it in 2026:
ipex-llm: archived by Intel, January 2026.** intel-extension-for-pytorch**: archived by Intel, March 2026.- Intel's stated path is now upstream vLLM XPU only, which is where the crashes live. On this card it cannot co-host anything larger than a 7B beside another model at any memory split, with or without workaround flags. llama.cpp SYCL: a separate GPU hang (Level Zero v2 adapter interacting with the VMM pool) that reproduces on stock master. Both documented workarounds failed extended soak tests.Vulkan: crashes the card outright.
Every escape route is either archived, broken, or the thing you're escaping from. When a vendor archives its own PyTorch extension and its own LLM library within three months while shipping a workstation card with "Pro" in the name, that tells you where the card sits on their priority list.
Upstream #
I filed a detailed report on the drm/xe kernel tracker with full logs, timing data, and reproduction steps, and posted a single-GPU repro to the closest public vLLM issue (vllm#41663). There are public reports with the same engine-reset signature on other Battlemage cards, including a B580 crashing from OpenCL in darktable, so this is not one lemon card, it's a driver or firmware family bug. As of late July: no movement on any of them. A weekly script watches the trackers so I'll know if that changes.
The kicker #
A used RTX 3080 Ti, a two-generation-old $500 card with a third of the VRAM, has served the same models on the same LAN under the same sustained load for the entire period without a single device loss. Half what I paid for the B70. The AMD R9700s likewise, zero device losses. The B70's peak throughput beat both. Peak throughput you can't sustain is a benchmark, not a product.
Where I landed #
The card is out of the fleet. The tooling I built around it (watchdog with auto-restart and reboot escalation, a one-command requalification battery for when Intel ships a fix) stays, because it's useful for any fragile card, and honestly because I'd like this card to earn its slot back someday. 32GB at this price should be a great deal.
If you're considering a B-series card for inference today: light, bursty, single-process loads are probably fine. Sustained serving is not. Check the drm/xe tracker and vLLM issue #41663 before you spend the money, and assume the software situation is what it is now, not what the marketing implies it will be.
I wish someone had written this post two months ago. Now someone has.