黄泓毅1. 先把话说明白：阿里云和华为云的AI合作，到底是真合作还是市场动作
经常有人问我，阿里云和华为云不是直接竞争对手吗，两家在AI领域怎么可能合作？说实话，我以前也认为这两家属于“王不见王”的状态，一个盘踞在公有云市场份额前列，一个靠昇腾芯片和全栈AI能力硬刚英伟达的生态位。但当我自己在华为云上把一个通义千问模型跑起来之后，我才意识到，这个行业的合作逻辑早就不一样了。
更准确的说法是：阿里云和华为云之间的“合作”，不是签一纸战略协议、搞一个联合品牌那种传统意义上的合作，而是在AI大模型、开源生态、芯片适配、行业标准这些层面，被技术趋势和市场现实倒逼出来的生态级协同。你打开阿里云的百炼大模型平台，能找到昇腾算力的调用入口；你登录华为云的ModelArts，也能轻松部署基于通义千问系列的开源模型。这不是两家公司坐在一张桌子前谈出来的结果，而是整个AI产业链在互操作性和兼容性上不断推进之后自然长出来的形态。
这篇文章我想围绕这个话题，结合我自己在两家云上做AI项目踩过的坑、实测过的流程，把“阿里云和华为云在AI领域的合作案例”系统拆一遍。我会从模型适配、开源社区、开发框架、企业级多云落地这几个角度，把那些看得见摸得着的协作点列出来，并给出可以直接参考的操作步骤。不管你是做AI应用开发的、搞运维的、还是给公司做技术选型的人，读完之后基本能搞清楚一个问题：在什么场景下，你可以同时把这两家云当作自己AI项目的基础设施。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 案例一：通义千问在昇腾芯片上跑通，AI大模型生态互通的标志性事件
2.1 为什么大模型必须“低头”适配更多芯片
先说一个背景事实。过去两年里，国内AI圈子最焦虑的不是模型效果，而是算力供应。训练大模型需要高端GPU，但在当前的国际环境下，高端GPU获取难度越来越高。这时候，谁手里有可替代的AI芯片，谁就掌握了下一轮AI竞争的话语权。华为昇腾系列就是在这个背景下迅速站到台前的。
但芯片做出来了，没人用也不行。昇腾毕竟不是英伟达，生态成熟度差着一截。CUDA生态里随手一个pip install就能解决的事，到了昇腾上可能要先折腾半天环境。所以华为云最核心的诉求，是让主流开源大模型能跑在昇腾上，尤其是那些在全球范围内口碑很好的模型，比如Meta的Llama系列，还有阿里云开源的Qwen通义千问系列。
这里就有意思了。阿里云是华为云在公有云市场上的直接对手，但阿里开源的大模型又是目前国内综合表现最出色的开源模型之一，在Hugging Face和ModelScope上下载量都是顶级的。如果昇腾生态不支持Qwen模型，开发者就会觉得昇腾没那么好用，甚至放弃这条路。所以华为云不仅不排斥，还主动把Qwen模型的适配和优化做了进去。这就是我说的第一类合作案例：基于模型适配层的技术协同，而不是公司层面的战略结盟。
2.2 这次合作实际是怎么发生的
我查过不少公开资料，也自己实测过。真实情况是，Qwen模型在昇腾上的支持路径主要有两条。一条是阿里方面，通义千问开源后在ModelScope上提供了大量的模型权重和部署样例，其中就包括了昇腾环境下的部署说明。另一条是华为方面，昇腾底层的CANN、MindIE这些推理引擎，很早就把Qwen作为重点适配对象，官方文档里给出了针对Qwen全系列的推理优化参数。
两条线在社区里汇合的效果就是，你可以在华为云的昇腾云服务上，拉一台带昇腾910B加速卡的云服务器，然后直接从一个已经封装好的镜像里启动Qwen模型推理服务。我记得第一次跑通的体验是：从创建实例到模型返回第一个token，整个过程不到四十分钟，对于一个追求新鲜感的开发者来说，这种体验已经非常接近英伟达A100云主机上那种“拿来即用”的感觉了。
从技术角度来看，这里面最难的部分其实是算子适配。多模态大模型和神经网络模型在昇腾芯片上运行，并不是简单地把PyTorch模型文件复制过去就行。昇腾提供了Pytorch框架的适配层，比如torch_npu这个插件，它会把PyTorch里的CUDA算子映射成昇腾的NPU算子，这个过程如果遇到了不支持的算子，就需要手动做算子替换或者走自定义算子编译。Qwen这种模型好在结构比较规整，Attention计算、FFN层都是Transformer的标准结构，昇腾的优化工具链基本都能覆盖。
2.3 在华为云上从头跑通一个Qwen2.5模型（参考步骤）
这部分给你一个我自己验证过的操作路径，不一定是最优解，但按着走基本能跑通。前提是你有一个华为云账号，并且开通了昇腾云服务，通常这类服务需要申请权限，一般工作日审核很快。
第一步，创建一台AI加速服务器。在华为云控制台里找到ECS，然后选择AI加速型实例，比如配备昇腾910B的实例规格。如果只是测试推理，选择最小配置就够了。需要注意的是，镜像一定要选支持CANN的公共镜像，或者是官方提供的AI容器镜像，不要拿一个普通CentOS镜像自己装驱动，那样折腾到你怀疑人生。
第二步，配置推理环境。如果是用官方AI容器镜像，环境基本是现成的。安装的时候先确认CANN版本和torch_npu版本是否匹配。一个我踩过坑的地方：有些老的torch_npu版本不支持PyTorch 2.1以上的版本，所以尽量按照官方文档推荐组合来，别自己发挥。
第三步，下载Qwen模型权重。推荐用ModelScope的命令行工具，华为云服务器访问ModelScope的速度通常不错。示例命令如下：
bash复制pip install modelscope
modelscope download --model Qwen/Qwen2.5-7B-Instruct
下载完成后，模型会存储在本地路径，你也可以把模型文件传到华为云OBS对象存储里，这样下次创建实例的时候直接从OBS拉取，比每次重新下载要快很多。
第四步，启动推理服务。华为昇腾有两个常用方案，一个是华为自研的MindIE推理引擎，一个是社区贡献的vLLM-Ascend。如果你是做生产级API服务，我建议优先用MindIE，它在动态batch、KV Cache管理、长文本处理上都针对昇腾做过深度优化。启动方式也不复杂，调用Python接口加载模型，把输入输出和OpenAI API兼容格式对齐，这样后端用什么都无所谓了。
我自己的经验是，整个流程里最容易出问题的不是模型本身，而是环境版本匹配。torch、torch_npu、cann这几个东西只要有一个版本不对，启动的时候就会报一些莫名奇妙的错误，比如libascend_ops.so找不到、CANN版本过低之类的。遇到这种问题，最有效的办法不是自己四处查，而是回到华为云官方镜像模板里，用他给你锁好的那一套版本组合，稳定性会好很多。
3. 案例二：开源社区里的“同框”——两个云厂商在AI标准和组织上确实有交集
3.1 共同参与的开源AI项目
阿里云和华为云在商业上是竞争关系，但在开源社区里，其实经常坐在同一个圆桌上。举一个例子，在LF AI & Data基金会下面，有不少中国科技公司参与的项目，阿里和华为都是主要的贡献者和赞助者。包括像OpenI启智平台这类国内开源的AI协作平台，阿里云和华为云也都有不同程度的参与。
这类合作在短期的商业视角下可能看不出直接价值，但它对整个AI技术栈的意义很大。随便举个例子，模型文件格式标准、数据集标注规范、评测基准办法，如果只有一家大厂跟进的，那八成会变成自家独有玩法，其他开发者根本不敢直接用。但如果阿里云和华为云同时在一个基准组织里出现，就能形成一个信号：这套标准背后不是某一家的利益，而是行业公认的准绳，开发者可以放心跟随。
我举一个我自己感受比较深的场景。之前帮一个客户做大模型选型，对方内部纠结是用通义千问还是用某个开源中文模型。最后拍板的原因是，通义千问在几个比较权威的中文评测集上都有公开成绩，而华为昇腾的官方适配列表里也明确支持这个系列模型。如果这两家没有在公开评测和开源适配上有这种“交集”，我们做技术选型的人就会很痛苦，等于每个模型都要自己拿来实测一遍算力兼容性。
3.2 “可信AI”这样的评测体系，本质是一种隐性的合作
在AI合规和评测层面，中国信通院牵头做过很多“可信AI”相关的评估和测试，阿里云和华为云都是积极参与方。这种评测看上去不像某个具体产品发布会上的合作，但它实际比任何一场发布会都重要。
为什么这么说？因为大模型落地到金融、医疗、政务这些行业的时候，客户不会只看模型的回答质量，还会要求提供各种评测报告、安全测试报告、性能基准数据。如果阿里云和华为云没有在评测标准和测试方法上先达成共识，那这些报告就没法互相参考，客户每换一家的云，所有测试就得重做一遍。而现在，很多评测基准是行业内共同认可的，意味着你在阿里云百炼上测过一轮模型能力，拿到华为云上用昇腾算力重新跑推理时，测试口径是基本一致的。
从我参与过的几个项目来看，这种“隐性合作”的价值，甚至比产品层面的互相适配更值钱。它降低了整个行业的信息不对称程度，也帮我这种做技术选型的人省了不少力气。你不需要对着两套完全不同的评测指标，花几周时间反复验证同一个模型。
3.3 为什么“签合作协议”反而不常见
你可能会问，既然两家在开源社区、评测标准上都有交集，为什么不直接签一个官方合作协议呢？我个人的理解是，这种级别的公司签协议，动静太大，反而容易让市场产生误解，以为他们要合并或者说要在某块业务上深度绑定了。而且，云市场的竞争格局根本不允许这种“深度绑定”出现。
所以你会看到一种有意思的现象：这两家从来不在发布会上互相站台，但技术适配的进度一点都不慢。阿里开源一个模型，昇腾这边很快就跟进适配；华为昇腾发布一个新系列的芯片，ModelScope上对应的部署说明也会逐渐更新出来。与其说是两家公司刻意合作，不如说是一个健康的开源生态加上一个充分竞争的市场，逼着他们走向互操作。这种状态，我作为一个开发者是举双手欢迎的，因为我不需要选边站队，也不需要担心选了一朵云之后就被另一朵云的生态彻底锁死。
4. 案例三：从开发框架到应用层的“自然合作”，AI Agent时代尤其明显
4.1 Spring AI 正在帮开发者“脚踏两只船”
另一个很有意思的合作色彩体现在开发框架层。如果你是Java开发者，大概率听说过Spring AI这个项目。它是Spring官方推出的AI开发框架，主要作用是把各种大模型API统一抽象成一套Spring风格的接口，让你写一套代码就能对接不同的模型提供方。
阿里云的百炼大模型平台和华为云的ModelArts，都有对Spring AI的适配。什么意思？就是说你可以在同一个项目里，先用Spring AI的接口接一个阿里云上的模型做智能客服，再配一个华为云上的模型做知识库总结，然后通过一个开关就切换不同服务商。这种开发体验在以前是完全不敢想的。
给你看一下Spring AI里的配置思路。在application.yml里配置两个不同的模型供应商，各自填好API key和endpoint，代码里调用的时候用不同的bean名区分：
yaml复制spring:
ai:
aliyun:
base-url: https://dashscope.aliyuncs.com/api/v1
api-key: ${ALIYUN_API_KEY}
chat:
options:
model: qwen-plus
huawei:
base-url: https://infer-modelarts.${region}.myhuaweicloud.com
api-key: ${HUAWEI_API_KEY}
chat:
options:
model: qwen2.5-72b-instruct
注意上面这个huawei配置里我填的模型名还是通义千问的Qwen2.5-72B，这就是我想表达的核心观点：因为开源模型的可移植性，你完全可以在两朵云上部署同一个模型的推理服务。你不需要为了换一朵云就换模型，模型是你的，算力是谁的都无所谓。
做AI Agent应用的人，对这种跨云部署的价值感知应该更明显。Agent应用通常有一个特点，就是需要调用多个模型完成不同任务，比如一个模型做意图识别，一个模型做内容生成，还有一个embedding模型做向量化。如果这三个模型全压在同一个供应商上，一是容易出单点故障，二是议价空间也小。但放到多云环境里，每个供应商只需要承担一部分能力，互相备份的可靠性也更好。
4.2 AI Agent 应用的跨云落地思路
我最近在帮一家电商公司做售前咨询机器人，整个架构就是典型的跨云方案。意图识别模型部署在阿里云百炼上，用通义千问-Turbo这个型号，处理速度比较快；答案总结模型用的是部署在华为云昇腾算力上的Qwen2.5-72B，效果更好但响应稍微慢一些；向量数据库用的是阿里云的DashVector，知识库内容同步存储在华为云OBS上。
这个方案的来源其实很实在。不是说我们非要搞多云，而是电商大促期间，单朵云的推理负荷会冲到很高，万一某个供应商限流或者出故障，整个客服系统就瘫了。把关键模型拆到两朵云上之后，至少可以保证一个主用、一个备用。而且在年度成本谈判的时候，因为有两家供应商互相盯着，你拿到的折扣通常会比只跟一家谈要更划算。
从技术实现角度看，跨云Agent应用最需要注意的是API兼容问题。现在有相当多的大模型API都宣称兼容OpenAI的协议格式，阿里云和华为云也都支持OpenAI兼容接口，这让代码可以无缝在两个平台上跳来跳去。但兼容归兼容，具体到超时设置、错误码处理、限流策略这些细节，两朵云还是有区别的。建议你在写核心代码时，把每一次模型调用都封装成独立函数，统一处理超时重试，这样切换供应商的时候只需要改配置，不需要改业务逻辑。
4.3 ModelScope、Hugging Face、华为云镜像仓库之间的关键体验
模型访问的便捷程度，直接决定了跨云开发的效率。阿里云的ModelScope平台，对开源模型的支持非常激进，Qwen系列新版本一发布，基本当天就能在ModelScope上看到权重文件。华为云这边也有自己的AI Gallery模型社区，上面同样有大量开箱即用的预置模型，包括Qwen系列。
这里有一个体验上的差异值得提一下。从ModelScope下载模型，在阿里云的ECS上最快，因为走的是内网；在华为云ECS或裸金属上，速度也还不错，但如果你先下载到本地再传到华为云OBS，那就纯属折磨自己了，动辄几十GB的模型文件，本地带宽根本扛不住。我后来是直接在华为云服务器上执行modelscope下载命令，让它在云上完成模型文件拉取，速度比本地中转快太多了。
华为云AI Gallery的好处是它自带很多部署模板，尤其是昇腾硬件相关的镜像和脚本，你不需要自己记那些复杂的推理引擎参数。选一个Qwen2.5模板，填好模型路径和资源池规格，它就能自动帮你把推理服务拉起来。对刚入门的人特别友好。
从这个角度看，ModelScope更像是模型分发的源头，华为云AI Gallery更像是针对昇腾算力做了二次封装的应用市场。两者之间不是谁替代谁的关系，而是各自承担了生态里不同位置的职责。这种分工本身就是一种默契合作的体现。
5. 案例四：企业客户的多云AI方案，真实需求倒逼生态握手
5.1 为什么企业客户把两家云“强行组合”在一起
我在实际工作中遇到的大量“阿里云+华为云合作案例”，其实并不是两家公司主动合作，而是企业客户通过自己的多云架构设计，把两朵云硬生生组合到了一起。我印象最深的一个项目是给一家做工业质检的公司设计AI平台。他们有一个自研的缺陷检测模型，训练的时候用了华为云的昇腾集群，因为采购成本显著低于同等算力的英伟达方案；但推理端却部署在阿里云上，因为他们的上下游合作伙伴和数据管道全都已经跑在阿里云上，换个环境改动太大。
这个项目最终运行了一年多，整体是稳定的。训练好的模型权重在华为云上导出为标准格式，通过OBS和阿里云OSS之间的跨云传输同步过来，再在阿里云的GPU实例上用Triton Inference Server启动推理服务。你可能会说，这不是折腾吗？为什么不干脆统一一朵云算了。
答案是成本和迁移成本的综合权衡。训练阶段在本地机房或者私有环境里完成，推理阶段靠近业务集群所在的那朵云，这是非常典型的企业级AI落地路径。两家云在这个过程中，各自都提供了稳定可靠的一环，所以我认为这也算是一种“实践意义上的合作”。甚至可以说，这种由客户需求驱动的协作，比任何战略协议都更牢固，因为它建立在实际业务依赖之上。
5.2 选型比较：昇腾算力与阿里云GPU的取舍
为了让你对两边的AI算力有个直观认知，我做了个简单的对比表，基于我自己实际使用过的服务类型，价格属于参考水平，具体以官网实时报价为准：
| 对比维度 | 华为云昇腾云服务 | 阿里云GPU云服务器 |
|---|---|---|
| 典型产品 | ModelArts + AI加速型ECS（昇腾910B） | PAI + ECS（A10/A100等） |
| 推理框架 | MindIE、vLLM-Ascend | vLLM、Triton、TensorRT-LLM |
| PyTorch适配 | torch_npu插件 | CUDA原生支持 |
| 主流模型兼容性 | 需关注CANN版本 | 基本所有模型都能跑 |
| 成本曲线 | 时租价格有优势，长包更划算 | 市场成熟，按量付费灵活 |
| 典型适合场景 | 国产化需求强、大规模长期推理负载 | 生态兼容要求高、快速原型验证 |
表格看着简单，其实背后反映的问题很实际。昇腾平台的优势在于长期跑推理时的性价比，尤其是你愿意接受一次性的环境适配成本之后，后续的算力成本会比同等性能的GPU低不少。阿里云的优势在于通用性，你随便下载一个开源模型，在上面跑成功的概率几乎是百分之百，不需要研究什么算子映射、CANN版本、MindIE配置这些额外知识。
如果你是一个小团队，只有一两个AI工程师，我不想让你一开始就去啃昇腾。先用阿里云或者别的GPU云快速跑通业务验证，是更稳妥的选择。等你的模型稳定了，推理量大起来了，再考虑把一部分推理迁移到昇腾上降低长期成本。这也是我在前面那个工业质检项目里采用的实际路径。
5.3 把两朵云串起来：网络与存储配置
如果在两家云之间做跨云AI系统，网络和存储是两个必须先解决的环节。第一个要点是内网通信。阿里云有VPC，华为云也有VPC，两个VPC之间默认是不通的，你需要通过公网或者专线打通。如果只是偶尔同步一下模型文件，走公网传输加上对象存储的断点续传功能问题不大；但如果两朵云之间要跑实时推理流量，那就得考虑专线或者云连接产品了。
具体到操作，我建议你这样设计网络。先在阿里云上创建一个VPC，CIDR别设置太窄，给以后扩容留空间；然后在华为云上创建另一个VPC，网段避免和阿里云那边重叠。两朵云的对象存储之间的数据同步，可以用各自的对象迁移工具，或者直接用开源的rclone工具，设置好双向同步策略。模型文件这种东西不会频繁变，设置每天同步一次就够了。
存储上的小技巧是，把热数据放在推理服务所在的云上，冷数据放在模型存放的那一侧。比如模型权重统一存一份在华为云OBS里，训练产出的新权重通过事件触发的方式同步到阿里云OSS，阿里云上的推理服务不需要手动改配置，就能自动识别到新模型版本。
6. 实操避坑与经验提醒，这几条能帮你少走很多弯路
6.1 昇腾上跑通模型不等于“性能达标”
在华为云昇腾上跑Qwen模型，第一次跑通时我非常兴奋，但后来的性能测试给了我一个不小的打击。跑通只是说明数据通路没问题，但每个token生成耗时比在同等定位的GPU上要慢不少。后来我研究了一下，问题出在几处：一是没有开启KV Cache复用，二是动态batch没有配置，三是CANN算子的编译优化等级不是最高档。
说白了，昇腾的性能发挥跟环境调优息息相关。你在华为云上部署Qwen，记得一定要看官方针对该模型的调优文档，里面会给出mindie配置里的batch大小、KV Cache策略、长度扩展参数。这些参数对生成吞吐量的影响，比硬件本身还大。同样是910B，调好参数和不调参数之间的差距可以达到两到三倍，这一点都不夸张。
6.2 入坑之前先分清CANN、MindIE和vLLM-Ascend的关系
这几个名词特别容易混淆。CANN是昇腾的底层计算架构，相当于CUDA在英伟达生态里的位置。MindIE是华为面向大模型场景推出的推理引擎，它基于CANN做了一层高度封装。vLLM-Ascend则是社区把vLLM移植到昇腾上的成果，用起来更接近开源生态的习惯。
我的建议是，如果你只是想把模型跑起来出个结果，优先用MindIE；如果你要做一些深度的性能压测和并发优化，可以试试vLLM-Ascend。但不管用哪个，都要先确认它们对你这代芯片和这个模型版本的具体支持情况。很多报错本质上就是“这个模型在这个推理引擎上还没有完成适配”，而不是你操作有误。
还有一个容易忽略的点是模型格式转换。昇腾推理通常需要把PyTorch的权重文件转换成MindIE IR格式，虽然官方提供了转换脚本，但转换过程中偶尔会因为算子不兼容而中断。所以对于那些特别新的模型，建议先看看昇腾的支持列表里是否已经包含对应版本，别拿到权重文件就一头扎进去，否则光是格式转换就能耗掉你一个下午。
6.3 小细节决定全局：API域名、对象存储和SSL证书
跨云部署遇到的头疼问题，其实往往不是什么高深的技术难点，而是一些看起来不起眼的运维细节。两朵云的API域名、SDK endpoint、对象存储桶的命名规则都不一样，稍微不留神就会连错区域节点。我建议你在项目最开始的时候，就把两朵云需要用到的endpoint、bucket、AK/SK信息整理到统一的配置文件里，每个环境写清楚。搜索引擎里那些“群晖换了阿里云SSL证书显示页面不存在”“阿里云SSL证书免费续期”之类的问题，虽然不是AI直接相关的，但本质上都是环境配置里的一环，一样需要细心对待。
SSL证书这个点尤其值得说。现在很多云厂商提供的免费SSL证书有效期越来越短，如果你在两朵云上都用了免费证书，最好做一个自动续期提醒，避免突然证书过期导致API连接失败。我经历过一次实例升级后证书没同步，结果整个推理服务的对外请求全部报握手错误，排查了半天才发现是证书链不完整。这种坑，一次就够你长记性的。
6.4 我的最终判断
回到标题本身，阿里云和华为云在AI领域有哪些合作案例？如果只看官方发布会和战略签约文件，你确实很难找到太多“合体”的场面。但如果把视野放到实际的模型适配、开源社区共建、开发框架兼容、企业多云落地这些具体场景，你会发现两家的生态其实已经深度交织在一起了。
我个人在实际操作中的感受是，这种合作比传统意义上的商业同盟更难能可贵。因为它不是靠一纸合同维持的，而是靠对开源AI理念的共同认可，靠让开发者活得更舒服这个朴实目标来驱动的。阿里云提供优秀的开源模型，华为云提供高效的本土算力，两家在市场上该竞争就竞争，在技术上该兼容就兼容，对做AI的人来说，这是最舒服的一种行业生态。未来不管是AI Agent越来越普及，还是国产算力进一步崛起，这种生态级的协作都只会越来越多，不会变少。
最后再分享一个小技巧，如果你打算在两家云之间做模型迁移，千万别把大量时间花在手工转换模型权重上。现在主流模型普遍支持通过ModelScope或者Hugging Face直接下载，你只需要把下载脚本放进目标云的服务器里，执行一次就能搞定，比自己到处拷贝模型文件要省太多事。用一句话总结我的经验：让模型以原生方式流动，让算力以标准接口对接，两朵云自然就“合作”起来了。