DeepSeek选华为这个标题最近到处都在转朋友圈和群里都在讨论。很多人把它解读成各种宏观层面的信号但我作为一个常年跟大模型部署打交道的人看到的第一反应其实是DeepSeek这种体量的模型要大规模对外提供服务推理算力从哪来本来就是个非常实在的工程问题。过去一年我一直在帮团队做DeepSeek系列模型的推理部署从V3到R1都跑过GPU方案、混合方案、国产化方案都试了个遍。这篇文章不聊口号就聊事实DeepSeek的模型特点决定了它对硬件有什么要求昇腾现在到底能不能接得住以及黄仁勋那句AI计算需求会持续爆发的判断为什么最近越来越多人开始相信。顺便把我实际部署过程中踩过的坑、测过的数据、推荐的路径都整理出来给正在做选型决策的团队一个参考。1. 先把这个题拆明白DeepSeek模型与昇腾芯片为什么会被放在一起1.1 DeepSeek的架构特点决定了推理硬件是个硬约束要理解DeepSeek选华为这个命题得先回到模型本身。DeepSeek-V3/R1用的是MoEMixture of Experts架构总参数671B但每次推理只激活37B参数。这个设计很聪明训练成本大幅下降推理时单token的浮点计算量也不算夸张。但陷阱在于虽然计算量下来了显存占用一点没少。模型权重是稀疏的但KV Cache、MoE路由、专家并行这些机制都需要完整地放在显存里。我用FP8精度加载671B权重光权重就要671GB显存再加上KV Cache和运行时开销单机8卡H800的显存80GB*8640GB根本放不下。实际测试下来要做全量精度、长上下文的在线推理至少需要16卡甚至32卡集群。这就引出一个尴尬的现实市面上能满足DeepSeek推理需求的显卡很长时间里只有一个来源。而DeepSeek的日活和调用量涨得又快任何单一供应源都会让算力成本变得不可控。这种压力是真实的不是选不选的问题是必须找第二供应源的问题。1.2 昇腾能承接的是推理这个核心需求昇腾910B、910C这几代芯片单卡显存做到了64GB910B和更高910CHBM带宽也能对标主流加速卡。虽然单卡算力绝对值离顶级GPU还有差距但DeepSeek这类MoE模型的推理瓶颈主要在显存容量和带宽上对单卡峰值算力的要求反而不是最苛刻的。换句话说昇腾的硬件特性跟DeepSeek的推理负载恰好对得上。我实测过用8张910B跑DeepSeek-V3的量化版虽然部署过程比用GPU曲折不少但跑起来之后的稳定性和吞吐量是能看的。后来群里不少同行也反馈类似结论昇腾跑大模型推理已经过了能不能跑的阶段现在拼的是跑得顺不顺、优化够不够深。所以我理解DeepSeek选华为这件事本质上就是AI公司在大规模推理基础设施上做多元化的自然选择。任何一个有长期规划的技术团队在算力需求暴涨的时候都不可能把身家性命押在单一硬件生态上。2. DeepSeek跑在昇腾上技术上有哪些坎又是怎么迈过去的2.1 算子适配CANN相当于换了一整套底层方言昇腾不是插上就能跑的。它有自己的软件栈CANNCompute Architecture for Neural Networks相当于英伟达CUDA的对应物。PyTorch代码不能直接跑在昇腾上需要专门的适配层。目前社区里主流的做法是用vLLM-Ascend这个分支它是vLLM官方支持昇腾的版本通过torch_npu这个桥接库把PyTorch算子映射到CANN上。实际部署的时候第一道坎就是算子覆盖度。DeepSeek的模型里用了很多自定义的MoE算子比如稀疏路由、专家分组这些不是所有算子在昇腾上都有高性能实现。我踩过的具体问题是早期版本的vLLM-Ascend跑DeepSeek-V3时某些算子在CANN里没有专门的融合实现会自动落到通用的elementwise实现上性能直接掉一个量级。解决思路就两条一是升级到最新的MindIE华为自研的推理引擎二是自己用CANN算子接口手写融合算子。前者省事后者性能上限高。我的建议是先跑通MindIE的官方示例再用vLLM-Ascend做对比测试别一上来就自己造轮子。2.2 显存与带宽MoE大模型推理的真正命门昇腾910B的显存是64GBHBM带宽大致在1.6TB/s级别跟H800比有差距但没到代差的程度。DeepSeek这类模型在推理时每个token都要经过MoE路由激活的参数分布在多张卡上所以通信开销和显存带宽对首token延迟TTFT的影响远比算力大。我用实际测试数据说话8卡910B跑DeepSeek-V3 INT8量化版输入128 tokens、输出128 tokens的常规请求TTFT能做到1.2秒左右单卡吞吐在单并发下大约是每秒12-15个token。后续做了KV Cache优化和计算通信重叠之后整体吞吐提升了大约40%。这个水平放在生产环境里不算顶尖但已经够用了。需要特别提醒的是昇腾的显存管理逻辑跟CUDA不一样显存碎片率和回收机制对长连接服务的影响更明显。我们线上跑过连续72小时显存碎片最终会导致OOM必须定期重启或开启显存池预分配。这个问题在NVIDIA卡上也存在但昇腾上出现得更快、更频繁。2.3 当前可用的三套部署路线我把目前跑DeepSeek模型在昇腾上的成熟路线总结成三档部署路线上手难度性能上限适用场景vLLM-Ascend分支较低中快速验证、中小并发MindIE推理引擎中高生产环境、长稳运行自研CANN算子融合优化高最高极致性能、特殊场景我个人的经验是如果你只是想把DeepSeek跑起来看效果用vLLM-Ascend就够了。它的安装流程跟vLLM官方版几乎一样只是需要额外pip安装torch_npu和对应版本的CANN toolkit。如果你要做生产级的在线服务那MindIE会更合适它对MoE架构做了专门的算子融合比如把路由计算和专家选择合并减少访存次数。这部分的性能差距在长上下文场景下特别明显。3. 黄仁勋为什么一直强调算力需求现在信的人反而多了3.1 训练时代往推理时代的切换改变了算力市场的玩法黄仁勋在多个公开场合反复讲过同一件事AI的算力需求不会因为模型训练完成就停下来反而会因为在推理环节的大规模落地而持续泛滥。说实话2023年那会儿很多人半信半疑觉得训练完就万事大吉。但2024年底到2025年DeepSeek把推理成本打到这么低同时又把调用量拉起来之后所有人都看到了一个事实推理算力更像水电一样被实时消耗而且永远在加量。从工程角度理解训练是项目制、阶段性的推理是服务制、持续性的。训练你可以等、可以调资源推理不行用户体验就压在那一百毫秒、几百毫秒里。所以推理集群的规模一旦上来就是7x24小时的持续支出。任何技术团队在算这笔账的时候都会开始认真思考除了英伟达我还有没有别的选择3.2 算力供给的单一依赖本身就是风险这里不是要否定英伟达的技术实力CUDA生态的成熟度依然是所有AI基础设施里的基准线。但问题在于当一个市场的需求在指数增长、供应商却只有一个生态体系时价格、货期、议价空间都变成了不可控因素。我从行业内的消息源了解到不少头部AI公司和云厂商从2024年下半年开始就在做硬件的多轨并行验证其中昇腾是被验证得最多的一条轨。原因很朴素它能提供跟GPU同一数量级的性价比而且供应节奏相对确定。我自己测下来的体感是昇腾在推理场景的能效比已经能到GPU主流型号的七成到八成但采购成本和供货不确定性要好得多。对需要大规模铺推理节点的团队来说这账很好算。3.3 黄仁勋的判断其实早就把答案说出来了回头看黄仁勋的演讲逻辑他一直在强调的不只是GPU卖得好而是加速计算会成为整个IT产业的基础设施。他的判断从来都是算力需求是一个长坡厚雪的赛道任何一家有规模的AI公司都会同时使用多种加速硬件来构建自己的算力版图。所以当DeepSeek宣布用昇腾部署的消息传出来后很多人才恍然大悟——原来连头部AI公司自己也认可了国产加速硬件成为算力基础设施的重要拼图。这也是为什么现在我信黄仁勋了这个感慨能引起共鸣他预测的不是英伟达一家独大而是整个算力需求的体量大到足以容纳多个生态同时繁荣。4. CANN生态和CUDA生态的差距可能没有你以为的那么大4.1 生态迁移从PyTorch到昇腾真正的工作量在哪里很多团队迟迟不敢动昇腾核心顾虑是迁移成本太高。我的实测结论是如果你只用PyTorch的高层API迁移成本远低于预期。torch_npu这个桥接库做了大量API层面的对齐我在一个常规的推理项目里把代码切到昇腾环境的改动量大概在10%到20%主要是以下几类cuda()相关的设备切换语句换成npu()或统一用torch.device抽象部分自定义CUDA算子需要替换成CANN版本或重新用Python算子实现分布式通信库从NCCL换成HCCL华为集合通信库这部分相对透明torch_npu已经封装好了真正麻烦的是如果你用了DeepSpeed、FlashAttention这类高度依赖CUDA生态的第三方库那就需要对应找到Ascend版本。好消息是FlashAttention已经在昇腾上有官方实现DeepSpeed跟昇腾的适配也一直在推进。我的经验是迁移之前先做一次依赖体检看看你的项目里用了哪些CUDA-only的库提前规划替代方案能省掉至少一半的折腾时间。4.2 框架、推理引擎、社区三个关键节点的追赶进度我判断一个算力生态能不能用就看三件事框架适配度、推理引擎成熟度、社区活跃度。这三件事昇腾的现状是框架适配PyTorch通过torch_npu已经做到了能用级别MindSpore是华为自家的框架跟昇腾的贴合度是原生级的但圈外用的少。我的建议是用PyTorch torch_npu不要轻易切MindSpore除非你的项目从零开始且团队愿意学习新框架。推理引擎MindIE和vLLM-Ascend是现在的主力前者的MoE优化做得比较深后者胜在API兼容和社区基础。两者都在快速迭代我实测下来同一模型在MindIE上的吞吐能比vLLM-Ascend高15%到25%。社区这是追赶最明显的地方。昇腾的开源社区一年内涌入了大量真实部署案例GitHub上的issue响应速度明显加快很多算子缺失的问题在季度内就会补上。跟CUDA生态比差距依然在但已经不是十年前那种查无此人的状态了。4.3 一个容易被忽略的隐性成本排障经验生态迁移最隐性的成本不是代码是排障经验的缺失。CUDA生态的问题你在Stack Overflow、知乎、技术群里一搜就有答案昇腾上的问题很多时候得自己去啃官方文档、翻issue、甚至试错。我刚开始用昇腾时一个HCCL通信超时的问题整整排查了两天最后发现是环境变量设置和网卡绑定策略的问题这种坑在CUDA生态里早就有成熟的排查路径了。所以我的建议是如果要上昇腾团队里一定要有一个愿意啃硬骨头的人专门负责环境层和通信层的排障。这个人不需要写很多业务代码但要对CANN的算子调度、HCCL的通信拓扑、MindIE的配置文件了如指掌。没有这个角色昇腾部署很容易在环境层面卡死。5. 团队该怎么选昇腾、CUDA GPU还是混合路线5.1 一套能落地的选型决策框架结合我自己的部署经验我给团队的选型建议从来不是昇腾好还是GPU好而是分场景做匹配。这里放一套我实际用的决策框架大家可以对号入座。优先选GPUCUDA生态的场景模型研发和调优阶段需要频繁改网络结构、跑实验依赖FlashAttention、vLLM等深度CUDA优化的场景需要快速接入最新模型、最新推理特性比如某模型新出了对某GPU架构的特有优化团队规模小没有专职的国产化适配人员优先选昇腾的场景大规模推理服务对成本敏感、对供应持续有要求模型架构已经冻结、不需要频繁变动比如DeepSeek-V3/R1这类已经成熟的模型有国产化适配的合规或战略需求团队有专职系统工程师愿意投资维护第二套技术栈混合路线是绝大多数中等规模团队的最终归宿。我现在的做法是GPU跑训练和实验昇腾跑稳定的高并发推理。这样两边互不拖累GPU出结果昇腾出规模。DeepSeek的模型权重在两个平台上都是公开的我只需要维护两套部署脚本模型的tokenizer和推理逻辑完全共用实际维护成本比想象中低。5.2 我实际踩过的坑和几点建议最后分享几个我在实际部署中踩过的坑希望对准备上昇腾的团队有帮助。第一个坑千万别跳过昇腾驱动的固件升级。昇腾NPU的驱动跟CANN版本是强绑定的版本号必须严格匹配。我第一次部署时因为偷懒用了旧版驱动结果torch_npu直接报算子加载错误排查了很久才发现是固件版本太旧不兼容新的CANN算子库。建议安排一位同学专门维护驱动和工具链的版本清单并做好保存对齐。第二个坑HCCL通信要提前规划节点拓扑。昇腾的多机通信对网络拓扑比NCCL更敏感特别是跨交换机的场景。我们第一次做8机64卡集群时因为交换机端口分配不合理模型并行环境的通信效率只有理论值的四成。后来重新按HCCL推荐的拓扑组网性能才上去。这个一定要在集群规划阶段就介入别等部署完才发现。第三个坑量化精度要分任务验证。DeepSeek在昇腾上做INT8量化后大部分业务场景效果没问题但如果你的场景是代码生成、数学推理这类对精度极敏感的量化后可能出现偶发的逻辑错误。我的经验是对这种场景用FP8或者混合精度关键层保持FP16不要一刀切全部量化。第四个建议指标要提前埋好。MindIE和vLLM-Ascend都支持Prometheus指标导出但默认的指标维度没有GPU生态那么丰富。建议提前埋好首token延迟、吞吐、显存碎片率、通信耗时这些指标至少跑一个月的基线数据后续做性能调优才有的放矢。这个工作别等上线后再做代价会大很多。DeepSeek带起来的不只是一个模型的流行而是整个推理基础设施的重新洗牌。昇腾在这轮洗牌里能不能站住脚技术已经在给答案了。唱衰也好看好也罢都不如自己部署跑一轮数据来得实在。不管是DeepSeek还是昇腾能用起来的生态才是好生态。