70多条算力大通道已经建成，国家枢纽间时延压到了20毫秒以内，广东韶关到广州只要1.3毫秒。网络够快了，光纤铺好了，通道打通了。

但算力还是调不动。

不是带宽不够，不是时延太高，而是"听不懂"——英伟达GPU说的是CUDA，华为昇腾说的是CANN，寒武纪说的是BangC，摩尔线程说的是MUSA。调度系统要做的，是在一个没有"普通话"的世界里，让说不同方言的人协作完成一项精密工程。

这就是算力网与电网最本质的技术分野：电网调度的是同质的电子，电子不需要翻译；算力网调度的是异构的计算任务，每一个任务都需要被"翻译"成目标芯片能理解的指令。70条大通道解决的是"路"的问题，异构调度解决的是"语言"的问题。路再宽，语言不通，货也送不到。

巴别塔之所以建不成，不是因为砖不够，而是因为大家说的是不同的语言。

CUDA的"方言效应"：二十年的护城河，不只是软件

第一篇里提过，CUDA形成了事实上的"技术方言"。现在需要追问：这个方言到底有多难翻译？

先看一组时间线。CUDA在2006年首发，到2020年左右形成完整的AI训练生态，花了14年。这14年里，英伟达不是只造了一个编程框架——它造了一整套"语言体系"：cuBLAS做线性代数，cuDNN做深度学习，NCCL做分布式通信，TensorRT做推理加速，CUDA C做底层编程。每一个库都针对自家GPU的寄存器分配、线程调度、内存层次做了极致优化。这种"软硬件深度耦合"带来的效率，不是写个兼容层就能复刻的。

数字更能说明问题。CUDA拥有，全球400万至500万开发者，90%的主流AI框架默认适配CUDA。华为CANN的第三方库数量不足2万，开发者约40万——差距不是几倍，是一个数量级。

更关键的是开发者的"肌肉记忆"。一个在CUDA上写了5年代码的工程师，闭着眼睛都能写出高效的GPU Kernel。让他切换到CANN的Ascend C，不是说"语法差不多"就行——内存管理模型不同（GPU统一寻址，NPU物理隔离），线程调度机制不同（GPU用SIMT，NPU用SIMD+专用硬件调度），甚至连显存分配的耗时都是CUDA的1.8倍。这些不是"兼容层"能抹平的差异，是底层架构的根本性分歧。

有人会说：华为CANN不是宣称95%的CUDA代码兼容吗？

这个数字需要拆开看。95%的兼容意味着最常见的算子可以"跑起来"，但"跑起来"和"跑得好"之间，隔着一道鸿沟。DeepSeek团队在迁移V4时发现，大量CUDA算子在CANN上的首次运行效率极低——不是因为不兼容，而是因为CANN的优化算子库覆盖还不完整，很多操作只能走"通用路径"，性能损耗达到20%至30%。DeepSeek V4推理效率从初始版本到优化版本提升了35倍——这个数字不是芯片进步带来的，而是14个月的算子重写和深度优化换来的。35倍，就是"兼容"和"优化"之间的距离。

DeepSeek的"飞行换引擎"：200个算子重写背后的硬仗

2026年4月24日，DeepSeek发布V4系列模型。最大的看点不是模型性能本身——而是它完全运行在华为昇腾950PR芯片上，底层代码从CUDA全面转向CANN框架。全球第一个脱离英伟达CUDA生态的顶级AI大模型。

这件事有多难？DeepSeek创始人梁文锋在内部说，这相当于"在一架飞行中的飞机上更换引擎"。

不是比喻。迁移过程面临三类硬核挑战，每一类都是工程地狱。

算子对齐：不是"差不多就行"，是逐位对齐。 CUDA的算子库（cuBLAS、cuDNN等）经过多年优化，每种操作的实现都针对GPU架构做了极致调优。CANN需要提供对应的算子，且精度必须完全一致。大模型在不同硬件上运行，浮点运算的并行分拆策略不同，而浮点加法不满足结合律——同一个矩阵乘法，分拆成几千个线程同时计算再求和，不同分法得到的末位数值不一样。对于7B小模型，误差在10的负4次方量级，可以忽略。对于V4这种1.6万亿参数的模型，处理百万Token长上下文时，误差随层数和序列长度累积，在输出层可能产生明显偏差。DeepSeek团队耗时数月重写了超过200个核心CUDA算子，反复进行精度对齐测试。有工程师透露，"精度对齐是最耗时的工作"。

通信优化：从NCCL到HCCL，不是换一行代码那么简单。 万亿参数模型的分布式训练和推理，高度依赖芯片间的高速通信。CUDA生态有NCCL库，在NVLink互连下效率极高。昇腾芯片之间的通信走的是HCCL，带宽和延迟特性不同，通信拓扑需要重新优化。MoE模型的All-to-All通信是最大的瓶颈——专家路由导致访存离散，不同芯片间需要频繁交换中间结果。CANN团队通过数据预取、通道合并、乱序发送等技术，将跨节点专家路由的通信延迟降低了58%。但这不是通用方案，是针对DeepSeek V4架构的定制优化。换一个模型，通信优化可能需要从头再来。

内存管理：GPU的"统一地址空间"和NPU的"物理隔离"，是两套完全不同的哲学。 GPU的内存层次是SRAM→L2→HBM→主机内存，统一寻址，开发者几乎不需要关心数据在哪个层级。NPU的内存管理更接近显式控制，数据在设备内存和主机内存之间的搬运需要开发者主动触发。DeepSeek V4引入的Engram分层存储机制——模型静态参数自动卸载到主机内存和SSD，GPU显存只留核心计算——在昇腾上的实现路径和NVIDIA GPU完全不同。CANN团队结合这一机制，实现了"GPU显存-主机内存-SSD存储"的三级自动调度，单卡可承载的模型规模提升了3倍。但同样，这是深度定制的结果。

14个月的攻坚，最终的回报是惊人的：经过CANN全链路优化的DeepSeek V4-Pro，在昇腾950PR上的推理时延低至20毫秒，单卡推理性能达到英伟达特供版H20的2.87倍，能耗降低40%。推理侧，国产芯片第一次在顶级大模型上实现了性能反超。

但14个月这个数字本身就是问题。一个模型从发布到在国产芯片上"好用"，需要14个月的深度协同——这意味着，如果算力网要实现"任意算力任意调度"，每接入一种新芯片、每上线一个新模型，都可能需要数月的适配。这不是"调度"，这是"翻译工程"——而且翻译不是自动的，是手动的。

更值得注意的是DeepSeek的技术路线选择。V4采用了TileLang——一种领域专用语言——来开发底层算子，而不是继续用CUDA C。TileLang可以跨硬件平台编译，降低向国产芯片的迁移成本。同时，V4引入MXFP4量化感知训练，对MoE专家权重实现FP4量化，降低了对NVIDIA FP8生态的绑定。这些不是适配层的"打补丁"，而是从模型架构设计阶段就在为异构部署做准备。

这意味着一条重要的分叉路：与其让调度系统去"翻译"CUDA，不如让模型本身就说"多国语言"。

谁在造"普通话"：三家路径，三种逻辑

既然翻译这么难，能不能造一门"普通话"？正在做这件事的，至少有三股力量。

第一股：智源FlagOS——"世界语"路线。

智源研究院牵头的众智FlagOS，是目前最接近"统一语言"的尝试。它的核心思路是：不翻译方言，而是造一门所有芯片都能听懂的新语言。

FlagOS的技术栈包括三个核心组件：FlagGems统一算子库，替换掉所有CUDA原生算子；FlagTree统一编译器，一次编写、多芯编译；FlagScale训推框架，屏蔽底层硬件差异。开发者不需要知道自己的代码跑在什么芯片上，FlagOS负责适配。

2026年4月24日，DeepSeek V4发布当天，FlagOS社区完成了9种AI芯片的Day0适配——海光、沐曦、华为昇腾、摩尔线程、昆仑芯、平头哥真武、天数智芯、英伟达、清微智能。这意味着，V4发布当天就能在这9种芯片上运行，不需要等数月的适配周期。

更关键的突破在训练侧。FlagOS已在海光、沐曦、摩尔线程等芯片上实现了同构千卡端到端训练，在"96台沐曦服务器+32台英伟达服务器"的异构千卡集群上，完成了Qwen3-10B模型的端到端混合训练，异构混合效率达到81.64%，与同构基线的平均误差仅为0.46%。

81.64%的异构效率意味着什么？如果在英伟达集群上跑一个任务需要100小时，在"沐曦+英伟达"混合集群上需要122小时。差距存在，但已经进入了"可用"区间。更重要的是，它证明了一个关键命题：不同厂商的芯片真的可以在同一个训练任务中协同工作——这不是理论推演，而是工程现实。

但"世界语"也有它的问题：世界语发明于1887年，比任何一种自然语言都简洁优雅，但至今使用者不到200万。语言的推广从来不只是技术问题。FlagOS需要每家芯片厂商主动对接它的标准，而芯片厂商有自己的考量——华为有CANN，寒武纪有NeuWare，摩尔线程有MUSA。谁愿意让自己的芯片变成FlagOS生态的"兼容机"？

第二股：国家算力标识体系——"身份证"路线。

工信部2025年发布《算力互联互通行动计划》，2026年2月印发《关于组织开展国家算力互联互通节点建设工作的通知》，正式启动"1+M+N"国家算力互联互通节点体系建设。"1"是国家算力互联网服务节点，"M"是区域节点，"N"是行业节点。

这套体系的核心发明是"算力标识"——给每一份算力资源分配一个唯一编码，就像给每个人发身份证。截至2026年1月，全国已部署1032万条算力标识，接入31个省（区、市）的155家企业的578个资源池，汇聚316 EFLOPS智算资源。

"身份证"解决的是"找得到"的问题——调度系统能知道某个资源池有什么芯片、多少算力、在什么位置、时延多少。但"找得到"和"调得动"之间，还隔着"能不能跑"这道鸿沟。身份证可以告诉你"这里有一个昇腾910B集群"，但无法告诉你"你的CUDA模型能不能在上面跑"。

"三统一"机制（统一标识、统一标准、统一规则）正在填这道沟。国家标准层面，鹏城实验室牵头起草了12项算力网相关指导性技术文件，涵盖算力并网技术要求、算力资源管理与调度技术要求、算力多量纲计费技术要求等。通信行业标准层面，YD/T 6505《算力网络 标识解析技术要求》和YD/T 6431《面向公共通信业务体验的统一算力标识技术要求》已正式发布。

标准在跑，但标准的落地需要时间。12项国家标准尚在"正在起草"阶段，行业标准的执行力度也有待观察。更核心的问题是：标准能规定"怎么描述算力"，但无法规定"算力之间怎么互操作"。这就像你可以用标准格式描述一个人的身高体重，但无法让他和别人自动成为搭档。

第三股：启元实验室"九源"——"编译器"路线。

启元实验室牵头提出的"九源统一智能计算架构"，走的是第三条路：不造新语言，也不发身份证，而是造一个"超级编译器"，让同一套代码自动适配不同芯片。

九源架构的核心设计分三层：统一算子库/通信库及运行时，提供底层算子接口的统一调用流程；统一领域编程语言及编译器，对Triton进行扩展，实现跨平台编译；兼容CUDA的NPU编译器，让现有CUDA代码可以在非CUDA芯片上运行。目前已在英伟达、天数智芯、沐曦、寒武纪、摩尔线程、昇腾、海光等芯片上初步适配。

这条路线的野心最大——它不仅要解决新代码的跨平台问题，还要让存量CUDA代码"自动迁移"。但难度也最高：CUDA的闭源特性意味着编译器必须"猜测"底层优化逻辑，而非直接复用。英伟达也明确禁止第三方通过翻译层运行CUDA代码，封堵了生态外溢的路径。

三条路线，三种逻辑：FlagOS造新语言，国家体系发身份证，九源造编译器。它们不是竞争关系，而是互补——但任何一条单独都无法解决异构调度的全部问题。算力网需要的，是一种能把"找得到""听得懂""调得动"三层能力串起来的系统。

算力网需要的不是"翻译"，是"操作系统"

到此为止，我们讨论的都还是在解决"怎么让不同芯片听懂彼此"的问题。但异构调度的真正难点，不是翻译，而是编排。

翻译是点对点的：CUDA→CANN是一对，CUDA→NeuWare是另一对，CANN→MUSA又是一对。N种芯片，需要N×(N-1)/2对翻译。而且每对翻译都是定制的，换了新模型可能又要重新调优。

互联网当年也面临过类似的问题——1970年代有十几种不同的计算机网络协议，IBM有SNA，DEC有DECnet，每个厂商都在说自己的"方言"。解决方案不是在每两种协议之间做翻译，而是发明TCP/IP——一套统一的抽象层，屏蔽底层差异，让上层应用不感知物理网络。

算力网需要自己的"TCP/IP时刻"。

中国电信的"息壤"平台正在朝这个方向探索。它提出的"Triless"架构——资源无关、框架无关、工具无关——本质上是在构建一个算力网的"操作系统"。用户不需要知道底层是什么芯片、什么框架，只需要描述"我要跑什么模型、需要什么性能"，平台自动匹配最优算力资源并完成适配。目前，息壤平台自有及接入智算总规模已突破91 EFLOPS，支持跨服务商、跨架构、跨地域的统一调度管理。

但"操作系统"的难度远超"翻译"。一个真正的算力操作系统，至少需要解决四个问题：

感知能力：知道每一块芯片此刻在干什么。 这不仅仅是"状态监控"，而是理解芯片的实时负载、可用算力、内存余量、通信带宽——并且以足够细的粒度（毫秒级）感知变化。目前国家级算力互联网平台的月均调度仅约300次，大部分算力资源的状态还是"离线登记"而非"实时感知"。

匹配能力：知道什么任务该派给什么芯片。 这不是一个简单的"性能排序"问题。训练任务需要大显存和高带宽互联，推理任务需要低时延和高吞吐，MoE模型的训练需要特定的All-to-All通信优化。一个任务在A100上跑得好，不代表在昇腾950上也能跑得好——不是性能不够，而是算子适配、通信模式、内存分配都需要针对性优化。中国联通的研究团队提出，算力调度需要考虑任务优先级、完成截止时间、数据位置、节点负载、网络带宽和时延等多维因素，是一个"典型的多约束优化问题"。目前的调度算法主要基于贪心策略和启发式算法，距离真正的"智能调度"还有距离。

迁移能力：正在跑的任务能无损地搬到另一块芯片上。 电力调度可以让电流瞬间切换路径。算力调度做不到——一个训练到一半的模型，要从A100集群迁移到昇腾集群，需要先保存检查点、转换权重格式、重新分配内存、重建通信拓扑，整个过程可能耗时数小时。这期间任务完全中断。当前最先进的做法是"断点续训"，但"断点续训"不等于"无缝迁移"——它只是让你能从上次中断的地方继续，而不是让你在迁移过程中不中断。

容错能力：任何一块芯片出问题，任务不崩。 在万卡集群中，硬件故障是常态而非异常。CUDA生态有成熟的容错机制——NCCL的通信容错、PyTorch的DDP弹性训练。国产芯片生态在这方面的能力还远远不够。2025年Q4，昇腾910C适配DeepSeek R2时出现"大规模推理时随机崩溃"的问题，一度让生态信心动摇。

四个问题，没有一个被完美解决。但方向已经清晰：算力网的调度系统，不是一个"翻译器"加上一个"路由器"，而是一个具备感知、匹配、迁移、容错能力的操作系统——它不是在芯片之间做翻译，而是在芯片之上做编排。

写在最后

回到巴别塔的隐喻。巴别塔建不成，不是因为砖不够，是因为语言不通。算力网面临同样的问题：70条大通道是砖，异构调度是语言。

但巴别塔故事的结局，不一定是永恒的分裂。

DeepSeek V4用14个月证明了"飞行换引擎"是可能的——200多个算子重写、35倍推理效率提升、单卡性能反超H20。FlagOS用Day0适配证明了9种芯片同日跑通一个模型是可能的。国家算力标识体系用1032万条标识证明了"给算力发身份证"是可行的。息壤的Triless架构证明了"屏蔽底层差异"的调度逻辑是可以落地的。

但这些"可能"都还停留在"点"的突破，没有连成"网"的贯通。DeepSeek的迁移是定制的，FlagOS的适配需要每家芯片厂商主动对接，国家标准还处于起草阶段，息壤的跨域调度月均只有300次。

算力网要真正跨过芯片异构这道坎，需要的不是更多的"翻译"——翻译再多，也只是让两种方言能对话。它需要的是一个足够好的"操作系统"——让上层应用完全不关心底层芯片是什么，就像你用手机打电话时不需要关心信号走的是4G还是WiFi。

互联网等了13年（1983年ARPANET切换TCP/IP）才迎来真正的爆发。算力网的"TCP/IP时刻"会什么时候到来？

三个信号值得盯住：第一，FlagOS或类似平台能否实现"零成本"的跨芯片迁移——即一个模型在A芯片上优化好的代码，能在B芯片上直接跑且性能损失低于10%；第二，国家级算力互联网平台的月调度量能否从300次跃升到30万次——这意味着调度不再是"试验"而是"日常"；第三，是否会出现第一个"算力原生"应用——离开算力网的异构调度能力就无法存在的应用，就像离开互联网就无法存在的电商。

巴别塔的故事还有一层被忽视的含义：人们被分散到各地，不是因为他们说不同的语言，而是因为他们不再愿意沟通。算力网面临的风险，不只是技术上的"听不懂"，更是商业上的"不想听"——每家芯片厂商都希望用自己的生态锁定用户，每家云厂商都希望用自己的平台圈住客户。异构调度越成熟，生态锁定就越难维持。

算力网的巴别塔，最终可能不是被技术推倒的，而是被利益重建的。（文/王子祺）