---
title: 解决 V100 上 pipeline_parallel=2 崩溃的问题
description: "  Tech Blog GPUStack vLLM Tesla V100 Multi-Node GPU 集群运维备忘录 # 解决 V100 上 pipeline_parallel=2 崩溃的问题， 并通过 tensor_parallel=4 + 64K 上下文实现稳定运行 在使用 GPUStack v2.1.1 + vLLM 0.17.1 于多节点（4× Tesla V100）环境上运行 Qwen2.5-14B-Instruct 时，每次发送聊天消息，引擎都会在 `_TorchTensorAcceleratorChannel` 中崩溃并抛出 AttributeError。根本原因在于 pipeline_parallel 与 V100 不兼容。通过切换为 tensor_parallel=4…"
url: "https://bestnetllc.co.jp/zh-hans/docs/%e8%a7%a3%e5%86%b3-v100-%e4%b8%8a-pipeline_parallel2-%e5%b4%a9%e6%ba%83%e7%9a%84%e9%97%ae%e9%a2%98/"
updated: "2026-10-17"
category: Tech Blog / GPU与LLM基础设施
---

# 解决 V100 上 pipeline_parallel=2 崩溃的问题

  Tech Blog
GPUStack
vLLM
Tesla V100
Multi-Node

GPU 集群运维备忘录

# 解决 V100 上 pipeline_parallel=2 崩溃的问题，
并通过 tensor_parallel=4 + 64K 上下文实现稳定运行

在使用 GPUStack v2.1.1 + vLLM 0.17.1 于多节点（4× Tesla V100）环境上运行 Qwen2.5-14B-Instruct 时，每次发送聊天消息，引擎都会在 `_TorchTensorAcceleratorChannel` 中崩溃并抛出 AttributeError。根本原因在于 pipeline_parallel 与 V100 不兼容。通过切换为 tensor_parallel=4 / pipeline_parallel=1，问题得到彻底解决，并进一步将上下文长度扩展到了 64K。本文记录了这一处理过程。

 AI-GPUST01：GPU-Worker-A / Tesla V100×2  |  AI-GPUST02：GPU-Worker-B / Tesla V100×2  |  GPUStack v2.1.1 / vLLM 0.17.1 / Ray 2.54.0 / CUDA 12.9

## 观察到的现象

模型能够正常启动，但每次发送聊天消息后，引擎总会在几分钟到几十分钟内崩溃。日志中反复出现以下错误。

```
AttributeError: '_TorchTensorAcceleratorChannel' object
has no attribute '_accelerator_group'.
Did you mean: '_accelerator_group_id'?

ray.exceptions.ActorUnavailableError: The actor is temporarily unavailable:
  RpcError: RPC error: Socket closed rpc_code: 14.
```

该错误是**崩溃后清理（teardown）阶段出现的 Ray 2.54.0 缺陷**，并非直接原因。真正的根本原因出在更上游：pipeline_parallel 各阶段之间 GPU 加速器通信通道的初始化失败。

## 根本原因：V100 不支持 pipeline_parallel 所需的 P2P GPU 传输

vLLM 的 pipeline_parallel（流水线并行）在各阶段之间传输激活值时使用 `_TorchTensorAcceleratorChannel`（GPU 间直接 P2P 传输）。这需要 NVLink 或高速 GPU P2P 支持，而 Tesla V100-PCIE（计算能力 7.0）并不具备该能力。

### pipeline_parallel=2 的问题

- 各阶段间的激活值传输使用 P2P GPU 通道
- V100 缺乏 NVLink/P2P 支持，导致初始化无法完整完成
- 在推理过程中或清理阶段抛出 AttributeError 崩溃
- 与 Ray 2.54.0 的缺陷叠加后极易复现

### tensor_parallel=4 的运作方式

- 模型权重按注意力头维度横向切分到 4 块 GPU 上
- GPU 之间的通信仅使用 NCCL AllReduce
- NCCL 在 V100 上运行正常（已确认 nccl==2.27.5 可用）
- 完全不使用 P2P 通道，从而彻底规避该缺陷

   **注意：**该问题为 V100（计算能力 7.0）特有。Ampere 及更新架构（计算能力 8.0 以上）不会出现此问题，因为其 P2P 与 pipeline_parallel 可以正常协同工作。

## 解决方案：仅通过配置变更即可彻底解决

在 GPUStack UI 中按如下方式变更模型配置后，问题得到彻底解决，无需对基础设施做任何改动。

### 变更前（崩溃配置）

```
--tensor-parallel-size 2
--pipeline-parallel-size 2
--distributed-executor-backend ray
--max-model-len 32768
--generation-config vllm
```

### 变更后（稳定配置）

```
--tensor-parallel-size 4
--pipeline-parallel-size 1
--distributed-executor-backend ray
--max-model-len 65536
--generation-config vllm
--enable-auto-tool-choice
--tool-call-parser hermes
```

此外，`RAY_CGRAPH_get_timeout` 是用于设置 pipeline_parallel 各阶段间通信超时的配置项，因此在 pipeline_parallel=1 时已不再需要，可以安全地从环境变量中移除。

## 变更效果对比

### 显存占用

模型被均匀分布到 4 块 GPU 上，每块 GPU 的显存占用大幅降低。

```
# Before change (handled by 2 GPUs)
Model loading took 15-17 GiB / GPU

# After change (handled by 4 GPUs)
Model loading took 6.95 GiB / GPU
```

### KV 缓存

富余的显存直接转化为缓存容量。

```
# Before change
KV cache: Limited (VRAM constrained)

# After change
Available KV cache memory: 20.97 GiB
GPU KV cache size: 458,160 tokens
```

### 稳定性变化

变更前，每次提交聊天请求都会崩溃。变更后确认，**同时提交多个长文本请求也不会引发崩溃**。并发处理时生成速度下降属于正常的排队行为，并非问题。

## 将上下文长度扩展到 64K

由于 tensor_parallel=4 带来了显存余量，我们尝试进一步扩展上下文长度。

### 关于 Qwen2.5-14B 的上下文长度

这里，`max_position_embeddings` 位于 `config.json` 中，默认为 32768，但这只是默认设置值。通过启用 YaRN 缩放（rope_scaling），可以将其扩展到 128K。不过 vLLM 默认会拒绝超过 32768 的取值，因此需要通过环境变量显式放行。

**添加到环境变量：**

```
VLLM_ALLOW_LONG_MAX_MODEL_LEN=1
```

**后端参数：**

```
--max-model-len 65536
```

启动验证：

```
INFO: Using max model len 65536
INFO: Available KV cache memory: 20.97 GiB
INFO: GPU KV cache size: 458,160 tokens
INFO: Maximum concurrency for 32,768 tokens per request: 13.98x
INFO: Starting vLLM API server ← Normal startup
```

  **注意：**超出该范围的 RoPE 位置编码已超出架构设计范围。中短上下文可以正常运行，但在处理超过 32,768 tokens 的超长文本时，存在推理质量下降（出现 nan）的风险。使用时请充分理解这一限制。

## 最终稳定运行配置汇总

### 后端参数

```
--distributed-executor-backend ray
--tensor-parallel-size 4
--pipeline-parallel-size 1
--max-model-len 65536
--generation-config vllm
--enable-auto-tool-choice
--tool-call-parser hermes
```

### 环境变量

```
VLLM_ALLOW_LONG_MAX_MODEL_LEN=1
```

### gpustack-worker 启动选项（附加项）

```
--ipc=host
--shm-size=64g
```

### 运行验证结果

已确认 Qwen2.5-14B-Instruct（float16）在 4× Tesla V100-PCIE-32GB（双节点配置）环境下，能够在上下文长度 65,536 tokens 及高负载并发请求条件下稳定运行。每块 GPU 显存占用 6.95GiB，KV 缓存 20.97GiB 得到保障。

## 检查清单

- 在 V100 环境中，使用 `--pipeline-parallel-size 1`（pipeline_parallel 需要 P2P GPU 通信，而 V100 不支持该功能）
- 在多节点配置中使用 4 块 GPU 时，统一采用 `--tensor-parallel-size 4`
- 在 pipeline_parallel=1 时 `RAY_CGRAPH_get_timeout` 已无必要，可以移除
- 如需 64K 上下文，请添加 `VLLM_ALLOW_LONG_MAX_MODEL_LEN=1` 到环境变量
- 使用 `--ipc=host --shm-size=64g` 选项启动 gpustack-worker 容器
- 在正式上线前，请使用长文本及并发请求进行负载测试，以验证稳定性

## 相关文章

- [彻底解决 GPUStack v2.1.1 多节点推理无法启动的问题](https://bestnetllc.co.jp/zh-hans/docs/gpustack-v2-1-1-%e5%bd%bb%e5%ba%95%e8%a7%a3%e5%86%b3%e5%a4%9a%e8%8a%82%e7%82%b9%e6%8e%a8%e7%90%86%e6%97%a0%e6%b3%95%e5%90%af%e5%8a%a8%e9%97%ae%e9%a2%98%e7%9a%84%e5%85%a8%e8%bf%87%e7%a8%8b/)
- [将 GPUStack 从 v0.7.1 迁移到 v2.1.1](https://bestnetllc.co.jp/zh-hans/docs/gpustack-%e4%bb%8e-v0-7-1-%e8%bf%81%e7%a7%bb%e8%87%b3-v2-1-1-%e7%9a%84%e7%bb%8f%e5%8e%86/)

本文是生产环境中的故障排查记录。IP、令牌等内部信息已作抽象化处理。实际行为可能因 GPU 环境、驱动及 vLLM 版本而异。