---
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 不相容。透過切換為…"
url: "https://bestnetllc.co.jp/zh-hant/docs/%e8%a7%a3%e6%b1%ba-v100-%e4%b8%8a-pipeline_parallel2-%e7%95%b6%e6%a9%9f%e5%95%8f%e9%a1%8c/"
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.
```

此錯誤是 **Ray 2.54.0 在當機後清理（teardown）階段出現的 bug**，並非直接原因。真正的根本原因出在更上游：pipeline_parallel 各階段之間 GPU 加速器通訊通道的初始化失敗。

## 根本原因：V100 不支援 pipeline_parallel 的 P2P GPU 傳輸

vLLM 的 pipeline_parallel（管線平行）在各階段之間傳輸 activation 時，使用 `_TorchTensorAcceleratorChannel`（GPU 之間的直接 P2P 傳輸）。這需要 NVLink 或高速 GPU P2P，而 Tesla V100-PCIE（計算能力 7.0）並不具備。

### pipeline_parallel=2 的問題

- 階段間的 activation 傳輸使用 P2P GPU 通道
- V100 缺乏 NVLink/P2P 支援，導致初始化不完整而終止
- 在推論或清理過程中拋出 AttributeError 而當機
- 與 Ray 2.54.0 的 bug 疊加後極易重現

### tensor_parallel=4 的運作方式

- 模型權重橫向切分至 4 張 GPU（以注意力頭為單位）
- GPU 間通訊僅使用 NCCL AllReduce
- NCCL 在 V100 上運作正常（已確認 nccl==2.27.5）
- 完全不使用 P2P 通道，因而徹底避開此 bug

   **備註：**此問題僅限於 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 時已無必要，可以安全地從環境變數中移除。

## 變更效果比較

### VRAM 使用量

模型平均分散至 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 快取

多出的 VRAM 空間直接轉化為快取容量。

```
# 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 帶來了 VRAM 餘裕，我們嘗試延伸上下文長度。

### 關於 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 VRAM，並確保 20.97GiB 的 KV 快取。

## 檢查清單

- 在 V100 環境中，使用 `--pipeline-parallel-size 1`（pipeline_parallel 使用 P2P GPU 通訊，V100 並不支援）
- 在多節點配置中使用 4 張 GPU 時，統一設為 `--tensor-parallel-size 4`
- `RAY_CGRAPH_get_timeout` 在 pipeline_parallel=1 時已無必要，可以移除
- 若要使用 64K 上下文，請在環境變數中加入 `VLLM_ALLOW_LONG_MAX_MODEL_LEN=1`
- 以 `--ipc=host --shm-size=64g` 選項啟動 gpustack-worker 容器
- 正式上線前，請以長文本與並行請求進行負載測試，以驗證穩定性

## 相關文章

- [GPUStack v2.1.1 多節點推論無法啟動問題完全解決](https://bestnetllc.co.jp/zh-hant/docs/gpustack-v2-1-1-%e5%be%b9%e5%ba%95%e8%a7%a3%e6%b1%ba%e5%a4%9a%e7%af%80%e9%bb%9e%e6%8e%a8%e8%ab%96%e7%84%a1%e6%b3%95%e5%95%9f%e5%8b%95%e7%9a%84%e6%89%80%e6%9c%89%e5%95%8f%e9%a1%8c/)
- [將 GPUStack 從 v0.7.1 遷移至 v2.1.1](https://bestnetllc.co.jp/zh-hant/docs/%e5%be%9e-gpustack-v0-7-1-%e9%81%b7%e7%a7%bb%e8%87%b3-v2-1-1-%e7%9a%84%e7%b6%93%e9%a9%97%e5%88%86%e4%ba%ab/)

本文為正式環境中的疑難排解紀錄。IP、Token 等內部資訊已做抽象化處理。實際行為可能因 GPU 環境、驅動程式與 vLLM 版本而異。