training-xpu-pytorch 26.01
本文介绍training-xpu-pytorch 26.01版本发布记录。
Main Features and Bug Fix Lists
Main Features
PPU SDK正式升级至2.0.0。
transformer_engine升级至2.8，推理组件 vLLM 升级至0.12.0+ppu2.0.0.oe。
health_check升级适配shuttle 1.5.3。
新增适配 vLLM 至0.14.0镜像，其中torch升级至2.9、triton升级至3.5、deepspeed升级至0.18.5、transformers升级至4.57.6。
升级 vLLM 至 0.16.0，其中Flashinfer升级至0.6.3、megatron 升级至 0.16.0。
Bugs Fix
vLLM0.16.0修复了如下问题：
修复GLM-5 回答乱码问题。
修复Qwen3.5-35B-A3B 模型 TP=2 Server Fail 问题。
Contents
镜像名 | training-xpu-pytorch | ||
镜像TAG | 26.01 | 26.01-pytorch2.9-20260215 | 26.01-pytorch2.9-20260320 |
应用场景 | 训练/推理 | ||
框架 | pytorch 2.8.0 | pytorch 2.9.0 | pytorch 2.9.0 |
Requirements | PPU SDK 2.0.0 | ||
Supported Architectures | amd64 | ||
核心组件 |
|
|
|
Assets
通过公网拉取ACS AI容器镜像需要先获取鉴权密钥。建议您使用VPC方式加速拉取AI容器镜像，减少镜像拉取的时间。
公网镜像
egslingjun-registry.cn-wulanchabu.cr.aliyuncs.com/egslingjun/training-xpu-pytorch:26.01
egslingjun-registry.cn-wulanchabu.cr.aliyuncs.com/egslingjun/training-xpu-pytorch:26.01-pytorch2.9-20260215
egslingjun-registry.cn-wulanchabu.cr.aliyuncs.com/egslingjun/training-xpu-pytorch:26.01-pytorch2.9-20260320
VPC镜像
将指定的AI容器镜像Asset URIegslingjun-registry.cn-wulanchabu.cr.aliyuncs.com/egslingjun/{image:tag}替换为acs-registry-vpc.{region-id}.cr.aliyuncs.com/egslingjun/{image:tag}即可在VPC内快速拉取PPU AI容器镜像。
{region-id}：ACS产品开服地域（包括金融云、政务云等）的地域ID。例如：cn-beijing、cn-wulanchabu、cn-shanghai-finance-1等。{image:tag}：AI容器镜像的名称和Tag。例如：inference-xpu-pytorch:25.11-v1.7.0-vllm0.10.2-torch2.8-cu129-20251113、training-xpu-pytorch:25.11等。
Driver Requirements
Driver version >= 1.1.0
Key Features and Enhancements
PyTorch编译优化
PyTorch 2.0引入的编译优化能力在单卡小规模下通常可以获得显著的收益，但是在LLM训练中需要引入显存优化、FSDP/Deepspeed等分布式框架，导致torch.compile()无法简单地获得收益或者存在负收益：
在DeepSpeed框架下控制通信的颗粒度，帮助编译器获取更完整的计算图，做更大范围的编译优化。
优化版本的PyTorch：
优化PyTorch编译器前端，确保在计算图中出现任意graph break的情况下仍能正常编译。
强化模式匹配以及dynamic shape能力，提高编译后代码性能。
结合上述优化，在8B LLM训练下通常可以获得20%左右的E2E吞吐收益。
重计算显存优化
基于大量性能评测数据，包括不同模型在不同集群以及不同训练参数配置，以及评测过程中采集的相关显存利用率等系统指标数据，我们进行模型显存开销的预测建模分析，并推荐出最佳的激活值重算层数，并集成到PyTorch中，让用户可以低门槛的使用显存优化带来的性能收益。当前已支持该特性在DeepSpeed框架中的适配。
ACCL通信库
ACCL是阿里针对灵骏产品自研的高性能网络通信库，针对GPU、PPU和AMD三个场景提供ACCL-N、ACCL-P和ACCL-R三个版本。ACCL-N是阿里云基于英伟达NCCL定制后提供的高性能通信库，在完全兼容NCCL的基础上，修复了官方NCCL版本的一些BUG，并进行了性能和稳定性相关的优化。ACCL-P是基于平头哥开源通信库pccl，进行二次开发的集合通信库。ACCL-R是基于AMD Rocm开源通信库rccl，进行二次开发的集合通信库。本版本主要将ACCL/ACCL-N上实现的主要特性移植到了pccl上，修复了一些问题，结合高网的相关自研产品组件进行了深度定制。
E2E性能益评估
利用云原生AI性能评测分析工具CNP，我们采用主流开源模型和框架配置，与标准的基础镜像进行了全面的端到端性能比较分析，并通过消融实验分析，进一步评估了每个优化组件对整体模型训练性能的收益贡献。
镜像对比基础镜像&迭代评估
PPU&GPU核心组件E2E性能贡献分析
以下测试基于26.01，在多节点PPU集群上进行训练E2E性能评测和对比分析，对比项包括：
Base：PPU PyTorch Image
ACS AI Image：Base+ACCL： 镜像使用ACCL通信库
ACS AI Image：AC2+ACCL： Golden镜像使用AC2 BaseOS，不开启任何优化
ACS AI Image：AC2+ACCL+CompilerOpt： Golden镜像使用AC2 BaseOS，只启用torch compile优化
ACS AI Image：AC2+ACCL+CompilerOpt+CkptOpt：Golden镜像使用AC2 BaseOS，且同时开启torch compile和selective gradient checkpoint优化
Quick Start
以下示例内容仅通过Docker方式拉取training-xpu-pytorch镜像。
在ACS中使用training-xpu-pytorch镜像可以通过控制台创建工作负载时输入指定镜像地址，或者通过YAML文件指定镜像引用。
1. 选择镜像
通过公网拉取ACS AI容器镜像需要先获取鉴权密钥。建议您使用VPC方式加速拉取AI容器镜像，减少镜像拉取的时间。
docker login egslingjun-registry.cn-wulanchabu.cr.aliyuncs.com2. 调用API开启编译器+重计算显存优化
启用编译优化
使用transformers Trainer API：
启用重计算显存优化
export CHECKPOINT_OPTIMIZATION=true
3. 启动容器
镜像中内置了模型训练工具ljperf，以此说明启动容器和运行训练任务的步骤。
ACS形态产品请通过YAML方式使用镜像。
LLM类
# 启动容器并进入
docker run --rm -it --ipc=host --net=host --privileged egslingjun-registry.cn-wulanchabu.cr.aliyuncs.com/egslingjun/training-xpu-pytorch:[tag]
# 运行训练demo
ljperf --action train --model_name deepspeed/llama3-8b使用建议
镜像中的改动涉及PyTorch、DeepSpeed等库，请勿重装。
DeepSpeed配置中的
zero_optimization.stage3_prefetch_bucket_size留空或者auto。本镜像内置环境变量
NCCL_SOCKET_IFNAME需要根据使用场景动态调整：当单Pod只申请了1/2/4/8卡进行训练/推理任务时，需要设置
NCCL_SOCKET_IFNAME=eth0（本镜像内默认配置）当单Pod申请了整机的16卡（此时您可以使用HPN高网）进行训练/推理任务时，需要设置
NCCL_SOCKET_IFNAME=hpn0
本镜像建议配合使用“在ACS产品使用阿里云提供的PPU PIP服务”，支持在ACS VPC内一站式免密使用PIP服务，不需要再组合使用其他PIP源。本镜像内已经内置了相应的pip config，还需要您结合您的使用场景根据文档的指引做必要的配置。
在ACS环境使用AcclEP-P（即PPU版本的DeepEP） ，需要设置环境变量
export EIC_VSOLAR=1（本镜像需要设置，预计后续镜像移除该限制）。建议配合最新版本驱动使用本镜像获得最佳性能，设置方法请参考为ACS GPU Pod指定GPU型号和驱动版本和GPU驱动版本说明。
PPU SDK 2.0.0容器镜像支持量化能力说明：
SAIL vLLM 0.12.0 支持的标准量化能力：per-token/per-channel w8a8（int8）
目前 SAIL vLLM 0.12.0 暂未对 Marlin kernel 进行适配和优化，AWQ（w4a16）、GPTQ （w4a16、w8a16）、mxfp4 性能较差，请使用 int8 w8a8 量化方案。
提供适配SDK2.0的量化模型示例，系统登录账密复用 PTG PIP 账密（如无，可联系您的客户经理获取）：
DeepSeek-R1：支持 per-token/per-channel a8w8（int8）量化方案
DeepSeek v3.2：支持 per-token/per-channel a8w8（int8）量化方案
Kimi-K2-Instruct：支持 per-token/per-channel a8w8（int8）量化方案
Qwen3-235B-A22B：支持 per-token/per-channel a8w8（int8）量化方案
GLM-5：支持 per-token/per-channel w8a8（int8）量化方案
MiniMax-M2.5：支持 per-token/per-channel w8a8（int8）量化方案
Qwen3.5-397B-A17B：支持 per-token/per-channel w8a8（int8）量化方案
使用vllm 0.14.0进行模型推理时，需要更新flash-attn依赖至v2.8.2。
Known Issues
vLLM 0.16.0已知问题
社区vLLM在0.16.0上并未支持Qwen3.5系列模型，PPU进行了部分支持，但无法支持Qwen3.5系列模型的所有功能和场景。可能会遇到的问题包括但不限于：
开启MTP功能后概率性fail。
bfcl_v3 精度测试（enable tool call功能）fail。
为适配GLM-5和Qwen3.5系列模型，transformers版本已升级到5.2.0。此版本不支持Qwen VL模型， 运行Qwen VL模型需要将transformers版本降到4.57.1。
DP+EP+DeepEP low latency问题：
第一次启动server需要设置
export VLLM_ENGINE_READY_TIMEOUT_S=6000，否则server会启动失败。社区在GU8TF卡型上会存在相同问题。对于 Qwen3 MoE BF16 的场景，存在精度问题。社区同样存在该精度问题。
MiniMax-M2.5模型 TP=16 Server Fail，请使用TP=8 运行int8量化权重。
MiniMax-M2模型ifeval精度测试得分较低，GU8TF卡型上同样存在该问题。
--gpu_memory_utilization的值高于0.96时，低概率会因Driver OOM出现seg fault。Flashinfer Sampler可能会导致精度掉点。如遇到模型精度掉点问题，可通过
export VLLM_USE_FLASHINFER_SAMPLER=0关闭该功能。Kimi-linear模型存在精度问题，社区同样存在精度问题。
Kimi-linear | DeepSeek-OCR 系列 模型使用 DeepGemm 将会导致 server 启动失败。请设置环境变量，使用 Acext MoE backend。
# 设置环境变量，使用Acext MoE backend export VLLM_USE_DEEP_GEMM=0 export VLLM_MOE_USE_ACEXT=1 export VLLM_DENSE_USE_ACEXT=1 export ACEXT_NUM_TOKENS_LIMIT=16385如果使用 DeepGemm backend，Server 启动阶段则会自动进行warmup，编译出需要用到的 DeepGemm kernel，可能会带来较长的 warmup 时间：
warmup时间较长，推荐通过环境变量指定deepgemm cache 路径：
export DG_CACHE_DIR=<your path>，从而避免重复编译。可以通过
export VLLM_DEEP_GEMM_WARMUP="skip"跳过 DeepGemm warmup，测试性能过程中请确保未出现 DeepGemm JiT 编译，否则会导致性能下降。
量化方面，目前 SAIL vLLM 0.16.0 暂未对 Marlin kernel 进行适配和优化，AWQ（w4a16）、GPTQ （w4a16、w8a16）、mxfp4 性能较差，请使用 int8 w8a8 量化方案。