SDK Release Note（v2.1）

产品

支持状态

真武810E

✅

组件名称

概要说明

Firmware

PPU 固件

KMD

PPU 内核驱动

UMD / HGGC

PPU 用户态驱动和运行时

Compiler

PPU 编译器工具链

Acompute

PPU 计算加速库

Acext

PPU 量化加速库

PCCL

PPU 通信加速库

PPU SMI

PPU 设备管理工具

PPU DCGM

PPU 在线监控工具

Asight Systems

PPU 性能分析工具

Asight Compute

PPU 性能分析工具

PPU GDB

PPU 调试工具

PPU MemCheck

PPU Sanitizer工具

PPU hgobjdump

PPU Device Binary工具

Holmes Inference Engine

PPU Holmes 推理加速引擎
Holmes-LLM

CUDA SDK Wrapper

CUDA API 兼容库

类别

操作系统

架构

GCC

Ubuntu

Ubuntu 24.04 LTS

x86_64

13.3.0

Ubuntu 22.04 LTS

11.4.0

Ubuntu 20.04 LTS

9.5.0

Ubuntu 18.04 LTS

7.5.0

CUDA Version

11.1

11.2

11.3

11.4

11.5

11.6

11.7

11.8

12.1

12.2

12.3

12.4

12.5

12.6

12.8

12.9

13.0

框架

版本

已知问题

PyTorch

2.9

UT FAIL的分类说明：

1. CUDA API 暂不支持

2. 预期结果：

   1. A100 FAIL

   2. 测试中Hardcode NV binary的名字

   3. 硬件SFU导致的差异 等

3. 个别tensor元素误差略大于测试用例阈值

4. 运行超时time out

SGlang

0.5.9

• 社区的临时解决方案是改写 tilelang act_quant 成 triton kernel，从而在运行时不会 import tilelang，但因为我们复用了 tilelang mqa_logits 相关的 kernel，所以无法移除对 tilelang 的依赖，因此将 flashinfer 暂时回退到适配 tvm-ffi 前的 v0.4.0rc3 版本。

• 待不同社区 flashinfer/tilelang/sglang 使用统一的 tvm-ffi 版本后，我们将会在后续版本回退这个改动。

• AWQ 和 GPTQ 未深度优化存在性能问题，后续视业务需要进行针对性优化。建议优先使用PTG提供的int8量化方案。

• 运行 a8w8（int8）量化模型需要加 --quantization w8a8_int8 选项。

VLLM

v0.16.0

• 社区vLLM在0.16.0上并未支持Qwen3.5系列模型，PPU进行了部分支持（TP），无法支持Qwen3.5系列模型的所有功能、所有case。如果需要使用Qwen3.5系列模型，请使用v0.17.1以上的版本。目前的已知问题：

  • 开启MTP功能后概率性fail

  • bfcl_v3 精度测试（enable tool call功能）fail

  • 不支持EP

• GLM-5和Qwen3.5系列模型运行需要升级 transformers ==5.2.0

• DP+EP+DeepEP low latency问题：

  • 第一次启动server需要设置export VLLM_ENGINE_READY_TIMEOUT_S=6000，否则可能会因DeepGemm warmup编译超时导致server启动失败。社区在H20上存在相同问题。

  • 对于 Qwen3 MoE BF16 的case，存在精度问题。社区同样存在该精度问题。请不要使用DP+EP+DeepEP low latency这种组合启动Qwen3 MoE BF16 模型权重

• MiniMax-M2.5模型 TP=16 server fail，请使用TP=8 运行int8量化权重。

• --gpu_memory_utilization的值高于0.96时，会概率性遇到HGGC OOM问题，调低gpu_memory_utilization可避免该问题。

• 开启Flashinfer Sampler可以获得性能提升，但可能会导致精度掉点（默认关闭该功能）。社区同样存在该问题。可通过 VLLM_USE_FLASHINFER_SAMPLER 环境变量控制该功能的开启或关闭。

• 精度问题：

  • MiniMax-M2模型 ifeval精度测试得分较低，社区在H20上同样存在该问题

  • Kimi-linear模型存在精度问题，社区同样存在精度问题

• Flashinfer Sampler可能会导致精度掉点（该功能默认开启）。如遇到模型精度掉点问题，可通过 export VLLM_USE_FLASHINFER_SAMPLER=0 关闭该功能

• 如果使用 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 量化方案。

• 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

v0.17.1

• GLM-5模型运行需要升级 transformers ==5.2.0

• DP+EP+DeepEP low latency问题：

  • 第一次启动server需要设置export VLLM_ENGINE_READY_TIMEOUT_S=6000，否则可能会因DeepGemm warmup编译超时导致server启动失败。社区在H20上存在相同问题。

  • 对于 Qwen3 MoE BF16 的case，存在精度问题。社区同样存在该精度问题。请不要使用DP+EP+DeepEP low latency这种组合启动Qwen3 MoE BF16 模型权重

• MiniMax-M2.5模型 TP=16 server fail，请使用TP=8 运行int8量化权重。

• --gpu_memory_utilization的值高于0.96时，会概率性遇到HGGC OOM问题，调低gpu_memory_utilization可避免该问题。

• 开启Flashinfer Sampler可以获得性能提升，但可能会导致精度掉点（默认关闭该功能）。社区同样存在该问题。可通过 VLLM_USE_FLASHINFER_SAMPLER 环境变量控制该功能的开启或关闭。

• 精度问题：

  • MiniMax-M2模型 ifeval精度测试得分较低，社区在H20上同样存在该问题

  • Kimi-linear模型存在精度问题，社区在H20上同样存在该问题

  • Qwen3-Next系列模型相比vLLM 0.16.0，存在精度掉点，社区在H20上同样存在该问题

  • Qwen2.5-7B模型存在精度问题，社区在H20上同样存在该问题

• 如果使用 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.17.1 暂未对 Marlin kernel 进行适配和优化，AWQ（w4a16）、GPTQ （w4a16、w8a16）、mxfp4 性能较差，请使用 int8 w8a8 量化方案。

• 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

v0.18.0

• GLM-5模型运行需要升级 transformers==5.2.0

• DP+EP+DeepEP low latency问题：

  • 第一次启动server需要设置export VLLM_ENGINE_READY_TIMEOUT_S=6000，否则可能会因DeepGemm warmup编译超时导致server启动失败。社区在H20上存在相同问题。

  • 对于 Qwen3 MoE BF16 的case，存在精度问题。社区同样存在该精度问题。请不要使用DP+EP+DeepEP low latency这种组合启动Qwen3 MoE BF16 模型权重

• MiniMax-M2.5模型 TP=16 server fail，请使用TP=8 运行int8量化权重。

• --gpu_memory_utilization的值高于0.96时，会概率性遇到HGGC OOM问题，调低gpu_memory_utilization可避免该问题。

• 开启Flashinfer Sampler可以获得性能提升，但可能会导致精度掉点（默认关闭该功能）。社区同样存在该问题。可通过 VLLM_USE_FLASHINFER_SAMPLER 环境变量控制该功能的开启或关闭。

• 如果使用 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.18.0 暂未对 Marlin kernel 进行适配和优化，AWQ（w4a16）、GPTQ （w4a16、w8a16）、mxfp4 性能较差，请使用 int8 w8a8 量化方案。

TransformerEngine

v2.10

• 为了更好的性能表现，我们推荐用户在TE里面使用flashattention的后端。因为暂时不支持cudnn中的fusedattention backend，在PPU版本的TE中做了保护性重定向，所有指定fusedattention backend的操作都会导向flashattention的后端。

• 已知问题列表：

  • 在PPU1.0/PPU1.1上不支持fp8/fp4相关特性的计算与围绕着其构建的功能，包括FP8 current/delay scaling, MXFP8 and block scaling以及NVFP4的训练特性等。

  • 目前PPU Transformer Engine只支持torch的backend，暂时不支持使用jax

Flashinfer

v0.6.3

目前ppu版本flashinfer存在性能问题，在端到端性能中，TPOT指标与A100存在性能差距，需要继续优化：

• test_batch_attention.py

  • Fail Instance：23039

  • Fail Reason：没有对mma适配，sglang暂时没有支持需求

• test_attention_sink.py

  • Fail Instance：1336

  • Fail Reason：用了hopper的特性

• test_cudnn_decode.py

  • Fail Instance：12

  • Fail Reason：cudnnFinalize failedptrDesc->finalize() cudnn_status: CUDNN_STATUS_BAD_PARAM，cudnn版本兼容问题

• test_group_gemm.py

  • Fail Instance：26

  • Fail Reason：sglang暂时没有适配需求 AssertionError(AssertionError: Unknown cases: sf.dtype=torch.float32)

• test_trtllm_alltoall.py

  • Fail Instance：6

  • Fail Reason：trtllm底层库不支持AssertionError: Process 0 failed with exit code 1test_trtllm_moe_allreduce_fusion.py:443: AssertionError

• test_trtllm_gen_mla.py

  • Fail Instance：1232

  • Fail Reason：trtllm底层库不支持

Jax

0.8.0

1. JAX 依赖 numpy >= 2.0.0, 如果需要配合 torch/tf 等框架，需要单独编译。

2. 只支持在 ubuntu 上编译运行，不支持 alios。

3. examples/advi.py 运行出现 nan。

4. 暂不支持 xla_gpu_enable_llvm_module_compilation_parallelism = True。

5. UT FAIL 的分类说明：

   1. cusolver/cusparse/cublas api 不支持导致的 fail。

   2. acdnn 内部错误导致 jaxlib._jax.XlaRuntimeError: UNKNOWN: Failed to determine best cudnn convolution algorithm。

Megatron

v0.15.0

• UT 测试 pass-rate: 98.24% (810E)， 98.51%（h20），部分 fail case 由于未安装必要依赖库导致；有部分case 要求 SM >= 90

v0.16.0

DeepSpeed

v0.18.7

• UT 测试： 当前 UT 测试通过率为 95.74%

• PPU DeepSpeed从v0.18.7版本开始会支持每个小版本的whl包发布

ROLL

v0.1.3

部分UT存在Failed的情况：

1. 一部份测试脚本需要多节点而导致Failed.

2. 部分test case存在hang的问题,该情况与NVIDIA H20上的行为保持一致.

veRL

v0.7.0

1. veRL的FusedKernels在PPU上性能未达预期，请在训练脚本中设置：actor_rollout_ref.model.use_fused_kernels=False。

2. veRL0.7.0的全量 UT 测试：

   • 使用SGLang后端的镜像：PPU pass rate为84.79%，GPU为84.48%。未通过的case大部分与PPU无关。

   • 使用vLLM后端的镜像：PPU pass rate为83.21%，GPU为82.55%。未通过的case大部分与PPU无关。

   • 测试models/test_transformers_ulysses.py出现hang，该情况与GPU上的行为一致。

Slime

v0.2.1

1. 在colocated模式下，即训练和推理在同一张卡上，在极少数复杂情况会出现Segfault 或 hang 的情况。如出现请切换到非colocated模式使用，取消启动脚本的--colocate ，并且合理分配训练和推理的卡数。

Warp

v1.10.0

1. 目前 NVIDIA Warp 属于第一版支持，专注于客户场景如 Mujoco 和 Newton 的使能，目前 Warp 单软件的 UT 通过率是41.2% ，还有待提高。

2. 某些硬件因为不支持conditional cuda graph，执行mujoco solver时会报错，改动mujoco-warp的一行代码即可解决。比如 /usr/local/lib/python3.12/site-packages/mujoco_warp/_src/solver.py，在文件的对应行加入and False关闭此功能即可。

3. 在运行Mujoco-Warp的make_constraint后，efc数据会在condim的维度反序，但是不影响每个contact的结果。