2026年6月5日，据深圳发布消息，深圳河套学院AI训练平台项目团队联合哈尔滨工业大学（深圳）、深圳市大数据研究院、华为有关团队，协同深智城AI算力平台，依托昇腾910C集群完成了DeepSeek V4-Pro全参数后训练。新浪科技、IT之家等随后跟进报道。这个模型的参数规模是1.6万亿。
训练跑通，是一个节点。但把模型搬进推理服务，问题会换一种方式出现。
我们接触到的5家已做迁移的团队，行业不一样：短视频内容审核、金融智能客服、语音识别、大模型API、自动驾驶感知。它们遇到的麻烦并不完全相同，但排查到最后，常见卡点集中在几层：CANN算子库、内存访问、通信链路，以及集群调度。
算子没融合，实时链路先抖起来
一位短视频平台推理引擎负责人赵刚（化名）提到，他们把一款内容审核模型从H200迁到910C后，P99延迟明显拉高。模型是Transformer和卷积混合架构，业务要求是实时审核，尾延迟比平均值更敏感。
Profiling之后，团队发现CPU和NPU之间的同步等待占了不少时间。问题不在单个大算子，而在一批基础算子：Transpose、Gather这类操作没有按他们预期完成融合，算子发射次数多，上下文切换也多。
赵刚的说法很直接：过去在H200上，很多类似操作由cuBLAS、cuDNN等库配合完成，工程师不一定会显式感知到；迁到昇腾后，关键子图需要重新看一遍，有些地方要手动写融合规则，或者等CANN版本补齐。
他们最后用CANN 8.0.RC1的融合API重写了关键子图，延迟才回到业务可接受范围。
这类问题不是“算力够不够”的问题，而是软件栈成熟度问题。峰值算力写在纸面上，线上P99却会被几个不起眼的基础算子拖住。
内存带宽不是写在参数表里就能用满
金融智能客服团队遇到的是另一类问题。
某股份制银行AI中台部署了约70亿参数的Llama 6客服问答模型，8卡910C，用vLLM做适配。首轮测试中，吞吐量只有理论峰值的40%。工程师李敏排查后认为，瓶颈主要在Attention阶段的内存访问。
他们观察到，910C的HBM2e带宽为1.6TB/s，但在这套模型和数据布局下，Attention计算中的带宽利用率不足50%。问题出在数据预取模式和NPU缓存行不匹配，算子能跑，但跑得不够顺。
后续团队换用了昇腾推荐的高带宽内存亲和算子，例如AscendFlashAttention，并在MindIE推理引擎里打开内存布局优化开关。吞吐量回升到理论值的75%。
这件事给他们的提醒是：百亿参数以上模型迁移时，不能只看卡数和显存，还要提前做内存访问模式测试。否则上线后看到的不是“算不动”，而是“算力闲着，数据喂不上”。
通信层短连接，会把在线P99吃掉
语音识别团队的问题更像线上服务常见故障。
一家智能语音创业公司把Whisper large-v3迁到910C，希望单次推理延迟低于500ms。实际生产环境里，平均延迟到了2.3秒，而且抖动明显。
他们一开始以为是模型计算慢，后来发现计算本身不是主因。多机推理时，HCCL通信初始化占了400ms以上。业务流程里，Whisper需要跨4台机器做语音片段拼接，每段推理前都会建立一次通信上下文，短连接把时间吃掉了。
团队后来改成AscendCL长连接池模式，提前做通信预热，并尽量把模型部署在同一台机器的4卡内，利用昇腾HCCS高速互联。调整后，延迟降到600ms以下。
这不是某个语音模型才有的问题。只要业务链路里有频繁的小请求、多机拆分、跨节点拼接，通信初始化就可能从“背景成本”变成主瓶颈。
调度器不看拓扑，KV cache就会绕远路
大模型API服务团队碰到的坑在调度层。
他们把DeepSeek V4-Flash部署到32卡910C集群上。经济观察网报道中提到，DeepSeek V4-Flash为2840亿参数、130亿激活；V4-Pro则为1.6万亿参数、490亿激活，上下文处理长度从上一代128K扩展至1M。
这家公司采用vLLM的prefill-decode分离策略。上线后，prefill阶段延迟基本正常，但decode阶段偶发长尾。排查后发现，部分decode请求被调度到了与prefill不同的节点上，KV cache需要跨节点传输，延迟被放大。
问题不在某一次请求，而在默认调度策略。资源够用，并不代表拓扑合适。昇腾集群默认调度器按资源请求分配，不会天然理解prefill和decode之间的亲和关系。
最后他们采用手动绑定GPU拓扑的办法，并使用Ascend Scheduler的亲和性调度策略，才把长尾压下来。
对大模型推理来说，调度不是运维边角料。KV cache在哪里、decode跑在哪里、跨节点链路怎么走，都会直接反映到用户看到的等待时间上。
NPU没慢，CPU预处理先拖了后腿
自动驾驶公司的案例更容易被忽视。
他们把一个BEVFormer变体感知模型部署到边缘侧910C推理卡上，预期推理延迟是20ms，实测为38ms。Profiling显示，NPU计算只占14ms，剩下时间主要花在CPU侧数据预处理，包括图像解码、归一化等环节。
也就是说，模型本身并没有慢到不可接受，慢的是模型前面的管线。
团队原本没有充分用上昇腾的DVPP硬件编解码模块，原因是旧版CANN DVPP驱动对自定义分辨率支持有限。后来他们把预处理切到AscendCV库的硬件加速版本，并把图像解码交给DVPP，整体延迟降到22ms。
他们给出的建议很朴素：凡是涉及非标准分辨率、边缘侧摄像头、多路视频输入的项目，迁移前先确认DVPP兼容性。不要等模型已经上卡，再发现CPU在前处理环节排队。
训练跑通之后，真正麻烦的是工程细节
这5个案例看下来，910C推理延迟常见问题大致可以归到几类。
第一类是CANN算子库。基础算子融合、自定义算子适配、关键子图替换，都会影响线上延迟。迁移时不能只验证模型输出是否一致，还要看算子发射次数、同步等待和子图执行时间。
第二类是内存访问。HBM2e带宽写在硬件参数里，但实际利用率取决于数据布局、Attention实现和访问模式。AscendFlashAttention、MindIE内存布局优化这类工具能解决一部分问题，但前提是团队愿意重新做Profiling。
第三类是通信。HCCL在短连接、多机、跨节点场景下可能放大尾延迟。长连接池、通信预热、机内多卡部署、拓扑亲和调度，往往比单纯加卡更有效。
第四类是模型外的链路。自动驾驶案例里，NPU计算只用了14ms，整体却到了38ms。图像解码、归一化、数据搬运这些步骤如果还停在CPU侧，最终用户看到的仍然是慢。
所以，910C迁移不是“模型能跑”就结束。训练侧的突破已经有公开案例：深圳团队完成DeepSeek V4-Pro全参数后训练，并被多家媒体报道为国产AI算力的重要进展。推理侧则更碎，问题藏在算子、内存、通信、调度和预处理里。
对正在做迁移的团队来说，比较稳妥的顺序是：先跑Profiling，确认时间到底花在哪；再看关键子图和算子融合；然后检查内存布局与Attention实现；最后处理通信拓扑和业务前后处理链路。
别急着把所有问题归因于硬件。很多时候，卡住延迟的不是910C本身，而是迁移后没有重新整理过的工程路径。
