메인 콘텐츠로 건너뛰기
모든 로컬 모델은 가중치, KV 캐시 및 일부 작업 오버헤드를 보유할 만큼 충분한 메모리가 필요하며, VRAM에 완전히 적합하지 않을 경우 오프로드는 GPU에서 빠르게 실행할 부분과 CPU에서 느리게 실행할 부분을 결정합니다. 이 페이지에서는 크기 계산 이론과 오프로드 메커니즘을 다룹니다. GPU 및 모델 크기별 준비된 VRAM 표는 GPU 모델 적합 가이드를 참조하십시오 — 이 페이지에서는 해당 표를 반복하지 않습니다.

​
크기 계산 공식

모델 가중치는 정밀도에 따라 매개변수당 고정된 바이트 수를 차지합니다: GGUF Q4_K_M은 혼합 정밀도이며, K-quants가 서로 다른 텐서에 서로 다른 비트 폭을 할당하기 때문에 평평한 0.5–0.56가 아닌 매개변수당 약 0.5 바이트로 평균화됩니다 — 해당 이름 읽는 방법은 양자화를 참조하십시오. 매개변수 수에 매개변수당 바이트 수를 곱하여 원시 가중치 크기를 구한 후, modest한 컨텍스트 길이에서 KV 캐시, 활성화 및 프레임워크 오버헤드를 위해 약 20%를 추가합니다:
Hugging Face는 15B+ 모델에서 이 패턴을 직접 측정했습니다: 29 GB에서 약 bf16, 8-bit에서 ~15 GB, 4-bit에서 ~9.5 GB — Hugging Face의 LLM 최적화 가이드를 참조하십시오. 더 긴 컨텍스트는 이 1.2× 기준 위에 더 많은 KV 캐시를 추가합니다 — 왜 그런 방식으로 확장되는지는 KV 캐시 및 컨텍스트를 참조하십시오.
이 공식은 가중치 크기에 대한 계획 추정치이며 절대적인 기준이 아닙니다. 실제 수치는 실행하려는 정확한 양자화에 대한 실제 GGUF 파일 크기와 목표 컨텍스트 길이에 대한 KV 캐시의 합입니다. 계산된 예제와 대화식 추정기는 GPU 모델 적합 가이드를 참조하십시오.

​
실제로 메모리를 경쟁하는 요소들

세 가지 요소가 동일한 VRAM(또는 통합 메모리) 풀을 공유합니다:
  • 모델 가중치 — 모델이 로드되면 고정되며, 프롬프트 길이에 영향을 받지 않습니다.
  • KV 캐시 — 컨텍스트 길이와 배치 크기에 따라 증가합니다; KV 캐시 및 컨텍스트를 참조하십시오.
  • 활성화 및 프레임워크 오버헤드 — 각 순전파 동안 필요한 더 작은 작업 메모리로, 위의 공식에서 1.2× 계수가 대략적으로 설명하는 부분입니다.
가중치는 가장 크고 예측 가능한 비용입니다. KV 캐시는 컨텍스트가 커질 때까지 보이지 않기 때문에 놀라움을 줄 수 있는 부분입니다.

​
오프로드: 모델이 완전히 적합하지 않을 때

모델의 가중치가 GPU의 VRAM에 완전히 적합하지 않다면, llama.cpp과 같은 백엔드는 실패하는 대신 모델을 GPU와 CPU 사이에 분할할 수 있습니다. 이는 --n-gpu-layers(짧은 형태 -ngl) 플래그로 제어됩니다: 이 플래그는 모델의 레이어 중 GPU에 로드될 레이어 수를 설정하며, 나머지는 시스템 RAM에 유지됩니다.
  • 전체 오프로드 (-ngl을 모든 레이어를 커버할 만큼 높게 설정): 전체 모델이 GPU에서 전체 GPU 속도로 실행됩니다.
  • 부분 오프로드: 일부 레이어는 GPU에서 실행되고, 나머지는 시스템 RAM을 사용하여 CPU에서 실행됩니다. 이는 VRAM보다 큰 모델이 실제로 로드되고 실행되도록 하지만, 비용이 발생합니다.
  • 오프로드 없음 (-ngl 0): 전체 모델이 CPU에서만 실행됩니다.
부분 오프로드의 비용은 속도이지 정확성이 아닙니다 — 출력은 어느 쪽이든 동일합니다. CPU 측 레이어와 시스템 RAM은 GPU VRAM보다 메모리 대역폭이 훨씬 낮으며, 추론 작동 방식에서 상기하듯 디코딩은 메모리 대역폭에 제한됩니다: 생성된 모든 토큰은 관련 레이어를 읽어야 하므로, 더 느린 메모리에 있는 레이어는 각 단계마다 병목 현상이 됩니다. GPU에서 밀어내는 레이어가 많을수록 생성 속도가 느려지며 — 모델이 RAM에서 디스크로 넘칠 때 특히 극적으로 느려질 수 있습니다.
모델이 RAM에 머무르는 대신 디스크(스왑)로 넘치면 심각한 속도 저하를 예상하십시오 — 디스크 대역폭은 RAM은 물론 VRAM보다 여러 단계 느립니다. 디스크 넘침을 모델이 더 작거나 더 공격적인 양자화를 선택해야 한다는 신호로 취급하고, 이를 관통하여 실행하려는 것으로 간주하지 마십시오.
백엔드에 대한 정확한 플래그 이름과 동작은 llama.cpp 저장소에서 찾으십시오; 다른 백엔드(LM Studio, Ollama)는 내부적으로 llama.cpp를 기반으로 하는 자체 설정을 통해 동일한 아이디어를 노출합니다.

​
통합 메모리가 그림을 어떻게 바꾸는지

특정 통합 메모리 시스템 — Apple Silicon과 AMD의 Strix Halo 플랫폼 — 에서는 CPU와 GPU가 GPU의 자체 작고 분리된 VRAM 대신 단일 메모리 풀을 공유합니다. 이는 오프로드 계산을 변경합니다:
  • 용량: 통합 메모리 시스템은 고정된 VRAM을 가진 이산 GPU보다 훨씬 큰 모델을 로드할 수 있습니다. “VRAM” 풀은 그래픽 사용에 할당된 부분을 제외하고 기계의 총 RAM만큼 클 수 있기 때문입니다.
  • 대역폭: 동일한 풀은 이산 GPU의 전용 GDDR 메모리보다 낮은 대역폭으로 실행됩니다. 통합 메모리에 완전히 맞는 모델도 이산 GPU의 VRAM에 완전히 맞는 동일한 모델보다 더 느리게 디코딩됩니다. 디코딩 속도는 용량이 아닌 대역폭을 따르기 때문입니다.
실제로 통합 메모리는 “도대체 맞는지”라는 트레이드오프를 “맞았을 때 얼마나 빠르게 실행되는지”로 이동시킵니다 — 오프로드를 처음부터 강제로 만드는 용량 문제를 해결하지만, 그 대가로 GDDR급 대역폭을 제공하지는 않습니다. 특정 통합 메모리 시스템이 이산 GPU와 어떻게 비교되는지는 GPU 모델 적합 가이드를 참조하십시오.

​
더 깊이 알아보기

추론 작동 방식

디코딩이 처음부터 메모리 대역폭에 제한되는 이유입니다.

KV 캐시 및 컨텍스트

모델뿐만 아니라 대화에 따라 증가하는 메모리 사용량 부분입니다.

양자화

크기 계산 공식의 가장 큰 입력을 변경하기 위해 매개변수당 바이트를 줄입니다.

GPU 모델 적합 가이드

VRAM 표, 대화식 추정기 및 일반 하드웨어에 맞는 모델입니다.

​
적합하고 실행된 후

크기 계산과 오프로드는 모델이 GPU 전체 또는 CPU와 분할되어 하드웨어에서 실행되도록 합니다. localhost에서 요청에 응답하는 단계가 완료되면, 다음 단계는 다른 곳에서 이를 도달하는 것입니다.

안정적인 엔드포인트 제공

Tokios는 모델을 선택, 호스팅 또는 파인튜닝하지 않습니다 — 로컬에서 실행되면, Tokios는 어디서나 호출할 수 있는 안정적이고 인증된 엔드포인트로 변환합니다.