/agentsop-llm-engine-selection

name: agentsop-llm-engine-selection
description: Cross-engine decision rubric for self-hosting or recommending an LLM serving stack. Picks among vLLM, SGLang, TensorRT-LLM, TGI, llama.cpp, Ollama, and MLX as a function of (hardware × workload × constraint), not "which is fastest". Activates whenever a coder-agent must choose, defend, or migrate a serving runtime.
domain: LLM inference engine selection
version: 0.1.0
dated: 2026-05
sources:
  - https://www.yottalabs.ai/post/best-llm-inference-engines-in-2026-vllm-tensorrt-llm-tgi-and-sglang-compared
  - https://explore.n1n.ai/blog/llm-inference-engine-comparison-vllm-tgi-tensorrt-sglang-2026-03-13
  - https://developers.redhat.com/articles/2025/09/30/vllm-or-llamacpp-choosing-right-llm-inference-engine-your-use-case
  - https://aimadetools.com/blog/vllm-vs-ollama-vs-llamacpp-vs-tgi/
  - https://contracollective.com/blog/llama-cpp-vs-mlx-ollama-vllm-apple-silicon-2026
  - https://arxiv.org/abs/2309.06180

LLM Engine Selection SOP

> **State-of-the-art warning.** This skill is dated **May 2026**. The inference-engine landscape moves in 3–6 month cycles (TGI exited maintenance into deprecation in late 2025; SGLang's RadixAttention regressed vLLM's lead in 2024; TensorRT-LLM dropped its proprietary-engine requirement in 2025; Ollama added concurrent-request support mid-2025). Re-verify before betting a quarter of eng budget on any choice below.

---

1. 何时激活 (When to activate)

Activate this skill any time a coder-agent must:

• **Pick** a serving stack for a new project (production hosting / batch / edge / dev laptop / multi-tenant SaaS / structured-output service).
• **Defend** an existing stack against a "let's switch to X" pressure.
• **Migrate**: justify or block a swap (e.g. TGI → vLLM, Ollama → vLLM, vLLM → TensorRT-LLM).
• **Mix**: design a multi-tier deployment (e.g. premium tier on TensorRT-LLM, free tier on vLLM-AWQ, dev on Ollama).
• **Audit** a recommendation that smells like benchmark-cherry-picking ("X is 5× faster").

Do **not** activate for:

• Tuning a single chosen engine — defer to the dedicated skill (`vllm`, `sglang`, `tensorrt-llm`, `llama-cpp`).
• Training/fine-tuning runtime selection — different problem class (`accelerate`, `deepspeed`, `axolotl`).
• Hosted-API procurement (OpenAI / Anthropic / Bedrock) — engine choice doesn't apply.

---

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

**Engine choice is a function of (hardware × workload × constraint), not "which is fastest".**

There is no global ranking. Every "X beats Y by N%" headline holds only inside an unstated (hardware, batch size, ISL/OSL, model, quantization, concurrency) tuple. Change any axis and the ranking flips.

2.1 The four-axis decision space

1. **Hardware axis** — NVIDIA H100/A100 (NVLink) ≠ NVIDIA L40S/RTX (PCIe-only) ≠ AMD MI300 ≠ Apple Silicon ≠ CPU-only. The interconnect topology matters as much as raw FLOPS [spheron.network 2026]. PCIe-only tensor parallelism collapses; NVLink rescues it. 2. **Workload axis** — production multi-user (throughput) vs latency-bound single-stream vs offline batch vs edge single-user vs structured-output service vs multi-LoRA SaaS. Each has a different winner. 3. **Constraint axis** — license (Apache vs proprietary), vendor lock-in tolerance, engineering budget (1 day vs 2 weeks setup), commercial-use clauses, on-prem vs cloud, P50 vs P99 SLA. 4. **Maturity axis** — the engine's coverage of YOUR model family. A 2025-launched MoE may run on vLLM day-1 but need a 3-month wait for TensorRT-LLM, and may never get a stable GGUF.

2.2 The default in 2026

For **GPU-backed, multi-user, open-weights** serving, the default is **vLLM**. It owns the production slot because it is vendor-neutral (NVIDIA/AMD/Intel/TPU/Apple-experimental), supports 200+ architectures including MoE/multimodal, ships an OpenAI-compatible API, and HuggingFace themselves recommend it over their own (now-maintenance-mode) TGI [yottalabs.ai 2026; vllm-project README].

You only reach past vLLM when one of three conditions binds:

• **Workload-binding** (heavy prefix sharing or structured generation → SGLang).
• **Hardware-binding** (NVIDIA-only + max throughput goal → TensorRT-LLM; CPU/edge/Apple → llama.cpp/MLX/Ollama).
• **Operator-binding** (dev laptop, want 5-min setup → Ollama; ≤1 concurrent user → llama.cpp).

2.3 "Fastest" is a category error

Throughput-per-GPU, throughput-per-dollar, P50 TTFT, P99 ITL, and developer-time-to-first-request are **five different goals**, and the engines optimize for different combinations:

| Engine | What it optimizes for | |---|---| | vLLM | Throughput-per-GPU across mixed traffic, model breadth | | SGLang | Throughput when requests share prefix; structured-gen TPS | | TensorRT-LLM | Peak throughput on NVIDIA at saturation; per-token cost at scale | | TGI | Was generic; now mostly a migration source | | llama.cpp | Single-user TPS on CPU/Apple/edge; minimal-deps install | | Ollama | Developer-time-to-first-request (5 min) | | MLX | Apple Silicon throughput and Apple-native dev UX |

Pick by **which axis your project is binding on**, not by which engine has the most stars.

---

3. SOP 工作流 (SOP Workflow)

[Step 0] Define the four-axis constraint vector
   ├─ Hardware: GPU vendor, count, interconnect (NVLink? PCIe?), VRAM/GPU
   ├─ Workload: # concurrent users, ISL/OSL distribution, shared-prefix %, structured-out %
   ├─ Constraint: license, vendor-lock tolerance, eng-days budget, P50/P99 SLA
   └─ Model: family (Llama/Qwen/Mixtral/DeepSeek/Mamba/...), size, quantization preference

[Step 1] Eliminate incompatible engines (hard filters)
   ├─ No NVIDIA GPU?            → drop TensorRT-LLM
   ├─ CPU/Apple/edge only?      → drop vLLM (production), TGI, TensorRT-LLM
   ├─ Need OSS-permissive only? → drop TensorRT-LLM (NVIDIA license)
   ├─ Mamba / brand-new arch?   → check vLLM+SGLang coverage; likely drop others
   └─ Multi-LoRA hot-swap?      → vLLM (best), TensorRT-LLM (good), SGLang (good); ot