使用两台服务器、每台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见附件
