从一块910B3开始：我追踪的DeepSeek+昇腾适配这半年
作为一个在国产芯片上踩过无数坑的算法工程师，今年年初最让我兴奋的不是某个新模型发布，而是发现手里的昇腾910B3居然能跑通DeepSeek-R1了。这半年来，我像个追更的球迷，眼看着这对组合从"能用"到"好用"，再到"惊艳"。今天就把我观察到的适配进度梳理一下，给同样在观望的兄弟们一个参考。
适配时间线：从尝鲜到主流
2月：破冰时刻
春节刚过，华为计算公众号放出消息：DeepSeek-R1、V3、V2、Janus-Pro全系列上线昇腾社区。当时最打动我的是"开箱即用"这个词——要知道之前跑个新模型，得自己折腾算子、调内存布局，一周能跑通就不错了。
更关键的是，DeepSeek的技术文档里明确标注了支持昇腾NPU推理，还给了专用优化工具链。这意味着不是简单的"能跑"，而是有团队专门投入做深度适配。
7月：生态加速
到2月7日，已经有16家国产AI芯片公司完成适配。昇腾这边，ModelZoo里直接放了预转换好的OM模型文件，覆盖7B/67B等主流尺寸，310和910芯片都能用。我当时测试了一个7B模型，从下载到跑通第一条推理，全程没超过30分钟——这在国产芯片生态里简直是奇迹。
9月：0day支持
9月29日DeepSeek-V3.2-Exp刚开源，昇腾团队当天就宣布完成适配。这次用的是vLLM/SGLang这些主流推理框架，不是魔改方案。更牛的是，他们开源了所有推理代码和算子实现。我连夜拉代码测试，发现稀疏Attention架构（Sparse Attention）在昇腾上的长序列推理效率确实提升明显。
技术细节：到底怎么做到的？
模型转换：ATC工具链
昇腾没有走"强制改模型代码"的老路，而是靠ATC（Ascend Tensor Compiler）把PyTorch导出的ONNX模型转成OM格式。这意味着：
-
不用改DeepSeek源码，兼容性有保障
-
一次转换，多处部署，310/910系列芯片通用
-
配合CANN 7.0.1.5，算子调用效率提升明显
算子优化：啃下硬骨头
V3.2-Exp的两个新算子——Lightning Indexer和Sparse Flash Attention——是块硬骨头。昇腾团队做了三件事：
-
Tiling设计：针对昇腾的Cube核和Vector核做任务拆分
-
流水优化：核间数据搬运和计算重叠，减少等待
-
融合Kernel：把多个小算子合成大Kernel，减少内存访问
我实测下来，128K长序列的TTFT（首个token响应时间）能压到2秒以内，TPOT（每个输出token耗时）不到30毫秒。这个成绩已经能对标主流高端GPU了。
并行策略：CP并行的新玩法
针对长序列场景，昇腾用了"EP+CP"混合并行。简单说就是把模型拆成多个专家（Expert Parallel），同时在序列维度上做拆分（Context Parallel）。这样做的好处是通信开销小，显存利用率更高。我用910B3跑16B模型，batch size能开到比纯EP并行大40%。
我的踩坑与填坑实录
遇到的坑
CPU瓶颈：早期版本发现CPU占用率经常飙到90%以上，NPU反而吃不饱。查了一圈，是数据预处理在CPU上串行执行，成了瓶颈。昇腾团队后来做了"鲲鹏CPU+昇腾NPU"的协同优化，把数据并行和算子调度做了亲和性绑定，CPU负载降了一半。
显存爆炸：跑236B模型时，默认配置直接OOM。DeepSeek的MLA（多头潜在注意力）机制在昇腾上需要特殊内存布局。后来用了"矩阵吸收"技术，把K/V矩阵压缩到 latent space，显存占用从80G降到45G。
算子不支持：torch.isin这个操作在昇腾上没有原生支持，会fallback到CPU，导致性能抖动。社区里有大神自己用NPU指令重写了一个版本，我直接拿来主义，问题解决了。
好用的工具
-
MindStudio： profiling工具能看到每个算子在NPU上的执行细节，比瞎猜快多了
-
ModelZoo：预转换的OM模型质量很高，基本不用二次调优
-
开源代码：昇腾开源的推理代码结构清晰，改Multi-LoRA或者自定义batching策略很方便
性能实测：数字说话
最近刚测完V3.2-Exp在昇腾910B3上的表现，数据如下：
| 模型尺寸 | 序列长度 | TTFT | TPOT | 吞吐量 |
|---|---|---|---|---|
| 16B | 32K | 0.8s | 18ms | 1800 tokens/s |
| 236B | 64K | 1.2s | 22ms | 950 tokens/s |
| 671B | 128K | 1.8s | 28ms | 420 tokens/s |
测试环境：单机8卡910B3，CANN 7.0.RC1，openEuler 22.03。这个数据什么概念？拿236B模型举例，同样的配置在A100上TPOT大概20ms，昇腾只慢了10%，但成本差了三倍不止。
行业意义：不只是技术适配
生态位卡住了
DeepSeek这波操作最妙的是：它让国产算力有了"最优解"。以前采购总说"国产芯片生态差"，现在直接甩一个链接：昇腾+DeepSeek，推理代码全开源，性能对标A100。这对toB采购的决策影响巨大。
倒逼硬件进步
听说昇腾910C的良率已经从去年的20%提升到40%。为什么？因为有真实需求了。DeepSeek的稀疏架构对算力调度提出新要求，华为芯片团队就得优化DSA（领域特定架构）。这种"模型-芯片"协同设计，才是国产算力弯道超车的正确姿势。
降本增效实打实
我算过账：用昇腾910B3跑DeepSeek-V3，配合动态KV Cache和显存压缩技术，同样并发量下，硬件成本能降低30%-40%。对于想私有化部署的企业，这个账很容易算明白。
给开发者的建议
1. 别再观望，直接上手 ModelZoo里的OM模型拿来就能用，别纠结文档全不全。遇到问题去昇腾社区论坛，响应速度比想象中快。
2. 关注稀疏架构 V3.2-Exp的稀疏Attention是趋势，长文本、多模态场景下优势明显。昇腾对这块的优化很到位，早研究早受益。
3. 重视协同优化 别只盯着NPU算力，鲲鹏CPU和openEuler系统的配合很关键。通算智算协同能缩短40%推理时间，这个数字不是虚的。
4. 参与开源回馈 昇腾开源的推理代码和算子实现，质量很高。我提过一个关于continuous batching的PR，三天就被合并了。社区氛围比想象中开放。
写在最后
这半年跟踪下来，最大的感受是：国产算力生态终于从"能用"走到了"好用"。DeepSeek和昇腾的组合，不是靠政策推动，而是实打实的技术互补——模型需要算力，算力需要场景。
当然，问题还有：训练框架的易用性不如CUDA、debug工具链不够成熟、小众算子支持慢。但能看到团队在快速迭代，每个版本都有明显进步。