Intel GPU AI Skills

Run, benchmark, profile, and migrate Hugging Face models on Intel GPUs with agent skills.

intel/gpu-ai-skills is 20 production-grade Agent Skills that teach any skills-capable agent — Claude Code, Copilot CLI, Cursor, Gemini CLI, opencode, Codex, Qwen Code, Kimi Code, Hermes, OpenClaw — exactly how to run, size, benchmark, profile, and migrate models on Intel Arc and Arc Pro. Apache-2.0. One install command.

git clone https://github.com/intel/gpu-ai-skills.git intel-gpu-ai-skills
cd intel-gpu-ai-skills && bash scripts/install.sh

Then stop thinking about it:

"Will Qwen2.5-32B in int4 fit on my Arc Pro B70 at 8K context, concurrency 4?"

- model-can-it-fit loaded automatically
- weights 16.8 GiB · KV 3.2 GiB · verdict: FITS
- headroom 11.2 GiB (35%) on a 32 GiB card

No skill name typed. No flag guessed. No GPU-hour burned finding out the hard way.

---

Try it in five minutes

You don't need a GPU for the first step, and you don't need a big one for the second. Start here before reading the catalog below.

Step 1 — no GPU required. The sizing math reads the model's config.json and works it out arithmetically, so you can run this on a laptop before you touch any hardware:

"Will Qwen2.5-1.5B-Instruct fit on a 16 GB Intel GPU in bf16?"

No download, no container, no launch — and note that it flags the difference between nameplate VRAM and what the driver will actually hand you, which is where tight verdicts usually go wrong.

Step 2 — a small model on a modest card. On an Intel Arc Pro GPU card:

"Serve Qwen2.5-1.5B-Instruct on my Intel GPU and send it a test prompt."

vllm-xpu-run picks the image, sets the device flags, starts the OpenAI-compatible endpoint — and then verifies a real completion came back before telling you it worked. A server that boots is not the same as a server that answers.

Step 3 — scale up when you're ready.

"Launch GPT-OSS-20B on my Intel B70 GPU."

Same skill, bigger model. The agent moves to quantized weights and pairs them with the attention backend that combination actually requires — exactly the kind of detail that costs an afternoon when you're guessing at it.

---

All 20 skills, organized by what you're trying to do

Twenty skills sounds like a lot to learn. It isn't — you never invoke them by name. They're grouped below the way you'd actually hit them: get the box working, decide what fits, run it, measure it, then figure out why it's slow. The prompts in the right-hand column are there to be copied and tried.

Setup & Readiness — 4 skills

Get a bare host or container to a verified go/no-go state before any GPU work starts.

With a healthy host, the fun part starts.

Run Models — 5 skills

Get a Hugging Face model actually loaded and serving on the GPU, with the right framework for the job.

Before you pull 60 GB of weights, though, there's a cheaper question worth asking.

Plan & Size — 3 skills

Answer "will it fit" and "what config" before spending a single GPU-hour on a launch attempt.

A server that starts isn't the same as a server that's fast. That's what these three are for.

Benchmark — 3 skills

Measure real TTFT, TPOT, inter-token latency, and throughput — not predictions.

And when the numbers disappoint, you need to know which op is eating the time — not a guess.

Profile & Debug — 3 skills

Go from "it's slow" to the exact op or SYCL kernel responsible.

Most teams don't start from scratch, of course — they start from a CUDA repo.

Migrate from CUDA — 2 skills

Assess and execute a CUDA-to-XPU port with a repeatable, gated process.

The split is the point: assessment never executes, execution never guesses.

cuda-to-xpu-migration runs a read-only scan and sorts findings into five tiers — portable PyTorch/HF, container/runtime, serving launch scripts, Triton kernels, and hard CUDA-native blockers (.cu/.cuh, CuPy, NCCL, TensorRT, flash-attn, bitsandbytes, cuBLAS/CUTLASS/ cuTENSOR/cuSPARSE/cuDNN) — then routes each to the skill that handles it. Its report always opens with the literal verdict: Migration result: COMPLETE | PARTIAL | BLOCKED.

xpu-port then executes deterministically, with a hard gate in the middle:

python3 xpu_port_scan.py . > findings.json          # tag: mechanical | semantic | escalate
python3 xpu_port_rewrite.py --transform <t> --path . # named, --check-previewable
python3 xpu_port_scan.py . > findings.after.json    # mechanical bucket MUST be zero
python3 xpu_port_verify.py .                        # CPU FP64 vs target dtype

---

Example: porting a PDF-to-podcast solution end to end

That's the catalog. Here's what it looks like when the skills have to cooperate on something real.

As an example, let's take a popular PDF-to-podcast solution and examine how the skills can help an agent run it fully on a system with four Intel Arc Pro B70 GPUs.

The original solution uses external inference APIs and can also be deployed with local GPUs. The goal here is to replace the external inference path with local inference on Intel Arc Pro hardware while preserving the rest of the application flow. The example is based on the pdf-to-podcast repository.

How this was planned and deployed

The important part is the routing. The migration assessment classifies the original application as api-first: model inference is accessed through service endpoints rather than through a large local CUDA kernel surface. That means the agent can focus on replacing the inference endpoint, selecting an XPU-compatible serving stack, and validating the deployment on four Arc Pro B70 GPUs instead of attempting an unnecessary kernel rewrite.

What remains is a small code edit, swapping the original model client for a local OpenAI-compatible client, plus a configuration-level endpoint change from the external inference service to a local vLLM-XPU endpoint. The full chain, from assessment through deployment planning to validation, is the sequence shown in the panel above.

Verified end to end on real Arc Pro hardware, PDF in, playable MP3 out.

---

Verified like a security control, not a doc

All of which raises a fair question: why trust any of this?

A Skill isn't a document an agent reads for inspiration. It's an instruction set an agent executes with real permissions — launching containers, installing packages, binding host devices. Wrong skills don't give bad advice; they run bad commands.

So each of the 20 ships an executable YAML contract, checked against the agent's actual recorded output:

• Activation — prompts that must trigger it, and near-misses that must not.
• Requirements — the right tool, the right flag, and a real verification step before reporting success.
• Forbidden — destructive cleanup, EOL toolchains, or CUDA-only flags that silently no-op on Intel.

260 checks · 231 pass · 29 advisory warn · 0 fail. 100% of required (error-severity) checks passing, 9.4/10 average. One failing required check blocks merge in CI.

Highest-risk skills run on real Battlemage silicon, not mocks. xpu-system-setup on an Arc Pro B70 / Ubuntu 24.04 stock kernel found all three broken prerequisite layers (nomodeset in GRUB, missing xe alias, compute runtime too old), applied --fix, and came back all-clear after reboot. sglang-xpu-run on a physical B580 surfaced a kernel/UMD mismatch and a non-root render-group bug a mock trace would never have caught — both now documented in the skill with the fix.

Currently verified against Claude Sonnet 4.6 via the skillverify harness. Broader model coverage is planned as the live-agent adapters mature.

---

Install it

git clone https://github.com/intel/gpu-ai-skills.git intel-gpu-ai-skills
cd intel-gpu-ai-skills && bash scripts/install.sh

Detects every agent on the machine and installs into all of them. --all creates dirs for agents you haven't used, --agent <name> targets one, --uninstall reverses it.

For any other agent, clone this repo and copy the skill folders into the agent's skills directory:

On Ubuntu 24.04 + Arc Pro B60/B70? Run this first — it checks nomodeset in GRUB, the OEM kernel 6.17 requirement, and compute runtime ≥26.18:

bash plugins/intel-gpu-ai-skills/skills/xpu-system-setup/scripts/check_battlemage_prerequisites.sh --fix

Then just describe what you want:

"Start a vLLM server with Qwen2.5-7B on my Intel GPU." "Why is my Qwen2.5 generate() slow on Intel?" "I have a CUDA repo — assess what it takes to port it to XPU."

---

Why it matters

Intel Arc Pro GPU are priced to compete on cost per token — but only if teams can operate them without re-learning a toolchain. Every hour rediscovering that --gpus all is a silent no-op, that fp8 KV needs a specific attention backend, or that SGLang fell back to CPU and your benchmark is fiction, is an hour of hardware savings that never reaches the bottom line.

Each of these 20 skills encodes one real, verified failure mode — so your team, and your agent, never pays for it twice.

⭐ github.com/intel/gpu-ai-skills · Apache-2.0

Found a wrong flag or a missing failure mode? Open an issue — that's exactly the knowledge this pack exists to capture.