企业官网建设流程全解析

"DeepSeek选华为"这个标题最近到处都在转，朋友圈和群里都在讨论。很多人把它解读成各种宏观层面的信号，但我作为一个常年跟大模型部署打交道的人，看到的第一反应其实是：DeepSeek这种体量的模型要大规模对外提供服务，推理算力从哪来，本来就是个非常实在的工程问题。

过去一年，我一直在帮团队做DeepSeek系列模型的推理部署，从V3到R1都跑过，GPU方案、混合方案、国产化方案都试了个遍。这篇文章不聊口号，就聊事实：DeepSeek的模型特点决定了它对硬件有什么要求，昇腾现在到底能不能接得住，以及黄仁勋那句"AI计算需求会持续爆发"的判断，为什么最近越来越多人开始相信。顺便把我实际部署过程中踩过的坑、测过的数据、推荐的路径都整理出来，给正在做选型决策的团队一个参考。

1. 先把这个题拆明白：DeepSeek模型与昇腾芯片为什么会被放在一起

1.1 DeepSeek的架构特点决定了推理硬件是个硬约束

要理解"DeepSeek选华为"这个命题，得先回到模型本身。DeepSeek-V3/R1用的是MoE（Mixture of Experts）架构，总参数671B，但每次推理只激活37B参数。这个设计很聪明，训练成本大幅下降，推理时单token的浮点计算量也不算夸张。但陷阱在于：虽然计算量下来了，显存占用一点没少。

模型权重是稀疏的，但KV Cache、MoE路由、专家并行这些机制都需要完整地放在显存里。我用FP8精度加载671B权重，光权重就要671GB显存，再加上KV Cache和运行时开销，单机8卡H800的显存（80GB*8=640GB）根本放不下。实际测试下来，要做全量精度、长上下文的在线推理，至少需要16卡甚至32卡集群。

这就引出一个尴尬的现实：市面上能满足DeepSeek推理需求的显卡，很长时间里只有一个来源。而DeepSeek的日活和调用量涨得又快，任何单一供应源都会让算力成本变得不可控。这种压力是真实的，不是选不选的问题，是必须找第二供应源的问题。

1.2 昇腾能承接的是"推理"这个核心需求

昇腾910B、910C这几代芯片，单卡显存做到了64GB（910B）和更高（910C），HBM带宽也能对标主流加速卡。虽然单卡算力绝对值离顶级GPU还有差距，但DeepSeek这类MoE模型的推理瓶颈主要在显存容量和带宽上，对单卡峰值算力的要求反而不是最苛刻的。换句话说，昇腾的硬件特性跟DeepSeek的推理负载恰好对得上。

我实测过用8张910B跑DeepSeek-V3的量化版，虽然部署过程比用GPU曲折不少，但跑起来之后的稳定性和吞吐量是能看的。后来群里不少同行也反馈类似结论：昇腾跑大模型推理，已经过了"能不能跑"的阶段，现在拼的是"跑得顺不顺、优化够不够深"。

所以我理解"DeepSeek选华为"这件事，本质上就是AI公司在大规模推理基础设施上做多元化的自然选择。任何一个有长期规划的技术团队，在算力需求暴涨的时候，都不可能把身家性命押在单一硬件生态上。

2. DeepSeek跑在昇腾上，技术上有哪些坎，又是怎么迈过去的

2.1 算子适配：CANN相当于换了一整套底层"方言"

昇腾不是插上就能跑的。它有自己的软件栈CANN（Compute 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的显存是64GB，HBM带宽大致在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模型在昇腾上的成熟路线总结成三档：

我个人的经验是：如果你只是想把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好"，而是分场景做匹配。这里放一套我实际用的决策框架，大家可以对号入座。

优先选GPU（CUDA生态）的场景：

• 模型研发和调优阶段，需要频繁改网络结构、跑实验
• 依赖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还是昇腾，能用起来的生态才是好生态。