---
id: agentsope/SkillAlchemy/agentsop-vllm
version: "81b8cacc"
license: MIT
install: manual
updated: 2026-06-30
---

# agentsop-vllm — A structured decision guide for deploying and tuning vLLM in production environments. Covers the PagedAttention memory model, continuous batching, quantization tradeoffs, tensor/pipeline parallelism choices, and step-by-step operational workflows for diagnosing throughput, latency, and out-of-memory issues. Includes comparisons to alternative inference engines and guidance on when vLLM is the right fit.

Publisher: agentsope · Stars: 219 · Updated: 2026-06-30

Install (manual): `git clone https://github.com/agentsope/SkillAlchemy`

## SKILL.md

# vLLM Serving SOP

## 1. 何时激活 (When to activate)

Activate this skill when any of the following hold:

- The user wants to **serve an LLM in production** (multi-user, concurrent requests, throughput-oriented) and has GPU infrastructure.
- The user is **comparing inference engines** (vLLM vs TGI vs SGLang vs TensorRT-LLM vs llama.cpp/Ollama).
- The user reports a **vLLM operational issue**: CUDA OOM, low throughput, high TTFT, request preemption, multi-GPU setup, quantization choice.
- The user is **sizing hardware** for an open-weights model (Llama / Qwen / Mixtral / DeepSeek-V3) and asking about tensor/pipeline parallelism.
- The user mentions PagedAttention, prefix caching, continuous batching, chunked prefill, or speculative decoding.

**Do NOT activate** for: training/fine-tuning (use accelerate/deepspeed/trl), CPU-only edge inference (use llama.cpp/Ollama), Apple Silicon production (vLLM Metal/MPS is experimental, not production-ready as of 2026) [aimadetools.com 2026], API-only consumption of hosted models (just call the OpenAI/Anthropic SDK).

---

## 2. 核心心智模型 (Core Mental Model)

### 2.1 The OS abstraction: KV cache as virtual memory

vLLM's defining insight (Kwon et al., SOSP 2023) is that **LLM serving's bottleneck was not compute — it was KV-cache memory fragmentation**. Pre-vLLM systems pre-allocated a contiguous KV-cache slot per request, sized for the maximum possible output length; in early 2023, inference engines used only **20–40% of available GPU memory** because of internal+external fragmentation [arxiv.org/abs/2309.06180; zilliz.com/learn].

PagedAttention applies classic OS paging to KV cache:

- **Block** = fixed-size chunk of KV cache (default 16 tokens; ~12.8 KB for a 13B model) [medium.com/@mandeep0405].
- **Logical blocks** per request → **block table** → **physical blocks** in GPU memory (analogous to virtual→physical page table).
- Blocks need not be contiguous. The attention kernel reads scattered physical blocks via the block table and presents them as a logical contiguous sequence.
- **Copy-on-write** + **prefix sharing**: multiple requests that share a prefix (e.g. a system prompt, few-shot examples) share KV blocks; a write triggers a per-request copy [arxiv.org/abs/2309.06180].

**Result**: near-zero memory waste → larger batch sizes → **2–4× throughput** vs FasterTransformer/Orca at equal latency [arxiv.org/abs/2309.06180]; **14–24×** vs vanilla HuggingFace Transformers [yottalabs.ai 2026].

### 2.2 The scheduler: iteration-level (continuous) batching

vLLM inherits Orca's iteration-level scheduling (OSDI 2022, **36.9× over FasterTransformer** [medium.com/byte-sized-ai]). Instead of waiting for a static batch to finish, the scheduler reassigns batch slots **every decode step**: a request that finishes early frees its slot to a waiting request. Static batching is dead; continuous batching is table stakes.

### 2.3 Prefill vs decode are different beasts

- **Prefill** (processing the prompt): compute-bound, high SM utilization, scales with input length.
- **Decode** (generating tokens one-at-a-time): memory-bandwidth-bound, low SM utilization.
- A long prefill blocks all decodes on the GPU → **head-of-line blocking** → high inter-token latency (ITL) for already-streaming requests.
- **Chunked prefill** breaks long prefills into pieces interleaved with decode steps [docs.vllm.ai/en/stable/configuration/optimization/].

**Takeaway**: when tuning, separate TTFT (time-to-first-token, gated by prefill+queue) from ITL (gated by decode bandwidth and batch interference).

### 2.4 Three throughput levers, in order of impact

Per Red Hat's tuning hierarchy [developers.redhat.com 2026]:
1. **Right-size the model** (smallest adequate).
2. **Scale hardware** (more replicas; better-bandwidth GPUs).
3. **Quantize** (FP8 weights + KV cache).
4. **Speculative decoding** (model-based: EAGLE-3 / MTP).
5. **Refine parallelism** (TP degree, replicas vs higher TP).

---

## 3. SOP 工作流 (SOP Workflow)

```
[Step 0] Confirm vLLM is the right tool
   ├─ Production, GPU-backed, concurrent users? → continue
   └─ Else → see §7 (ecosystem) and stop

[Step 1] Pick the model + precision
   ├─ Model fits in single-GPU VRAM at BF16?         → keep BF16, TP=1
   ├─ Need 50% VRAM cut, ~zero quality loss?         → FP8 (Hopper/Ada+) [arxiv 2411.02355]
   ├─ Need 4× VRAM cut, tolerate ~1.6pt avg drop?    → AWQ-4 or GPTQ-4
   └─ Reasoning-heavy / coding workload?             → favor FP8 > AWQ; verify on eval set

[Step 2] Choose parallelism
   ├─ Fits 1 GPU                                     → TP=1, PP=1
   ├─ Fits 1 node, NVLink present                    → TP=#GPUs/node
   ├─ Fits 1 node, only PCIe (e.g. L40S)             → PP within node (TP-only over PCIe collapses)
   ├─ Multi-node                                     → TP=GPUs/node, PP=#nodes
   └─ MoE model (Mixtral, DSv3)                      → DP attention + EP/TP for MoE layers

[Step 3] Set memory/batch envelope
   ├─ --gpu-memory-utilization 0.90 (default; 0.85 if sharing GPU)
   ├─ --max-model-len = (longest realistic prompt + output) — NOT model max!
   ├─ --max-num-seqs (start 256; lower if preemption logs appear)
   └─ --max-num-batched-tokens (raise for TTFT; lower for ITL)

[Step 4] Turn on the free wins
   ├─ enable_prefix_caching=True            → if any system-prompt/few-shot reuse
   ├─ enable_chunked_prefill=True (V1: default on) → tame long-prompt HoL blocking
   └─ kv_cache_dtype="fp8"                  → +KV headroom, Ampere+ only

[Step 5] Optional: speculative decoding
   ├─ Low QPS, latency-bound, have draft/EAGLE weights? → EAGLE-3 or MTP (high gain)
   ├─ No draft model, zero setup cost?                  → n-gram (modest gain, ~1.17×)
   └─ High QPS / large batch?                           → skip; gains shrink, complexity rises

[Step 6] Benchmark on YOUR workload
   ├─ Replay representative ISL/OSL distribution
   ├─ Watch Prometheus: num_requests_waiting, KV cache occupancy, preemption count
   └─ Tune in this order: §3 Step 3 → Step 4 → Step 5 → reconsider Step 2

[Step 7] Scale out
   ├─ Latency SLA violated under load? → add a replica (data parallelism across pods)
   ├─ Tail TTFT high?                  → prefix-aware routing; pin prefix to replica
   └─ Cost too high?                   → revisit quantization, smaller model, draft model
```

---

## 4. 操作模型 (Operation Model: Trigger / Action / Output / Evidence)

### OP-1: Diagnose vLLM CUDA OOM at startup
- **Trigger**: log shows `torch.OutOfMemoryError: CUDA out of memory` during engine init or warmup.
- **Action**:
  1. Lower `--max-model-len` to the realistic max (`prompt + output`), not the model's architectural max [markaicode.com 2026].
  2. Lower `--gpu-memory-utilization` to `0.85` if other processes share the GPU; raise to `0.95` if vLLM is alone and KV cache is too small.
  3. Add `--kv-cache-dtype fp8` (Ampere+) or `--enforce-eager` (skip CUDA-graph reservation).
  4. Reduce `--max-num-seqs` (e.g. 256 → 64 → 16).
  5. If still OOM at TP=1: bump `--tensor-parallel-size` to shard the model.
- **Output**: engine starts; KV cache occupancy logged at boot is non-zero and <100%.
- **Evidence**: [docs.vllm.ai/en/stable/configuration/conserving_memory/]; [discuss.vllm.ai/t/cuda-failure-out-of-memory/524]; [github.com/vllm-project/vllm/issues/188].

### OP-2: Pick quantization for an open-weights model
- **Trigger**: deploying a model that doesn't fit at BF16, or where cost/throughput matters more than peak quality.
- **Action**:
  1. **Hopper/Ada/Blackwell GPU available?** → prefer **FP8** (effectively lossless across model scales) [arxiv.org/abs/2411.02355].
  2. **No FP8 hardware, need 4× compression?** → AWQ-4 (better stability at 4-bit) or GPTQ-4 (slightly better on code tasks) [arxiv.org/abs/2411.02355].
  3. **Avoid INT3 / 3-bit**: ~6-point average drop, not worth it.
  4. Verify on a held-out eval set in your domain before shipping.
- **Output**: chosen `--quantization {fp8|awq|gptq|...}` flag; documented expected accuracy delta.
- **Evidence**: [arxiv.org/abs/2411.02355 "Give Me BF16 or Give Me Death"]; [docs.gpustack.ai vLLM quantization].

### OP-3: Configure tensor/pipeline parallelism
- **Trigger**: model too large for one GPU; multi-GPU or multi-node deployment.
- **Action**:
  1. **One node + NVLink**: `--tensor-parallel-size=<GPUs in node>`, PP=1.
  2. **One node + only PCIe** (e.g. L40S, consumer cards): consider `--pipeline-parallel-size` instead of large TP — all-reduce over PCIe will tank TP throughput [docs.vllm.ai parallelism_scaling].
  3. **Multi-node**: `TP=GPUs/node`, `PP=#nodes`. Use InfiniBand if possible.
  4. **MoE (Mixtral/DSv3)**: combine **DP attention + EP/TP on MoE layers**.
  5. Test TP=2 vs TP=4 vs 2×replicas-of-TP=2 — replicas often win on throughput-per-dollar when one replica already saturates [developers.redhat.com 2026 step 5].
- **Output**: chosen TP/PP/DP/EP config with measured tokens/s on real workload.
- **Evidence**: [docs.vllm.ai/en/stable/serving/parallelism_scaling/].

### OP-4: Enable prefix caching
- **Trigger**: workload has repeated prefixes (shared system prompt, few-shot examples, RAG with stable instructions, multi-turn chat with same persona).
- **Action**: launch with `--enable-prefix-caching` (in V1, often on by default).
- **Output**: prefill TTFT drops on cache-hit requests; KV occupancy may rise (cached blocks held longer).
- **Caveats**:
  - APC accelerates **prefill only**; if outputs are long and prefixes don't repeat, gain ≈ 0 [docs.vllm.ai automatic_prefix_caching].
  - In multi-replica clusters, naive round-robin scatters prefix-sharing requests → use **prefix-aware routing** (e.g. Ray Serve LLM, llm-d) [llm-d.ai/blog/kvcache-wins-you-can-see].
  - Multi-tenant privacy: use **cache salting** to avoid cross-tenant prefix collisions [github.com/vllm-project/vllm/issues/16016].
- **Evidence**: [docs.vllm.ai/en/stable/design/prefix_caching/].

### OP-5: Triage live performance (TTFT vs ITL)
- **Trigger**: SLA miss, user complaints, queueing alerts.
- **Action** (5-step Red Hat triage):
  1. **Split symptom**: high TTFT vs high ITL? (Prometheus histograms.)
  2. **Saturation**: `num_requests_waiting` > 0 sustained → engine queue-bound; check `num_requests_running`.
  3. **KV health**: KV cache occupancy near 100% with rising preemption count → drop `--max-num-seqs` or quantize KV to FP8.
  4. **Sequence-length correlation**: ITL ~40 ms/token implies ~40 s per 1000 tokens output — sometimes the workload is the answer.
  5. **Interconnect check**: PCIe-only with TP=4? Drop to TP=2 + 2 replicas.
- **Output**: identified bottleneck class (queue / compute / memory / interconnect) and one targeted change.
- **Evidence**: [developers.redhat.com 2026 5-steps-triage].

### OP-6: Decide on speculative decoding
- **Trigger**: latency-bound workload, model ≥ 13B, low/medium QPS.
- **Action**:
  - If draft/EAGLE-3 weights exist for the target model → enable; expect up to **2.5×** decode speedup [developers.redhat.com 2025 eagle3].
  - If not → try **n-gram** (~1.17×, no extra weights, ~zero risk) [jarvislabs.ai].
  - **Skip** speculative decoding if QPS is high (large batches already saturate compute → speculation wastes capacity).
  - Always benchmark: poor hyperparameter tuning can degrade cost-per-token by up to **175%** [arxiv.org/pdf/2601.11580].
- **Output**: `--speculative-config` JSON, with measured tokens/s delta on representative traffic.
- **Evidence**: [docs.vllm.ai/en/latest/features/speculative_decoding/].

---

## 5. 困境决策案例 (Dilemma Cases)

### Dilemma 1: Throughput vs Latency — how aggressively to batch?

**Situation**: A team serves Llama-3-70B-FP8 on 2×H100. P50 TTFT is fine at 250 ms, but P99 spikes to 4 s when traffic bursts. They consider raising `--max-num-seqs` from 64 to 256 to handle bursts.

**Tension**:
- Higher `max_num_seqs` → more concurrency → higher throughput, but also more contention for KV cache → preemption + head-of-line blocking on prefills.
- Higher `max_num_batched_tokens` → better TTFT (more prefill per step) → worse ITL for streaming requests already mid-decode.

**Resolution heuristic**:
- If P99 spike correlates with `num_requests_waiting > 0` and KV occupancy < 80%: raise `max_num_seqs`.
- If KV occupancy hits 100% and **preemption counter rises**: do NOT raise; either quantize KV to FP8, add a replica, or shorten `max_model_len`.
- For latency-sensitive interactive workloads: **lower** `max_num_batched_tokens` (e.g. 2048) to favor decode/ITL; for batch/offline: **raise** (≥8192) to favor TTFT/throughput [docs.vllm.ai optimization; anyscale.com].

**Evidence**: [developers.redhat.com 2026 5-steps-triage]; [medium.com/@kaige.yang0110].

### Dilemma 2: 4-bit AWQ vs FP8 — is the quality drop worth the VRAM?

**Situation**: Deploying Qwen-72B on a single H100 (80 GB). At BF16, model is 144 GB → doesn't fit. Options: (a) FP8, 72 GB → fits with tight KV budget; (b) AWQ-4, 36 GB → comfortable KV budget, larger batches.

**Tension**:
- FP8 is empirically **near-lossless** across all model scales [arxiv.org/abs/2411.02355], but leaves little KV headroom on a single H100 → smaller batches → less throughput.
- AWQ-4 frees ~36 GB for KV → 2–3× more concurrent sequences → higher throughput, but loses ~1.6 average points on benchmarks (more on reasoning-heavy/long-context tasks).

**Resolution heuristic**:
- **Quality-critical** (legal, medical, coding agent): FP8 + accept smaller batch, or move to 2×H100 with TP=2 and stay at BF16.
- **Throughput-critical** (bulk classification, summarization, search re-ranking): AWQ-4 wins; validate on YOUR eval set, not generic benchmarks (real-world drop on code can exceed academic-benchmark drop) [arxiv.org/abs/2411.02355].
- **Mixed**: serve two replicas — FP8 for premium tier, AWQ for free tier.

**Evidence**: [arxiv.org/abs/2411.02355]; [docs.gpustack.ai vLLM quantization].

### Dilemma 3: TP=4 single replica vs 2×TP=2 replicas for a 70B model

**Situation**: 4×A100-80GB available, NVLink. Choice: one big replica (TP=4, max single-request latency optimized) or two replicas (TP=2, more concurrency).

**Tension**:
- **TP=4** lowers single-request latency (model layers parallelized further), but all-reduce overhead grows quadratically; on saturated workloads, marginal throughput per added GPU diminishes.
- **2×TP=2** doubles independent throughput (each replica handles its own batch) and survives one-replica failures, but a single request can never go faster than TP=2.

**Resolution heuristic**:
- If P99 latency SLA is the binding constraint and single-request decode is the bottleneck → **TP=4**.
- If throughput-per-dollar is the constraint, requests are independent, and average request latency at TP=2 is acceptable → **2×TP=2 replicas**; this is the Red Hat triage step-5 recommendation [developers.redhat.com 2026].
- Always check NVLink topology: across-NUMA TP=4 on PCIe degrades faster than two NVLink-paired TP=2 islands [servermo.com vLLM multi-gpu].
- Benchmark with `vllm bench serve` on representative ISL/OSL.

**Evidence**: [docs.vllm.ai parallelism_scaling]; [docs.jarvislabs.ai scaling-llm-inference-dp-pp-tp].

### Dilemma 4: Prefix caching ROI — is the RAM cost justified?

**Situation**: Production RAG service. Each request has a 2 KB system prompt + 4–16 KB context + short user query. They wonder whether `enable_prefix_caching` helps enough to justify the held KV blocks.

**Tension**:
- APC reduces **prefill** time on cache-hit; if 90% of requests share the system prompt, prefill of those tokens is free → big TTFT win.
- Cached blocks **stay resident** in KV memory → fewer free blocks for new requests → can trigger preemption on bursty traffic.

**Resolution heuristic**:
- **Enable** when shared-prefix fraction ≥ ~30% and outputs are short-to-medium (APC helps prefill, not decode) [docs.vllm.ai automatic_prefix_caching].
- **Disable / tune** when requests are unique and long-output dominated — caching just consumes KV with no hit-rate.
- For multi-replica deployments: pair with **prefix-aware routing** so requests with the same prefix land on the same replica; otherwise you pay the cache cost N times for 1/N hit-rate [llm-d.ai/blog/kvcache-wins-you-can-see].
- For multi-tenant: enable **cache salting** for privacy [github.com/vllm-project/vllm/issues/16016].

**Evidence**: [docs.vllm.ai/en/stable/design/prefix_caching/]; [bentoml.com/llm/inference-optimization/prefix-caching].

### Dilemma 5: Speculative decoding — when is the complexity worth it?

**Situation**: Single-user, latency-sensitive coding assistant on Llama-3-70B. Decode dominates total latency.

**Tension**:
- EAGLE-3 can deliver up to **2.5× decode speedup** for low-QPS workloads [developers.redhat.com 2025 eagle3], but requires a trained EAGLE head, increases VRAM, and is sensitive to hyperparameters (bad config → -175% cost) [arxiv 2601.11580].
- n-gram speculation is cheap (no extra weights) but only ~1.17× speedup [jarvislabs.ai].
- At high QPS, the GPU is already saturated by real batch work; speculative compute steals capacity instead of filling idle cycles.

**Resolution heuristic**:
- **Low QPS, single-stream-latency-bound, EAGLE/MTP head available** → enable model-based speculation. Worth the engineering cost.
- **No draft weights, want easy win** → try n-gram first; if speedup < ~1.1×, disable.
- **High QPS / throughput-bound** → skip speculation, invest in quantization + parallelism instead.
- Always A/B against the non-speculative baseline on representative traffic.

**Evidence**: [docs.vllm.ai/en/latest/features/speculative_decoding/]; [developers.redhat.com 2025 fly-eagle3-fly].

---

## 6. 反模式与边界 (Anti-patterns & Boundaries)

### Anti-pattern 1: Setting `max_model_len` to the model's architectural max "just in case"
A Llama-3.1 model supports 128k context. If you serve 4k-prompt workloads but set `--max-model-len 131072`, vLLM reserves KV-cache slots for the worst case → smaller batches → throughput collapse. **Set it to your realistic max** (longest_prompt + longest_output + safety margin) [markaicode.com 2026].

### Anti-pattern 2: Treating prefix caching as a panacea
APC accelerates **prefill only**. If outputs are long and prefixes don't repeat, gain ≈ 0 — and you've consumed KV memory for nothing [docs.vllm.ai automatic_prefix_caching]. Measure shared-prefix fraction before enabling for high-pressure workloads.

### Anti-pattern 3: TP across PCIe-only GPUs
Tensor parallelism issues an all-reduce after each layer. NVLink (≈900 GB/s bidirectional) handles it; PCIe Gen4 x16 (≈32 GB/s, ~28× slower) does not [spheron.network 2026]. On L40S / consumer cards / cross-NUMA setups, **use pipeline parallelism or independent replicas instead** [docs.vllm.ai parallelism_scaling].

### Anti-pattern 4: Picking quantization off academic benchmarks alone
Academic benchmarks (MMLU, HellaSwag) show GPTQ ≈ AWQ; **real coding workloads can show meaningfully larger gaps** between methods, and quality at INT3 collapses (~6-point drop) [arxiv.org/abs/2411.02355]. Always test on your eval set.

### Anti-pattern 5: Using vLLM for the wrong workload
- **Small models / hobby use / 1 user, 1 GPU**: Ollama or llama.cpp give you 5-minute setup; vLLM's scheduler overhead doesn't pay off [aimadetools.com 2026].
- **CPU-only / edge / Apple Silicon production**: llama.cpp (GGUF) is the right tool; vLLM's Metal/MPS support is experimental as of 2026 [aimadetools.com 2026].
- **Embedding-only workloads**: vLLM supports embedding endpoints, but TEI (Text Embeddings Inference) or sentence-transformers servers are often simpler/faster for that single purpose.
- **Pure throughput, single-vendor NVIDIA, willing to spend 1–2 weeks tuning**: TensorRT-LLM can beat vLLM by 30–50% on throughput but locks you in [n1n.ai 2026].

### Anti-pattern 6: Ignoring CPU provisioning
vLLM needs minimum **`2 + N` physical CPU cores for N GPUs**; under-provisioning CPUs makes the API server, tokenizer, and detokenizer the bottleneck before the GPU is touched [docs.vllm.ai/en/stable/configuration/optimization/]. Scale CPU and use `--api-server-count` when needed.

### Anti-pattern 7: `--enforce-eager` in production "for stability"
`--enforce-eager` skips CUDA graph capture → slower decode. It's a debugging/memory-OOM workaround, not a steady-state production setting. Fix the underlying OOM (KV dtype, max_model_len, max_num_seqs) and re-enable CUDA graphs.

### Boundaries

vLLM is the right tool when:
- ✅ ≥10 concurrent requests OR variable request length OR shared prefixes.
- ✅ NVIDIA / AMD GPU with ≥1 device of sufficient VRAM.
- ✅ Decoder-only or supported architecture (Llama, Qwen, Mixtral, DeepSeek, Gemma, Phi, multimodal: LLaVA / Qwen-VL).
- ✅ Throughput, cost-per-token, or P50 latency under load is the goal.

vLLM is the **wrong** tool when:
- ❌ Single user, single stream, dev laptop.
- ❌ CPU/edge/mobile, no GPU.
- ❌ Architecture not yet supported (check the model list — Mamba/hybrid coverage is growing but incomplete).
- ❌ You need state-machine-driven structured generation tighter than vLLM's `guided_decoding` (consider SGLang for complex agent state machines).

---

## 7. 生态对照 (Ecosystem Comparison)

| Engine | Sweet spot | When to pick over vLLM |
|---|---|---|
| **vLLM** | Production GPU serving, mixed traffic, open weights, vendor-neutral | Default first choice for throughput-oriented LLM serving in 2026 |
| **TGI** (HuggingFace) | Was the HF default | Officially in maintenance mode; HF themselves now recommend vLLM or SGLang [yottalabs.ai 2026] |
| **SGLang** | Heavy prefix sharing, agent/RAG state machines, structured generation | ~29% higher throughput than vLLM when requests share context (chatbots, RAG, agents) thanks to RadixAttention prefix tree [n1n.ai 2026] |
| **TensorRT-LLM** | Single-vendor NVIDIA, max throughput, willing to invest setup | Up to 30–50% higher throughput than vLLM in high-concurrency NVIDIA-only deployments; 1–2 weeks setup; vendor lock-in [n1n.ai 2026] |
| **llama.cpp** | CPU, edge, Apple Silicon, single-user, GGUF | No GPU available; ≤1 concurrent user; minimal-deps deploy [aimadetools.com 2026] |
| **Ollama** | Local dev, prototyping, model switching | Developer ergonomics over throughput; 5-minute setup [contracollective.com 2026] |

**Common pattern**: develop on Ollama → benchmark with vLLM → consider SGLang if prefix-sharing workload → consider TensorRT-LLM only if NVIDIA-locked and engineering budget is large.

---

## Quick-start reference command

A production-ish vLLM serve for Llama-3.1-70B-Instruct-FP8 on 2×H100 with NVLink, RAG-style workload:

```bash
vllm serve meta-llama/Llama-3.1-70B-Instruct \
  --quantization fp8 \
  --tensor-parallel-size 2 \
  --max-model-len 8192 \
  --max-num-seqs 256 \
  --max-num-batched-tokens 8192 \
  --gpu-memory-utilization 0.90 \
  --enable-prefix-caching \
  --enable-chunked-prefill \
  --kv-cache-dtype fp8
```

Then triage with the §4 OP-5 5-step workflow on real traffic before tuning further.

---

## Cited sources (primary)

- PagedAttention paper: https://arxiv.org/abs/2309.06180
- vLLM docs: https://docs.vllm.ai/en/stable/
- vLLM GitHub: https://github.com/vllm-project/vllm
- Quantization tradeoffs: https://arxiv.org/abs/2411.02355
- Performance triage: https://developers.redhat.com/articles/2026/03/09/5-steps-triage-vllm-performance
- EAGLE-3 results: https://developers.redhat.com/articles/2025/07/01/fly-eagle3-fly-faster-inference-vllm-speculative-decoding
- Engine comparison: https://www.yottalabs.ai/post/best-llm-inference-engines-in-2026-vllm-tensorrt-llm-tgi-and-sglang-compared


[View on SkillFed](https://skillfed.io/agentsope/SkillAlchemy/agentsop-vllm) · [View on GitHub](https://github.com/agentsope/SkillAlchemy)