能否给下mp的参数
vllm serve /mnt/data/models/ --tensor-parallel-size 8 --pipeline-parallel-size 2 --nnodes 2 --node-rank 0 --master-addr 192.168.100.231 --master-port 29500 --gpu-memory-utilization 0.85 --max-model-len 8192 --max-num-batched-tokens 4096 --trust-remote-code --tool-call-parser kimi_k2 --reasoning-parser kimi_k2 --mm-encoder-tp-mode data

从节点

vllm serve /mnt/data/models/ --tensor-parallel-size 8 --pipeline-parallel-size 2 --nnodes 2 --node-rank 1 --master-addr 192.168.100.231 --master-port 29500 --gpu-memory-utilization 0.85 --max-model-len 8192 --max-num-batched-tokens 4096 --trust-remote-code --tool-call-parser kimi_k2 --reasoning-parser kimi_k2 --mm-encoder-tp-mode data --headless

对否？

使用两台服务器、每台8张沐曦 C500，通过 vLLM + Ray 双机部署 DeepSeek-R1-0528。

模型可以正常启动并提供推理服务，但连续运行一段时间后，正在执行的请求停止生成 Token。等待约300秒后，vLLM报 RayChannelTimeoutError，随后 node2 的 Raylet 在 experimental_mutable_object_provider.cc:154 触发致命断言并退出，最终导致整个模型服务不可用。

历史上该问题曾在运行数小时后出现；本次完整采集的复现中，Ray Session 大约在15:27启动，16:32发生故障，约运行64分钟后复现。

二、软硬件环境

服务器与GPU
服务器数量：2台
每台GPU数量：8张
GPU型号：MetaX C500
单卡显存：65536 MiB
总GPU数量：16张
cpu:海光7390*2

本次采集时，两台服务器均能正常识别8张GPU。GPU拓扑为每4张卡通过 MetaXLink 互联，两个四卡组之间跨NUMA/CPU互联。

系统和驱动
Kernel：
4.19.90-52.23.v2207.gfb08.ky10.x86_64

MX-SMI：
2.2.12

Kernel Mode Driver：
3.6.17

MACA：
3.5.3.18
驱动和MACA版本来自 node1 的 mx-smi 输出。

3. 推理软件版本

Ray：2.53.0
vLLM：0.14.0
PyTorch：2.8.0+metax3.5.3.9
Python：3.10

两台节点容器内的软件版本一致。

三、模型部署配置

运行时日志中确认的主要配置如下：

模型：
/mnt/data/models/DeepSeek-R1-0528

dtype：
torch.bfloat16

quantization：
compressed-tensors

max_seq_len：
32768

tensor_parallel_size：
8

pipeline_parallel_size：
2

data_parallel_size：
1

disable_custom_all_reduce：
True

enable_prefix_caching：
True

enable_chunked_prefill：
True

enforce_eager：
False

Compilation Mode：
VLLM_COMPILE

CUDAGraph Mode：
FULL_AND_PIECEWISE

即单机内部采用 TP=8，两台机器采用 PP=2，共使用16张GPU。运行过程中启用了 vLLM Compile、CUDAGraph 和 Ray Compiled DAG 相关执行路径。

四、网络配置

Ray、Gloo 和 Socket 通信使用：

网卡：p5p1

node1：
192.168.1.204

node2：
192.168.1.205

当前速率：
1000Mb/s Full Duplex

MTU：
1500

故障后两台机器之间 Ping 正常，丢包率为0%，往返延迟约0.1ms。node1 到 node2 的路由明确经过 p5p1。

MCCL日志显示跨节点通信使用：

NET/IB
GDRDMA

故障清理阶段出现了到 192.168.101.24 的 MCCL Socket 连接异常。

五、问题现象及完整时间线

1. 16:27左右模型停止产生Token

故障前生成速度正常：

16:26:31  generation throughput：50.3 tokens/s
16:26:41  generation throughput：51.2 tokens/s
16:26:51  generation throughput：50.3 tokens/s
16:27:01  generation throughput：51.0 tokens/s

随后吞吐快速下降：

16:27:11
Avg generation throughput：10.5 tokens/s
Running：2
Waiting：0

16:27:21
Avg generation throughput：0.0 tokens/s
Running：2
Waiting：0
GPU KV cache usage：0.6%

当时仍显示有两个请求正在运行，没有等待请求，但已经不再生成Token。

2. 16:32:03触发 RayChannelTimeout

停止生成约5分钟后，EngineCore报错：

ray.exceptions.RayChannelTimeoutError:
System error: Timed out waiting for object available to read.

ObjectID:
004fc8a14e43c330d8a5ea50e2389bc5b2cba1de0100000002e1f505

随后日志提示：

If the execution is expected to take a long time,
increase RAY_CGRAPH_get_timeout which is currently 300 seconds.

Otherwise, this may indicate that the execution is hanging.

调用栈位于：

ray/dag/compiled_dag_node.py
ray/experimental/channel/common.py
ray/experimental/channel/shared_memory_channel.py
ray._raylet.CoreWorker.get_objects

说明 EngineCore 在 Ray Compiled DAG/Shared Memory Channel 中等待执行结果超过300秒。

3. vLLM开始关闭 Ray Distributed Executor

超时后立即出现：

Shutting down Ray distributed executor
Tearing down compiled DAG
Cancelling compiled worker
Waiting for worker tasks to exit

API请求开始返回：

HTTP/1.1 500 Internal Server Error
EngineDeadError

4. 16:32:03.673出现 Socket closed

在清理 Compiled DAG 和取消 Worker 时，RayWorkerWrapper报错：

raylet_client.cc:202:
Error pushing mutable object:
RpcError: RPC error: Socket closed
rpc_code: 14

5. 16:32:04.443，node2 Raylet触发致命断言

发生故障的 Raylet 位于：

ip=192.168.1.205

即 node2。

完整关键错误：

experimental_mutable_object_provider.cc:154:

An unexpected system state has occurred.
You have likely discovered a bug in Ray.

Check failed:
object_manager_->WriteAcquire(
    info.local_object_id,
    total_data_size,
    nullptr,
    total_metadata_size,
    info.num_readers,
    object_backing_store
)

Status not OK:
ChannelError: Channel closed.

调用栈关键位置：

ray::core::experimental::MutableObjectProvider::HandlePushMutableObject
ray::raylet::NodeManager::HandlePushMutableObject
ray::rpc::ServerCallImpl<>::HandleRequestImpl

该错误触发 Raylet异常退出。

6. 16:32:05出现MCCL连接中断

Raylet异常后，node1上的MCCL日志出现：

MCCL WARN socketProgressOpt:
Call to recv from 192.168.101.24 failed:
Connection reset by peer

后续还有：

MCCL WARN socketStartConnect:
Connect to 192.168.101.24 failed:
Software caused connection abort

这些MCCL错误发生在 RayChannelTimeout 和 node2 Raylet异常之后，因此目前判断更像是进程退出和通信清理产生的后续报错。

7. 16:32:18，Head节点将node2标记为死亡

node1的 GCS Server记录：

Node is dead because the health check failed.

death reason：
UNEXPECTED_TERMINATION

death message：
health check failed due to missing too many heartbeats

node_name：
192.168.1.205

随后大量Actor报：

Node with actor is already dead
Disconnected: GRPC client is shut down

六、内存和共享内存情况

两台服务器物理内存均为1TiB。

node2故障后采集结果：

物理内存总量：1.0TiB
可用内存：995GiB
Swap使用量：0

容器内存使用：
317.1GiB / 1006GiB

Docker Memory Limit：
0，未限制

Docker OOMKilled：
false

Docker ExitCode：
0

容器 ShmSize：
107374182400 bytes，约100GiB

node1容器状态同样为：

Container state：running
OOMKilled：false
ExitCode：0
Memory limit：0
ShmSize：107374182400

Ray Object Store配置约为：

object_store_memory：
约102GB

plasma_directory：
/dev/shm

故障后两台宿主机最近12小时均未发现明确的 Linux OOM Killer记录。

因此目前基本排除：

宿主机物理内存不足
Docker内存限制触发
容器被OOM Kill
/dev/shm容量不足
磁盘空间不足

七、p5p1网卡异常情况

虽然本次16:32故障附近没有新的Link Down记录，但 p5p1 确实存在历史链路不稳定问题。

node1在最近12小时记录到8次Link Down，其中几次恢复后只协商到100Mbps：

09:42:11 Link Down
09:42:14 Link Up 100 Mbps

09:43:03 Link Down
09:45:22 Link Up 100 Mbps

09:47:56 Link Down
09:47:59 Link Up 100 Mbps

之后恢复到1000Mbps。

模型本轮启动前最近一次为：

15:21:51 Link Down
15:21:54 Link Up 1000 Mbps

node2也记录到：

15:20:59 Link Down
15:21:03 Link Up 1000 Mbps

但本次模型停止生成发生在16:27，Ray报错发生在16:32，因此现有时间线不能证明本次故障由 p5p1 Link Down 直接触发。

八、当前初步判断

目前可以确认的故障链路为：

模型正在运行
    ↓
某个Ray Worker、GPU Rank、MCCL执行或Compiled DAG执行静默卡住
    ↓
连续约300秒没有产生可读取的Object
    ↓
RayChannelTimeoutError
    ↓
vLLM关闭Ray Distributed Executor
    ↓
Compiled DAG开始teardown并关闭Channel
    ↓
Worker继续push mutable object
    ↓
Socket closed rpc_code=14
    ↓
node2 Raylet在WriteAcquire时遇到Channel closed
    ↓
experimental_mutable_object_provider.cc触发CHECK failed
    ↓
node2 Raylet异常退出
    ↓
GCS将node2标记为dead
    ↓
整个vLLM服务down

目前尚不能确定最初300秒卡住的底层原因是：
1. Ray 2.53.0 Compiled DAG / Mutable Object Channel自身问题；
2. vLLM 0.14.0与当前Ray版本的兼容性问题；
3. 某个MetaX GPU Worker或GPU Rank静默卡死；
4. MCCL/RDMA Collective静默阻塞；

九、希望沐曦官方协助确认的问题

烦请官方协助确认以下问题：

vLLM 0.14.0 + Ray 2.53.0 + torch 2.8.0+metax3.5.3.9 是否为当前推荐和验证过的版本组合？
当前版本中，Ray Compiled DAG、Shared Memory Channel和Mutable Object Channel是否存在已知稳定性问题？
以下Raylet错误是否属于已知问题？
experimental_mutable_object_provider.cc:154
WriteAcquire(...)
ChannelError: Channel closed
在vLLM已经开始 teardown 后，Raylet收到 PushMutableObject 并直接触发 CHECK failed，是否可能是 Ray Compiled DAG teardown过程中的竞态问题？
是否有官方推荐的 Ray、vLLM、MACA、驱动版本组合，可以规避该问题？
如何进一步定位是哪个GPU Rank、MCCL Collective或Ray Worker在16:27左右首先卡住？是否有推荐的MCCL超时、异步错误检测或Worker Watchdog环境变量？
RAY_CGRAPH_get_timeout=300 是否建议调整？本次只有两个运行请求、KV Cache使用率仅约0.6%，但执行完全停止，因此暂时认为单纯增大超时时间只能延迟失败，无法解决底层卡死。

log见附件

lishuai

从节点