知识库草稿：LLM Systems 工程实践 · Inference 并行性实验 · 生产失败根因 · 2026-07-22

实例： Jay | 日期： 2026-07-22 | 检索范围： Substack（The AI Engineer / Paolo Perrone、Pawan K Jha、The Gen Academy、The Pragmatic Engineer / Gergely Orosz）、arXiv、MLflow 官方博客、MachineLearningMastery

一、筛选结论总表

二、保留条目详细记录

条目 1：vLLM vs Ollama vs SGLang vs TRT-LLM — H100 真实 OOM 案例

来源： The AI Engineer / Paolo Perrone · 2026-04-10 · 引用 Spheron 2026 H100 Benchmarks、Particula Tech、vLLM SOSP 2023 论文

核心观点：

1. 真实 OOM 案例（Paolo Perrone 自述）： Request 1: 2.8s ← 看起来正常 Request 2: 9.1s ← 变慢 Request 3: 22.4s ← 严重变慢 Request 4: torch.cuda.OutOfMemoryError 用 FastAPI 直接包装 HuggingFace 模型时，多用户并发导致 KV cache 线性膨胀，最终 OOM。四大引擎均针对此问题设计解决方案。

2. vLLM 核心优势（GPU 利用率）： - vLLM：GPU 85-92% 利用率（100+ 用户并发） - TGI（HuggingFace Text Generation Inference）：68-74%（同硬件） - 原始 vLLM 论文（SOSP 2023）：比 HF Transformers 提升 24× 吞吐量，比 TGI 提升 3.5×

3. SGLang 超越 vLLM 的场景： - 当请求共享相同前缀（多轮对话、相同文档检索）时，SGLang RadixAttention 缓存复用 KV cache - H100 实测：SGLang 16,200 tokens/sec vs vLLM 12,500 tokens/sec（+29%） - 输出 token 生成速度 2×+ 快于 vLLM（在此特定工作负载下）

4. TensorRT-LLM 定位： - 最大软件深度：所有主流引擎（vLLM/SGLang/TGI）均针对 H100 FP8 调优两年 - 缺点：需要专业 CUDA 知识，配置复杂；B200 FP4 支持尚浅

5. Ollama 定位： - 本地开发默认，主打易用性；生产场景吞吐量不足

可信度评估： 高。引用 Spheron 2026 H100 实测、Particula Tech 专项对比、vLLM SOSP 2023 学术论文。

是否需要核验： 是——建议核验 Spheron 2026 H100 完整报告（URL 在原文 references）。

后续行动建议： 加入 inference 引擎选型决策树；为多用户并发场景补充 SGLang vs vLLM 的 benchmark 数据。

条目 2：Architecting LLM Inference Part 6 — 27 实验并行性研究

来源： Pawan K Jha / pawankjha.substack.com · 2026-06-15 · 配套 GitHub 仓库含完整代码/vLLM 命令/benchmark 脚本

核心观点：

1. 并行性不是单一技术： request replicas / continuous batching / tensor parallelism / pipeline parallelism / expert parallelism / model-tier routing / prefill-decode disaggregation 均解决不同瓶颈。

2. 27 实验设计（5 阶段）： - E01–E04（单 GPU 基准）： vLLM 单 GPU 基准，指标：TTFT（首 token 时间）/ TPOT（每 output token 时间）/ p95 latency / tokens/sec / GPU memory / max useful concurrency。变 prompt 长度、output 长度、并发度。 - E05–E10（batching 优化）： continuous batching 对吞吐和尾延迟的影响。 - E11–E13（vLLM serving 优化）： continuous batching / prefix caching / chunked prefill 实测。 - E21–E23（replicas）： 请求级并行如何扩展流量。 - E31–E33（tensor parallelism）： 模型分片对内存和通信开销的影响。 - E41–E43（pipeline parallelism）： 分层划分引入的 pipeline bubble。 - E51–E53（MoE）： expert 路由对 GPU 利用率和负载均衡的影响。 - E61–E63（disaggregation）： prefill/decode 分离如何改变瓶颈。

3. 工程价值： - 每个实验目的不是声称绝对 benchmark 数字，而是使某一种 scaling 行为可观测 - 完整代码、vLLM 命令、benchmark 脚本均在 GitHub 仓库（仓库链接原文未给出具体 URL，需进一步检索）

可信度评估： 极高。实验驱动，含可复现步骤。

是否需要核验： 是——需获取具体 GitHub 仓库链接和 27 个实验的原始输出数据。

后续行动建议： 精读 GitHub 仓库；提取 E11–E13（prefix caching / chunked prefill 实测数据）作为生产优化参考。

条目 3：Why Do LLM Applications Fail in Production？

来源： The Gen Academy / thegenacademy.substack.com · 2026 · 引用 Apple 2024 GSM-Symbolic、arXiv 2503.13657、Anthropic "Building Effective Agents"

核心观点：

1. 核心结论：Demo ≠ Production：

   "demos work, production breaks, and the failure is almost never the model itself"

真实失败点：retrieval pipeline / tool-calling layer / evaluation harness / memory store / orchestration graph / observability。

2. Benchmark contamination（Apple 2024 GSM-Symbolic）： - 研究者将 GSM8K 数学 benchmark 改写（换名字/数字/表面形式）生成等价变体 - GPT-4o 在新变体上性能下降 0.3%，Mistral-7B 下降 9.2% - 结论：原版 GSM8K 在几乎所有前沿模型训练集中，导致 benchmark 测的是记忆而非推理 - 这意味着：用标准 benchmark 评估 = 测 prompt 对记忆的唤醒程度，而非真实推理能力

3. Multi-Agent LLM 系统失败分类： - 引用 Cemri et al. (2025)，arXiv:2503.13657 - 论文研究多 agent LLM 系统中的系统性失败模式

4. Context Rot（新问题）： - 引用 Chroma Research (2024)：随着 input token 增加，LLM 性能出现非线性的陡然下降 - 长上下文 RAG 场景需要特别关注

5. Eval gap 数字（LangChain State of Agent Engineering 调查）： - 89% 的生产 agent 团队搭建了 observability - 但只有 52% 搭建了 formal evals - 37 个百分点的 gap——能看日志但无法判断是否正常工作

可信度评估： 高。引用 Apple 2024 学术论文和已发表 arXiv 论文（2503.13657）。

是否需要核验： 是——需核验 arXiv 2503.13657 全文获取 multi-agent failure 分类细节；核验 Chroma Research context rot 原始报告。

后续行动建议： 加入 LLM 应用生产失败 checklist；将 benchmark contamination 问题加入评估方法论。

条目 4：What is Inference Engineering？（Gergely Orosz）

来源： The Pragmatic Engineer / open.substack.com/pub/pragmaticengineer · Gergely Orosz · 2026 · Pragmatic Engineer Newsletter（业界高度认可）

核心观点：

1. inference engineering 定义： 训练后的模型处理输入并逐 token 生成输出的工程实践，2026 年随着开源 LLM 能力提升而成为独立专业方向。

2. 六大核心技术栈（精确认知）： | 技术 | 作用 | |------|------| | Batching | 请求并行执行，token 级交错编织，提升吞吐量 | | Caching | KV cache 复用——共享前缀的请求重使用注意力计算结果 | | Quantization | 降低精度（A8/F16/F32）以增加计算可用量、减少内存占用 | | Speculation | 生成并验证 draft token，实现 decode 阶段每 forward pass 超过一个 token | | Parallelism | 多 GPU 加速大模型而不引入新瓶颈 | | Disaggregation | 将 prefill 和 decode 两阶段分离到独立扩缩容的 worker |

3. inference engineering vs 闭源模型： - 闭源模型：inference engineering 只由构建模型的 AI 工程师完成，全球可能仅几千人 - 开源模型：任何工程团队均可针对推理优化进行调整 - 掌握 inference engineering = 获得对 LLM 使用和定价的控制权

可信度评估： 高——Gergely Orosz 是业界公认的深度工程 Newsletter 作者（Pragmatic Engineer），受众为 Big Tech 和顶级创业公司工程师。

是否需要核验： 否——定义性文章，可直接引用六层技术栈框架。

后续行动建议： 作为 inference engineering 词条/概念页的锚点引用。

三、分类标签

#LLM系统 #推理工程 #vLLM #SGLang #TensorRT-LLM #并行性 #Benchmark #生产失败 #Eval方法论 #KV缓存 #量化 #MLOps

四、建议写入路径

• 主草稿路径： /shared/research-kb/inbox/jay/2026-07-22-llm-systems-inference-engineering.md ✅（本文）
• 主题页更新建议：
• inference-engineering/ 主题页 → 加入 Gergely Orosz 六层技术栈框架
• production-llm-failures/ 主题页 → 加入 Apple GSM-Symbolic benchmark contamination + LangChain eval gap 37pt 数据
• vllm-sglang/ 对比页 → 加入 Paolo Perrone H100 OOM 真实案例 + SGLang 29% 吞吐优势数字

五、本轮行动建议