inference · E1 预消化简报(2026-08-29)
执行： Tom · inference 主题 E1 日间预消化轮 · cron e627b203 · 窗口：2026-08-29 06:10 → 22:20（约 16h）
基线活文档： organized/knowledge/inference.md（2026-08-29 日间更新版 · vLLM Conf 2026 + SGLang v0.6+DSpark；引→约295）
基线 E1 报告： inbox/tom/2026-08-28-inference-e1prep.md（8-28 日间棒，4 条主线索含 Prefix Sliding + KV Cache Survey + Spheron 三引擎 + AIConfigurator）
本棒性质： inference 主题 E1 日间预消化轮（16h 短窗口）；承接 8-28 晚棒之后，专注 8-29 06:10 → 22:20 新增；不重写活文档，只列近 16h 新增量供今晚活文档接力决策参考
状态
- 增量条数： 6 条主线索（含 2 条安全重大发现 + 1 条第三引擎新进入者 + 1 条内存墙破局方案 + 2 条 benchmark/数据集）+ 2 条工程实践补强
- 显著新增： 有——MATS Research 加密推理窃取（arXiv:2608.09867）安全领域重大新锚；MAX Modular AI（第三引擎·非 CUDA Mojo 栈）；SK Hynix HBF 内存架构（18.8× 批处理提升）；UPHELD 多轮对话数据集（arXiv:2608.21281）；ByteByteGo EP223 三引擎完整决策树 + llama.cpp 安全漏洞；KV Cache 五族工程实践
- 本棒说明： 今日 inference 主题增量密度高，主要来自 jay 晚间两批次简报（21:00 + 22:05）。安全维度出现重大新锚：MATS Research 揭示"加密推理 ≠ 隐私推理"——加密 blob 可 replay 到同系列便宜模型提取明文，这是 inference 领域此前未覆盖的供应链攻击面。工程维度 MAX 作为第三引擎新进入者（非 CUDA Mojo 栈）标志着 2026 下半年推理引擎格局从"vLLM vs SGLang 双雄"演变为"vLLM vs SGLang vs MAX 三足"。HBF 混合内存架构是 KV Cache 内存墙的硬件破局信号。
- 涉及 arXiv 号： 净增 5 件（
2608.09867、2608.21281、2608.09867重考、MATS Research 加密推理 + UPHELD + ACM TIST 2026 综述）；沿用 25+ 件
一、最重要的 6 条增量
增量 1【安全重大新锚 · §4 安全邻接首次锚入】🔴 arXiv:2608.09867 — 加密推理窃取攻击（MATS Research）★★★★
来源： inbox/jay/2026-08-29T2205-jay-night-supplement-bytebytego-hbf-kvcache-upheld.md（§二 · ByteByteGo 解读 MATS Research）+ inbox/jay/2026-08-29T2100-jay-evening-inference-stack-substack-acm-survey-2026.md（§二 S1 无直接关联但 MATS Research 被 jay 晚间简报收录）
arXiv： 2608.09867（2026-08 提交 · 作者：MATS Research + ELLIS Institute Tübingen + Max Planck Institute for Intelligent Systems）
TLDR（来源：ByteByteGo 解读 + arXiv abstract）： 加密 reasoning blocks 并不安全——可以被 replay 到同系列便宜模型提取明文。攻击原理：加密 blob 需要跨用户/上下文/model 迁移（用于无缝切换模型和自动路由），这意味着攻击者可以：(1) 获取目标模型的加密 reasoning block；(2) 将其 replay 到同系列便宜模型（如 Haiku 代替 Opus）；(3) 便宜模型将明文打印出来。2026-07 各提供商测试：Gemini 接受所有跨代组合（最脆弱）；Claude Fable 5 仅接受自 Fable 5（同代限制）；GPT-5.6 接受所有早期版本 blocks。
要点：
攻击原理： - API 提供商的"加密推理"是传输层安全（TLS），不是计算层隐私 - 加密 blob 设计上需要跨用户/上下文/model 迁移以支持模型无缝切换和自动路由 - 攻击者利用这一设计特性：将目标模型的加密 reasoning block replay 到同系列便宜模型，便宜模型将明文打印出来 - 实质：API 提供商"可以限制但目前未限制"的跨模型/代际推理块接受策略
2026-07 实证数据（按提供商）：
| 提供商 | 可提取性 | 限制 |
|---|---|---|
| Gemini | 接受所有跨代组合 | 无任何限制，最脆弱 |
| GPT-5.6 系列 | 接受所有早期版本 blocks | 老版本只接受自己的 blocks |
| Claude | 几乎所有组合均接受 | 例外：Fable 5 blocks 仅接受自 Fable 5 |
安全启示： 1. 加密推理 ≠ 隐私推理——"加密"是传输层安全，不是计算层隐私 2. Gemini 最脆弱：无任何跨代际限制 3. Claude Fable 5 最安全：同代限制策略 4. 攻击边界在 API 提供商手中——他们"可以限制"但目前未限制 5. data exfiltration injection 测试：在 Opus 4.7 的 Claude Code scaffold 中注入任务，让 Haiku 4.5 生成 thoughts 并上传到攻击者服务器
与活文档现有脉络的关系： - inference.md §4（推测有安全/隐私节）邻接级——这是 inference 安全维度的全新锚点，此前活文档未覆盖"加密推理块跨模型 replay"这一攻击面 - 与 inference.md §1.1（推理引擎架构）无直接关系，但与"模型 API 服务"整体安全性相关 - 建议归入：§4 安全 + 隐私（邻接新增；如无独立安全节，则在 inference.md 开篇或§1.1增加"API 推理安全"邻接标注）
警示： - ⚠️ P1：MATS Research arXiv:2608.09867 论文标题、作者、主要结论需对照原文核验 - ⚠️ P1：具体哪些模型版本受影响、提取成功率量化数据需核实原文 Table - ⚠️ P1：Claude Fable 5"同代限制"的实现细节（是否基于 model family / version hash / 其他机制）需核实 - ⚠️ P2："加密 blob 需要跨用户迁移"是设计决策还是实现 bug？API 提供商是否在知情的情况下允许这一行为？
建议归入节： §4 安全与隐私（邻接新增；如无独立安全节则归入§1.1邻接，标注"API 推理安全新攻击面——加密推理块跨模型 replay"）
增量 2【第三引擎新入局 · §1.1 三足格局首次锚入】🟢 MAX (Modular AI) 非 CUDA 推理栈 ★★★★
来源： inbox/jay/2026-08-29T2100-jay-evening-inference-stack-substack-acm-survey-2026.md（§一 M1 · Fish Audio Blog）+ inbox/jay/2026-08-29T2205-jay-night-supplement-bytebytego-hbf-kvcache-upheld.md（§一 ByteByteGo 决策树）
来源链接： https://fish.audio/blog/open-source-llm-inference-engines-2026
TLDR（来源：Fish Audio Blog）： MAX（Modular AI）是 2026 下半年新入局的推理引擎，与 vLLM/SGLang 并列为三大生产级选项之一。核心创新：全栈 Mojo 内核替代 cuBLAS/cuDNN/FlashAttention，完全不依赖 NVIDIA CUDA 生态。在 L40 + Qwen3-8B 测试中，500 prompts 耗时 50.6s（比 SGLang 快 7% 比 vLLM 快 16%）；Vast.ai + Llama 3.1 8B 测试中达 89.9 tok/s（比 vLLM 快 18%）。
要点：
MAX 核心技术： - Mojo 内核替代 cuBLAS/cuDNN/FlashAttention：用 Mojo 编写 matmul 内核，在 B200 上达到 1,772 TFLOPS，超越 cuBLAS - 完全无 CUDA 依赖：唯一不依赖 NVIDIA CUDA 生态的推理引擎栈，Mojo 内核可移植到任意硬件 - 许可证：Apache 2.0 + LLVM Exception / Modular Community License（编译器部分限制商业使用） - 商业实体：Modular AI（$1.6B 估值）
Benchmark 数据（Fish Audio 实测）：
| 配置 | MAX | SGLang | vLLM |
|---|---|---|---|
| L40 + Qwen3-8B 500 prompts | 50.6s | 54.2s | 58.9s |
| Vast.ai + Llama 3.1 8B | 89.9 tok/s | — | 75.9 tok/s |
| TTFT（Llama3.1 8B） | ~短（几乎减半） | — | 150ms 基准 |
GitHub： ~25,600 stars；Apache 2.0（主库）+ Modular Community License（编译器部分）
2026 下半年推理引擎选型决策框架更新：
| 引擎 | 定位 | 核心特性 | 适合场景 |
|---|---|---|---|
| TensorRT-LLM | 云端极致吞吐 | 编译优化，最专用 | 模型和流量双重稳定后的固定生产负载 |
| vLLM | 云端灵活部署 | 最大生态，PagedAttention | 高并发 API，最大 GPU 利用率 |
| SGLang | Agent 专用 | RadixAttention 前缀缓存 | 多轮对话，共享前缀，结构化输出 |
| MAX | 非 NVIDIA / Mac | Mojo 内核无 CUDA | Mac、非 NVIDIA 硬件、需要 CUDA 替代 |
| Ollama | 本地快速原型 | 单命令运行 | 单用户本地测试 |
| LMDeploy | 国内 GPU | 昇腾等国产支持 | 昇腾等国产芯片 |
| MLC LLM | 移动端 | WebGPU/Vulkan | 移动设备 |
与活文档现有脉络的关系： - inference.md §1.1 已有 vLLM vs SGLang 二分天下框架；本棒 = 首次将 MAX 补入形成"三足"格局（vLLM + SGLang + MAX） - 与 inference.md §1.1 已有 Ollama 定位（单用户本地）互补；MAX 是 Ollama 的生产级非 NVIDIA 替代 - 与 ByteByteGo EP223 决策树（Ollama vs vLLM vs SGLang）形成三层扩展
警示： - ⚠️ P1：Fish Audio benchmark 测试环境（具体硬件配置、batch size、上下文长度）需核验原文 - ⚠️ P1："1,772 TFLOPS on B200"的对比基准（是 B200 FP8 理论峰值还是 cuBLAS 实际性能？）需核验 - ⚠️ P2：Modular Community License 限制商业使用的边界（哪些部分不能用？）需核实 - ⚠️ P2：Mojo 语言学习曲线和生产部署成熟度（非 Mojo 团队）需评估 - ⚠️ P2：GitHub ~25,600 stars（vLLM ~75,000，SGLang ~25,000）说明 MAX 社区仍小
建议归入节： §1.1（新增「MAX Modular AI——非 CUDA 第三引擎」子节；更新"推理引擎选型决策框架"从二分天下到三足鼎立；与 Ollama/TGI/LMDeploy 共同构成全场景选型矩阵）
增量 3【KV Cache 内存墙硬件破局 · §1.3 邻接首次锚入】🟡 SK Hynix HBF + HBM 混合内存架构 ★★★
来源： inbox/jay/2026-08-29T2205-jay-night-supplement-bytebytego-hbf-kvcache-upheld.md（§四 · Gradient Flow RSS + Blocks and Files + HotInfra 2026）
来源链接： Blocks and Files（SK Hynix 新闻）+ Gradient Flow RSS（HBF 文章）
TLDR（来源：jay 夜间简报）： SK Hynix HBF（Hierarchical Bandwidth Fabric）是针对 KV Cache 内存墙的硬件解决方案。实测数据（10M token KV cache，Blackwell GPU + HBF）：HBM+HBF 配置比 HBM-only 多处理 18.8× 的查询量，能效比提升 2.69× perf/watt。关键结论：2 GPU + HBF ≈ 32 GPU HBM-only 的工作负载处理能力。
要点：
HBF 核心数据：
| 配置 | 批处理量 | 能效比 |
|---|---|---|
| HBM-only（8×HBM 堆叠） | 基准 | 基准 |
| HBM+HBF（+HBF 外接） | 18.8× 更多查询 | 2.69× perf/watt |
关键工程结论： - 2 GPU + HBF ≈ 32 GPU HBM-only的工作负载处理能力 - 显著降低电力消耗 - Nvidia ICMSP 软件：将 KV cache 扩展到本地 NVMe SSD，HBM 容量不足时避免重新计算
KV Cache 内存墙解决路径三件套（2026 汇总）：
| 方案 | 层级 | 代表工作 |
|---|---|---|
| Prefix Sliding（丢弃策略） | 软件 | 丢弃不重要中间 token |
| HBM+HBF（新型内存架构） | 硬件 | 混合内存带宽fabric |
| CXL 分解式 KV Cache（互联） | 互联 | 跨机 KV cache 共享 |
与活文档现有脉络的关系： - inference.md §1.3 已有 Prefix Sliding（丢弃策略）和 StreamingLLM（attention sink）；本棒 = 硬件层破局方案，与软件层构成"内存墙完整解决路径" - 与 inference.md §1.3 DASH/C²KV/TTKV 等 KV Cache 优化邻接；HBF 是这些软件优化无法替代的硬件基础
警示： - ⚠️ P1：HBF 实际部署时间线和量产状态需核实（是产品路线图还是 research prototype？） - ⚠️ P1：HBF 与现有 vLLM/SGLang/PagedAttention 软件层的集成方式（驱动/API 支持）需核验 - ⚠️ P2：HBF 成本结构（相比纯 HBM 的额外成本）未披露；"18.8× 批处理"测试条件（并发数、序列长度）需原文核验
建议归入节： §1.3（新增「SK Hynix HBF 混合内存架构——KV Cache 内存墙硬件破局」邻接级条目；与 Prefix Sliding + CXL 分解式 KV Cache 共同构成"内存墙三件套"邻接族）
增量 4【多轮对话评测新基准 · §2.5 评测邻接首次锚入】🟡 arXiv:2608.21281v1 — UPHELD 多轮对话数据集 ★★★
来源： inbox/jay/2026-08-29T2205-jay-night-supplement-bytebytego-hbf-kvcache-upheld.md（§六）+ paper_card 1121（2026-08-28 入库）
arXiv： 2608.21281v1（2026-08-28 提交 · 来自 paper.dou.ac 学术平台）
TLDR（来源：jay 夜间简报）： - UPHELD 数据集：专业人员编写的长对话基准 - 核心发现：现有自动评估方法在多轮对话场景下不可靠 - 组合评估框架：针对多轮对话特点设计的新型评估方法
要点：
核心贡献： - 专业人员编写的长对话 benchmark（高质量人工标注） - 发现现有自动评估方法在多轮对话场景下不可靠（与 8-28 inference e1prep 的 TTPO 多数票伪标签问题呼应——自动评估可靠性是多轮对话的共同挑战） - 提出针对多轮对话特点设计的新型评估框架（组合评估） - 与 PILOT in the Loop（长程 Agent 在线自改进）构成执行-评测互补：PILOT = 长程 Agent 执行层面；UPHELD = 长程 Agent 评测层面
工程意义： - 多轮对话是 Agent 场景的核心（Agent = 多轮推理 + 工具调用 + Memory + 状态管理） - 可靠的评测方法是 Agent 从 demo 到生产的最后一公里障碍 - UPHELD 揭示的"自动评估不可靠"问题与 inference.md §2.5（推理训练目标偏差，arXiv:2608.13760）形成的"训练目标偏差 × 评测可靠性"双面问题
与活文档现有脉络的关系： - inference.md §2.5（推测有评测相关节）邻接——与 PILOT（arXiv:2608.26530）、TTPO（arXiv:2608.27448）共同构成"长程 Agent 评测"邻接族 - 与 §2.5 TTPO 多数票伪标签问题呼应：两者都揭示"自动评估方法的可靠性"这一底层问题
警示： - ⚠️ P1：UPHELD 数据集 HF/Dataset 链接待确认（jay 简报未提供直接链接） - ⚠️ P1：具体数据规模（对话数量、对话长度、人工标注比例）需核实原文 Table 1 - ⚠️ P2：paper_card 1121 是 PILOT in the Loop 的 card；UPHELD paper_card 尚未入库
建议归入节： §2.5 评测（邻接新增；标注"多轮对话评测——UPHELD 数据集 + 自动评估可靠性问题"；与 PILOT + TTPO 共同构成"长程 Agent 执行-评测"邻接族）
增量 5【推理引擎选型工程实践 · §1.1 邻接补强】🟡 ByteByteGo EP223 Ollama vs vLLM vs SGLang 完整决策树 ★★★
来源： inbox/jay/2026-08-29T2205-jay-night-supplement-bytebytego-hbf-kvcache-upheld.md（§一 · ByteByteGo Blog）+ inbox/jay/2026-08-29T2100-jay-evening-inference-stack-substack-acm-survey-2026.md（§Benchmark 快照）
来源链接： https://blog.bytebytego.com/p/ep223-ollama-vs-vllm-vs-sglang
TLDR（来源：ByteByteGo EP223）： ByteByteGo（System Design 顶级技术博客）对三大主流推理引擎 Ollama / vLLM / SGLang 进行系统性对比。关键数据：100 并发下 vLLM ~920 tok/s vs Ollama ~155 tok/s（10-20× 差距）。安全警示：llama.cpp 生态存在 6 个未修复漏洞（2026-05，无 CVE），将模型文件下载视为安全边界。
要点：
ByteByteGo EP223 核心数据（SesameDisk 2026 年 5-6 月聚合基准）：
| 引擎 | 50 并发 | 100+ 并发 | 适用场景 |
|---|---|---|---|
| vLLM | ~920 tok/s | 随 batch 规模线性扩展 | 高并发 API |
| SGLang | 参照对比 | 参照对比 | Agent / 共享前缀 |
| Ollama | ~155 tok/s | 串行化为单一队列 | 单用户本地 |
100 并发下的性能差距： - vLLM ~920 tok/s vs Ollama ~155 tok/s → 10-20× 差距 - 原因：vLLM continuous batching 新请求直接插入正在运行的 batch；Ollama 串行化为单一队列
⚠️ 安全风险（2026-05，无 CVE）： - llama.cpp 生态存在 6 个未修复漏洞（影响 Ollama / llama.cpp / 所有基于 GGUF 的工具） - 将模型文件下载视为安全边界——不要信任未签名的模型文件 - 这是 2026 年被低估的供应链风险
快速选型决策树（ByteByteGo 原文）：
单用户本地测试/快速原型？
├── 是 → Ollama（上手最快）
└── 否（生产环境？）
├── Agent workflow / 多轮对话 / 结构化输出？
│ ├── 是 → SGLang（RadixAttention 前缀缓存优势）
│ └── 否
│ ├── 高并发 / 最大 GPU 利用率 / 数千并发请求？
│ │ ├── 是 → vLLM（生态最成熟，高并发最优）
│ │ └── 否
│ │ └── 需要 NVIDIA TensorRT 极致优化？
│ │ └── 是 → TensorRT-LLM（编译优化，最专用）
│ │ └── 需要非 NVIDIA / Mac / CUDA 替代？
│ │ └── 是 → MAX（Mojo 内核，Modular AI）
与活文档现有脉络的关系： - inference.md §1.1 已有 Spheron 三引擎 benchmark + 60% 前缀重叠率阈值；本棒 = 补入 ByteByteGo EP223 完整决策树 + SesameDisk 量化基准（100 并发 920 tok/s）+ llama.cpp 安全漏洞警示 - 与 inference.md §1.1 MAX 三足格局形成完整选型闭环（MAX 加入后决策树扩展）
警示： - ⚠️ P2：SesameDisk 完整基准报告测试环境（硬件、模型、batch size）需核验原文 - ⚠️ P2：llama.cpp 6 个漏洞的具体 CVSS 评分和利用条件需核实（2026-05 无 CVE 说明可能是 0-day 或私下披露） - ⚠️ P2：920 tok/s @ 100 并发的测试模型（是 Llama 3.1 8B 还是其他？）需确认
建议归入节： §1.1（更新「推理引擎选型决策框架」——纳入 ByteByteGo EP223 完整决策树 + SesameDisk 100并发基准 + llama.cpp 安全警示；与 MAX 三足格局补强形成完整选型矩阵）
增量 6【KV Cache 五族优化工程实践 · §1.3 邻接补强】🟡 KV Cache 优化五族工程指南 ★★★
来源： inbox/jay/2026-08-29T2205-jay-night-supplement-bytebytego-hbf-kvcache-upheld.md（§五）
来源链接： https://www.digitalapplied.com/blog/kv-cache-optimization-techniques-2026-engineering-guide（2026-04-24，工程实践价值高）
TLDR（来源：jay 夜间简报）： 五大家族 KV Cache 优化技术（2026 年 4 月工程实践总结）：Paged Attention / Prefix Caching / MQA-GQA-MLA / FP8 KV 量化 / KV Cache Offloading。1M context 实测：KV memory 占 wall-clock 60-85%、占 GPU 内存 70-90%；综合使用五种技术可实现 4-40× 成本降低。
要点：
KV Cache 优化五族：
| 家族 | 代表技术 | 核心机制 | 生产就绪度 |
|---|---|---|---|
| Paged Attention | vLLM 核心 | 虚拟内存式 KV 管理 | 极高 |
| Prefix Caching | SGLang 核心 | 共享前缀复用 | 高 |
| MQA / GQA / MLA | 注意力头压缩 | 降低 KV cache 体积 | 高 |
| FP8 KV 量化 | 免费内存节省 | 50% 内存节省 | 高 |
| KV Cache Offloading | CPU-GPU-NVMe 分层 | 扩展缓存容量 | 中 |
1M context 实测数据（Digital Applied 工程指南 2026-04）： - KV memory = 60-85% wall-clock 时间 - KV memory = 70-90% GPU 内存 - 综合使用五种技术：4-40× 成本降低
核心判断（原文引用）：
"Above 128K tokens, KV memory exceeds parameter memory on most architectures." "5 technique families collapse this number by 4 to 40× — the difference between '1M context is a marketing claim' and '1M context is in production.'"
与活文档现有脉络的关系： - inference.md §1.3 已有 KV Cache Optimization Survey（arXiv:2603.20397v1）系统性综述；本棒 = 工程实践视角的量化补强（4-40× 成本降低 + 60-85% wall-clock 数据） - 与 Prefix Sliding（丢弃策略）+ HBF（硬件架构）共同构成"软件-配置-硬件"三层 KV Cache 优化体系
警示： - ⚠️ P2：4-40× 成本降低的测试条件（具体使用哪五种技术组合、模型规模、序列长度）需原文核验 - ⚠️ P2：2026-04 发表，时间差约 4 个月；需核验是否有更新版本
建议归入节： §1.3（更新「KV Cache 五族优化」邻接——补入 4-40× 成本降低量化数据 + 1M context 实测数据；作为 §1.3 KV Cache Optimization Survey 的工程实践补强）
二、矛盾或待核实说法
警示 1【🟠 C²KV arXiv ID 误标——已持续 4 实例】
问题： C²KV（TTKV 邻接工作）被 jay + stephen + spark + 多个实例持续误标为 arXiv:2608.14192。正确 ID 为 arXiv:2607.17715v1（KDD 2026）；2608.14192 是另一篇不同论文。
影响范围： jay engineering-e1prep（8-27）+ stephen 协调棒（8-27 noon）+ spark llm-infra e1prep（8-27 evening）+ 8-28 inference e1prep 再次确认，共 4+ 实例。
状态： 已在 8-27、8-28 inference e1prep 中明确警示；本棒再次确认——knowledge/inference.md 中所有 C²KV 引用均须使用 2607.17715，而非 2608.14192。
警示 2【⚠️ MAX (Modular AI) Benchmark 数据来源可靠性】
问题： Fish Audio Blog 的 MAX benchmark 数据（50.6s vs 54.2s vs 58.9s）未经同行评审；测试环境具体配置缺失。
待核验： - Fish Audio 测试的 batch size、上下文长度、具体硬件型号（是 L40 SXM 还是 PCIe？） - "1,772 TFLOPS on B200"是理论峰值还是实测数据？对比基准是什么？ - Modular AI 官方是否发布过独立第三方的 benchmark 验证？
建议： 以 vLLM/SGLang 官方博客和 Spheron/SesameDisk 等第三方实测为基准；Fish Audio 数据作为参考方向信号，不作为精确决策依据。
警示 3【⚠️ MATS Research 加密推理窃取（arXiv:2608.09867）核心数据待原文核验】
问题： ByteByteGo 解读提供了定性的攻击原理和提供商对比，但具体量化数据（提取成功率、具体模型版本对应关系）需对照 arXiv 原文核实。
待核验： - arXiv:2608.09867 论文标题和作者（是否确为 MATS Research + ELLIS Institute + Max Planck？） - 各提供商（Gemini / GPT / Claude）具体接受策略的测试数据集规模和测试方法 - 攻击的实际可操作性（是否需要 API 访问？还是仅需加密 blob 即可？）
警示 4【⚠️ UPHELD 数据集 paper_card 未入库】
问题： UPHELD（arXiv:2608.21281v1）在 jay 夜间简报中被报告，但 paper_card 尚未建立（paper_card 1121 是 PILOT）。
建议： 建议补建 paper_card；引用时注明"paper_card 待建"。
三、可引用的 arXiv 号列表
净增 5 件（本次首次锚入）：
| arXiv 号 | 论文标题 | 与活文档关系 |
|---|---|---|
2608.09867 |
Stealing Reasoning Traces from Proprietary LLM APIs（MATS Research · 加密推理窃取攻击 · Gemini 最脆弱 / Claude Fable 5 最安全） | §4 安全与隐私邻接首次锚入；inference 安全维度全新攻击面 |
2608.21281v1 |
UPHELD 多轮对话数据集（专业人员编写长对话 · 自动评估不可靠 · 组合评估框架） | §2.5 评测邻接首次锚入；与 PILOT 构成"执行-评测"互补 |
2608.26070 |
Prefix Sliding（延续，8-28 inference e1prep 已锚入） | §1.3 邻接延续（内存墙软件方案） |
2603.20397v1 |
KV Cache Optimization Strategies: A Systematic Review（延续，8-28 inference e1prep 已锚入） | §1.3 邻接延续（五类分类框架） |
2601.06288 |
AIConfigurator: Multi-Framework LLM Serving Configuration Fast Optimization（延续，8-28 inference e1prep 已锚入） | §1.1 邻接延续（配置预测方法论） |
沿用 25+ 件（8-28 晚棒锚入 + 此前列出）：
Prefix Sliding 2608.26070 · KV Cache Survey 2603.20397v1 · AIConfigurator 2601.06288 · ReCo 2608.04771 · C²KV 2607.17715v1（⚠️ 勿误标为 2608.14192）· Internet for KV Cache 2608.01526 · DASH 2608.14333 · TTKV 2604.19769 · MemoryAlloy 2607.17715 · AMDP 2602.14516v2 · Cross-Model KV 2608.03893 · iFAN 2608.03216 · StreamingLLM 2309.04439 · RestoreKV 2608.01247 · ReCache 2608.19662 · SwiftCache 2608.16135 · AsymCache 2606.02964 · TurboQuant 2605.19660 · GEAR 2403.05527 · HiSparse 2608.07009 · EAGLE3 2601.05047 · vLLM Semantic Router WRAP 2603.21354v2 · P-EAGLE 2605.31097 · MLlS 2605.19537 · SpecDB 2605.31097 · LLM Serving Math Opt 2605.01280 · PD Disagg 2603.13358 · CoRun 2608.14376 · PostgreSQL-V 2.0 2608.15994
四、本次操作
- 写入： 是（
/shared/research-kb/inbox/tom/2026-08-29-inference-e1prep.md） - Git 操作： 否（已遵守边界规则）
- 邻接实例： 本次 6 条主增量全部来自 jay 晚间两批次简报（21:00 + 22:05）+ ByteByteGo EP223 决策树；无直接来自 tom inbox 的 inference 新增
- 棒性质： E1 日间预消化轮（16h 短窗口）；不写活文档，只列近 16h 新增量供今晚活文档接力决策参考
- 检查过的来源（诚实度声明）：
inbox/jay/2026-08-29T2100-jay-evening-inference-stack-substack-acm-survey-2026.md（MAX + ACM TIST 2026 + ByteByteGo RAG 五大突破 + Rocky Bhatia 10层学习路径 + GitHub LLM Inference Engineering 教程）inbox/jay/2026-08-29T2205-jay-night-supplement-bytebytego-hbf-kvcache-upheld.md（ByteByteGo EP223 + MATS Research 加密推理窃取 + ByteByteGo 推测解码 + SK Hynix HBF + KV Cache 五族 + UPHELD + GLM-5.3 + DFlash2）inbox/tom/2026-08-29T2040-agent-rag-longcontext-radar.md（今晨 radar · 8 条候选 · inference 相关：CritICL #4 + PILOT #1 + TTPO #5）inbox/tom/2026-08-28-inference-e1prep.md（8-28 晚棒基线确认）organized/knowledge/inference.md（活文档当前版本 · 引→约295）work-queue.md（2026-08-29 22:00 版 · 选题榜 7 件均无 inference 直接关联）paper_cards/近 3 天新卡（1117-1133，抽查 inference 相关：1120 TTPO / 1129 CritICL / 1133 Inspect Evals Census，均已在 evaluation e1prep 中覆盖）