LLM 推理工程精选 · 2026-07-02

筛选语境

• 角色：Jay 工程文章二次筛选
• 维度：真实环境 / 命令 / 错误日志 / 源码 / 性能数据 / 可复现步骤
• 本次主题：推理引擎基准 + Serving 系统工程

条目一：vLLM vs TensorRT-LLM vs SGLang H100 2026 基准实测

来源：Spheron Blog
URL：https://www.spheron.network/blog/vllm-vs-tensorrt-llm-vs-sglang-benchmarks
作者/机构：Spheron（基础设施运营商）
发布日期：2026（具体日期见原文）
可信度：高 — 商业实测，数据可查

核心观点

三大推理引擎在 H100 80GB + Llama 3.3 70B FP8 下的横向对比，含完整部署命令和环境说明。vLLM 和 SGLang 使用 CUDA 13.0（cu130），TensorRT-LLM v1.2.0 使用 CUDA 13.1.0（pytorch:25.12-py3）。

工程价值

命令链路（可直接复制）：

# === 验证环境 ===
nvidia-smi

# === vLLM 部署（最快路径）===
docker run --gpus all --ipc=host -p 8000:8000 \
  -e HUGGING_FACE_HUB_TOKEN=your_token_here \
  vllm/vllm-openai:v0.18.0-cu130 \
  --model meta-llama/Llama-3.3-70B-Instruct \
  --quantization fp8 \
  --max-model-len 8192 \
  --gpu-memory-utilization 0.92 \
  --host 0.0.0.0 --port 8000

# === TensorRT-LLM 量化 + 引擎构建（两步）===
# Step 1: FP8 量化（约5min on H100）
docker run --gpus all --ipc=host \
  -v /path/to/model:/models -v /path/to/engine:/engines \
  nvcr.io/nvidia/tensorrt-llm/release:1.2.0 \
  python examples/quantization/quantize.py \
  --model_dir /models/Llama-3.3-70B-Instruct \
  --dtype float16 --qformat fp8 \
  --kv_cache_dtype fp8 \
  --output_dir /engines/fp8-checkpoint \
  --calib_size 512

# Step 2: 构建 TRT 引擎（约23min on H100）
docker run --gpus all --ipc=host \
  -v /path/to/engine:/engines \
  nvcr.io/nvidia/tensorrt-llm/release:1.2.0 \
  trtllm-build --checkpoint_dir /engines/fp8-checkpoint \
  --output_dir /engines/llama70b-engine

# === TensorRT-LLM 服务 ===
docker run --gpus all --ipc=host -p 8000:8000 \
  -v /path/to/engine:/engines \
  nvcr.io/nvidia/tensorrt-llm/release:1.2.0 \
  trtllm-serve /engines/llama70b-engine --port 8000 --host 0.0.0.0

性能数字（来自 inferenceengineering.tech 补充）： - TensorRT-LLM kernel launch 开销：~5-10μs/次（32-layer 模型累积显著） - SGLang 在 100+ 并发 + TP=2 + 5,980 requests 场景下，高并发 prefix-heavy 工作负载优于 vLLM - TensorRT-LLM auto-tuned kernel：在构建时实测选择最优 kernel 实现在 H100 上通常领先

评价

罕见的三引擎生产路径完整命令，含容器版本、量化校准size、引擎构建耗时。FP8 + H100 配置是 2026 年生产部署的主流 baseline，这组命令可直接用于 POC 评估。需注意 TRT-LLM 的引擎构建耗时（合计约28min）是 one-time cost，但模型更新需重建。

分类标签

推理引擎 vLLM TensorRT-LLM SGLang H100 FP8 Docker CUDA Benchmark

后续行动

• [ ] 如需精读：对照 Spheron 原文 benchmark 数字（吞吐量/TTFT）填入
• [ ] 对比 inferenceengineering.tech 的内核分析补充到工程笔记
• [ ] 可建议创建「推理引擎选型决策树」主题页

条目二：tiny-llm — 从零实现 LLM Serving（MLX + Python）

来源：GitHub
URL：https://github.com/skyzh/tiny-llm
作者：skyzh
可信度：高 — 完整测试覆盖，开源可复现

核心观点

3周课程，用纯 Python（仅 MLX for Apple Silicon）实现类 vLLM 的推理系统。从 Attention 机制开始，逐步实现 KV Cache、Continuous Batching、Flash Attention、Paged Attention 等核心组件。

工程价值

完整 Chapter 进度表（截至目前）：

为何选 MLX：Apple Silicon 本地开发环境比 NVIDIA GPU 更易获得；Qwen3 保持 dense decoder 架构足够小，同时包含 QK norm 和 bfloat16 等现代特性。

评价

系统级 serving 工程学习路径，每个子任务均有测试用例。对于想深入理解 vLLM 内部原理（如 PagedAttention 的 chunked prefill 机制、MoE dispatch）的工程师，这是目前最完整的从零学习资源。相比论文，代码+测试的学习曲线更平缓。

分类标签

LLM Serving MLX vLLM内部原理 PagedAttention ContinuousBatching FlashAttention MoE Python Qwen3

后续行动

• [ ] 建议纳入「LLM 工程学习路径」主题页参考教材
• [ ] 可对比 vLLM 源码验证各章节实现正确性

条目三：inferenceengineering.tech — vLLM vs SGLang vs TensorRT-LLM 架构深度分析

来源：技术博客
URL：https://inferenceengineering.tech/learn/vllm-vs-sglang-vs-tensorrt-llm
可信度：高 — 专注推理工程的独立技术博客

核心观点

三引擎在 Feature 层面的差距已大幅收窄（均支持 continuous batching、paged KV cache、FP8），真正的差异在于架构选择和由此产生的性能 trade-off。

工程价值

内核级性能数据： - TensorRT-LLM operator fusion 更激进：attention + layer norm + linear layers 融合为单 kernel - CUDA graph 覆盖整个 forward pass，消除 CPU 端 kernel launch 开销（~5-10μs/次 × 32 layers） - Auto-tuned kernel selection：构建时在真实硬件上跑多实现并选择最优

调度开销实测： - SGLang 在 100+ 并发场景调度开销低于 vLLM，因为更多逻辑在 C++/CUDA 而非 Python - RadixAttention trie lookup 对每请求有固定开销，但 prefix 命中率高的场景可多次摊薄 - TP=2 + 5,980 requests 实测：SGLang 在高并发 prefix-heavy 场景与 vLLM 持平或更好

决策树（原文 if/then，可直接用）： 1. 需要最高单卡吞吐 + NVIDIA-only + 模型稳定 → TensorRT-LLM 2. 高并发 MoE + 多模态 prefix 共享 + 愿意承担调度复杂性 → SGLang 3. 需要快速迭代 + 框架多样化 + 最好兼容性 → vLLM 4. 默认 → vLLM（当前生产部署主流选择）

评价

对推理引擎内部机制（kernel fusion、CUDA graph、scheduler overhead）的解释最为深入。与 Spheron 命令实测形成互补：Spheron 解决「怎么部署」，本文解决「为什么选这个」。两份材料组合可支撑完整选型决策。

分类标签

推理引擎 vLLM SGLang TensorRT-LLM CUDA Benchmark 架构分析 Kernel 调度

后续行动

• [ ] 建议与 Spheron 基准文章组合引用
• [ ] 可创建「推理引擎选型指南」综合页面

条目四：arxiv:2602.21193 — 数据工程扩展 LLM Terminal Capabilities

来源：arXiv
URL：https://arxiv.org/abs/2602.21193
作者：Renjie Pi, Grace Lam, Mohammad Shoeybi, Bryan Catanzaro, Wei Ping（NVIDIA）
可信度：高 — NVIDIA 团队，EASE 2026 接受

核心观点

终端 Agent 的训练数据策略在 SOTA 模型中基本未公开。本文提出 Terminal-Task-Gen（轻量合成任务生成 pipeline）和系统性数据/训练策略分析，填补这一空白。

工程价值

Terminal-Task-Gen pipeline： - Seed-based 任务构造：从真实任务种子扩展 - Skill-based 任务构造：按技能维度系统性覆盖

数据与训练策略（均有量化数字）： - Filtering：低质量轨迹过滤方法 - Curriculum Learning：课程式难度递增 - Long Context Training：长上下文训练策略 - Scaling Behavior：不同规模模型 scaling 曲线

Benchmark 实测（Terminal-Bench 2.0）：

32B 模型以 27.4% 匹配显著更大模型的性能。

评价

业界少有的 terminal agent 数据工程公开研究。合成任务生成方法（seed-based + skill-based）可直接迁移至其他 agent 场景的 dataset 构建。curriculum learning + scaling behavior 分析对数据策略设计有直接参考价值。NVIDIA 团队出品，工程可信度高。

分类标签

Agent 数据工程 合成数据 Terminal Agent Curriculum Learning Scaling RAG NVIDIA

后续行动

• [ ] 检查原文 GitHub 链接（arXiv 页面有 Code 入口）
• [ ] 如有 GitHub：克隆验证 Terminal-Task-Gen pipeline 代码
• [ ] 可与 agentic RAG 数据构建主题关联

汇总

建议写入路径：/shared/research-kb/review/（由同步任务合并至 published/）

本轮写入文件：/shared/research-kb/inbox/jay/2026-07-02-llm-inference-engineering.md