---
title: V100에서 pipeline_parallel=2 크래시 문제 해결
description: "  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로 크래시하는…"
url: "https://bestnetllc.co.jp/ko/docs/v100%ec%97%90%ec%84%9c-pipeline_parallel2-%ed%81%ac%eb%9e%98%ec%8b%9c-%eb%ac%b8%ec%a0%9c-%ed%95%b4%ea%b2%b0/"
updated: "2026-10-17"
category: Tech Blog / GPU·LLM 인프라
---

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

  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,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=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,160 tokens
INFO: Maximum concurrency for 32,768 tokens 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` 옵션과 함께 실행합니다
- 프로덕션 투입 전에 장문 동시 요청으로 부하 테스트를 실시하여 안정성을 확인합니다

## 관련 글

- [GPUStack v2.1.1 멀티노드 추론이 실행되지 않는 문제를 모두 해결한 이야기](https://bestnetllc.co.jp/ko/docs/gpustack-v2-1-1-%eb%a9%80%ed%8b%b0-%eb%85%b8%eb%93%9c-%ec%b6%94%eb%a1%a0%ec%9d%b4-%ec%8b%9c%ec%9e%91%eb%90%98%ec%a7%80-%ec%95%8a%eb%8a%94-%eb%ac%b8%ec%a0%9c%eb%a5%bc-%eb%aa%a8%eb%91%90-%ed%95%b4/)
- [GPUStack을 v0.7.1에서 v2.1.1로 마이그레이션한 이야기](https://bestnetllc.co.jp/ko/docs/gpustack%ec%9d%84-v0-7-1%ec%97%90%ec%84%9c-v2-1-1%eb%a1%9c-%eb%a7%88%ec%9d%b4%ea%b7%b8%eb%a0%88%ec%9d%b4%ec%85%98%ed%95%9c-%ec%9d%b4%ec%95%bc%ea%b8%b0/)

본 글은 실제 환경에서의 트러블슈팅 기록입니다. IP·토큰 등 내부 정보는 추상화되어 있습니다. GPU 환경·드라이버·vLLM 버전에 따라 동작이 다를 수 있습니다.