长上下文对大模型部署 / 超节点 / 多芯互联通信的影响 — Leader 汇报脑暴
任务：从"长上下文"这一主题，穷举可向管理层展开的汇报角度，并按"该不该讲 + 能不能用 Tier6 量化"排序，收敛出一条汇报主线。 本文档独立展开长上下文主题；它在 2026-05-22 leader 汇报脑暴 中是候选 C1a（被定位为 MoE EP 课题的开场铺垫）。
名词定义
本文档涉及的缩写、技术名词集中说明，后续各节默认沿用。
推理阶段与性能指标
| 名词 | 定义 |
|---|---|
| Prefill | 推理第一阶段，并行处理输入 prompt 的全部 token 生成首 token，attention 计算量随序列长度 n 呈 O(n²)，算力密集 |
| Decode | 推理后续阶段，逐 token 自回归生成，每步需读取全量 KVCache，访存密集 |
| KVCache | Key/Value 缓存，存历史 token 的 attention key/value，避免重算；显存占用随序列长度线性增长 |
| TTFT（Time To First Token） | 首 token 延迟，prefill 主导，长上下文下随 O(n²) 恶化 |
| TPOT（Time Per Output Token） | 单 token 生成延迟，decode 主导，随 KVCache 读取量 O(n) 恶化 |
| MFU（Model FLOPs Utilization） | 模型算力利用率，长上下文下因访存瓶颈与并行通信开销而退化 |
| 算术强度（Arithmetic Intensity） | FLOP / Byte 比值，决定负载落在 roofline 的算力区还是访存区 |
@tbl-bs-longctx-glossary-stage 推理阶段与性能指标：名词、定义
并行策略与互联
| 名词 | 定义 |
|---|---|
| TP（Tensor Parallelism） | 张量并行，矩阵乘按行/列切到多卡，通信主要是 all-reduce |
| SP（Sequence Parallelism） | 序列并行，把序列维切到多卡，降单卡激活/KV 显存 |
| CP（Context Parallelism） | 上下文并行，专为长序列，attention 跨卡协同计算 KV，通信是 all-gather / P2P |
| Ring Attention | CP 的一种实现，用环形 P2P 流水化传 KV 块，理论支持近无限上下文 |
| EP（Expert Parallelism） | 专家并行，MoE 不同 expert 分到不同卡，通信是 all-to-all（dispatch + combine） |
| scale-up | 单一 fabric 内紧耦合互联（NVLink / UALink），低延迟高带宽 |
| scale-out | 跨 fabric 松耦合互联（RoCE / InfiniBand），跨服务器 / 机柜 |
| 超节点（superpod） | 大 scale-up 域，如 NVL72 = 72 GPU 单 NVLink fabric，可当统一显存池 |
| PD 分离（Prefill-Decode Disaggregation） | prefill 与 decode 部署到不同集群各自优化，代价是 KVCache 跨集群传输 |
@tbl-bs-longctx-glossary-parallel 并行策略与互联：名词、定义
KV 与算法方法
| 名词 | 定义 |
|---|---|
| GQA / MQA | Grouped / Multi-Query Attention，多个 query head 共享 KV head，降 KV 体积 |
| MLA（Multi-head Latent Attention） | DeepSeek 架构级 KV 压缩，把 KV 投影到低秩潜空间存储 |
| PagedAttention | vLLM 按页管理 KVCache，降显存碎片，提利用率 |
| Prefix Caching | 复用相同前缀（如长 system prompt）的 KVCache，省重复 prefill |
| Chunked Prefill | 把长 prefill 切块，与 decode 交错调度，平滑算力尖峰 |
| 稀疏 / 线性 attention | 滑窗 / 块稀疏把 O(n²) 降到近线性；线性 attention / SSM（Mamba）改变 KV 增长曲线 |
| 位置编码外推 | RoPE + YaRN / NTK-aware / Position Interpolation，把短上下文训练的模型外推到更长上下文 |
@tbl-bs-longctx-glossary-kv KV 与算法方法：名词、定义
候选清单（按维度）
11 个维度，约 50 个候选。每个候选标注三个轻量评估标签（评分卡的简化视图）：
- 汇报优先级：▲ 必讲（核心论点） / ● 该讲（支撑） / ○ 背景（点到即止）
- 实现复杂度：指在 Tier6 / G5 上做出量化结果的工程量 — 低（现有模块直接出） / 中（需扩展） / 高（需新建子系统或平台不直接覆盖）
- 证据强度：公开 benchmark / 硬件 spec / 论文可校验程度 — 强 / 中 / 弱
除证据弱、平台不覆盖的安全 / 可靠性维度保留速览表外，其余维度的候选都在各表格下方附四要素展开——背景（这个话题为什么存在）、痛点（解决什么问题）、方法（业界怎么应对）、可量化性。
可量化性判断候选能否用建模仿真给出可信数字，分三档：能仿真量化（有闭式或可仿真模型，输入参数→输出曲线）/ 半量化（性能骨架可仿真，关键收益需真实 trace 或框架级仿真）/ 仅理论分析（涉及模型精度或能耗，纯性能仿真给不出可信数字）。它与表格里的"实现复杂度"正交——前者问"能不能仿真"，后者问"在本平台做要多少工程量"。
负载特征重构
| 候选 | 说明 | 优先级 | 复杂度 | 证据 |
|---|---|---|---|---|
| prefill-compute-bound prefill 算力密集化 | prefill attention 随 n² 增长，成算力黑洞 | ▲ | 低 | 强 |
| decode-memory-bound decode 访存密集化 | decode 每步读全量 KV，转为访存密集 | ▲ | 低 | 强 |
| ttft-tpot-divergence TTFT/TPOT 指标解耦 | TTFT（O(n²)）与 TPOT（O(n)）解耦，两指标需分别优化 | ▲ | 低 | 强 |
| arithmetic-intensity-shift 算术强度两极分化 | 长上下文把 prefill/decode 拉到 roofline 两极 | ● | 低 | 强 |
| batch-shape-irregularity 混批形状不规则 | 长短序列混批导致 padding 浪费，SLA 难保 | ○ | 中 | 中 |
@tbl-bs-longctx-cand-load 负载特征重构：候选、评估标签
prefill-compute-bound（prefill 算力密集化）
- 背景：prefill 并行处理输入 prompt 全部 token 生成首 token，attention 两两计算复杂度 O(n²)。
- 痛点：上下文从 4K 涨到 1M，prefill 计算量增长百万倍，TTFT 被算力拖垮。
- 方法：chunked prefill 切块平滑尖峰、稀疏 attention 降阶、CP 把单序列摊到多卡。
- 可量化：能仿真量化 —— FLOP vs 序列长度是闭式算力模型，roofline 直接出曲线。
decode-memory-bound（decode 访存密集化）
- 背景：decode 逐 token 自回归，每步读取全量 KVCache 才能算下一个 token。
- 痛点：KV 随历史线性增长，decode 从算力密集翻转为访存密集，TPOT 受 HBM 带宽限制。
- 方法：KV 压缩/量化减读取量、GQA/MQA 减 KV head、提高 batch 摊薄权重读取。
- 可量化：能仿真量化 —— 每步 KV 读取字节数是闭式，访存模型出 TPOT。
ttft-tpot-divergence（TTFT/TPOT 指标解耦）
- 背景：TTFT 由 prefill（O(n²)）决定，TPOT 由 decode（O(n)）决定，两者增长曲线不同。
- 痛点：单一优化目标无法同时压住两个指标，长上下文下二者解耦需分别优化。
- 方法：PD 分离让两阶段各自调度、chunked prefill 交错平衡、SLA 分别定义。
- 可量化：能仿真量化 —— 两条曲线分别由算力/访存模型给出。
arithmetic-intensity-shift（算术强度两极分化）
- 背景：算术强度（FLOP/Byte）决定负载落在 roofline 的算力区还是访存区。
- 痛点：长上下文把 prefill 推向算力极、decode 推向访存极，同一模型横跨 roofline 两端。
- 方法：用算术强度定位瓶颈，指导 prefill/decode 的硬件配比与并行策略。
- 可量化：能仿真量化 —— roofline 是标准分析模型。
batch-shape-irregularity（混批形状不规则）
- 背景：线上请求长短不一，长短序列混入同一 batch 需 padding 对齐。
- 痛点：padding 浪费算力、长尾长序列拉高整批延迟，SLA 难保证。
- 方法：continuous batching、按长度分桶调度、chunked prefill 拆解长请求。
- 可量化：半量化 —— padding 浪费可算，但 SLA 效果依赖真实请求 trace 驱动仿真。
KV Cache 显存墙
| 候选 | 说明 | 优先级 | 复杂度 | 证据 |
|---|---|---|---|---|
| kv-linear-growth KV 显存线性膨胀 | KV 显存 = 2·layers·heads·head_dim·seq·batch，长上下文吃满 HBM | ▲ | 低 | 强 |
| mla-compression MLA 低秩压缩 | MLA 低秩压缩 KV（DeepSeek 路线） | ● | 中 | 强 |
| kv-quantization KV 量化 | KV 量化 FP8/INT4 降显存，代价是精度与算子 | ● | 中 | 中 |
| kv-offload-cpu-ssd KV 下沉 CPU/SSD | KV 下沉 CPU/NVMe，靠互联带宽换显存容量 | ● | 中 | 中 |
| kv-cache-pooling KV 显存池化 | 跨卡/跨节点 KV 显存池化 | ● | 中 | 中 |
| gqa-mqa-sharing GQA/MQA 共享 KV head | GQA/MQA 减 KV head 数，质量换体积 | ○ | 低 | 强 |
| paged-attention 分页 KV 管理 | PagedAttention 按页管理降碎片（框架级） | ○ | 高 | 中 |
@tbl-bs-longctx-cand-kv KV Cache 显存墙：候选、评估标签
kv-linear-growth（KV 显存线性膨胀）
- 背景：KVCache 显存 = 2·layers·heads·head_dim·seq·batch，每个历史 token 都要存 K/V。
- 痛点：显存随序列线性增长，长上下文很快吃满单卡 HBM，成为部署的硬上限。
- 方法：压缩（MLA）、量化（FP8/INT4）、offload、池化，从不同角度推高单卡可承载长度。
- 可量化：能仿真量化 —— 显存占用是闭式公式，直接出 vs 序列长度曲线与单卡墙拐点。
mla-compression（MLA 低秩压缩）
- 背景：MLA（DeepSeek）把 KV 投影到低秩潜空间存储，是架构级 KV 压缩。
- 痛点：GQA/MQA 共享降体积有限，需要更激进的压缩支撑超长上下文。
- 方法：低秩投影只存潜向量，attention 时再上投影重建 K/V。
- 可量化：半量化 —— 显存节省比能算，但精度/质量影响只能靠真实模型实测，不可纯仿真。
kv-quantization（KV 量化）
- 背景：把 KVCache 从 FP16 量化到 FP8/INT4，按位宽比例直接降显存。
- 痛点：显存墙逼近，需要在不重训的前提下压缩已有 KV。
- 方法：分组量化、保留 outlier 通道、量化-反量化算子融合。
- 可量化：半量化 —— 体积收益线性可算，精度损失需实测。
kv-offload-cpu-ssd（KV 下沉 CPU/SSD）
- 背景：HBM 容量贵且有限，CPU 内存 / NVMe 容量大但带宽低。
- 痛点：单卡 HBM 放不下超长 KV，需要把冷 KV 下沉到更大但更慢的层级。
- 方法：按访问热度分层存储，预取 + 流水隐藏搬运延迟。
- 可量化：能仿真量化 —— 容量-带宽-延迟是层级访存模型，可算搬运开销与命中收益。
kv-cache-pooling（KV 显存池化）
- 背景：单卡显存孤立，跨卡/跨节点显存无法当一个池用。
- 痛点：长 KV 超单卡容量，但相邻卡可能有空闲显存。
- 方法：把多卡 HBM 聚成统一 KV 池，按需远程读取（依赖高带宽互联）。
- 可量化：能仿真量化 —— 池容量 + 跨卡访问延迟可建模，是超节点价值的直接支撑。
gqa-mqa-sharing（GQA/MQA 共享 KV head）
- 背景：多个 query head 共享一组 KV head，是最早的 KV 压缩手段。
- 痛点：每个 head 独立存 KV（MHA）体积过大。
- 方法：分组（GQA）或全共享（MQA）KV head，按 group 数权衡质量与体积。
- 可量化：半量化 —— KV 体积按 head 比例直接算，质量损失需实测。
paged-attention（分页 KV 管理）
- 背景：KVCache 连续分配产生大量碎片，利用率低（vLLM 提出）。
- 痛点：变长序列下预留 + 碎片浪费大量显存。
- 方法：按页（block）管理 KV，逻辑连续物理离散，类虚拟内存分页。
- 可量化：半量化 —— 利用率提升依赖真实请求分布，需框架级 trace 仿真而非解析模型。
互联通信放大
| 候选 | 说明 | 优先级 | 复杂度 | 证据 |
|---|---|---|---|---|
| attention-allgather-scaling attention KV all-gather 放大 | SP/CP 下 attention 的 KV all-gather 通信量随 n 线性放大 | ▲ | 中 | 中 |
| alltoall-moe-x-longctx MoE all-to-all × 长上下文 | MoE all-to-all 与长上下文叠加，通信量乘积式增长 | ▲ | 中 | 强 |
| bandwidth-becomes-bottleneck 带宽成为瓶颈 | 长上下文下互联带宽（非算力）成端到端瓶颈的拐点 | ▲ | 低 | 中 |
| topology-aware-routing-pressure 拓扑路由拥塞压力 | 大流量对路由算法（DOR/UGAL/ECMP）的拥塞压力 | ▲ | 中 | 中 |
| latency-vs-bandwidth-sensitivity 延迟 vs 带宽敏感度 | 长上下文偏带宽敏感，不同集合通信敏感度不同 | ● | 中 | 中 |
| kv-transfer-pd-disagg PD 分离 KV 跨节点传输 | PD 分离下 prefill→decode 的 KV 跨节点传输，单次 GB 级 | ● | 中 | 中 |
@tbl-bs-longctx-cand-comm 互联通信放大：候选、评估标签
attention-allgather-scaling（attention KV all-gather 放大）
- 背景：SP/CP 把序列切到多卡后，attention 需跨卡聚合各分片的 K/V。
- 痛点：all-gather 通信量随序列长度线性放大，长上下文下通信占比飙升。
- 方法：ring attention 流水化 P2P、overlap 通信与计算、选择性 gather。
- 可量化：能仿真量化 —— 通信量是序列长度×维度的闭式，comm-eval 直接出。
alltoall-moe-x-longctx（MoE all-to-all × 长上下文）
- 背景：MoE 用 all-to-all 做 expert dispatch/combine，长上下文增加 token 数。
- 痛点：通信量约等于 token 数 × expert 维度，长上下文 × MoE 呈乘积式增长。
- 方法：EP 分组、分层 all-to-all、token dropping、拓扑感知放置。
- 可量化：能仿真量化 —— all-to-all 通信量与拓扑延迟正是 comm-eval/G5 强项。
bandwidth-becomes-bottleneck（带宽成为瓶颈）
- 背景：传统认知里算力是瓶颈，长上下文改变了这个假设。
- 痛点：通信/访存量随 n 增长超过算力增长，端到端在某拐点被带宽限制。
- 方法：识别瓶颈翻转拐点，据此决定加带宽还是加算力。
- 可量化：能仿真量化 —— roofline + 通信模型可定位翻转拐点。
topology-aware-routing-pressure（拓扑路由拥塞压力）
- 背景：大流量在网络上需要路由算法（DOR/ECMP/UGAL）分配路径。
- 痛点：长上下文产生的大集合通信流量加剧链路拥塞与负载不均。
- 方法：自适应路由（UGAL）、多路径（ECMP/KSP）、拓扑感知放置降跨域流量。
- 可量化：能仿真量化 —— G5 指令级仿真拥塞，路由算法是团队既有能力。
latency-vs-bandwidth-sensitivity（延迟 vs 带宽敏感度）
- 背景：不同集合通信（all-reduce/all-gather/all-to-all）对延迟和带宽敏感度不同。
- 痛点：长上下文偏大消息（带宽敏感），但小消息算子仍延迟敏感，优化方向冲突。
- 方法：按消息大小区分优化、大消息分块流水、小消息聚合。
- 可量化：能仿真量化 —— 扫描延迟/带宽参数即得敏感度曲线。
kv-transfer-pd-disagg（PD 分离 KV 跨节点传输）
- 背景：PD 分离下 prefill 算完的 KV 要传给 decode 节点。
- 痛点：长上下文单请求 KV 达 GB 级，跨节点传输延迟可能抵消分离收益。
- 方法：选高带宽 fabric（NVLink/RDMA）、分层传输、与 decode 启动 overlap。
- 可量化：能仿真量化 —— 传输量/带宽是闭式延迟，但前提是公司做 PD 分离（当前不做）。
并行策略演进
| 候选 | 说明 | 优先级 | 复杂度 | 证据 |
|---|---|---|---|---|
| context-parallel 上下文并行 | CP 专为长上下文，attention 跨卡协同 | ▲ | 中 | 强 |
| parallelism-x-context-tradeoff 并行度 × 上下文权衡 | 并行度↑降显存但↑通信，sweet spot 随上下文漂移 | ▲ | 中 | 中 |
| sequence-parallel 序列并行 | SP 沿序列维切分降激活/KV 显存 | ● | 中 | 中 |
| ring-attention 环形 attention | 环形 P2P 流水化 attention，支持近无限上下文 | ● | 高 | 强 |
| tp-sp-hybrid TP+SP 混合切分 | TP+SP 混合切分在长上下文下的最优配比 | ● | 中 | 中 |
| head-parallel-attention head 维并行 | 按 attention head 切分及其通信代价 | ○ | 高 | 中 |
@tbl-bs-longctx-cand-parallel 并行策略演进：候选、评估标签
context-parallel（上下文并行）
- 背景：CP 专为长序列，把序列维切到多卡，attention 跨卡协同算 KV。
- 痛点：单卡放不下超长序列的激活与 KV，必须沿序列切分。
- 方法：各卡持有序列分片，用 all-gather / ring P2P 交换 KV 完成全局 attention。
- 可量化：能仿真量化 —— 通信模式明确，需在 comm-eval 建 CP 的 all-gather/ring 模式。
parallelism-x-context-tradeoff（并行度 × 上下文权衡）
- 背景：提高并行度降单卡显存，但增加跨卡通信。
- 痛点：最优并行配置随上下文长度漂移，固定配置非全局最优。
- 方法：扫描 TP/SP/CP/EP 组合，找给定上下文下的通信-显存 sweet spot。
- 可量化：能仿真量化 —— 多维参数扫描正是仿真平台所长。
sequence-parallel（序列并行）
- 背景：SP 沿序列维切分，降低 LayerNorm/Dropout 等的激活与 KV 显存。
- 痛点：TP 切不到的序列维激活仍占大量显存。
- 方法：序列维切分，配合 all-gather/reduce-scatter 在 TP 边界衔接。
- 可量化：能仿真量化 —— 切分后通信量可建模。
ring-attention（环形 attention）
- 背景：CP 的一种实现，用环形 P2P 流水化传 KV 块。
- 痛点：朴素 all-gather 需一次性聚合全部 KV，峰值显存与通信高。
- 方法：环形拓扑逐块传 KV，计算与传输流水，理论支持近无限上下文。
- 可量化：能仿真量化 —— P2P 流水延迟可建模，但建模工程量偏高。
tp-sp-hybrid（TP+SP 混合切分）
- 背景：TP 切权重、SP 切序列，二者可叠加。
- 痛点：纯 TP 或纯 SP 在长上下文下都非最优。
- 方法：TP+SP 混合切分，搜索最优配比。
- 可量化：能仿真量化 —— 配比扫描可量化。
head-parallel-attention（head 维并行）
- 背景：attention 可按 head 维度切到多卡（类 TP 的一种）。
- 痛点：head 数有限，切分粒度受限且引入通信。
- 方法：按 head 分组切分，配合 context parallel（如 LoongTrain）。
- 可量化：能仿真量化 —— 通信代价可建模，工程量偏高。
超节点架构价值
| 候选 | 说明 | 优先级 | 复杂度 | 证据 |
|---|---|---|---|---|
| nvlink-domain-as-memory-pool NVLink 域当显存池 | 超节点大 NVLink 域当统一显存池，长 KV 不受单卡限制 | ▲ | 中 | 中 |
| high-bw-domain-justification 高带宽域必要性论证 | 用长上下文负载论证"为什么要超节点而非松散机架" | ▲ | 中 | 中 |
| scale-up-vs-scale-out 紧耦合 vs 松耦合选择 | 长上下文偏好 scale-up 还是 scale-out，拐点在哪 | ▲ | 中 | 中 |
| intra-vs-inter-node-bw-gap 节点内外带宽鸿沟 | 节点内外带宽鸿沟被长上下文放大成性能悬崖 | ● | 低 | 强 |
| superpod-size-sweep 超节点规模扫描 | 超节点规模（72/256/…）对长上下文的边际收益曲线 | ● | 中 | 中 |
@tbl-bs-longctx-cand-superpod 超节点架构价值：候选、评估标签
nvlink-domain-as-memory-pool（NVLink 域当显存池）
- 背景：超节点（如 NVL72）是单一 NVLink fabric，72 GPU 高带宽紧耦合。
- 痛点：长 KV 超单卡 HBM，松散机架跨节点带宽不足以做显存池。
- 方法：把大 NVLink 域当统一显存池，长 KV 跨卡存取不受单卡限制。
- 可量化：能仿真量化 —— 池容量 + 跨卡带宽可建模，但超节点实测数据少，需外推并标注可信度。
high-bw-domain-justification（高带宽域必要性论证）
- 背景：超节点比松散机架贵，需要负载证据支撑投资。
- 痛点：缺"为什么非超节点不可"的量化论证。
- 方法：用长上下文负载（高带宽 + 大显存需求）反推超节点必要性。
- 可量化：半量化 —— 性能收益可仿真，但结论依赖外推，证据强度中等。
scale-up-vs-scale-out（紧耦合 vs 松耦合互联选择）
- 背景：scale-up（NVLink）低延迟高带宽但规模有限，scale-out（RoCE/IB）可扩展但带宽低。
- 痛点：长上下文该用紧耦合还是松耦合，切换拐点不清。
- 方法：建带宽阶梯模型，找 scale-up 收益被规模上限反超的切换点。
- 可量化：能仿真量化 —— 带宽阶梯 + 通信量模型可定位拐点。
intra-vs-inter-node-bw-gap（节点内外带宽鸿沟）
- 背景：节点内（NVLink ~TB/s）与节点间（RoCE ~百 GB/s）带宽差一个数量级。
- 痛点：长上下文大流量一旦跨节点，带宽鸿沟变成性能悬崖。
- 方法：拓扑感知放置把高频通信限制在节点内、降跨节点流量。
- 可量化：能仿真量化 —— 带宽阶梯是硬件 spec，跨域流量可算。
superpod-size-sweep（超节点规模扫描）
- 背景：超节点规模可选 72/256/… GPU，规模越大成本越高。
- 痛点：domain 规模对长上下文的边际收益未知，盲目堆大浪费成本。
- 方法：扫描 domain size，画长上下文下的边际收益曲线找拐点。
- 可量化：能仿真量化 —— 规模扫描可量化，但大规模依赖外推。
成本与能效
| 候选 | 说明 | 优先级 | 复杂度 | 证据 |
|---|---|---|---|---|
| mfu-degradation-longctx 长上下文 MFU 退化 | 长上下文下 MFU 退化分析 | ▲ | 低 | 强 |
| cost-per-token-vs-context 每 token 成本 vs 上下文 | 每 token 成本随上下文长度的增长曲线 | ▲ | 低 | 中 |
| hbm-cost-dominance HBM 成本主导 | 长上下文把成本结构从算力主导推向 HBM 容量主导 | ● | 低 | 中 |
| interconnect-capex-share 互联 CAPEX 占比上升 | 互联硬件在长上下文部署中的 CAPEX 占比上升 | ● | 中 | 中 |
| energy-per-token 每 token 能耗 | 每 token 能耗随上下文变化（平台能耗建模弱） | ○ | 中 | 弱 |
@tbl-bs-longctx-cand-cost 成本与能效：候选、评估标签
mfu-degradation-longctx（长上下文 MFU 退化）
- 背景：MFU 衡量算力利用率，长上下文下因访存与通信开销退化。
- 痛点：长上下文下 MFU 大幅下降，硬件买了用不满。
- 方法：定位退化来源（访存/通信），针对性优化提利用率。
- 可量化：能仿真量化 —— MFU = 有效 FLOP / 峰值 FLOP，仿真直接出。
cost-per-token-vs-context（每 token 成本 vs 上下文）
- 背景：每 token 成本随上下文长度变化，是定价与容量规划基础。
- 痛点：长上下文每 token 成本上升曲线不清，难定价难规划。
- 方法：综合算力/显存/互联成本，建每 token 成本 vs 上下文曲线。
- 可量化：能仿真量化 —— 成本模型 + 性能模型组合可出曲线。
hbm-cost-dominance（HBM 成本主导）
- 背景：长上下文吃显存，HBM 在 BOM 中占比上升。
- 痛点：成本结构从算力主导转向 HBM 容量主导，采购重心变。
- 方法：BOM 拆解算 HBM 占比随上下文的变化。
- 可量化：能仿真量化 —— BOM 成本模型可算。
interconnect-capex-share（互联 CAPEX 占比上升）
- 背景：长上下文放大互联流量，需要更强互联硬件。
- 痛点：互联（交换机/光模块/线缆）CAPEX 占比上升但常被低估。
- 方法：把互联硬件计入部署成本，算其 CAPEX 占比。
- 可量化：能仿真量化 —— 互联 BOM 可建模。
energy-per-token（每 token 能耗）
- 背景：每 token 能耗是 TCO 与碳排的核心指标。
- 痛点：长上下文下能耗如何变化缺数据。
- 方法：按算力/访存/通信活动量估算能耗。
- 可量化：仅理论分析 —— 平台能耗建模弱，缺器件级功耗数据，证据弱。
PD 分离与 KV 迁移
约束：公司当前部署未做 PD 分离（沿用 2026-05-22 脑暴 v0.3 决策），本维度整体降级为对照背景，不作主线。
| 候选 | 说明 | 优先级 | 复杂度 | 证据 |
|---|---|---|---|---|
| pd-disaggregation-motivation PD 分离动因 | 长上下文加剧 prefill/decode 资源错配，催生 PD 分离 | ● | 中 | 强 |
| chunked-prefill 分块 prefill | Chunked Prefill 平滑长 prefill 算力尖峰 | ● | 中 | 中 |
| kv-transfer-over-fabric KV 走哪条 fabric | KV 走哪条 fabric（NVLink/RDMA/PCIe）对端到端延迟的影响 | ● | 中 | 中 |
| kv-migration-cost KV 迁移代价 | PD 分离的代价：KV 跨节点搬运，长上下文下量巨大 | ● | 高 | 中 |
| prefill-pool-decode-pool prefill 池 / decode 池配比 | prefill 池/decode 池异构配比 | ○ | 高 | 中 |
@tbl-bs-longctx-cand-pd PD 分离与 KV 迁移：候选、评估标签
pd-disaggregation-motivation（PD 分离动因）
- 背景：prefill 算力密集、decode 访存密集，同集群部署资源利用率互相拖累。
- 痛点：长上下文加剧两阶段资源错配，混部 MFU 低。
- 方法：prefill/decode 部署到不同集群各自优化（PD 分离）。
- 可量化：能仿真量化 —— 资源利用率可建模，但公司当前不做 PD 分离（假设不成立）。
chunked-prefill（分块 prefill）
- 背景：长 prefill 一次性算完产生算力尖峰，挤占 decode。
- 痛点：长上下文 prefill 尖峰让 decode 卡顿，TPOT 抖动。
- 方法：把长 prefill 切块，与 decode 交错调度平滑尖峰。
- 可量化：半量化 —— 算力分布可算，但调度效果需调度器/trace 仿真。
kv-transfer-over-fabric（KV 走哪条 fabric）
- 背景：PD 分离时 KV 可走 NVLink/RDMA/PCIe 不同 fabric。
- 痛点：fabric 选择直接影响 KV 传输延迟与端到端 SLA。
- 方法：按 fabric 带宽-延迟特性选路、分层传输。
- 可量化：能仿真量化 —— 各 fabric 传输延迟可建模。
kv-migration-cost（KV 迁移代价）
- 背景：PD 分离的代价是 prefill→decode 的 KV 跨节点搬运。
- 痛点：长上下文 KV 量巨大，迁移开销可能抵消分离收益。
- 方法：压缩后传输、与 decode overlap、就近调度降迁移距离。
- 可量化：能仿真量化 —— 迁移量/带宽是闭式，但前提是做 PD 分离。
prefill-pool-decode-pool（prefill 池 / decode 池配比）
- 背景：PD 分离后 prefill 池与 decode 池可用不同硬件配比。
- 痛点：两池配比不当导致一边排队一边空闲。
- 方法：按负载比例配 prefill/decode 池的卡数与型号。
- 可量化：半量化 —— 排队/利用率可仿真，但需真实请求到达分布。
仿真平台落点（本项目结合）
| 候选 | 说明 | 优先级 | 复杂度 | 证据 |
|---|---|---|---|---|
| tier6-longctx-modeling Tier6 长上下文参数化建模 | Tier6 参数化建模序列长度对计算/访存/通信的影响 | ▲ | 低 | 强 |
| comm-eval-longctx-sweep 通信评估长上下文扫描 | 通信评估扫描长上下文 × 拓扑 × 路由延迟矩阵 | ▲ | 低 | 中 |
| g5-kv-traffic-sim G5 KV 流量仿真 | G5 指令级仿真长上下文下 KV 流量与互联拥塞 | ▲ | 中 | 中 |
| superpod-roi-quantification 超节点 ROI 量化 | 用 Tier6 量化"长上下文场景下超节点的 ROI" | ● | 中 | 中 |
| what-if-topology-design 反推最优拓扑设计 | 给定长上下文负载反推最优拓扑/带宽配置 | ● | 中 | 中 |
@tbl-bs-longctx-cand-platform 仿真平台落点：候选、评估标签
本维度候选是"做量化的工具"而非"待量化的对象"，因此"可量化性"一栏对它们恒为"能仿真"——这里标注的是各候选当前的覆盖程度与需扩展量。
tier6-longctx-modeling（Tier6 长上下文参数化建模）
- 背景：量化长上下文影响需把序列长度作为一等参数贯穿计算/访存/通信建模。
- 痛点：现有评估多以固定序列长度为输入，长序列端到端覆盖未系统化。
- 方法：参数化序列长度，在 Math 代数模型中贯穿三类开销。
- 可量化：能仿真量化 —— 平台核心能力，现有模块可直接出。
comm-eval-longctx-sweep（通信评估长上下文扫描）
- 背景：通信评估可扫描多维参数出延迟矩阵。
- 痛点：长上下文 × 拓扑 × 路由的组合空间缺系统扫描。
- 方法：用 comm-eval 跑长上下文 × 拓扑 × 路由延迟矩阵。
- 可量化：能仿真量化 —— comm-eval 现成能力，是第一梯队"互联放大"的核心证据图。
g5-kv-traffic-sim（G5 KV 流量仿真）
- 背景：G5 指令级事件驱动仿真可还原细粒度流量与拥塞。
- 痛点：长上下文下 KV 流量在网络上的拥塞缺指令级证据。
- 方法：用 G5 仿真长上下文 KV 流量与互联拥塞。
- 可量化：能仿真量化 —— G5 现成，需扩展长上下文 KV 流量场景（工程量中）。
superpod-roi-quantification（超节点 ROI 量化）
- 背景：超节点投资需要 ROI 依据。
- 痛点：长上下文场景下超节点 ROI 缺量化。
- 方法：用性能 + 成本模型算超节点相对松散机架的 ROI 曲线。
- 可量化：能仿真量化 —— 性能 + 成本可组合算，但 ROI 依赖性能外推，需标注可信度。
what-if-topology-design（反推最优拓扑设计）
- 背景：给定负载反推最优拓扑是拓扑寻优器的能力。
- 痛点：长上下文负载对应的最优拓扑/带宽配置未知。
- 方法：用寻优器对长上下文负载做拓扑/带宽反向设计。
- 可量化：能仿真量化 —— 寻优器现成能力。
算法侧减负
| 候选 | 说明 | 优先级 | 复杂度 | 证据 |
|---|---|---|---|---|
| sparse-attention 稀疏 attention | 稀疏 attention（滑窗/块稀疏）把 n² 降到近线性 | ● | 中 | 强 |
| linear-attention 线性 attention / SSM | 线性 attention / SSM（Mamba）改变 KV 增长曲线 | ○ | 中 | 强 |
| attention-sink-streaming attention sink 流式 | StreamingLLM / attention sink，固定显存处理无限流 | ○ | 中 | 强 |
| kv-eviction-policy KV 驱逐策略 | KV 驱逐策略（H2O 等），只留重要 token 的 KV | ○ | 中 | 中 |
@tbl-bs-longctx-cand-algo 算法侧减负：候选、评估标签
sparse-attention（稀疏 attention）
- 背景：标准 attention 是 O(n²)，但实际注意力矩阵高度稀疏，大量 token 对贡献极小。
- 痛点：长上下文下 O(n²) 的计算与显存不可承受。
- 方法：滑窗（只看邻近）、块稀疏、Longformer/BigBird 固定稀疏模式，把复杂度降到近线性。
- 可量化：半量化 —— FLOP/显存节省可算，但稀疏模式对模型质量的影响需真实实测。
linear-attention（线性 attention / SSM）
- 背景：线性 attention 与 SSM（Mamba）用固定大小状态而非全量 KV 表示历史。
- 痛点：KV 随序列线性增长是显存墙根因，需从根上改增长曲线。
- 方法：核函数近似 softmax（线性 attention）或状态空间递归（Mamba），KV 退化为固定状态。
- 可量化：半量化 —— 显存增长曲线变平可算，但模型能力/质量改变需实测。
attention-sink-streaming（attention sink 流式）
- 背景：StreamingLLM 发现保留最初几个 token（sink）+ 滑窗即可稳定生成。
- 痛点：朴素滑窗丢弃早期 token 会导致模型崩溃，无法处理无限流。
- 方法：固定保留 sink token + 近期窗口，以固定显存处理无限长流。
- 可量化：半量化 —— 固定显存占用可算，但长程信息保留质量需实测。
kv-eviction-policy（KV 驱逐策略）
- 背景：并非所有历史 token 的 KV 对后续生成都重要。
- 痛点：全量保留 KV 显存不可持续，需要选择性丢弃。
- 方法：按注意力分数（H2O）、位置等启发式驱逐低价值 token 的 KV。
- 可量化：仅理论分析 —— 驱逐对生成质量的影响只能靠真实模型实验，纯仿真给不出。
软件栈 / 调度框架
| 候选 | 说明 | 优先级 | 复杂度 | 证据 |
|---|---|---|---|---|
| prefix-caching 前缀缓存复用 | Prefix Caching / KV 复用，长 system prompt 省 prefill | ● | 中 | 中 |
| vllm-sglang-longctx vLLM/SGLang 长上下文优化 | vLLM/SGLang 长上下文优化（PagedAttention/RadixAttention） | ○ | 高 | 中 |
| scheduling-policy-longctx 长短请求混合调度 | 长短请求混合调度（优先级/抢占/公平） | ○ | 高 | 中 |
| speculative-decoding-x-longctx 投机解码 × 长上下文 | 投机解码在长上下文下的收益变化 | ○ | 高 | 中 |
@tbl-bs-longctx-cand-stack 软件栈 / 调度框架：候选、评估标签
prefix-caching（前缀缓存复用）
- 背景：多请求常共享相同前缀（长 system prompt、few-shot 示例）。
- 痛点：每个请求重算相同前缀的 prefill 是巨大浪费。
- 方法：缓存公共前缀的 KV（RadixAttention 树形复用），命中则跳过重算。
- 可量化：半量化 —— 命中率与省下的 prefill 可算，但依赖真实请求的前缀分布。
vllm-sglang-longctx（vLLM/SGLang 长上下文优化）
- 背景：vLLM/SGLang 是主流推理框架，集成多种长上下文优化。
- 痛点：长上下文下显存碎片、调度、前缀复用需要框架级协同。
- 方法：PagedAttention 分页 + continuous batching + RadixAttention 前缀树。
- 可量化：半量化 —— 端到端吞吐提升依赖框架内部实现与真实负载，需实测。
scheduling-policy-longctx（长短请求混合调度）
- 背景：线上长短请求混合，调度策略决定资源分配。
- 痛点：长请求占资源久挤占短请求 SLA，公平与吞吐冲突。
- 方法：优先级 / 抢占 / 公平队列、chunked prefill 让长请求可中断。
- 可量化：半量化 —— SLA/吞吐效果需真实请求到达分布驱动的调度仿真。
speculative-decoding-x-longctx（投机解码 × 长上下文）
- 背景：投机解码用小模型草拟、大模型验证以加速 decode。
- 痛点：长上下文下 KV 读取已是瓶颈，投机解码收益是否仍成立不清。
- 方法：draft-verify，长上下文下需评估草稿命中率与 KV 重复读取代价的权衡。
- 可量化：仅理论分析 —— 草稿命中率取决于真实模型与数据，纯仿真无法给可信收益。
安全 / 可靠性
| 候选 | 说明 | 优先级 | 复杂度 | 证据 |
|---|---|---|---|---|
| slo-tail-latency SLO 长尾延迟 | 超长上下文长尾请求对 SLO 的冲击与隔离 | ○ | 中 | 中 |
| fault-domain-longctx 故障域放大 | 长上下文请求占资源久，单点故障波及面大 | ○ | 高 | 弱 |
| kv-checkpoint-recovery KV 检查点恢复 | 请求中断后 KV 保存/恢复，避免重算长 prefill | ○ | 高 | 弱 |
| multi-tenancy-isolation 多租户隔离 | 多租户下长上下文请求的显存/带宽抢占隔离 | ○ | 高 | 弱 |
@tbl-bs-longctx-cand-safety 安全 / 可靠性：候选、评估标签
可量化性分布观察
把四要素里的"可量化"一栏横向汇总，候选清楚分成三类，且分界有规律：
- 能建模仿真量化（多数）：落在性能 / 容量 / 通信 / 成本的候选——prefill FLOP、KV 显存公式、通信量、延迟、MFU、ROI——都有闭式或可仿真模型，输入参数即输出数字曲线。这是汇报里能摆"硬数据图"的部分。
- 半量化：涉及框架内部状态或真实请求分布的候选——PagedAttention 碎片率、chunked prefill 调度效果、batch 混批 SLA、PD 池配比——性能骨架能仿真，但关键收益要真实 trace 或框架级仿真才可信。
- 仅理论分析：涉及模型精度 / 质量损失（MLA、KV 量化、GQA 的质量换体积）和能耗的候选——只能定性论证或需真实模型跑实验，纯性能仿真给不出可信数字。
一条分界规律："算 bit 和延迟"的能仿真，"算精度和调度效果"的只能实测或理论。这条线提示汇报时哪些结论可以直接摆数字、哪些只能给定性判断并标注证据边界——也正好与第三梯队"算法侧减负 / 软件栈"普遍落在半量化或仅理论一致，印证它们排序靠后的合理性。
业界对标 — 现在的大模型怎么实现超长上下文
把"实现超长上下文"拆成三层，正好对应上面的维度：架构层让模型"能看长"，训练层让模型"学会长"，推理部署层让模型"跑得起长"。Tier6 关注的是第三层（部署/互联）。
三层技术路线
| 层次 | 解决的问题 | 代表方法 | 落到哪些维度 |
|---|---|---|---|
| 架构 / 位置编码 | 模型"能不能"看到长上下文 | 位置编码外推（RoPE + YaRN / NTK-aware / Position Interpolation）；稀疏 / 线性 attention；attention sink（StreamingLLM）；KV 压缩架构（GQA/MQA/MLA） | 算法侧减负、KV 显存墙 |
| 训练 | 模型"学不学得会"长依赖 | 长序列训练靠 Context / Sequence Parallel + Ring Attention 把单条长序列的 attention 切到多卡（单卡显存放不下激活）；head + context 混合并行（LoongTrain） | 并行策略演进（训练侧，不在部署范围） |
| 推理部署 | 长上下文"跑不跑得起、跑得快不快" | KV 管理（PagedAttention 分页 / 量化 / offload / 压缩 / 驱逐 / prefix caching）；计算调度（chunked prefill / continuous batching）；分布式推理（Context Parallel 把 1M token 的 KV 跨 GPU，用 ring / all-gather 通信；PD 分离） | 互联通信放大、KV 显存墙、超节点价值、PD 分离 |
@tbl-bs-longctx-three-layer 超长上下文实现的三层技术路线
一句话：超长上下文不是单点突破，而是「位置编码外推让模型能看长 → 稀疏/线性注意力和 KV 压缩降低单 token 代价 → Context Parallel + KV 管理把长序列摊到多卡多节点跑起来」三者叠加。其中部署侧的核心矛盾是 KV 随序列线性膨胀 → 单卡放不下 → 被迫跨卡切分 → 互联通信成新瓶颈，这正是本汇报的主线。
关键来源
| 技术方向 | 代表来源 |
|---|---|
| 长上下文建模全景综述 | A Comprehensive Survey on Long Context Language Modeling (arXiv 2503.17407) |
| KV Cache 管理 / 优化综述 | Survey on LLM Acceleration based on KV Cache Management (arXiv 2412.19442)，KV Cache Optimization Strategies (arXiv 2603.20397) |
| Context Parallel 百万 token 推理 | Context Parallelism for Scalable Million-Token Inference (Meta, arXiv 2411.01783) |
| 训练侧长序列混合并行 | LoongTrain: head + context parallelism (arXiv 2406.18485) |
| 工程实践：TP / CP / EP 扩展推理 | Meta Engineering: Scaling LLM Inference (2025-10-17) |
| 百万 token 高效训练 | NVIDIA: Scaling to Millions of Tokens |
@tbl-bs-longctx-sources 超长上下文实现：关键业界来源
数据可信度说明：上述来源来自 webserp 实时检索，URL 与标题已核对；但论文内部的具体数字（如某方法降 KV X%）落地为正式汇报材料前需逐条 verify。
排序方法与评分卡
reporting-angle 类型本应用 MoSCoW，但你明确要求分析"实现复杂度、落地可能性"——这是可行性评估，单纯 MoSCoW 四桶分类承载不了。所以改用 Weighted Scoring（加权评分卡）：6 个维度各打 1-5 分，加权求和得综合分。
评分卡同时回答两个问题：该不该讲（战略说服力 / 技术差异化 / 时效热度）和能不能用 Tier6 量化讲（平台契合度 / 实现复杂度 / 证据可得性）。
| 评分维度 | 权重 | 含义 | 5 分 = | 1 分 = |
|---|---|---|---|---|
| 战略说服力 | 0.25 | 对管理层投资/方向决策的相关性 | 直接支撑决策 | 仅技术细节 |
| 平台契合度 | 0.20 | Tier6 / G5 现有能力能否建模量化 | 现有模块直接出 | 平台不覆盖 |
| 实现复杂度（反向） | 0.20 | 做出量化结果的工程量，越低分越高 | 现成能力 | 需新建子系统 |
| 证据可得性 | 0.15 | 公开 benchmark / 硬件 spec 可校验 | 数据充分可信 | 无公开数据 |
| 技术差异化 | 0.10 | 是否体现团队壁垒而非人尽皆知 | 团队独有能力 | 行业常识 |
| 时效热度 | 0.10 | 是否踩中超节点 / 长上下文当前热点 | 当下最热 | 旧话题 |
@tbl-bs-longctx-rubric 排序评分卡：6 维度、权重、含义
权重设计理由：战略说服力 0.25 最高——这是给领导汇报，讲不到决策点的内容再精巧也没用；平台契合度 + 实现复杂度合计 0.40——课题必须能用 Tier6 真做出数据，否则是空谈；差异化与时效各 0.10，是加分项不是决定项。
收敛矩阵（加权评分）
11 个维度按综合分降序排列。每行分值已按评分卡逐项打分（打分理由见下方分层说明）。
| 排名 | 维度 | 战略 0.25 | 平台 0.20 | 易建 0.20 | 证据 0.15 | 差异 0.10 | 时效 0.10 | 综合 | 梯队 |
|---|---|---|---|---|---|---|---|---|---|
| 1 | 互联通信放大 | 5 | 5 | 4 | 4 | 4 | 5 | 4.55 | 一 |
| 2 | 负载特征重构 | 4 | 5 | 5 | 5 | 2 | 3 | 4.25 | 一 |
| 3 | 仿真平台落点 | 4 | 5 | 4 | 4 | 5 | 3 | 4.20 | 一 |
| 4 | KV Cache 显存墙 | 4.5 | 4 | 4 | 4 | 3 | 4 | 4.03 | 一 |
| 5 | 超节点架构价值 | 5 | 4 | 3 | 3 | 4 | 5 | 4.00 | 一 |
| 6 | 成本与能效 | 5 | 4 | 4 | 3 | 2 | 3 | 3.80 | 二 |
| 7 | 并行策略演进 | 4 | 4 | 3 | 3 | 4 | 4 | 3.65 | 二 |
| 8 | PD 分离与 KV 迁移 | 4 | 3 | 2 | 4 | 4 | 5 | 3.50 | 二 |
| 9 | 算法侧减负 | 3 | 3 | 3 | 3 | 3 | 4 | 3.10 | 三 |
| 10 | 软件栈 / 调度框架 | 3 | 2 | 3 | 4 | 2 | 3 | 2.85 | 三 |
| 11 | 安全 / 可靠性 | 3 | 2 | 2 | 2 | 2 | 2 | 2.25 | 三 |
@tbl-bs-longctx-converge 收敛矩阵：11 维度加权评分排序
第一梯队（必讲核心，综合分 ≥ 4.0）
构成汇报主干，5 个维度恰好串成一条因果链。
- 互联通信放大（4.55） — 排名第一。战略 5（直接论证互联/超节点投资）、平台 5（comm-eval + topo_routing 正是团队强项）、时效 5（超节点是当下最热）、差异 4（拓扑路由量化是壁垒）。这是汇报的核心论点。
- 负载特征重构（4.25） — 平台 5 + 易建 5 + 证据 5（TTFT/TPOT/MFU/roofline 全现成、有公开 benchmark 校验），差异 2（基础认知不独特）。作开场铺垫最佳：低成本、可信、自然引出问题。
- 仿真平台落点（4.20） — 差异 5（团队独有能力）+ 平台 5。作收尾：把前面所有论点收到"而这些 Tier6 都能量化"。
- KV Cache 显存墙（4.03） — 战略 4.5（KV 是长上下文一切问题的第一性原因）。讲清"KV 为什么放不下"，是通信放大的前置因果。
- 超节点架构价值（4.00） — 战略 5 + 时效 5，但易建 3 + 证据 3（超节点实测数据少，仿真依赖外推）。作"解药"论证。
第二梯队（该讲支撑，3.4 ≤ 综合分 < 4.0）
主线的补充论据，时间够就讲，不够可压缩成一页。
- 成本与能效（3.80） — 战略 5（领导关心钱），但差异 2。作主线的"经济性账"补充。
- 并行策略演进（3.65） — 差异 4，但易建 3（CP/Ring Attention 建模有工程量）。讲"为什么被迫切分"的机制。
- PD 分离与 KV 迁移（3.50） — 时效 5、差异 4，但易建 2 且公司当前不做 PD 分离（假设不成立），仅作对照背景，不作主线。
第三梯队（背景，综合分 < 3.4）
点到即止或放附录，平台契合度低或与互联主线远。
- 算法侧减负（3.10） — 属架构层而非部署层，作"减负手段"一笔带过。
- 软件栈 / 调度框架（2.85） — 平台 2（框架内部调度非 Tier6 建模范围）。
- 安全 / 可靠性（2.25） — 全项低分，平台不建模故障域，证据弱。本次不讲。
推荐汇报主线
把第一梯队 5 个维度（+ 第二梯队的并行/成本）串成一条因果链叙事，而非 50 个点平铺：
长上下文（1M+ 成为主流需求）
│
├─① 负载特征重构 ── prefill 算力密集化 + decode 访存密集化，TTFT/TPOT 解耦 ［开场：为什么是问题］
│
├─② KV Cache 显存墙 ── KV 随序列线性膨胀，单卡 HBM 放不下 ［第一性原因］
│
├─③ 并行策略演进 ── 被迫上 SP/CP/Ring Attention 把序列切到多卡 ［机制：被迫切分］
│
├─④ 互联通信放大 ── 切分的代价：attention all-gather / KV 跨芯流量随 n 放大，
│ 互联带宽（非算力）成新瓶颈 ★核心论点★
│
├─⑤ 超节点架构价值 ── 大 NVLink 域 = 高带宽 + 统一显存池，
│ 恰好是长上下文最吃的资源 → 论证超节点必要性 ［解药］
│
├─⑥ 成本与能效 ── 成本结构从算力主导转向 HBM + 互联主导 ［经济性账］
│
└─⑦ 仿真平台落点 ── 上述每一步 Tier6 都能参数化量化：
长上下文 × 拓扑 × 路由的延迟矩阵、超节点 ROI 曲线 ［收尾：团队价值］
一句话主线：长上下文把推理瓶颈从"算力"推向"互联与显存"，超节点是当前最优解，而 Tier6 能把这条因果链每一步量化成决策依据。
开放问题
待决定
- 汇报时长：30 分钟 → 只讲第一梯队 5 维主线；60 分钟 → 加第二梯队成本/并行。哪个时长？
- 落脚点：主线收尾在"超节点必要性"（偏硬件投资决策）还是"Tier6 能量化"（偏平台能力展示）？两者评分接近（4.00 vs 4.20），取决于领导更想听"该不该买超节点"还是"团队能做什么"。
- 是否做系列 TCB：长上下文主线单独成篇，还是与 2026-05-22 的 MoE EP 主线合成系列？
待补量化（落地为 TCB 前）
- 长上下文 × 拓扑 × 路由延迟矩阵 — comm-eval 现成能力可直接跑，是第一梯队"互联通信放大"的核心证据图。
- 超节点 ROI 曲线 — scale-up domain size 扫描（72/256/…）对长上下文的边际收益，证据 3（依赖仿真外推），需标注可信度。
- 业界数字二次核实 — 业界对标段引用的论文内部数字（KV 降幅、CP 通信占比）需逐条 verify，当前仅核对了 URL 与标题。
待补能力（若选中相关候选）
- G5 长上下文 KV 流量仿真（g5-kv-traffic-sim，复杂度中）— 若主线要展示指令级 KV 拥塞，需扩展 G5。
- CP / Ring Attention 通信建模（复杂度中-高）— 若第二梯队"并行策略演进"要量化，comm-eval 需建 CP 的 all-gather / ring P2P 模式。