A team runs DeepSeek on a Xeon box, reads 42 tokens per second off one prompt, and concludes the platform is too slow. That single number is the most expensive mistake in accelerator selection, because it invites a hardware swap when the real bottleneck may live in the runtime or the deployment — places a hardware swap will not touch.

Running DeepSeek on Intel silicon — Xeon CPUs, Gaudi accelerators, or Arc and Data Center GPUs — is not the hard part. Reading what the platform is actually doing under load is. The naive approach fires one prompt, reads tokens-per-second, and treats it as representative of production cost. The expert approach instruments the serving path with Intel’s own profilers, reads the layered view, and only then decides whether the cost lives in the model, the runtime, or the deployment. Those are three different problems with three different fixes, and a scalar throughput number cannot tell them apart.

Why a single tokens-per-second benchmark on Intel silicon misleads a platform decision

A tokens-per-second reading is a single point on a surface that has at least four axes: batch size, sequence length, KV-cache occupancy, and whether the request path was warm. Change any one of them and the number moves — often by a factor that dwarfs the hardware difference you are trying to measure. When a team benchmarks one prompt on a Xeon node and one on an alternative accelerator, they are usually comparing two different points on two different surfaces and calling it a platform comparison.

The deeper problem is attribution. A slow tokens-per-second figure has no address. It does not tell you whether the time went to attention kernels, to Mixture-of-Experts routing overhead, to memory pressure from the KV cache, or to host-device transfer stalls. Each of those has a distinct remedy. If the cost is host-device transfer, buying a faster accelerator changes nothing, because the bottleneck was the data path, not the compute. We see this pattern regularly: a re-hosting quarter is spent moving DeepSeek from one platform to another, and the p95 latency barely moves, because the profiled bottleneck was never on the axis the swap addressed.

This is why attributing DeepSeek inference cost on Intel hardware to a specific layer is what separates a defensible platform choice from a quarter spent re-hosting for no p95 gain. The benchmark tells you how fast; only the profile tells you why, and why is the input that governs the decision.

How Intel profiling tools map to questions about a DeepSeek serving path

Intel ships a coherent profiling stack, and each tool answers a different question. The mistake is reaching for one tool and expecting it to cover the whole serving path. VTune Profiler is the right instrument for CPU-side hotspots, microarchitecture stalls, and memory-access behaviour on Xeon. The oneAPI toolchain — including the tracing and analysis components that ship with it — covers device-side kernel timing and the offload boundary on Arc and Data Center GPUs. On top of both, request-level tracing captures where time goes at the granularity a serving SLO actually cares about: queueing, prefill, decode, and detokenisation.

The layered read is the point. VTune tells you a specific attention kernel is memory-bound on the CPU path; the oneAPI trace tells you a Gaudi or GPU kernel is waiting on a transfer that has not landed; the request trace tells you which of those actually shows up in p95 versus which is amortised away under batching. No single layer is decision-grade on its own.

Which Intel tool answers which DeepSeek profiling question

Question about the serving path	Primary Intel instrument	What it reveals
Where does CPU time go on Xeon?	VTune Profiler (hotspots, microarchitecture)	Kernel-level hotspots, cache/memory stalls, vectorisation gaps
Is a GPU/Gaudi kernel compute- or transfer-bound?	oneAPI trace + device timeline	Kernel duration, offload boundary, host-device transfer stalls
Is the KV cache causing memory pressure?	VTune memory analysis + serving metrics	Memory occupancy under cache load, allocation churn
Which stage dominates p95, not the mean?	Request-level tracing	Per-stage latency contribution: queue, prefill, decode
Does MoE routing add measurable overhead?	oneAPI kernel timeline + request trace	Expert-selection cost vs dense attention cost

Evidence class for the mappings above: observed-pattern, drawn from Intel-hardware inference profiling in our engagements — not a published benchmark of any specific tool.

How to read profiler output to find the real bottleneck

The reason profiling is worth the effort is that DeepSeek’s cost structure is layered, and the layers do not fail in the same way. Reading the output means asking, in order, which layer owns the latency you care about.

Start at the request trace, because it defines what “slow” means for your SLO. If p95 is dominated by decode rather than prefill, the bottleneck is in the token-by-token loop, and attention-kernel or KV-cache behaviour is the place to look. If prefill dominates, the cost is in ingesting the prompt, and batching or sequence-length effects are in play. This is the same discipline as reading a machine learning architecture diagram of the serving path — you are locating the stage before you optimise it.

Then drop into the device or CPU layer. A VTune hotspot showing an attention kernel stalled on memory access points to a bandwidth problem, not a compute one — and DeepSeek’s KV cache is a classic case of a memory-intensive inference workload where bandwidth, not FLOPS, is the ceiling. If the oneAPI timeline shows a GPU kernel idle while a transfer completes, the offload boundary is the constraint. And on DeepSeek specifically, MoE routing has its own signature: expert-selection overhead that can be invisible in a throughput number but shows up plainly as a distinct kernel cost in the device timeline.

The three most useful things you can carry out of a profiled DeepSeek-on-Intel session are concrete: per-stage latency contribution on the Intel CPU or GPU path, a kernel-level time breakdown for the MoE and attention paths, and memory occupancy under realistic KV-cache load. Those numbers have addresses. A tokens-per-second scalar does not.

Which Intel hardware fits, and how you actually tell

The honest answer is that the profile decides, not the datasheet. Xeon CPUs can serve DeepSeek at small batch sizes and modest concurrency where latency budgets are generous and the deployment values operational simplicity; the profile will show whether decode throughput clears your SLO before the memory subsystem saturates. Gaudi accelerators target higher-concurrency serving where the MoE and attention paths dominate, and the question the profile answers is whether the offload boundary is fed efficiently. Arc and Data Center GPUs sit between those postures.

Rather than pick from specs, run the same DeepSeek serving path on each candidate, capture the layered profile under identical load, and compare the bottleneck maps — not the top-line numbers. The comparison that matters is not “which is faster” but “which one’s cost lives in a layer I can afford or fix.” That framing is the same one behind the broader question of reading the numbers before you commit to a platform for DeepSeek inference on Intel, and it is why the runtime matters as much as the silicon — the way SGLang and the serving runtime shape what you profile on a DeepSeek path can move the bottleneck more than a hardware generation does.

From profiler output to a cost-per-request baseline

Profiler numbers are inputs to an audit’s before/after baseline, not a substitute for it. A per-stage latency contribution and a kernel-level breakdown become decision-grade only when they are placed against a cost-per-request figure and compared under matched load to alternative accelerators. The trap is over-reading one benchmark: a measured cost delta between Intel and an alternative is worth acting on only if it survives the same batch size, sequence-length distribution, and concurrency you run in production.

This is exactly the instrument the [AI Inference Cost Audit](Inference Cost-Cut Pack) uses — it applies the same profiling stack to a DeepSeek-on-Intel serving path and folds the per-layer attribution into a bottleneck map that stays legible across hardware families. The point of reading Intel-specific profiler output the way this article describes is so that map is comparable when you set it beside a non-Intel trace. If you want the profiling done as part of a scoped engagement rather than in-house, that is what our R&D and consulting services are for.

Frequently Asked Questions

What does working with intel deepseek involve in practice?

Running DeepSeek on Intel hardware means serving the model on Xeon CPUs, Gaudi accelerators, or Arc and Data Center GPUs, using Intel’s software stack and profilers. In practice it means the same DeepSeek serving path — prefill, decode, attention, MoE routing — runs on Intel silicon, and the question is not whether it runs but where its cost lives. A profiled trace, not a single throughput number, is what tells you that.

Which Intel hardware is best suited to running DeepSeek inference, and how do I tell?

There is no datasheet answer — the profile decides. Xeon CPUs suit small-batch, latency-tolerant serving; Gaudi targets higher-concurrency workloads where MoE and attention paths dominate; Arc and Data Center GPUs sit between. To tell, run the identical serving path on each candidate under matched load and compare the bottleneck maps rather than the top-line tokens-per-second numbers.

Which Intel profiling tools map to which questions about a DeepSeek serving path?

VTune Profiler answers CPU-side questions: hotspots, microarchitecture stalls, and memory-access behaviour on Xeon. The oneAPI toolchain covers device-side kernel timing and the offload boundary on Arc, Data Center GPU, and Gaudi paths. Request-level tracing sits on top and shows per-stage latency at the granularity your SLO cares about — queue, prefill, decode. The layered read across all three is what becomes decision-grade.

How do I read profiler output to tell what DeepSeek latency on Intel is bound by?

Start at the request trace to see whether p95 is dominated by prefill or decode, which locates the stage. Then drop into VTune or the oneAPI timeline: a kernel stalled on memory access indicates a bandwidth bound (common with the KV cache), an idle kernel waiting on a transfer indicates the offload boundary, and a distinct expert-selection cost indicates MoE routing overhead. Each has a different remedy, which is why the layer matters.

Why can a single tokens-per-second benchmark on Intel silicon mislead a platform decision?

A tokens-per-second reading is one point on a surface with at least four axes — batch size, sequence length, KV-cache occupancy, and warm-versus-cold — so comparing two isolated numbers usually compares two different operating points. More importantly, the scalar has no address: it cannot say whether the cost is in attention kernels, MoE routing, memory, or host-device transfer, and only the last of those is unaffected by a hardware swap.

How do DeepSeek-on-Intel profiler numbers become an audit’s before/after baseline?

The per-stage latency contribution, kernel-level MoE and attention breakdown, and KV-cache memory occupancy are inputs to a cost-per-request baseline, not a substitute for it. They become decision-grade when placed against cost-per-request under matched production-like load, so a measured delta is trusted only if it survives the same batch size, sequence-length distribution, and concurrency. The audit folds them into a bottleneck map that stays comparable across hardware families.

How do I compare cost-per-request for DeepSeek across Intel and alternative accelerators without over-reading one benchmark?

Capture the layered profile on each accelerator under identical load, then compare bottleneck maps rather than headline throughput. Ask which platform’s cost sits in a layer you can afford or fix, not which is nominally faster. A cost delta is worth acting on only when it holds under matched batch size, sequence length, and concurrency — otherwise you are re-hosting on the strength of one benchmark that will not reproduce in production.

The failure to avoid is spending a quarter re-hosting DeepSeek off Intel to chase a p95 improvement that a profiled trace would have shown was never on the layer a hardware swap touches. Read the layers before you move the workload.