阿里云与华为云AI合作：通义千问适配昇腾算力的技术解析

1. 为什么阿里云和华为云的AI合作值得关注

这两年我在做企业数字化转型相关项目，频繁听到同行讨论一个现象：阿里云和华为云这两家在国内云计算市场正面竞争最激烈的厂商，居然在AI领域有不少合作落地。乍一听有点反直觉，但仔细研究后会发现，这背后其实是国内AI产业生态走向成熟的一个信号。

先说清楚一个概念：阿里云和华为云在IaaS、PaaS层面的公有云市场竞争非常激烈，但在AI这条赛道上，两家各自的优势其实高度互补。阿里云强在AI平台和模型生态，通义千问系列大模型、百炼平台、魔搭社区这些大家应该都不陌生；华为云的核心优势则是昇腾算力硬件、Atlas系列产品，以及从芯片到框架的全栈自研能力。当一个项目既需要大规模GPU训练算力，又需要国产化、自主可控的推理底座时，两家厂商从竞争走向合作几乎是必然的。

我最早注意到这个趋势是在2023年下半年，当时有几个政府客户和大型央企在人工智能基础设施招标时，明确提出要求“训练侧用通义千问生态、推理侧用昇腾算力”。这种需求如果只靠单一云厂商，很难同时满足得漂亮，于是阿里云和华为云在项目层面的联合交付就越来越多了。

本文会围绕我实际接触过、以及在业内公开资料中验证过的几类合作案例展开，包括大模型底座与国产算力适配、企业级AI平台共建、开源生态协同，以及具体行业场景里的联合方案。同时会把每类合作背后的技术逻辑和经验教训一并讲清楚，方便准备做类似项目选型的朋友直接参考。

2. 合作案例全景：双方在AI领域到底怎么分工

2.1 大模型训练与国产算力适配：通义千问跑在昇腾上

这应该是目前公开度最高、也是我实际参与验证最多的一类合作。简单来说，就是阿里云的通义千问系列大模型，通过华为昇腾的AI框架和推理引擎完成适配，最终部署在华为云或者客户自建的昇腾算力集群上。

具体的技术路径是这样的：华为昇腾社区有一个专门的模型适配仓库（ModelZoo），里面维护了大量主流大模型在昇腾硬件上的迁移脚本和配置。阿里云这边则在魔搭社区同步发布经过调优的量化版本和推理部署包。两边配合下来，通义千问-7B、通义千问-14B这些开源模型可以比较顺畅地在昇腾310/910系列芯片上跑起来。

我在2024年初做过一个实际的测试项目，客户要求把一套基于通义千问-7B的智能客服系统从NVIDIA A10迁移到昇腾910B上。初期遇到的坑非常多，主要集中在这几个方面：

• 算子兼容性问题：PyTorch生态里很多GPU算子昇腾不支持，需要手动替换成昇腾的适配算子，尤其是FlashAttention这类高性能算子，当时昇腾上只能用官方提供的优化版本，效果略差但可用。
• 精度对齐：FP16和BF16混合精度训练在昇腾上有细微差异，导致loss曲线和GPU上有偏差。
• 推理延迟：昇腾最初对连续推理场景的优化一般，需要开启昇腾自带的动态分档功能才能把首Token延迟控制在可接受范围。

但到2024年第三季度之后，情况改善非常明显。昇腾的CANN版本更新了几个大版本，算子覆盖率提升很快，通义千问系列也做了针对性的算子融合优化。到2025年初，我测试的结果显示，在相同参数规模下，昇腾910B跑通义千问-7B的推理吞吐量已经能达到A10的八成左右，对于国产化要求高的客户来说完全够用。

这类合作的价值很清晰：阿里云不需要自己造芯片，就能满足客户对国产算力的硬性要求；华为云也不需要在模型层从零做起，直接拥有一批经过验证的成熟大模型生态。对甲方来说，采购流程和合规评审也顺畅很多。

2.2 企业级AI平台共建：阿里云百炼与华为云的联合交付

另一类我见得比较多的合作，是企业级AI应用平台的联合交付。这里的典型模式是：用阿里云的百炼大模型平台来做模型训练、微调、评测和应用编排，用华为云的ModelArts和AI Gallery来处理数据标注、算力调度和模型部署，两边通过API和数据集格式的互相兼容完成对接。

说个具体的例子。2024年下半年我参与了一个金融行业的智能文档处理项目，客户需要处理大量合同、尽调报告和财报，要做一个集文档解析、信息抽取、风险点识别于一体的AI应用。当时的需求很明确：

• 模型要私有化部署，数据不能出域。
• 训练用的数据在客户自己的机房，但推理服务想放到公有云弹性扩缩容。
• 合规要求部分算力必须国产化。

最终交付方案是：

1. 在客户内网机房使用华为Atlas 800训练服务器做通义千问-7B的领域微调，用ModelArts的数据标注能力清洗和标注了几万份脱敏文档。
2. 微调完成的模型权重迁移到阿里云百炼平台，在百炼上做评测、对齐和RAG流程搭建。
3. 推理服务部署在客户自己的昇腾推理集群上，通过阿里云提供的SDK接入业务系统。

这个方案最麻烦的地方在于两朵云之间的模型格式和部署环境差异。百炼平台默认输出的模型格式和昇腾的离线模型格式并不完全兼容，需要经过一层模型转换，我当时用了一台带昇腾驱动的中转服务器，跑通了整个转换流程，过程不算轻松但结果是稳定的。

这类合作现在越来越多，本质上是因为企业客户越来越不愿意把AI应用的开发、训练、部署完全绑定在某一家云厂商上。能够同时调用阿里云的大模型生态和华为云的算力底座，是很多甲方在招标文件里刻意写进去的诉求。

2.3 开源生态协同：通义千问、MindSpore与ModelScope的互通

如果说前面两类合作偏项目落地，那开源生态层面的协同就是更基础、更长远的一类。这一块普通用户感知不强，但实际对开发者生态的影响很大。

具体表现有几个方向：

• 魔搭社区（ModelScope）上专门开设了昇腾适配专区，用户可以直接在魔搭上筛选出支持昇腾硬件的模型，一键导出昇腾格式的部署包。
• 华为的MindSpore框架做了和ModelScope数据格式的兼容适配，部分模型可以直接从魔搭下载后导入MindSpore环境使用。
• 两个社区的SDK互相做了对接，比如魔搭的modelscope库可以直接调用昇腾的推理接口，不需要开发者自己写底层适配代码。
• 两边还在联合维护一批国产化AI工具链，包括模型量化工具、推理加速插件、容器镜像等。

我在实际开发中感受到一个很明显的变化：2023年想在昇腾上跑一个开源模型，得准备两天时间看文档、改代码、调环境；到了2025年，魔搭上很多热门模型都标注了昇腾适配状态，下载下来用官方镜像基本能开箱即用。这种变化对二线以下城市的开发者和中小企业尤其友好，因为他们不可能每个人都是昇腾专家。

从战略角度看，阿里云放开了自家模型生态对昇腾的支持，相当于扩充了通义千问在国产算力上的覆盖面；华为云则通过魔搭社区获得了一个活跃的开发者流量入口。这个逻辑和当年开源Linux生态崛起的路径非常像，底层的核心就是让开发者少重复造轮子。

2.4 行业场景联合方案：政务、制造、医疗的落地样本

最后一类合作是面向垂直行业的联合方案。我接触到的以政务、智能制造、医疗影像这三个方向居多，每个方向的技术侧重点都不一样。

先看政务方向。几个省级政务云的AI项目里，出现过这样的组合：阿里云提供政务大模型底座（基于通义千问政务版），负责智能问答、政策解读、公文写作辅助这些上层应用；华为云负责底层的政务云国产化环境和昇腾算力资源池，确保满足等保合规和自主可控的要求。这种模式下，重庆、四川等地的一些智慧政务项目已经在用类似的组合方式。

制造方向则更偏工业质检和知识库。我2024年底调研过一个汽车零部件工厂，他们的AI质检系统就是“阿里云视觉模型+华为昇腾边缘推理盒子”的架构，训练在阿里云上用GPU完成，推理部署在产线边缘的昇腾设备上，两端通过标准API通信。这样做的好处很明显：训练端灵活、成本可控，推理端靠国产设备就近部署，延迟低、数据安全。

医疗影像方向稍微特殊一点，因为涉及数据合规，公有云用得少，更多是混合云形态。医院内网部署华为昇腾服务器跑医学影像分割和辅助诊断模型（模型本身基于阿里云开放平台的医学影像预训练模型做微调），影像数据不出院，训练和模型更新则通过定期同步方式完成。

这几个行业案例共同验证了一个趋势：未来的AI应用交付越来越像“乐高积木”，模型、算力、平台、行业知识四个模块可以自由组合，而不再要求客户必须在一家云厂商的生态里从一而终。

3. 合作背后的技术逻辑与选择策略

3.1 为什么双方需要互相适配：从芯片到模型的分层解耦

要理解阿里云和华为云合作的必要性，得先看清楚AI技术栈的分层结构。从下到上大致是：

• 芯片层：GPU/ASIC/NPU等AI计算芯片。
• 框架层：PyTorch、TensorFlow、MindSpore、PaddlePaddle等深度学习框架。
• 模型层：基础大模型、垂直领域模型。
• 应用层：AI应用、智能体、行业解决方案。

在理想情况下，这四层应该自由组合，但现实是每一层都有绑定关系。比如NVIDIA的GPU和CUDA生态深度绑定，PyTorch在CUDA上性能最好，大部分模型默认针对CUDA优化，这就形成了“应用→模型→框架→芯片”的一条龙锁定。

华为昇腾想打破这种锁定，就必须解决两个问题：一是让PyTorch生态的模型能跑在昇腾上（算子适配），二是让头部大模型的权重能在昇腾上高效执行（模型适配）。而阿里云作为国内模型生态最丰富的厂商之一，恰好手里握着通义千问系列这个重量级筹码。

两家合作本质上是在做“分层解耦”：华为云提供芯片和框架层的国产替代能力，阿里云提供模型和应用层的丰富生态，双方通过适配层打通，让用户能按需选配，而不是被迫站队。

3.2 技术选型决策：什么场景选合作方案，什么场景选单一厂商

根据我这一两年的项目经验，可以给一个相对实用的选型参考：

技术选型不要追求单一正确答案，关键看约束条件。合规要求是红线，成本预算是底线，团队技术栈是上限，三者交集之外再考虑生态和性能。

3.3 迁移适配的代价：真实项目里的隐性成本

很多人只看到合作方案的好处，却没估算迁移适配的隐性成本。这部分我踩过坑，说点实在的。

• 模型转换耗人力：从PyTorch权重转到昇腾离线模型，不是一条命令就能完成的，涉及算子映射、精度对齐、调优，通常需要2-4周人力投入。
• 推理性能需要反复调：同样的模型在GPU和昇腾上的最优推理配置不一样，batch_size、动态分档、内存分配策略都要重新测试。
• 多框架混合增加运维复杂度：一个系统里既有Kubernetes调度阿里云的GPU节点，又要维护昇腾的驱动和CANN环境，对团队运维能力要求高了一个台阶。
• 开源社区的支持力度：很多最新的模型优化技术（如量化、投机采样）默认先支持CUDA，昇腾的支持往往滞后一个版本周期。

所以我的建议是：如果项目规模小、周期短、没有硬性国产化要求，没必要硬凑合作方案；如果项目体量大、周期长、未来有持续迭代需求，那前期多花一个月做适配很值得，后期的收益会越来越大。

4. 实操过程：如何搭建一个“通义千问+昇腾”的最小可用环境

4.1 环境准备与版本选择

为了帮助想亲自验证的朋友少走弯路，我整理一套本人实测可用的最小环境配置方案。这套方案适合个人开发机和测试环境，生产环境在此基础上增加稳定性配置即可。

硬件方面，如果没有昇腾实体硬件，可以用华为云的ECS推理加速型实例（搭载昇腾310或910芯片）代替，按量付费跑完测试即可释放，成本可控。

软件环境建议版本如下：

• 操作系统：Ubuntu 22.04 LTS（昇腾官方对20.04和22.04支持最好）
• CANN版本：8.0.RC1及以上（算子覆盖率更高，对通义千问支持更好）
• MindSpore版本：2.3以上（如需使用MindSpore做框架层适配）
• Python版本：3.10（通义千问生态和昇腾工具链都适配良好）
• PyTorch：2.1.0 + torch_npu插件（昇腾适配版）

这里要特别强调一点：昇腾的软件栈版本之间强耦合，CANN、驱动、固件、PyTorch适配插件必须严格匹配，版本不一致大概率出现算子加载失败或者显存报错，这是所有昇腾入门者最容易踩的坑。

4.2 从魔搭下载通义千问模型并在昇腾上推理

下面是一个最简可运行的推理代码示例，展示了从魔搭下载通义千问-1.8B模型，再到昇腾NPU上执行推理的完整流程。

python复制# 安装依赖（建议在昇腾容器镜像内执行）
# pip install modelscope transformers torch_npu

import torch
import torch_npu
from modelscope import AutoModelForCausalLM, AutoTokenizer

# 使用NPU设备
device = "npu:0"

# 从魔搭下载通义千问-1.8B模型
model_name = "qwen/Qwen-1_8B-Chat"
tokenizer = AutoTokenizer.from_pretrained(model_name, trust_remote_code=True)
model = AutoModelForCausalLM.from_pretrained(
    model_name, 
    torch_dtype=torch.float16,
    trust_remote_code=True
).to(device)

# 构造对话
prompt = "你好，请简单介绍下你自己"
messages = "system: 你是一个有用的AI助手。\nuser: " + prompt + "\nassistant: "
inputs = tokenizer(messages, return_tensors="pt").to(device)

# 推理生成
with torch.no_grad():
    outputs = model.generate(
        **inputs,
        max_new_tokens=128,
        do_sample=True,
        temperature=0.7,
        top_p=0.9
    )

# 输出结果
response = tokenizer.decode(outputs[0][inputs["input_ids"].shape[1]:], skip_special_tokens=True)
print(response)

这段代码看起来简单，但背后有个大坑：模型必须使用昇腾适配版的PyTorch才能正确调度NPU。如果直接用官方PyTorch，即使to("npu:0")不报错，算力也不会真正落到NPU上，而是可能直接报设备不识别。所以务必先安装torch_npu插件，并且在import顺序上让torch_npu在model加载之前完成初始化。

另外，小模型（1.8B）在昇腾310上的推理性能和预期会有差异，310的算力定位是边缘推理，跑1.8B模型偏吃力。我个人建议测试时优先用昇腾910系列，虽然贵一些，但体验顺畅很多，测试结果也更接近生产环境。

4.3 用MindSpore做模型迁移的另一种路径

如果不想走PyTorch+torch_npu路线，还可以直接使用MindSpore框架加载通义千问模型。华为昇腾社区对MindSpore框架的原生支持度更高，运行稳定性更好，但MindSpore生态里模型的丰富程度不如PyTorch。

bash复制# 使用MindFormers套件加载通义千问模型（昇腾原生方案）
pip install mindformers

# 下载模型权重和配置（以qwen-1.8b为例）
mkdir -p /opt/qwen-1.8b
cd /opt/qwen-1.8b
wget https://modelscope.cn/models/qwen/Qwen-1_8B-Chat/resolve/master/config.json
wget https://modelscope.cn/models/qwen/Qwen-1_8B-Chat/resolve/master/model.safetensors
wget https://modelscope.cn/models/qwen/Qwen-1_8B-Chat/resolve/master/tokenizer.json

# 使用MindFormers的推理脚本
python run_qwen.py \
  --model_name qwen-1.8b \
  --checkpoint_path /opt/qwen-1.8b \
  --device_target Ascend \
  --device_id 0 \
  --predict_length 128

MindSpore路线的优势是规避了PyTorch和昇腾的适配层问题，性能和稳定性都有保障；劣势是生态相对封闭，遇到问题在公开社区找到的参考案例少很多。如果团队里有人精通PyTorch，我建议优先走PyTorch路线，调试工具链更成熟。

4.4 容器化部署：让环境一次搭建、处处运行

为了避免每次换机器都要重新折腾环境，容器化是必选项。昇腾官方提供了带CANN和MindSpore的Docker镜像，可以直接基于它二次封装。

dockerfile复制# 基于昇腾官方镜像构建
FROM ascendai/cann:8.0-910b-ubuntu22.04-py3.10

RUN apt-get update && apt-get install -y python3-pip git

# 安装Python依赖
RUN pip install modelscope transformers torch torch_npu

# 将模型下载脚本复制进镜像
COPY download_model.py /opt/download_model.py
RUN python /opt/download_model.py

# 启动推理服务
COPY server.py /opt/server.py
CMD ["python", "/opt/server.py"]

容器化部署最需要留意的是设备映射，运行容器时一定要挂载昇腾设备，否则容器内看不到NPU：

bash复制docker run -it --rm \
  --device=/dev/davinci0 \
  --device=/dev/davinci_manager \
  --device=/dev/hisi_hdc \
  -v /usr/local/Ascend/driver:/usr/local/Ascend/driver \
  -v /usr/local/dcmi:/usr/local/dcmi \
  -v /usr/local/bin/npu-smi:/usr/local/bin/npu-smi \
  my-qwen-ascend:latest

设备挂载缺失是容器化部署里最常见的报错原因，报错信息通常不直观，只是提示类似NPU device not found或者HIAI_PROCESS相关错误，新手很容易被误导去排查驱动问题，但实际上只是容器没挂设备。

5. 常见问题与避坑指南

5.1 模型适配过程中的典型报错与解法

以下是本人和团队在真实项目中遇到过的高频问题，整理成速查表供参考：

做昇腾适配时，排查算子类问题最高效的方式是先用npu-smi info确认设备状态，再通过CANN自带的msprof工具跑一遍性能剖析，基本能定位到具体算子的性能瓶颈。

5.2 性能不达预期时的优化手段

实测一个通义千问-7B模型在昇腾910B上推理，如果只是简单用默认参数跑，吞吐量大概只有优化后的一半左右。以下几个优化手段几乎每次都有效：

• 开启动态分档（Dynamic Shape）：将输入长度固定到几个常用档位，减少内存重分配开销。
• 使用昇腾图模式（Graph Mode）：把PyTorch模型转换成静态图执行，减少Python解释开销。
• 开启连续批处理（Continuous Batching）：多路请求打散执行，显著提高吞吐量。
• 模型量化（INT8/INT4）：昇腾对INT8的算子支持度很好，吞吐量提升明显，精度损失在可接受范围。

这里额外提醒一句：昇腾的性能优化参数非常多，不同型号芯片、不同CANN版本之间存在差异，最好的做法是先按官方性能调优手册把基础项设置一遍，再基于业务请求特征二次微调，不要盲目照搬网上的参数组合。

5.3 两套生态并用时的团队技能要求

最后聊一个组织层面的问题。兼容方案做起来不难，但要用好需要团队同时具备两个生态的基本能力。我的建议是：

• 算法团队至少要熟悉PyTorch的模型导出和调试流程。
• 运维团队要掌握昇腾驱动的安装、CANN环境变量配置、NPU监控方法。
• 团队里最好有一个人专门负责昇腾算子适配和性能调优，这个角色前期投入大但后期价值极高。
• 不要低估文档的重要性，昇腾和魔搭两边的官方文档都在快速迭代，建议每季度梳理一次版本变更，避免线上环境和新版本工具链之间出现兼容性断裂。

如果团队预算允许，可以参加华为云和阿里云分别举办的开发者训练营，两家都有面向生态伙伴的免费课程和实验环境，比自己摸索省力得多。

6. 关于未来：合作会继续加深还是变成又一次生态卡位

从我个人的从业判断来看，阿里云和华为云在AI领域的合作长期会保持“有限深度合作”的态势。双方会在模型适配、开源社区互通、行业联合方案这些能让彼此生态扩大的方向上继续推进，但在核心平台层面（比如云市场、开发者工具链、企业级AI平台）依然会保持竞争关系。

这种竞合关系对甲方和开发者来说其实是好事。竞争确保了技术演进的活力，合作减少了绑定风险和使用门槛。对真正想落地AI项目的团队来说，与其纠结选阿里云还是华为云，不如把两边的能力都纳入自己的技术评估范围，按项目需求灵活组队。

我自己后续也会持续关注几个方向：一是通义千问系列更大参数版本在昇腾上的性能表现，二是华为昇腾新一代芯片对多模态模型的支持度，三是两家在AI Agent领域的联合方案会不会出现新的样板案例。这些一旦有新的实测结果，我会再写文章和大家分享。

最后分享一个很实在的个人体会：技术选型的时候少听厂商宣讲，多自己动手跑几个基准测试。我见过太多项目死在“PPT上很美好、实际部署很骨感”的环节里。拿通义千问和昇腾这套组合来说，只要环境配好、版本对齐、算子调顺，实际表现完全撑得起国产化AI应用的落地需求。真正需要花时间的，恰恰是那些看起来不起眼的适配细节。