Six weeks with Intel's Arc Pro B70 in a production inference fleet — ModDog Blog

July 29, 2026 · Nate, building ModDog

Six weeks with Intel's Arc Pro B70 in a production inference fleet

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<br>... Engine reset: engine_class=ccs<br>... Engine reset: engine_class=bcs<br>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 died fastest (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_LOADER_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...