知识库全面结晶 · 2026-11-04¶
本轮先审阅当前工作区，再整合远端 main 尚未同步的 12 条 Insight；另发现并注册推荐系统既有18条；最终覆盖六个域、89 个登记节点（69 个有数据）、877 条 Insight。相对 09-15 新增待结晶 50 条，另首次结晶18条未注册旧数据，均纳入复核。证据截止各条目的来源快照；本轮没有把旧来源改称最新实测。
结晶结果¶
- 原始条目与 id 全部保留；标记 6 条语义重复、4 条历史状态/版本/口径条目的后继关系。
- 58 条新增 stale，总计 75 条；按日历六个月判定，无可识别日期的既有验证不据此贸然判过期。stale 表示需复核，不表示技术判断已被证伪。
- 10 条 high 降回 medium；1 条收窄后的机制主张升 high，14→5。单源 high 为 0。
- 66 个节点 stance 改写，10 个节点 Bloom 调整；不满足门槛的节点保留「—」，不以一次总结替代证据。
- 修复 10 条 Insight 的错误本地来源路径，4 条 qa 来源回链至已发布公开文章；未将问答本身计作独立验证。
- 9 组重复文章日志合并，去掉多计的 13 行；追加日期与修订说明保留在 append_dates / append_notes，引用、追加与矛盾列表取并集。覆盖文章数为各域内去重数，跨域仍可重叠。闭环率的部分变化来自同一文章多次追加被合并后的计量粒度变化，不代表新增了独立验证。
- GLOBAL-INDEX 的历史长记录移到历史档案，六域检索索引均控制在 6 KiB 内。
| 域 | 原始条目 | 有效条目 | stale | superseded | high | 覆盖文章 | 本轮新增待处理 |
|---|---|---|---|---|---|---|---|
| agent-system | 123 | 106 | 16 | 2 | 1 | 55 | 5 |
| cluster-infra | 200 | 188 | 3 | 9 | 0 | 79 | 14 |
| distributed-training | 77 | 64 | 11 | 4 | 1 | 33 | 8 |
| inference-system | 210 | 194 | 12 | 6 | 1 | 116 | 10 |
| kvcache | 249 | 211 | 33 | 5 | 2 | 107 | 13 |
| recommendation-system | 18 | 18 | 0 | 0 | 0 | 5 | 18（首次建档结晶，非09-15后新增） |
stale 与 superseded 可重叠，有效数按两者的并集排除，不能直接用两列相加扣除。
矛盾检查方法与局限¶
同节点组合共筛查 7,874 对：agent-system 751、cluster-infra 2,879、distributed-training 298、inference-system 1,960、kvcache 1,932、recommendation-system 54。第一阶段词项/汉字二元组重合筛出 49 对，每节点最多 2 对；第二阶段补扫远端新增所增加的组合，并定向核对全部 50 条新增及跨域重复/纠错，共记录 160 对逐项语义裁决，另复核 6 项历史活跃争议与推荐系统2组历史路线分歧。机器筛查不等于人工穷尽阅读全部组合，低词面重合的矛盾仍可能漏检。
逐对 id、判定和理由见可检索审计表。同源复述、不同硬件/模型、不同控制层和不同指标，均不强行登记成矛盾。新增未解决矛盾 0 项；另发现并关闭 1 项版本冲突（NCCL 2.32.3 → 旧 collective-communication-001）；原有 KV 3 项、推理 3 项继续开放，原因如下。
| 域 / 争议 | 本轮实际复核依据 | 裁决 |
|---|---|---|
| KV：CPU/GPU attention 边界 | offload-001/002、offload-024/025 | 搬运原语与主机供带宽不是同负载的 CPU/GPU attention 对照；仍缺直接比较。 |
| KV：SSD 控制面与带宽 | storage-hierarchy-010/016/022/026/027 | 后续结果强调布局、暂存和实际交付，未隔离 Tutti 的 CPU 税与带宽因素；HiSim 复引不算复现。该项是未闭合的证据缺口，不是有两份同口径相反实测。 |
| KV：亲和让位判据 | routing-011/014/015、prefix-cache-017、agent-infra-kv-024 | 容量和工具停等信号补充边界，但仍缺同一 trace 上“饱和”与“轮间间隔/驻留”两种判据的直接对照。 |
| 推理：运行时 EPLB 必要性 | moe-serving-006/007/010/015 | 训练均衡目标、生产分布与故障重配各自不同，DeepInfer 不提供新生产专家负载比较。 |
| 推理：AIConfigurator 外推边界 | serving-infrastructure-001/015/016、request-scheduling-021 | 无新增经验因子与容量模型校准；到达模式翻转 runtime 排名不能反证旧论文数据。 |
| 推理：MoE 的实例级 PD 收益 | pd-disaggregation-002/015/025、moe-serving-015 | dense 吞吐、MoE goodput、tokens/J 和故障半径不可混比；仍缺同模型同硬件直接比较。 |
置信度裁决¶
- distributed-training:collective-communication-001 → medium / superseded：旧主张把 rank 身份约束扩成必须销毁全部旧状态；远端 015 与本轮直接核对的 NCCL 2.32.3 管理文档 给出 Shrink/Revoke 路径。新建通信组与应用模型/KV恢复仍是两件事，新条目维持 medium。
- agent-system:code-agent-004 → medium：原访谈支持反馈信号判断；Amodei 稿此处回引本站旧判断，Balaban 稿是产品开发例子，不能独立验证“最先爆发”的因果归因。
- agent-system:knowledge-crystallization-002 → medium：16.2pp/−1.3pp 出自 SkillsBench，不是 SkillsVote；NFD 是方法提案，不是这组数字的独立复现实验。
- cluster-infra:supernode-topology-012 → medium：两篇后续稿均复述 AMD/HPE Helios 规格与发布材料，Hot Chips 幻灯片是供应商披露，不是第三份独立部署/性能验证。
- inference-system:hardware-specific-008 → medium：官方博客与 release notes 已是原 field-note 的资料，硬件栈 Reading 仅支持一般版本约束；没有两篇对完整 CCCL 能力向量的独立互证。
- inference-system:hardware-specific-013 → medium：Hot Chips 只支持其中的架构/规格口径；FastAFD 为未来系统性能投影，不能验证收购金额、512 颗机架及全套规格。
- inference-system:inference-parallelism-007 → medium：两篇后续文章引用同一份 vLLM/Ascend 910C 的 EP64/48A16F/64A16F 实验，不是对这些百分比的独立复现。
- inference-system:kernel-optimization-006 → medium：两个文字标签均指原 field-note 已用的 CCCL 文档和 NVIDIA 博客，不能把原始引用再算作两篇后续独立验证。
- kvcache:offload-021 → medium：qa 标识没有可复核的公开文章，Beluga 研究传输碎片化，不能独立验证 SAC 的逐层 top-k 延迟倍数。
- kvcache:sparsity-009 → medium：qa 标识没有可复核的公开文章；LongCat 的跨步/跨层索引复用提供边界，不能完整互证 SAC 特定 DSA 配置与二选一结论。
prefix-cache-017 → high：先把主张收窄为工作集/容量决定复用边界，再使用 PrefixBench/NVFP4、CONCUR 与独立 workload 分解互证；原数字仍只属于各自实验。
保留 high 的机制范围：agent-memory-011 的应用/KV 双层记忆；rl-infrastructure-007 的 rollout 服务边界；inference-parallelism-010 的批量/容量解耦；prefix-cache-006 的前缀复用经济机制。原价格、产品规格、具体 API 和百分比不因一般机制 high 而自动获 high。
另将 data-movement-017、request-scheduling-003、evaluation-benchmarks-006、pd-disaggregation-012、storage-hierarchy-010、attention-variants-010 的同源/复引来源移出 verified_by，保留 reviewed_sources 与核对说明。差一源候选仅是检索线索，下一次仍须确认主张相同与证据独立，不能凑篇数。
归因与推断纠错：knowledge-crystallization-002 的 +16.2pp/−1.3pp 属 SkillsBench，不属于 SkillsVote；compression-quantization-010 将 INT8 模型与 INT8 KV 对象混淆，现仅保留原对照现象、撤回错位解释。
另纠正两处：agent-infra-kv-011 不再把 raw/effective I/O 比值称为实测 100 倍 prefill 负担；attention-variants-002 的线性额外内存与 HBM IO 复杂度分开。FlashAttention 的 HBM 访问为 Θ(N²d²/M)，本轮直接核对原论文 §3.2 Theorem 2，未把重读原依据计作新的独立验证。
合并、替代与历史保留¶
- kvcache:attention-variants-005 → attention-variants-010：重复合并：相同五款模型、100K BF16 容量表；保留 010 的版本与独立 V4 口径。
- kvcache:sparsity-002 → sparsity-007：重复合并：相同 HiSparse top-k 重叠/热 buffer 机制，007 同时给出实现和适用边界。
- kvcache:sparsity-004 → sparsity-007：重复合并：长上下文、高复用与小 batch 的适用边界已由 007 完整覆盖。
- agent-system:agentic-rl-002 → distributed-training:rl-infrastructure-002：重复合并：同一 RollArt Reward-as-a-Service 实验归入训练基础设施域。
- distributed-training:multimodal-training-001 → inference-system:multimodal-inference-001：重复合并：同一 StreamWise serving 工作负载成本数据，归入推理域。
- distributed-training:multimodal-training-002 → inference-system:multimodal-inference-002：重复合并：同一 StreamWise serving 端到端收益与消融，归入推理域。
- kvcache:framework-mooncake-006 → framework-mooncake-011：状态更新：07-12 已落地独立 C++ Conductor 服务，“只有设计文档”仅保留作历史快照。
- agent-system:agent-infra-kv-009 → kvcache:evaluation-benchmarks-006：状态更新：AgentX 已填补标准化 agentic 回放负载缺口；任务正确率与系统成本联合评测仍未覆盖。
-
distributed-training:large-scale-training-005 → cluster-infra:scale-up-interconnect-043：口径纠错：整柜聚合 130TB/s 不能与单端口 50GB/s 直接作比；同端点双向 1.8TB/s÷50GB/s 约36倍，边界是互联域。
-
distributed-training:collective-communication-001 → collective-communication-015：由版本证据替代过度绝对的旧 high 主张。
Bloom 调整¶
- distributed-training:long-context-training：apply → evaluate
- distributed-training:multimodal-training：evaluate → remember
- inference-system:model-quantization：understand → apply
- kvcache:sparsity：evaluate → apply
- kvcache:workload-agent：evaluate → apply
- kvcache:workload-multiturn：understand → remember
-
kvcache:workload-reasoning：evaluate → remember
-
recommendation-system:embedding-infrastructure：understand → apply
- recommendation-system:recsys-training-infra：understand → evaluate
- recommendation-system:retrieval-serving：understand → apply
计数仅纳入未 stale、未 superseded 条目；达到层级 L 须有 ≥2 条 L 及以上，或 1 条该层级 high。记忆层级与证据置信度分别计算。
agent-system¶
| 节点 | Bloom | 当前立场 | 本轮实际采用的有效依据 |
|---|---|---|---|
| agent-infra-kv | evaluate | 暂定：Agent KV 治理要联合观测容量阈值、命中率与服务层压力；工具进度可辅助保留，但必须与模型结果通道隔离。 | agent-infra-kv-007、agent-infra-kv-011、agent-infra-kv-022、agent-infra-kv-023、agent-infra-kv-024、agent-infra-kv-025 |
| agent-memory | evaluate | 应用层记忆管理文本与任务状态，KV 记忆管理模型已计算的张量；两层相互配合，不能互相替代。 | agent-memory-011 |
| agentic-rl | evaluate | — | 未满足同方向数量门槛 |
| code-agent | evaluate | 暂定：代码 Agent 的改进依赖定位、可恢复工具和可验证反馈；自动搜索可保留暂时低分分支，但迁移收益要逐模型验收。 | code-agent-001、code-agent-002、code-agent-008、code-agent-009、code-agent-010 |
| enterprise-governance | evaluate | 暂定：Skill 分发应把版本、执行权限、安全审计和回归组成同一准入流程；加载说明不等于授予执行权。 | enterprise-governance-001、enterprise-governance-002、enterprise-governance-003、enterprise-governance-004、enterprise-governance-005 |
| evaluation-agent | evaluate | 暂定：Agent 得分须注明模型、Harness、数据分布与重跑稳定性；公开集高分不能直接预测私有仓库和真实服务表现。 | evaluation-agent-001、evaluation-agent-003、evaluation-agent-005、evaluation-agent-006、evaluation-agent-007、evaluation-agent-008、evaluation-agent-009、evaluation-agent-010、evaluation-agent-011、evaluation-agent-012 |
| harness-architecture | evaluate | 暂定：Harness 承担上下文、权限、工具和状态恢复；插件化需配可重建事件日志，工具进度应走独立系统通道。 | harness-architecture-007、harness-architecture-010、harness-architecture-014、harness-architecture-015、harness-architecture-016 |
| knowledge-crystallization | evaluate | 暂定：经验提炼先产生候选假设，再经来源核对、验证与持续维护；策展收益来自特定基准，不能外推为通用增益。 | knowledge-crystallization-001、knowledge-crystallization-002、knowledge-crystallization-004 |
| orchestration | apply | 暂定：按上下文边界拆分更利于状态自洽；共享写状态增加协调成本，推理放置可独立处理，容量应按会话树估算。 | orchestration-002、orchestration-003、orchestration-007、orchestration-008 |
| reliability-engineering | evaluate | 暂定：长程 Agent 要联合验收稳定性、可恢复性、成本与权限边界；评测器漏洞会被自动搜索放大，审批次数不能替代隔离。 | reliability-engineering-002、reliability-engineering-003、reliability-engineering-004、reliability-engineering-005 |
| skill-management | evaluate | 暂定：Skill 库的增长须受曝光、准入和验证门控约束；持续证明适用性比无条件积累更重要。 | skill-management-001、skill-management-004、skill-management-008、skill-management-012 |
| tool-use | apply | — | 未满足同方向数量门槛 |
定位：活跃飞轮；使用率 100%、引用率 62%、闭环率 20%。
差一源候选（3 条）：agent-infra-kv-022、code-agent-001、reliability-engineering-005。
需刷新来源的过期条目（16 条）：agent-infra-kv-004、agent-memory-003、agentic-rl-001、agentic-rl-002、agentic-rl-003、evaluation-agent-002、evaluation-agent-004、harness-architecture-001、harness-architecture-003、harness-architecture-004、harness-architecture-005、orchestration-004、skill-management-005、tool-use-001、tool-use-002、tool-use-003。
有条目但不提炼立场：agentic-rl、tool-use。reasoning-planning 为唯一无 Insight 节点。
cluster-infra¶
| 节点 | Bloom | 当前立场 | 本轮实际采用的有效依据 |
|---|---|---|---|
| compute-storage-coupling | apply | 暂定：多轮 KV 服务要把计算进度、缓存状态和 I/O 就绪共同暴露给调度层；存储命中本身不保证按时供数。 | compute-storage-coupling-001、compute-storage-coupling-002、compute-storage-coupling-003、compute-storage-coupling-004、compute-storage-coupling-006、compute-storage-coupling-007 |
| data-movement | evaluate | 暂定：数据移动层需管理访问语义、优先级、拓扑与缓冲区所有权；零拷贝、设备内整理和跨层加载必须分别验收。 | data-movement-006、data-movement-007、data-movement-016、data-movement-023、data-movement-024 |
| hardware-generations | evaluate | 暂定：硬件代际应按精度口径、内存互连、软件成熟与交付能力共同评估；发布规格和投影不能替代独立运行证据。 | hardware-generations-002、hardware-generations-003、hardware-generations-009、hardware-generations-017、hardware-generations-018、hardware-generations-019 |
| heterogeneous-cluster | evaluate | 暂定：异构利用率依赖非均匀切分、通信与设备代价模型；框架能表达不同布局，不等于能自动平衡不同型号 GPU。 | heterogeneous-cluster-002、heterogeneous-cluster-005、heterogeneous-cluster-006、heterogeneous-cluster-007、heterogeneous-cluster-008 |
| memory-fabric | evaluate | 暂定：内存层须标明消费域、容量与隔离成熟度；扩容、共享池和并发供带宽是不同工作点，不能互换性能证据。 | memory-fabric-015、memory-fabric-016、memory-fabric-017、memory-fabric-018、memory-fabric-020、memory-fabric-021、memory-fabric-022、memory-fabric-023、memory-fabric-024 |
| network-reliability | evaluate | 暂定：路径恢复、隔离清场与回池验收须分层；维修范围须匹配清场证明，恢复健康与调度资格也须分别观测。 | network-reliability-002、network-reliability-005、network-reliability-006、network-reliability-008、network-reliability-011、network-reliability-012、network-reliability-013、network-reliability-014、network-reliability-015、network-reliability-016 |
| rack-scale-scheduling | apply | 暂定：调度器需持续消费拓扑图、域层级、故障与功率边界；物理同柜不代表同一通信域，拓扑标签本身也不保证收益。 | rack-scale-scheduling-001、rack-scale-scheduling-005、rack-scale-scheduling-006、rack-scale-scheduling-007 |
| scale-out-network | evaluate | 暂定：RDMA 尾延迟依赖路径、端侧拥塞和在途量联合控制；多平面须保留独立反馈，硬件拥塞控制不能替代应用预算。 | scale-out-network-015、scale-out-network-016、scale-out-network-017、scale-out-network-018 |
| scale-up-interconnect | evaluate | 暂定：互连须分介质、协议、拓扑与负载评估；带宽比较统一端点和方向，逐层交接与小消息还要看同步及地址翻译开销。 | scale-up-interconnect-042、scale-up-interconnect-043、scale-up-interconnect-044、scale-up-interconnect-055、scale-up-interconnect-059、scale-up-interconnect-062 |
| supernode-topology | evaluate | 暂定：超节点验收应确认软件可消费的单一或分层互联域；卡数、聚合带宽和产品发布材料不足以证明部署闭环。 | supernode-topology-009、supernode-topology-016、supernode-topology-017、supernode-topology-018、supernode-topology-019 |
定位：活跃飞轮；使用率 82%、引用率 78%、闭环率 41%。
差一源候选（7 条）：data-movement-020、hardware-generations-007、scale-out-network-008、scale-up-interconnect-004、scale-up-interconnect-005、scale-up-interconnect-023、scale-up-interconnect-043。
需刷新来源的过期条目（3 条）：hardware-generations-004、hardware-generations-005、supernode-topology-004。
有条目但不提炼立场：无。
distributed-training¶
| 节点 | Bloom | 当前立场 | 本轮实际采用的有效依据 |
|---|---|---|---|
| async-distributed | evaluate | 暂定：松耦合训练用低频聚合换取网络容忍度，紧耦合留在低延迟域；压缩比与吞吐收益须连同模型规模及收敛对照阅读。 | async-distributed-005、async-distributed-006、async-distributed-007 |
| collective-communication | apply | 暂定：通信组重组须按版本验收；NCCL 已有 Shrink/Revoke，但模型、KV 与执行状态仍需运行时恢复。 | collective-communication-003、collective-communication-005、collective-communication-012、collective-communication-014、collective-communication-015 |
| correctness-verification | apply | 暂定：正确性验收要从数值容差和参考实现逐层扩展到分布式与真实服务；局部测试通过不能替代公共请求路径验证。 | correctness-verification-001、correctness-verification-002、correctness-verification-003、correctness-verification-005 |
| fault-tolerance-training | apply | 暂定：容错须区分精确状态恢复、可容忍扰动恢复与拓扑重配置；故障范围、收敛要求和替代容量共同决定可用路径。 | fault-tolerance-training-001、fault-tolerance-training-003、fault-tolerance-training-004、fault-tolerance-training-005、fault-tolerance-training-006 |
| large-scale-training | analyze | 暂定：跨域训练按通信频率与延迟分层放置；规模化运行还需持续跨层诊断，带宽比较不能混用整柜与单端口口径。 | large-scale-training-002、large-scale-training-003、large-scale-training-004、large-scale-training-007 |
| long-context-training | evaluate | 暂定：长上下文训练要联合优化非对称并行与选择重放；索引恢复仅适用于依赖选中集合的损失，短程加速不能证明长期收敛。 | long-context-training-001、long-context-training-002、long-context-training-003、long-context-training-004、long-context-training-005、long-context-training-006 |
| multimodal-training | remember | — | 未满足同方向数量门槛 |
| rl-infrastructure | evaluate | Rollout 可作为独立服务面，与训练器通过任务、轨迹和回调衔接；跨 Harness 的交互状态不能简化为一次采样调用。 | rl-infrastructure-007 |
| sparse-moe-training-stability | understand | — | 未满足同方向数量门槛 |
| training-parallelism | evaluate | 暂定：异构流水线要联合分配层、local batch 与梯度同步布局；非均匀表达只是起点，设备代价与运行节拍仍需建模。 | training-parallelism-005、training-parallelism-006、training-parallelism-008、training-parallelism-009、training-parallelism-011、training-parallelism-012 |
| weight-management | apply | 暂定：RL 权重分发应按模型规模、EP 和共置关系选择 IPC、NCCL 或 RDMA；大模型路径收益不可外推到低节点配置。 | weight-management-001、weight-management-002、weight-management-004、weight-management-005 |
定位：活跃飞轮；使用率 70%、引用率 55%、闭环率 30%。
差一源候选（1 条）：training-parallelism-008。
需刷新来源的过期条目（11 条）：async-distributed-001、async-distributed-002、async-distributed-003、async-distributed-004、multimodal-training-001、multimodal-training-002、multimodal-training-003、rl-infrastructure-001、rl-infrastructure-002、rl-infrastructure-003、weight-management-003。
有条目但不提炼立场：multimodal-training、sparse-moe-training-stability。
inference-system¶
| 节点 | Bloom | 当前立场 | 本轮实际采用的有效依据 |
|---|---|---|---|
| engine-architecture | evaluate | 暂定：引擎控制面、内存与传输需分层；模型专用快路径须显式准入、可回退，并同时验证数值状态与真实服务形状。 | engine-architecture-013、engine-architecture-014、engine-architecture-015、engine-architecture-020、engine-architecture-022 |
| hardware-specific | evaluate | 暂定：可部署性取决于精度、算子、互连和软件版本；机密模式会改变搬运与计时，规格与投影不能替代同负载实测。 | hardware-specific-008、hardware-specific-010、hardware-specific-013、hardware-specific-014、hardware-specific-018、hardware-specific-019 |
| inference-parallelism | evaluate | Attention/FFN 分离可让 KV 容量与聚合批量分别定容；收益须扣除不可掩盖的往返，资源比仍需按模型和负载测量。 | inference-parallelism-010 |
| kernel-optimization | evaluate | 暂定：内核优化先核对计时协议、缓存层与带宽分母，再判断融合和重叠收益；局部时间线不能代替整请求验收。 | kernel-optimization-006、kernel-optimization-009、kernel-optimization-010、kernel-optimization-011、kernel-optimization-012、kernel-optimization-014、kernel-optimization-015、kernel-optimization-016、kernel-optimization-017 |
| long-context-serving | evaluate | 暂定：长上下文成本由注意力结构、KV 斜率与前缀复用共同决定；固定 batch 的收益、放开容量的吞吐和舰队调度要分别测量。 | long-context-serving-007、long-context-serving-008、long-context-serving-009、long-context-serving-010、long-context-serving-011、long-context-serving-012、long-context-serving-013 |
| model-quantization | apply | 暂定：量化支持应拆为文件可加载、打包执行与负载可服务；精度、元数据和后端兼容须联合评估，不能由格式名称推断。 | model-quantization-001、model-quantization-002、model-quantization-005、model-quantization-006、model-quantization-007、model-quantization-008 |
| moe-serving | evaluate | 暂定：专家负载均衡、共享专家与故障恢复是不同设计轴；训练时均衡不保证生产均衡，可变 EP 规模也不等于在线摘卡。 | moe-serving-006、moe-serving-007、moe-serving-010、moe-serving-011、moe-serving-013、moe-serving-014、moe-serving-015 |
| multimodal-inference | evaluate | 暂定：多模态服务按感知交付单位与阶段关键路径验收；表示压缩、encoder 复用和分段拆分不能直接推出端到端加速。 | multimodal-inference-003、multimodal-inference-004、multimodal-inference-005、multimodal-inference-006、multimodal-inference-007、multimodal-inference-008 |
| pd-disaggregation | evaluate | 暂定：分离收益取决于模型、指标口径、资源配比与交接频率；固定 P:D 池可能错配，不能把分离本身视为收益来源。 | pd-disaggregation-002、pd-disaggregation-013、pd-disaggregation-015、pd-disaggregation-020、pd-disaggregation-023、pd-disaggregation-025 |
| request-scheduling | evaluate | 暂定：调度需联合前缀、有效工作量、到达模式与容量阈值；容量充足时看排队和准入，越界后先处理缓存重算。 | request-scheduling-007、request-scheduling-013、request-scheduling-016、request-scheduling-020、request-scheduling-021 |
| serving-infrastructure | evaluate | 暂定：配置搜索、性能建模和仿真应服从产品约束；长度分布、缓存、抖动、质量与安全模式需组成同一验收合同。 | serving-infrastructure-012、serving-infrastructure-015、serving-infrastructure-016、serving-infrastructure-025、serving-infrastructure-026、serving-infrastructure-028、serving-infrastructure-029 |
| speculative-decoding | evaluate | 暂定：投机解码须联合草稿延迟、验证步成本、接受长度与并发评估；K-Flat 是特定工作点现象，不能把验证普遍视为免费。 | speculative-decoding-002、speculative-decoding-006、speculative-decoding-008、speculative-decoding-013、speculative-decoding-014、speculative-decoding-015、speculative-decoding-018 |
定位：活跃飞轮；使用率 73%、引用率 66%、闭环率 61%。
差一源候选（10 条）：engine-architecture-007、hardware-specific-010、inference-parallelism-003、inference-parallelism-009、inference-parallelism-011、moe-serving-003、request-scheduling-013、request-scheduling-017、serving-infrastructure-023、speculative-decoding-013。
需刷新来源的过期条目（12 条）：engine-architecture-003、engine-architecture-004、engine-architecture-005、engine-architecture-009、kernel-optimization-005、long-context-serving-001、moe-serving-001、moe-serving-002、multimodal-inference-001、multimodal-inference-002、pd-disaggregation-004、pd-disaggregation-005。
有条目但不提炼立场：无。
kvcache¶
| 节点 | Bloom | 当前立场 | 本轮实际采用的有效依据 |
|---|---|---|---|
| attention-variants | evaluate | 暂定：KV 容量按注意力结构和指定模型版本核算，跨长度结果须分列。 | attention-variants-007、attention-variants-010、attention-variants-015、attention-variants-016 |
| compression-quantization | evaluate | 暂定：量化需分测读带宽、驻留容量、精度与物理取数粒度，格式和后端联合验收。 | compression-quantization-006、compression-quantization-007、compression-quantization-010、compression-quantization-013、compression-quantization-014、compression-quantization-018、compression-quantization-019、compression-quantization-020 |
| evaluation-benchmarks | evaluate | 暂定：分别测等并发、等容量与复用开关；会话回放不等于任务质量。 | evaluation-benchmarks-004、evaluation-benchmarks-005、evaluation-benchmarks-006、evaluation-benchmarks-007、evaluation-benchmarks-008 |
| framework-lmcache | apply | — | 未满足同方向数量门槛 |
| framework-mooncake | apply | 暂定：Store、传输与 Conductor 分工明确，本地性和租户准入须显式配置。 | framework-mooncake-008、framework-mooncake-011、framework-mooncake-012、framework-mooncake-017、framework-mooncake-018、framework-mooncake-019 |
| framework-sglang | apply | 暂定：存储池随模型架构静态选择，HiCache 管策略，外部存储管机制。 | framework-sglang-004、framework-sglang-005、framework-sglang-006、framework-sglang-007 |
| framework-trtllm | apply | 暂定：KV 层级与标准挂点须结合精度和版本验收，旧版最优不外推。 | framework-trtllm-003、framework-trtllm-004、framework-trtllm-005、framework-trtllm-006、framework-trtllm-007 |
| framework-vllm | apply | 暂定：调度器掌握 GPU block 分配，第一方卸载和外置连接器须按接口边界验收。 | framework-vllm-005、framework-vllm-006、framework-vllm-007、framework-vllm-008 |
| future-system | understand | — | 未满足同方向数量门槛 |
| lifecycle | apply | — | 未满足同方向数量门槛 |
| offload | evaluate | 暂定：卸载收益随访问粒度、搬运原语和硬件变化，稀疏需求不能只按带宽估算。 | offload-001、offload-007、offload-021、offload-023、offload-024、offload-025 |
| paged-kv | apply | 暂定：分页化解容量碎片，剪枝、I/O 与回收粒度仍须对齐。 | paged-kv-001、paged-kv-002、paged-kv-003、paged-kv-005、paged-kv-007 |
| pd-disaggregation | evaluate | 暂定：KV 交接须区分增量状态与持久范围，统一提交点和租约生命周期。 | pd-disaggregation-012、pd-disaggregation-013、pd-disaggregation-014、pd-disaggregation-015、pd-disaggregation-016、pd-disaggregation-017 |
| prefix-cache | evaluate | 前缀稳定与可达性决定复用，工作集越过 KV 容量可触发命中率陡降。 | prefix-cache-006、prefix-cache-017 |
| routing | evaluate | 暂定：亲和与均衡须按容量、轮间间隔及状态重取成本联合选择。 | routing-008、routing-009、routing-010、routing-011、routing-014、routing-015 |
| runtime-architecture | apply | 暂定：KV 状态成为调度可见对象，分配权、连接器职责与状态身份须明确。 | runtime-architecture-007、runtime-architecture-009、runtime-architecture-010、runtime-architecture-013、runtime-architecture-014、runtime-architecture-015 |
| sparsity | apply | 暂定：按查询选取与跨步跨层复用须分开建模，不能一概判为不可预取。 | sparsity-008、sparsity-009、sparsity-010、sparsity-011、sparsity-012、sparsity-013、sparsity-014 |
| storage-hierarchy | evaluate | 暂定：KV 分层须联合验收访问生命周期、布局与按时恢复能力。 | storage-hierarchy-010、storage-hierarchy-018、storage-hierarchy-019、storage-hierarchy-020、storage-hierarchy-021、storage-hierarchy-022、storage-hierarchy-023、storage-hierarchy-024、storage-hierarchy-025、storage-hierarchy-026、storage-hierarchy-027 |
| workload-agent | apply | 暂定：Agent 容量按会话累积与停等复用估算，并单测重算及语义精度。 | workload-agent-005、workload-agent-006、workload-agent-007、workload-agent-008、workload-agent-009 |
| workload-multiturn | remember | — | 未满足同方向数量门槛 |
| workload-reasoning | remember | — | 未满足同方向数量门槛 |
定位：活跃飞轮；使用率 100%、引用率 58%、闭环率 52%。
差一源候选（4 条）：attention-variants-002、paged-kv-005、prefix-cache-005、routing-006。
需刷新来源的过期条目（33 条）：attention-variants-001、attention-variants-003、compression-quantization-011、compression-quantization-012、evaluation-benchmarks-001、evaluation-benchmarks-002、evaluation-benchmarks-003、framework-mooncake-003、framework-sglang-001、framework-sglang-002、framework-sglang-003、framework-trtllm-002、framework-vllm-001、framework-vllm-002、framework-vllm-003、framework-vllm-004、lifecycle-001、lifecycle-002、paged-kv-004、paged-kv-006、pd-disaggregation-003、pd-disaggregation-004、prefix-cache-004、routing-001、runtime-architecture-001、runtime-architecture-002、runtime-architecture-003、storage-hierarchy-003、workload-agent-001、workload-agent-003、workload-multiturn-002、workload-reasoning-001、workload-reasoning-002。
有条目但不提炼立场：framework-lmcache、future-system、lifecycle、workload-multiturn、workload-reasoning。另保留 19 个正文主题空节点；agent/coding/RAG 联合质量与成本评估仍缺。
recommendation-system¶
此前已有18条、5篇公开来源，却缺 KNOWLEDGE-INDEX，因此不出现在 stats/validate 的域列表。本轮补轻量域入口，保留3个既有节点，没有为了凑规模新增条目。5篇来源达到域创建门槛。
| 节点 | Bloom | 当前立场 | 本轮实际采用的有效依据 |
|---|---|---|---|
| embedding-infrastructure | apply | 暂定：Embedding 容量管理应区分训练状态完整性与推理缓存复用，再选择字典或缓存语义；表规模与精度必须同口径。 | embedding-infrastructure-001、embedding-infrastructure-002、embedding-infrastructure-004、embedding-infrastructure-005、embedding-infrastructure-006 |
| recsys-training-infra | evaluate | 暂定：训练内梯度一致性与训练到服务的参数新鲜度分开配置；同步策略要按更新重叠、业务漂移和硬件约束决定。 | recsys-training-infra-001、recsys-training-infra-003、recsys-training-infra-005、recsys-training-infra-006、recsys-training-infra-007、recsys-training-infra-009 |
| retrieval-serving | apply | 暂定：MIPS 量化目标应对齐召回任务；ScaNN 的高召回收益受数据与检索前提限制，仍须粗筛及重排。 | retrieval-serving-001、retrieval-serving-002、retrieval-serving-003 |
全部54组同节点对及2组原日志跨域候选已复核：字典/缓存按状态完整性和可重建性条件化并存；Monolith training→serving参数发布与Persia训练内梯度同步不是同一对象。未新增活跃矛盾。
修复：悬空的 kvcache:storage-hierarchy-032 回链到实际 HKV 条目 003；嵌套对象式 contradictions_found 改为可被现有校验器读取的双方id列表，原说明保留 contradiction_note。
数值纠错：百万行×64维×FP32=256MB（约244MiB），不是单表数GB；Monolith假设模型中一次故障影响DAU约0.1%，按故障率摊到每日期望为0.01%/日，两者不能混用。
定位与限制：stats 定位为活跃飞轮，但使用/引用/闭环100%/100%/100%仅来自5篇建档样本，不证明长期飞轮已形成。18条、0 high，成熟度只记★★☆。该域没有eval目录，本轮按规则跳过场景自评；后续优先建立同负载的新鲜度/一致性/吞吐对照。
孤岛与后续补证¶
按有效条目的 related_nodes 检查到 1,286 条有向连接，69 个有数据节点均有入边或出边，没有已填充节点形成双向零连接孤岛。空节点仍作为知识缺口保留。
- agent-system:reasoning-planning 与 KV 的 19 个空节点仍保留在检索索引；正文导航节点不强行用摘要填满。
- 相邻但不同的节点无需搬运重复数字来提高覆盖；优先补同一负载、同一硬件的对照实验。
- 下一轮优先补：SSD 控制路径消融、亲和路由判据对照、MoE PD 与共享专家对照；其次刷新六个月前的源码/部署快照。
- pd-disaggregation 在两个域同名，保留结构性警告；文档和跨域 id 使用域前缀，避免通过改名破坏历史引用。
场景自评¶
原五域从既有 scenarios.yaml 各选一题，实际答案与局限追加到 grades；它们是知识复用自评，不是独立外部复现。
| 域 | 场景 | 自评 | 主要限制 |
|---|---|---|---|
| agent-system | scenario-001 Skill 治理 | acceptable | 改正 SkillsBench/SkillsVote 归因；缺组织级独立收益对照。 |
| cluster-infra | scenario-003 网络自愈 | good | 分层机制与新多平面证据齐备，实机与仿真口径分别保留。 |
| distributed-training | scenario-003 长上下文训练 | acceptable | HyScale 补重算路径，未证明五维联合调度或长期收敛。 |
| inference-system | scenario-002 Agent P95 | acceptable | 容量/到达模式边界明确，仍无统一工作负载的完整 P95 配方。 |
| kvcache | scenario-002 固定前缀降本 | good | 能给出稳定前缀、边界、复用与容量的验收流程，供应商价格仍须使用时核验。 |
远端整合的补充结晶¶
远端新增 12 条全部保留来源与 medium 上限：FMS 的消费域/成熟状态/位置与复用对照、NVSentinel 的清场与回池证明、NCCL 新版管理接口、H20 计时和双缓冲边界、Ascend 量化取数布局，以及 VLDA 的串行部署关键路径。逐条对照已加入审计表。未将共享内存蓝图、静态 occupancy 或紧凑表示直接写成已验证端到端加速。
校验记录¶
六域 YAML 以 js-yaml 完整解析；来源路径、后继目标、索引字节数、Bloom 门槛与 stance 依据另作交叉检查。npm run stats:knowledge 与 npm run validate:knowledge 均通过，待结晶与统计漂移归零；仅保留跨域同名 pd-disaggregation 的结构性告警。npm run check:confidential 为 0 blocking（3 条历史文章厂商名提示，非本轮新增）；mkdocs build --strict 成功。原五域各有 1 条 2026-11-04 场景作答；推荐域没有eval目录，跳过并登记缺口，非外部复现。