Tech Blog
GPUStack
vLLM
Tesla V100
Multi-Node

GPU क्लस्टर ऑपरेशंस मेमो

V100 पर pipeline_parallel=2 क्रैश समस्या का समाधान, और
tensor_parallel=4 + 64K context के साथ स्थिर ऑपरेशन की उपलब्धि #

GPUStack v2.1.1 + vLLM 0.17.1 के साथ multi-node (4× Tesla V100) पर Qwen2.5-14B-Instruct चलाते समय, जब भी कोई chat message भेजा जाता, engine _TorchTensorAcceleratorChannel में AttributeError के साथ क्रैश हो जाता था। मूल कारण pipeline_parallel और V100 के बीच असंगति थी। tensor_parallel=4 / pipeline_parallel=1 पर स्विच कर के हमने पूर्ण समाधान पाया और context length को 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

देखे गए लक्षण #

मॉडल सामान्य रूप से शुरू होता था, लेकिन chat message भेजने के कुछ मिनट से लेकर दसियों मिनट बाद engine अनिवार्य रूप से क्रैश हो जाता था। नीचे दिए गए errors बार-बार log हो रहे थे।

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.

यह error दरअसल Ray 2.54.0 का वह bug है जो क्रैश के बाद cleanup (teardown) में होता है— प्रत्यक्ष कारण नहीं। असली मूल कारण upstream में है: pipeline_parallel stages के बीच GPU accelerator communication channel की initialization विफलता।

मूल कारण: V100 pipeline_parallel के P2P GPU transfers को सपोर्ट नहीं करता #

vLLM का pipeline_parallel (pipeline parallelism) stages के बीच activation transfer के लिए इस्तेमाल करता है _TorchTensorAcceleratorChannel (GPUs के बीच सीधा P2P transfer)। इसके लिए NVLink या high-speed GPU P2P चाहिए, जो Tesla V100-PCIE (compute capability 7.0) पर उपलब्ध नहीं है।

pipeline_parallel=2 की समस्या #

Stages के बीच activation transfer के लिए P2P GPU channel इस्तेमाल करता है
V100 में NVLink/P2P सपोर्ट नहीं है, इसलिए initialization अधूरी रह जाती है
Inference या cleanup के दौरान AttributeError के साथ क्रैश होता है
Ray 2.54.0 के bug के साथ मिलकर आसानी से reproduce होने लगता है

tensor_parallel=4 ऑपरेशन #

Model weights 4 GPUs में क्षैतिज रूप से विभाजित (attention head के आधार पर)
GPU-से-GPU communication में सिर्फ़ NCCL AllReduce का उपयोग
NCCL V100 पर सामान्य रूप से काम करता है (nccl==2.27.5 पुष्ट)
P2P channels बिल्कुल इस्तेमाल न कर के bug से पूरी तरह बचाव

नोट: यह समस्या V100 (compute 7.0) के लिए विशिष्ट है। Ampere और उसके बाद के GPUs (compute 8.0+) में यह समस्या नहीं होती क्योंकि वहाँ pipeline_parallel के साथ P2P काम करता है।

समाधान: सिर्फ़ configuration बदलकर पूर्ण समाधान #

GPUStack UI में model configuration को नीचे की तरह बदलने से समस्या पूरी तरह हल हो गई। infrastructure में किसी बदलाव की ज़रूरत नहीं पड़ी।

बदलाव से पहले (क्रैश करने वाली configuration) #

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

बदलाव के बाद (स्थिर configuration) #

--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 में stages के बीच communication timeout की setting है, इसलिए pipeline_parallel=1 होने पर यह अनावश्यक हो जाती है। इसे environment variables से सुरक्षित रूप से हटाया जा सकता है।

बदलावों के प्रभाव की तुलना #

VRAM उपयोग #

Model 4 GPUs में समान रूप से वितरित हुआ, जिससे प्रति 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 Cache #

VRAM की बचत सीधे cache में बदल जाती है।

# Before change
KV cache: Limited (VRAM constrained)

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

स्थिरता में बदलाव #

बदलाव से पहले हर chat भेजने पर क्रैश होता था। बदलाव के बाद पुष्टि हुई कि एक साथ भेजे गए कई long-text requests से भी क्रैश नहीं होता। concurrent processing के दौरान generation speed का घटना सामान्य queuing व्यवहार है और कोई समस्या नहीं।

Context length को 64K तक बढ़ाना #

tensor_parallel=4 से VRAM में गुंजाइश मिलने पर हमने context length बढ़ाने की कोशिश की।

Qwen2.5-14B की context length के बारे में #

डिफ़ॉल्ट रूप से max_position_embeddings की वैल्यू, जो config.json में है, 32768 है — पर यह सिर्फ़ default setting है। YaRN scaling (rope_scaling) enable कर के इसे 128K तक बढ़ाया जा सकता है। हालाँकि vLLM डिफ़ॉल्ट रूप से 32768 से अधिक values reject कर देता है, इसलिए environment variable से स्पष्ट अनुमति देना ज़रूरी है।

Environment Variables में जोड़ें:

VLLM_ALLOW_LONG_MAX_MODEL_LEN=1

Backend Parameters:

--max-model-len 65536

Startup सत्यापन:

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 positional encoding आर्किटेक्चर की डिज़ाइन सीमा से बाहर चला जाता है। छोटे से मध्यम contexts बिना समस्या चलते हैं, लेकिन 32, से आगे के अति-लंबे text को handle करते समय inference गुणवत्ता घटने (nan आने) का जोखिम है। इस सीमा को समझते हुए उपयोग करें।

अंतिम स्थिर ऑपरेशन configuration का सारांश #

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

Environment Variables #

VLLM_ALLOW_LONG_MAX_MODEL_LEN=1

gpustack-worker के startup options (अतिरिक्त) #

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

ऑपरेशन सत्यापन परिणाम #

Qwen2.5-14B-Instruct (float16) की 4× Tesla V100-PCIE-32GB (2-node configuration) पर context length 65, और high-load concurrent requests के साथ स्थिर रूप से चलने की पुष्टि हुई। प्रति GPU 6.95GiB VRAM उपयोग और 20.97GiB KV cache सुरक्षित।

चेकलिस्ट #

V100 environments में इस्तेमाल करें --pipeline-parallel-size 1 (pipeline_parallel P2P GPU communication इस्तेमाल करता है, जिसे V100 सपोर्ट नहीं करता)
Multi-node configuration में 4 GPUs इस्तेमाल करते समय एकीकृत रखें: --tensor-parallel-size 4
RAY_CGRAPH_get_timeout pipeline_parallel=1 के साथ अनावश्यक है और हटाया जा सकता है
64K context के लिए VLLM_ALLOW_LONG_MAX_MODEL_LEN=1 को Environment Variables में जोड़ें
gpustack-worker container को --ipc=host --shm-size=64g options के साथ शुरू करें
Production में लगाने से पहले long text और concurrent requests के साथ load testing कर के स्थिरता सत्यापित करें

V100 पर pipeline_parallel=2 क्रैश समस्या का समाधान