Jay 工程筛选 · 2026-08-19 上午第二轮
筛选主题
本期重点：vLLM vs SGLang 生产选型 · OOM 排障 · H100/H200 Benchmark 成本分析
候选条目（12 条）→ 保留 9 条 / 丢弃 3 条
✅ 保留 1：DevOpsBeast — "vLLM vs SGLang for Production LLM Serving in 2026"
URL： https://devopsbeast.com/blog/vllm-vs-sglang-production-2026
作者： Sharon Sahadevan · 2026
类型： 工程对比 · 决策框架
保留理由： - 核心论点是"benchmark数字不是决策依据，工作负载形态才是"，有实际工程判断逻辑 - 明确给出 RadixAttention 在 60%+ 共享前缀场景下领先 vLLM 2-3x 的具体条件 - 列举了各引擎在实际生产中的操作成熟度差异 - 包含 TTFT/ITL 具体数值范围（chat/RAG/agent 三类场景）
工程价值： - 不是跑分炫技，而是给决策者看的生产选型 check - 覆盖 structured output、multi-tenant 场景对比
可复现性： 高（判断框架清晰，benchmark 数据有硬件上下文）
标签： inference-engineering vLLM SGLang production benchmark
✅ 保留 2：Sector88 — "How to fix vLLM OOM: the complete 2026 checklist"
URL： https://www.sector88.co/blog/how-to-fix-vllm-oom
类型： 排障命令 · 配置手册
保留理由：
- 提供完整 OOM 分类（KV cache overflow / batch size / memory fragmentation）
- 给出三档硬件的具体配置示例：
- 24GB GPU + Llama-3-8B：gpu_memory_utilization=0.85, max_model_len=8192, max_num_seqs=32
- 40GB A100 + Llama-3-70B AWQ 的 agent 场景配置
- 包含"Don't"清单（不要设 1.0、不要混跑 CUDA、不要 keep max_model_len at max）
- 内存分层（VRAM/RAM/NVMe）方案
工程价值： - 实操级 runbook，不是通用建议 - CUDA Graph 捕获期间临时 RAM 耗尽导致 OOM 的具体原因说明
可复现性： 高（具体参数值 + 硬件配置）
标签： vLLM OOM 排障 GPU-memory CUDA runbook
✅ 保留 3：SitePoint — "vLLM Production Deployment: Complete 2026 Guide"
URL： https://www.sitepoint.com/vllm-production-deployment-guide-2026
类型： 部署手册 · Benchmark 命令
保留理由：
- 明确说明 --gpu-memory-utilization 在 0.85-0.95 区间的权衡（并发容量 vs 爆内存风险）
- --enforce-eager flag 的具体效果：disable CUDA graph 节省 5-15% 显存（30B+模型），但牺牲 throughput
- --max-model-len 对 KV cache 内存的直接影响
- 给出 benchmark_serving.py 的实际调用命令和输出解读示例：
Throughput: 842.3 tokens/s
Mean TTFT: 48.2ms | P99 TTFT: 142.7ms
Mean E2E latency: 1.24s | P99 E2E: 3.87s
- Prometheus metrics endpoint 配置
工程价值： - 从 demo 到生产可观测服务的实操桥接 - 参数语义明确，不是泛泛而谈
可复现性： 高
标签： vLLM production deployment benchmark Prometheus CUDA-graph
✅ 保留 4：Particula — "SGLang vs vLLM in 2026: Benchmarks, Architecture, and..."
URL： https://particula.tech/blog/sglang-vs-vllm-inference-engine-comparison
类型： Benchmark 数据 · 架构对比
保留理由： - 实测数据（作者自己的测试，非引用）： - Total throughput: SGLang ~16,200 tok/s vs vLLM ~12,500 tok/s（SGLang +29%） - Output token throughput: SGLang 894 vs vLLM 413（SGLang +117%） - TTFT: SGLang 79ms vs vLLM 103ms（快 23%） - ITL: SGLang 6.0ms vs vLLM 7.1ms（快 15%） - 详细并发梯度数据（1/10/50/100 并发下的 tok/s） - Constrained decoding JSON 合规率：SGLang 96-98.2% vs vLLM 90-94% - FSM compressed structured output 原理说明
工程价值： - 具体 benchmark 数据 + 硬件上下文（H100 Llama-70B FP16/FP8） - JSON 合规率数字对 structured output 应用场景直接有用
可复现性： 中（硬件/模型条件明确，可复测）
标签： SGLang vLLM benchmark structured-output H100 RadixAttention
✅ 保留 5：Spheron — "vLLM vs TensorRT-LLM vs SGLang: H100 Benchmarks"
URL： https://www.spheron.network/blog/vllm-vs-tensorrt-llm-vs-sglang-benchmarks
类型： 成本分析 · GPU 性价比
保留理由： - 硬成本数据（基于 2026-06-24 定价）： - H100 SXM5 SGLang：$0.44/1M tokens（$4.06/hr on-demand） - H100 SXM5 vLLM APC off：$0.61/1M tokens - H200 SXM5 SGLang：$0.51/1M tokens（$5.92/hr on-demand） - H200 SXM5 spot $3.31/hr → SGLang ~$0.29/1M tokens - Blackwell B200 上 FlashAttention 4 的具体说明（v0.17.0+ 在 SM100/SM103） - 列出 SGLang speculative decoding 集成不如 vLLM v0.5.9 成熟的判断 - H200 vs H100 内存带宽数据（4.8TB/s vs 3.35TB/s）
工程价值： - 成本选型的硬数字，不是"哪个更好"的泛论 - spot instance 策略对成本的量级影响
可复现性： 中（定价随市场波动，但框架可复用）
标签： H100 H200 Blackwell cost-analysis SGLang vLLM TensorRT-LLM spot
✅ 保留 6：Paralleliq — "vLLM OOM Errors: Root Cause Diagnosis Guide"
URL： https://www.paralleliq.ai/blog/vllm-oom-errors-root-cause-diagnosis
类型： OOM 分类诊断
保留理由： - 三类 OOM 的 signature 区分： 1. KV cache overflow：OOM during generation, not at startup 2. Batch size misconfig：OOM at startup, flat high memory 3. Memory fragmentation：gradual degradation over time - Continuous batching vs static batching 的内存分配模型对比 - PyTorch CUDA allocator fragmentation 的解释
工程价值： - 不同于 Sector88 的"如何修复"，这是"如何判断哪类问题" - 与 Sector88 形成互补（诊断 + 修复）
可复现性： 高（signature 特征明确）
标签： vLLM OOM diagnosis batch-scheduling CUDA-memory
✅ 保留 7：F22labs — "TRT-LLM vs vLLM vs SGLang: What to Choose in 2026"
URL： https://www.f22labs.com/blogs/trt-llm-vs-vllm-vs-sglang-what-to-choose-in-2026-2
类型： 3 引擎对比 · 工程成本
保留理由： - TRT-LLM 的核心工程成本明确： - 每次模型更新需 rebuild（2-4 周上手期） - engine 文件 GPU 架构耦合（sm_89 ≠ sm_90），跨 GPU 迁移必须 rebuild - INT8/FP8 精度差异说明：TRT-LLM 在 tensor core 实际以量化精度计算，vLLM 的量化只省显存但计算仍解量化到 FP16 - Qwen2.5-1.5B on RTX 4090 的实测数据 - GPTQ/AWQ/GGUF/FP8/INT8/INT4 各量化格式支持矩阵
工程价值： - TRT-LLM 选型决策必读，避免低估迁移成本 - 量化精度工程细节（很多文章混淆的点）
可复现性： 中
标签： TensorRT-LLM vLLM SGLang quantization precision production
✅ 保留 8：Deploybase — "Best LLM Inference Engines 2026"
URL： https://deploybase.ai/articles/best-llm-inference-engine
类型： 部署命令 · 基准方法论
保留理由：
- 给出具体部署命令：
bash
pip install vllm
python -m vllm.entrypoints.openai.api_server \
--model meta-llama/Llama-2-70b-hf \
--tensor-parallel-size 2 \
--dtype float16 \
--gpu-memory-utilization 0.90 \
--port 8000
- SGLang 部署命令同样具体
- 基准方法论说明：batch size 1/8/32、context 512 tokens、output 128 tokens、10 runs
- 成本优化：night batch 利用 spot 差价（$0.003 → $0.0015/token，年省 $54,750 案例）
工程价值： - 命令可复制，方法论可复用 - 成本核算框架
可复现性： 高
标签： vLLM SGLang deployment benchmark tensor-parallel cost-optimization
✅ 保留 9：AI multiple — "LLM Inference Engines: vLLM vs LMDeploy vs SGLang"
URL： https://aimultiple.com/inference-engines
类型： Benchmark 数据
保留理由： - 自测数据（H100 + Llama 3.1 8B-Instruct + 1000 ShareGPT prompts）： - SGLang: 16,215 tok/s - LMDeploy: 16,132 tok/s（几乎相同） - vLLM（FlashInfer优化）: 基准 - 两者都 saturate H100 内存带宽，差距在统计噪声内 - 0.8 GPU utilization 是"安全区"的工程经验值 - 实用性结论：LMDeploy 胜出（99.5% SGLang 性能，pip install lmdeploy 即可，无需复杂依赖）
工程价值： - 实测数据，驳斥了"SGLang 全面领先"的说法 - 安装便捷性也是工程选型维度
可复现性： 高（方法透明：H100 + Llama 3.1 8B + 1000 prompts）
标签： SGLang LMDeploy vLLM H100 benchmark FlashInfer
丢弃条目
❌ 丢弃 1：Codezilla — "How to Optimize LLM Costs in Production (2026 Guide)"
URL： https://codezilla.io/blog/how-to-optimize-llm-costs-in-production-2026-guide
丢弃理由：
- Semantic caching 声称"90% hit rate，cost reduction 80%"——无来源、无硬件上下文
- 31% enterprise LLM queries are semantically comparable——无研究引用
- 多处具体数字缺乏来源锚点，可信度低
- 属于通用成本优化概述，非工程深度
❌ 丢弃 2：MLflow — "Setting Up LLM Observability Pipelines in 2026"
URL： https://mlflow.org/articles/setting-up-llm-observability-pipelines-in-2026
丢弃理由：
- 采样率建议（prod 10-30%）是常见经验值，无新意
- 框架层面说明，无具体 instrument 代码示例
- 更多是 MLflow 产品推广，不是中立工程指南
- 与之前收录的 Helicone/Langfuse/Arize Phoenix 内容高度重叠
❌ 丢弃 3：The AI Engineer (Substack) — "vLLM vs Ollama vs SGLang vs TensorRT-LLM"
URL： https://theaiengineer.substack.com/p/vllm-vs-ollama-vs-sglang-vs-tensorrt
丢弃理由：
- 订阅墙，核心内容不可见
- 可见摘要无新工程数据（引用了 DevOpsBeast、Particula、Spheron 的数字）
- 结论"Ollama is essential for proving an idea on a laptop, replace it when you move to cloud"——已是行业共识
- 实质是对已发表文章的摘要整理，不是一手工程内容
汇总
| 类别 | 数量 |
|---|---|
| 保留 | 9 |
| 丢弃 | 3 |
| 理由重复（已收录） | 0 |
高质量内容共性特征： - 给出具体硬件型号 + 具体模型 + 具体配置参数值 - 有可复现的 benchmark 方法论（batch size、context length、n runs） - OOM 文章有三类区分（诊断signature + 修复步骤 + 不要清单） - 成本分析有 on-demand/spot 分层
本轮无 Substack 高价值一手内容（theaiengineer.substack.com 被订阅墙阻挡，pawan k jha 系列偏理论架构，designgurus 订阅墙）。
建议写入路径： /shared/research-kb/inbox/jay/2026-08-19T1050-jay-engineering-filter.md
精读建议： - 必读（直接可执行）： Sector88 OOM checklist + Paralleliq OOM diagnosis（互补配对） - 选读（决策参考）： Spheron H100 cost analysis + F22labs TRT-LLM 工程成本 - 验证复测： Particula benchmark 数据（自测数据，可复验）
主题标签： inference-engineering vLLM SGLang TensorRT-LLM OOM benchmark H100 cost-analysis production
下一步行动： 1. Sector88 + Paralleliq 可合并为"vLLM OOM 完整排障手册"入库 2. F22labs TRT-LLM rebuild 成本数据值得在知识库标记为"常见低估项"