1. 从“护城河”到“开放战场”AI芯片格局的深层变局最近行业里讨论得最热闹的一件事莫过于微软在Build开发者大会上宣布的“Copilot PC”战略以及其背后那颗代号为“NPU”的神经处理单元。这看似是一次常规的硬件升级发布但如果你仔细拆解其技术路径和生态宣言会发现它远不止于此。它像一把精准的手术刀正在尝试撬动一个由英伟达NVIDIA用CUDA生态构筑了超过十五年的坚固堡垒。标题里提到的“背刺”、“拆掉护城河”这些词虽然带有强烈的戏剧色彩但确实精准地捕捉到了当前AI硬件领域暗流涌动的核心矛盾封闭的生态壁垒与开放的行业标准之争。我们得先理解“护城河”是什么。在AI计算领域英伟达的护城河从来不只是那几块性能强大的GPU芯片而是围绕这些芯片建立的一整套软件栈、开发工具、优化库和庞大的开发者社区其核心就是CUDA。CUDA让开发者能够相对轻松地利用GPU的并行计算能力它就像一座桥梁连接了上层的AI框架如PyTorch、TensorFlow和下层的GPU硬件。过去十几年几乎所有的AI研究、模型训练和推理部署都默认运行在CUDA这座桥上。这种深度绑定使得英伟达的GPU成为了AI计算的“事实标准”形成了极强的用户粘性和生态锁定。然而当AI从实验室走向千行百业从云端大规模训练渗透到每一台终端设备进行推理时这种单一、封闭的生态开始显现出它的“副作用”。成本高企、供应商依赖、技术路径单一以及最重要的——创新的天花板。其他芯片厂商如AMD、英特尔以及众多AI初创芯片公司设计出了架构各异的AI加速芯片性能可能更优、能效比可能更高但它们面临的最大障碍就是如何让开发者愿意为它们重写代码如何让主流的AI框架和模型能顺畅地跑在自己的硬件上CUDA这座桥对英伟达是护城河对其他人则是难以逾越的天堑。微软的这次动作其深层逻辑正是试图成为那个“架桥人”或“制定新交通规则的人”。它没有选择正面硬撼CUDA而是从两个更底层的方向进行“迂回包抄”一是推动开放的、跨平台的编译器和运行时标准二是将AI能力深度、原生地集成到最庞大的终端生态——Windows之中。这不仅仅是微软和英伟达两家公司之间的商业博弈更标志着AI计算基础设施正在从“硬件定义软件”的单一垄断时代迈向“软件定义硬件”、“开放标准驱动创新”的新阶段。对于每一位开发者、每一家寻求AI落地的企业乃至整个科技行业理解这场变局的脉络和其中的技术细节都至关重要。2. 微软的“组合拳”DirectML、ONNX Runtime与Windows原生集成要拆解微软的策略不能只看其发布了什么硬件更要看它同步推进了哪些软件和生态层面的关键布局。这是一套精心设计的“组合拳”拳拳都指向降低开发门槛、打破硬件绑定。2.1 DirectMLWindows上的跨硬件AI加速层DirectML是微软推出的一个直接面向开发者的高性能机器学习API。它的核心定位非常清晰为Windows系统上的AI推理任务提供一个统一的、硬件加速的抽象层。开发者使用DirectML API编写代码无需关心底层究竟是英伟达的GPU、英特尔的集成显卡/独立显卡、高通的NPU还是AMD的加速器。DirectML驱动会负责将计算任务高效地分发到系统中最合适的硬件上执行。这带来的直接好处是解放了开发者。以前如果你想在Windows PC上做AI推理加速大概率要针对CUDA进行优化这无形中将设备限制在了搭载NVIDIA GPU的电脑上。而通过DirectML同一份代码可以在搭载英特尔Arc显卡、AMD Radeon显卡甚至未来更多品牌NPU的设备上运行大大扩展了应用的潜在用户基数。对于应用开发商而言这意味着更低的适配成本和更广的市场覆盖。2.2 ONNX与ONNX Runtime模型格式与运行时的“世界语”如果说DirectML解决了“在哪里跑”的问题那么ONNX则解决了“跑什么”的问题。ONNX是一种开放的模型表示格式你可以把它理解为AI模型的“世界语”或“集装箱标准”。开发者用PyTorch、TensorFlow等框架训练好的模型可以导出为标准的ONNX格式。这个ONNX模型就像一个封装好的集装箱可以被任何支持ONNX的运行环境所识别和载入。ONNX Runtime则是高效运行这个“集装箱”的引擎。它是一个跨平台的高性能推理引擎针对ONNX模型进行了深度优化。ORT的厉害之处在于它的“执行提供程序”架构。它本身是一个核心运行时但可以通过插入不同的“Execution Provider”来对接不同的硬件后端。例如CUDAExecutionProvider用于英伟达GPUDmlExecutionProvider用于Windows上的DirectML从而间接支持所有DirectML兼容的硬件OpenVINOExecutionProvider用于英特尔CPU/GPUQNNExecutionProvider用于高通骁龙平台等。微软的生态闭环就此形成开发者用主流框架训练模型 - 导出为ONNX标准格式 - 通过ONNX Runtime加载 - ONNX Runtime根据当前系统硬件自动选择或由开发者指定最佳的Execution Provider如DML- 最终通过DirectML在具体硬件上高效执行。这个链条将上层的模型开发与底层的硬件细节进行了彻底解耦。2.3 Windows Copilot Runtime系统级的AI能力“水电煤”在2024年Build大会上微软宣布了“Copilot PC”并推出了Windows Copilot Runtime。这是将上述技术栈从“可供调用的库”升级为“系统原生能力”的关键一步。Copilot Runtime包含了一系列预装在系统中的、本地运行的AI组件比如一个拥有数百亿参数、针对特定任务优化的小型语言模型以及视觉、语音等模型。更重要的是它向开发者暴露了统一的API。这意味着开发者开发Windows AI应用时可以直接调用系统提供的、经过深度优化的本地AI能力而无需自己费力去集成和维护复杂的模型推理管线。系统会默默地在后台处理好一切模型管理、硬件调度、资源分配。这极大地降低了开发门槛让更多应用可以轻松地融入AI功能。这一套组合拳的终极目标是建立一个以Windows和开放标准ONNX/DirectML为中心的、跨硬件厂商的AI应用生态。在这个生态里硬件厂商竞争的重点回归到芯片本身的性能、能效和成本而不是生态壁垒。这无疑是对现有游戏规则的一次重塑。3. CUDA护城河的真正构成与挑战要理解微软以及其他挑战者在做什么必须首先看清英伟达的CUDA护城河究竟有多宽、多深。它绝非一个简单的API而是一个层层递进、相互增强的复杂生态系统。3.1 软件栈的深度与广度CUDA的护城河最直观的部分是其极其丰富和成熟的软件栈CUDA Toolkit核心开发套件包括编译器、调试器、性能分析器。cuDNN深度神经网络原语库对卷积、池化、归一化等操作进行了极致优化。cuBLAS / cuFFT基础线性代数子程序和快速傅里叶变换库是许多科学计算和AI算法的基石。TensorRT专门用于深度学习推理的高性能SDK能对模型进行图优化、精度校准INT8/FP16、层融合等大幅提升推理速度和效率。NCCL多GPU、多节点通信库对于大规模分布式训练至关重要。这些库经过十多年的迭代其优化程度已经深入到芯片的微架构级别与英伟达自家的GPU硬件配合达到了“炉火纯青”的地步。一个常见的比喻是如果你用CUDA生态就像开着一辆出厂就调校到巅峰状态的赛车而如果用其他方案你可能需要自己从组装发动机开始。3.2 开发者心智与社区惯性这是比软件栈更无形的壁垒。全球数百万AI开发者、研究员、数据科学家的学习路径、代码库、项目经验都深深植根于CUDA。大学课程、在线教程、开源项目范例绝大多数都以CUDA/PyTorch为默认环境。这种惯性是巨大的。让一个已经熟练使用CUDA的团队切换到新的平台意味着巨大的学习成本、迁移成本和未知的技术风险。企业决策时“有没有CUDA支持”往往是一个一票否决的关键因素。3.3 与上层框架的深度融合PyTorch和TensorFlow这两个最主要的AI框架其GPU后端默认且优化最好的就是CUDA。虽然它们也开始支持其他后端如PyTorch支持ROCm但成熟度、稳定性和性能表现与CUDA版本仍有差距。这种框架层的深度绑定使得CUDA成为了AI开发“空气和水”一样的存在。因此挑战CUDA不是在挑战一个API而是在挑战一个由极致性能、完整工具链、庞大社区和用户习惯共同构成的完整生态体系。任何替代方案不仅需要在关键性能指标上接近甚至超越更需要提供一条平滑、低成本的迁移路径并构建起一个有生命力的开发者社区。这正是微软通过DirectMLONNXWindows原生集成所尝试的路径不追求在每一个细分性能指标上打败CUDA而是通过提供更高的开发便利性、更广的硬件覆盖度和系统级的深度集成来创造新的价值维度吸引开发者“用脚投票”。4. 开放标准的崛起MLIR、OpenXLA与行业合力微软并非在孤军奋战。打破封闭生态建立开放标准是整个行业尤其是受制于CUDA的硬件厂商和寻求降本增效的大用户的共同诉求。在这场运动中两个由巨头推动的开放编译器基础设施项目尤为关键。4.1 MLIR编译器领域的“LLVM for AI”MLIR由Google主导推出但其目标是成为整个行业的公共基础设施。你可以把传统的编译器想象成只能处理一种特定语言如C的翻译机。而MLIR则定义了一套通用的、可扩展的“中间表示”系统。它允许将不同层次的抽象高层AI计算图、中层循环优化、底层硬件指令都表达和转换到同一个框架内。MLIR的核心价值在于“解耦”和“复用”。硬件厂商可以为自己的芯片定义一套独特的、低层的MLIR方言Dialect。AI框架开发者则可以在高层MLIR上描述计算图。然后通过一系列可重用的、基于MLIR的编译优化pass可以将高层的计算图逐步“ lowering ”到特定硬件的低级方言最终生成高效的机器码。这意味着AMD、英特尔、高通等公司无需再为每一个AI框架PyTorch, TensorFlow, JAX…单独开发并维护一套完整且复杂的编译器后端它们只需要针对MLIR框架开发一个针对自己硬件的后端理论上就能支持所有基于MLIR的前端框架。这极大地降低了新硬件支持上层生态的难度和成本。4.2 OpenXLA针对机器学习负载的专用编译器如果说MLIR是提供了一套制造“翻译机”的通用工具和标准零件那么OpenXLA则是一个利用这些工具制造出来的、专门用于“翻译AI模型”的顶级翻译机。它最初源自Google内部的XLA编译器后来开源并发展为OpenXLA项目。OpenXLA接受来自多个框架TensorFlow, PyTorch, JAX的计算图并将其编译优化成在各类硬件CPU, GPU, TPU以及其他AI加速器上高效运行的代码。它的强大之处在于其跨框架、跨硬件的“全堆栈”优化能力。例如它能够进行跨操作符的融合、常量折叠、内存布局优化等这些优化在传统的、以算子为单位的执行方式中是无法实现的。OpenXLA与MLIR的关系是协同的。OpenXLA项目正在将其核心基础设施迁移到MLIR之上这意味着它能够利用MLIR的模块化和可扩展性。同时硬件厂商通过为MLIR贡献后端也能让自家的硬件获得OpenXLA的编译支持。微软的DirectML团队也积极参与MLIR和OpenXLA社区探索如何让DirectML作为硬件目标接入这个开放的编译生态。4.3 行业合力的趋势除了微软、Google像英特尔推动OpenVINO、oneAPI、AMD推动ROCm等公司都在大力投入开放标准。甚至一些云巨头和大型互联网公司出于避免供应商锁定和降低成本的需求也在支持多元化的AI硬件和软件栈。这种行业合力正在慢慢侵蚀CUDA生态的“唯一性”基础。虽然CUDA在可见的未来依然会是最主流、最成熟的选择但“唯一”和“主流”之间已经有了本质区别。开发者现在有了更多选择尤其是当这些选择背后有强大的生态如Windows和开放的技术标准作为支撑时。5. “Copilot PC”的硬件实质与生态野望让我们回到这次风波的直接导火索——Copilot PC。它不仅仅是“一台性能更强的电脑”其硬件配置和生态定位蕴含着微软深远的战略意图。5.1 NPU从“协处理器”到“主力计算单元”Copilot PC的核心硬件要求是必须搭载每秒可进行40万亿次运算的NPU。这个TOPS指标本身很重要但更重要的是NPU在系统架构中的角色转变。过去的PCAI计算主要由GPU或CPU兼职处理属于“客串”性质。而Copilot PC将NPU提升为与CPU、GPU并列的三大计算单元之一并且由系统直接管理和调度用于处理持续的、低功耗的AI负载。这带来的体验革新是直接的实时字幕翻译、照片视频的即时AI编辑、录音的智能摘要、基于自然语言的系统全局搜索等。这些功能需要持续感知环境并做出低延迟响应如果全部交给GPU处理功耗和发热将是无法接受的。专用NPU的高能效比特性使得“全天候AI助手”成为可能。这实际上是在定义下一代个人计算设备的交互范式从“人操作机器”变为“机器智能地辅助人”。5.2 高通骁龙X Elite/Plus的“破局”意义首批Copilot PC大量采用了基于Arm架构的高通骁龙X系列平台。这本身就是一个强烈的信号。长期以来Windows on Arm生态发展缓慢主要障碍在于x86应用兼容性和性能。但这一次微软联合高通从“AI PC”这个新赛道发起冲击。骁龙X Elite集成了强大的Oryon CPU、Adreno GPU以及标称性能达45 TOPS的Hexagon NPU其能效比在移动场景下极具竞争力。微软通过其Prism模拟器来保障x86应用的兼容性而将最体现差异化的、面向未来的AI体验全部构建在原生Arm64应用和本地NPU加速之上。这步棋非常巧妙它绕开了在传统性能上与x86芯片的正面厮杀而是开辟了一个以“全天候AI”和“超长续航”为核心卖点的新战场。如果成功它将不仅打破Wintel联盟的硬件垄断惯性更将Arm架构的能效优势带入主流PC市场为整个PC硬件创新注入新的活力。5.3 生态闭环的构建硬件、系统、开发者的三位一体微软的最终目标是构建一个以Windows为核心的、软硬一体的AI生态闭环硬件层通过Copilot PC规范推动OEM厂商联想、戴尔、惠普、三星等和高通、英特尔、AMD等芯片厂商生产符合标准的、内置高性能NPU的设备。系统层通过Windows Copilot Runtime将DirectML、ONNX Runtime等能力深度集成到操作系统中作为系统服务提供给所有应用。开发者层通过统一的Windows AI API和开发工具吸引开发者为这个庞大的、具备统一AI能力的设备生态开发应用。一旦这个闭环运转起来它将产生强大的网络效应。更多的AI PC设备吸引更多的开发者更丰富的AI应用又反过来促进更多用户购买AI PC。在这个生态里微软掌控着操作系统和核心API的定义权而硬件厂商则回归到比拼芯片设计、制造工艺和成本的“本职工作”上。这无疑是对现有以GPU为中心、以CUDA为壁垒的AI计算生态的一次结构性挑战。6. 开发者的新选择与迁移实践面对正在裂变的生态格局开发者该如何应对是坚守成熟的CUDA还是开始拥抱开放标准这并非一个非此即彼的选择而是一个需要根据项目阶段、团队能力和目标平台进行权衡的策略问题。6.1 评估项目需求与目标平台首先明确你的AI应用要运行在哪里云端训练与大规模推理目前CUDA生态在大型模型训练和云端高吞吐量推理方面依然拥有无可争议的领先优势。其工具链的成熟度、大规模集群的调度与管理、与云服务的深度集成短期内难以被完全替代。如果你的核心业务在此CUDA仍是首选。边缘设备与终端推理这是变数最大、也是开放标准发力最猛烈的领域。智能摄像头、汽车、手机、IoT设备以及现在的AI PC硬件平台碎片化严重。如果你的应用需要部署到多种不同的边缘硬件上那么基于ONNX Runtime 多后端支持包括CUDA、DML、OpenVINO、CoreML、QNN等的方案可以极大地降低你的维护成本实现“一次开发多处部署”。Windows原生应用如果你的应用主要面向Windows用户并且希望深度集成系统级的AI功能如Recall、实时翻译那么直接使用Windows Copilot Runtime API和DirectML将是最高效、体验最好的路径。这能让你直接利用系统优化过的本地模型和硬件加速。6.2 从PyTorch/TensorFlow到ONNX的模型导出拥抱开放生态的第一步通常是学会将训练好的模型导出为ONNX格式。以PyTorch为例这个过程已经非常简便import torch import torch.onnx # 假设你有一个训练好的模型 model 和一个样例输入 dummy_input model.eval() # 将模型设置为评估模式 # 指定导出的输入输出名称和动态轴如果需要处理可变尺寸输入 input_names [input] output_names [output] dynamic_axes { input: {0: batch_size, 2: height, 3: width}, # 示例动态批次、高、宽 output: {0: batch_size} } # 导出模型 torch.onnx.export( model, dummy_input, your_model.onnx, input_namesinput_names, output_namesoutput_names, dynamic_axesdynamic_axes, opset_version14, # 使用较新的算子集版本以获得更好支持 do_constant_foldingTrue # 常量折叠优化 )关键注意事项算子支持并非所有PyTorch或TensorFlow中的复杂操作都能在ONNX中找到完全对应的标准算子。在导出时可能会遇到不支持的算子错误。这时需要寻找替代实现或者自定义算子。动态形状如果你的模型需要支持可变尺寸的输入如图像大小不固定务必正确设置dynamic_axes参数否则导出的模型将是静态的灵活性受限。验证导出后务必使用ONNX Runtime加载并运行一次推理验证输出结果与原始框架是否在可接受的误差范围内一致。6.3 使用ONNX Runtime进行跨平台推理成功导出ONNX模型后你就可以使用ONNX Runtime进行推理了。其API设计简洁明了import onnxruntime as ort import numpy as np # 创建推理会话并指定执行提供程序 # 情况1优先使用DirectMLWindows providers [DmlExecutionProvider, CPUExecutionProvider] # 情况2优先使用CUDA如果系统有NVIDIA GPU # providers [CUDAExecutionProvider, CPUExecutionProvider] # 情况3优先使用OpenVINOIntel平台 # providers [OpenVINOExecutionProvider, CPUExecutionProvider] session ort.InferenceSession(your_model.onnx, providersproviders) # 准备输入数据注意格式和数据类型需与模型定义匹配 input_name session.get_inputs()[0].name output_name session.get_outputs()[0].name # 假设输入是 [batch, channel, height, width] 的float32图像数据 input_data np.random.randn(1, 3, 224, 224).astype(np.float32) # 运行推理 outputs session.run([output_name], {input_name: input_data}) result outputs[0]执行提供程序的选择策略 ORT允许你按优先级顺序提供一个执行提供程序列表。它会从前往后尝试初始化使用第一个成功的提供程序。这种设计让代码具有了硬件自适应性。在实际部署中你可以根据目标设备的特性动态生成或选择这个列表。6.4 性能调优与平台特定优化使用通用运行时意味着在获得便利性的同时可能会牺牲一些极致的性能。为了弥补这一点你需要进行针对性的优化模型图优化ORT在加载模型时会自动应用一系列图优化如算子融合、常量折叠。你可以通过SessionOptions启用更激进的优化级别。硬件厂商工具链虽然使用了ORT但你仍然可以结合硬件厂商提供的特定工具进行深度优化。例如如果你最终的目标硬件是英特尔CPU可以先用ONNX Runtime运行确认功能正确后再尝试使用英特尔OpenVINO Toolkit对ONNX模型进行进一步的量化、剪枝和编译优化以获得在其硬件上的最佳性能。高通、英伟达等也有类似的工具链。通用运行时保证“能跑”专用工具链追求“跑得最快”。量化将模型从FP32转换为INT8等低精度格式能大幅减少模型体积、提升推理速度尤其适合边缘设备。ORT支持训练后静态量化和动态量化。但需要注意量化可能会带来精度损失且需要目标硬件支持相应的低精度计算指令。迁移到开放生态是一个渐进的过程。对于新项目尤其是目标平台多样化的边缘AI项目从一开始就采用ONNXORT的架构是明智的。对于已有的CUDA项目可以尝试将推理部分剥离并迁移到ORT作为降低部署复杂度、探索多硬件支持的第一步。这场生态变迁不会一蹴而就但提前了解和布局无疑能让开发者在未来的技术选型中占据更主动的位置。
)
