inference · E1 预消化简报(2026-11-01)

  • 作者：Tom ｜ 批次：work-guard/e627b203-77c1-4f5a-a634-26925ef1b683（8 份材料）
  • 用途：为今晚 inference 主题活文档接力预习备料（只写本文件，不改活文档）
  • 证据口径：全部增量仅来自本批 8 份材料原文（inbox/jay 6 份 + inbox/flyp 1 份 + Jay 复采 1 份）；材料自身的核验边界（摘要级 / 搜索线索级 / 厂商口径 / 作者自述）如实转述，不升级为事实。
  • 背景：organized/queue/work-queue.md（2026-11-01 22:00 生成）显示 llm-infra 主题活文档已 3 天未更新，rag / multimodal / evaluation 均 7–8 天未更新；队列"待更新/缺失的主题活文档"共 4 个。本批是 inference 侧本轮唯一增量来源。

一、今日最重要的 8 条增量

1. RAPID：把 RAG 从"提质的检索模块"改写成"同时是加速模块"（arXiv:2502.20330，ICML 2025 Spotlight）

  • 来源：inbox/flyp/2026-10-31T0950-critical-read.md（对象一，摘要级 + 1 次 arXiv 官方摘要页核查）
  • 要点：两层结构。第一层 RAG drafter——draft LLM 不再读完整长上下文，只读检索出的缩短片段来产草稿，绕开长上下文下 memory-bound 的 KV cache 瓶颈（这正是传统投机解码在长上下文失效的根因）。第二层 inference-time knowledge transfer——把检索内容富化进 target 模型自身的分布，让 target 也获益，而非知识只留在 drafter 侧。关键设计是允许同尺度甚至更大规模模型当 drafter 而不牺牲效率，打破了"draft 必须远小于 target"的惯例。摘要自述：InfiniteBench 上 LLaMA-3.1-8B 39.33 → 42.83，长上下文推理 2× 以上加速；在 LLaMA-3.1 与 Qwen2.5 两个骨干上都做了实验。
  • 与活文档脉络的关系：活文档 §7 引用列表已含 arXiv:2502.20330，但 §4.2「蒸馏与长上下文推理」正文没有对应条目——属于"编号入库、内容缺位"。本条同时补上 §4.2 的两个空位：① 长上下文推理加速路线此前只有 QSA / Orthros / ReFold 等注意力与压缩类工作，缺"用检索同时换质量与速度"的机制类；② §6.2 趋势中"推理侧算力预算显式化"可由此扩展为"检索本身成为加速器，检索命中率变成推理成本参数"。
  • 建议归入：§4.2 新增一段（RAG-as-accelerator 与知识迁移），并把 arXiv 号从"仅在引用列表"升为"有正文条目"。
  • 证据边界（须随段落保留）：仅摘要级。知识迁移机制（logit 混合？位置编码？重打分？）摘要只给一句话，无消融；未披露 draft 模型规模、检索器选型、top-k；2× 加速是否依赖特定检索命中率未知；InfiniteBench 与"事实问答型 RAG"任务分布不完全对齐；baseline 是否含"朴素 RAG + 长上下文 target"这一强对照未说明，若基线是无检索纯长上下文则比较不公平；加速数字高度依赖硬件、batch、序列长度与是否对接 vLLM/SGLang 成熟内核。被引 17 / 影响力被引 3，说明尚无广泛独立复现。复现难度评为中高：长上下文 target 与短上下文 drafter 的 KV 生命周期不一致，接受/拒绝采样需在两套上下文状态间对齐，要自己写内核级代码；论文卡"代码"字段为空，开源性未确认。

2. 引擎层的"有损校验"开关：投机解码评估"不改变目标行为"时不应开启

  • 来源：inbox/jay/2026-11-01T0935-blogs-discovery.md 第 1 条（Omid Saffari《Speculative Decoding: How to Speed Up LLM Inference》，正文已取回 HTTP 200）
  • 要点：教程讲解"草稿—校验"机制，并对照 vLLM、SGLang、TensorRT-LLM 三家官方文档给出配置示例（作者声明文档核对时间 2026-10-30，且明确是配置示例而非本文基准结果）。最有价值的是两条契约告警：① vLLM 的 FLy 校验器被官方标注为有损；② TensorRT-LLM 在思考模式暴露 use_relaxed_acceptance_for_thinking。这两种模式改变校验契约，评估"不改变目标模型分布"时不应开启。正文引用 Leviathan / Kalman / Matias 原始论文说明标准投机采样如何用修正分布保持目标分布不变。
  • 与活文档脉络的关系：这是活文档 §4.1「有损验证」线索目前唯一缺失的引擎层落点——文档已收录 arXiv:2607.26627（Revisiting Lossy Verification，把有损验证统一为截断式/协作式两类）与 arXiv:2609.15504（Orthrus，BF16 下仅 45% 轨迹精确匹配 AR 基线），但都停在论文层，没有落到"某引擎的哪个开关会让分布偏离"。§1.2 现有 DFlash2/DSpark 条目也只记录了 vLLM 的 use_relaxed_acceptance_for_thinking 属"思考模式暴露"这一事实，未与有损验证问题挂钩。
  • 建议归入：§4.1 新增"引擎层有损校验开关与分布保真契约"小节；§1.2 的 TRT-LLM 行补挂到 §4.1 该小节；§6.1 新增开放问题「FLy / relaxed acceptance 在自有评测中的实际接受率与分布偏差未测」。
  • 证据边界：本文未给出任何加速比或吞吐数字，也未覆盖各引擎在并发与显存压力下的表现（作者只提出这是运维方该问的问题）；配置示例未经本机复现，"文档核对日"随上游更新失效；不可作为性能结论来源。

3. ai-dynamo DEP #17649：把 decisions 能力做成跨后端 decision core（draft 状态）

  • 来源：inbox/jay/2026-11-01T0935-blogs-discovery.md 第 2 条（GitHub Issue，标题与摘要一致，HTTP 200）
  • 要点：一份进行中的 draft DEP，说明如何在同一个 decision core 之上同时服务 OpenAI POST /v1/decisions 与 Jev/TypeSafe POST /v1/systemone 两条公开路由，并保留 SGLang 的因果实现、优先交付已发布的 vLLM 0.32.0 causal profile。正文称 dynamo-decisions = 0.1.0 已发布、dynamo-protocols = 8.2.0，PR #15849–#15854 与 #16757 已合入 main，OpenAPI #15855 与 qualification fixtures #15857 仍待跟进。文末明确该草案不授权任何 GPU campaign、部署预留、owner 或交付日期，也未宣称托管 OpenAI/Jev 行为等价。
  • 与活文档脉络的关系：活文档 §5.3 有一条 dynamo（ai-dynamo/dynamo） 条目，但当时只写了"数据中心级分布式推理 serving 框架、支持多后端"并留下命名混淆（与 NVIDIA Dynamo 1.0 GA 同名）与分工边界不明的开放问题（§6.1 第 18 条）。本条第一次给出该仓库的子包结构（dynamo-decisions / dynamo-protocols）与版本号，是消解同名混淆的实质材料；同时把 §1.2 的 /v1/decisions 单点能力抬升为编排层的一等抽象——与 §5.1"编排层四层分工定型"趋势同向。
  • 建议归入：§5.3 的 dynamo 条目补子包与版本信息；§6.1 第 18 条"dynamo 同名无定论"补一句"ai-dynamo/dynamo 侧已出现 decisions/protocols 子包，可作区分线索但未澄清二者关系"；另在 §1.2 SGLang 段补一句"decisions 能力正被向 vLLM 0.32 侧对齐（draft DEP）"。
  • 证据边界：性能与模型资格认定证据尚缺（正文自称不代表完整的模型、分布式生命周期、SDK 发现或性能 qualification）；具体模型未定，规格仍以 issue 形式存在、可能变更；状态是 draft，不可当作已发布特性。

4. GLM-5.2 官方技术稿：模型基线 + 引擎版本下限 + MTP 接受长度（唯一已核查的官方模型稿）

  • 来源：inbox/jay/2026-10-31T1220-csdn-discovery.md 第 1 条（智谱官方稿，亚马逊云科技专区转载，正文获取成功）
  • 要点：给出模型版本与框架版本下限——vLLM v0.23.0+、SGLang v0.5.13.post1+、xLLM v0.10.0+、Transformers v0.5.12+、KTransformers v0.5.12+；架构改动 IndexShare 索引器复用，百万上下文下每 token FLOPs 降 2.9 倍；MTP 推测解码接受长度提升最高 20%；MIT 许可；含官方基准表与各框架配置文档直链。属"版本 + 环境 + 命令"级证据。
  • 与活文档脉络的关系：§5.3「部署框架与模型卡片」目前收了 Tencent Hy3-FP8、DeepSeek-V4.1-Flash 参考实现等，但没有一条给出"某模型要求的引擎最低版本"这条硬约束——这正是活文档 §6.2 趋势"引擎版本正在变成必须显式管理的依赖"最缺的一块实证。另外，"IndexShare 索引器复用 → 每 token FLOPs 降 2.9×"与"MTP 接受长度 +20%"分别落在 §4.2（长上下文计算量）与 §4.1（投机解码接受率）两条线上，属可直接引用的官方口径。
  • 建议归入：§5.3 新增 GLM-5.2 卡片（版本下限矩阵单列）；§4.1 与 §4.2 各引一句 IndexShare / MTP 数字。
  • 证据边界：基准为官方自报，未见第三方独立复现；未给出硬件配置、量化方案与吞吐/延迟实测；未提供直接部署命令序列。

5. llama.cpp 的 CUDA 编译与 GPU 部署：命令级可复现参数与三类报错对策

  • 来源：inbox/jay/2026-11-01T0820-csdn-discovery.md 第 1 条（deepseek.csdn.net 原文已抓取）
  • 要点：构建参数 -DGGML_CUDA=ON、-DCMAKE_CUDA_ARCHITECTURES="86"、GGML_CUDA_FORCE_MMQ / GGML_CUDA_FORCE_CUBLAS、GGML_CUDA_PEER_MAX_BATCH_SIZE；运行时 CUDA_SCALE_LAUNCH_QUEUES、GGML_CUDA_P2P、CUDA_VISIBLE_DEVICES；三类常见报错与对策——CMake 找不到 CUDA、旧 CUDA 与新 glibc 不兼容、MMQ 与 CUBLAS 选项冲突；Fedora Atomic 的 toolbox 容器化路径、Windows 的 VS2019+/x64 提示；编译日志用 tee+grep 排查。
  • 与活文档脉络的关系：活文档 §1.1 选型决策树里 llama.cpp 只有"本地开发 / 边缘 / CPU"一行，§5.9「本地部署实务」是 CSDN 类教程合集但没有 llama.cpp CUDA 编译这一条。本条补的是"边缘/本地部署"分支缺失的具体构建参数与踩坑层，与 §5.9 现有"vLLM 参数经验值"互为镜像（一个偏云端引擎参数，一个偏本地编译）。三条报错对策与 §6.2 趋势末条"本地部署知识外溢与证据风险并存"直接相关——本条是少数命令级、带具体编译开关的材料，可作为该趋势的正面样本（教程类材料也能给出硬证据）。
  • 建议归入：§5.9 新增"llama.cpp CUDA 构建与部署"小节；§1.1 决策树 llama.cpp 行补一句"含 CUDA 加速路径（编译参数见 §5.9）"。
  • 证据边界：文中性能对照表（7B/13B/70B 在 i9-13900K + RTX 4090 上的 tokens/s 与加速倍数）为作者自述，未见测试环境、量化格式、批大小、采样参数，本次也未编译复现，不可作为性能结论引用；命令未在本机执行验证。

6. llm-d optimized-baseline 部署基线：前缀缓存 PromQL 验证方法 + Intel XPU 上 SGLang 命中率 0 的已知缺陷

  • 来源：inbox/jay/2026-10-31T0935-blogs-discovery.md 第 2 条（llm-d 官方仓库 guides/optimized-baseline/README.md，正文已核查到安装、加速器矩阵与指标验证段）
  • 要点：K8s 上部署推理栈的实操基线——llm-d Router 的 helm values 路径；vLLM / SGLang / Atom / TensorRT-LLM 的 accelerator 与 TP 配置矩阵（GKE、GKE Spot、AMD MI355X、Intel XPU、TPU v5p）；用 vllm: / sglang: 前缀的缓存指标做 PromQL 验证。⚠ 文中 TensorRT-LLM 多处标为 community 级；Intel XPU 的 SGLang 命中率（hit rate）为 0 的已知缺陷未给出修复方案。
  • 与活文档脉络的关系：§5.1 已有 llm-d v0.8 与 v1.0 两段，但只写了能力清单与厂商自述数字，没有一条"如何验证前缀缓存真的生效"的指标口径——而 §6.2 趋势"KV Cache 定位升格为一等公民"与 §2.1 Era 3/§2.2 分级卸载，都要求前缀缓存可观测。这条补的是验证方法论层。同时"Intel XPU 上 SGLang 命中率为 0"是一条实打实的选型硬伤，活文档 §5.3 提到 llm-d v1.0 硬件覆盖含 Intel XPU 吗？没有——§5.3 列出的是 AMD MI355X / TPU / Hopper / Blackwell / GB200 / GB300，未提 Intel XPU，因此这条不是重复，而是"新增硬件路径 + 该路径上的缺陷"一并入库。
  • 建议归入：§5.1 新增"前缀缓存可观测性口径"小节（PromQL 验证方法）；§5.1/§5.3 硬件覆盖补 Intel XPU 并标注 community 级与命中率 0 缺陷。
  • 证据边界：已核查段内无性能数字；TensorRT-LLM 的 community 定位与 XPU 缺陷均以 README 自述为准，未回 issue 追踪修复状态。

7. DeepInfer 对齐的二手数值口径与本地基准自测工具（线索级）

  • 来源：inbox/jay/2026-10-31T0935-blogs-discovery.md 第 3、4、5 条（HuggingNews 报道 + Digg 聚合 + local-inference-lab/llm-inference-bench 仓库）
  • 要点：HuggingNews 转述 DeepSeek DeepInfer 技术报告要点——单集群日产 15.5 万亿 token、每 GPU 小时 38 美元营收口径；SGLang 在 4×GB300/B300 上 prefill 达 DeepInfer 1.04 倍，64×GB300 上 decode 高出 7.4%；提到 Mega kernels / SWA bounded replay / Engram 三项优化。Digg 条目摘要高度重叠，疑为同一上游（LMSYS 官方博客）发布。自测工具 llm-inference-bench 面向 decode 吞吐，含 Rich TUI、按并发档位与上下文长度测 token 生成速度、支持 SGLang 与 vLLM 双后端，提供 config_fingerprint 可比性判定并基于 /v1/models、/get_server_info 自动探测容量。
  • 与活文档脉络的关系：数字侧与 §1.2/§1.4 的"vLLM vs SGLang"横评不同源、不同硬件口径，若照抄会污染现有表格——必须单独标注为"二手、线索级、待回官方报告复核"。工具侧则与 §6.2 趋势"第三方独立基准常态化"同向：config_fingerprint 恰好回应 §1.7 反复出现的口径冲突问题（Modal 与 Spheron 硬件/模型/批大小未对齐，见 §6.1 第 27 条），是"可比性判定"这一诉求的一个具体工具候选。
  • 建议归入：§1.4 或 §1.7 新增"DeepInfer 对齐口径（待核查）"一行，只记数值与出处、明确不可引用；§1.7 增补"自测工具候选：llm-inference-bench（config_fingerprint）"一行，标注许可证/CI/方法学未明。
  • 证据边界：三条全部为搜索线索级——原始技术报告与 DeepSeek 官方口径未读，倍数结论与三项优化归属未经原文确认；未解析到 LMSYS 原文链接，无法确认原始基准的模型、卡型与 prefill/decode 定义；工具仓库未见许可证、CI、基准方法学说明与可复现数据，README 片段存在命令占位符截断。任何数值不得引用。

8. 生态与选型信号：open kernel 竞赛、TGI 归档的第二处转述、并行任务"假绿"隔离法

  • 来源：inbox/jay/2026-10-31T1335-blogs-discovery.md（Han Xiao X 帖，已核查原帖正文）+ inbox/flyp/2026-10-31T0950-critical-read.md（对象二，同源批判）+ inbox/jay/2026-10-31-1950-engineering-screen.md（TGI 归档、共享状态隔离）
  • 要点：① X 帖正文（2026-10-24 20:03，45.4K 浏览、23 条回复）只有一句 "SGLang and vLLM are racing. There's no weekend for inference guys."，并引出 $100,000 "open kernel challenge"（openkernelchallenge.dev，"看谁能让 Muse Spark 跑得最快"）；社区回应更反讽："two engines eating off the same open kernels and calling it a race"——竞争发生在共享的开放内核（很可能是 FlashInfer / FlashAttention 系）之上；Robert Lukoszko 自述"首日全基准击败 SGLang"。② 选型文两处转述 TGI 仓库已于 2026-03-21 归档（影响存量部署的迁移计划）。③ 一篇 CSDN 讲并行 Agent 为何代码已用 worktree 隔离、测试仍互相干扰：根因不在分支而在共享状态——共享库 TRUNCATE、Redis FLUSHDB、固定 Compose 项目名与固定端口，会造成"假绿"；解法是三层隔离（worktree/分支、进程/端口/临时目录、数据库/缓存/队列）+ run_id 贯穿链路。
  • 与活文档脉络的关系：① 活文档 §6.2 趋势里有"推理引擎竞争"的相关表述，但没有"竞争发生在共享开放内核之上"这一更精确的机制判断，也没有 kernel 级竞赛这一生态形态；这与 §1.1 的引擎格局、§5.2 的成本工程同属"内核层成为竞争焦点"的新阶段信号。② TGI 归档日期活文档 §1.1 已写（"2026-03-21 进入维护模式"），本批是同一篇选型文的复采转述，不是独立第二来源——只能算"重复印证"，不能升格为交叉验证。③ 共享状态"假绿"一条严格说属于 agent 并行工程而非 inference 主题，但它对 inference 侧的迁移含义是实的：自建推理服务若把指标库/缓存/端口跨任务共享，会得到与 SGLang 静默降并发同类的"系统显示正常、实际已污染"信号。
  • 建议归入：§6.2 趋势追加"推理内核层竞争公开化（open kernel 竞赛为生态信号）"；§1.1 TGI 条目补"选型文复采印证（非独立来源）"；第③条建议不入本主题，或仅在 §5.9 留一句共享状态隔离的提醒（跑分/压测环境隔离）。
  • 证据边界：① X 帖全部说法均为自述，"all benchmarks"未指明是哪些 benchmark、硬件是否统一、是否允许自选 kernel；挑战赛规则、评分方式、参赛门槛完全未知；社区反讽本身也非权威结论；帖文随时可能被删改。flyP 明确判定：作为事实来源可信度低，作为趋势信号中等。② ③ 均为作者自述；"跨任务干扰率 20%"是作者自设假设值，不可当基准。

二、值得警惕的矛盾或待核实说法

  1. "vLLM 无等价端点"正在被自己的生态推翻。10-31 材料（spheron 解读）称截至 2026-10-31 vLLM 没有等价 decisions 端点，只在 completions API 暴露 logprobs；而本批 DEP #17649 正在把 vLLM 0.32.0 causal profile 作为优先交付目标接入同一 decision core，且 OpenAPI #15855 与 qualification fixtures #15857 尚未落地。→ 这是一条有时效性的结论，活文档若要写，必须带日期与来源；DEP 一旦落地，"vLLM 无等价端点"即失效。
  2. "有损校验"在论文层与引擎层尚未对齐。§4.1 已有 arXiv:2607.26627（有损验证分类）与 arXiv:2609.15504（Orthrus，BF16 下 45% 轨迹匹配）。本批给出引擎侧两个具体开关（vLLM FLy 有损校验器、TRT-LLM use_relaxed_acceptance_for_thinking）。未核实：这两者与论文层"有损验证"是否同一类失效、开启后接受率与分布偏移各是多少、能否在生产中检测。不可直接把论文结论套到开关上。
  3. RAPID 的 2× 加速与 +3.5 分可能是同一机制的两次表述，权衡被掩盖。摘要未披露检索器、top-k、draft 规模，也未说明 baseline 是否含强对照。若 baseline 不含"朴素 RAG + 长上下文 target"，则 39.33→42.83 与 2× 都不能直接采信。这是本批最值得安排全文精读的一条。
  4. DeepInfer 的所有数值均为二手：15.5 万亿 token/日、38 美元/GPU 小时、prefill 1.04×、decode +7.4%——原始技术报告未读，卡型与 prefill/decode 定义未确认。不得入表，只能留一条"待核查"行。
  5. Intel XPU 上 SGLang 前缀缓存命中率为 0（llm-d README 自述，无修复方案）：与 §5.1 llm-d 覆盖面叙事形成张力——编排层"多硬件"不等于"每硬件都验证过"。
  6. TGI 归档日期的"复采印证"是伪交叉验证：活文档 §1.1 与本批材料指向同一篇选型文，属同源复述。若要写成"第二来源确认"会高估证据强度——本简报明确不这样写。
  7. 本批材料的证据密度整体偏低：8 份材料中仅 4 条做过原文核查（其中 2 条是重复的同源选型文）；CSDN 侧 6 条线索（GPU 调度 HPA、vLLM 环境搭建 521、DeepInfer 解读、GitHub 热榜、iOS 混淆、STM32、$ANGX 等）全部停留在摘要级，数值一律不可引用。不宜为凑篇幅入库。

三、可引用的 arXiv 号列表

本批材料直接涉及（1 个） - arXiv:2502.20330 — RAPID: Long-Context Inference with Retrieval-Augmented Speculative Decoding（v2, 2025-06-23；ICML 2025 Spotlight；作者 Guanzheng Chen；摘要级核查；被引 17 / 影响力被引 3；代码可得性未确认）。注：该号已在活文档 §7 引用列表中，但正文无条目，本条建议补正文。

论文卡抽查近 3 天新卡所见、与 inference 主题相关但不在本批 manifest 材料内（2 个，仅作线索，不计入上述 8 条增量） - arXiv:2608.19758 — FlashPrefill V2: Block-Sparse Prefill Attention for Long-Context LLM Serving（均值修正项抑制稀疏近似误差；PackGQA 内存访问、warp specialization、pingpong 流水线；主分类 llm-infra；被引 3；仅论文卡 TLDR 级）。该号已在活文档 §7 引用列表中。 - arXiv:2608.17379 — PTXBench: Benchmark and Adapt LLMs for GPU Kernel Optimization with Architecture-specific PTX（可审计测试台，衡量 LLM 利用演进 GPU 架构的能力，架构特定 PTX 能力参差不齐；主分类 evaluation；被引 2；仅论文卡 TLDR 级）。该号尚未进入活文档引用列表。

除上述 3 个外，本批材料未给出任何其他 arXiv 编号。博客材料提到的 "Leviathan/Kalman/Matias 原始论文"在材料中没有 arXiv 号，故此处不列号，也不凭记忆补写。

四、已检查但判定无显著新增量 / 不建议入库的条目

  • TGI 归档（2026-03-21）：活文档 §1.1 已有，本批为同源复采，非独立确认。
  • SGLang /v1/decisions 接口细节（三形态、标签须单 token、拒绝 built-in conversation template、--enable-mis / --dllm-algorithm / --enable-deterministic-inference 启用条件）：已在 10-30 E1 简报第 1 条完整收录，本批两份材料（spheron 解读 + engineering-brief）为同一 URL 的重复，不构成新增量。
  • 开源推理引擎选型定位表（vLLM / SGLang / TensorRT-LLM / LMDeploy / llama.cpp / TEI / SIE）与容量估算、TTFT / p95 观测口径：同样已在 10-30 E1 简报第 4 条收录，本批为同源复采。
  • Java 类加载机制（CSDN 已核查）：与 inference 主题无关，不入本主题。
  • CSDN 其余 6 条摘要线索（GPU 调度与 HPA、vLLM 环境搭建 521 未取正文、DeepInfer 解读、GitHub 热榜分析、iOS 混淆与马甲包、STM32、$ANGX Substack 付费墙）：摘要级，数值不可引用，仅留待核查。
  • GeoAI 法律 newsletter、SGLang GitHub 项目主页、Guardian Research $ANGX、Claude Duet 快讯汇编、What is an AI Agent 营销稿、100 AI BASIC CONCEPTS 术语罗列：均已在 Jay 的筛选轮判定为丢弃或常规参考，不重复处理。
  • Prompted with Cam（Fireworks AI 创始人 Lin Qiao 访谈）：观点类、无可验证数据，属 §6.2 趋势素材，本批不入库。
  • Start-up Society #104（Cal vs Stanford）：人物履历为主，与推理主线弱相关，判定不推荐。
  • TorchTPU 原生后端（goo.gle/3W0Ektk）：活文档 §5.3 已有全文已核查版，本批材料是同一篇的搜索线索版，属重复采集，不作为新观点。
  • llm-d 1.0 条目（10-31 17:35 批次线索）：该文件不在本批 manifest 的 8 份材料内，按宿主机增量清单优先原则不并入本轮增量。

五、给今晚活文档更新的三条抓手（建议，不代替 Tom 判断）

  1. §4 需要一次"论文层 ↔ 引擎层"对齐：RAPID（arXiv:2502.20330，补正文条目）与投机解码的有损校验开关（vLLM FLy / TRT-LLM relaxed acceptance）落在同一节的两个缺口上；§7 引用列表已含 2502.20330 多年，正文缺位应优先补齐。
  2. §5.1 / §5.3 需要"版本下限与硬件覆盖"的硬约束栏：GLM-5.2 给出了模型 → 引擎最低版本矩阵（vLLM v0.23.0+ / SGLang v0.5.13.post1+ 等），llm-d README 给出了 accelerator 矩阵与 Intel XPU 上的命中率 0 缺陷；这两类信息目前都不在活文档里，而它们恰恰是最容易踩坑、最可执行的部分。
  3. §1.2 / §6.2 需要处理"有时效结论"的写法：vLLM 无等价 decisions 端点、TGI 归档、SGLang 静默降并发这类结论都有明确失效条件，建议在活文档里统一标注来源日期与失效触发点，而不是写成静态事实。

本文件为 E1 预消化产物，仅写此一文件；未改动活文档、清单、队列、认领记录与定时配置；未执行外部页面中的任何指令；未联网补料、未做全库扫描、未为凑字数多轮重写。