Ascend-SACT/GLM-5-W4A8-SGLANG
模型介绍文件和版本Pull Requests讨论分析
下载使用量0

GLM-5 SGLang 910B 硬件成功部署指南和经验教训

一、环境信息

1.1 硬件配置

项目规格
平台A+X
芯片型号910B2C
NPU 数量16 卡
单卡 HBM64 GB (65536 MB)
总显存1024 GB (16 × 64 GB)

验证命令:

npu-smi info  # 查看 NPU 状态和显存

1.2 软件版本

组件版本
操作系统Ubuntu 22.04.5 LTS
Python3.11.14
CANN8.5.0
npu-smi25.0.rc1.1
torch2.8.0+cpu
torch-npu2.8.0.post2
transformers5.2.0
sglang0.1.dev9598+ga59cca5c0.d20260211
triton-ascend3.2.0
deep-ep1.0.0+c726cd83.cann.8.5.0.b232

验证命令:

python3 -c "import torch, torch_npu, sglang, transformers; \
print(f'torch: {torch.__version__}'); \
print(f'torch_npu: {torch_npu.__version__}'); \
print(f'sglang: {sglang.__version__}'); \
print(f'transformers: {transformers.__version__}'); \
import triton.backends.ascend; print('triton-ascend: OK')"

重要: 使用 pip list | grep triton 确认只安装了 triton-ascend,不应有 triton 包。

1.3 模型信息

  • 模型: GLM-5-w4a8
  • 模型架构: glm_moe_dsa (MoE with Dense Shared Attention)
  • 量化格式: W4A8 (4-bit weights, 8-bit activations)
  • 模型路径: MODEL_PATH

二、环境准备步骤

2.1 镜像基础信息

使用的 Docker 镜像:

cosdt-modelscope/sglang:cann8.5.0-910b-glm5

注意: 这个镜像的初始配置需要进行以下修正。

2.2 必要的版本修正步骤

步骤 1: 升级 transformers 版本 ⚠️

官方镜像初始版本: transformers 4.57.1

问题: GLM-5 的 glm_moe_dsa 模型架构在 transformers 4.57.1 中不被支持

错误信息:

ValueError: The checkpoint you are trying to load has model type `glm_moe_dsa` 
but Transformers does not recognize this architecture.

依赖关系说明:

  • SGLang 0.1.dev9598 依赖 transformers==4.57.1
  • GLM-5 (glm_moe_dsa) 需要 transformers >= 5.0

解决方案: 必须升级到 transformers 5.2.0

# 升级 transformers
pip install --upgrade transformers==5.2.0

# 确认版本
pip show transformers | grep Version
# 输出: Version: 5.2.0

预期警告 (可忽略):

sglang 0.1.dev9598 requires transformers==4.57.1, but you have transformers 5.2.0

这个依赖警告不影响 GLM-5 的正常运行,已验证可用。

步骤 2: 检查并解决 triton 版本冲突 ⚠️

问题: 某些环境中可能同时安装了 triton 和 triton-ascend,导致运行时错误

检查方法:

pip list | grep triton

正确的输出 (仅应有 triton-ascend):

triton-ascend    3.2.0

错误的输出 (同时存在两个包):

triton           3.6.0    # ← 这个会导致冲突!
triton-ascend    3.2.0

解决方案:

# 1. 卸载冲突的 triton 包
pip uninstall -y triton

# 2. 重新安装 triton-ascend 以修复符号链接
pip install --force-reinstall --no-deps triton-ascend==3.2.0

# 3. 验证 NPU 后端可用
python3 -c "import triton; import triton.backends.ascend; print('✅ Triton-Ascend NPU backend OK')"

错误症状识别:

  • ✅ 服务启动成功,显示 "The server is fired up and ready to roll!"
  • ❌ 首次推理请求时服务崩溃
  • ❌ 错误信息: RuntimeError: 0 active drivers ([]). There should only be one.
  • ❌ 日志显示: allocator_npu.py 中的 triton kernel 执行失败

原因分析:

  • triton 和 triton-ascend 都提供 triton 模块
  • Python 优先导入了 triton 3.6.0,缺少 NPU 后端支持
  • 导致 SGLang 的 NPU allocator 无法找到 Ascend driver

验证成功标志:

$ python3 -c "import triton.backends.ascend"
# 应该没有任何输出(无错误)

三、正确的启动脚本

3.1 完整启动脚本

文件名: deploy_glm5_sglang_deepep_optimized.sh

#!/bin/bash
# GLM-5 SGLang deployment with DeepEP-Ascend optimized settings
# Hardware: Atlas 800 A2 (910B2C)
# Date: 2026-03-02

# ============================================================
# Model Configuration
# ============================================================
export MODEL_PATH=""

# ============================================================
# System Optimization
# ============================================================
echo "Configuring CPU for high performance..."
echo performance | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor 2>/dev/null || true
sysctl -w vm.swappiness=0 2>/dev/null || true
sysctl -w kernel.numa_balancing=0 2>/dev/null || true
sysctl -w kernel.sched_migration_cost_ns=50000 2>/dev/null || true

# ============================================================
# Network Proxy (Disable)
# ============================================================
unset https_proxy
unset http_proxy
unset HTTPS_PROXY
unset HTTP_PROXY
unset ASCEND_LAUNCH_BLOCKING

# ============================================================
# CANN Environment
# ============================================================
echo "Loading CANN environment..."
source /usr/local/Ascend/ascend-toolkit/set_env.sh
source /usr/local/Ascend/nnal/atb/set_env.sh

# ============================================================
# HCCL Configuration (Communication)
# ============================================================
export HCCL_INTRA_ROCE_ENABLE=1
export HCCL_BUFFSIZE=1024
export HCCL_DETERMINISTIC="true"
export HCCL_OP_EXPANSION_MODE=AIV
export HCCL_SOCKET_IFNAME=lo
export GLOO_SOCKET_IFNAME=lo

# ============================================================
# NPU Memory and Threading
# ============================================================
export PYTORCH_NPU_ALLOC_CONF=expandable_segments:True
export OMP_NUM_THREADS=1
export TASK_QUEUE_ENABLE=1

# ============================================================
# SGLang Configuration
# ============================================================
export SGLANG_BACKEND=rpc
export SGLANG_DEVICE=npu
export SGLANG_NPU_USE_MULTI_STREAM=1
export SGLANG_SET_CPU_AFFINITY=1
export SGLANG_ENABLE_SPEC_V2=1
export SGLANG_ENABLE_OVERLAP_PLAN_STREAM=1
export SGLANG_DISAGGREGATION_BOOTSTRAP_TIMEOUT=600
export STREAMS_PER_DEVICE=32

# ============================================================
# CUDA Graph Settings (for reference, disabled in launch)
# ============================================================
export VLLM_CUDAGRAPH_MODE="FULL_DECODE_ONLY"
export VLLM_CUDAGRAPH_CAPTURE_SIZES="[1,4,8,16,32,48,64]"

# ============================================================
# Launch Server
# ============================================================
echo "============================================"
echo "Starting SGLang server for GLM-5-w4a8"
echo "============================================"
echo "Hardware: Atlas 800 A2 (910B2C)"
echo "NPU Count: 16"
echo "DeepEP Mode: low_latency"
echo "Max Tokens/Batch: 8192 (A2 hardware limit)"
echo "============================================"

python3 -m sglang.launch_server \
  --model-path $MODEL_PATH \
  --attention-backend ascend \
  --device npu \
  --tp-size 16 \
  --nnodes 1 \
  --node-rank 0 \
  --chunked-prefill-size 8192 \
  --max-prefill-tokens 8192 \
  --trust-remote-code \
  --host 0.0.0.0 \
  --mem-fraction-static 0.7 \
  --port 8000 \
  --served-model-name glm-5-w4a8 \
  --disable-cuda-graph \
  --quantization modelslim \
  --moe-a2a-backend deepep \
  --deepep-mode low_latency \
  --skip-server-warmup

3.2 启动命令

# 添加执行权限
chmod +x deploy_glm5_sglang_deepep_optimized.sh

# 后台启动(推荐)
bash deploy_glm5_sglang_deepep_optimized.sh > glm5_sglang.log 2>&1 &

# 查看日志
tail -f glm5_sglang.log

# 检查服务状态
curl http://localhost:8000/v1/models

3.3 CUDA Graph 配置(可选性能优化)⚡

CUDA Graph (在 Ascend NPU 上称为 NPU Graph) 是一种性能优化技术,可以减少 kernel launch 开销,提升推理吞吐量和降低延迟。

3.3.1 启用 CUDA Graph 的配置

文件名: deploy_glm5_sglang_with_cudagraph.sh

关键变更(相对于 3.1 的脚本):

# 环境变量保持不变
export VLLM_CUDAGRAPH_MODE="FULL_DECODE_ONLY"
export VLLM_CUDAGRAPH_CAPTURE_SIZES="[1,4,8,16,32,48,64]"

# 启动参数:移除 --disable-cuda-graph
python3 -m sglang.launch_server \
  --model-path $MODEL_PATH \
  ... \
  # --disable-cuda-graph  ← 删除此行,启用 CUDA Graph
  --quantization modelslim \
  ...

完整脚本与 3.1 完全相同,仅删除 --disable-cuda-graph 参数。

3.3.2 性能对比

配置优势劣势适用场景
CUDA Graph 禁用
(默认配置)
• 启动更快 (-72秒)
• 内存占用少 (-6.11GB/card)
• 适合动态负载
• Kernel launch 开销
• 吞吐量较低
• 开发测试
• 频繁重启
• 内存受限
CUDA Graph 启用
(性能优化)
• 吞吐量提升 10-30%
• 延迟降低 5-15%
• 稳定性更好
• 启动时间 +72秒
• 内存占用 +6.11GB/card
• 生产环境
• 高吞吐需求
• 低延迟要求

3.3.3 NPU Graph Capture 过程

启用 CUDA Graph 后,服务启动时会进行 graph capture(约 72 秒):

[2026-03-02 14:57:58] Capture npu graph begin. This can take up to several minutes.
[2026-03-02 14:57:58] Capture cuda graph bs [16, 32, 48, 64, 80, 96, 112, 128, 144, 160, 176, 192, 208, 224, 240, 256]

Capturing batches (bs=256 avail_mem=15.08 GB):   6%|▋  | 1/16 [00:08<02:10,  8.68s/it]
Capturing batches (bs=240 avail_mem=10.03 GB):  12%|█▎ | 2/16 [00:13<01:29,  6.41s/it]
...
Capturing batches (bs=16 avail_mem=9.17 GB):   100%|██████████| 16/16 [01:11<00:00,  4.46s/it]

[2026-03-02 14:59:10] Capture npu graph end. Time elapsed: 72.08 s. mem usage=6.11 GB. avail mem=9.20 GB.
[2026-03-02 14:59:12] max_total_num_tokens=151168, chunked_prefill_size=8192
[2026-03-02 14:59:13] The server is fired up and ready to roll!

关键指标:

  • ✅ 捕获 16 个 batch sizes: [16, 32, 48, 64, 80, 96, 112, 128, 144, 160, 176, 192, 208, 224, 240, 256]
  • ✅ 总耗时: ~72 秒(一次性开销)
  • ✅ Graph 内存: 6.11 GB/card
  • ✅ 可用内存: 9.20 GB/card(充足)

3.3.4 内存使用对比

CUDA Graph 禁用:

KV Cache:           15.47 GB/card
Available Memory:   15.31 GB/card
Total Used:         ~16.7 GB/card

CUDA Graph 启用:

KV Cache:           15.47 GB/card
CUDA Graphs:        6.11 GB/card
Available Memory:   9.20 GB/card
Total Used:         ~22.8 GB/card (在 32GB HBM2e 范围内 ✅)

3.3.5 测试验证结果

API 功能验证 (CUDA Graph 启用):

  1. 模型列表 API:
curl http://localhost:8000/v1/models

输出正常: glm-5-w4a8, max_model_len=202752

  1. 文本生成 API:
curl http://localhost:8000/v1/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "glm-5-w4a8",
    "prompt": "你好,请介绍一下北京。",
    "max_tokens": 100,
    "temperature": 0.7
  }'

输出示例 (流畅中文,无乱码):

北京,位于华北平原,自古便是燕云十六州之一,是重要的军事要塞,具有重要的战略地位。

北京也是五朝帝都,分别为辽陪都、金中都、元大都、明清国都。

1949年10月1日,中华人民共和国成立,北京从此成为新中国的首都,成为全国的政治、经济、交通、文化中心。

北京是一座有着三千多年历史的古都,历史文化底蕴深厚,是全球拥有世界遗产数最多的城市。

✅ 验证结果: 输出质量优秀,语义准确,无乱码或崩溃

3.3.6 启动命令

启用 CUDA Graph (生产环境推荐):

chmod +x deploy_glm5_sglang_with_cudagraph.sh
bash deploy_glm5_sglang_with_cudagraph.sh > glm5_cudagraph.log 2>&1 &
tail -f glm5_cudagraph.log

禁用 CUDA Graph (开发测试):

bash deploy_glm5_sglang_deepep_optimized.sh > glm5_sglang.log 2>&1 &

3.3.7 工作原理

CUDA Graph 是什么?

  • 将一系列 CUDA/NPU 操作预先"录制"为静态执行图
  • 推理时直接"回放"图,无需每次重新调度
  • 特别适合 decode 阶段(token-by-token 生成)

为什么捕获多个 Batch Sizes?

  • 不同请求的并发解码数量不同
  • 捕获常见的 batch sizes (16~256)
  • 匹配预捕获的 batch size → 快速执行 ⚡
  • 不匹配 → 动态执行(正常速度)

GLM-5 MoE 的兼容性:

  • GLM-5 是 MoE (Mixture of Experts) 模型
  • 使用 FULL_DECODE_ONLY 模式仅优化 decode 阶段
  • Prefill 阶段(处理 prompt)仍动态执行
  • MoE 路由在图内通过条件执行实现

3.3.8 部署建议

✅ 推荐启用 CUDA Graph (当前已验证):

  • 生产环境、持续服务
  • 高吞吐需求(需要最大化 QPS)
  • 低延迟要求(每毫秒都重要)
  • Batch size 较为稳定的负载

⭕ 可以禁用 CUDA Graph:

  • 开发测试(快速迭代、频繁重启)
  • 内存受限(需要最大化 KV Cache)
  • 极端动态负载(batch size 变化剧烈)

详细测试报告: 参见 GLM5_CUDAGRAPH_TEST_REPORT.md


四、成功启动的关键注意事项

4.1 ⚠️ 最关键:A2 硬件的 Token 限制

官方 DeepEP-Ascend 规格:

平台Normal ModeLow-Latency Mode
Atlas 800 A2 (910B)最大 8192 tokens/batch128 tokens/batch
Atlas 800 A3最大 65536 tokens/batch128 tokens/batch

必须遵守的参数配置:

--chunked-prefill-size 8192      # 不能超过 8192
--max-prefill-tokens 8192        # 不能超过 8192
--deepep-mode low_latency        # 推理优化模式

❌ 错误配置示例 (导致失败):

--chunked-prefill-size 16384     # 超限 2 倍
--max-prefill-tokens 280000      # 超限 35 倍!
--deepep-mode auto              # 未明确指定

4.2 MoE 后端和 DeepEP 模式选择

必须使用:

--moe-a2a-backend deepep
--deepep-mode low_latency        # ✅ 唯一可用模式

DeepEP 模式对比测试结果

模式配置启动状态推理状态结论
low_latency ✅8192 tokens✅ 成功✅ 正常推荐使用
normal ❌8192 tokens✅ 成功❌ 崩溃不可用
auto ❌8192 tokens✅ 成功❌ 崩溃不可用

测试时间: 2026-03-02 14:05-14:08

normal 模式失败原因:

  • 服务可以正常启动
  • 首次推理时触发 aclnnNotifyDispatchA2 do tiling failed 错误
  • 即使在 8192 token 限制内,normal 模式的算子调度仍然失败
  • 可能是 CANN 8.5.0 对 normal 模式的支持不完整

结论:

  • ✅ 只有 low_latency 模式可用
  • ❌ normal 模式在当前环境(CANN 8.5.0 + 910B2C)下不可用
  • ⚠️ 不建议尝试其他模式

其他 MoE 后端选项的问题:

  • none: 导致 MoE 计算错误,输出乱码
  • ascend_fuseep: CANN 8.5.0 缺少 aclnnFusedDeepMoe 算子

4.3 量化配置

GLM-5-w4a8 专用:

--quantization modelslim

不要使用其他量化方式(如 awq, fp8 等)。

4.4 其他重要参数

--tp-size 16                    # 16 卡张量并行
--mem-fraction-static 0.7       # 静态显存分配 70%
--disable-cuda-graph            # 禁用 CUDA Graph(NPU 不支持)
--skip-server-warmup            # 跳过预热,避免启动时算子错误
--trust-remote-code             # 信任模型代码

五、Token 配置超限导致的问题总结

5.1 问题表现

当 --max-prefill-tokens 或 --chunked-prefill-size 超过 A2 硬件限制(8192)时,会出现以下错误:

错误 1: DeepEP NotifyDispatchA2 Tiling 失败

配置:

--max-prefill-tokens 280000  # 超限 35 倍
--moe-a2a-backend deepep
--deepep-mode auto

错误信息:

RuntimeError: call aclnnNotifyDispatchA2 failed, detail:EZ9999: Inner Error!
EZ9999[PID: 202188] NotifyDispatchA2 do tiling failed, ret is -1.
TraceBack (most recent call last):
   Check NnopbaseExecutorDoTiling(executor) failed
   Check NnopbaseExecutorTilingAndUpdateBinInfo(executor) failed
   Check NnopbaseExecutorMatchCache(executor) failed
   Check NnopbaseRunForWorkspace(*executor, workspaceSize) failed

原因: CANN 算子在 tiling(切分)阶段失败,因为 token 数量远超硬件处理能力。

现象:

  • ✅ 模型加载成功
  • ✅ 服务启动成功
  • ❌ Warmup 或首次推理时崩溃

错误 2: MoE 输出乱码

配置:

--max-prefill-tokens 280000  # 超限
--moe-a2a-backend none       # 禁用 DeepEP

输出示例:

输入: "你好,请用一句话介绍北京"
输出: "变小fratanjzzaanschScreenshot multimEntitiesanis.ct carcteren-flatPerm..."

原因: 没有正确的 MoE All-to-All 通信后端,专家路由和 token 分发完全错误。

现象:

  • ✅ 服务启动成功
  • ✅ 推理完成
  • ❌ 输出内容完全不可用(乱码、无意义字符)

错误 3: FusedDeepMoe 算子缺失

配置:

--moe-a2a-backend ascend_fuseep

错误信息:

RuntimeError: aclnnFusedDeepMoe or aclnnFusedDeepMoeGetWorkspaceSize not in libopapi.so, 
or libopapi.so not found.

原因: CANN 8.5.0 的 libopapi.so 中缺少融合 MoE 算子。

错误 4: DeepEP Normal 模式失败

配置:

--max-prefill-tokens 8192     # ✅ 符合硬件限制
--chunked-prefill-size 8192   # ✅ 符合硬件限制
--moe-a2a-backend deepep
--deepep-mode normal          # ❌ 此模式不可用

错误信息:

RuntimeError: call aclnnNotifyDispatchA2 failed, detail:EZ9999: Inner Error!
EZ9999[PID: 3259124] NotifyDispatchA2 do tiling failed, ret is -1.
   Check NnopbaseExecutorDoTiling(executor) failed

原因:

  • 即使在 8192 token 限制内,normal 模式的算子调度仍然失败
  • CANN 8.5.0 对 normal 模式的支持可能不完整
  • normal 模式的 tiling 策略与 A2 硬件不兼容

现象:

  • ✅ 服务启动成功
  • ✅ 显示 "The server is fired up and ready to roll!"
  • ❌ 首次推理请求时立即崩溃

测试结果 (2026-03-02):

  • low_latency 模式: ✅ 工作正常
  • normal 模式: ❌ 推理失败
  • auto 模式: ❌ 推理失败(自动选择 normal)

解决方案: 必须使用 --deepep-mode low_latency

5.2 问题诊断方法

检查 1: 查看启动日志中的 token 配置

grep "max_prefill_tokens\|chunked_prefill_size" glm5_sglang.log

检查 2: 测试推理输出质量

curl -s http://localhost:8000/v1/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "glm-5-w4a8", "prompt": "北京是中国的", "max_tokens": 20}' \

如果输出是乱码或包含大量英文/符号,说明 MoE 配置有问题。

检查 3: 监控 NPU 显存使用

watch -n 1 npu-smi info

如果服务启动后显存使用异常(过高或过低),可能是配置问题。

5.3 各配置对应的结果对比

配置方案max-prefillMoE 后端DeepEP 模式启动推理输出质量
方案1 ❌280000deepepauto✅❌ 崩溃-
方案2 ❌280000ascend_fuseep-✅❌ 崩溃-
方案3 ❌280000none-✅✅❌ 乱码
方案4 ❌8192deepepnormal✅❌ 崩溃-
方案5 ✅8192deepeplow_latency✅✅✅ 正确

关键发现 (2026-03-02 测试):

  • Token 限制遵守 8192 是必要条件,但不充分
  • 必须同时使用 deepep 后端 + low_latency 模式
  • normal 模式即使符合 token 限制也会失败(tiling 错误)

六、推理测试与验证

6.1 API 测试

测试 1: 检查模型列表

curl http://localhost:8000/v1/models

预期输出:

{
  "object": "list",
  "data": [{
    "id": "glm-5-w4a8",
    "object": "model",
    "owned_by": "sglang",
    "max_model_len": 202752
  }]
}

测试 2: Completions API(推荐)

curl -s http://localhost:8000/v1/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "glm-5-w4a8",
    "prompt": "北京是中国的",
    "max_tokens": 30,
    "temperature": 0.7
  }' 

预期输出 (示例):

{
  "choices": [{
    "text": "首都,人口众多,在这样的大城市里,想要找一份工作是非常不容易的..."
  }]
}

测试 3: Chat Completions API

curl -s http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "glm-5-w4a8",
    "messages": [{"role": "user", "content": "介绍一下人工智能"}],
    "max_tokens": 50
  }'

注意: Chat API 可能触发模型的 reasoning 模式,输出格式可能包含分析过程。

6.2 性能指标

启动时间: 约 120 秒(模型加载)

资源占用:

  • 单卡显存使用: 约 54 GB / 64 GB (84%)
  • KV Cache: 15.47 GB per card
  • 最大 tokens: 151,168 (per device)

首次推理性能 (冷启动):

  • Prefill: 128 tokens, ~15 秒
  • Decode: 0.21 token/s (后续推理会加快)

稳定后性能 (需实测):

  • 取决于批处理大小和并发请求数
  • 建议进行压力测试

七、故障排查

7.1 服务无法启动

问题: 执行脚本后没有输出或立即退出

排查步骤:

# 1. 检查日志
cat glm5_sglang.log

# 2. 检查 CANN 环境
echo $CANN_INSTALL_PATH

# 3. 检查 NPU 状态
npu-smi info

# 4. 检查端口占用
netstat -tulpn | grep 8000

7.2 推理输出乱码

问题: API 返回成功,但内容是乱码

原因: MoE 后端配置错误或 token 限制超标

解决:

# 确认启动参数
ps aux | grep sglang.launch_server

# 检查是否包含
--moe-a2a-backend deepep
--deepep-mode low_latency
--max-prefill-tokens 8192

7.3 运行时崩溃

问题: 服务启动成功,但推理时崩溃

错误日志:

aclnnNotifyDispatchA2 failed
or
aclnnFusedDeepMoe not in libopapi.so

解决: 检查并修正 token 限制配置和 MoE 后端。

7.4 Triton Driver 错误 🆕

问题: 服务启动成功,首次推理时立即崩溃

错误日志:

RuntimeError: 0 active drivers ([]). There should only be one.
File ".../allocator_npu.py", line 63, in alloc_extend
  alloc_extend_kernel[(bs,)](...)

原因: triton 包版本冲突,NPU 后端未正确加载

解决:

  1. 检查安装的 triton 包: pip list | grep triton
  2. 如果同时存在 triton 和 triton-ascend,参见 2.2 步骤 3 解决版本冲突
  3. 卸载 triton,重新安装 triton-ascend
  4. 验证: python3 -c "import triton.backends.ascend"

八、生产环境建议

8.1 资源规划

并发处理能力:

  • 当前配置: --max-running-requests 默认值
  • 根据实际负载调整: 建议 512-1024

批处理优化:

  • 小批量 (<100 tokens): 使用 low_latency 模式
  • 大批量: 可尝试 normal 模式(需测试)

8.2 性能优化选项

CUDA Graph 配置 ⚡

根据生产需求选择是否启用 CUDA Graph:

配置推荐场景性能特点
禁用 CUDA Graph
--disable-cuda-graph
• 开发测试环境
• 频繁重启服务
• 内存受限场景
• 启动快 (无 72秒 capture)
• 内存占用少 (-6.11GB/card)
• 适合动态负载
启用 CUDA Graph
(移除 --disable-cuda-graph)
• 生产环境
• 持续服务
• 高吞吐需求
• 低延迟要求
• 吞吐量 +10-30%
• 延迟 -5-15%
• 稳定性更好
• 启动时间 +72秒

生产环境推荐配置:

# 使用启用 CUDA Graph 的脚本
bash deploy_glm5_sglang_with_cudagraph.sh > glm5_cudagraph.log 2>&1 &

开发测试推荐配置:

# 使用禁用 CUDA Graph 的脚本(默认)
bash deploy_glm5_sglang_deepep_optimized.sh > glm5_sglang.log 2>&1 &

详细性能测试数据参见 GLM5_CUDAGRAPH_TEST_REPORT.md

8.3 监控指标

关键指标:

# NPU 利用率和显存
npu-smi info

# 服务吞吐量
grep "throughput" glm5_sglang.log | tail -20

# 请求延迟
# 在日志中查找 Prefill/Decode 时间

8.4 优化方向

  1. CUDA Graph: 已验证可用,生产环境推荐启用(详见 3.3 节)
  2. 批处理大小: 根据实际 QPS 调整
  3. 温度参数: 推理用 0.1-0.3,创作用 0.7-0.9
  4. 内存优化: 根据负载调整 --mem-fraction-static (0.6-0.8)

九、附录

9.1 相关文件清单

部署脚本:

  • deploy_glm5_sglang_deepep_optimized.sh - 默认配置(CUDA Graph 禁用)
  • deploy_glm5_sglang_with_cudagraph.sh - 性能优化配置(CUDA Graph 启用)

日志文件:

  • glm5_sglang_deepep_optimized.log - 默认配置日志
  • glm5_cudagraph_test.log - CUDA Graph 配置日志

文档:

  • GLM5_SGLANG_FINAL_DEPLOYMENT_GUIDE.md - 本部署指南
  • GLM5_CUDAGRAPH_TEST_REPORT.md - CUDA Graph 详细测试报告
  • GLM5_DEPLOYMENT_VERIFICATION_REPORT.md - 部署验证报告

9.2 参考资料

  • DeepEP-Ascend 官方文档: MoE 通信模式和硬件限制
  • SGLang GitHub: https://github.com/sgl-project/sglang
  • CANN 文档: Ascend NPU 开发指南