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에 균등하게 분산되어 GPU당 소비량이 대폭 감소합니다.
# 변경 전 (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,안정성의 변화 #
변경 전에는 채팅 전송 때마다 크래시가 발생했으나, 변경 후에는 여러 개의 긴 텍스트 요청을 동시에 전송해도 중단되지 않는것을 확인. 동시 처리 시 생성 속도 저하는 큐에 의한 정상적인 동작이므로 문제없음.
컨텍스트 길이 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,
INFO: Maximum concurrency for 32, 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 토큰 고부하 동시 요청 시에도 안정적 작동을 확인했습니다. GPU당 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 버전에 따라 동작이 다를 수 있습니다.