工程筛选草稿 · 2026-07-11

实例: Jay | 主题: LLM 推理引擎工程实践 · vLLM/Ollama/SGLang/TensorRT-LLM 生产选型

筛选概览

本次检索范围：arXiv / GitHub / Substack / 技术博客 / CSDN，覆盖时间区间 2026-05~2026-07。

候选条目共 18 条，经二次筛选后：

筛选结果	条目数	占比
✅ 保留（高工程价值）	6	33%
⚠️ 降级（参考线索）	4	22%
❌ 丢弃（综述/无数据）	8	44%

✅ 保留条目（高工程价值）

条目 1 — vLLM 比 Ollama 快 16 倍的背后：架构差异与六大优化策略

来源: 必学必会 (bixuebihui.com) — 技术博客
URL: https://bixuebihui.com/content/pRQRWL34oM8OP92cjxImPQ
发布日期: 2026（推断）
类型: 工程实践 / 性能对比 / 命令配置
可信度: 高 — 含具体 benchmark 数字、命令和配置参数

核心内容摘要

性能数据（关键保留）：

并发用户	Ollama (tok/s)	vLLM (tok/s)	vLLM 优势
1	62	71	1.1×
10	98	485	4.9×
50	155	2,205	5.9×
100	142（退化）	1,640	11.5×
128	失败	1,890	—

Blackwell B200 单卡 50 用户场景：vLLM 达到 2,960 tok/s，是 Ollama 的 16.6 倍。

根因分析（架构层面）：

Ollama: Go HTTP server + llama.cpp，FIFO 顺序队列，KV Cache 静态预分配（按 num_ctx 固定大小），无论实际序列长度均预留完整空间，造成 60-80% 显存浪费
vLLM: PagedAttention，以页（block）为单位动态分配 KV Cache（block_size=16 默认），消除碎片；连续批处理（Continuous Batching）同时处理多请求，无需等待最长序列

六大优化命令（原文引用）：

# 策略一：KV Cache 优化
--gpu_memory_utilization=0.92    # 92% 显存用于 KV cache
--block_size=16
--enable_prefix_caching=True     # 缓存公共 prompt 前缀

# 策略四：多 GPU 张量并行
vllm serve meta-llama/Llama-3.1-70B-Instruct --tensor-parallel-size 4

# 策略六：投机解码
vllm serve meta-llama/Llama-3.1-70B-Instruct \
  --speculative-model meta-llama/Llama-3.1-8B-Instruct \
  --num-speculative-tokens 5

成本分析：
每日 50,000 请求：GPT-4o API 月费约 $7,500；vLLM + A100 服务器月费 <$1,600，降低 78%。盈亏平衡点 = 每小时 150-200 请求。

版本信息：
Ollama v0.17.7（Apple Silicon M4 Ultra 70B 模型达 85 tok/s）；vLLM v0.17.0（FlashAttention-4 吞吐量提升 30.8%）。

保留理由

✅ 真实性能数字（并发 1→128 分层对比）
✅ 根因分析深入（PagedAttention 机制 vs FIFO）
✅ 可复现命令和配置参数
✅ 成本量化（回本周期）
✅ 版本号明确
⚠️ 来源非顶级学术/大厂博客，但数据与 GitHub benchmark 吻合

后续行动

精读：可对比 SGLang Long Context Issue #3471 的实测数据
来源核验：查看 vLLM 官方博客 2026 年的 benchmark 帖子

条目 2 — vLLM vs TensorRT-LLM vs Ray Serve: The Stack, Not the Showdown

来源: Ali Darbehani (alidarbehani.com)
URL: https://alidarbehani.com/2026/06/23/vllm-vs-tensorrt-llm-vs-ray-serve-a-stack-not-a-showdown
发布日期: 2026-06-23
类型: 工程架构 / 深度技术分析
可信度: 高 — 作者背景清晰，引用了 SOSP/OSDI 学术论文，有原创图表

核心内容摘要

核心论点（重要框架认知）：
三种工具处于不同层次，直接对比是错误框架：

Layer 1 (Engine):     vLLM / TensorRT-LLM  ← 拥有 GPU，决定 KV Cache 布局
Layer 2 (Orchestration): Ray Serve          ← 从不跑 forward pass，只负责横向扩展

TensorRT-LLM 2026 现状（重要更新）：
"TensorRT-LLM 1.0（2025-09-24 发布）将 PyTorch 原生后端改为默认，trtllm-serve 不再强制编译步骤"——这是大多数过时比较文章的盲点。

vLLM V1 引擎重写（关键工程细节）：
2025 年完成的重写解决了"GPU 快但 Python 调度慢"的问题： - EngineCore 隔离进程通过 ZeroMQ 与 API Server 通信，CPU/GPU 工作并行化 - 统一调度器取消硬性 prefill/decode 分离，改为 per-request token budget - 删除了 KV-cache CPU swapping（paging 使 preemption 足够便宜）

关键技术概念解释（适合工程知识库）：

概念	解释
Prefill vs Decode	Prefill = 处理整个 prompt（计算密集）；Decode = 逐 token 生成（带宽密集）
Chunked Prefill (SARATHI)	长 prompt 分块，与 decode 交织，避免巨型 prefill 导致 p95 延迟尖刺
Continuous Batching	每步重新调度，而非等最慢请求完成（OSDI 2022 Orca 论文）
PagedAttention	类 OS 虚拟内存的分页机制，block_size=16，copy-on-write 共享公共前缀

保留理由

✅ 层次化认知框架（engine vs orchestrator 分离）——对工程选型有根本价值
✅ TensorRT-LLM 2026 现状澄清（纠正过时信息）
✅ 引用了真实学术论文（SOSP 2023 PagedAttention，OSDI 2022 Orca）
✅ vLLM V1 内部机制细节
✅ 原创图表和类比（"引擎 vs 调度"）
⚠️ 来自个人技术博客，非公司官方，但分析深度和引用质量高

后续行动

引用来源：可直接引用 PagedAttention 论文 (arXiv) 交叉验证 KV Cache 数据
建议收录至"LLM 推理架构"主题页

条目 3 — vLLM Benchmark Suite (GitHub)

来源: notaDestroyer/vllm-benchmark-suite
URL: https://github.com/notaDestroyer/vllm-benchmark-suite
发布日期: 持续更新（2026）
类型: 开源工具 / Benchmark 框架
可信度: 高 — 开源可审计，含 roofline 分析、统计严谨性

核心内容摘要

工具能力：

pip install vllm-benchmark-suite 后 vllm-bench --quick 即可对运行中服务器做完整性能画像
同时支持 vLLM 和 SGLang 后端（--backend auto 自动检测）
模型感知：自动检测 MoE vs Dense、KV Cache 头数，计算 VRAM 占用

核心命令：

# 快速基准
vllm-bench --quick

# 标准跑分 + 统计误差
vllm-bench --standard --iterations 5 --seed 42

# 瓶颈扫描（经验性找到 B* 临界 batch size）
vllm-bench --bottleneck-sweep

# 量化对比
vllm-bench --compare-quants fp8.json awq.json gptq.json

# vLLM vs SGLang A/B 对比
vllm-bench --standard --vs http://other-server:8000

关键指标（roofline 分析）：

指标	含义	适用场景
MBU (Model Bandwidth Utilization)	decode 阶段 HBM 带宽利用率	低 MBU + 高 batch → overhead/调度瓶颈
MFU (Model FLOPs Utilization)	prefill 阶段计算利用率	±15% 误差，参考值非精确值
B* (Critical batch size)	从带宽密集转计算密集的临界点	指导 batch size 调参
Bottleneck classes	memory-bandwidth / compute / overhead 三选一	决定调优方向

统计严谨性： BCa bootstrap 置信区间、Welch's t-test、Cohen's d effect size、Holm-Bonferroni 多重比较校正

保留理由

✅ 开源可复现，Benchmark 方法论严谨
✅ 解决了"如何科学测量推理引擎性能"这一工程难题
✅ 支持 vLLM/SGLang 双引擎对比
✅ 提供质量测量（perplexity/KL-divergence）与性能分离
✅ 含 copy-paste Markdown 导出，适合直接写报告

后续行动

精读：clone 仓库看 --bottleneck-sweep 的实现逻辑
可在"K8s 上的 LLM 推理服务"主题页引用此工具作为推荐 benchmark 方案

条目 4 — Speculative Decoding: Theory and Implementation in vLLM

来源: Vizuara (Substack)
URL: https://vizuara.substack.com/p/speculative-decoding-theory-and-implementation
发布日期: 2026
类型: 深度技术解析 / 源码分析
可信度: 高 — 理论与实践结合，含代码仓库链接

核心内容摘要

核心洞见（关键理论）：
生成慢的根因不是计算难，而是 内存带宽瓶颈：每生成一个 token 需从 HBM 读取完整模型权重（70B ≈ 140 GB/次），而算力单元大部分时间空等。"生成是内存密集型，不是计算密集型"——这是投机解码成立的前提。

投机解码机制：

小模型（Mq）快速猜 K 个 token（耗时 ≈ 4×T_fast）
大模型（Mp）一次并行验证整批（耗时 ≈ T_slow）
接受直到第一次不匹配；即使全错也保证至少 1 个正确 token（永不退化）

接受率公式（α）的经济含义：
α = 平均接受 token 数 / K
加速比 ≈ (K+1) / (1 + K·(T_fast/T_slow)·(1-α))
当 T_fast << T_slow 且 α 较高时，2-3× 加速

vLLM 支持的投机解码方法：

方法	显存开销	适用场景	备注
N-gram lookup	零额外 VRAM	重复性、输入相关任务	无训练
Medusa	单模型自包含	通用	训练一个额外的猜测头
EAGLE / EAGLE3	中等	最高接受率	draft head 预测特征而非 token，接受率最高

重要经验规则：
"小模型 + 快 GPU"是投机解码的困难场景：8B 模型单流已达 45 tok/s，draft head 自身的前向传播吃掉了大部分收益。
EAGLE 类方法接受率高的原因：draft head 预测的是目标模型的内部特征而非原始 token。

保留理由

✅ 根因分析透彻（内存带宽瓶颈假说）
✅ 提供了量化分析框架（α、加速比公式）
✅ vLLM 实际支持的方法对比表格
✅ 揭示了投机解码失效的场景（重要工程经验）
✅ 引用了 GitHub 代码仓库（可复现）

后续行动

可交叉验证：arxiv:2607.08690v1 "Training-free Relaxed Speculative Decoding" 近期论文
建议收录至"LLM 推理优化"主题页

条目 5 — SGLang 项目动态与 Benchmark 数据

来源: GitHub sgl-project/sglang
URL: https://github.com/sgl-project/sglang
发布日期: 2026（持续更新）
类型: 开源项目 / 推理引擎
可信度: 高 — 官方 GitHub，含具体 benchmark 数据和 blog 链接

核心内容摘要

近期重要更新（2026）：

日期	更新内容	关键数据
2026-04	DeepSeek-V4 Day-0 支持 + Verified RL with SGLang + Miles	blog 链接
2026-02	GB300 NVL72 上 25× 推理性能提升	25× throughput on NVIDIA GB300
2025-12	Day-0 支持 MiMo-V2-Flash, Nemotron 3 Nano, Mistral Large 3, LLaDA 2.0	多种新模型
2025-10	SGLang-Jax 后端发布（支持 TPU）	TPU 原生支持
2025-09	GB200 NVL72 PD 部署：Prefill 3.8× / Decode 4.8×	96×H100

SGLang vs vLLM Long Context 对比数据（GitHub Issue #3471）：

Issue 内含实测对比： - vLLM (chunked prefill disabled): Request throughput 0.78 req/s，Mean TTFT 4,081 ms，P99 TTFT 7,798 ms - vLLM (chunked prefill enabled): Request throughput 0.68 req/s，Mean TTFT 13,002 ms（长序列场景更差）

SGLang 的竞争优势：

稀疏注意力优化（DeepSeek-V3.2 with Sparse Attention）
Disaggregated Prefill/Decode (PD) 支持
Expert Parallelism (EP) for MoE models
SGLang-Jax：TPU 原生推理后端

保留理由

✅ 官方 benchmark 数据（可溯源到 blog）
✅ GB300 NVL72 最新硬件场景数据（2026 年前沿）
✅ Issue 内含真实失败案例（vLLM chunked prefill 在长上下文的退化）
✅ SGLang-Jax TPU 支持信息（多硬件生态）

后续行动

精读：SGLang blog on GB300 对应文章
可在"分布式推理 / 专家并行"主题页引用

条目 6 — SGLang Long Context: sglang vs vLLm (GitHub Issue #3471)

来源: GitHub sgl-project/sglang Issues
URL: https://github.com/sgl-project/sglang/issues/3471
发布日期: 2026
类型: 工程实测 / 故障对比
可信度: 高 — GitHub Issue，含真实 benchmark 命令输出和数字

核心内容摘要

Issue 内容摘要：
用户在 2×H100、8B Llama3、TP=2 环境下做 vLLM vs SGLang 对比，发现 vLLM v0.6.2 在长序列场景下性能退化，并附上了完整的 benchmark 输出。

vLLM 两次测试对比（长上下文场景）：

测试条件：8B llama3，2×H100，TP=2，128 并发请求，1M input tokens

配置	吞吐 (req/s)	Mean TTFT (ms)	P99 TTFT (ms)	Decode tok/s
vLLM (default)	0.78	4,081	7,798	390
vLLM (chunked prefill, 2k)	0.68	13,002	27,605	338

用户原话： "vllm had a massive throughput speed up made in v0.6.2 over its v0.5 — which is probably why the benchmark on your site needs a refresher."

保留理由

✅ 真实 GitHub Issue，非受控测试环境
✅ 完整 benchmark 数字可复制
✅ 揭示了 vLLM 版本迭代带来的性能变化
✅ 与条目 5 的 SGLang 官方数据相互印证

后续行动

关注该 Issue 的后续回复（可能有 maintainer 回应）
适合作为"SGLang vs vLLM 选型"决策参考

⚠️ 降级条目（参考线索）

条目 7 — AI Engineer Roadmap 2026 (dataskew.io)

URL: https://dataskew.io/roadmaps/ai-engineering
降级理由: 路线图型综述，无具体命令/数字；适合作为新人导航，不适合工程知识库收录

条目 8 — LLM Evaluation in 2026 (Medium/nairmilind3)

URL: https://medium.com/@nairmilind3/llm-evaluation-in-2026-e631a78c67dc
降级理由: Benchmark 排名综述，HLE 45% / Claude Opus 4.6 34.4% 等数字有新闻价值，但无工程细节；可作行业动态参考

条目 9 — RAG Evaluation Metrics (Flotorch.ai)

URL: https://www.flotorch.ai/blogs/rag-evaluation-metrics
降级理由: 评估指标框架性文章，含 LLM-as-a-Judge 方法介绍，但缺少命令和可复现步骤；作为 RAG 评估方法论的入门参考

条目 10 — Jam with AI Substack (生产 AI/ML 系统路线图)

URL: https://jamwithai.substack.com/p/the-2026-roadmap-production-aiml
降级理由: 社区型周刊介绍，定位偏学习路线，非工程实践；保留为潜在定期追踪源

❌ 丢弃条目

#	标题	丢弃理由
1	KDnuggets: LLM Engineer Roadmap 2026	路线图，无工程数据
2	Addy Osmani: My LLM coding workflow	个人工作流，非系统架构
3	Reddit: How to become LLM Engineer 2026	讨论帖，无原创技术内容
4	BoringBot: Agentic RAG Day 4	系列教程，无新内容
5	AI Mastery: Evaluating Agentic RAG	课程推广，评估方法论但无命令
6	Gradient Flow: RAG Reimagined	行业综述，无可复现步骤
7	SuperAnnotate: RAG Evaluation Guide	工具对比，无硬数字
8	CSDN: vLLM vs Ollama vs TensorRT-LLM 私有化部署	CSDN 筛选：仅有框架概述，缺少具体命令、版本号或 benchmark 数据；标题与内容深度不符

分类标签

LLM推理引擎 vLLM Ollama SGLang TensorRT-LLM PagedAttention 投机解码 Benchmark RayServe MLOps

建议写入路径

/shared/research-kb/inbox/jay/2026-07-11-llm-inference-engineering.md

后续行动建议

优先级	行动	关联条目
高	精读 SGLang GB300 NVL72 blog（25× 性能数据源）	条目 5
高	验证 vLLM v0.17.0 FlashAttention-4 30.8% 提升（官方 changelog）	条目 1
中	克隆 vllm-benchmark-suite 并在本地 GPU 运行 `--bottleneck-sweep`	条目 3
中	交叉验证 TensorRT-LLM 1.0 PyTorch 原生后端（官方 release notes 2025-09）	条目 2
中	追踪 GitHub Issue #3471 后续（SGLang vs vLLM 长上下文维护者回应）	条目 6
低	建立"LLM 推理引擎选型决策树"主题页，整合条目 1-6	全局

本草稿由 Jay 实例筛选，写入时间 2026-07-11 14:50 CST

工程筛选草稿 · 2026-07-11

筛选概览

✅ 保留条目（高工程价值）

条目 1 — vLLM 比 Ollama 快 16 倍的背后：架构差异与六大优化策略

核心内容摘要

保留理由

后续行动

条目 2 — vLLM vs TensorRT-LLM vs Ray Serve: The Stack, Not the Showdown

核心内容摘要

保留理由

后续行动

条目 3 — vLLM Benchmark Suite (GitHub)

核心内容摘要

保留理由

后续行动

条目 4 — Speculative Decoding: Theory and Implementation in vLLM

核心内容摘要

保留理由

后续行动

条目 5 — SGLang 项目动态与 Benchmark 数据

核心内容摘要

保留理由

后续行动

条目 6 — SGLang Long Context: sglang vs vLLm (GitHub Issue #3471)

核心内容摘要

保留理由

后续行动

⚠️ 降级条目（参考线索）

条目 7 — AI Engineer Roadmap 2026 (dataskew.io)

条目 8 — LLM Evaluation in 2026 (Medium/nairmilind3)

条目 9 — RAG Evaluation Metrics (Flotorch.ai)

条目 10 — Jam with AI Substack (生产 AI/ML 系统路线图)

❌ 丢弃条目

分类标签

建议写入路径

后续行动建议

相关 · 按语义匹配