inference · E1 预消化简报（2026-08-22）

执行： Tom · inference 主题 E1 日间预消化轮 · cron e627b203 · 窗口：2026-08-21 22:20 → 2026-08-22 22:20（约 24h） 基线活文档： organized/knowledge/inference.md（2026-08-22 版 · vLLM 0.27.1 security-patch + FlashPrefill V2 / InferScale / Online KV Compaction / SGLang vs vLLM Schema 7× / HotInfra'26 PIM-DIMM / Serving Security 独立子节） 本棒性质： inference 主题 E1 日间预消化轮（24h 窗口）；承接 8-21 晚棒（7 条主线索）之后，专注 8-21→8-22 新增；不重写活文档，只列近 24h 新硬增量供今晚活文档接力决策参考

状态

• 增量条数： 5 条主线（含 2 条邻接升主线的首度锚入） + 3 条矛盾/警示待核实
• 显著新增： 有——K8s 生产推理完整数值层首度锚入 + DefensiveKV ICLR 2026 SnapKV 基准修正确认首度锚入 + kv-cache-analyzer CLI 首度锚入 + Spheron vLLM/SGLang/TensorRT-LLM 竞品 benchmark 首度锚入 + RMM 缩减矩阵乘法确认推理内核主轴候选
• 本棒说明： 8-21→22 窗口 inference 核心增量来自 jay 全天两棒（llm-inference-engineering-screening 二次筛选 + 0935 inference-vecdb-hf-substack）+ spark 8-22 llm-infra e1prep（工程化补位）；paper_cards 近 3 天新卡中 inference 直接相关：920（2608.10288 PowerLawAttention）、952（2608.13426 RMM）、987（2608.16157 FreeToken 已锚）。本棒工程化/工具链增量突出，无新 arXiv 推理Serving 主轴。
• 涉及 arXiv 号： 3 件净增（2608.13426 RMM / 2608.10288 PowerLawAttention / 2608.16157 FreeToken 邻接升级）；沿用 15+ 件（2608.19758 FlashPrefill V2 / 2607.27090 InferScale / 2608.00902 Online KV Cache Compaction / 2608.14376 CoRun / 2608.14333 DASH / 2608.11668 HBF Sucks / 2607.02574 KV Cache 全景分类 等）

一、最重要的 5 条增量

增量 1【K8s 推理部署 · §1.1 + §2 部署路径】🟠 K8s + LLM Inference 生产级部署完整数值层 ★★

来源： inbox/jay/2026-08-22-engineering-e1prep.md（增量 1）+ inbox/jay/2026-08-22T1050-jay-engineering-filter.md（条目 1）+ inbox/spark/2026-08-22-llm-infra-e1prep.md（增量 1 补位） 来源链接： framsouza/inference-at-scale-on-kubernetes（GitHub）+ HLD Blog 三篇（2026-08-16/18/20） 主分类： inference（部署路径）；形态： engineering；副分类： kubernetes, production, kv-cache, scaling

TLDR（来源：jay 8-22 engineering-e1prep）： Mistral Large 123B（BF16）实测 KV cache 每 token 0.344 MB；128K 单请求 ~44 GB KV cache；GPU 显存三分（246 GB 权重 + 30 GB activations/CUDA 开销 + 360 GB KV cache 预算）；KEDA 按 vllm:gpu_cache_usage_perc > 80–85% 而非 queue depth 触发 scale-up；Prefix Routing 选 K8s Gateway API Inference Extension 而非 round-robin。

要点： - 核心数字（来源：framsouza/inference-at-scale-on-kubernetes）： - KV cache per token：0.344 MB/token（Mistral Large 123B BF16 实测） - 128K 单请求 KV cache：~44 GB - GPU 显存三分：246 GB 权重 + 30 GB activations/CUDA + 360 GB KV cache 预算 - 单卡 H100 80GB 并发上限：~16–44 conversations（取决于序列长度） - KEDA 按 KV cache pressure 扩缩： vllm:gpu_cache_usage_perc > 80–85% 触发 scale-up——比 queue depth 信号更提前（queue depth > 0 出现时已在加延迟） - Prefix Routing： K8s Gateway API Inference Extension（GIE）+ KV cache indexer 避免 round-robin 前缀重复计算；SGLang RadixAttention prefix cache 复用已有 10–20% 优势（inference.md 已有锚入） - HLD Blog 三篇（8-16/18/20）: vLLM MoRI-IO vs SGLang 动态路由、vLLM V1 重写架构分析、SGLang vs vLLM V1 横向对比；硬件池分离方案（Prefill Pool: H100/B200; Decode Pool: L40S/A100/MI300X） - KServe v0.17 upstreamed： spec.kvCacheOffloading.cpu: 10Gi → 自动 render --kv-transfer-config JSON；spec.prefill.kvCacheOffloading 字段

警示： - Mistral Large 123B 数值参考性；MoE vs 稠密差异较大，直接套用会高估/低估并发上限 - KEDA 单一信号（GPU cache pressure）需补 queue depth 监控；两者都应监控 - DRA 在 K8s 1.31+ 才稳定；部分生产环境 K8s 版本可能不支持

与活文档现有脉络的关系： - inference.md 8-22 版 §1.1 已有 vLLM 0.27.1 security-patch + SGLang K3 Day0；K8s 生产数值层（§1.1 补位 + §4.2 推理经济学新子节）是工程化落地数字的首次完整锚入 - 与 8-22 版 Serving Security 独立子节（§5）形成"安全 + 部署 + 扩缩"三维度 K8s 推理工程栈

建议归入节： §1.1（新增子节「K8s 生产推理完整数值层：0.344 MB/token + 128K 44GB + H100 并发 16–44 + KEDA 扩缩 + GIE prefix routing」）+ §4.2 推理经济学（补充 K8s 部署成本数字）

增量 2【KV Cache 压缩 · §3.3】🔴 DefensiveKV ICLR 2026 = SnapKV 基准修正是工程严肃性重要信号 ★★★

来源： inbox/jay/2026-08-22-engineering-e1prep.md（增量 2）+ inbox/spark/2026-08-22-llm-infra-e1prep.md（增量 2） 来源： FFY0/DefensiveKV（GitHub · ICLR 2026）；具体 arXiv ID 需从 repo 确认（待核实） 主分类： inference；形态： benchmark/correction；副分类： kv-cache, compression, snapkv, ruler

TLDR（来源：jay 8-22 engineering-e1prep + spark llm-infra e1prep）： SnapKV 原文在 RULER 20% cache size 下得分被高估；DefensiveKV 在相同条件下得分 85.3（vs SnapKV 声称的"无损"）；LayerDefensiveKV 达 91.4；实现仅需 NVIDIA KVPRESS + 2 行代码 Defensive Aggregation；单 RTX 4090 ≤1 小时可跑完 RULER 10%。

要点： - RULER 20% cache size 基准修正（关键数字）： - SnapKV 原文自称"接近无损" → 实测 39.0 分（非"无损"） - DefensiveKV：85.3 分 - LayerDefensiveKV：91.4 分 - 实现代价极低： NVIDIA KVPRESS + 2 行 Defensive Aggregation；单 RTX 4090 ≤1 小时跑完 RULER 10% - ICLR 2026 接收意义： 学术顶会接收确认工程严肃性；意味着"SnapKV 类 KV Cache 压缩方法在 RULER 基准的实际性能"需要重新评估 - 关键教训： "无损压缩"声称 → 必须有独立实测验证；压缩方法在单一 benchmark 的高分不等于跨模型/跨任务泛化

警示： - arXiv 编号待核实（来源为 GitHub repo FFY0/DefensiveKV，标注 ICLR 2026，具体编号未给出，需补查） - 评测仅在 RULER；LMEval / 其他长上下文 benchmark 未对比；不同 model family 一致性待验 - SnapKV 39.0 vs DefensiveKV 85.3 的差距是否在 RULER 之外泛化——尚无证据

与活文档现有脉络的关系： - inference.md 8-22 版 §3.3 Cache Compression 已有 DASH / HBF Sucks / vToken / Maglev / FreeToken / KV Cache Transform Coding ICLR 2026 + InferScale（注入）/ Online KV Cache Compaction（压缩） - DefensiveKV = §3.3 压缩方向"基准修正"信号补位；与 KV Cache Transform Coding ICLR 2026（加压增密）并列；共同构成压缩路线的"实测校准"维度

建议归入节： §3.3（新增子节「DefensiveKV ICLR 2026 基准修正 + SnapKV 39.0 实测 vs 声称无损 + LayerDefensiveKV 91.4 + 2 行实现 + RULER 20% 警示」）；与 Transform Coding ICLR 2026 并列为压缩路线"可验证性"锚点

增量 3【KV Cache 可观测性 · §3.1 + §3.3】🟠 kv-cache-analyzer CLI = 生产 KV Cache 可观测性工具链 ★★

来源： inbox/jay/2026-08-22-engineering-e1prep.md（增量 4）+ inbox/spark/2026-08-22-llm-infra-e1prep.md（增量 3） 来源： bs258q/kv-cache-analyzer（GitHub · MIT）+ llm-d/llm-d-kv-cache（GitHub · CNCF · vLLM v0.23 upstreamed） 主分类： inference；形态： tool；副分类： kv-cache, observability, cli, production, llm-d

TLDR（来源：jay 8-22 engineering-e1prep）： kv-cache-analyzer 提供生产 KV cache 的 CLI 命令和多场景 LRU hit rate 实测数字；llm-d 已 upstreamed 到 vLLM v0.23；两者共同构成 KV cache 从分析诊断（analyzer）到分布式路由（llm-d）的完整工具链。

要点： - kv-cache-analyzer CLI 命令： kv-cache-analyzer analyze logs.jsonl --format openai --model llama-3-70b \ --cache-size 200000 --block-size 16 --session-field session_id --output-json report.json - 多框架 LRU Hit Rate 实测（llama-3-70b）： | 场景 | LRU Hit Rate | Within-Session | |------|------------|----------------| | customer-support | ~92% | ~67% | | code-assistant | ~92% | ~60% | | rag-qa | ~93% | ~30% | - RAG QA within-session 30% = RAG 跨会话 KV cache 复用效果最差（检索新鲜度优先于缓存复用，与 inference.md 已有认知一致） - llm-d KV Events 路由（upstreamed vLLM v0.23）： 分布式 KV cache 跨 Pod 路由，vLLM 官方支持 - 安全设计： 512 MB 文件限制 + JSON depth limit + 防 symlink 攻击；含 check_cache_regression() CI/CD 集成函数

警示： - 数字来自 llama-3-70b；MoE vs 稠密、不同序列长度、不同请求分布下数字会有偏差 - RAG QA 30% within-session 不是 bug，而是 RAG 设计目标（新鲜度优先） - 仓库较新，需关注 maintenance 状态

与活文档现有脉络的关系： - inference.md §3.1/§3.3 KV Cache 管理已有 vToken / Maglev / FreeToken / DASH / HBF Sucks / InferScale / Online Compaction；kv-cache-analyzer = 可观测性子节首度锚入 - 与 §4.1 llm-d（CNCF Sandbox Kubernetes 分布式推理编排）形成"工具链 + 可观测性"互补

建议归入节： §3.1（新增 KV Cache 可观测性工具链子节：kv-cache-analyzer CLI + 多场景 LRU hit rate 实测 + RAG QA 30% 警示 + llm-d KVEvents + vLLM v0.23 upstreamed 确认）；§3.3 邻接标注

增量 4【推理引擎竞品分析 · §1.1】🟠 Spheron Network Benchmark：vLLM vs SGLang vs TensorRT-LLM 2026 决策框架 ★

来源： inbox/jay/2026-08-22-llm-inference-engineering-screening.md（条目 2）+ inbox/jay/2026-08-22-0935-jay-ai-engineering-inference-vecdb-hf-substack.md（§二） URL： https://www.spheron.network/blog/llm-inference-optimization-2026 主分类： inference；形态： benchmark；副分类： vllm, sglang, tensorrt-llm, comparison, throughput, latency

TLDR（来源：jay 8-22 screening）： 50 并发请求实测：TensorRT-LLM 吞吐量 2,100 tok/s（最快）但冷启动 28 分钟；SGLang 1,920 tok/s，TTFT p50 360 ms；vLLM 1,850 tok/s，TTFT p50 380 ms；SGLang prefix-heavy traffic 场景领先 vLLM 29%。

要点： - 50 并发请求实测数据（Spheron Network）： | Engine | Throughput | TTFT p50 | Cold Start | |--------|-----------|-----------|------------| | vLLM | 1,850 tok/s | 380 ms | ~62 sec | | TensorRT-LLM | 2,100 tok/s | 340 ms | ~28 min | | SGLang | 1,920 tok/s | 360 ms | ~58 sec | - SGLang Prefix Cache 实测（RunPod 独立测试）： Llama 3.1 8B，prefix-heavy traffic，SGLang ~16,200 tok/s vs vLLM ~12,500 tok/s（差距 29%，归因于 prefix cache reuse） - SGLang vs vLLM TTFT p50/p95： TTFT p50 低 37%，TTFT p95 低 41%（50 并发） - TensorRT-LLM 冷启动代价： 28 分钟编译是真实生产痛点；适合长时稳定服务，不适合 Serverless/按需扩缩场景 - HLD Blog 补充（8-18）： vLLM V1 重写架构分析；SGLang EPD（Encoder-Prefill-Decode）disaggregation；MLA 压缩；EAGLE-3 投机解码

警示： - Spheron Network = Spheron CTO 撰写，有商业立场（竞品中立性有限），数据需独立验证 - 测试条件（模型/硬件/请求分布）需完整核实才能做跨论文对比 - 冷启动数字（28 分钟）对 TensorRT-LLM 是已知痛点，非新发现

与活文档现有脉络的关系： - inference.md §1.1 已有 vLLM vs SGLang 框架对比（vLLM 0.27.1 / SGLang K3 Day0）；Spheron benchmark = 2026 年最新实测决策数据补位 - 与 8-22 版 §1.1 新增的 HLD Blog 三篇（MoRI-IO / EPD / vLLM V1 分析）共同构成"工程实测 + 架构分析"双维补充

建议归入节： §1.1（补充子节「2026 推理引擎实测决策数据：Spheron 50并发 benchmark + HLD Blog vLLM V1 / EPD / MoRI-IO 三篇 + TensorRT-LLM 冷启动代价」）或 §4.2 推理经济学（工程选型成本-性能对照）

增量 5【LLM 推理内核优化 · §7 推理优化全景】🟡 RMM（Reduced Matrix Multiplication）确认推理内核主轴候选（arXiv 2608.13426）★

来源： paper_cards/952-2608-13426.md（8-22 批次入库，主分类 llm-infra）+ inbox/tom/2026-08-20-inference-e1prep.md（8-20 棒首次出现邻接线索） arXiv： 2608.13426v1 主分类： llm-infra；形态： method；副分类： inference, matrix-multiplication, efficiency, training-free

TLDR（来源：paper_card TLDR）： RMM 提出 Reduced Matrix Multiplication，一种训练无关、输入自适应的推理方法，通过沿收缩维度选择信息性切片来缩减 Transformer 矩阵乘积，无需修改模型权重。在简单保留率控制下，提供平滑且可预测的精度-效率权衡。在 1B–70B 语言模型上验证。

要点： - 核心机制： 无需训练；在推理时根据输入自适应选择矩阵乘积的信息性切片；与模型权重无关 - 精度-效率权衡： 简单的保留率（retention ratio）控制；提供可预测的 accuracy-efficiency 曲线 - 规模验证： 1B–70B 语言模型全覆盖 - 与 TMA / FlashAttention 的关系： 三者均为推理优化，但层次不同——RMM 是矩阵级裁剪，TMA 是内存访问优化，FlashAttention 是注意力计算优化 - 2026-08-22 paper_cards 确认入库（8-20 首次出现邻接线索 → 8-22 确认入库升级）

警示： - TLDR 被截断；完整性能数字（具体保留率与精度损失对应关系）需 PDF 核验 - 1B–70B 覆盖范围是否包含 MoE 模型未说明 - 与其他推理优化方法（FlashAttention / PagedAttention / 量化）的组合效果未验证

与活文档现有脉络的关系： - inference.md 8-20 版引入了 RMM（邻接线索，arXiv 2606.20295 方向）；8-22 paper_card 确认入库（主分类 llm-infra）→ 从邻接升级为候选主轴 - 与 §7.1 Token-Operations 四层架构（arXiv 2606.20295v1）邻接——RMM 属于"计算层 token-ops 优化"

建议归入节： §7（新增 RMM 子节「缩减矩阵乘法：训练无关输入自适应 + 1B–70B 验证 + 精度-效率可预测权衡 + 与 FlashAttention/PagedAttention 层次区分」）；标注为候选 ★ 中档，待 PDF 核验

二、矛盾与待核实说法

矛盾 A【TurboQuant 数字冲突】：AIxFunda 声称 6×/8× vs jay 6-11 实测 2.69–4.4×

来源： inbox/jay/2026-08-22-0935-jay-ai-engineering-inference-vecdb-hf-substack.md（§五·AIxFunda）+ inbox/jay/2026-06-11-evening-supplement-k8s-db-inference-updates.md（§条目 5）

冲突描述： - AIxFunda（2026-08 上半月）： TurboQuant（Google）→ KV cache 压缩 6× + 推理加速 8×，H100 上零精度损失 - jay 6-11 实测（更可信的时间节点）： TurboQuant → 2.69–4.4×（同一 arXiv 2605.19660 论文的数字）

分析： TurboQuant 原论文（arXiv 2605.19660）数字应在 2–5× 范围；AIxFunda "6×/8× + 零精度损失"可能是将 KV 压缩倍数与端到端推理加速倍数混淆，或引用了最优条件下的数字。

建议： 查 TurboQuant 原论文 arXiv 2605.19660 核实各场景实际数字；AIxFunda 来源列为"待核验线索"而非可靠数据点。

矛盾 B【PowerLawAttention arXiv 编号】：2608.10288 推理时"经验性坍缩"claim 需要核实

来源： paper_cards/920-2608-10288.md（8-22 批次入库，主分类 llm-infra） arXiv： 2608.10288 标题声明： "幂律图注意力：缩放点积注意力的精确泛化，推理时出现经验性坍缩"（Power law graph attention: exact generalization... empirical collapse at inference）

警示： - "推理时经验性坍缩"claim 与 SGLang/vLLM 等生产系统中 attention 的实际鲁棒性存在张力；需要原论文核实实验条件 - "exact generalization of scaled dot-product attention"——严格数学声明，需要核实证明 - 建议列为"待 PDF 核验 claim"；不作为已知事实在活文档中引用

矛盾 C【DefensiveKV arXiv 编号缺失】

来源： inbox/jay/2026-08-22-engineering-e1prep.md（增量 2）+ inbox/spark/2026-08-22-llm-infra-e1prep.md（增量 2） 来源： FFY0/DefensiveKV（GitHub · ICLR 2026 接收）

缺失信息： - GitHub repo 标注 ICLR 2026，但具体 arXiv 编号未给出；需要从 repo 或 ICLR 论文集补查 - 在核实 arXiv 编号前，活文档中只能引用"DefensiveKV（ICLR 2026 / FFY0/DefensiveKV）"

三、可引用 arXiv 号列表（本次新进）

四、已检查来源清单

本棒已检查的 inbox 来源（8-21 22:20 → 8-22 22:20 窗口）：

本棒已检查的 paper_cards 来源（8-20 ~ 8-22 批次）：

结论： inference 主题 8-21→22 窗口增量以工程化/工具链/部署数值层为主（K8s / kv-cache-analyzer / DefensiveKV 基准修正 / Spheron benchmark），无新增 arXiv 推理 Serving 主轴（PD disaggregation 新架构/新方法）；TurboQuant 数字冲突需在接力棒核实。

Tom · 2026-08-22 22:20 CST · inference · E1 预消化轮