背景概述

在基于昇腾（Ascend）硬件平台的AI推理场景中，高效部署大语言模型已成为关键需求。本文针对使用SGLang框架在Atlas 800I A2双机环境下部署DeepSeek-V3.2-W8A8（W8A8量化）模型时，出现服务拉起过程中“Capturing batches”阶段卡死的问题，结合实际排查过程，系统性地梳理了问题根因与解决方案，为类似场景提供可复用的优化路径。

问题现象

在使用SGLang 0.5.9.rc1版本部署DeepSeek-V3.2-W8A8模型时，启动服务进入Capturing batches图捕获阶段后，系统完全无响应，进程卡死。进一步观察发现，操作系统整体响应迟滞，无法执行任何操作，初步判断为底层资源或通信异常所致。

排查过程与分析

1. 环境与基础通信验证

为排除环境问题，首先使用vLLM框架进行对比验证。在相同硬件与网络环境下，vLLM可正常拉起服务并响应curl请求，说明系统环境、驱动、网络及硬件本身无异常。

随后，通过克隆sgl-kernel-npu（https://github.com/sgl-project/sgl-kernel-npu）仓库，根据(https://github.com/sgl-project/sgl-kernel-npu/blob/main/python/deep_ep/A2_DEEPEP_CN.md )，运行deepep的A2双机单算子测试脚本，验证了DeepEP通信链路正常，各节点间算子通信无阻塞，确认单算子通信功能正常。

2. 图模式与MTP功能冲突分析

尝试关闭图模式（--disable-cuda-graph）后重启服务，发现模型加载阶段出现权重文件相关报错。经确认，该模型权重未启用MTP（Multi-Token Prediction）量化，但启动命令中仍配置了MTP相关参数，导致运行时异常。

尝试以下命令

#启动命令中删除如下MTP相关配置
--speculative-algorithm NEXTN \
--speculative-num-steps 2 \
--speculative-eagle-topk 1 \
--speculative-num-draft-tokens 3

#取消环境变量设置
#export SGLANG_ENABLE_OVERLAP_PLAN_STREAM=1
#export SGLANG_ENABLE_SPEC_V2=1

3. 图模式重启与资源瓶颈暴露

重新启用图模式（--cuda-graph-bs 4 8）后，服务不再卡在图捕获阶段，但在预热（warm up）阶段出现如下错误：

RuntimeError: call aclnnDispatchNormalA2 failed

连续报错提示“tiling失败”及“NnopbaseRunForWorkspace验证失败”，初步判断为工作空间内存不足。

4. HCCL_BUFFSIZE与Ant-moving Function调优

进一步检查发现，HCCL_BUFFSIZE默认值为800，可能不足以支撑长序列场景下的集体通信缓冲需求。同时，环境变量中启用了Ant-moving Function（用于优化长序列预填充阶段的通信缓冲），其对HCCL_BUFFSIZE的计算公式有显著影响。

#使能ant-moving function，指示每个Rank上传输的轮次，默认为1轮 
export DEEPEP_NORMAL_LONG_SEQ_ROUND=8
#使能ant-moving function，指示每个Rank每轮传输的token数量，默认为8192个token
export DEEPEP_NORMAL_LONG_SEQ_PER_ROUND_TOKENS=512

Ant-moving Function启用时，HCCL_BUFFSIZE需满足：

HCCL_BUFFSIZE >= 2 * (102MB + 4MB + DEEPEP_NORMAL_LONG_SEQ_PER_ROUND_TOKENS * (hidden_size + hidden_size + hidden_size) * topk) + PADDING_BUFFSIZE

而禁用时则为：

HCCL_BUFFSIZE >= 2 * (102MB + 4MB + TOTAL_SEQ_LEN * (hidden_size + hidden_size) * topk) + PADDING_BUFFSIZE

为降低内存压力，尝试将`HCCL_BUFFSIZE`从800提升至1500，并**禁用Ant-moving Function**，即：

export HCCL_BUFFSIZE=1500
# export DEEPEP_NORMAL_LONG_SEQ_ROUND=8
# export DEEPEP_NORMAL_LONG_SEQ_PER_ROUND_TOKENS=512

重启服务后，问题彻底解决，服务可正常拉起，curl请求响应稳定，推理流程完整无阻。

问题根因总结

1. MTP功能与模型量化不匹配：模型权重未启用MTP量化，但启动命令中启用了MTP相关参数，导致运行时异常。

2. 工作空间内存配置不足：HCCL_BUFFSIZE设置过小，无法满足长序列场景下的集体通信缓冲需求，尤其在启用Ant-moving Function时，内存需求进一步放大。

解决措施

为确保服务稳定部署，建议按以下配置进行调整：

1. 禁用MTP相关功能（若模型未量化）

# 移除MTP参数
--speculative-algorithm NEXTN \
--speculative-num-steps 2 \
--speculative-eagle-topk 1 \
--speculative-num-draft-tokens 3

# 禁用相关环境变量
# export SGLANG_ENABLE_OVERLAP_PLAN_STREAM=1
# export SGLANG_ENABLE_SPEC_V2=1

2. 调整HCCL_BUFFSIZE并禁用Ant-moving Function

export HCCL_BUFFSIZE=1500
# 禁用Ant-moving Function以降低内存需求
# export DEEPEP_NORMAL_LONG_SEQ_ROUND=8
# export DEEPEP_NORMAL_LONG_SEQ_PER_ROUND_TOKENS=512

✅ 提示：若需启用Ant-moving Function以优化长序列性能，应根据实际序列长度与模型参数，重新计算并设置HCCL_BUFFSIZE，确保其满足通信缓冲需求。

总结

本案例表明，在部署大模型推理服务时，需综合考虑模型量化方式、推理框架功能配置与底层通信资源之间的匹配性。对于未启用MTP量化的模型，应避免启用MTP相关功能；同时，合理配置HCCL_BUFFSIZE是保障双机通信与图模式稳定运行的关键。通过精准调整配置参数，可有效规避因资源不足或功能冲突导致的服务卡死问题，提升部署成功率与推理稳定性。