昇腾平台多模态微调与推理实战，从理论到落地的完整探索

它不仅预置了30+主流多模态模型（包括视图生成的Wan、HunyuanVideo，视图理解的InternVL、QwenVL等），还提供了完整的数据工程、模态编码与对齐、评价体系。多模态大模型正在改变AI的应用边界，从文生图到文生视频，从图像理解到全模态交互，这些能力的背后离不开强大的算力支持和高效的推理框架。多模态模型的性能瓶颈往往不在单个算子，而在系统层面的通信、显存、调度协同。对于想在昇腾平台

屿小夏.

434人浏览 · 2025-12-24 22:43:57

屿小夏. · 2025-12-24 22:43:57 发布

文章目录

多模态大模型正在改变AI的应用边界，从文生图到文生视频，从图像理解到全模态交互，这些能力的背后离不开强大的算力支持和高效的推理框架。

最近我在昇腾平台上完成了一次完整的多模态项目实践——使用MindSpeed MM进行Qwen2.5-VL模型微调，并通过MindIE SD实现Wan2.1视频生成模型的高性能推理。

这次经历让我深刻体会到，多模态模型的训练和部署远比想象中复杂，但昇腾平台提供的工具链确实能让整个流程变得可控。

一、初识生态

刚接触昇腾平台时，我面对的是三个核心套件：MindSpeed LLM（大语言模型）、MindSpeed MM（多模态模型）和MindSpeed RL（强化学习）。

对于我的项目需求——既要微调视觉理解模型，又要部署视频生成模型——MindSpeed MM成为了首选。

这个套件的架构设计很巧妙。它不仅预置了30+主流多模态模型（包括视图生成的Wan、HunyuanVideo，视图理解的InternVL、QwenVL等），还提供了完整的数据工程、模态编码与对齐、评价体系。

更重要的是，底层对接了MindSpeed Core加速库，在计算、显存、通信、并行四个维度都做了深度优化。

选择框架时一定要确认版本配套关系。我最初使用的PyTorch 2.6.0与torch_npu 7.1.0、CANN 8.2.RC1完美适配，但如果版本不匹配，后续会遇到各种奇怪的算子报错。

二、环境搭建

环境准备是整个项目最容易踩坑的环节。

以下是我总结的完整流程：

安装驱动和固件

bash Ascend-hdk-*-npu-driver_*.run --full --force
bash Ascend-hdk-*-npu-firmware_*.run --full

安装CANN套件

bash Ascend-cann-toolkit_8.2.RC1_linux-aarch64.run --install
bash Ascend-cann-kernels-*_8.2.RC1_linux-aarch64.run --install
source /usr/local/Ascend/ascend-toolkit/set_env.sh
bash Ascend-cann-nnal_8.2.RC1_linux-aarch64.run --install

创建Python环境并安装依赖

conda create -n mm_env python=3.10
conda activate mm_env
pip install torch-2.7.1-cp310-cp310-manylinux_2_28_aarch64.whl
pip install torch_npu-2.7.1*-cp310-cp310-manylinux_2_28_aarch64.whl

拉取代码仓库

git clone https://gitee.com/ascend/MindSpeed-MM.git
cd MindSpeed-MM
git clone https://github.com/NVIDIA/Megatron-LM.git
cd Megatron-LM && git checkout core_v0.12.1
cp -r megatron ../MindSpeed-MM/

这里有个关键点，CANN的nnal包必须在source环境变量后安装，否则会找不到依赖路径。我第一次就是因为顺序错误，导致后续模型推理时报libatb.so找不到的错误。

三、权重转换

选择Qwen2.5-VL-7B作为微调目标后，我遇到的第一个问题是权重转换。

HuggingFace下载的原始权重无法直接使用，因为MindSpeed-MM对网络结构名称做了修改以适配并行策略。

下方是权重转换的命令：

mm-convert Qwen2_5_VLConverter hf_to_mm \
--cfg.mm_dir "ckpt/mm_path/Qwen2.5-VL-7B-Instruct" \
--cfg.hf_config.hf_dir "ckpt/hf_path/Qwen2.5-VL-7B-Instruct" \
--cfg.parallel_config.llm_pp_layers [[12，16]] \
--cfg.parallel_config.vit_pp_layers [[32，0]] \
--cfg.parallel_config.tp_size 1

这里的llm_pp_layers和vit_pp_layers参数让我困惑了很久。

后来了解到这是Pipeline Parallel（流水线并行）的层数切分配置。比如[[12，16]]表示LLM部分第一张卡放12层，第二张卡放16层。

我是单卡进行训练，设置为[[28]]。

有一点需要注意，TP并行度（tp_size）不能超过模型配置中的num_key_value_heads，否则会因为KV头无法均分到各卡而报错。

四、格式转换

使用COCO2017数据集进行图像理解微调时，原始的标注文件需要转换为MindSpeed-MM的格式。

官方提供了转换脚本：

import json
def convert_format(input_file， output_file):
with open(input_file， 'r') as f:
data = json.load(f)
converted = []
for item in data:
new_item = {
"messages": [
{"role": "user"， "content": item["conversations"][0]["value"]}，
{"role": "assistant"， "content": item["conversations"][1]["value"]}
]，
"images": [f"./data/COCO2017/train2017/{item['image']}"]
}
converted.append(new_item)
with open(output_file， 'w') as f:
json.dump(converted， f， indent=2)

运行转换后，还需要修改data.json中的路径配置。

这里有个小技巧，max_samples参数可以限制只读取前N条数据，用于快速验证流程是否正确，避免等待完整数据集加载。

五、开始微调

正式启动微调前，必须设置一系列环境变量，这些变量看似繁琐，实则直接影响性能和稳定性。

环境变量的参数：

export ASCEND_SLOG_PRINT_TO_STDOUT=0 # 关闭日志打屏，避免影响性能
export TASK_QUEUE_ENABLE=2 # 开启Level 2算子队列优化
export COMBINED_ENABLE=1 # 开启算子组合优化
export CPU_AFFINITY_CONF=1 # 开启粗粒度绑核
export HCCL_CONNECT_TIMEOUT=1200 # 设置HCCL通信超时时间
export PYTORCH_NPU_ALLOC_CONF=expandable_segments:True # 开启内存池扩展
启动脚本中，我特别关注了几个参数：
GPT_ARGS="
--no-load-optim \ # 不加载优化器状态，节省显存
--no-save-rng \ # 不保存随机数状态
--save-interval 5000 \ # 每5000步保存一次（分布式优化器保存很慢）
--log-tps \ # 打印tokens吞吐量

注意save-interval不要设置太小！使用分布式优化器时，保存checkpoint会非常耗时。我第一次设置成100步保存一次，结果训练大部分时间都在等待写磁盘。

六、推理部署

完成微调后，我转向另一个任务，就是在昇腾上部署Wan2.1视频生成模型。

这是一个基于DiT（Diffusion Transformer）架构的文生视频模型，推理性能优化是核心挑战。

扩散模型的推理过程本质上是多轮迭代去噪。以50步采样为例，每一步都要经过完整的DiT前向计算。

给我的感觉是会带来三个问题：

计算冗余：相邻步骤间的激活特征存在70%以上的相似性
长序列负担：视频帧序列可达百万级别，Attention计算复杂度是O(N²)
显存压力：大激活、小参数的特点导致显存瓶颈在中间特征而非权重

MindIE SD针对这些问题提供了三层优化方案：

最直接的优化是将计算密集型操作替换为融合算子。

以RoPE（旋转位置编码）为例：

def apply_rotary_emb(x， freqs_cis):
cos， sin = freqs_cis
x_rot = torch.stack([-x[...， 1::2]， x[...， ::2]]， dim=-1).flatten(-2)
return x * cos + x_rot * sin
# 优化后使用融合算子
from mindiesd import rotary_position_embedding
cos， sin = freqs_cis_img
query = rotary_position_embedding(
query， cos， sin，
rotated_mode="rotated_half"，
head_first=False，
fused=True # 关键参数，使用融合算子
)

这个替换在我的测试中带来了约15%的单步推理加速。

类似的，attention_forward接口封装了多种高性能Attention实现（PFA、FASCore、LaserAttention），并支持自动寻优：

from mindiesd import attention_forward
# 自动选择最优算子（首次会搜索，后续使用缓存结果）
hidden_states = attention_forward(
query， key， value，
attn_mask=attention_mask，
opt_mode="runtime" # 运行时动态搜索
)

这是我认为最巧妙的优化。通过分析发现，扩散采样过程中约70%的特征在步间高度相似。

DiTCache不是简单复用前一步的结果，而是引入"偏置量"机制：

from mindiesd import CacheConfig， CacheAgent
# 配置缓存策略
config = CacheConfig(
method="dit_block_cache"，
blocks_count=len(transformer.single_blocks)，
steps_count=50， # 总采样步数
step_start=20， # 从第20步开始缓存
step_interval=2， # 每2步强制重新计算
step_end=47， # 第47步停止缓存
block_start=10， # 只缓存第10-30个block
block_end=30
)
cache_agent = CacheAgent(config)
transformer.cache = cache_agent
# 在block前向传播中使用
x = self.cache.apply(block， hidden_states=x， vec=vec， ...)

这个策略在我的实验中，将50步采样的总时间从45秒降至28秒，加速比达1.6x。关键在于step_interval的设置——每隔几步强制重新计算，避免误差累积。

不同模型的最优缓存策略差异很大。建议使用官方提供的递进式搜索工具Cache Searcher自动找到当前模型的最佳配置。

对于长序列视频生成，单卡内存根本放不下。

MindIE SD实现了一套优雅的混合并行方案：

export PYTORCH_NPU_ALLOC_CONF='expandable_segments:True'
export TASK_QUEUE_ENABLE=2
torchrun --nproc_per_node=4 generate.py \
--task t2v-1.3B \
--ulysses_size 4 \ # Ulysses并行度
--prompt "Two cats fighting on stage" \
--use_attentioncache \
--start_step 20 \
--attentioncache_interval 2

Ulysses并行的核心思想是：在序列维度切分输入，在注意力头维度聚合计算。

具体流程是：

输入序列按卡数切分，每卡得到(S/p， d)的数据块。
QKV线性变换后，通过AllToAll通信变为(S， d/p)。
每卡计算完整序列的部分注意力头。
再次AllToAll恢复为(S/p， d)输出。

这种方式的通信量是4Sd/p（QKV+O各一次AllToAll），相比传统数据并行大幅降低。

最终在Atlas 800T A2训练服务器（8卡NPU）上的测试结果：

场景	配置	端到端时延	加速比
Qwen2.5-VL微调	单卡，BF16	2.3 samples/s	-
Wan2.1推理（单卡）	832x480，50步	45s	1.0x
+Layer优化	同上	38s	1.18x
+DiTCache	同上	28s	1.61x
Wan2.1推理（4卡）	Ulysses并行	12s	3.75x