TL;DR

每年的假期确实是一个让人停下来好好思考的机会, 像一颗少了很多“中断”的处理器,效率提高不少. 似乎还有两天又要上班了, 记录一些文字吧... 

前些日子云栖大会结束后同时开启了两个项目: 一个是 Off-Policy 的 RL 后训练算法上的分析, 回归到一个很基础的原点来看有好多细节可以挖掘. 另一个项目开启了一颗新的 XPU 架构的研究, 类似于 OpenAI Janapeno 但又有很多新的结合模型架构的理解, 当然后一个项目涉密不太会多说什么.

而两者的交集出现在了一个新的问题上, 一个 10T 参数模型的 AI Infra 需要什么? 想写一下这个话题是工业界似乎又有大量的误区, 甚至是盲目的设计一些局部次优的东西. 首先我们从模型架构的层面谈谈 10T 的模型应该长什么样子, 然后再来展开分析 AI Infra 需要什么.

1. 模型架构

1.1 为什么还需要Scaling到 10T 的模型?

首先得回答一个问题, 为什么要 Scaling 到 10T 的规模, 在纯语言模型的时代, 通常的训练数据也就是一些常见的互联网上的语料, 大概数据规模在 35T token 左右, 事实上模型的参数规模受到训练数据规模的约束. 而在 Agentic 时代或者是很快会到来的 RSI 时代, Frontier 模型有了足够多的训练数据, 特别是大量 Long Horizon 的 Agent workflow 及大量的新的高价值的证明分析(例如很多数学定理的证明), 另外 AI4S 估计最近几个月也会有重大的突破. 这些推动了整个模型的可训练数据规模指数级在增长. 这也是模型本身的参数规模可以进一步扩展的前提.

另一个是来自于Infra的变化, 从早期的 96GB HBM 的 Hopper, 到现在 Blackwell / Rubin 288GB 的HBM, 以及相对大规模的超节点系统(NVL72)的演进, 使得在推理场景单个超节点理论上可以承载 5~10T 规模的模型.

1.2 10T的模型结构是什么?

基础设施和训练数据都满足模型继续 scaling 到 10T 时, 接下来需要回答的一个问题是 10T 的模型结构应该是什么样的?

首先从算力约束上来看, 我们要满足 Agent 一类 workflow 的高速推理需求以及成本约束, 那么期望的模型应当是更加稀疏的. 以当前开源的 3T 模型来看, 激活参数规模为 100B 左右, 那么我们能否在一个 10T 的模型上继续做到 100B~150B 左右的激活参数规模? 

其次从内存约束上来看, 非常值得注意的一个 Scaling 机会是 context scaling, 能否进一步把 context 的规模推向 5M 而不显著增加算力和KVCache 的占用? 这个约束不光来自于推理成本和速度的约束, 更重要的是对大量后训练 Scaling 上的约束, 我们需要 Rollout 足够的快, 并发足够的高.

简单的推导一下. 第一个问题, 或许我们需要某种 2048 ~ 4096 Experts 的 MoE. 而第二个问题则需要 Attention Block 需要有更好的算法支撑. 这也是今年在模型结构上各个基模团队出现一些新的变化和尝试的最根本的逻辑.

其实更值得关注的是这两个问题之间隐含的一些千丝万缕的联系. 很多时候, 我们期望 Attention 的效率足够高, 按照一些近似的数学推导看上去可以推导出Linear Attention 这类的算法. 但当它真要承载一个 num_experts = 2048~4096 的模型时, 很有可能会带来灾难性的影响. 例如大量的 dead experts 的影响... 另一方面,我们期望更高的 num_experts 数量也是期望能够在后训练阶段能够更加容易的进行局部参数更新, 避免带来某个任务增强后其它能力显著下降的影响(当然这涉及到一些后训练 RL 相关的算法, 过段时间空闲一点后再来写一下).

那么实际上这就带来一个算法上两难的问题, 一方面尽力需要提高 Attention 的计算结果, 使得它能够通过 MoE Routing-Gate 更好的触发需要激活的少量 Experts, 另一方面又需要降低 Attention 的计算复杂度, 并通过一系列手段来降低 KVCache 的占用. 基于这两个约束, 或许就明白了为什么最近几家国内的开源模型都在逐渐采用 YOCO 一类的路线, 例如《详细分析 DeepSeek-V4.1 Flash 技术报告(1) : 模型结构》.

当然还有一些所谓的 Loop Transformer 的做法, 但是我并不认为这样的做法是对的, 具体可以参考《谈谈未来的Transformer:  Loops Are Not What You Need》. 就像文中谈到的:

我们更希望的是某种递归的方式, 在训练和推理阶段能够分离 Q和K,V 的处理, 对于Q是否能够通过某种记忆注入的方式获得更多的表达能力, 进一步增强后续在 MoE Routing Gate 上的选择精度. 而对于K,V是否能有更好的复用能力, 进一步降低内存容量的约束.

这是围绕着 Attention 算法的一个核心问题. 或者从数学上来看, 能否把原有的每一层Q, K, V 的变化, 变成某种能够利用局部的K,V不变性的处理, 将原有跨层之间 KV 流形上的映射进一步的融合到Q中.

另一方面是我在前段时间的一些很复杂的 agentic workflow 中发现的一些当前 context 管理的算法缺陷. 也是我在文章《谈谈Kimi K3 的KDA(2): 对比 Sparse Attention》中提到的一个问题, 我需要的是一个 attention 的算法能够对 KV 的计算满足基于 block 的 composable 的能力.

这些就是 10T 参数规模的模型可能必须要优先处理的问题. 点到为止不想展开.

2. 10T参数模型的 AI Infra 需要什么?

2.1 超节点规模需要多大?

国内最近有一个很有趣的讨论, 或许是大概知道了一些北美顶尖模型的信息, 然后自身网络/互联能力又很强. 于是开始讨论千卡到万卡规模的超节点. 这是我想主要谈的第一个问题. 首先不可否认大规模超节点确实解决了不少问题, 内存语义对于 EP 这类的 dispatch/combine 会有比较明确的收益, 但是是否意味者所谓的“一卡一专家”这样的说法也成立呢? EP 背后隐藏着一个“同步”的诉求以及整个 ScaleUP 的可靠性的约束.

规模越大带来的“计算”和“传输”耗时的方差越大, 也就是说整个系统的长尾延迟会导致整个系统的利用率随着节点数增加出现显著的下降. 然后一些设计不当的 ScaleUP 协议也会带来很大的影响, 从 2020 年我在思科的时候开始做 NetDAM 实质上就是最早的在尝试 Ethernet based ScaleUP, 当然后续也和 BRCM 一起进行了很多非常深入的讨论, 但 BRCM 在设计 SUE 的时候犯了一个错误, 我当时把 Nvidia FinePack的论文给他们, 让他们借鉴一下这种机制来避免Ethernet Header的开销, 但是他们后续的 SUE 设计上也没有给我 review 导致 pack 方案潜在的会出现很大的长尾, 这将会进一步约束整个 ScaleUP域的规模.

另一个问题来自于可靠性, 整个系统的 MTBF 也随着超节点规模扩大以及被迫使用光互连带来的可靠性降低急剧下降. 因此, 我个人是非常反对千卡规模的超节点的. 另一方面大家也可以注意到, DeepSeek前段时间开源的昇腾 950 基础组件, 超节点规模也就在 128 卡, 并没有广泛宣传的千卡甚至万卡规模的超节点部署.

那么在这些约束下, ScaleUP 规模支撑到最多 128 卡规模时, 交换机Radix = 128, 使用 112G Serdes 为 12.8Tbps , 使用 224G Serdes 为 25.6Tbps, 其实我们并不需要 Radix = 1024 这样规模的 ScaleUP, 另一方面也或许不需要 448G Serdes 这样的产品, 因为 448G Serdes 带来的光传输的可靠性问题暂时还未解决, 同时 FEC 等带来的延迟增长是显著的.

在 Radix = 128 或者说最多到Radix = 256的约束下, 构建一个交换芯片和 ScaleUP 协议该如何处理, 其实是非常容易的一件事.

2.2 基础设施的稳定性

对于这种 10T 规模的模型训练, 或许需要单个训练任务 20 万卡的规模. 那么整体系统的可靠性是一个非常值得探讨的问题. 特别是在 ScaleUP 和 ScaleOut 的取舍上. 我个人的观点是非常明确的, 在 ScaleUP 域内采用 Lossless Credit based 的方案, 当前尽量把 ScaleUP域约束在1~2个机柜内的铜互联为主的方案, 而更多的去提高 ScaleOut 的 Lossy 的可靠性, 具体可以参考《谈谈RDMA和ScaleUP的可靠传输》

可靠传输的实质是用算力去置换链路的不稳定性, 当你有一个 20 万卡规模的集群运行单个训练任务时, Lossless 的 RDMA 一定会达到某种不可用的状况, 所以大家才会看到今年无论是 AMD / BRCM / Meta 以及一些国内厂商都在自定义的RoCE协议中宣传支持 Lossy. 这些问题是我几年前就一直在提的, 当你的训练规模达到一定程度后, Lossless 并不像某些人宣传的那样 at scale.

但是这些厂商在 RoCE 上魔改支持 SACK 的时候, 似乎能力上还是有欠缺的. 例如某个知名厂商在今年的 HotChip 上分享了在 1% 丢包情况下, 一个 400Gbps 的网卡实际的传输性能在 SACK 的帮助下可以到 160Gbps, 这是他们所认为的 SOTA 的性能. 而我们想说的是, 在 3 年前 CIPU 2.0 完成开发时, 我们已经做到 5% 丢包时可以达到 90% 的Goodput, 达到业界领先水平.

当然有很多人会说, 现在网络上的丢包一般观测到的也就 0.1% 的量级, 把它做好了就行了, 为什么需要做到 5% 时还能接近满载的运行, 避免误重传带来的带宽占用. 5%这个数据并不是凭空而来的, 而是实实在在业务的要求. 通常 ScaleOut 网络中的大规模互联, 特别是扩展到 20w 卡规模时, 多层交换机组网和大量的光模块/光纤的使用, 你肯定不希望看到整个训练的 MFU 出现很大的抖动, 然而光模块中 DSP 晶振相位噪声过大, 加上高密机柜热点导致 DSP CTLE/DFE 漂移或者光纤接头的污染都会导致丢包和链路不稳定. 实质上还有一个显著的问题, 假设一个交换机的Uplink Radix = 32, 断一根上行链路带来的路由黑洞导致的丢包为 3% , 断两根为 6%. 还有一些由于 20万卡规模组网需要 Scale-across 的互联引起的一些丢包的问题. 所以我才会把可靠传输的目标定到 5% 的丢包率下系统仍然能够维持较高的 goodput.

2.3 基础设施的安全性

最近一直在谈一些安全相关的问题, 上周的云栖大会我们也提到云环境的多租安全《谈谈Agentic 时代的 DPU是什么: CIPU如何构建阿里云AI Agent、推理、训练等AI infra核心技术竞争力》, 作为全球第一个发布裸金属实例的团队, 其实有很多关于安全的设计, 但是不能公开对外说.  正好 Nvidia 这两天发布了 Open Agent Safety Platform

它把 Agent 安全分成相互补充的两层. OpenShell 在执行环境附近限制智能体实际可以访问的文件, 网络, 服务与凭据. Sentry 把监控和部分策略执行放到 BlueField-4 DPU 的独立信任域(Trust Domain), 为主机被攻破的场景增加独立防线. 但是... 有些基本的安全上的问题还是没考虑清楚, 实质上它还是一个从网络的角度在考虑这个问题, 借助于一些Telemetry然后通过BF4 上的一些 flow-table进行阻断. 有很多主机安全的处理他们并没有很完善的解决...

最根本性的问题是, Agentic workflow 打破了原有的安全边界. 原来我们讲企业内的软件很大程度上是可信可控部署的, 因此用户单一数据中心内并不需要什么多租户隔离的技术, 简单的安全访问控制即可. 但是当 LLM 产生大量代码时, 整个信任的边界发生了变化. 即便是很多基模团队的 Agentic RL 训练或许也需要按照任务进行多租户的安全隔离, 特别是大量的沙箱环境. 但是工业界似乎一直对裸机和 裸金属这两个概念理解不清, “像VM那样使用物理机”这句话估计很多人都不明白,  有些安全的问题, 等他们尝到苦果了就知道了.

2.4 基础设施的性能

前几天看到知乎的一篇文章《辩经系列之六：超标量或者静态排流水》^[1], 包括OpenAI Janapeno 《从 Nvidia GPU 的缺陷到 OpenAI Jalapeño》^[2] 都提到了一个问题: “超标量”.

其实这个问题我在去年就提过 《Inside Nvidia GPU: 谈谈Blackwell的不足并预测一下Rubin的微架构》^[3], 记得去年在华为海思的一个什么会上, 还和廖恒博士聊过这个事情, 这篇文章老黄也在 NV 内部转发过, 真不知道 NV 的同学能听进去多少. 可惜有些背后的设计考虑涉密就不多说了...

大概就这样吧, 看到一些错误的东西, 随手写点文字, 全文完.