GLM-5 PP=3 推理卡死问题
环境
- 4 节点, 每节点 8 张 C500 (64GB), 共 32 卡
- MACA 3.5.3, vLLM-MetaX 0.14.0 镜像 (
vllm-metax:0.14.0-maca.ai3.5.3.102-torch2.8-py310-ubuntu22.04-amd64_glm_w4a8_full) - 模型: GLM-5-W8A8, PP=3 TP=8, 3 节点 24 卡
- Ray 分布式, MCCL 跨节点通信
问题
PP=3 TP=8 部署启动正常 (模型加载、KV cache、API server 全部成功), 但发送推理请求后:
- 前 10 秒有少量输出 (prompt throughput 1.1 tok/s)
- 之后 throughput 降为 0, 请求卡死不返回
- 300 秒后超时报
RayChannelTimeoutError
用 --enforce-eager 禁用 CUDA graph 后仍然卡死, 排除 CUDA graph 问题。
关键对比: PP=2 全部正常
我们测试了所有节点对的 PP=2 推理:
| 节点对 | PP=2 推理 |
|--------|----------|
| 节点0 ↔ 节点1 | ✅ 正常 |
| 节点0 ↔ 节点3 | ✅ 正常 |
| 节点1 ↔ 节点3 | ✅ 正常 |
| 节点2 ↔ 节点3 | ✅ 正常 |
| PP=3 任意 3 节点 | ❌ 卡死 |
所有节点两两 PP=2 通信正常, 只有 3 节点 PP=3 时卡死。
另一个问题
PP=2 只有 16 卡, KV cache 不够, 最大只能支持 ~62k 上下文。尝试 --kv-cache-dtype fp8_e5m2 来减少 KV cache 内存占用, 但 FLASHMLA_SPARSE 不支持 FP8 KV cache:
FLASHMLA_SPARSE: [kv_cache_dtype not supported]
如果支持 FP8 KV cache, PP=2 就能到 ~124k, 不需要 PP=3。
请求
- 排查 PP=3 推理卡死问题, 怀疑 MCCL 3 节点通信组场景
- 评估 FLASHMLA_SPARSE 支持 FP8 KV cache 的可行性
