기본적으로 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 옵션 없이 동일한 테스트를 수행했으며 다음과 같은 결과를 얻었습니다:

이 테스트에서 계산 버퍼(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에 제출함
[링크] [댓글]