这两天朋友圈里刷到一条挺有意思的消息GPT-6 全员开放同时某通信巨头正在测试一个 25.6 万卡的超节点集群。大多数人看到前半句想到的是新模型终于随便用了但我的注意力完全被后半句勾走了。25.6 万张加速卡哪怕按当前主流单卡算力粗略折算也已经超出绝大多数公开集群一到两个数量级。这篇文章我不打算复述新闻而是想从工程和产品两个角度把这个数字翻译成人话25.6 万卡意味着什么、为什么下一代旗舰模型会选择全员开放、要撑起这种量级的训练和推理底座中间到底藏着哪些难啃的骨头以及普通开发者和企业现在应该怎么接住这波变化。1. 25.6万卡到底是个什么概念先把这个数字翻译成人话1.1 从服务器数量、机柜和用电量看规模25.6 万张卡听起来抽象我习惯先换算成机房里的物理存在感。按一台 8 卡服务器来算25.6 万张卡就是 3.2 万台服务器按一个机柜放 40 台服务器来算大概需要 800 个机柜如果一座大型数据中心有 200 到 400 个机柜那这个集群相当于两三个园区拼在一起。很多做私有化部署的团队手里能凑出 512 卡就已经觉得自己很富了25.6 万卡是它的 500 倍。更直观的是用电量。单张卡按 350W 左右功耗算25.6 万张卡的理论满负荷功耗约 89.6MW再算上服务器整机、网络设备、存储和制冷整个集群功耗奔着 130MW 以上去。这个数字什么概念相当于一个几万户规模的小城镇全年无休的用电负荷。所以但凡是这种量级的超节点它选址的第一条件不是风景好而是电力并网点、变电站容量和散热条件是否允许。1.2 为什么叫超节点而不是数据中心这里有个关键差异普通数据中心是几千台服务器通过网络凑在一起服务器之间有互联但延迟和带宽并不支持把它们当一台机器来用。而超节点强调的是计算和网络深度耦合所有卡之间用极低延迟、极高带宽的互联方式打通逻辑上像一个巨大的单一设备在对外提供算力。我举个例子帮助理解。普通机房里的服务器互联像城市之间走高速公路出一趟门要过收费站、绕环路超节点内部的全互联更像是把整个小区修成一个大平层家家户户之间的门都开着串门就是一步路的事。25.6 万卡的超节点就是要在一栋逻辑上的大平层里容纳 25.6 万个住户。这背后不仅是网卡和交换机的升级还需要整套通信库、调度器、故障检测机制都围绕超节点式互联重新设计。1.3 规模本身不是目的有效算力才是但我要泼一盆冷水。25.6 万卡是峰值算力的堆叠真正有价值的是有效算力也就是跑大模型训练时实际发挥出来的计算效率。大模型训练里有个关键指标叫 MFU模型算力利用率也就是硬件理论算力中有多少真正用于模型计算。业内做得好的是 45% 到 55%做得一般的可能只有 30% 出头。如果 25.6 万卡集群的 MFU 只有 30%那它的有效算力相当于 7.68 万卡跑满如果能做到 50%就是 12.8 万卡级别的满血输出。两者差距直接反映在训练时间和成本上。所以当我看到一个X 万卡的新闻标题时第一反应从来不是哇好大而是这卡池的中位故障间隔多久、MFU 能做到多少、网络有没有拥塞。2. 全员开放背后下一代模型到底在下一盘什么棋2.1 先分辨开放是哪种开放全员开放这四个字很容易让人兴奋但在技术圈里开放至少有三种完全不同的含义。第一种是入口开放也就是任何用户都能通过网页或 App 免费体验到部分能力后端依然是限流和计费第二种是 API 开放开发者可以通过接口调用按 token 付费第三种是权重开源把模型参数直接释放出来任何人都能拿去微调、私有化部署。三种开放对行业的影响天差地别。如果只是入口和 API 开放说明产品方想拿到的是用户流量、真实使用数据和生态粘性如果是权重开源那就是直接把护城河拆掉一块让企业用户不用再担心数据出域。从目前透露的信息来看全员开放更接近前两者你可以直接用、可以接入业务但底层商业化逻辑没有消失只是把体验门槛降下来了。2.2 为什么偏偏在这个时间点选择全员开放我的判断是这一代旗舰模型的能力已经进入一个微妙的阶段上一代模型之间的差距在缩小用户切换成本在降低谁先把新一代模型推到足够多的人面前谁就能占据下一轮生态的先发位置。全员开放本质上是用免费体验换使用习惯和真实数据这些数据又会反哺下一轮训练和产品迭代。另一个不能忽略的原因是单位推理成本。大模型开放的最大瓶颈其实是算力成本25.6 万卡超节点如果顺利落地推理池的扩容和调度能力会远超现在单位 token 的边际成本被显著摊薄。也就是说全员开放的底气不完全来自产品自信更多来自算力基建的自信。没有足够大的集群开放体验一上线就会被挤爆反而砸了口碑。2.3 算力基建是开放承诺的履约能力我一直认为模型开放不是一句口号而是算力能力的对外承诺。如果一个模型号称全员免费结果高峰时段排队三小时用户转头就去别家了。真正支撑全员开放的是背后足够大的推理集群和足够聪明的调度策略用户请求来了系统能就近分配、弹性伸缩、自动把简单任务路由到便宜的小模型上把复杂任务留给旗舰大模型。25.6 万卡的超节点显然不是为了跑一个模型的一个训练任务而建的它更像一个多租户的大算力底座同时承担训练集群、推理池和实验环境三种角色。开放在前面的用户体验真正的重活全在后面的基建里。3. 粗略推算25.6万卡集群能撑起多大的模型3.1 算一笔账训练耗时公式与实例测算在深度学习圈里有个估算训练时间的经典公式单次预训练时间大概等于 6 乘以数据量再乘以参数量除以卡数量 × 单卡算力 × MFU。这里的 6 是个经验常数对应前向和反向过程中大概需要的计算量。公式本身不复杂但参数代入之后能看出很多门道。假设我们训练一个总参数 3 万亿的 MoE 模型训练数据 15 万亿 token用 25.6 万张卡单卡 FP8 算力按 1800 TFLOPS每秒 1.8 千万亿次浮点运算算MFU 取 45%。代入公式6 × 15 万亿 × 3 万亿得到约 2.7×10^26 次浮点运算分母是 25.6 万 × 1.8×10^15 × 0.45约 2.07×10^20 次浮点运算/秒。两者一除大概是 130 万秒折合约 15 天。也就是说一个 3 万亿参数的模型在这个集群上单次预训练可以在两周左右完成。3.2 更大的模型也并非不可能如果把胃口放得更大一点模型总参数量提升到 10 万亿训练数据提升到 50 万亿 token单次预训练时间就要拉到两个月左右。这个周期虽然不短但在一个 25.6 万卡的集群上是可以接受的因为它意味着团队有空间做多次实验、做超参数扫描、尝试不同的数据配比。上一代模型动辄训练大半年很多时间其实是卡在集群规模不够大不得不在数据质量和训练成本之间取舍。当然我必须强调这是一道量级估算题不是官方数据。实际的训练还要考虑 MoE 模型只激活部分专家、通信开销、checkpoint 写入、故障回滚等因素真实耗时会比纸面数字高出不少。但这个量级已经足够说明问题25.6 万卡集群确实能把百万亿参数级别的探索推进到工程上可执行的区间。3.3 通信同步卡越多短板效应越明显大模型训练是同步并行每一轮梯度更新前所有卡都要做一次全局通信。25.6 万张卡意味着每一步更新都要等最慢的那张卡算完、把它那部分梯度传过来然后再统一更新参数。这个短板效应很残酷一个卡池里只要有少数几张卡变慢整个集群的速度就会被拖到它们的水平。所以超节点的存在本质上是把物理距离和网络延迟压到最低让所有卡等最慢一张的代价尽量小。这也解释了为什么超节点不能用普通数据中心那种粗放网络来搭卡与卡之间的互联带宽、通信库的集合通信优化、训练框架的流水线并行和专家并行调度每一个环节都是瓶颈。规模越大系统工程的难度不是线性增长而是指数级增长。4. 从8卡到25.6万卡超节点里最难啃的硬骨头4.1 卡间互联从 PCIe 到自研高速总线单机 8 卡时代卡与卡之间的通信可以通过 PCIe 交换机实现带宽虽然不高但对大多数业务来说够用。到了大模型训练张量并行要求同一层参数拆分在不同卡上每次前向和反向都要做大量的卡间通信这时候卡间互联带宽直接决定训练速度。业界普遍做法是用 NVLink 这类高速总线把同一节点内的卡打通但跨节点依然要走网络。超节点的设计思路是把网络也变成总线。在超节点内部任意两张卡之间的通信路径要尽量短、尽量直连而不是绕经一堆交换机。这背后的拓扑设计、路由算法、拥塞控制和传统数据中心网络完全不是一个思路。我见过不少团队在 8 卡机上调得很好一到千卡集群就性能骤降问题几乎都出在互联和通信库上而不是显卡本身。4.2 掉卡是常态训练系统必须容忍故障做大规模训练的人都有一个共识在数万卡的规模下讨论会不会坏卡是没意义的应该讨论每分钟平均坏几张卡。假设单卡平均无故障时间是 10000 小时25.6 万张卡每天的故障期望大概在 600 张左右。这个数字听起来吓人但它是统计必然。真正的工程挑战是如何让训练任务在故障发生时不被中断。解决办法是三层联动第一层是高频 checkpoint每隔几十分钟甚至十几分钟把模型状态写入持久化存储第二层是弹性训练框架发现某张卡失联后自动把它踢出训练组剩下的卡重新组队继续训练第三层是任务调度系统能快速调度备用卡补位并恢复最近一次 checkpoint。这就像长跑比赛选手跑到一半抽筋了不是让整个比赛停下来而是让替补队员接棒记录成绩从上次计时点重新起算。说起来轻松实际做起来牵扯到框架、网络、存储三方的深度配合。4.3 功耗与散热规模大到必须重新设计机房25.6 万卡的集群如果还是按照传统风冷机房的思路来建散热系统会被直接压垮。单个机柜放 8 张卡的主流方案功耗已经到 10kW 到 15kW而超节点架构下单个机柜可能会堆进去更多加速卡单柜功耗直奔 100kW 以上。这种功率密度下风冷完全力不从心需要用冷板式液冷甚至浸没式液冷把热量直接通过冷却液带走。更麻烦的是电力供给。一个 130MW 级别的园区连电网改造周期都很长所以超节点选址通常会依赖大型水电站、风电场或专门的变电站。机房里的 UPS 和柴发备份也要按能带起整个集群的规模设计而不是只保控制节点。很多人以为大集群的难点是钱和芯片其实真正卡脖子的是电、散热和整个物理空间规划。4.4 调度与多租户让 25.6 万卡同时干很多件事还有一层容易被忽略的复杂性25.6 万卡不是一次训练任务独占的。一个超大规模集群通常同时跑着几百个训练任务、推理服务和开发调试任务它们共享同一个资源池。要让这些任务不互相干扰、按优先级合理排队、在故障后自动恢复调度器就是那个沉默的中央大脑。我用机场打比方机场再大也不可能只为一家航空公司的一架航班服务。流量管理、停机位分配、延误改签、突发天气下的重新排序每一个环节都需要系统自动决策。超节点的调度器和机场塔台的角色一模一样只是它调度的不是飞机而是几万张卡的算力切片。任务之间还要做网络隔离和存储隔离防止一个团队的异常流量拖垮整个集群。5. 模型全员开放之后你的项目该怎么接5.1 接入前的三件套兼容性检查、影子模式、评测集每次新一代模型开放我都会建议团队不要第一时间全量替换而是按三步走。第一步做兼容性检查确认现有代码调用的接口是否兼容特别是工具调用function calling、结构化输出和流式返回这几块经常会有格式变化第二步跑影子模式也就是新旧模型并行处理线上真实请求但新模型的结果只记录不下发对比一段时间第三步准备领域评测集把你自己业务里最容易出问题的几千条样本整理出来跑一遍新模型的表现。很多团队喜欢把公开榜单的分数直接当绩效指标这其实很容易被误导。公开榜单覆盖的是通用能力和你业务场景里那些又脏又乱的边缘 case 基本是两回事。真正应该关心的是模型在你的客服场景里能不能准确判断用户意图在你的代码辅助流程里能不能遵守仓库规范在你的长文档分析流程里能不能记住 50 页之前的一个细节。5.2 评测抓四个关键维度我一般会建立一张四维评估表每个维度给出一到两个具体的压测方法评测维度关注什么我的压测方法长上下文理解上下文窗口变大后是否真的有效利用丢一段 5 万字材料随机位置埋细节问尾部相关问题工具调用与 Agent 能力能否稳定输出 JSON、按流程调用外部 API构造 20 个连续多步任务检查中途失败率和格式合规率代码与逻辑多文件工程场景下的正确性和一致性给它一个仓库片段让它定位 bug对比修复方案安全与拒答不当请求的拒绝是否稳定合理整理一套对抗样本集反复探测拒答率和答非所问率新模型带来新能力的同时也经常带来新的怪脾气。有的人可能会发现它写代码更强了但在多轮对话里更容易跑偏有的人发现它长文本总结很出色但工具调用的返回格式偶尔会多出多余字段。这些必须靠你自己的评测集提前暴露而不是上线之后让用户替你做测试。5.3 控制成本与延迟的实操手段全员开放不等于你调 API 不要钱。对你来说网关后面依然是按 token 计费的引擎所以成本控制仍然要做。最实用的做法是任务路由简单问题给便宜的小模型复杂问题才路由给旗舰模型。一个客服系统里80% 的请求可能都是一般性问答没必要让旗舰模型来回答只有那 20% 需要复杂推理的请求才值得付出更高成本。缓存也很关键。很多业务的用户问题高度重复可以在网关层做语义缓存把完全相同的 prompt 命中结果直接返回而不去打模型接口。实测下来语义缓存能省掉 15% 到 30% 的成本具体取决于业务问题重复度。这两个手段配合模型蒸馏能把整体推理成本压到可接受的范围。5.4 我踩过的调优小坑最后说几个我在接大模型时踩过的小坑。第一个是提示词位置上下文窗口变长以后系统提示词放在消息序列最前面仍然有效但如果中间夹了超长资料模型对尾部规则的关注度会明显下降所以关键约束条件我习惯在用户消息里再强调一遍。第二个是温度参数在 Agent 任务里温度太高会带来随机行为我习惯把 temperature 调低到 0.2 甚至 0同时提高最大迭代轮数让模型在确定性的路径上多走几步。第三个是结构化输出即使模型声称支持 JSON 模式我依然会在代码里做一层 schema 校验遇到解析失败就重试一次而不是直接报错给用户。6. 大集群并非万能算力叙事背后的真实瓶颈6.1 数据墙可能比算力墙更早到来25.6 万卡集群解决了算得动的问题但模型训练还有一个更朴素的前置条件有足够多、足够高质量的数据。15 万亿 token 听起来很多但其中真正的高质量、去重、配比合理的数据集合攒起来远比想象中难。全网公开语料里大量内容是重复的、低质的、有噪声的直接拿去训练模型能力不升反降。合成数据是这两年绕不开的补充手段用模型生成数学题、代码题、对话样本来扩充训练集。但合成数据吃多了也会出问题模型会在某些模式上自循环缺乏真实世界的多变性。所以数据团队的工作已经从抓取清洗变成分布设计要人为控制代码、数学、多语言、多模态数据的配比。这是算力堆不出来的一环。6.2 架构与算法创新仍是天花板另一个不是靠堆卡就能解决的是模型架构本身。如果沿用上一代的主流架构参数规模放大到一定程度后收益会明显递减。业界已经有不少方向值得关注比如 MoE 稀疏激活总参数很大但每次推理只激活一小部分专家从而在算力成本和模型能力之间取得平衡还有多模态统一架构把文本、图像、音频、代码放在同一个表征空间里让跨模态理解和生成更自然。大集群给了架构探索的实验空间但架构创新本身还是要靠研究和工程积累。换句话说25.6 万卡是放大器不是发动机。如果模型架构本身有瓶颈给再多的卡也只是让瓶颈更快暴露而不是直接消失。6.3 对齐、安全与评测的成本同样在膨胀还有一个经常被忽视的成本项安全与对齐。模型能力越强、开放范围越广被滥用的风险就越高需要投入的评测、红队测试、对抗样本和价值观对齐工作也越多。全员开放意味着面向的人群更广输入输出内容更不可控系统要在不对正常体验造成干扰的前提下过滤掉有害请求、防止生成违规内容、保护用户隐私。这部分工作既消耗算力需要大量评测集跑场景测试更消耗人力和时间。很多团队把预算全部砸在预训练集群上等到模型训练完才发现对齐阶段还要再跑好几轮强化学习费用和时间都被低估了。所以在评估一个超大集群项目时我建议把预训练、后训练、评测、推理部署四个环节的成本一起算进去而不是只盯着那张响亮的万卡标签。7. 写在最后下次看到XX万卡的新闻先别急着转发在行业里待久了我发现一个规律技术圈对数字的敏感度很高但对数字背后的口径敏感度很低。同样一个 25.6 万卡的消息不同的人能理解出完全不同的信息。我现在的习惯是拿到任何万卡规模的消息先看三件事第一这是单集群超节点还是多集群总算力两者工程难度差一个数量级第二这是规划目标还是在测的实测状态新闻里的数字经常是 PPT 数字第三这个集群是偏向训练还是推理两者的网络、存储、调度设计完全不同。如果 GPT-6 真的全员开放而配套的超大集群又顺利投产那对整个应用层来说确实是一个新的窗口期。但我个人的建议始终是别焦虑别急着推翻现有系统。先在现役模型上把业务场景跑通、把评测集攒起来、把任务路由和缓存机制搭好等新一代模型稳定下来之后花一到两周时间灰度切换。技术在新闻里总是跑得比现实快但超大算力集群从In testing到稳定可用通常还需要很长一段路程。真正能吃到红利的人不是刷屏最快的那批而是提前把手头工具链准备好、等新模型一落地就能接住的那批。
