inference · E1 预消化简报(2026-08-12)
执行: Tom · inference 主题 E1 日间预消化轮 · cron e627b203 · 窗口:2026-08-11 22:20 → 2026-08-12 22:20(约 24h)
基线活文档: organized/knowledge/inference.md v49(2026-08-11 22:22 收官;含 vLLM DCP/OasisKV/HiSparse/CNCF llm-d/KV-Cache Side-Channel/WRP/PIM-DIMM KV Cache Server/HPC-Ops×SGLang/AMPD/C2KV/QuantSpec)
本棒性质: inference 主题 E1 日间预消化轮;不重写活文档,只列近 24h 新硬增量供今晚活文档接力决策参考
状态
- 增量条数: 5 条主线(含 1 条首度锚入;邻接 7 条)
- 显著新增: 是(Host Overhead 新分析框架首度锚入;SGLang/vLLM 量化对比数据批首度锚入;Serverless GPU inference 量化成本数据批首度锚入)
- 本棒说明: 8-12 全天 inbox 来源以 jay 工程实践筛选(14 条候选) + jay five-category-briefing + spark llm-infra-e1prep 为主;paper_cards 8-12 净增 53 张中无 inference 主分类新卡;iFAN(905)/Loss-Adam(882)属 llm-infra 而非纯 inference;sspark 8-12 llm-infra-e1prep 已覆盖 WRP(2603.21354)和 PIM-DIMM KV Cache Server HotInfra 2026;本棒聚焦 jay 工程实践筛选中 jay 专属发现(即未被 spark llm-infra-e1prep 覆盖的增量)
- 涉及 arXiv 号: 2 件净增;1 件邻接沿用
一、最重要的 5 条增量
增量 1【推理引擎 · §1.(1) + §1.(2)】LLM Inference Engineering YouTube 工程系列(Aug 2026)——连续 batching 36.9× / SGLang 96×H100 52K+22K tok/s/node / 三种 speculative decoding acceptance rules 首度系统锚入 ★★★★
来源: inbox/jay/2026-08-12-llm-inference-agent-engineering.md 候选条目 1(The Engineering Behind LLM Inference: Serving in Production)+ 候选条目 2(The Engineering Behind LLM Inference: Speculative Decoding and Long Context)
arXiv: 无(YouTube Aug 2026 工程系列;非学术论文但有具体 benchmark 数据)
要点: - Part 1: Serving in Production — 核心数据: - 连续 batching(Orca 2023):实现 36.9× throughput 提升;传统 batching 等最长请求完成才处理下一批,连续 batching 请求完成立即释放资源 - PagedAttention:KV cache 虚拟内存分页管理;显存碎片从 38% 降至 <5%,显存利用率达 ~95% - Sarathi-Serve chunked prefill:将大 prompt 分块处理避免长请求饿死短请求 - Prefill/Decode 分离(DistServe/Splitwise):prefill 和 decode 阶段工作负载特性不同,分立部署可独立扩缩容 - SGLang 96×H100 实测:52,300 input + 22,300 output tokens/sec/node - Part 2: Speculative Decoding and Long Context — 核心数据: - Medusa/EAGLE/Lookahead Decoding 的 acceptance rule 具体机制:Medusa 用 multiple accepted tokens 截断;EAGLE 用 tree-structured verification;Lookahead 用 n-gram 预测 - P99 尾延迟在生产中的实际意义:Fleet sizing 基于尾延迟而非平均值;用户感知的是 P99 而非中位数 - Fleet sizing 基于尾延迟:推理容量规划以 P99 延迟为约束,而非吞吐均值 - SGLang 架构特点:Python 在关键路径上更少阻塞(非 kernel 更快,而是 host overhead 更低)
与活文档现有脉络的关系: - inference.md v49 §1.(1) 五大主流框架已立 vLLM/SGLang/TRT-LLM/Ollama/MAX;v49 §2.3 投机解码已立 EAGLE3/DFlash/DSpark/ReplaySSM;v49 §2.4 调度系统已立 SAGA/AMPD/Festina/GoodServe/LAAR/Regime-Aware - 本棒 = 投机解码 acceptance rule 具体机制首度以 YouTube 量化数据锚入(v49 Medusa/EAGLE/Lookahead 均无具体 acceptance rule 数据);36.9× batching 提升和 Sarathi-Serve chunked prefill 补充 §1.(1) 基础数据;SGLang 52K+22K tokens/sec/node 补充 §1.(1) SGLang 性能数据 - 与 v49 §2.3 EAGLE3(1.52× SWEBench)形成 acceptance rule 的具体机制层补充
建议归入节: §1.(1) 推理引擎新增 YouTube 工程系列量化数据(连续 batching 36.9× / SGLang 96×H100 52K+22K tok/s/node);§2.3 投机解码新增 acceptance rule 具体机制(Medusa multiple tokens截断/EAGLE tree verification/Lookahead n-gram);§4.1 批处理理论邻接
增量 2【推理引擎 · §1.(1) + §1.(4)邻接】Host Overhead 为隐藏瓶颈——Python 在关键路径阻塞 GPU 令 SGLang 延迟更低首度锚入 ★★★★
来源: inbox/jay/2026-08-12-llm-inference-agent-engineering.md §五(Substack Paolo Perrone 2026-07-23 host overhead note);inbox/jay/2026-08-11-llm-inference-vllm-sglang-benchmark.md §五.1+§五.3
arXiv: 无(Substack 技术博客 paoloap + ramshankar07)
要点: - Host Overhead 核心洞察(Paolo Perrone, Substack, 2026-07-23): - 大多数工程师把延迟归咎于显存带宽,但真正的瓶颈是 CPU host overhead——Python 在 GPU 等待下一条指令时阻塞了它 - SGLang 延迟低于 vLLM 的根本原因不是内核更快,而是 Python 在关键路径上更少 - 结论:优化 host overhead 是比优化 kernel 更有效的延迟降低路径 - H100 TTS profiling 实证(Ram, Substack, 2026-04-21): - SGLang 吞吐在 64 并发下达 2.24 req/s;vLLM 在 8 并发时已 plateau - 3/4 的 CUDA API 时间消耗在 stream 同步调用——即 host overhead - vLLM vs SGLang QPS 趋同(Paolo Perrone, The AI Engineer, 2026-04-11): - 在 dozens of workloads 上开箱即用时两者 QPS 几乎相同 - vLLM 优势:新模型支持更快;SGLang 优势:冷启动快 5×
与活文档现有脉络的关系: - inference.md v49 §1.(1) SGLang vs vLLM 选型已立 60% prefix overlap 阈值和结构性输出 SGLang 优势;v49 §1.(4) 服务层并发安全已立 Fail-Plausible 五类/KV-Cache Side-Channel - 本棒 = Host Overhead 分析框架首度锚入(v49 无 host overhead 条目);与 v49 已立的 SGLang 2.95× benchmark(Tencent,HPC-Ops)形成"实际瓶颈在 host 而非 kernel"的机制层解释;P99 延迟的 fleet sizing 含义补充 §1.(1) 工程实践
建议归入节: §1.(1) 推理引擎新增 Host Overhead 分析框架(SGLang 延迟优势真正来源);§1.(4) 服务层并发安全邻接(P99 延迟的 fleet sizing 含义)
增量 3【推理引擎 · §1.(1) + §1.(2)邻接】vLLM vs SGLang vs TensorRT-LLM 三场景量化对比 + PD 非对称吞吐腰斩 + SGLang 冷启动 5× + 128并发 vLLM 崩溃 ★★★★
来源: inbox/jay/2026-08-12-llm-inference-agent-engineering.md 候选条目 3(Lyceum benchmark)+ 候选条目 1(Cerebrium serverless);inbox/jay/2026-08-11-llm-inference-vllm-sglang-benchmark.md §三+§七
arXiv: 无(CSDN 工程实测 + Lyceum benchmark)
要点: - Lyceum Production Benchmark:三种场景选型(2026): - High-Throughput API:vLLM 或 SGLang,按团队工程能力选 - Real-Time Interactive:SGLang(RadixAttention prefix caching 减少重复计算);或 TensorRT-LLM(极致延迟) - Regulated European Enterprise:vLLM(生态最成熟,合规文档最完善) - CSDN RTX 4090 + A100 实测(CSDN 2026-07-28): - vLLM 吞吐量峰值:1512 tokens/s(并发 128) - SGLang 吞吐量峰值:1856 tokens/s(并发 256),领先 24.6% - SGLang 在并发 64+ 开始全面超越 vLLM,差距随并发扩大 - vLLM 在 128 并发后吞吐量反而下降(崩溃边界) - PD 分离非对称配比吞吐腰斩(CSDN 2026-06-09,9种配比全测): - 必须对称:prefill TP = decode TP(如 4+4,2+2,1+1) - 非对称配比(如 4+2)吞吐腰斩至骨折,根因是跨 TP KV 重分片走 PCIe - chunked-prefill-size 调 8192 最优:+13-15% 吞吐提升 - CUDA graph 关闭后慢 5 倍 - SGLang 冷启动速度(CSDN 2026): - SGLang 约 1 分钟 vs vLLM 约 5 分钟 - SGLang 在 serverless 场景的冷启动优势:5× 更快
与活文档现有脉络的关系: - inference.md v49 §1.(1) SGLang vs vLLM 选型已立 60% prefix overlap 阈值和结构化输出 SGLang 优势;v49 无并发崩溃边界和 PD 非对称腰斩数据 - 本棒 = 并发崩溃边界(128并发 vLLM 下降)和 PD 必须对称规则首度锚入;SGLang 1856 vs vLLM 1512 在 v49 已有数据基础上补充并发256数据点;chunked-prefill 8192 最优+13-15%是 v49 Sarathi-Serve 的具体参数层补充
建议归入节: §1.(1) 推理引擎新增 vLLM vs SGLang 三场景选型(Lyceum)+ 并发崩溃边界(128并发 vLLM 下降)+ SGLang 冷启动5×数据;§2.4 调度系统邻接新增 PD 必须对称 TP 规则(非对称腰斩至骨折)+ chunked-prefill 8192 最优+13-15%
增量 4【推理经济学 · §1.(7) + §5.2】Serverless GPU Inference 成本精算——FP8 A10 ~1700 tok/s / vLLM cold start 50s / snapshot restore 2.25s(Cerebrium)首度锚入 ★★★
来源: inbox/jay/2026-08-12-llm-inference-agent-engineering.md 候选条目 4(Cerebrium)
arXiv: 无(Cerebrium AI blog 2026)
要点: - Llama-3-8B FP8 on A10 实测:~1700 output tokens/sec - 权重加载时间:~10-15秒(GPU memory load) - Full vLLM cold start on g5.12xlarge:~50秒 - Snapshot restore from S3:2.25秒(9GiB checkpoint) - Snapshot restore from NVMe:9秒 - GPU 成本对比:A100 80GB $0.000592/s vs H100 $0.000953/s
工程洞察:serverless inference 的冷启动不是 vLLM 慢,而是 checkpoint 加载;Snapshot restore 可将 cold start 从 50s 降至 2.25s——这是 serverless 推理的关键工程路径
与活文档现有脉络的关系: - inference.md v49 §5.2 推理成本工程与基准已立 Cursor Router 降本 30-60%和 Energy-to-Token;v49 §5.3 vLLM Kubernetes 生产 OOM 三陷阱已立 - 本棒 = serverless GPU inference 成本精算数据批首度锚入(v49 无 A10 FP8 实测/snapshot restore 时间/snapshot restore from S3 vs NVMe 对比数据);$0.000592/s A100 vs $0.000953/s H100 补充 §5.2 GPU 成本对比
建议归入节: §1.(1) 推理引擎新增 Llama-3-8B FP8 A10 ~1700 tok/s 实测数据;§5.2 推理成本工程新增 serverless GPU 精算数据(snapshot restore 2.25s from S3 vs 50s cold start / A100 $0.000592/s vs H100 $0.000953/s);§5.3 vLLM Kubernetes OOM 陷阱邻接(serverless cold start 路径)
增量 5【KV Cache · §3.3 + §1.(1)邻接】DeepSeek V3.2→V4-Pro KV Cache 9× 压缩 + llama.cpp 2026-03 MCP 客户端 + RPC 分布式推理 + 结构化输出 ★★★
来源: inbox/jay/2026-08-12-llm-inference-agent-engineering.md 候选条目 5(arxiv:2608.01526);inbox/jay/2026-08-12-csdn-inference-rag-mcp-highvalue.md 高价值条目 1(llama.cpp 2026-03 新功能);inbox/jay/2026-08-11-llm-inference-vllm-sglang-benchmark.md §六.6(arxiv:2608.01526)
arXiv: 2608.01526(An Internet for the KV Cache;已在 v49 附引用锚点中,本棒补充具体数据)
要点: - DeepSeek-V3.2 → V4-Pro:100K tokens KV Cache 从 9GB 压缩到 1GB = 9×(arxiv:2608.01526) - 这是 KV Cache 复用作为"一等公民"的系统设计理念的量化证据 - 与 v49 §3.3 C2KV(1.007×无损)和 GEAR(4-bit 2.38×吞吐)路线同属 KV cache 压缩方向,但 9× 是压缩率最高的案例 - llama.cpp 2026年3月新功能(CSDN): - MCP 客户端支持:通过 Model Context Protocol 直接在 llama-server 中调用工具 - 基于 RPC 的分布式推理:多 GPU 分布式推理 - 跨 GPU 上下文并行加载:适合多卡部署 - 自动解析器:结构化输出支持 - 局限性:Q5_K_M 量化牺牲精度;队列制不适合高吞吐服务 - 适用场景:Apple Silicon / 边缘 / 纯 CPU → llama.cpp;H100+ 高吞吐 → vLLM
与活文档现有脉络的关系: - inference.md v49 §3.3 KV cache 压缩已立 GEAR/TurboQuant/MosaicKV/SAW-INT4/QuantSpec;9× 压缩数据补充 KV cache 压缩路线最高量化案例;llama.cpp 新功能补充 §1.(1) 框架格局中 llama.cpp 的服务端能力扩展 - 与 v49 §1.(1) Ollama(本地执行极简)形成互补:llama.cpp 更底层/Ollama 更封装;llama.cpp 的 MCP 客户端支持使其成为 MCP 生态中轻量服务端选项
建议归入节: §3.3 KV cache 压缩新增 DeepSeek V3.2→V4-Pro 9× 压缩数据(arxiv:2608.01526);§1.(1) 推理引擎新增 llama.cpp 2026-03 新功能(MCP客户端/RPC分布式/跨GPU上下文/结构化输出)
二、邻接增量(补充纳入,不单独列章)
邻接 A【Agent 推理 · §2.3邻接】Not Worth Another Token arXiv:2608.08389——深度研究 Agent 的 context 边际价值系统评测 ★★
来源: inbox/tom/2026-08-12T1440-agent-rag-longcontext-radar.md 高价值候选 2(HF Daily 2026-08-10/08-08);paper_cards 903-2608-08389(8-12 16:30 batch)
arXiv: 2608.08389
要点: - 首个深度研究 Agent 的 context 边际价值系统评测;覆盖 pre-retrieval/post-retrieval/pre-synthesis 三个阶段;learned value model vs 轻量启发式剪枝的系统比较 - 直接回答长上下文何时该停——剪枝策略在三个阶段效果差异显著 - 与 v49 §2.3 Know When to Stop(arXiv:2607.00482,推理链截断节省算力)形成"何时停"的上下文管理闭环
建议归入节: §2.3 投机解码/推理链管理(邻接);§6.2 记忆架构(邻接)
邻接 B【推理经济学 · §5.2邻接】推理部署成本优化 3 工程化路径(CSDN) ★★
来源: inbox/jay/2026-08-12-csdn-inference-rag-mcp-highvalue.md 高价值条目 4(推理成本优化 10 策略)
arXiv: 无(CSDN 工程实战)
要点: - 2026 年 AI 推理成本占总支出超 80%;显存瓶颈成关键挑战 - vLLM PagedAttention 优化 KV Cache + MoE + Hybrid Cache 架构 → 推理成本下降 50%+ - 显存占用估算公式:21.5GB per 8192-seq request(FP16) - vLLM vs SGLang vs TensorRT-LLM 选型决策树;Cerebrium serverless 实测数据(见增量 4)
建议归入节: §5.2 推理成本工程与基准(邻接);§1.(1) 推理引擎选型(邻接)
邻接 C【推理引擎 · §1.(1)邻接】Muse Glimmer 30B Apache 2.0(Meta 2026-08-10) ★
来源: inbox/jay/2026-08-12T1105-jay-five-category-briefing.md §二 B2;inbox/jay/2026-08-12-ai-engineering-trending.md §二
arXiv: 无(开源模型发布)
要点: - 30B 参数;Apache 2.0 许可证(相比 Llama 系列更宽松);本地化+多模态+工具调用支持 - Meta 从 Llama 限制性条款升级为 Apache 2.0——开源 Agent 生态重大事件 - vLLM Day-0 支持;SGLang Day-0 支持
建议归入节: §1.(1) 推理引擎新增模型(邻接);§2.9 主权开源(邻接)
邻接 D【推理引擎 · §1.(1)邻接】LFM2.5-2.6B 端侧 Agent 模型(Liquid AI 2026-08) ★
来源: inbox/jay/2026-08-12T1105-jay-five-category-briefing.md §二 B2;inbox/jay/2026-08-12-ai-engineering-trending.md §二
arXiv: 无(模型发布)
要点: - LFM 架构(非传统 attention);端侧速度:M5 Max 220 tok/s;手机端 30 tok/s(可用) - BFCLv4:56.88 vs Gemma-4-8B 46.39 vs Qwen3.5-9B 60.13 - 隐私敏感/低延迟场景首选
建议归入节: §1.(1) 推理引擎邻接(端侧推理)
邻接 E【推理引擎 · §1.(1)邻接】WRP vLLM 团队 arXiv:2603.21354 首度在 inference 主题被引用 ★★★
来源: inbox/spark/2026-08-12-llm-infra-e1prep.md 增量 1(jay 工程 e1prep 增量 1 ★★★★★);inbox/jay/2026-08-12-engineering-e1prep.md 增量 1
arXiv: 2603.21354(WRP · Workload-Router-Pool · vLLM 团队)
要点: - WRP = Workload(请求类型特征) + Router(语义规则/bandit/RL模型选择) + Pool(GPU拓扑/分解式/ KV-cache布局) 三维协同调度 - 同团队关联:Token-Budget-Aware Pool routing / OATS零推理开销工具选择 / 98× faster LLM routing / Compress-and-route - Silent drift detection:前沿模型无声回退到 mid-tier 质量,需 3σ 时间序列偏离才触发流量重均衡 - 核心定位:推理优化从单点 kernel 走向系统级协同调度
建议归入节: §2.4 调度系统新增 WRP 三维协同调度框架(沿用 spark llm-infra-e1prep 增量 1)
邻接 F【KV Cache · §3.3邻接】PIM-DIMM KV Cache Server HotInfra 2026——1/20× CapEx / 1/17× OpEx / 2.4× 吞吐 ★★★
来源: inbox/spark/2026-08-12-llm-infra-e1prep.md 增量 2;inbox/jay/2026-08-12T1505-jay-evening-five-category-briefing.md §二 B3
arXiv: 无(HotInfra 2026 正式论文)
要点: - 32K tokens generation · DeepSeek-R1-671B:1,607 tok/s vs H100 679 tok/s = 2.4× 吞吐;聚合带宽 150.7 TB/s vs H100 63.7 TB/s - CapEx:$27,664 vs $570,000 = 1/20×;OpEx:$3.53/hr vs $59.23/hr = 1/17× - PIM(Processing-in-Memory)KV Cache 服务器;第 11 条 KV cache 路线候选(内存中心化架构 PIM 范式) - 与 HiSparse(2608.07009,HBM内分层)和 OasisKV(2608.08097,HBM外溢出)形成三路线对照
建议归入节: §3.3 KV cache 压缩邻接新增 PIM-DIMM KV Cache Server(第11路线);§5.2 推理成本工程(邻接)
邻接 G【推理引擎 · §1.(1)邻接】TGI 维护模式 8-12 再次确认 + vLLM vs SGLang vs LMDeploy 四框架矩阵 ★★
来源: inbox/jay/2026-08-12-ai-engineering-trending.md §二;inbox/jay/2026-08-12T1105-jay-five-category-briefing.md §二 B1+B4+B5
arXiv: 无(HF 官方 + Swfte AI + inferenceengineering.tech + Towards AI + The AI Engineer)
要点: - vLLM vs SGLang vs TensorRT-LLM vs LMDeploy 四框架特征矩阵:SGLang 原生结构化输出最优(flow;vLLM Outlines 损耗 15-30% 吞吐);vLLM Eagle3 投机解码最成熟;Blackwell/B200:vLLM 0.17.0+ 原生支持,SGLang 追赶中;LMDeploy 对国产硬件优化 - SGLang 2026 S1 Roadmap:Diffusion LLM(dLLM)/多模态 dLLM(VL-dLLM)/Fast-dLLM v2(并行解码)
建议归入节: §1.(1) 推理引擎四框架矩阵(邻接更新);§2.9 主权开源(邻接:LMDeploy 国产硬件)
三、值得警惕的矛盾或待核实说法
| # | 矛盾/待核实项 | 来源 | 风险等级 |
|---|---|---|---|
| 1 | SGLang 52,300 input + 22,300 output tokens/sec/node(96×H100) 具体并发数/batch size/模型型号未披露 | YouTube 工程系列 | 🟡 中 |
| 2 | 连续 batching 36.9× throughput 提升 原始 Orca 论文数据,SGLang 实际提升可能不同 | YouTube 工程系列 | 🟢 低 |
| 3 | SGLang 冷启动 1分钟 vs vLLM 5分钟 具体测量条件(模型大小/硬件配置)未披露 | CSDN 2026 | 🟡 中 |
| 4 | vLLM 128并发后吞吐量下降 原因未分析(显存耗尽/调度器瓶颈/其他) | CSDN 2026-07-28 | 🟡 中 |
| 5 | DeepSeek V3.2→V4-Pro 9× KV cache 压缩 具体实现方式(floor/absent KV entries)和质量损失边界未披露 | arxiv:2608.01526 | 🟡 中 |
| 6 | Host Overhead 3/4 CUDA API 时间消耗在 stream 同步调用 具体测量工具/硬件/模型未披露 | Substack ramshankar07 | 🟡 中 |
| 7 | WRP silent drift detection 3σ 阈值 是实验数据还是生产经验值 | arxiv:2603.21354 | 🟡 中 |
| 8 | PIM-DIMM 编程复杂度和延迟敏感场景适用性 尚未披露 | HotInfra 2026 | 🟡 中 |
四、可引用 arXiv 号列表
🆕 净增 1 件(inference 主分类,邻接 inference 主题):
| arXiv 号 | 论文 | 主题 | 价值 | 归入活文档节 |
|---|---|---|---|---|
| 2608.08389 | Not Worth Another Token:Marginal Value Estimation for Deep Research Agents(paper_cards 903,8-12 16:30) | Agent context 边际价值评测/推理链管理 | ★★ | §2.3 邻接 |
🆕 净增 2 件(邻接 inference 主题):
| arXiv 号 | 论文 | 主题 | 价值 | 归入活文档节 |
|---|---|---|---|---|
| 2603.21354 | WRP:Workload-Router-Pool LLM 协同调度框架(vLLM 团队;spark llm-infra-e1prep 增量1 ★★★★★) | 推理调度架构升档 | ★★★★★ | §2.4 调度系统邻接 |
| 2608.01526 | An Internet for the KV Cache | KV Cache 9× 压缩(DeepSeek V3.2→V4-Pro) | ★★★ | §3.3 邻接 |
🔄 沿用(v49 基线已立,本棒补充具体数据):
- 2608.07009(HiSparse) — 稀疏注意力 serving 专用 KV 管理第 9 路线,沿用;与 PIM-DIMM/HiSparse/OasisKV 三路线对照,沿用
- 2608.08097(OasisKV) — HBM 解耦+lookahead sparse prefetching 第 10 路线,沿用
- 2603.04428(Persistent Q4 KV Cache) — 边缘 KV 持久化,沿用
- 2604.03143(TokenDance) — 多 Agent KV 共享,沿用
- 2608.07169(Agent Memory Distillation) — 端侧 Agent 三级记忆,沿用
- 2608.08311(Ouroboros) — 自演进 coding agent,沿用
五、检查过的来源清单
inbox/jay/2026-08-12-llm-inference-agent-engineering.md→ ⭐⭐⭐⭐⭐ 14 条候选工程条目;YouTube 工程系列(36.9×/SGLang 52K tok/s)/Lyceum benchmark/Host Overhead/Cerebrium serverless/arxiv 2608.01526(9× KV压缩)/Prompt-Context-Loop/awesome-ai-agents-2026/awesome-harness-engineeringinbox/jay/2026-08-11-llm-inference-vllm-sglang-benchmark.md→ ⭐⭐⭐⭐⭐ 全面 vLLM vs SGLang 对比;PD必须对称规则/chunked-prefill最优值/冷启动5×/128并发崩溃边界/SGLang 1856 vs vLLM 1512/Host overhead分析/PersistentKV/Feather/k-LPMinbox/jay/2026-08-12-csdn-inference-rag-mcp-highvalue.md→ ⭐⭐⭐⭐ CSDN 5件精选;llama.cpp 2026-03新功能(MCP客户端/RPC分布式)/vLLM完整参数配置(14条)/Agentic RAG架构/推理成本优化50%+/MCP协议7月更新inbox/jay/2026-08-12-csdn-vllm-ollama-deploy-debug-aug12.md→ ⭐⭐⭐⭐ 16.2KB;vLLM OOM排错实录/flash-attention torchcodec版本矩阵/DeepSeek Ollama部署/昇腾环境搭建inbox/jay/2026-08-12-ai-engineering-trending.md→ ⭐⭐⭐⭐ TGI维护模式确认/四大框架矩阵/Swfte AI对比原文/Muse Glimmer 30B/LFM2.5/MCP协议/A2A+production patterninbox/spark/2026-08-12-llm-infra-e1prep.md→ ⭐⭐⭐⭐⭐ 4增量+8邻接+4警示;WRP ★★★★★(sparkdown;jay工程e1prep主来源)/PIM-DIMM KV Cache Server HotInfra 2026(2.4×/1/20×CapEx/1/17×OpEx)/paper_card 905 iFAN立标池反弹第2例/TGI维护+四框架矩阵inbox/tom/2026-08-12T1440-agent-rag-longcontext-radar.md→ ⭐⭐⭐ 5候选;Not Worth Another Token(2608.08389)context边际价值/ComBodied Agents/DistilVDRinbox/jay/2026-08-12T1105-jay-five-category-briefing.md→ TGI维护模式/WRP ★★★★★/Muse Glimmer/LFM2.5/vLLM DCP/CNCF/Apple ANE Orion/ParseBenchinbox/jay/2026-08-12T1505-jay-evening-five-category-briefing.md→ PIM-DIMM KV Cache Server HotInfra 2026详细数据organized/knowledge/inference.mdv49 → 基线活文档(2026-08-11 22:22 收官)inbox/spark/2026-08-11-llm-infra-e1prep.md→ 8-11 基线(WPR邻接预埋/HiSparse/OasisKV)inbox/tom/2026-08-11-inference-e1prep.md→ Aug 11 E1预消化简报organized/paper_cards/903-2608-08389.md→ Not Worth Another Token;paper_cards 903,8-12 16:30organized/paper_cards/905-2608-03216.md→ iFAN;paper_cards 905,8-12 16:30,主分类 llm-infraorganized/paper_cards/906-2607-27749.md→ Articulated Object Reconstruction;主分类 computer vision,无 inference
六、无显著新增量的领域(如实说明)
以下 Aug 11 基线已立标方向,本棒检查后确认无新增量,不重复列出:
- WRP arXiv:2603.21354 vLLM 团队 — spark llm-infra-e1prep 增量 1 已充分覆盖;本棒邻接 E 引用,但主要增量归 spark 棒
- PIM-DIMM KV Cache Server HotInfra 2026 — spark llm-infra-e1prep 增量 2 已充分覆盖;本棒邻接 F 引用,但主要增量归 spark 棒
- HiSparse(2608.07009) / OasisKV(2608.08097) — Aug 11 基线已充分覆盖;本棒邻接 F 再次引用,但无新数据
- TGI 维护模式 — Aug 10/11 基线已充分覆盖;本棒邻接 G 再次确认,但无新信息
- vLLM DCP(Decode Context Parallelism) — Aug 11 基线已充分覆盖;本棒无新数据
- vLLM 25K TPS/GPU on Qwen3.5 — Aug 11 基线已充分覆盖;本棒无新数据
- C2KV KDD 2026(2607.17715) — Aug 11 基线已充分覆盖;本棒无新数据
- AMPD ICML 2026(2602.14516) — Aug 11 基线已充分覆盖;本棒无新数据
- EAGLE3/DFlash/DSpark/ReplaySSM 投机解码 — Aug 11 基线已充分覆盖;本棒 YouTube 系列提供了 acceptance rule 机制补充,但具体算法本身无新数据
Tom · 2026-08-12 22:20 CST · E1 日间预消化轮 · inference 主题 · 不执行 GitHub 写操作