向管理层 Leader 汇报 — 课题候选脑暴（互联通信机制聚焦版）
v0.3 — 进一步聚焦"机制类研究"，移出具体产品对比（NVL72/UALink/RoCE 等）、远期前瞻（光互联 / 跨 DC）、当前不适用的部署模式（PD 分离） 原则：一个切入点 = 一个潜在 TCB，不强行合并；主体只保留"通用机制 + 项目可量化"的课题
名词定义
本文档涉及的缩写、技术名词、产品名集中说明，后续各节默认沿用这些定义。
并行策略与推理阶段
| 名词 | 定义 |
|---|---|
| TP（Tensor Parallelism） | 张量并行，把单个矩阵乘按列 / 行切到多卡，通信主要是 all-reduce |
| PP（Pipeline Parallelism） | 流水并行，把模型层按顺序切到多卡，通信主要是 P2P 跨 stage 传 activation |
| DP（Data Parallelism） | 数据并行，每卡复制完整模型，梯度做 all-reduce |
| EP（Expert Parallelism） | 专家并行，MoE 模型把不同 expert 分到不同卡，通信主要是 all-to-all（dispatch + combine） |
| SP（Sequence Parallelism） | 序列并行，把序列维度切到多卡，与 TP 互补 |
| Prefill | 推理第一阶段，处理输入 prompt 生成首个 token，算力密集 |
| Decode | 推理后续阶段，逐个生成 token，带宽密集 |
| PD 分离（Prefill-Decode Disaggregation） | 把 prefill 和 decode 部署到不同集群，各自优化。代表实现：SGLang / vLLM / Mooncake |
| KVCache | Key/Value 缓存，transformer 推理时存历史 token 的 attention key/value，避免重计算 |
| KV transfer / KV migration | PD 分离场景下，prefill 完成后把 KVCache 传到 decode 集群，是 PD 部署的核心瓶颈 |
| TTFT（Time To First Token） | 首 token 延迟，prefill 阶段主导 |
| TPOT（Time Per Output Token） | 单 token 生成延迟，decode 阶段主导 |
| SLO（Service Level Objective） | 服务等级目标，如 "TTFT < 500ms" |
| continuous batching | 推理时动态合并不同请求的 token 到同一批，提升吞吐 |
| PrfaaS（Prefill-as-a-Service） | Moonshot + 清华提出的跨数据中心 prefill 服务架构，见 PrfaaS arXiv 2604.15039 |
@tbl-bs-leader-glossary-parallel 并行策略与推理阶段：名词、定义
互联硬件与协议
| 名词 | 定义 |
|---|---|
| scale-up | 单一 fabric 内紧耦合互联（NVLink / UALink），延迟低带宽高，如 NVL72 = 72 GPU 单 fabric |
| scale-out | 跨 fabric 松耦合互联（RoCE / InfiniBand），靠以太网或专用网，跨服务器 / 跨机柜 |
| scale-up domain | 同一 scale-up fabric 覆盖的 GPU 数，8 → 72 → 576 是 NVIDIA 路线 |
| NVLink | NVIDIA 私有 GPU 间高速互联；详见 1.2 NVLink |
| NVL72 / Vera Rubin NVL72 | NVIDIA 机架级方案，72 GPU 单 NVLink 域，260 TB/s scale-up 带宽；详见 2.16 NVL72 |
| UALink（Ultra Accelerator Link） | AMD/Intel 联盟主推的开放 scale-up 标准，对标 NVLink,2027 量产 |
| UEC（Ultra Ethernet Consortium） | 开放 scale-out 以太网标准 |
| SUE（Scale-Up Ethernet） | Broadcom 的 scale-up 以太网方案 |
| RoCE（RDMA over Converged Ethernet） | 基于以太网的 RDMA,scale-out 主流方案；详见 1.5 RoCE (RDMA over Converged Ethernet) |
| CPO（Co-Packaged Optics） | 光模块与交换机芯片共封装，降低互联功耗 / 提升带宽密度 |
| OCS（Optical Circuit Switching） | 光电路交换，可重构拓扑，详见 2.15 光交换（OCS） |
@tbl-bs-leader-glossary-hw 互联硬件与协议：名词、定义
集合通信与网络拓扑
| 名词 | 定义 |
|---|---|
| all-to-all | N 个节点两两交换数据，MoE EP 的 dispatch/combine 是典型代表，通信量大；详见 4.9 AllToAll |
| all-reduce | 所有节点合并数据（求和等）再分发，TP/DP 的典型通信；详见 4.8 AllReduce |
| dispatch / combine | MoE 路由的两步：把 token 发到目标 expert（dispatch），处理完收回（combine） |
| fat-tree / dragonfly / torus / Jellyfish / SlimFly | 不同的网络拓扑结构，详见 网络拓扑总览 |
| ZCube | ATOP 自动搜索发现的拓扑实例；详见 2.13 ZCube |
| SHARP（Scalable Hierarchical Aggregation and Reduction Protocol） | NVIDIA 在网计算，把 all-reduce 卸载到 InfiniBand 交换机 |
| INC（In-Network Computing） | 在网计算的统称，Edge-INC / Core-INC 是两种部署位置 |
@tbl-bs-leader-glossary-cc 集合通信与网络拓扑：名词、定义
模型架构与开源实现
| 名词 | 定义 |
|---|---|
| MoE（Mixture of Experts） | 混合专家，每 token 只激活部分参数，代表 DeepSeek-V3/V4 |
| DeepSeek-V3 / V4 | DeepSeek 大模型，V4 = 1T 总参数 / 37B 激活，58 层 MoE；详见 DeepSeek-V4 总览 |
| DeepEP | DeepSeek 开源的 MoE EP 通信库，见 GitHub |
| MHC（Manifold-Constrained Hyper-Connections） | DeepSeek-V4 的 head 共享 KV 设计，降低 KVCache 带宽；详见 2.2 mHC |
| Mooncake / SGLang / vLLM | 主流 LLM 推理框架，均支持 PD 分离 |
| reasoning model | 推理型模型，如 o3 / DeepSeek-R1，在 decode 阶段生成长思维链 |
| agentic | 智能体型工作负载，多轮 / 工具调用 / 长会话，流量 spiky |
@tbl-bs-leader-glossary-model 模型架构与开源实现：名词、定义
算法、方法论与项目内部名词
| 名词 | 定义 |
|---|---|
| Pareto 前沿 | 多目标优化下"无法在不牺牲一项的前提下改善另一项"的解集 |
| co-design（Algorithm-Topology Co-design） | 算法与拓扑协同设计，而非互相迁就 |
| TopoOpt | OSDI'23 论文，拓扑 + 并行联合优化；详见 8.3 TopoOpt |
| MoSCoW | 收敛方法之一，Must / Should / Could / Won't 四桶分类 |
| RICE | 收敛方法之一，Reach × Impact × Confidence / Effort |
| G5 | 项目内的指令级仿真器，Rust 实现，见 perfmodel/evaluation/g5/ |
| Math | 项目内的代数性能模型，与 G5 互补 |
| 拓扑寻优器 | 项目模块，给定 workload + 硬件约束自动搜出 Pareto 拓扑方案，Phase 1 已交付；详见 拓扑寻优总览 |
| TCB（Task Capability Brief） | 公司内部项目立项汇报 PPT 格式，见 write-tcb skill |
| leader 汇报 | 公司内部向管理层做工作汇报，通常用 TCB 形式 |
@tbl-bs-leader-glossary-method 算法、方法论与项目内部名词：名词、定义
候选清单（按维度）
主体保留 4 个候选，按 2 个聚焦子方向组织：
F1. LLM 通信负载机制研究
C1b: MoE EP all-to-all 对拓扑敏感性
KBG:
- 大规模 MoE 模型（如 DeepSeek-V4 类负载）每层产生数十 GB 量级 all-to-all 流量，EP 已从可选并行维度变成 first-class 维度，但行业对 EP × 拓扑匹配缺系统研究
- 不同拓扑结构（fat-tree / dragonfly / torus / ZCube）在 all-to-all dispatch + combine 模式下性能差异巨大，目前选拓扑靠"参考厂商"而非定量
- 缺乏机制级的"MoE 流量模式 × 拓扑特征"对照关系，部署决策无可靠依据
项目落点：拓扑寻优器（路由模块 v1.2 + 多目标搜索）+ docs/interconnect/08-DeepSeek-V4 + 08-拓扑寻优。
为什么倾向作为主汇报：
- 互联通信纯度最高（EP all-to-all 当前最尖锐的通信瓶颈）
- 机制类研究（不依赖具体产品对比），结论可泛化
- 项目落点最直接（路由 v1.2 + 寻优器 Phase 1 全用上）
- 量化结果可秀（不同拓扑同一负载对比图）
备注：DeepSeek-V4 等模型可作为代表性负载用作数据源，但课题本身研究的是 MoE EP 通信机制，不依赖任何具体产品。
C1a：长上下文（1M+）对通信瓶颈位移的影响（用户原始种子）
KBG:
- 主流模型上下文从 128K 普遍向 1M+ 推进，KV-cache 内存占用线性增长但带宽 / latency 非线性恶化，并行切分边界被迫重画但缺少量化工具
- TP 切多了通信开销飙升，PP 切多了 activation / KV 跨 stage 成本暴涨，工程团队靠经验拍板
- 业界已有 paged attention / chunked prefill 等点子，但缺乏在确定硬件下"上下文长度 vs 切分方案 Pareto"的系统分析
项目落点：G5 + 通信评估 + 拓扑寻优。输出"上下文长度 vs 通信占比 / 切分方案"曲线。
备注：与 C1b 主题部分重叠（长上下文是 EP 通信变重的原因之一），可作为 C1b 主汇报的开场铺垫，或独立成篇。
F4. 协同设计 + 集合通信机制
C7a: Algorithm-Topology Co-design 方法论
KBG:
- 长期以来"算法不动调拓扑 vs 拓扑不动调算法"两条路径割裂，协同设计仅停留在论文层面（TopoOpt 等）
- 工业级模型已经出现"算法迎合拓扑"的设计（如 DeepSeek-V4 的 MHC 让 head 共享 KV 来降低带宽压力），说明 co-design 在工业界已自发发生
- 项目工具栈正好覆盖 algorithm side（workload）+ topology side（寻优），有方法论高度但缺包装
项目落点：方法论包装 + 案例研究（DeepSeek-V4 MHC / 拓扑选择联动）。
C7c: In-Network Computing 机制研究
KBG:
- 在网计算（把 reduce / multicast 卸载到交换机）是集合通信加速的新方向，学术界论文很多但工业级实测数据少
- 当前通信评估假设 host-side reduce,对在网计算加速效果建模不足，无法支撑"是否引入 INC"的设计决策
- 加上 INC 建模后，"老拓扑 + 新加速"组合可能重新有竞争力，改变拓扑选择的结论
项目落点：通信评估 + 路由模块扩展支持在网计算抽象。
备注：NVIDIA SHARP 是最成熟的 INC 实现，可作为参考案例，但课题本身研究的是 在网计算这一通用机制，不限于某厂商。
业界对标
本节列出与 2 个主线子方向（F1 LLM 通信负载机制、F4 协同设计 + 集合通信机制）直接相关的 2026 年业界信号 + 来源。
具体产品对比（NVL72 / UALink / RoCE）与远期前瞻（光互联 / 跨 DC）相关的业界信号已不在主体讨论范围，见附录 B。
F1 相关：LLM 通信负载机制
| 关键信号 | 代表来源 |
|---|---|
| 大规模 MoE 模型 EP 通信流量级别（DeepSeek 类负载每层数十 GB all-to-all） | DeepEP GitHub, Glenn K. Lockwood blog, DeepSeek-V3 MLPerf |
| 长上下文（1M+）下 KV cache 优化策略 | KV Cache Optimization Strategies (arXiv 2603.20397) |
F4 相关：协同设计 + 集合通信机制
| 关键信号 | 代表来源 |
|---|---|
| 在网计算（INC / Edge-INC / multicast）加速集合通信 | INC emergentmind, Multicast collective arXiv 2605.22428, NAIC Workshop |
| TopoOpt 拓扑+并行联合优化（Algorithm-Topology co-design 学术代表作） | TopoOpt OSDI'23 |
当前分类（讨论中，未最终收敛）
仅作为讨论过程的工作快照，不是最终决策。最终选哪个进 TCB，由 leader 反馈或后续讨论确定。
主体 4 个候选按"在汇报中的潜在角色"做粗分类：
当前倾向做主汇报候选
| 候选 | 子方向 | 倾向理由 |
|---|---|---|
| C1b MoE EP all-to-all 拓扑敏感性 | F1 | 互联通信纯度最高 + 机制类研究可泛化 + 项目落点最直接 + 量化结果可秀 |
主汇报备选（也可单独成 TCB）
| 候选 | 子方向 | 倾向理由 |
|---|---|---|
| C7a Algorithm-Topology Co-design | F4 | 方法论高度，但缺定量结果支撑独立成篇 |
| C7c In-Network Computing 机制研究 | F4 | 集合通信加速新方向，但需先有 INC 建模基础 |
二级嵌入候选（适合做主汇报里的子章节，不单独成 TCB）
| 候选 | 子方向 | 在主汇报中的潜在角色 |
|---|---|---|
| C1a 长上下文通信瓶颈位移 | F1 | 主汇报开场铺垫（用户种子，与 C1b 自然衔接） |
已暂时移出主体
18 个候选，移出理由分 6 类：
- 偏算力 / serving、偏工具适配、偏商业决策、偏方法论（v0.2 移出的 12 个）
- 当前不适用的部署模式（v0.3 移出）
- 具体产品对比（v0.3 移出）
- 互联前瞻太远（v0.3 移出）
完整 KBG + 移出理由见附录 A。 保留在附录意味着不符合当前聚焦范围，不代表永久否决——若 leader 另指方向，可挑回主线。
决策痕迹
v0.1 → v0.2 聚焦决策
v0.1 阶段：第一轮发散，列出 22 个候选，跨 5 个维度（D1 业界热点 / D2 工具展示 / D5 选型决策 / D7 跨学科 / D8 前瞻）。
v0.2 决策：用户要求聚焦"大模型互联通信"主线。
按"通信是否核心"过滤 22 候选，12 个剔除（通信非主线）→ 移到附录 A，主体保留 10 个，按 4 个子方向 F1-F4 重组。
v0.2 → v0.3 进一步聚焦
v0.3 决策：用户进一步要求剔除三类不适合当前汇报的候选：
- 当前不适用的部署模式：PD 分离假设公司部署模式做 PD 分离，但实际部署没有分离，所以这类课题不适用
- 具体产品对比：NVL72 vs UALink vs RoCE 这种"列产品对比"型课题，缺机制深度，不适合本次定位
- 互联前瞻太远：光互联 / 跨 DC 等 5 年期前瞻，管理层关注当下能落地的事
主体从 10 个进一步缩到 4 个：C1b, C1a, C7a, C7c。子方向从 F1/F2/F3/F4 缩到 F1（LLM 通信负载机制）+ F4（协同设计 + 集合通信机制）。
倾向 C1b 作主汇报的依据
| 评估维度 | C1b 表现 |
|---|---|
| 互联通信纯度 | 最高（EP all-to-all 是当前最尖锐的通信瓶颈） |
| 机制类研究纯度 | 高（MoE EP 通信是通用机制，DeepSeek-V4 只是数据源） |
| 项目落点成熟度 | 高（路由 v1.2 + 寻优器 Phase 1 + docs/interconnect/08 + 09 全可用） |
| 量化结果可演示性 | 高（不同拓扑同一负载对比图） |
| 后续延展性 | 可衍生 C7a 协同设计 / C7c INC 加速 |
否决其他主体候选作主线的理由
- C7a Co-design 方法论：方法论高度好，但缺定量结果撑场，讲方法论容易空洞，适合做 C1b 的方法论包装
- C7c In-Network Computing 机制研究：方向新但需先有 INC 建模基础，项目还没做，落点偏弱
- C1a 长上下文：与 C1b 重叠（长上下文是 EP 通信变重的原因之一），作为开场铺垫更合适
移出 18 个候选的分类与理由
| 类别 | 候选 | 共同特征 | 移出版本 |
|---|---|---|---|
| 偏算力 / serving | C1d, C1e, C1f, C1g | 主线是算力 / 推理优化 / serving 调度，通信非核心 | v0.2 |
| 偏工具 / 适配 | C2a, C2b, C2d | 工具能力展示型，缺业界叙事 hook | v0.2 |
| 偏商业 / 选型 | C5a, C5d | 商业决策主线，通信是 TCO / 部署的一个分项 | v0.2 |
| 偏方法论 / 跨学科 | C7b, C7d, C8c | 方法论 / AI for systems / 绿色 AI 视角，通信非叙事主角 | v0.2 |
| 当前不适用部署模式 | C1c | 公司当前部署没做 PD 分离，假设不成立 | v0.3 |
| 偏具体产品对比 | C5b, C5c, C2c | 列产品对比型，缺机制深度，不适合本次定位 | v0.3 |
| 互联前瞻太远 | C8a, C8b | 5 年期前瞻，管理层关注当下能落地的事 | v0.3 |
详细 KBG 见附录 A。
开放问题
待决定
- 选哪个进 TCB？ 倾向 C1b，备选 C7a / C7c
- 是否要做系列 TCB？ C1b 主 + C7a 辅（协同设计方法论作为 C1b 的高度包装），还是单 TCB
- C1b 的具体切入点？ 是按"workload 一种 × 拓扑多种"出对比，还是按"workload 多种 × 拓扑一种"出敏感性曲线
待补调研
- MoE EP 通信流量的实测数据 — 需从公开论文 / 开源仓库提取更可信的数据点（不仅 Glenn K. Lockwood blog）
- In-Network Computing 机制(C7c)的项目内建模基础 — 当前通信评估对在网计算的支持现状，决定 C7c 是否能短期支撑 TCB
数据可信度待核实
落地为正式汇报材料前，需对以下关键数据点做二次核实（当前来自 webserp 调研，未逐条 verify）：
- MoE 模型每层 all-to-all 通信流量量级 — 源自 Glenn K. Lockwood blog，需对照 DeepSeek 官方 / DeepEP 仓库数据
- 不同拓扑下 all-to-all 性能差异 — 需对照 ATOP / TopoOpt 论文实测
附录 A — 移出主线的 18 个候选（不符合当前聚焦，留底备查）
这 18 个候选在不同版本中移出：v0.2 移出 12 个（通信非主线），v0.3 移出 6 个（当前不适用部署 / 偏具体产品 / 远期前瞻）。 业务价值依然存在，但不符合"互联通信机制研究"的当前聚焦。若未来 leader 另指定汇报方向，可从这里挑回主线。
A.1 偏算力 / serving 模式（4 个，v0.2 移出）
C1d: Reasoning Model 长思维链对推理基础设施的影响
移出理由：推理算力 / SLO 调度是主线，通信非核心。
KBG:
- 业界共识：2026 推理工作负载占 AI compute 2/3（o3 / R2 / Deep Think 推动），但长思维链推理与传统短输出 serving 模式截然不同
- 长思维链 = 长 decode 阶段，TPOT 比 TTFT 更关键，但当前部署系统仍按 prefill-heavy 优化
- 推理时间从秒级 → 分钟级，集群 scheduling / 资源调度 / SLO 定义需要重构
项目落点：Math + G5 联合评估，量化 reasoning 场景下 TPOT-dominated SLO 对部署方案的影响。 来源：Reasoning Models 2026, AI Reasoning Models & Test-Time Compute
C1e: Agentic 工作负载的 spiky 流量对 serving 集群的挑战
移出理由：serving 调度 / 集群规模规划是主线，通信非主角。
KBG:
- Agentic 流量与传统 LLM API 不同："一小时零调用 → 突发并发数百"（业界 GPU infra 文章原话）
- 工具调用 / 多轮 / KV reuse 模式复杂，传统 continuous batching 失效
- 集群按 peak 配置浪费资源，按均值配置 SLO 崩盘，没有量化模型指导集群规模规划
项目落点：扩展 workload 抽象支持 agentic trace,G5 评估突发流量下的部署冗余度。 来源：GPU Infrastructure for AI Agents 2026, Agentic AI Market Report Q1 2026
C1f: Speculative Decoding 在不同拓扑下的加速天花板
移出理由：drafter-target 通信存在但偏次要，主线是推理加速。
KBG:
- Speculative decoding（及递归 speculative）已成标准加速手段，但接受率 / target verify 通信对集群拓扑敏感
- AdaServe 等 SLO-customized 方法需要在线评估通信成本来决策 speculative 长度，缺乏仿真工具
- 不同 drafter / target ratio 下的最优部署方案业界缺系统比较
项目落点：G5 + 通信评估扩展支持 drafter-target 双模型 workload。 来源：Speculative Speculative arXiv 2603.03251, AdaServe EuroSys'26, Google TPU diffusion speculative
C1g：多模态 LLM（视频 / 音频）serving 的新通信模式
移出理由：输入侧 token 数 / encoder 异构部署是主线，通信是衍生话题。调研也不足。
KBG:
- 多模态输入 token 数巨大（1 分钟视频 → 数万 token），prefill 阶段算力 / 带宽需求与文本完全不同
- 视频 encoder / audio encoder 与 LLM 主干异构部署 vs 同构部署的通信权衡未量化
- 流式输入（实时视频对话）对通信延迟 SLO 要求与离线推理冲突，部署架构需要重新设计
项目落点：workload 模型扩展 + G5 仿真异构 pipeline。 来源：需补充调研（webserp q12 未返回有效结果，需要单独查多模态 serving）
A.2 偏工具能力 / 适配（3 个，v0.2 移出）
C2a：拓扑寻优器 Phase 1 端到端能力发布
移出理由：纯工具展示，缺业界叙事的 hook。可作为 C1b 等课题的工具基底。
KBG:
- 业界拓扑选型长期靠"参考标杆部署"或"工程师经验",没有给定 workload + 硬件约束就能自动出 Pareto 拓扑方案的开源 / 内部工具
- 我们交付了 Phase 1（G5 adapter + 多目标搜索 + 路由 v1.2），但能力对外尚未系统展示
- 管理层 / 兄弟团队不知道这个工具能解决什么具体决策问题，导致工具影响力 / 资源支持不足
项目落点：拓扑寻优器 Phase 1 已交付，直接出 demo。
来源：内部 Phase 1 plan 文档 docs/plans/2026-05-21-拓扑寻优器-phase1.md
C2b: G5 仿真器对 MoE Workload 的精度验证
移出理由：工具内功型课题，管理层听不出价值。适合学术 / 同行评审场合。
KBG:
- G5 指令级仿真已支持基本 LLM workload,但对 DeepSeek-V3/V4 这种 MoE + 长上下文 workload 的精度未公开验证
- 业界 Astra-sim / SimAI 等仿真器各自标榜精度，我们需要把 G5 放在同一标尺下验证
- 缺乏精度 baseline,下游决策 / 论文 / 评审都缺背书
项目落点：G5 + DeepSeek-V3/V4 workload + 业界公开 benchmark 对照。
来源：DeepSeek-V3 MLPerf v6.0，项目内 docs/interconnect/07-仿真工具/06-g5-vs-simai.md
C2d：拓扑寻优器对国产芯片的适配能力
移出理由：工具适配是主线，通信不是。可作为 C1b 在国产芯片上 demo 时的支撑。
KBG:
- Ascend 950PR / SG2262 等国产芯片快速量产，但软件栈生态（寻优 / 仿真 / 部署评估）弱于 NVIDIA 生态
- 项目工具栈若仅 demo 在 H100,对国产芯片用户价值有限
- 没有国产芯片适配工作，项目错过国产替代的战略窗口
项目落点：拓扑寻优器 + 国产芯片硬件 spec 注入（已有 SG2262 spec）。 来源：Huawei Ascend 950PR, 华为 AI 芯片产能翻倍
A.3 偏商业 / 选型决策（2 个，v0.2 移出）
C5a: DeepSeek-V4 在国产芯片集群上的最优部署方案
移出理由：业务价值最直接，但偏部署研究 / 选型支撑，不是互联通信纯度高的课题。可作为 C1b 的下一阶段延展。
KBG:
- DeepSeek-V4 推出后，Ascend 950PR / 国产卡用户急需部署方案，但官方部署示例只覆盖 NVIDIA H100/H200
- 国产芯片 HBM 容量 / 互联带宽与 H100 不同，TP/EP/PP 切分方案需要重新设计
- 项目工具完全可以承接这个量化研究，直接服务公司选型决策
项目落点：Math + G5 + 拓扑寻优，输出"DeepSeek-V4 × 国产芯片"部署矩阵。 来源：Reuters: DeepSeek V4 推动 Ascend 需求, DeepSeek V4 推动 Ascend 950PR
C5d：国产芯片集群替代 H20 的 TCO 分析
移出理由：商业决策为主，通信仅是 TCO 公式的一个分项。适合战略汇报场合而非技术汇报。
KBG:
- H20 受出口管制影响供应不稳定，Ascend 950PR 单卡算力 2.8× H20（FP8），但集群级互联弱于 NVLink
- 集群级性价比 = 单卡算力 × 互联效率 × 软件栈成熟度，三项缺一不可，业界缺综合评测
- 决策层需要"性能 / 成本 / 风险"三维量化才能做替代决策
项目落点：成本评估 + 通信评估 + 报告生成。 来源：Huawei Ascend 950PR vs H20, AI Inference Power 2026, LLM TCO Calculator
A.4 偏方法论 / 跨学科（3 个，v0.2 移出）
C7b：多目标贝叶斯优化在拓扑搜索中的应用
移出理由：搜索算法升级，通信是被搜索的对象，不是主线。适合 Phase 2 算法路线分享。
KBG:
- 拓扑设计空间巨大（节点连接 + 路由 + 调度三维），遍历搜索不可行
- 业界 TopoOpt 用 GA / 演化算法，但 Pareto 前沿稀疏时贝叶斯方法效率更高
- 项目 Phase 1 已有基础设施，Phase 2 可引入 SOTA 搜索方法，出研究成果
项目落点：拓扑寻优器 Phase 2 算法升级。
来源：BoTorch (Meta) 多目标贝叶斯优化，项目内 docs/interconnect/08-拓扑寻优/04-多目标搜索算法.md
C7d：用 RL 训练拓扑寻优 Agent
移出理由：AI for systems 范式，学术性强，通信不是叙事主角。
KBG:
- 当前拓扑寻优 = 多目标搜索，搜索算法固定，不能"学会"什么是好拓扑
- Post-training 时代 RL 基础设施（GRPO / RLinf）已成熟，理论上可以训练一个 topology design agent
- 这是项目从"寻优工具"升级到"AI for systems"研究方向的钩子，学术意义 + 媒体影响力双高
项目落点：拓扑寻优器接入 RL agent（探索性课题）。 来源：RLinf GitHub, Post-Training 2026: GRPO/DAPO/RLVR, RL Posttraining for Tool-Using Agents
C8c：把能耗 / TCO 融入拓扑寻优目标
移出理由：寻优器目标函数扩展，主线是绿色 AI，通信只是评估对象。
KBG:
- 业界 2026 共识：推理电力成本是隐藏 TCO 大头，但当前寻优只优化性能 / 成本（资本支出）
- 不同拓扑 / 互联方案的功耗差异显著（光互联 vs 铜缆，大 scale-up vs scale-out）
- 把 power 当作第三个目标加入 Pareto 优化，寻优器从"性能工具"升级为"绿色 AI 决策工具"，蹭可持续 AI 热点
项目落点：拓扑寻优器目标函数扩展（性能 + 成本 + 能耗）。 来源：AI Inference Power 2026, LLM 电力需求系统综述, Local vs Cloud TCO
A.5 当前不适用的部署模式（1 个，v0.3 移出）
C1c: PD 分离部署下 KVCache transfer 的带宽临界点
移出理由：公司当前部署没有做 PD 分离，这个课题的假设不成立。若未来部署模式变化（如真的引入 PD 分离），可挑回主线。
KBG:
- PD 分离已成主流（SGLang / vLLM / Mooncake），但 PD 部署边界由 KVCache transfer 决定，缺乏临界点工具
- Moonshot PrfaaS 把 prefill 推到跨 DC,意味着跨机柜 / 跨 DC 的 KV 通信带宽成为新瓶颈
- 长上下文场景下 KV 传输可达 TB 级，网络选型（NVLink / RoCE / 100G 以太网）决定 PD 是否可行，但工程师没工具评估
项目落点：G5 仿真 + 通信评估，输出"PD 分离临界点 vs 网络带宽"曲线。 来源：PrfaaS arXiv 2604.15039, Together.ai CPD blog, PD Disaggregation Roadmap 2026Q2
A.6 偏具体产品对比（3 个，v0.3 移出）
共同特征：以"NVL72 / UALink / RoCE 等具体硬件方案对比"为主线，缺机制深度，不适合"互联通信机制研究"的本次定位。 这类课题更适合做战略 / 采购汇报，而非技术机制汇报。
C5b: NVL72 vs UALink vs RoCE 集群方案对比研究
移出理由：具体产品对比类课题，缺机制深度，且 UALink 2027 才量产，部分数据偏推测。
KBG:
- NVIDIA NVL72 已量产，UALink/UEC 2027 才可用，RoCE 是兜底，公司在采购 / 自研集群方案时面临三选一
- 三种方案在不同 workload（MoE / 长上下文 / agentic）下的性价比未系统对比
- 错配方案会带来千万级浪费，但目前内部缺乏量化决策支撑
项目落点：通信评估 + 拓扑寻优 + 成本评估，输出三方案对比表。 来源：NVL72 Detailed, UALink Consortium, AMD/Intel UALink
C5c: Scale-up Domain Size 临界点研究（8 → 72 → 576）
移出理由：绑定具体产品路线（NVL72 / Rubin Ultra），且属于硬件趋势分析而非通信机制研究。
KBG:
- NVL72 把 scale-up 从 8 GPU 推到 72,Rubin Ultra 还要到 576,但更大 scale-up 是否一定更好？
- 对不同 workload,scale-up domain 增大的边际收益在某个点开始递减，但行业没有定量曲线
- 我们的 G5 + 拓扑寻优可以在仿真层面跑出这个临界点，为公司未来 3-5 年硬件路线提供数据依据
项目落点：G5 + 拓扑寻优器扫描 scale-up domain size。 来源：NVIDIA Rubin Ultra @ GTC 2026, SemiAnalysis scale-up vs scale-out
C2c：通信评估模块对 NVL72 / 多机柜场景的支持
移出理由：绑定具体产品 NVL72 的工具建设型课题，缺业界叙事 hook。
KBG:
- 当前通信评估基于 alpha-beta + 拓扑感知，对 NVL72 级别 scale-up domain（72 GPU 单一 fabric）的特殊性未充分建模
- 业界正在重新划 scale-up / scale-out 边界，评估模型若不跟进，失去对最新硬件的代表性
- 国内 ZCube 等大 scale-up 拓扑也面临同类建模需求
项目落点：通信评估扩展 + docs/interconnect/02-网络拓扑/16-nvl72.md 已有基础。 来源：NVIDIA Vera Rubin NVL72, NVL72 Detailed (videocardz)
A.7 互联前瞻太远（2 个，v0.3 移出）
共同特征：5 年期前瞻，管理层关注当下能落地的事，这类课题更适合学术报告 / 长期路线规划场合。
C8a：光互联 / CPO 对未来 AI DC 拓扑选择的影响
移出理由：5 年期前瞻，落地时机太远，当前汇报不适合。
KBG:
- OFC 2026 共识：5 年内 AI DC 互联全光化，CPO（Co-Packaged Optics）进入量产准备
- 光互联改变带宽 / 延迟 / 成本曲线，原本最优的拓扑（fat-tree / dragonfly）在光互联条件下可能被其他拓扑超越
- 项目工具有机会前瞻评估"光互联条件下的拓扑选择"，给公司硬件路线规划提供前瞻输入
项目落点：硬件 spec 注入 + 拓扑寻优扫描。 来源：All AI DC Interconnects Will Be Optical Within 5 Years (SemiEng), OFC 2026 Outlook, OIF AI Optical Specs, AdtekFiber CPO 2026
C8b：跨数据中心 LLM 推理（PrfaaS 启发）的通信挑战
移出理由：跨 DC 推理是远期方向，且依赖 PD 分离假设（见 A.5），当前公司部署模式不适用。
KBG:
- Moonshot PrfaaS 提出跨 DC 部署 prefill cluster,via 商用以太网传 KVCache 到 decode cluster
- 这预示着 LLM 推理从单 DC → 跨 DC 演进，WAN 通信对部署架构的影响完全没人量化
- 国内公司多 DC 资源整合需求强烈，这是一个有具体业务驱动的前瞻课题
项目落点：通信评估扩展支持 WAN link + 拓扑寻优纳入跨 DC 层级。 来源：PrfaaS arXiv 2604.15039, MarkTechPost PrfaaS
附录 B — 业界调研补充信号（主线之外的方向）
业界对标段只保留了与"互联通信机制"主线高相关的 2 个子方向的信号（F1 / F4）。以下方向的调研结果保留备查，可能在未来其他汇报场合用到。
| 方向 | 关键信号 | 代表来源 |
|---|---|---|
| Reasoning model | 2026 推理工作负载占 AI compute 2/3 | Reasoning Models 2026, Zylos Test-Time Compute |
| Agentic | 流量 spiky；CodeAgent vs JSON tool call；120+ 框架 | Agent Frameworks 2026, Awesome AI Agents 2026 |
| Speculative decoding | 递归 speculative；SLO-customized speculative (AdaServe) | Speculative Speculative arXiv 2603.03251, AdaServe EuroSys'26 |
| 国产芯片 | Ascend 950PR = 2.8× H20 (FP8)；2026 中国 AI 芯片产能翻倍至 160 万 die | Huawei Ascend 950PR, Reuters DeepSeek V4 chip rush |
| RL 后训练 | GRPO / DAPO / RLVR；async rollout infra (RLinf / Relax) | Post-Training 2026, RLinf |
| TCO / 能耗 | 推理电力成隐藏 TCO 大头；自托管 vs 云 API TCO 对比 | AI Inference Power 2026, Local vs Cloud TCO |
| Scale-up 硬件趋势 | NVL72 / Vera Rubin（260 TB/s scale-up）；UALink / SUE / UEC 2027 才量产 | NVIDIA Vera Rubin NVL72, UALink Consortium, Broadcom SUE vs NVLink |
| 光互联 / CPO | OFC 2026 主题从 telecom 切到 AI；5 年内 DC 内全光化预测 | SemiEngineering optical, OFC 2026 outlook |
| PD 分离 / 跨 DC 推理 | CPD（cache-aware PD）提速 40%；Moonshot + 清华 PrfaaS 跨 DC 部署 | Together.ai CPD, PrfaaS arXiv 2604.15039 |