llama.cpp의 파이프라인 병렬화 (Pipeline parallelism)가 VRAM을 낭비하고 있을 수 있습니다

기본적으로 llama.cpp는 추론 속도를 높이기 위해 파이프라인 병렬화 (Pipeline parallelism)를 활성화합니다. 제 테스트 결과, 파이프라인 병렬화는 속도 이점이 없으며 상당한 VRAM 비용을 초래한다는 것을 발견했습니다.

이 비용은 llama.cpp를 -DGGML_SCHED_MAX_COPIES=1 옵션으로 컴파일함으로써 피할 수 있습니다. 이 옵션은 파이프라인 병렬화가 활성화되었을 때 llama.cpp가 훨씬 더 큰 연산 버퍼 (compute buffer)를 할당하는 것을 방지합니다.

파이프라인 병렬화는 --split-mode layer가 사용될 때(기본값) 그리고 모든 모델 레이어와 모든 연산이 GPU로 오프로드 (offloaded)될 때 활성화됩니다. 기본 옵션으로 컴파일된 경우, llama.cpp는 파이프라인 병렬화가 활성화되었을 때 하나의 스케줄 복사본 (sched copy) 대신 네 개의 스케줄 복사본을 할당합니다. 스케줄 복사본이 정확히 무엇인지는 모르겠지만, VRAM 내 연산 버퍼 크기에 크게 기여하는 요소입니다. 네 개의 복사본은 특히 컨텍스트 캐시 양자화 (context cache quantization)가 사용될 때 훨씬 더 많은 VRAM을 소비합니다.

적어도 제 설정에서는 이 네 개의 스케줄 복사본을 할당하는 것이 VRAM의 완전한 낭비라는 것을 확인하기 위해 많은 테스트를 수행했습니다. 속도 향상은 전혀 없었습니다.

수정: 여러 사용자가 댓글을 통해 병렬 요청 (parallel requests)을 제출할 때는 파이프라인 병렬화가 유익하다고 지적했습니다. 저는 그 부분은 테스트하지 않았습니다. 만약 병렬 요청을 자주 제출한다면, 직접 테스트하여 속도 향상이 VRAM 비용을 감수할 가치가 있는지 확인해 보시기 바랍니다.

이 테스트를 위해 저는 모두 Vulkan 백엔드를 사용하는 세 가지 버전의 llama.cpp 빌드를 비교했습니다. 첫 번째 빌드는 기본 옵션인 GGML_SCHED_MAX_COPIES=4를 사용했습니다. 두 번째는 GGML_SCHED_MAX_COPIES=1을 사용했습니다. 세 번째는 GGML_BLAS=ON GGML_BLAS_VENDOR=OpenBLAS를 사용했는데, 우연히도 이 설정이 파이프라인 병렬화를 비활성화한다는 것을 발견했습니다.

세 가지 빌드 각각에서 실행한 llama.cpp 명령어는 다음과 같습니다:
./llama-server -m models/Qwen3.6-27B-MTP/Qwen3.6-27B-UD-Q5_K_XL.gguf \ --verbosity 4 \ --no-op-offload \ -fa on \ --mlock \ -ngl 999 \ --temp 0.6 --top-k 20 --top-p 0.95 --presence-penalty 0.0 \ --cache-type-k f16 --cache-type-v q8_0 \ --host 0.0.0.0

세 번의 테스트 후 수집한 데이터는 다음과 같습니다:

설정 | 테스트 | 입력 토큰 (Input tokens) | 입력 t/s (Input t/s) | 출력 토큰 (Output tokens) | 출력 t/s (Output t/s) | 연산 GPU1 (MB) (Compute GPU1 (MB)) | 연산 GPU2 (MB) (Compute GPU2 (MB)) | 연산 호스트 (MB) (Compute Host (MB)) | 컨텍스트 크기 (토큰) (Context size (tokens))

4개의 스케줄러 복사본을 사용한 파이프라인 병렬화 (Pipeline parallelism with 4 sched copies) | 1 | 30564 | 362.66 | 3524 | 17.24 | 1022 | 910 | 364 | 88832
4개의 스케줄러 복사본을 사용한 파이프라인 병렬화 (Pipeline parallelism with 4 sched copies) | 2 | 30564 | 362.61 | 4072 | 17.24 | 1023 | 913 | 367 | 88832
4개의 스케줄러 복사본을 사용한 파이프라인 병렬화 (Pipeline parallelism with 4 sched copies) | 3 | 30564 | 362.86 | 4475 | 17.24 | 1022 | 912 | 366 | 88576
1개의 스케줄러 복사본을 사용한 파이프라인 병렬화 (Pipeline parallelism with 1 sched copy) | 1 | 30564 | 362.99 | 4100 | 17.26 | 242 | 242 | 130 | 113408
1개의 스케줄러 복사본을 사용한 파이프라인 병렬화 (Pipeline parallelism with 1 sched copy) | 2 | 30564 | 362.61 | 4055 | 17.26 | 243 | 243 | 131 | 113920
1개의 스케줄러 복사본을 사용한 파이프라인 병렬화 (Pipeline parallelism with 1 sched copy) | 3 | 30564 | 362.40 | 4062 | 17.27 | 243 | 243 | 131 | 113920
파이프라인 병렬화 없음 (No pipeline parallelism) | 1 | 30564 | 362.88 | 3482 | 17.28 | 242 | 242 | 130 | 113408
파이프라인 병렬화 없음 (No pipeline parallelism) | 2 | 30564 | 362.93 | 3969 | 17.26 | 243 | 243 | 131 | 113920
파이프라인 병렬화 없음 (No pipeline parallelism) | 3 | 30564 | 363.01 | 4001 | 17.26 | 243 | 243 | 131 | 113920

보시다시피, 추론 속도 (inference speed)는 모든 설정에서 사실상 동일했습니다. 하지만 llama.cpp의 기본 설정인 4개의 스케줄러 복사본을 사용하는 파이프라인 병렬화 (pipeline parallelism)의 경우 연산 버퍼 (compute buffer) 크기가 훨씬 더 컸습니다. 저의 특정 모델과 설정에서는 다른 설정들에 비해 1.5 GB의 VRAM을 추가로 소모했습니다.
연산 버퍼 팽창 (compute buffer bloat) 현상은 컨텍스트 캐시 양자화 (context cache quantization)를 사용할 때 훨씬 더 심해지는 것으로 보입니다.

저는 --cache-type-k f16 --cache-type-v q8_0 옵션 없이 동일한 테스트를 수행했으며 다음과 같은 결과를 얻었습니다:

설정	입력 토큰	입력 t/s	출력 토큰	출력 t/s	계산 GPU1 (MB)	계산 GPU2 (MB)	계산 호스트 (MB)	컨텍스트 크기 (토큰)
파이프라인 병렬화 (4 sched 복사본 사용)	30564	333.77	4614	17.07	481	481	327	78592
파이프라인 병렬화 (1 sched 복사본 사용)	30564	333.66	4073	17.08	219	219	105	87552
파이프라인 병렬화 없음	30564	333.71	4058	17.08	219	219	105	87552

이 테스트에서 계산 버퍼(compute buffer)는 파이프라인 병렬화와 4개의 sched 복사본을 사용할 때 '단지' 약 0.5 GB 더 커졌습니다.
4개의 sched 복사본과 컨텍스트 양자화가 결합된 계산 버퍼 블랏(bloat) 현상은 캐시를 양자화하여 얻는 VRAM 절감 효과를 부분적으로 상쇄할 만큼 심각합니다!
물론, 이 모든 발견은 제 컴퓨터와 llama.cpp 설정에 국한됩니다. 여러분의 결과는 다를 수 있습니다.
제 시스템에 대한 더 자세한 정보는 다음과 같습니다:

컴포넌트 세부 정보

CPU Intel Core i5-13600K
GPU 1 AMD Radeon RX 6800 XT (16GB)
GPU 2 AMD Radeon RX 6700 XT (12GB)
시스템 RAM 2x16GB DDR5-3200
운영 체제 Kubuntu 26.04 HWE

/u/Warrenio 님이 r/LocalLLaMA에 제출함
[링크] [댓글]