서빙 메모리 폭주, 이 가지 복구 전략으로 해결한다
LMStudio GGUF 서빙 시 OOM을 해결하려면 --n-gpu-layers 35와 KV-cache 크기 2048 토큰 제한을 적용하여 메모리 소비를 9~10GB로 낮추고 초당 12~15토큰 추론 속도를 회복하세요. 맥미니 M2 16GB 환경에서는 Q4_K_M 7B 단일 모델 서빙이 최적 구성이며, 추가 메모리 여유가 필요하면 --ctx-size 2048로 컨텍스트 창을 단축하거나 Q3_K_S 양자화를 고려하세요.
이 글의 핵심 주장과 근거
LMStudio GGUF 서빙의 세 가지 OOM 패턴
LMStudio에서 GGUF 모델을 서빙할 때 발생하는 메모리 폭주는 크게 세 단계에서 명확히 관찰된다. 첫 번째는 모델 로드 단계로, FP32 정밀도의 7B 파라미터 가중치가 약 28GB의 RAM을 요구하는데 16GB 램을 가진 맥미니 M2 환경에서는 로드 즉시 OOM이 발생한다. 두 번째는 KV-cache 할당 단계로, 13B 모델을 8K 컨텍스트 길이로 설정하면 추론 시작 전에 이미 약 10GB의 메모리가 추가로 소모된다. 세 번째는 inference 피크 단계로, 실제 토큰 생성 중 스왑이 발생하고 토큰 생성 속도가 급격히 떨어지는 현상이 관찰된다. 이 세 단계는 각각 독립적으로도 OOM을 유발할 수 있으며, 특히 첫 단계와 두 번째 단계가 연쇄적으로 발생하면 시스템이 완전히 응답 불가능 상태에 빠진다.
GPU 레이어 오프로딩과 KV-cache 제한의 효과
메모리 폭주를 해결하는 가장 효과적인 전략은 --n-gpu-layers 35 옵션을 적용하여 가능한 많은 레이어를 GPU에 할당하는 것이다. 동시에 KV-cache 크기를 2048 토큰으로 제한하면 불필요한 메모리 할당을 방지할 수 있다. 이 두 가지 설정을 조합하면 전체 메모리 소비를 약 9~10GB 수준으로 낮출 수 있으며, 추론 속도는 초당 12~15토큰 수준으로 안정적으로 회복된다. 맥미니 M2 환경에서는 GPU 가속이 제한적이므로 --n-gpu-layers는 시스템 구성에 따라 적정 값으로 조절해야 하지만, CPU 오프로딩과 결합하면 16GB RAM 환경에서도 충분히 실용적인 성능을 확보할 수 있다. 이는 대부분의 바이브코딩 시나리오에서 충분한 성능이며, 코딩 보조 도구로 활용하기에 지연 시간이 수용 가능한 수준이다.
컨텍스트 창 단축과 양자화 전략의 트레이드오프
더 극단적인 메모리 절감이 필요할 때는 컨텍스트 창을 --ctx-size 2048 토큰으로 단축하는 방법이 있다. 이렇게 하면 KV-cache 소비를 0.5~1GB 수준으로 크게 줄일 수 있어 대부분의 로컬 개발 시나리오에서 품질 저하 없이 안정적인 서빙이 가능하다. 또한 Q4_K_M 양자화 수준을 Q3_K_S로 낮추고 배치 크기를 1로 제한하면 13B 모델도 8K 컨텍스트에서 반복하던 OOM 문제를 해결할 수 있다. 다만 이는 품질과 메모리 사이의 명확한 트레이드오프를 감수해야 한다. 맥미니 M2 16GB RAM 환경에서는 Q4_K_M 7B 단일 모델 서빙이 OOM 위험을 최소화하는 최적 구성이며, 두 개 이상의 모델을 동시에 서빙하면 여유 메모리가 2GB 이하로 하락하여 스트리밍 출력 시 OOM이 거의 반드시 발생한다. > 이 주제의 전체 맥락 방향성은 **8. 나는 더 이상 예전 방식으로 일하지 않는다.** 원본 글에 세밀하게 정리되어 있습니다. 더 깊게 탐구하고 싶다면 관련 내부 대표 문서(Pillar/Entity)를 참조하세요.