企业官网建设流程全解析

前阵子我们组接到一个内部项目：把DeepSeek V4完整跑通在昇腾上。这里的"跑通"不是指能出几个token就算交差，而是从模型权重、算子适配、图编译、精度对齐到性能压测全部走完，最后给业务侧交付一个可用的推理接口。整件事前后花了几周时间，做完之后我对"芯模协同"这四个字的理解完全变了。这篇把我们的拆解思路、技术路线、落地过程和踩坑记录整理出来，给正在做国产算力适配的同行一个参考。

这篇文章适合几类人看：准备把大模型迁移到昇腾的推理工程师、做大模型平台和部署框架的开发同学、做技术选型的管理者。如果你对昇腾还不熟，也没关系，我会把CANN、MindIE、算子映射这些概念尽量用大白话拆开讲，你把这篇文章当一份"昇腾适配避坑指南"来用就行。

1. 芯模协同：到底在解决什么问题

1.1 先说结论：这不是一次简单的"模型搬家"

很多人以为在昇腾上跑DeepSeek V4，就是把PyTorch的权重文件搬过去，用某个工具转一下格式，然后跑个推理脚本就完事了。真实情况远没有这么简单。

大模型从设计之初就是围绕GPU的生态特征来的。比如CUDA生态里有非常成熟的算子库、通信库和推理框架，模型里的每一个算子几乎都能找到现成的高性能实现。而昇腾走的是另一套软硬件体系：达芬奇架构的AI Core、CANN软件栈、MindIE推理引擎，它的算子实现、内存管理、指令调度方式都和CUDA体系完全不一样。这意味着一个在GPU上跑得好好的模型，放到昇腾上可能连编译都过不了——某个算子不支持、某个shape推导出错、某个融合规则没覆盖到，每一环都可能卡住。

所以"芯模协同"这个词，本质上说的不是"把模型搬过来"，而是"让模型的运行方式和芯片的计算特性互相匹配"。模型侧要做结构适配，芯片侧要提供对应的算子能力和调度策略，两边一起调优，才能把一个模型真正"跑好"。我们这次的DeepSeek V4适配，本质上就是在做这件事。

1.2 昇腾和CUDA生态的底层差异

先聊清楚昇腾的软件栈长什么样，后面所有的适配工作都基于这个框架来展开。

昇腾最底层是达芬奇架构的AI Core，往上依次是：

• CANN（Compute Architecture for Neural Networks）：最核心的软件栈，负责算子开发、图编译、任务调度，类似CUDA的生态位
• MindIE：昇腾的推理引擎，负责大模型推理的加载、调度和执行，对标的是CUDA生态里的那些推理框架
• torch_npu / MindSpore：模型侧的接入层，torch_npu让PyTorch代码能在NPU上跑，MindSpore则是昇腾的原生框架
• ATC（Ascend Tensor Compiler）：模型转换编译工具，把ONNX等格式的模型编译成昇腾可执行的离线模型文件（.om）

关键点在于，CUDA生态里你写的是算子库的调用，昇腾上你需要关注算子在AI Core上怎么排布、AI Core上有多少计算单元、内存带宽怎么分配。同一个算子，在GPU上可能是一个已经封装好的函数，到了昇腾上可能就得看它的算子实现是否已经适配，没有的话就得自己写自定义算子。

还有一个不能忽略的差异：昇腾对静态Shape的支持比动态Shape成熟得多。动态Shape意味着每次输入的长度、batch大小都可能变化，这对算子的调度、内存的分配都是极大的压力。我们在适配过程中大量工作其实是在处理shape相关的兼容问题。

1.3 为什么选DeepSeek V4做协同适配

选DeepSeek V4作为适配目标，不是因为它"热度高"，而是它的架构特点非常适合用来检验一套国产算力栈的成熟度。

DeepSeek系列模型用的是MoE（Mixture of Experts，混合专家）架构，加上MLA（Multi-head Latent Attention，多头潜在注意力）机制。MoE的特点是：模型总参数量巨大，但推理时只激活其中一部分专家，这样可以显著降低计算量。这种稀疏激活的特性，对芯片的调度能力和内存带宽要求极高——你需要在很短的时间内决定哪些专家被激活，然后快速调度计算资源。

对昇腾来说，这是一个很好的压力测试：如果能把MoE架构的调度在昇腾上跑顺，说明这套软件栈的算子调度和图编译能力已经达到相当水平。反过来，如果MoE这种稀疏结构跑不通，那很多其他模型的适配也会有问题。

这也就是为什么我们说"芯模协同"不只是一个口号——它背后是一整套非常具体的工程问题：怎么把模型的计算拓扑映射到芯片的执行单元上，怎么让通信模式和芯片的互联结构匹配，怎么在精度和性能之间取平衡。下面拆开来讲。

2. 核心技术拆解：算子、图编译和MoE的适配难点

2.1 DeepSeek V4的架构特点与适配难点

先快速过一遍DeepSeek V4的架构面。它沿用了DeepSeek系列的MoE设计思路：一个大的Transformer主干网络，内部包含多个FFN专家模块，推理时通过路由网络（Router）选择激活哪些专家。MLA机制则对KV Cache做低秩压缩，降低显存占用，这对推理性能非常关键。

这个架构在昇腾上适配，会遇到几个具体难点。

第一个难点是自定义算子的映射。DeepSeek系列模型里有不少融合算子，比如注意力计算中的Flash Attention、MoE路由中的TopK选择逻辑。这些算子在PyTorch里可能是一个函数调用，但到了昇腾上，并没有一一对应的算子实现。我们前期花了不少时间梳理模型的算子清单，逐个核对昇腾算子库的覆盖情况。

第二个难点是路由和专家调度。MoE的Router需要根据输入动态选择专家，这涉及到数据的分发和收集。在GPU上，这一块已经有成熟的实现，但昇腾的通信方式和显存拓扑不一样，直接照搬会有性能问题。

第三个难点是动态形状。大模型推理时，输入序列长度不同，MoE每次激活的专家数也可能不同，这会让模型的执行图在运行时发生变化。昇腾对静态Shape的执行效率更高，所以我们需要在"保留动态能力"和"换取静态性能"之间做权衡。

2.2 算子映射与自定义算子开发

算子映射是整个适配工作中最琐碎、最容易出问题的一环。我们的流程是这样：

第一步，把PyTorch模型导出成ONNX。这一步看起来简单，实际上有很多细节要注意。导出时需要固定一部分shape，同时标记哪些维度是动态的。如果遇到不支持的导出操作，还需要改写部分forward代码，用ONNX支持的算子组合去替代。

第二步，把ONNX模型交给ATC工具做编译，这一步会输出一个算子支持情况报告。哪些算子能直接用，哪些需要自定义，一目了然。我们第一次编译时，报错集中在几类算子上：TopK、CumSum、Deformable Attention这类偏门算子，以及一些深度定制的融合算子。

第三步，对缺失算子做自定义开发。昇腾上开发自定义算子有两条路：一条是用Ascend C算子编程语言，直接面向AI Core写高性能实现，适合对性能要求极高的场景；另一条是用TBE（Tensor Boost Engine）框架，偏模板化，上手快一些。我们这次用Ascend C开发了两个核心算子：一个是MoE路由的TopK分发算子，另一个是MLA里的低秩投影算子。

心态上要有个准备：自定义算子的开发不是一锤子买卖。写完之后要用CPU/GPU的浮点结果做对比验证，逐元素比对误差，把精度对齐到可接受范围，然后才能进图编译。

2.3 图编译融合与Shape策略

算子映射解决的是"每个算子有没有得用"的问题，图编译解决的是"这些算子怎么组织效率更高"的问题。

ATC在编译ONNX模型时，会做几件关键的事：

• 算子融合：把连续的、可以合并的计算合并成一个算子，减少AI Core启停和数据搬运次数
• 内存复用：分析哪些中间结果生命周期不重叠，复用内存空间
• 指令调度：决定计算和搬运的先后顺序，尽量让AI Core的矩阵计算单元和向量计算单元都别闲着

这里有一个特别值得注意的点：昇腾的算子融合规则是跟具体的芯片型号相关的。同一个模型，在昇腾910系列的不同型号上编译，融合策略可能不一样。所以换芯片型号时，模型建议重新编译一次，不要用旧型号的.om文件硬跑。

Shape策略方面，我们的做法是生成两套模型：一套静态Shape，固定batch为1、序列长度固定为2048，用于追求极致性能；另一套动态Shape，支持序列长度从1到8192变化，用于业务侧的灵活接入。静态模型的性能明显更高，但业务场景千变万化，动态模型必不可少。这个取舍后面会细说。

2.4 MoE专家并行在昇腾上的重排

MoE的专家调度，是这次适配中最有"芯模协同"感觉的部分。

DeepSeek V4的MoE层里有多个专家，推理时Router对每个token算出应该走哪些专家。如果这些专家分布在多张昇腾卡上，就需要把token按专家归属做分发，这会产生大量的通信操作。GPU生态里，这块通常靠NCCL这类通信库搞定。昇腾有自己的通信机制，叫做HCCS（Huawei Cache Compression System？）——不对，实际是HCCL（集合通信库）。我们的工作重点是把模型里的专家并行策略和昇腾卡间的互联拓扑对齐，让通信尽量发生在物理距离近的卡之间。

具体的做法：查询昇腾设备的拓扑信息，把专家分组和卡间连接关系做了一次重排，让同一批查询token最常访问的专家，物理分布在相邻的卡上。这个调整做完，MoE层所有token的网络通信量明显下降，端到端耗时降了一截。

这里要说一个挺反直觉的经验：模型侧的并行策略，有时候要反过来适应芯片的拓扑结构，而不是一味照搬GPU上的玩法。就像搬家的时候，不是把所有东西都塞进一个房间，而是根据房间的布局重新安排收纳——这就是芯模协同最直观的体现。

3. 全流程实操：从PyTorch权重到昇腾推理

3.1 环境准备：工具链与版本选型

先列一下我们这次使用的环境，供参考：

版本选型的第一原则是：跟着官方支撑矩阵走，不要自己搞混搭。我们一开始贪新鲜，想用最新的CANN版本搭配较早的torch_npu，结果算子注册老是出问题。折腾了两天，最后回到官方发布说明里列出的匹配组合才稳定下来。

另一个环境层面的提醒：昇腾的镜像最好用官方提供的容器镜像，里面CANN、驱动、固件的组合已经验证过。自己手动装很容易出现版本不匹配的问题。我们最开始在物理机上装，踩了一堆坑，切到官方容器镜像后世界安静了。

3.2 模型转换与OM生成

环境就绪之后，整个转换流程分三步走。

第一步是导出ONNX。以下面的方式用torch.onnx.export导出，注意用dynamic_axes标记动态维度，否则后续推理时序列长度一变就没法用了：

import torch dummy_input = ( torch.randint(0, 100000, (1, 2048), dtype=torch.int64).cpu(), torch.randint(0, 100000, (1, 2048), dtype=torch.int64).cpu(), ) torch.onnx.export( model, dummy_input, "deepseek_v4.onnx", opset_version=17, input_names=["input_ids", "attention_mask"], output_names=["logits"], dynamic_axes={ "input_ids": {0: "batch_size", 1: "seq_len"}, "attention_mask": {0: "batch_size", 1: "seq_len"}, "logits": {0: "batch_size", 1: "seq_len"}, }, )

第二步是ONNX算子检查。可以用ATC先做一次试编译，它会明确报出哪些算子不支持。我们遇到的几个典型报错：

• 算子类型为TopK的节点不被支持
• 算子类型为CumSum的节点不被支持
• 某个自定义融合算子不识别

遇到这些之后，我们有两条路可以选：改写模型代码，用已支持的算子组合替代；或者开发自定义算子。对于TopK，我们选择了改写：把TopK拆成了"排序+切片"，虽然多占了一点计算量，但省去了算子开发周期。对于MLA里的那个自定义融合算子，没有替代方案，只能走Ascend C开发。

第三步是ATC编译。这一条命令的例子：

atc --model=deepseek_v4.onnx \ --framework=5 \ --output=deepseek_v4 \ --soc_version=Ascend910B3 \ --input_shape="input_ids:1,2048;attention_mask:1,2048" \ --insert_op_conf=aipp_config.cfg \ --precision_mode=allow_mix_precision \ --log=info

其中soc_version要填实际芯片型号，precision_mode控制混合精度的策略。编译成功后会生成.om文件，这就是昇腾的离线模型。

值得注意的是，ONNX导出这一步非常耗时且易碎。模型里的if分支、动态循环、某些Python控制流都会导致导出失败。我们团队里有个同事专门改模型里不支持导出的代码段，改了几十处才顺利走出来。

3.3 精度对齐流程与阈值标准

模型编译通过之后，并不意味着工作完成了。在GPU上跑得好好的，到昇腾上可能结果就飘了。精度对齐是这个项目里最磨人的一环。

我们的精度对齐分三个层次：

第一层，算子级比对。对每个关键算子，用同一份输入分别在GPU和昇腾上执行，计算输出张量的cosine相似度和最大绝对误差。我们的要求是：cosine相似度大于0.999，最大绝对误差小于1e-2（混合精度下）。如果某个算子偏差超限，就逐项排查，通常是算子实现中中间精度保留不够（比如某些中间结果被强制cast到FP16，精度损失被放大）。

第二层，模型级比对。用一组固定的prompt，在GPU和昇腾上各跑一遍前向，比对logits分布。阈值是：logits的cosine相似度大于0.99，top-1预测一致率大于98%。这层能暴露算子级测试发现不了的累加误差问题。

第三层，生成级比人。拉一个几百条（包含数学推理、代码生成、摘要）的测试集，让模型真实生成文本，人工检查结果是否与GPU一致。生成级的偏差往往不体现在logits指标上，而体现在长文本的多步推理结果偏离上，这一步不能省。

精度对不齐时，我们的排查顺序是：

1. 检查输入数据预处理是否完全一致（tokenizer版本与padding策略）
2. 逐个冻结模型层，做二分定位
3. 确认混合精度时哪些层被降到了FP16/BF16，调整precision_mode配置
4. 检查自定义算子内核的累加顺序和中间精度

印象最深的一次：精度偏差定位了整整两天，最后发现是某个归一化算子在NPU上用的是近似算法，精度略低于GPU，直接替换成更高精度的算子实现后问题消失。这种问题常规文档根本不会写，只能靠实测排查。

3.4 性能调优：Batch、序列长度与内存池

精度对齐后进入性能调优阶段，这阶段的目标是让模型"跑得快"而不只是"跑得对"。

先说一个评估基准：我们用一组固定长度的测试数据，分别对比静态Shape模型、动态Shape模型在GPU和昇腾上的推理吞吐和首token延迟。结果符合预期：静态Shape显著优于动态Shape，昇腾在稳定的batch和序列长度下能发挥出更好的性能水平。

性能调优主要做了几件事：

• Batch Size与序列长度分组：把业务侧请求按token长度分段，每段固定shape，用不同的静态模型服务，兼得灵活性和性能
• 内存池设置：动态Shape下NPU内存分配碎片化严重，我们在MindIE里设置了统一的缓存池，把内存碎片率降了下来
• 算子融合开关：对照昇腾融合规则文档，逐个开启可用的融合优化。有些融合开启后精度会轻微下降，需要跟精度对齐组来回沟通确认
• KV Cache量化：MLA的低秩特性在昇腾上带来了一个额外红利——KV Cache占用比传统模型更小，但缓存策略仍需单独调优

调优过程不是一次到位的。我们是"改一个参数、压一次测、记录结果、再改下一个"的笨办法，靠一张对比表串联起全部实验。性能对比表大致长这样：

需要提醒的是，这些数字只在我们这次的硬件和模型配置下有效。不同型号的芯片、不同的batch策略，结果差异会很大。性能调优一定要以自己环境的实测数据为准，参考别人的数字只能当方向性指引。

4. 常见问题与排查技巧实录

4.1 "算子不支持"的快速处理套路

这是昇腾适配里出现频率最高的一类错误。遇到算子不支持时，先别急着写自定义算子，按以下顺序尝试：

1. 查昇腾官方算子支持清单，确认是否真的不支持
2. 看能不能通过修改模型实现来绕开（比如把TopK拆成排序+切片）
3. 看ONNX算子的subgraph版本，有些算子高版本不支持，低版本反而可以
4. 最后才考虑开发自定义算子

自定义算子开发的工作量很大，而且调试周期长，非必要不碰。判断必要性有一个简单标准：这个算子在整个模型的计算耗时中占比是否达到5%以上？如果没有，绕开它可能是更划算的选择。

4.2 精度对不齐的定位方法

精度问题是最难调的。我们沉淀下来一个固定排查链路：

1. 固定输入，确保预处理完全一致
2. 在模型中间层插入hook，逐层对比输出
3. 找到偏差爆发的第一层，锁定嫌疑算子
4. 检查该算子在NPU上的实现方式（是FP16累加还是BF16，是不是用了近似算法）
5. 针对性地替换实现或调整混合精度策略

工具层面，昇腾的msprof性能剖析工具配合torch_npu的dump接口，可以导出NPU上每个算子的输入输出，和GPU侧逐元素比对。这套组合基本能解决90%的精度定位问题。

4.3 性能不达标的排查路径

性能问题我们遇到过几类：首token延迟高、吞吐上不去、显存占用异常增长。排查时按这个顺序来：

• 先看是否存在CPU与NPU之间的同步等待，数据搬运链路是否成了瓶颈
• 再看算子图是否被过度切分，小算子过多导致AI Core启动开销大
• 继续看动态Shape是否导致频繁重编译，如果是，优先改静态Shape
• 最后看通信占比，MoE场景下多卡all-to-all通信往往是隐性瓶颈

定位通信瓶颈时可以用一个简单技巧：先把模型改成单卡执行，对比多卡和单卡的时间差，就能估算通信开销占比。如果通信开销超过总耗时的30%，就该认真优化并行策略了。

4.4 问题速查表

把这次遇到的高频问题整理成一个速查表，方便大家对照：

4.5 一个容易被忽视的坑：warmup与动态编译

最后单独拎一个坑出来说。昇腾的推理服务上线后，第一次请求往往会非常慢，有时比后续请求慢一个数量级。原因在于运行时存在懒编译：模型第一次执行到某个分支时才开始编译对应的算子内核。如果业务侧没有做预热，线上第一个请求就会超时。

我们的做法是在服务启动阶段主动跑几条不同长度的请求，把最常见的shape组合都触发一遍，确保算子内核在正式流量进来前已经编译完毕。这个细节虽然简单，但如果不处理，上线当天就会收到告警。

另外，昇腾的日志里有大量从0开始累加的错误计数，多数是网关层预设的阈值过高导致。排查问题时建议先看核心索引日志，别被外层日志的数量吓到。

5. 这次适配做完，我的一些真实体会

项目收尾那天，团队里有人问了一个问题："这次适配最大的收获是什么？"我当时的回答是：最大的收获不是让那个模型在昇腾上跑起来了，而是把"昇腾到底能不能跑大模型"这个问题从一个观点变成了一个经过验证的答案。

在动手之前，团队里也有不同声音：有人觉得昇腾生态还不成熟，适配成本太高；有人觉得MoE架构太复杂，短期内搞不定。事实是，确实有很多坑，工具链的完善程度和CUDA生态比还有差距，但这套体系已经具备支撑真实业务的能力了——只要愿意花时间摸清它的脾性。

我个人最大的感触是：跨生态适配，真正难的不是技术本身，而是"预期管理"。当你习惯了CUDA生态里"开箱即用"的体验之后，切换到昇腾需要一个心态转变——很多在GPU上理所当然的事情，在这里都需要你亲自确认一遍。比如算子支持、精度行为、性能特性，这些都不能假设，都要实测。

如果你正在做类似的适配，我的建议是：先做一个小验证项目，挑一个运算量适中、算子种类有代表性的模型，完整走一遍转换、编译、精度校验和性能调优的闭环。把全流程的坑踩一遍之后，再上DeepSeek这种量级的模型。别一上来就直接跑大模型，否则你会同时面对格式问题、精度问题、性能问题三座大山，排查起来非常痛苦。

最后分享一个小技巧：在整个适配过程中，一定要把每一次报错信息、环境版本、处理方式都记录下来。跨生态适配的问题往往看起来毫无规律，但记录多了你会发现，很多问题在不同模型上是重复出现的。建一个自己的问题库，比翻任何官方文档都管用。