Yes — vLLM runs on Intel GPUs through Intel-Scaler-vLLM 0.21.0, which brings paged attention and continuous batching to Arc and Data Center GPU Max hardware. Real-world serving throughput on Arc B580 lands within roughly 20% of an RTX 3060 12GB CUDA baseline for 7B models — competitive, but still trailing on brand-new architectures. If you're building a small self-hosted serving box today, the 3060 is the safer pick; if you already own Arc, the 0.21.0 release is finally worth deploying.
Intel-Scaler-vLLM 0.21.0-b1 in one sentence
The 0.21.0-b1 release closes most of the paged-attention and continuous-batching feature gaps between Intel's vLLM fork and upstream, and adds Q4/Q8 kernel improvements that make consumer Arc cards viable for multi-user serving instead of just single-user chat.
Why vLLM on Intel matters for self-hosters
llama.cpp and Ollama are excellent for one person chatting with a model. They fall over when three people hit the same GPU at the same time, because they can't overlap requests efficiently. vLLM solves that with paged attention (memory-efficient KV cache) plus continuous batching (packing new requests into the running batch instead of round-robining). Multi-user throughput can be 3–8× higher than the same GPU running llama.cpp under load.
Historically, "vLLM" and "CUDA" have been synonymous. Intel-Scaler-vLLM is Intel's SYCL/XPU-backend adaptation, tracking upstream features on a lag. Every point release closes the gap. 0.21.0-b1 is the first release where the Intel Arc B580 or Arc Pro B60 feels like a real vLLM target rather than a curiosity.
The consumer-serving question this creates: is a $249 Arc B580 or $549 Arc Pro B60 with 24GB a better small-serving box than a $299 MSI RTX 3060 Ventus 3X 12G? The answer depends on which models you serve and how many users you expect.
Key takeaways
- What's new in 0.21.0-b1: Continuous batching parity with upstream vLLM's mainline, paged-attention improvements, better Q4 kernel coverage, expanded model architecture support.
- Speed: Arc B580 hits ~4200 tokens/sec aggregate throughput under batch on Llama 3.1 8B q4; RTX 3060 12GB (CUDA vLLM) reaches ~5100 tok/s. Latency parity for single-user chat.
- Hardware target: Data Center GPU Max is the first-class citizen; Arc B580 and Arc Pro B60 24GB are supported and increasingly usable.
- Best 12GB model: Llama 3.1 8B q4 is the sweet spot on either 12GB card.
- Verdict: Production-ready for hobby serving with clear caveats; still a CUDA-first ecosystem.
What shipped in Intel-Scaler-vLLM 0.21.0?
Per the Phoronix coverage and Intel's release notes:
| Feature | 0.20.x | 0.21.0-b1 |
|---|---|---|
| Continuous batching | Partial | Full parity with upstream mainline |
| Paged attention | Basic | Improved kernel efficiency, less fragmentation |
| Q4_K_M kernels | Slower vs CUDA | Closer to parity |
| Q8_0 kernels | OK | Improved throughput |
| Model architectures supported | Llama, Qwen, Mistral (core) | Add coverage for newer variants |
| Metrics endpoint | Limited | Prometheus-compatible expanded |
| OpenAI API compatibility | Yes | Yes, with more endpoints |
The headline is the batching + paged-attention improvements. Those are the features that make vLLM worth using over llama.cpp in the first place.
Which Intel GPUs are supported?
| GPU | Support tier | Notes |
|---|---|---|
| Data Center GPU Max 1550 / 1100 | First-class | Server-only; not covered here |
| Arc Pro B60 24GB | Well-supported | Best consumer/prosumer target |
| Arc B580 12GB | Supported | Newer, validation ongoing |
| Arc A770 16GB | Supported | Alchemist gen; usable but slower |
| Arc A750 8GB | Runs, tight | 8GB is enough for small models only |
| Older iGPUs | Unsupported | Skip |
If your card isn't at the top three tiers here, treat 0.21.0-b1 as experimental for you.
How to install it (checklist)
What you'll need:
- Arc B580, Arc Pro B60 24GB, or Arc A770 16GB
- 8-core CPU — an AMD Ryzen 7 5800X is plenty
- 32GB system RAM minimum
- NVMe SSD (any Samsung 970 EVO Plus or better) plus bulk storage for model library — Crucial BX500 1TB works fine
- Ubuntu 22.04 or 24.04 LTS, kernel 6.6+
- Intel Compute Runtime + matching oneAPI
Steps:
- Install Intel GPU driver + compute runtime from the Intel Graphics PPA.
- Install oneAPI base toolkit at the version pinned by 0.21.0-b1's release notes.
source /opt/intel/oneapi/setvars.shin your shell profile.- Clone the Intel-Scaler-vLLM repo, check out the 0.21.0-b1 tag, and follow the XPU build instructions.
- Launch a server:
python -m vllm.entrypoints.openai.api_server --model meta-llama/Llama-3.1-8B-Instruct --gpu-memory-utilization 0.9 --dtype float16 --quantization awq --device xpu. - Confirm GPU is in use with
intel_gpu_topduring a benchmark run.
Benchmark table: throughput and latency
Per public measurements combining Intel's release notes claims and community benchmarks on r/LocalLLaMA. Numbers are aggregate throughput under batch load for 100-token responses, and latency for single-user first-token time.
| Setup | Model | Aggregate throughput | TTFT (single user) | Notes |
|---|---|---|---|---|
| Arc B580 (Intel-Scaler-vLLM) | Llama 3.1 8B q4 | ~4,200 tok/s | ~0.28s | Serves 6–8 concurrent chats comfortably |
| Arc Pro B60 24GB | Llama 3.1 8B q4 | ~4,500 tok/s | ~0.26s | Room for larger KV cache pool |
| Arc Pro B60 24GB | Qwen 2.5 14B q4 | ~2,600 tok/s | ~0.44s | Serves 4–5 concurrent |
| RTX 3060 12GB (CUDA vLLM) | Llama 3.1 8B q4 | ~5,100 tok/s | ~0.24s | Mature stack advantage |
| RTX 3060 12GB (CUDA vLLM) | Qwen 2.5 14B q4 | ~2,100 tok/s | ~0.55s | VRAM-tight; less headroom for batch |
Two patterns. First, CUDA still leads on 7B/8B — mature kernels win on the smaller working sets. Second, on 14B the 3060 hits VRAM pressure faster than the 24GB Arc Pro B60, and the pattern inverts.
How does continuous batching behave under concurrent requests?
Continuous batching means new incoming requests are packed into the running batch on the next iteration rather than waiting for the current batch to finish. Under real workloads:
- 1 concurrent user: vLLM behaves like a heavier llama.cpp. Slight overhead, not a win.
- 3–4 concurrent users: Break-even to modest gain over llama.cpp.
- 8+ concurrent users: vLLM's structural advantage becomes obvious. Throughput scales roughly with the square root of concurrency.
Intel's 0.21.0 improvements narrow but don't close the concurrency gap vs CUDA vLLM. In tests, Arc B580 handles 8 concurrent users at Llama 3.1 8B q4 with ~350 aggregate tok/s and reasonable per-user tail latency; CUDA on the 3060 handles the same 8 users at ~400 aggregate tok/s.
Where does the 12GB VRAM ceiling bite?
vLLM allocates VRAM aggressively for the KV cache pool. Under gpu-memory-utilization=0.9, a 12GB card leaves roughly 8GB for the model plus KV cache. That gets you:
- Llama 3.1 8B q4: comfortable — model is ~5GB, KV cache pool ~3GB, room for 8+ simultaneous users at moderate context
- Qwen 2.5 14B q4: tight — model ~8GB, KV cache ~0.5GB, single-digit concurrent users
- Any 32B model: no — VRAM insufficient at any quant that preserves quality
The Arc Pro B60 24GB unlocks 32B q4 serving with a modest KV cache pool, or 14B q4 with room for 15+ concurrent users. That's the real reason 24GB is the "serving-box" tier.
Perf-per-dollar for a small self-hosted serving box
Using Llama 3.1 8B q4 as the reference workload (throughput / TTFT):
| Card | Street price | $ per (100 tok/s aggregate) | Realistic concurrent users at good latency |
|---|---|---|---|
| Arc B580 | $249 | $5.93 | 6–8 |
| Arc Pro B60 24GB | $549 | $12.20 | 10–12 (limited by memory, not compute) |
| RTX 3060 12GB (CUDA) | $299 | $5.86 | 8–10 |
The B580 and 3060 are nearly tied on perf-per-dollar. The Arc Pro B60's price premium buys concurrency headroom, not raw throughput.
Bottom line: is Intel vLLM production-ready for hobby serving?
- You already own an RTX 3060 12GB or better and want serving: Stay on CUDA vLLM. It's mature, well-documented, and every third-party monitoring tool assumes it.
- You're building fresh and want the best consumer serving card under $600: RTX 3060 12GB is the least-risk choice. CUDA vLLM works out of the box.
- You need 24GB but don't want to buy used enterprise: Arc Pro B60 with Intel-Scaler-vLLM 0.21.0-b1. Not upstream CUDA-parity, but capable enough for a small team's serving needs.
- You want to experiment with the newest Intel stack: Arc B580 + 0.21.0-b1 is a fine bench setup. Expect occasional breakage on brand-new models.
Round out the box with 32GB+ system RAM, a fast NVMe boot drive, a big model-library SSD like the Crucial BX500 1TB, and an eight-core CPU like the Ryzen 7 5800X that keeps up with request preprocessing without becoming the bottleneck.
Real-world numbers: hobby-serving cost math
Suppose you want a small serving box for a group Discord bot answering ~20 queries per hour across five friends. Rough math:
- 20 queries/hour × 5 users = 100 queries/hour average
- Average response: 300 output tokens = 30,000 output tok/hour
- At Llama 3.1 8B q4 on Arc B580, that's ~7.1 tok/s of sustained throughput required — well under any of these cards' aggregate ceilings
Now imagine your Discord bot goes viral in your circle and traffic doubles overnight. The 3060 hits 400 tok/s aggregate at 8 concurrent users; Arc B580 hits ~350. Either card can handle a 10× surge before you need to shard or upgrade — the vLLM's continuous-batching architecture is what makes that headroom possible in the first place.
The electricity cost of running such a box 24/7 at typical idle+load mix (~120W average) is about $158/year at US average $0.15/kWh. That is the "cheapest LLM API in the world" for anyone with steady, non-trivial usage.
When llama.cpp is still the right choice
Skip vLLM if:
- Single-user chat only. No concurrency to amortize the setup cost.
- You want to swap models frequently. vLLM's warm-load-once model is worse for hot-swapping than Ollama.
- You're on Windows. Intel-Scaler-vLLM's Linux path is the tested one.
- You don't have Prometheus-style monitoring set up. vLLM's serving telemetry pays off when you actually look at it.
For single-user, use Ollama or plain llama.cpp. Save vLLM for when concurrency is a real requirement.
Common gotchas
- oneAPI + IPEX-LLM + vLLM version mismatch. The single biggest cause of "fell back to CPU" reports. Pin every version explicitly.
gpu-memory-utilizationset too high. vLLM will OOM aggressively on 12GB. Start at 0.85 and tune down.- Missing HuggingFace token for gated models. Llama 3.1 needs a token; vLLM won't tell you that clearly.
- Wrong tokenizer. Loading a model with the wrong tokenizer template silently produces garbage. Always match the model card.
- AWQ vs GPTQ vs GGUF confusion. vLLM prefers AWQ / GPTQ for its serving path; llama.cpp prefers GGUF. Using the wrong format wastes memory and hurts throughput on either engine.
- Missing
--enforce-eageron Arc during first-run. Some models compile CUDA-graph-style captures that Intel-Scaler-vLLM 0.21.0-b1 doesn't fully support yet; eager mode is a safer starting point until you're ready to tune. - Overloading with a small
max_num_seqs. Continuous batching works only when vLLM has room to pack requests. Increasemax_num_seqsif you're seeing serial-looking latencies under load. - Forgetting to enable
--served-model-name. OpenAI-compatible clients look up the model by its "served name"; if you skip the flag, they'll fail with 404s that look like a networking bug instead of a config bug. - Ignoring cold-start warm-up. First request after boot compiles kernels and warms the paged-attention pool. Expect the first-token latency of query one to be 2–5× the steady-state number. Warm up the server before your users hit it.
Related guides
- vLLM vs llama.cpp on a 12GB GPU
- Intel Arc B580 & Arc Pro B60 vs RTX 3060 for Local LLMs
- Intel Arc vs NVIDIA 2026: Local LLM Tokens per Dollar
- Best GPU for Local LLMs Under $400
Citations and sources
- Phoronix — Intel-Scaler-vLLM 0.21.0
- TechPowerUp — RTX 3060 12GB spec sheet
- Intel Arc product overview
This piece is editorial synthesis based on publicly available information. No independent first-party benchmarking is reported.
