GPUStack
vLLM
Tesla V100
Multi-Node
GPU クラスタ運用メモ
pipeline_parallel=2 が V100 でクラッシュする問題を解決し
tensor_parallel=4 + 64K コンテキストで安定稼働させるまで #
GPUStack v2.1.1 + vLLM 0.17.1 で Qwen2.5-14B-Instruct をマルチノード(Tesla V100×4枚)で動かしていたところ、チャット送信のたびに _TorchTensorAcceleratorChannel の AttributeError でクラッシュする問題が発生。原因は pipeline_parallel と V100 の非互換にありました。tensor_parallel=4 / pipeline_parallel=1 に変更することで根本解決し、さらにコンテキスト長を 64K まで拡張した記録です。
発生していた症状 #
モデルは正常に起動し、チャットを送信して数分〜数十分後に必ずエンジンが落ちる。ログには以下のエラーが繰り返し記録されていた。
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(compute capability 7.0)では利用できない。
pipeline_parallel=2 の問題 #
- ステージ間アクティベーション転送に P2P GPU チャンネルを使用
- V100 は NVLink/P2P 非対応のため初期化が不完全に終わる
- 推論中またはクリーンアップ時に AttributeError でクラッシュ
- Ray 2.54.0 のバグと絡み合って再現しやすい状況に
tensor_parallel=4 の動作 #
- モデルの重みを 4GPU で水平分割(アテンションヘッド単位)
- GPU 間通信は NCCL の AllReduce のみ使用
- NCCL は V100 でも正常動作(nccl==2.27.5 確認済み)
- P2P チャンネルを一切使わないためバグを完全回避
解決策:設定変更のみで完全解決 #
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 使用量 #
モデルが 4GPU に均等分散されるため、1GPU あたりの消費が大幅に減少。
# 変更前(2GPU で担当)
Model loading took 15-17 GiB / GPU
# 変更後(4GPU で担当)
Model loading took 6.95 GiB / GPUKV キャッシュ #
VRAM の余裕がそのままキャッシュに転換される。
# 変更前
KV cache: 少ない(VRAM が逼迫)
# 変更後
Available KV cache memory: 20.97 GiB
GPU KV cache size: 458,160 tokens安定性の変化 #
変更前はチャット送信のたびにクラッシュが発生していたが、変更後は複数の長文リクエストを同時投入しても落ちないことを確認。同時処理時の生成速度低下はキューによる正常な挙動であり、問題ない。
コンテキスト長 64K への拡張 #
tensor_parallel=4 で VRAM に余裕が生まれたため、コンテキスト長の拡張を試みた。
Qwen2.5-14B のコンテキスト長について #
config.json の max_position_embeddings は 32768 だが、これはデフォルト設定値。YaRN スケーリング(rope_scaling)を有効にすることで 128K まで拡張可能。ただし vLLM ではデフォルトで 32768 超を拒否するため、環境変数で明示的に許可が必要。
Environment Variables に追加:
VLLM_ALLOW_LONG_MAX_MODEL_LEN=1Backend Parameters:
--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 ← 正常起動最終的な安定動作設定まとめ #
Backend Parameters #
--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動作確認結果 #
Qwen2.5-14B-Instruct (float16) が 4×Tesla V100-PCIE-32GB(2ノード構成)で、コンテキスト長 65,536 トークン・高負荷同時リクエスト時も安定稼働を確認。1GPU あたり VRAM 使用量 6.95GiB、KVキャッシュ 20.97GiB 確保。
チェックリスト #
- V100 環境では
--pipeline-parallel-size 1を使用する(pipeline_parallel は P2P GPU 通信を使うため V100 非対応) - マルチノードで 4GPU 使う場合は
--tensor-parallel-size 4に統一する RAY_CGRAPH_get_timeoutは pipeline_parallel=1 なら不要・削除して良い- 64K コンテキストは
VLLM_ALLOW_LONG_MAX_MODEL_LEN=1を Environment Variables に追加する - gpustack-worker コンテナは
--ipc=host --shm-size=64g付きで起動する - 本番投入前に長文・同時リクエストで負荷テストを行い安定性を確認する
関連記事 #
本記事は実環境でのトラブルシューティング記録です。IP・トークン等の内部情報は抽象化しています。GPU 環境・ドライバ・vLLM バージョンにより挙動が異なる場合があります。