LLM 推理框架工程横评：vLLM vs SGLang 生产落地指南

收录时间：2026-08-11
主题：LLM Inference Framework Production Benchmark
标签：#LLM-Serving #vLLM #SGLang #PagedAttention #RadixAttention #Continuous-Batching #Inference-Optimization
实例：Jay
可信度：高（CSDN 工程实测 + Substack 行业分析 + arXiv 学术验证）
是否需精读：是，建议优先审稿

一、核心结论（工程选型速查）

实测关键数字（RTX 4090, Qwen2.5-7B）： - vLLM 吞吐量峰值：1512 tokens/s（并发 128） - SGLang 吞吐量峰值：1856 tokens/s（并发 256），领先 24.6% - SGLang 在并发 64+ 开始全面超越 vLLM，差距随并发扩大

二、核心技术原理对比

2.1 PagedAttention（vLLM）

• 灵感来源：操作系统虚拟内存分页
• 机制：KV Cache 按固定大小 block（类似 16 tokens/page）按需分配
• 效果：显存碎片率从 38% 降至 <5%，显存利用率达 ~95%
• 论文：Kwon et al., Efficient Memory Management for LLM Serving with PagedAttention, SOSP 2023
• 开源：https://github.com/vllm-project/vllm

2.2 RadixAttention（SGLang）

• 灵感来源：基数树（Radix Tree）+ LRU Cache
• 机制：所有请求的 KV Cache 保留在基数树中，自动检测共享前缀并复用
• 前缀复用率：Few-shot 85-95%，多轮对话 75-90%，Agent 工具调用 75-95%
• 额外优化：Compressed FSM（有限状态机压缩）加速结构化输出
• 论文：Zheng et al., Efficiently Programming LLMs using SGLang, arXiv:2312.07104

2.3 Continuous Batching（两者均实现）

• 传统 Batching：等最长请求完成才处理下一批，GPU 利用率低
• Continuous Batching：请求完成立即释放资源，新请求动态插入
• 效果：吞吐提升 5-25x

三、生产环境关键参数配置

3.1 vLLM 推荐配置（CUDA 12.4, PyTorch 2.5.1）

pip install "vllm==0.6.6.post1" "transformers>=4.43,<4.46"

python -m vllm.entrypoints.openai.api_server \
  --model Qwen/Qwen2.5-7B-Instruct \
  --dtype bfloat16 \
  --max-model-len 8192 \
  --gpu-memory-utilization 0.90 \
  --max-num-seqs 256 \
  --enable-prefix-caching \
  --enable-chunked-prefill  # 延迟敏感业务可关闭

注意：vLLM 0.8.x 有 flashinfer 兼容问题；0.21.x 需要 CUDA 13.0

3.2 SGLang 推荐配置

python -m sglang.launch_server \
  --model-path Qwen/Qwen2.5-7B-Instruct \
  --dtype bfloat16 \
  --context-length 8192 \
  --mem-fraction-static 0.85 \
  --max-running-requests 256 \
  --enable-prefix-caching \
  --attention-backend flashinfer \
  --schedule-policy lpm \
  --port 30000

注意：SGLang 各版本与 PyTorch 2.5.1 有 ABI 不兼容问题，建议固定版本

3.3 PD 分离（Prefill-Decode Disaggregation）关键规则

• 必须对称：prefill TP = decode TP（如 4+4, 2+2, 1+1）
• 非对称配比（如 4+2）吞吐腰斩至骨折，根因是跨 TP KV 重分片走 PCIe
• PD 解码 TPOT 比单服务低约一半（~12ms vs ~22ms），长尾 P99 稳 2-3 倍

四、2026 年版本生态现状

来源：The AI Engineer (substack.com), 2026-04-11

五、Substack 高价值原文线索

5.1 Host Overhead：隐藏的瓶颈

• 作者：Paolo Perrone (@paoloap)
• 平台：substack.com
• 发布时间：2026-07-23
• 链接：https://substack.com/@paoloap/note/c-300476550
• 核心洞察：大多数工程师把延迟归咎于显存带宽，但真正的瓶颈是 CPU host overhead——Python 在 GPU 等待下一条指令时阻塞了它。SGLang 延迟低于 vLLM 的根本原因不是内核更快，而是 Python 在关键路径上更少。
• 判断：值得核验，需要 benchmark 数据支撑

5.2 vLLM vs SGLang Benchmark 结果几乎相同

• 作者：Paolo Perrone
• 平台：substack.com / The AI Engineer
• 发布时间：2026-04-11
• 链接：https://theaiengineer.substack.com/p/vllm-vs-ollama-vs-sglang-vs-tensorrt
• 核心洞察：在 dozens of workloads 上开箱即用时两者 QPS 几乎相同；vLLM 新模型支持更快，SGLang 冷启动快 5x
• 判断：高可信，行业广泛引用

5.3 TTS 推理 profiling（H100 SXM）

• 作者：Ram (ramshankar07)
• 平台：substack.com
• 发布时间：2026-04-21
• 链接：https://ramshankar07.substack.com/p/blandai-rejected-me-so-i-profiled
• 核心洞察：SGLang 吞吐在 64 并发下达 2.24 req/s，vLLM 在 8 并发时已 plateau；3/4 的 CUDA API 时间消耗在 stream 同步调用——即 host overhead
• 判断：高质量 profiling 案例，方法论值得参考

5.4 Prefix Caching for Builders

• 作者：Prahitha Movva
• 平台：substack.com (The Nuanced Perspective)
• 发布时间：2026-07-11
• 链接：https://thenuancedperspective.substack.com/p/prefix-caching-for-builders
• 核心洞察：2026 年最高效的 Agent 团队不仅选更好的模型，还以选模型的同样严谨度对待 text layer 优化
• 判断：有见地，值得引用

六、学术前沿（arXiv 2025-2026）

6.1 Feather: RL-based Prefix-Aware Scheduler

• 标题：Requests of a Feather Must Flock Together: Batch Size vs. Prefix Homogeneity in LLM Inference
• arXiv：2605.06046
• 核心贡献：提出 Feather 调度器，用 Chunked Hash Tree (CHT) 替代 radix tree 遍历，用 RL 学习最优 batch size vs prefix homogeneity 权衡
• 结果：集成到 vLLM 和 SGLang，end-to-end throughput 提升 2-10x
• 可信度：高，有 formal 分析 + 实验验证
• 是否需核验：是，建议验证 RL 调度器在生产环境的稳定性

6.2 k-LPM: TTFT 约束下的 RadixAttention 调度

• 标题：LLM Query Scheduling with Prefix Reuse and Latency Constraints
• arXiv：2502.04677
• 核心贡献：证明 RadixAttention + TTFT 约束下调度问题为 NP-Hard，提出 k-LPM 算法，k=2 时 P99 TTFT 显著优于 FCFS 和 LPM
• 可信度：高，有理论证明 + 实验验证
• 是否需核验：可参考，k=2 超参数需结合实际 workload 验证

6.3 PersistentKV: Page-Aware Decode Scheduling

• 标题：PersistentKV: Page-Aware Decode Scheduling for Long-Context LLM Serving on Commodity GPUs
• arXiv：2606.26666
• 核心贡献：研究 native paged decode attention 与 serving scheduler 之间的接口；在低活跃长上下文场景，workqueue 调度减少 launch fan-out 从 16.00 到 2.00，wall throughput 提升 1.063-1.265x
• 可信度：高，方法论可复现
• 是否需核验：是，建议关注与 vLLM/SGLang 集成方式

七、CSDN 高价值工程文章（严格筛选）

✅ 收录：CSDN - vLLM 与 SGLang 推理框架性能横评

• 作者：成就一亿技术人!
• 来源：https://hankcorner.blog.csdn.net/article/details/163280072
• 发布日期：2026-07-28
• 工程价值：★★★★★（完整可复现的十大维度评测，含 RTX 4090 + A100 实测数据、崩溃边界测试、命令与参数）
• 版本信息：Python 3.10.14, PyTorch 2.4.0+cu124, vLLM 0.6.3.post1, SGLang 0.4.0
• 核心结论：SGLang 在中高并发（8+）开始超越 vLLM，峰值领先 24.6%；vLLM 在 128 并发后吞吐量反而下降
• 复现可行性：高，含完整测试命令和参数对齐表

✅ 收录：CSDN - 生产级 LLM Serving 系统搭建全过程记录

• 作者：成就一亿技术人!
• 来源：https://blog.csdn.net/qq_45998729/article/details/161225805
• 发布日期：2026-05-19
• 工程价值：★★★★★（从零搭建生产级系统的完整踩坑记录，含 PD 分离、量化、压测）
• 版本信息：Ubuntu 22.04, 4x RTX 4090, CUDA 12.4, vLLM 0.6.6.post1
• 踩坑记录：SGLang 0.5.x 需 PyTorch 2.11.0（CUDA 13.0）；SGLang 0.4.4 deep_gemm ABI 不兼容；vLLM 0.8.x flashinfer 问题
• 复现可行性：高，含完整安装命令和环境配置

✅ 收录：CSDN - 长输入短输出 SGLang PD 分离实测

• 作者：成就一亿技术人!
• 来源：https://blog.csdn.net/qq_63106808/article/details/161839778
• 发布日期：2026-06-09
• 工程价值：★★★★★（PD 配比全景测试，9 种配比全跑，含 SGLang 0.5.12 + 8×RTX 5090）
• 核心发现：非对称 PD 吞吐腰斩；CUDA graph 关闭慢 5 倍；chunked-prefill-size 调 8192 最优（+13-15%）
• 复现可行性：高，含完整参数消融表和配置模板

✅ 收录：CSDN - 生产级推理框架横评（vLLM, SGLang 等 5 大方案）

• 来源：https://devpress.csdn.net/amd/6a3e0f4510ee7a33f282c014.html
• 工程价值：★★★★☆（实战横评，含 chunked-prefill 踩坑、Docker NCCL 问题、混合部署建议）
• 建议：可作为生产选型参考，含决策树和 5 条避坑清单

✅ 收录：CSDN - Qwen3 单卡 4090 部署三框架对比

• 来源：https://gitcode.csdn.net/6a0fedcd662f9a54cb764f4d.html
• 工程价值：★★★★☆（单卡消费级显卡视角，vLLM/SGLang/Ollama 同条件对比，含 OOM 诊断）
• 复现可行性：高，环境描述清晰，测试方法论严谨

八、监控关键指标（生产必读）

vLLM 关键监控指标

SGLang 关键监控指标

九、后续行动建议

立即可做

• [ ] 验证本文收录的 CSDN 文章命令在目标硬件上的可复现性（RTX 4090 单卡 / A100 8 卡）
• [ ] 对比 vLLM 0.6.6.post1 和最新 vLLM 0.8.x 的 flashinfer 兼容问题是否已修复
• [ ] 验证 k-LPM (k=2) 在实际生产 workload 上的 P99 TTFT 改善

值得深入

• [ ] Feather 调度器（arXiv 2605.06046）集成到 vLLM 的可行性研究
• [ ] PersistentKV 的 workqueue 调度与 SGLang 的融合可能性
• [ ] KVzap（KV cache pruning）尚未在 vLLM/SGLang 实现，关注跟进

知识库更新

• [ ] 建议在知识库中建立 vLLM / SGLang 各自适用场景的决策树
• [ ] 建议为 PD 分离配置添加"必须对称 TP"的警示条目
• [ ] 建议增加"TGI 已进入维护模式"的状态更新条目

十、参考链接汇总

Substack 原文

1. https://substack.com/@paoloap/note/c-259514505 — vLLM vs SGLang benchmark note
2. https://theaiengineer.substack.com/p/vllm-vs-ollama-vs-sglang-vs-tensorrt — The AI Engineer 完整横评
3. https://scalablethoughts.substack.com/p/the-wall-you-hit-after-you-ship-inference — 生产推理优化
4. https://substack.com/@paoloap/note/c-300476550 — Host overhead note
5. https://gradientupdate.substack.com/p/llm-inference-metrics-reference — TTFT/TPOT/TPS 指标详解
6. https://ramshankar07.substack.com/p/blandai-rejected-me-so-i-profiled — H100 TTS profiling
7. https://thenuancedperspective.substack.com/p/prefix-caching-for-builders — Prefix Caching 建设者指南
8. https://kaitchup.substack.com/p/mmlu-pro-has-an-answer-leak-and-its — vLLM KV Cache Offloading + KVzap

CSDN 原文

1. https://hankcorner.blog.csdn.net/article/details/163280072 — vLLM vs SGLang 十大维度横评
2. https://blog.csdn.net/qq_45998729/article/details/161225805 — 生产级 LLM Serving 搭建全记录
3. https://blog.csdn.net/qq_63106808/article/details/161839778 — SGLang PD 分离实测
4. https://devpress.csdn.net/amd/6a3e0f4510ee7a33f282c014.html — 五大框架横评
5. https://gitcode.csdn.net/6a0fedcd662f9a54cb764f4d.html — 4090 单卡三框架对比
6. https://blog.csdn.net/weixin_42624889/article/details/159818883 — TTFT/ITL 评测方法

arXiv 论文

1. Kwon et al., Efficient Memory Management for LLM Serving with PagedAttention, SOSP 2023 — https://arxiv.org/abs/2309.06180
2. Zheng et al., Efficiently Programming LLMs using SGLang, arXiv:2312.07104
3. Requests of a Feather Must Flock Together, arXiv:2605.06046
4. LLM Query Scheduling with Prefix Reuse and Latency Constraints, arXiv:2502.04677
5. PersistentKV: Page-Aware Decode Scheduling, arXiv:2606.26666

本条目由 Jay 自动生成于 2026-08-11，仅作为研究线索和技术洞察来源，不复制原文内容。