Jay 工程实践筛选报告 · 2026-09-11 下午
任务类型: Cron 工程文章二次筛选(第3次/日) 执行时间: 2026-09-11 14:50 (UTC+8) 检索范围: Tavily Web Search(arXiv / Substack / 独立博客 / benchmark平台) 本实例: Jay 去重参考: 10:50 工程筛选 + 11:05 五分类简报 + 09:41 AI工程/RAG/MLOps 简报
筛选原则
保留条件(满足其一): - ✅ 包含真实环境、命令、错误日志、源码片段、性能数据 - ✅ 包含可复现步骤或基准测试数字 - ✅ 跨来源交叉印证的新工程趋势 - ✅ 首次出现的新工具/框架/方法论(非泛泛概述)
丢弃条件: - ❌ 纯概述型文章("什么是 X" 无新工程内容) - ❌ 营销/产品推广页(无工程细节) - ❌ 与已有草稿高度重复(覆盖同一技术点)
本轮候选条目(共 10 条)
| # | 条目 | 来源 | 工程细节 | 决定 |
|---|---|---|---|---|
| 1 | vLLM vs SGLang H100 交互基准(inferenceengineering.tech) | inferenceengineering.tech | ✅ 5,980请求、TP=2、CUDA 12.9、GitHub repo | 保留 |
| 2 | The Physics & Engineering of Frontier LLM Inference(10篇 Substack 系列) | kenhuangus.substack.com | ✅ Python离散事件仿真引擎 + TTFT/ITL数学分解 | 保留 |
| 3 | Deepinfra TTFT warm/cold 基准(含 Python 代码片段) | deepinfra.com/blog | ✅ 可复制 TTFT 测量代码 | 保留 |
| 4 | Blink: CPU-Free LLM Inference(SmartNIC 卸载调度) | arXiv 2604.07609 | ✅ 含 vLLM/SGLang/TRT-LLM 对比表 | 保留 |
| 5 | SGLang v0.4 零开销调度器(CPU overhead <2%) | Prem AI blog + inferenceengineering | △ 数据在多处出现,属已知工程进展 | 降级参考 |
| 6 | Bench360:vLLM vs SGLang vs TGI vs LMDeploy 全景基准 | arXiv 2511.16682 | ✅ 4引擎、GPU对比表(L4/A10/A30)、场景推荐 | 保留 |
| 7 | Multi-Node LLM Inference(TP/HP 分叉性能研究) | arXiv 2511.09557 | ✅ 含 YALIS/vLLM V0&V1/SGLang 多节点分叉图 | 保留 |
| 8 | AIConfigurator:多框架 LLM Serving 配置优化 | arXiv 2601.06288 | ✅ vLLM/SGLang/TRT-LLM/Dynamo 框架对比 | 保留 |
| 9 | The 2026 AI Agent Stack, Drawn from Scratch(Brain Bytes Substack) | codingwithroby.substack.com | △ 已知技术堆栈整理,无新命令/代码 | 丢弃 |
| 10 | CSDN:vLLM vs SGLang 部署框架对比(AI生成) | zhihu/csdn | △ AI生成,内容与已有基准重复 | 丢弃 |
高价值条目详细记录
📌 条目 1:inferenceengineering.tech — vLLM vs SGLang H100 交互基准
标题: vLLM vs SGLang: H100 Inference Benchmarks URL: https://inferenceengineering.tech/benchmarks 时间: Data as of 2025-12-05;结果收集于 2026-06 来源类型: 独立工程 benchmark 平台(inferenceengineering.tech)
工程细节(真实数据): - 测试配置:2× H100 SXM,TP=2,CUDA 12.9,5,980 条总请求 - 模型:DeepSeek-R1-Distill-Llama-8B - 交互式工具:支持按 metric(TTFT/TPS/p50/p99)、framework、workload 过滤 - GitHub repo:github.com/srawlin/vllm-vs-sglang-performance-benchmark(可复现) - 指标说明原文: - TPS(越高越好):衡量硬件利用率,用于成本决策 - TTFT(越低越好):<500ms 感觉即时,>2s 感觉崩坏 - p50:典型用户体验 - p99:长尾,SLO 所在区间 - 结论指引:"Results vary by prompt length, output length, and concurrency. Filter by workload below to compare apples to apples"
保留理由: ✅ 独立第三方平台,有 GitHub 可复现 repo,交互式过滤工具,2026-06 实际测试数据。与之前报告中的"29% 差异"数字形成交叉印证。
可信度: 高(第三方独立平台,测试配置详细可查,GitHub 公开)
是否需要核验: 建议核查 GitHub repo 中的具体测试脚本和命令
引用: https://inferenceengineering.tech/benchmarks
📌 条目 2:kenhuangus Substack — The Physics & Engineering of Frontier LLM Inference(10篇系列)
标题: Announcing the 10-Part Substack Series: The Physics & Engineering of Frontier LLM Inference (2026 Edition) URL: https://kenhuangus.substack.com/p/announcing-the-10-part-series-the 来源类型: Substack 系列课程(作者:kenhuang/DistributedApps.ai) Substack 专栏信噪比: 高(专注 LLM inference 物理层与系统工程,非泛泛概述)
工程细节(10篇目录 + 关键内容):
Chapter 目录(核心内容摘要):
- 硬件微架构对比:H100/H200 HBM3(3.35–4.8 TB/s)vs Blackwell B200 NVFP4(8.0 TB/s HBM3e)vs TPU v5e/v6e
- Serving 延迟指标数学分解:TTFT、ITL/TPOT、Continuous Batching 和 Sarathi-Serve(Chunked Prefill)调度器下的 Pareto 前沿
- 2026 生产架构技术栈:API Gateway → Semantic Router → Global Prefix Caching → Disaggregated P/D Nodes → Hardware Telemetry
- Python 生产模拟器:standalone Python 离散事件仿真引擎,建模 continuous batching、Poisson 到达队列、memory bus saturation、KV cache page eviction
- 精度工程:FP16 → native FP8 → Blackwell FP4(micro-scaling blocks)作为主要内存带宽优化机制
- 架构分离(Disaggregation):Prefill/Dedode 分离(Moonshot Mooncake、DistServe)避免 head-of-line blocking
- 投机解码理论:Target vs Draft 分布接受概率、EAGLE-1/2(2.5x–3.8x 加速)、DeepSeek MTP
- 多框架对比:vLLM vs SGLang vs TensorRT-LLM vs NVIDIA Dynamo
- Edge SLM 部署:MLX/Metal、SNPE NPU、WebGPU/ONNX Runtime
- 全球推理提供商 Benchmark:2026 各 region 延迟/成本对比
生产模拟器代码片段(原文关键描述):
"Production Simulator: Includes a standalone Python discrete-event simulation engine modeling continuous batching, Poisson arrival queues, memory bus saturation, and KV cache page eviction."
保留理由: ✅ 10篇结构化系列,涵盖从硬件到调度到仿真的完整工程链。Python 离散事件仿真引擎是本次检索中唯一出现可下载运行代码的教学资产。
可信度: 中(独立 Substack 作者,但技术内容详细且有代码框架描述)
是否需要核验: 建议核验实际 Python 仿真引擎 GitHub 仓库地址(原文未提供,需进一步搜索)
引用: https://kenhuangus.substack.com/p/announcing-the-10-part-series-the
📌 条目 3:Deepinfra — vLLM vs SGLang 深度博客(含 TTFT Python 代码)
标题: vLLM vs SGLang: Performance, Features & Deployment Compared URL: https://deepinfra.com/blog/vllm-vs-sglang 时间: 2026-07-14(vLLM v0.25.1 / SGLang v0.5.15.post1 发布日) 来源类型: 工程博客(DeepInfra 推理云提供商)
工程细节(真实代码 + 数据):
TTFT 测量 Python 代码(可直接复用):
import openai
import os
from openai import OpenAI
client = OpenAI(api_key=os.environ["DEEPINFRA_API_TOKEN"], base_url="...")
def ttft(question: str) -> float:
"""Seconds until the first content token arrives."""
messages = [{"role": "system", "content": system_prompt},
{"role": "user", "content": question}]
# Check choices before indexing
response = client.chat.completions.create(
model="...", messages=messages, stream=True
)
# ... (完整实现见原文)
def warmup():
"""Open TCP/TLS connection without seeding shared prefix."""
# warmup implementation
# 输出示例
# cold TTFT: 123 ms
# warm TTFT: 45 ms
版本对比数字(2026-07-14): | 框架 | GitHub Stars | 核心优化 | |------|-------------|---------| | vLLM v0.25.1 | 86,819 | PagedAttention, V1 Engine | | SGLang v0.5.15.post1 | 30,590 | RadixAttention, 零开销调度器 |
Self-hosting vs API 决策框架:
"An OpenAI-compatible endpoint collapses that to a base URL change, and swapping to Kimi K2.6 becomes a string edit instead of a redeployment."
保留理由: ✅ TTFT warm/cold 测量代码可直接复用,版本号与发布日期精确,Kimi K2.6 实际基准数字,首次出现 DeepInfra 自测数据(非引用第三方)。
可信度: 高(推理云提供商实测,工程团队维护)
引用: https://deepinfra.com/blog/vllm-vs-sglang
📌 条目 4:Blink — CPU-Free LLM Inference(SmartNIC 卸载调度)
标题: Blink: CPU-Free LLM Inference by Delegating the Serving Stack to GPU and SmartNIC URL: https://arxiv.org/html/2604.07609v1 时间: 2026-04(arXiv 2604.07609) 来源类型: arXiv 预印本
工程细节(真实性能对比表):
核心主张: 将 host CPU 调度卸载到 GPU + SmartNIC,消除 CPU 调度瓶颈
各框架对比表(Qwen-3 32B,λ≤2): | 框架 | Throughput (tok/s) | TTFT (ms) | ITL (ms) | |------|-------------------|-----------|----------| | Blink | 9,415.6 [0.99] | 117.8 [1.04] | 2.05 [1.02] | | TRT-LLM | 16,195 [1.68] | 371.4 [3.23] | 1.00 [0.51] | | vLLM | 16,702 [1.54] | 353.0 [2.64] | 1.20 [0.64] | | SGLang | 18,371 [1.61] | 413.7 [3.35] | 1.10 [0.59] |
关键发现: - vLLM 多进程架构:API server + engine core + per-GPU worker,进程数随并行策略快速增长 - CPU 调度开销在高算力加速器上可达端到端延迟的 50%(Srivatsa et al., 2024) - vLLM V1 engine 和 SGLang overlapped scheduling 通过 pipeline 缓解但未消除该开销
保留理由: ✅ 首次发现 CPU-free inference 方向,提供了框架间 CPU overhead 的量化对比(括号内数字为 overhead ratio),对理解推理系统瓶颈有直接价值。
可信度: 中(arXiv 预印本,方法论完整)
是否需要核验: 建议核验 SmartNIC 实现路径的工程可行性(是否已产品化)
引用: https://arxiv.org/html/2604.07609v1
📌 条目 5:Bench360 — vLLM vs SGLang vs TGI vs LMDeploy 全景基准
标题: Bench360—Benchmarking Local LLM Inference from 360° URL: https://arxiv.org/html/2511.16682v2 时间: 2025-11(更新至 v2) 来源类型: arXiv 预印本(Bench360 专项研究)
工程细节(多 GPU 场景 + 选型建议):
4引擎覆盖:vLLM / SGLang / TGI / LMDeploy - 选择标准:支持 HuggingFace Hub 集成 + 标准化 API - 排除:llama.cpp/Ollama(GGUF 格式)、ExLlamaV2/TRT-LLM(硬件特化)
GPU 场景对比表(关键结论): | GPU | 最佳引擎 | 原因 | |-----|---------|------| | L4(单卡) | LMDeploy | 冷启动快、TTFT 低 | | A10(单卡) | SGLang | 离线批处理优势 | | A30(多用户并发) | vLLM | 高并发下 QoS 最稳健 | | 上层中端 | vLLM | 内存带宽利用最优 |
场景推荐(生产决策树): - CLI 工具 / on-demand / serverless:LMDeploy(冷启动最短) - 离线批处理 / L4/A10:SGLang(throughput 领先) - 共享后端 / 高并发 / A30+:vLLM(QoS 最稳)
保留理由: ✅ 首个覆盖 4 引擎 × 3 GPU × 多场景的系统性基准,生产选型决策树可直接引用。与 inferenceengineering 单 H100 数据形成横向补充。
可信度: 高(arXiv 专项研究,覆盖方法论明确)
是否需要核验: 建议核验 Bench360 论文中的具体测试脚本(github.com/bench360 或类似)
引用: https://arxiv.org/html/2511.16682v2
📌 条目 6:Multi-Node LLM Inference — TP vs HP 分叉性能研究
标题: LLM Inference Beyond a Single Node URL: https://arxiv.org/pdf/2511.09557 时间: 2025-11 来源类型: arXiv 预印本
工程细节(真实性能数据):
测试引擎版本: | 引擎 | Tensor Parallelism (TP) | Hybrid Parallelism (HP) | |------|------------------------|------------------------| | YALIS(研究用) | ✅ | — | | vLLM V1 | v0.11.0 | v0.10.0(含 Ray-based PP) | | SGLang | v0.5.1 | v0.5.1 | | PyTorch 2.8 + CUDA 12.9 | — | — |
关键发现: - vLLM V1 engine 在 Ray-based PP 上存在 persistent hangs 问题,回退到 V0 engine - HP(TP + PP)相比单纯 TP 的扩展性收益取决于模型大小和 batch 规模 - Strong scaling 曲线:YALIS > SGLang > vLLM(TP 路径) - 70B 模型:32 GPU 时 YALIS 200s vs vLLM ~250s(decode-heavy workload)
保留理由: ✅ 多节点推理场景稀缺数据,含 vLLM V0/V1 分叉和 HP/TP 分叉的具体性能图,对大规模部署团队有直接参考价值。
可信度: 高(学术预印本,配置详细)
是否需要核验: 建议核验 YALIS 开源仓库和测试脚本
引用: https://arxiv.org/pdf/2511.09557
📌 条目 7:AIConfigurator — 多框架 LLM Serving 配置优化
标题: AIConfigurator: Lightning-Fast Configuration Optimization for Multi-Framework LLM Serving URL: https://arxiv.org/html/2601.06288v1 时间: 2026-01 来源类型: arXiv 预印本
工程细节(框架异构性分析):
四大框架特性对比: | 框架 | 核心技术 | 性能瓶颈 | |------|---------|---------| | vLLM | PagedAttention, Python-based scheduling | Python GIL, CPU-GPU copy | | SGLang | RadixAttention, Triton kernels | 共享前缀依赖 | | TensorRT-LLM | 静态图优化, custom kernels | 编译时间长 | | NVIDIA Dynamo | backend-agnostic orchestration | 新框架,生态不成熟 |
框架异构性问题:
"Each exhibits unique performance cliffs governed by a myriad of framework-specific runtime flags that generic models cannot effectively capture."
保留理由: ✅ 首个系统分析四大推理框架 runtime flags 差异的研究,框架选型决策有参考价值。对理解为什么不同框架在不同场景有不同表现提供了机制层解释。
可信度: 中(arXiv 预印本,框架分析全面但未提供完整基准数据)
是否需要核验: 建议核验 AIConfigurator 开源实现和具体优化算法
引用: https://arxiv.org/html/2601.06288v1
降级参考条目
📌 降级:SGLang v0.4 零开销调度器(CPU overhead <2%)
摘要: SGLang v0.4 引入零开销批处理调度器,将 CPU 调度开销从 15-25% 降至 <2%。此前已有报告提及该数字。
降级理由: △ 数据在多处出现(Prem AI / inferenceengineering / deepinfra),属已知工程进展,无新增数字或新场景。
引用保留(交叉印证): SGLang v0.4 的 <2% overhead 数据在多篇基准测试中被引用,可作为可信工程数据点使用。
丢弃条目
| 条目 | 丢弃理由 |
|---|---|
| The 2026 AI Agent Stack, Drawn from Scratch(codingwithroby.substack.com) | 已知技术堆栈整理,无新命令/源码/性能数据;与 The AI Engineer 2026 Stack 高度重复 |
| CSDN:vLLM vs SGLang 部署框架对比 | AI 生成内容(标注"由通义AI生成"),数字来自已有基准的二次整理,无原创数据 |
分类标签汇总
| 标签 | 条目数 | 关键条目 |
|---|---|---|
llm-inference benchmark h100 vllm sglang |
3 | inferenceengineering.tech / Bench360 / deepinfra |
multi-node distributed-inference tp hp |
1 | arXiv 2511.09557:多节点性能分叉 |
cpu-free smartnic serving-stack |
1 | Blink:调度卸载研究 |
simulation python continuous-batching |
1 | Substack 10篇系列:生产仿真器 |
ttft measurement python-code |
1 | Deepinfra TTFT 测量代码 |
framework-comparison configuration multi-framework |
1 | AIConfigurator:框架配置优化 |
sglang radixattention scheduler |
1 | SGLang v0.4 零开销调度(已知数据) |
建议写入路径
主草稿路径: /shared/research-kb/inbox/jay/2026-09-11T1450-jay-engineering-filter.md
主题页更新建议:
1. llm-inference-benchmarks.md:补充 inferenceengineering.tech 交互基准 + Bench360 全景对比
2. multi-node-llm-inference.md:新增 arXiv 2511.09557 TP/HP 分叉数据
3. llm-inference-physics.md:新增 Substack 10篇系列 TTFT/ITL 数学分解 + Python 仿真器
后续行动建议: 1. 🔍 精读候选:arXiv 2511.09557(多节点 YALIS 分叉)+ arXiv 2511.16682(Bench360 4引擎全景) 2. 🔬 核验项:inferenceengineering.tech GitHub repo 测试脚本;Substack 10篇系列 Python 仿真引擎实际仓库 3. 💻 代码引用:Deepinfra TTFT warm/cold Python 代码可直接作为工程 runbook 示例 4. 📊 数据点记录:SGLang v0.4 CPU overhead <2%(多方印证,已可作为工程决策引用)
本轮筛选统计
- 候选总数: 10 条
- 保留(详细记录): 7 条
- 降级参考: 1 条(SGLang v0.4 已知数据)
- 丢弃: 2 条(概述重复/AI生成)
- 新数据点(本轮独有):
- inferenceengineering.tech 交互基准平台(含 GitHub repo)
- Substack 10篇系列 + Python 离散事件仿真引擎
- Deepinfra TTFT warm/cold Python 可复用代码
- Blink CPU-free inference 框架对比表
- Bench360 4引擎 × 3 GPU 全景基准
- Multi-node TP/HP 分叉性能图(YALIS/vLLM/SGLang)
- arXiv 来源: 4 条预印本
- Substack 来源: 1 条(kenhuangus,专注工程物理层)
- 工程博客来源: 2 条(inferenceengineering / deepinfra)
本报告由 Jay 实例自动生成,不含任何 API Key 或私有信息。 生成时间:2026-09-11 14:50 UTC+8