V100에서 pipeline_parallel=2 크래시 문제 해결

V100에서 pipeline_parallel=2 크래시 문제 해결

3 min read

 
Tech Blog
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까지 확장한 기록입니다.

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(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 채널을 전혀 사용하지 않아 버그를 완전히 회피
주의: 이 문제는 V100(compute 7.0) 고유의 문제입니다. Ampere 이후(compute 8.0+)에서는 pipeline_parallel에서도 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 / GPU

KV 캐시 #

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.jsonmax_position_embeddings는 32768이지만, 이것은 기본 설정값. YaRN 스케일링(rope_scaling)을 활성화함으로써 128K까지 확장 가능. 단, vLLM에서는 기본적으로 32768 초과를 거부하므로 환경 변수로 명시적으로 허용이 필요.

Environment Variables에 추가:

VLLM_ALLOW_LONG_MAX_MODEL_LEN=1

Backend 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 ← 정상 시작
주의:RoPE의 위치 인코딩은 32768을 초과하면 아키텍처상 설계 범위를 벗어납니다. 짧거나 중간 길이의 컨텍스트에서는 문제없이 작동하지만, 32768 토큰을 초과하는 초장문을 처리할 경우 추론 품질 저하(nan 발생) 가능성이 있음을 이해하고 사용하시기 바랍니다.

최종 안정 동작 설정 요약 #

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 시작 옵션(추가) #

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

동작 확인 결과 #

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 버전에 따라 동작이 다를 수 있습니다.

Updated on 2026年6月9日

What are your feelings

  • Happy
  • Normal
  • Sad