Jay 工程实践筛选 · 2026-09-26 晚间
主题
KV Cache 容量规划与淘汰策略 2026 新进展（arXiv Sep 23）+ AWS 分层存储实战 + AMD 推理基准
候选条目
| # | 条目 | 来源 | 时间 | 初判 |
|---|---|---|---|---|
| 1 | The KV Cache Working Set: Online Capacity Planning for LLM Inference Systems | arXiv:2609.27746 | 2026-09-23 | ✅ 保留 |
| 2 | Risk-Controlled KV-Cache Eviction: From Memory Budgets to Risk Targets | arXiv:2609.27981 | 2026-09-23 | ✅ 保留 |
| 3 | Accelerate inference with KV cache tiering on AWS | AWS Storage Blog | 2026-09-21 | ✅ 保留 |
| 4 | TileRT AgentX on AMD Instinct GPUs — 469 tok/s, 1M context | AMD ROCm Blog | 2026-09-24 | ⚠️ 参考 |
| 5 | NVIDIA AIPerf K8s — Exit code 137 OOM 修复方案 | NVIDIA Docs | 2026 | ⚠️ 参考 |
| 6 | Q2D-Web: Large-Scale Agentic RAG Benchmark | arXiv:2609.08887 | 2026-09-09 | ⚠️ 参考 |
| 7 | ClusterMAX 3.0 — EFA vLLM/SGLang 部署注意事项 | SemiAnalysis | 2026-09 | ⚠️ 参考 |
✅ 保留条目 1：KV Cache Working Set
标题： The KV Cache Working Set: Online Capacity Planning for LLM Inference Systems 作者： Luchang Li et al.（arXiv:2609.27746，2026-09-23） 可信度： 高 — 有开源实现，支持在线请求处理和离线 trace 回放
核心内容
Prefix caching 对 Agentic 工作负载至关重要（共享系统 prompt、工具调用历史产生相同 KV 向量）。但现有方法依赖静态配置或事后分析，本文提出在线容量规划方法：
- KVSET 工具：根据目标命中率，自动推导所需的最大 LRU 深度，据此确定最小缓存容量
- 验证方式：使用生产 LLM 工作负载 trace，估算结果与真实缓存部署测量值高度吻合
- 关键洞察：在实际生产中，KV cache 的"工作集"大小随并发量、prompt 复用率动态变化；静态配置常导致 OOM 或命中率过低
工程价值
| 维度 | 评价 |
|---|---|
| 实战性 | 高 — 有 trace replay 开源工具，可直接用于生产容量评估 |
| 新颖性 | 高 — 在线规划而非静态配置，填补了生产 KV 容量规划的空白 |
| 可复现 | ✅ 有代码（GitHub 链接待查） |
筛选理由（保留）
首次系统提出 KV cache 工作集在线容量规划，解决了生产部署中"缓存配多大"的工程难题，而非停留在算法层淘汰策略。带 trace replay 验证，工程可直接使用。
✅ 保留条目 2：Risk-Controlled KV-Cache Eviction
标题： Risk-Controlled KV-Cache Eviction: From Memory Budgets to Risk Targets 作者： Beomgu Kang et al.（arXiv:2609.27981，2026-09-23） 可信度： 高 — ACL/ICLR 风格方法论，压缩方法无关（compressor-agnostic）
核心内容
传统淘汰策略用平均质量-内存 trade-off 评估，但平均损失小不代表所有请求都好——少数请求质量大幅下降会被平均值掩盖。本文重新定义问题：
- Material Degradation（实质性退化）：当淘汰后任务质量相比全 KV 推理下降超过部署容忍阈值
- Deployment Risk：发生实质性退化的请求在全体中的比例（population frequency）
- 可靠性合约（Reliability Contract）：指定目标风险等级 + 置信度要求
- 后验认证流程：给定可靠性合约，从校准数据中选择保留策略，提供有限样本保证；无策略满足则回退全 KV
实验结论（Llama + Mistral，LongBench + RULER-32K）
- 同一合约在不同模型上支持截然不同的淘汰策略
- Llama LongBench：SnapKV 在 75% 保留率下通过认证；但 RULER-32K 上没有任何压缩策略通过认证，必须全 KV
- 关键启示：RULER-32K 等长上下文基准对淘汰更敏感，认证结果不能跨任务迁移
工程价值
| 维度 | 评价 |
|---|---|
| 实战性 | 高 — 提供有限样本认证流程，生产可直接用可靠性合约约束淘汰策略 |
| 新颖性 | 高 — 首次将淘汰策略评估从平均质量转向部署级可靠性风险 |
| 可复现 | ✅ 有 TeX 源码 |
筛选理由（保留）
将淘汰策略从"平均质量"指标提升到"部署可靠性合约"层面，是生产级 KV 淘汰策略选择的方法论突破。工程团队可以直接说"我的 SLA 要求 95% 请求无实质性退化"然后反推淘汰策略，而非拍脑袋配置。
✅ 保留条目 3：AWS KV Cache 分层存储实战配置
标题： Accelerate inference with KV cache tiering on AWS（AWS Storage Blog，2026-09-21） 来源： AWS 官方博客 可信度： 高 — AWS 官方，含具体公式和 FSx for Lustre 选型步骤
核心工程内容
两种淘汰模式（Eager vs Lazy）的带宽计算公式：
# Eager eviction（立即写 T3）
峰值溢出带宽 = new_sessions/second × KV_per_session
# Lazy eviction（压力触发时才降级）
峰值溢出带宽 = (new_sessions/second × KV_per_session) − evictions_returning_capacity/second
FSx for Lustre 容量选型步骤（4 步）：
1. 计算峰值写带宽（eviction rate）
2. 计算峰值读带宽（promotion rate）= cache_hit_rate × req/s × avg_KV_per_promoted_session
3. 选吞吐量档位（125 / 250 / 500 / 1000 MBps per TiB），使 capacity_TiB × throughput_per_TiB ≥ max(write_req, read_req)
4. 容量 = peak_sessions × avg_KV_per_session × (1 − T1_T2_absorption_ratio)
Prefix cache namespace 设计原则： - 系统 prompt、RAG 文档前导、通用指令模板 → 相同 KV 向量，可跨节点共享 - T3 层 write-once, read-many：一份 KV，多个节点读取，避免重复 prefill - 适合 Agentic 多轮对话：每轮都含相同 system prompt
与今日其他条目的关联
| 关联条目 | 关系 |
|---|---|
| arXiv 2609.27746（KVSET） | KVSET 决定"多大"，AWS 博客决定"放哪层"——两者组合构成完整容量+分层策略 |
| arXiv 2609.27981（Risk-Controlled） | 风险控制决定"淘汰哪些"，AWS 决定"淘汰到哪层"——上下游关系 |
筛选理由（保留）
AWS 官方提供了从公式到 FSx 选型的完整生产路径，是目前最完整的 KV 分层存储配置指南。Eager/Lazy eviction 的带宽计算公式可直接用于容量规划文档。
⚠️ 参考条目
AMD TileRT / AgentX（Sep 24）
- TileRT + GLM-5.3 FP8 在 8× MI355X 上达到 469 tok/s，AgentX leaderboard 第一
- 关键指标：1K → 1M context，保留约 2/3 原始速度——说明长上下文内存访问开销线性增长但可控
- 结论：AMD MI350X/MI355X 对长程 Agent 工作负载已有明确竞争力
- 参考价值：跨硬件对比数据，不要单独作为选型依据
NVIDIA AIPerf K8s Exit Code 137（OOM）
- Exit code 137 = SIGKILL（OOM 或外部 kill）
- 优先级修复步骤： 降低 cgroup ceiling →
spec.resourceMode: burstable（默认，推荐开发/基准测试）→guaranteed（requests == limits，生产高优任务） - 附：exit code 1 = 配置错误/模型缺失；exit code 2 = Python 语法/镜像版本问题
- 参考价值：快速 K8s OOM 排障命令备忘
Q2D-Web（arXiv 2609.08887，Sep 9）
- 190M 文档语料 + 70k agentic 搜索查询（10 语言），来自真实生产用户 query 的 agent reformulation
- 13 个 retriever 评测，含 dense、lexical、late-interaction 模型
- 关键发现：rel ordering 在不同 judgment set 选择下稳定，但跨 domain、query language 差异大
- 参考价值：Agentic RAG retriever 评测标准数据集；已覆盖在今日 Jay 草稿（2026-09-26 1735），可交叉引用
分类标签
KV-Cache 容量规划 淘汰策略 AWS-Storage FSx-Lustre Eager-Lazy-Eviction 风险控制 AMD-ROCm Inference-Engine Agentic-RAG Production-Engineering
建议写入路径
主要草稿：
/shared/research-kb/inbox/jay/2026-09-26-1950-jay-kvcache-capacity-eviction-production-2026sep23.md
关联补充（如果需要整合到现有主题页）： - 合并到现有 KV Cache 主题页（建议由 review 环节合并） - Q2D-Web 可补充到 agentic RAG benchmark 主题
后续行动建议
| 优先级 | 行动 |
|---|---|
| 高 | arXiv 2609.27746 KVSET 开源代码复现测试（用 trace 数据验证容量估算准确性） |
| 中 | AWS 博客 FSx 选型公式整合到 vLLM/SGLang 生产 runbook |
| 中 | arXiv 2609.27981 可靠性合约思路引入 Jay 推理引擎评估框架 |
| 低 | AMD vs NVIDIA AgentX 对比数据补充到硬件选型参考页 |
是否需要精读/审稿/主题页更新
- 精读（建议）： arXiv 2609.27746（带开源工具，trace replay 可验证）；arXiv 2609.27981（方法论完整，有限样本认证流程可工程化）
- 审稿： 暂不需要，可纳入季度 KV Cache 专题更新
- 主题页更新： 建议在 KV Cache 主题页新增"容量规划"和"可靠性合约"两个子章节