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,

稳定性变化 #

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

将上下文长度扩展到 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,
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，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 容器
在正式上线前，请使用长文本及并发请求进行负载测试，以验证稳定性

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