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,

穩定性變化 #

變更前，每次送出聊天訊息都會當機。變更後，確認同時送出多個長文本請求也不會導致當機。並行處理時生成速度下降屬於正常的排隊行為，並非問題。

將上下文長度延伸至 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,
INFO: Maximum concurrency for 32, per request: 13.98x
INFO: Starting vLLM API server ← Normal startup

備註：RoPE 位置編碼超出此範圍即已超過架構設計的上限。中短長度的上下文可正常運作，但在處理超過 32, 的超長文本時，存在推論品質下降（出現 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 與高負載並行請求下皆能穩定運作。每張 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 容器
正式上線前，請以長文本與並行請求進行負載測試，以驗證穩定性

解決 V100 上 pipeline_parallel=2 當機問題