llama.cpp에서 SWA 모델의 VRAM 사용량을 3배 줄이는 최적화 방법

커뮤니티 반응

작성자의 구체적인 수치 제시와 해결책에 대해 긍정적인 반응이며, 특히 저사양 GPU 사용자들 사이에서 실질적인 도움이 된다는 평가이다.

주요 논점

01찬성다수

단일 사용자 환경에서는 병렬 슬롯을 최소화하는 것이 VRAM 효율성 확보를 위한 가장 효과적인 방법이다.

합의점 vs 논쟁점

합의점

SWA 모델의 VRAM 문제는 양자화보다 병렬 슬롯 수(-np)와 배치 크기(-ub) 설정에 더 큰 영향을 받는다.
최신 llama.cpp 빌드를 사용하는 것이 버그로 인한 추가 메모리 누수를 방지하는 기본 전제이다.

실용적 조언

단일 채팅 용도로 사용한다면 실행 명령어에 반드시 `-np 1`을 포함하세요.
VRAM이 부족하다면 속도 향상을 위한 `-ub 4096` 설정을 지양하고 기본값 512를 사용하세요.
31B급 모델을 16GB GPU에서 쓰려면 IQ3 또는 Q3_K 양자화와 함께 mmproj 로드를 최소화하세요.

섹션별 상세

SWA KV 캐시의 VRAM 점유 문제로 인해 모델 생성 전부터 대량의 메모리가 소모된다. SWA 캐시는 일반 KV 캐시와 달리 F16 정밀도로 고정 할당되며 양자화가 적용되지 않아 16GB VRAM 환경에서 빈번한 OOM을 유발한다. 최근 llama.cpp의 특정 업데이트가 이 문제를 악화시켰으나 현재는 수정되었으므로 최신 빌드 사용이 필수적이다.

병렬 시퀀스 설정인 `-np` 옵션이 SWA 캐시 크기에 직접적인 영향을 미친다. SWA 캐시 크기는 슬라이딩 윈도우 크기에 병렬 슬롯 수를 곱한 값에 비례하므로, 기본값인 4개 슬롯을 사용하면 단일 사용자 환경에서도 불필요하게 3배의 메모리를 소모한다. 26B 모델 기준 `-np 1` 설정 시 SWA 캐시가 900MB에서 300MB로 줄어들며, 31B 모델은 3.2GB에서 1.2GB로 즉각적인 절감 효과가 나타났다.

bash

./llama-cli -m gemma-4-31b.gguf -np 1 -ub 512

단일 사용자 환경에서 SWA 캐시 VRAM을 최적화하여 실행하는 명령어 예시

마이크로 배치 크기인 `-ub` 값을 과도하게 높게 설정하는 행위가 VRAM 팽창의 원인이 된다. 속도 향상을 위해 배치 크기를 4096 등으로 설정하면 SWA 버퍼가 비대해져 전체 메모리 가용성을 압박하게 된다. 16GB 환경에서 31B 모델을 구동하려면 `-ub` 값을 기본값인 512로 유지하고, 필요시 비전 모델(mmproj) 비중을 줄여야 30K 이상의 컨텍스트를 확보할 수 있다.

용어 해설

슬라이딩 윈도우 어텐션(SWA): — 고정된 크기의 윈도우 내 토큰들만 참조하여 계산 복잡도를 줄이는 어텐션 기법이다. 전체 문맥 대신 최근 토큰들만 처리하여 메모리 효율을 높이지만, llama.cpp와 같은 특정 구현체에서는 캐시 할당 방식에 따라 VRAM 점유가 커질 수 있다.
키-값 캐시(KV Cache): — 이전 추론 단계의 계산 결과를 저장하여 다음 토큰 생성 시 중복 계산을 방지하는 기술이다. 모델의 컨텍스트 길이가 길어질수록 VRAM 점유율이 높아지며, 추론 속도 유지에 핵심적인 역할을 한다.
마이크로 배치 크기(Ubatch Size): — 추론 시 한 번에 처리하는 데이터의 최소 단위이다. 크기를 키우면 처리 속도가 빨라질 수 있으나, SWA 모델에서는 버퍼 크기를 비대하게 만들어 VRAM 부족(OOM)을 유발하는 원인이 되기도 한다.
메모리 부족(OOM): — Out of Memory의 약자로, 시스템이나 GPU에 할당된 메모리 용량을 초과하여 프로그램이 강제 종료되는 현상이다. LLM 구동 시 모델 가중치나 KV 캐시가 GPU 메모리보다 클 때 발생한다.

언급된 도구

llama.cpp추천링크

LLM 추론 및 서빙 엔진

언급된 리소스

GitHubllama.cpp SWA 캐시 관련 수정 PR