Arc LLM Lab: One A$999 Intel Card Decodes Qwens 27B Model at 53 Tokens a Second
By Indie Kings | October 17, 2026
Updated October 17, 2026: The arc-llm-lab repository reports 53 tok/s mean decode for a local Qwen 27B coding model on a single Intel Arc Pro B60 24GB, a 97/100 score on a 100-task hidden-checker agent eval, and a benchmark trail where every number links to a raw log. Every figure below is the project's own published, logged measurement; Indie Kings has not independently verified any of it.
Image: GitHub repository card for arc-llm-lab. Credit: GitHub.
The headline numbers
The one sentence worth repeating: a largely one-person repository runs a 27B local coding model at 53 tokens per second on a single A$999 Intel Arc Pro B60 card, and every benchmark number in the repo links to a raw log. Per the repository README, that 53 tok/s is per-request server decode averaged over seven coding tasks, ranging from 47 to 58 with a 64K context window allocated and short prompts. The same card on stock llama.cpp with no draft model decoded 16 tok/s in the project's own test.
Per the README, the card costs A$999 including GST for an ASRock Arc Pro B60 Passive 24GB OEM unit per a PCCaseGear snapshot dated October 10, 2026, with A$1,240 listed for an ASRock B60 Creator in an Australian price snapshot dated October 7. Both are snapshots the project cites, not prices we confirmed. The passive card has no fan of its own and needs strong airflow, per the same notes.
No purchase path follows, per our own policy: this is a community writeup of a local-inference stack, nothing more.
| Measurement per the README | Stock llama.cpp Vulkan | The tuned stack |
|---|---|---|
| Generation, eval-suite wall clock | 16.0 tok/s, no drafter | 42.3 tok/s with DFlash2 |
| Per-request decode, seven coding tasks | 16.05 tok/s at empty context | 47 to 58 tok/s, mean 53.3 |
| Prompt reading at 32K context | 118 tok/s | 420 tok/s, 3.6x |
| Context window | Not the measured claim | Up to 64K configured, 57 to 61K logged in use |
| Agent turns at 30 to 37K context | 201 s observed, log not retained | 55 to 57 s, logged |
| Hidden-checker agent eval at 32K | Not measured | 97/100 Claude Code, 95/100 Codex |
The project itself flags the inconsistency in its own favor. Per its fine-print block, 53 tok/s is the per-request figure with short prompts, real agent turns at 30 to 37K tokens of conversation generate about 42 tok/s, and the 42.3 headline is the conservative wall-clock number it chooses to lead with. Single runs on one workstation back every cell.
The recipe behind the speed
Per the README, four changes do almost all of the work, and each was measured on its own before it went in.
First, the DFlash2 draft model. In the project's own words, a small DFlash2 draft model takes a 27B dense model from 16 to 42 tok/s with identical output quality on its seven coding tasks, drafting seven tokens per round. One logged shallow-context code request shows 65 percent draft acceptance, 573 of 877 drafted tokens accepted, per the raw server test log the README cites.
Second, Intel's flash-attention prefill kernel runs prompt reading at 32K depth 3.6x faster, from 118 to 420 tok/s, and only works with an f16 KV cache; the README states a q4 KV cache gains nothing, 101 versus 101. The kernel comes from a llama.cpp pull request its author closed without merging on September 25, 2026, so the repo vendors the two commits with checksums and attribution instead of waiting upstream.
Third, VRAM budgeting. The model is Qwen3.8-27B in a Q4_K_M quant, a 16.46 GB weights file, per the versions table, all dated October 10, 2026. An f16 KV cache costs 64.5 KiB per token for this model, 4.0 GiB at 64K. Per the README, a 256-token upload block plus a q8 draft KV cache frees 0.55 GiB at no speed cost, which is the difference between a 57K and a 64K window inside 24GB.
Fourth, keeping the GPU to itself. Per the October 17 field report the README links, an idle Ollama model left resident on the same card cut one request's decode from 52.7 to 22.2 tok/s, and unloading it restored the speed. A report generator in the repo sizes context to whatever VRAM is free at each load.
The hidden-checker agent eval
Speed on its own means little if the model cannot finish a task. Per the README's reliability section, the repo ships a 100-task agent eval across seven categories, including 20 coding, 20 debugging, 15 tool-use, 10 long-context retrieval and 10 business-maths tasks. In the project's words, each task is scored by a hidden checker the agent never sees, and the headline metric is completed tasks per minute, not tokens per second.
Results per the README: 97/100 for the local model wired into Claude Code with a 95 percent confidence interval of 91.5 to 99 on a single run at a 32K window, 95/100 for Codex, and 1.54 completed tasks per minute. Sustained 10-step sessions at 48K and 64K windows score a mix of 9s and 10s out of 10 across both harnesses, again single runs. The project also reports one of the 100 tasks ended destructively, and it uses that as its argument for committing work before any unattended agent run.
How it compares with other published B60 numbers
Other people publish Qwen3.8-27B numbers for the same card, and the project puts them side by side in its docs/PEERS.md comparison, collected from public pages on October 10, 2026. Per that page, its 47 to 58 tok/s decode range sits above the highest single-card B60 figure it found for this model. The closest rivals self-report 41.3 to 41.9 tok/s on custom tuned quants with an embedded multi-token path on a different backend, which the repo itself marks not like-for-like.
Per the same page, the project is not the fastest at everything. Competing runs read prompts at 589 to 638 tok/s near 29K context on a modified llama.cpp engine, and 657 tok/s at 32.8K on OpenVINO, against the project's 420 at 32K. The repo names that gap plainly: it is strongest on generation speed and end-to-end reproducibility, not prefill.
| Source per docs/PEERS.md | Backend and method | Depth | Prompt tok/s | Generation tok/s |
|---|---|---|---|---|
| arc-llm-lab | llama.cpp Vulkan with Intel FA patches, DFlash2 draft | 32K | 420 | 42.3 eval suite, 47 to 58 decode |
| arc-llm-lab, stock build | llama.cpp Vulkan, no drafter | 32K | 118 | 14.45 |
| marfrit/arcint issue thread | llama.cpp engine with MTP drafts | 28.8K | 589 to 638 | 32.3 |
| marfrit/arcint issue thread | OpenVINO int4 with MTP | 32.8K | 657 | 17.4 |
| Greatjedi model card on Hugging Face | llama.cpp SYCL, custom quants, embedded MTP | Shallow | 245.5 | 41.3 to 41.9 |
The peer page asks readers to treat gaps under about 10 percent as noise, since backends, KV types, draft depths and measurement tools all differ across rows. That is the right instinct, and it is rare in community benchmarking.
The rest of the stack
The repo is bigger than a tuned benchmark. Per the README, it also carries local video generation through LTX-2.5 text-to-video and image-to-video with sound via ComfyUI on the same card's XPU path, with a queue that hands the GPU from the LLM to the video pipeline and back. A logged 2-second, 49-frame, 768x512 clip with sound took 188 to 219 seconds queued to finished.
There is a phone control panel: per the README, a web app reachable over a private tailnet only, with live GPU and VRAM telemetry, render progress, PIN-gated approvals, and a phone-gateway eval scoring 10/10 with a median approval time of 10.3 seconds. Roughly 100 desktop and browser tools sit behind seven pinned ones. A Claude Code bridge rounds it out: per the project, its ask_local tool hands first-pass code and review tasks to the local model while Claude stays the gate.
Scale, per the README's own project card: 443 automated tests, 100 agent tasks with hidden checkers, 23 logged tuning experiments, about 31K lines of code, 89 Markdown guides, 15 raw logs, and 26 doctor health checks. The whole thing is MIT licensed and was built and measured by Elie Dagher with Claude as an engineering pair.
Caveats worth reading first
Everything above is the project's own published, logged benchmarking, not independently verified by us. All numbers come from single runs on one workstation per the README: a Ryzen 7 3700X, 32 GB of RAM, Windows 11, driver 32.0.101.8976 released September 25, 2026. The stock-comparison agent-turn figure has the repo's own asterisk, an observation from before logging was in place with the raw log not retained.
The card itself is a caveat. One sentence of honest framing belongs next to every one of these counts: the Arc Pro B60 is a bulkier, workstation-family card that is far less mainstream than the Arc B580 or B570 desktop boards most buyers actually see. Per the README's card-fit table, the 27B model does not fit usefully on those smaller boards at 12GB VRAM or below, and the 32GB Arc Pro B70 result is a size-and-arithmetic estimate, not a measurement. Owners of mainstream desktop cards should not read these figures as transferable.
Context has its own fine print. Per the October 17 field report, a 53K window on a contended desktop fell to 22 tok/s, and running 50 to 60K tokens without loss is not yet qualified. The overflow path is deliberate: per the README, the server is configured so an overlong conversation returns an error instead of silently dropping old tokens.
Our take: The raw logs are the story here as much as the speed. A repo that links every headline number to a raw output file, publishes a 24-hour-old regression to 22 tok/s, and tells you which competitor reads prompts faster is behaving like a reference source, not a showcase, and we would trust its less flattering numbers faster for that reason. We would still wait for independent replication before treating the 53 tok/s mean as settled, because it is one workstation, one driver, one date, and speculative decoding does best on exactly the code-heavy workload the authors chose. The B60's bulk and obscurity keep this a specialist rig for now; nothing here says mainstream desktop Arc owners are one config away from the same numbers.
FAQ
What card and model produce these numbers?
Per the README, one Intel Arc Pro B60 24GB, Qwen3.8-27B in a Q4_K_M quant with a DFlash2 draft model, on llama.cpp with Vulkan and Intel's flash-attention prefill kernel.
Is the 53 tok/s figure independently verified?
No. It is the project's own per-request decode mean over seven coding tasks, backed by raw logs in the repo and self-described as the fastest published single-card figure it found for this model and card.
Can I get the same speed on an Arc B580 or B570?
Per the README, no for this 27B model; the weights alone leave no room for a useful context on 12GB or smaller cards. The Vulkan tuning techniques carry over to other Arc cards, but you would run smaller models.
Is this the fastest Intel Arc LLM setup on every measure?
No, by the project's own admission. Peer runs read prompts faster than its 420 tok/s at 32K; it leads on generation decode and on being reproducible end to end.
Can I reproduce it inside Ollama or LM Studio?
Not this exact setup, per the README. Those apps bundle their own llama.cpp without the vendored flash-attention patches or the DFlash2 draft path, and the repo describes pointing them at this server's OpenAI-compatible endpoint instead.
Who built it?
Per the README, Elie Dagher built and measured it with Claude as an engineering pair, under an MIT license, with all results dated October 10, 2026 and a field report added October 17.
Bottom Line
Per the project's own logged benchmarks, arc-llm-lab turns a single Intel Arc Pro B60 24GB and a Q4_K_M quantized 27B model into a roughly 3.3x decode jump over stock: 53 tok/s mean against 16, 97/100 on a 100-task hidden-checker agent eval at a 32K window, and a 64K context inside 24GB VRAM. The transparency is genuine, the caveats are unusually loud, and the prefill crown belongs to someone else. Single-card, single-run, self-published: worth reading closely, worth replicating, not yet settled.