VRAM 계산기

속도는 단일 스트림 디코딩을 위한 대역폭 기반 추정치이며 벤치마크가 아닙니다. 프롬프트 처리는 연산 기반이므로 다르게 동작합니다.

3단계 분석 읽는 법

인터넷상의 거의 모든 "들어갈까?"에 대한 논쟁은 사실 세 가지 숫자 중 무엇을 잊었는지에 대한 것입니다. 모델 카드에 적힌 다운로드 크기가 그중 하나입니다. 나머지 두 개는 모델이 로드되어 답변을 시작할 때만 존재하며, 바로 그때 메모리 부족 문제가 발생합니다.

Llama 3.1 8B, Q4_K_M, 8K 컨텍스트, 단일 요청, F16 cache 환경을 예로 들어보겠습니다. 이는 가장 일반적인 로컬 설정이며, 그 구성 요소는 다음과 같습니다:

weights  = 8.03e9 params x 4.85 bits / 8      = 4.87e9 bytes = 4.53 GB
kv       = 2 x 32 layers x 8 kv-heads x 128 dim
           x 8192 tokens x 2 bytes             = 1.07e9 bytes = 1.00 GB
overhead = 0.65 + 0.08 x (4.53 + 1.00)                        = 1.09 GB
                                                                -------
total                                                            6.63 GB

가중치는 유일하게 조회 가능한 부분입니다. 이는 순수 산술 계산으로, 파라미터 수에 가중치당 비트를 곱하고 8로 나눈 값입니다. 작업 부하에 따라 변하지 않습니다. 나머지 두 숫자를 고려하지 않으면 4비트 8B 모델이 4.5 GB를 차지하여 6 GB 카드에 충분히 들어갈 것이라고 결론 내리겠지만, 실제로는 그렇지 않습니다.

KV cache는 변하는 부분입니다. 컨텍스트의 모든 토큰은 레이어마다 키와 값 벡터를 저장하여 모델이 재계산 없이 과거를 참조할 수 있게 합니다. 이것이 생성을 빠르게 만드는 이유이며 cache가 필수적인 이유입니다. 이는 컨텍스트 및 동시 요청 수에 비례하며, 파라미터 수가 아닌 attention 레이아웃에 의해 결정됩니다. 여기서는 1024 토큰당 정확히 0.125 GB를 차지하는데, Llama 3.1이 32개의 쿼리 헤드에 8개의 키-값 헤드를 사용하기 때문에 작게 유지됩니다.

런타임 오버헤드는 아무도 예산에 넣지 않지만 누구나 겪는 부분입니다. 컴파일된 커널, CUDA 또는 Metal 컨텍스트, 활성화 및 로짓 버퍼, 블록을 완벽하게 채울 수 없는 할당자, 샘플러 작업 세트가 포함됩니다. 이 계산기는 이를 고정 0.65 GB와 나머지 전체의 8%로 모델링합니다. 이는 의도적인 근사치이지만, 오버헤드는 작은 모델에서 사라지지 않고 큰 모델에서 일정하게 유지되지 않는다는 점을 정확히 반영합니다.

단위 관련 참고 사항입니다. 이 페이지의 모든 GB는 1024의 3제곱으로 나누어 계산되므로 기술적으로는 gibibyte입니다. 이는 GPU 드라이버가 보고하는 단위와 동일하며, 24 GB로 판매되는 카드가 약 24564 MiB로 표시되는 이유입니다. Hugging Face의 모델 파일은 보통 십진수 기가바이트로 표시되므로 5.0 GB 다운로드는 여기에서 약 4.65 GB로 나타납니다. 약 7%의 차이가 발생하며, 이는 사용자에게 유리하게 작용합니다.

Quantization 레벨 선택

Quantization은 각 가중치를 더 적은 비트로 저장합니다. BF16으로 출시된 모델은 파라미터당 2바이트를 사용하지만, 4비트 quantization은 반 바이트 조금 넘게 사용합니다. 모델의 다른 부분은 변하지 않으므로, quantization은 모델 수용 여부를 결정하는 가장 큰 요소입니다.

이 계산기에서 제공하는 모든 레벨의 Llama 3.3 70B 모델 예시입니다. 가중치는 디스크상의 파일 크기이며, 나머지 두 열은 F16 cache를 사용한 단일 스트림에서의 cache와 오버헤드를 포함한 전체 로드된 메모리 점유율입니다.

이 표에서 주목할 만한 세 가지가 있습니다. 첫째, 명목상 비트 수는 사용자에게 유리할 수도, 불리할 수도 있는 거짓 정보입니다. K-quant 형식은 손상이 가장 큰 attention 및 embedding 텐서를 더 높은 정밀도로 유지하기 때문에 Q4_K_M은 가중치당 4비트가 아닌 4.85비트입니다. Q2_K도 같은 이유로 평균 3.35비트입니다. 모델 크기를 파라미터 수에 4/8을 곱해 계산하면 약 5분의 1 정도 과소평가하게 됩니다.

둘째, 비트 수를 낮출수록 성능 향상 폭이 급격히 줄어듭니다. BF16에서 Q8_0으로 가면 모델 크기가 절반으로 줄지만 측정 가능한 손실은 없습니다. Q8_0에서 Q4_K_M으로 가면 다시 거의 절반으로 줄어들며, 일반적인 사용 환경에서는 대부분 사람이 감지할 수 없는 품질 저하만 발생합니다. Q4_K_M에서 Q3_K_M으로 가면 7.8 GB를 절약하지만 지시 이행 능력 저하, 코드 품질 약화, 산술 오류 증가가 나타나기 시작합니다. 그 이하로 내려가면 체감할 수 있을 정도로 성능을 용량과 맞바꾸게 됩니다.

셋째, 과도한 quantisation으로 인한 손상은 모델 크기에 따라 균등하게 나타나지 않습니다. 70B 모델은 Q2_K에서도 사용할 수 있는데, 이는 제거할 수 있는 중복성이 매우 크기 때문입니다. 반면 3B 모델은 Q2_K에서 종종 깨진 출력을 생성합니다. 실무에서 검증된 경험칙은 다음과 같습니다. 약 4비트까지는 낮은 quantisation의 더 큰 모델을 선호하고, 그 이하에서는 4비트 이상의 더 작은 모델을 선호하십시오. 대부분의 작업에서 Q4_K_M의 70B 모델이 Q8_0의 32B 모델보다 우수하지만, IQ2_XXS의 70B 모델은 보통 그렇지 않습니다.

알아두어야 할 특별한 사례가 있습니다. 일부 모델은 사후 quantisation 방식이 아니라 처음부터 저비트 형식으로 출시됩니다. gpt-oss는 가중치당 4.25비트인 MXFP4로 제공되며, 학습 과정에서 이를 고려했기 때문에 BF16 모델을 4비트로 압축한 것과는 품질을 비교할 수 없습니다. 이것이 계산기에서 MXFP4를 실제로 해당 형식으로 출시된 모델에만 제공하는 이유이며, 117B 모델이 전체 정밀도에서 250 GB가 필요한 것과 달리 gpt-oss 120B가 63.4 GB인 이유입니다.

context length가 하드웨어 결정 사항인 이유

사람들은 context length를 기능 플래그처럼 취급하여 모델 카드에 128K라고 적혀 있으면 128K로 설정합니다. 하지만 이는 기능 플래그가 아니라 메모리 할당이며, 일부 아키텍처에서는 예산에서 가장 큰 비중을 차지하는 항목입니다. 여기 Q4_K_M, 단일 스트림, F16 cache 환경에서 4가지 context length에 따른 총 로드 용량을 보여주는 4개 모델이 있습니다.

Llama 3.1 8B는 2K에서 128K 사이에서 크기가 5.8 GB에서 22.8 GB로 4배 증가하는데, 이는 거의 모든 환경에서 실행 가능한 것과 24 GB 카드에 들어가지 않는 것의 차이입니다. Command R 35B는 극단적인 사례입니다. 2K에서는 Qwen3 32B보다 작게 시작하지만 128K에서는 거의 4배 더 커집니다. 64개의 key-value head를 사용하는 전체 multi-head attention을 사용하며 1024 token당 1.25 GB의 cache를 소모하기 때문입니다. Gemma 3 27B는 거의 변화가 없는데, 6개 레이어 중 5개가 1024 token 윈도우에만 attention을 수행하므로 거의 즉시 성장이 멈추기 때문입니다.

실질적인 결과는 설정하는 context length가 모델이 지원하는 최대치가 아니라 실제로 사용하는 길이여야 한다는 것입니다. 프롬프트가 3000 token이고 답변이 800 token이라면 32K로 설정하는 것은 더 나은 quantisation에 사용할 수 있는 메모리를 낭비하는 것입니다. 24 GB 카드에서 Q4_K_M의 Llama 3.1 8B는 64K context는 수용할 수 있지만 128K는 불가능합니다. 128K는 22.8 GB가 필요한데 디스플레이와 드라이버가 점유한 후에는 약 22.3 GB만 남기 때문입니다. cache를 Q8로 낮추면 가능해집니다. 다른 것은 바꿀 필요가 없습니다.

어떤 runtime을 사용하는지도 중요합니다. llama.cpp는 전달된 context 크기만큼만 cache를 할당하므로 작은 context를 사용하면 메모리가 실제로 반환됩니다. 반면 vLLM은 카드 메모리의 일부를 미리 점유하고 내부적으로 paged pool을 관리하므로, 무엇을 설정하든 nvidia-smi에서는 카드가 거의 꽉 찬 것으로 표시됩니다. 이 계산기가 제공하는 수치는 필요한 working set이며, 이는 llama.cpp의 동작 방식과 vLLM이 할당해야 하는 pool에 직접적으로 대응됩니다.

cache는 크기가 아닌 아키텍처에 의해 결정됩니다

KV cache에 대해 가장 유용한 사실은 파라미터 수로는 이를 거의 예측할 수 없다는 점입니다. 이를 결정하는 요소는 모델이 유지하는 key-value head의 수, 각 head의 너비, 레이어 수, 그리고 특수한 기법 적용 여부입니다. 파라미터 수가 3자릿수 차이가 나는 모델들에 대한 1024 token당 cache 비용을 확인하십시오.

맨 위와 맨 아래 행을 함께 보십시오. 671B 모델이 35B 모델보다 cache가 작고, 3.8B 모델이 27B 모델보다 cache가 4.5배 큽니다. Phi-3.5 mini는 128K context에서 총 54.8 GB가 필요한데, 그중 가중치는 2.2 GB에 불과합니다. 사람들이 작다고 말하는 모델이 32B 모델보다 더 많은 메모리를 필요로 하는 경우입니다.

4가지 메커니즘으로 이 표 전체를 설명할 수 있습니다. Grouped-query attention은 여러 query head가 하나의 key-value head를 공유하며, 이는 현재 업계 표준으로 보통 cache를 4~8배 줄여줍니다. Sliding-window attention은 대부분의 레이어에 고정된 윈도우를 제공하여 cache가 그 이상 커지지 않게 하며, 이것이 Gemma 3와 gpt-oss의 cache가 평탄해지는 이유입니다. DeepSeek에서 사용하는 Multi-head latent attention은 key와 value를 전체 저장하는 대신 레이어당 token 하나를 576개 요소 벡터로 압축합니다. Command R이나 Phi-3.5 같은 구형 모델에서 여전히 사용하는 일반적인 multi-head attention은 이러한 기법을 사용하지 않아 모든 head에 대한 비용을 지불합니다.

이 논의의 상세 버전과 유도 과정이 궁금하다면 다음에서 별도로 확인할 수 있습니다. 파라미터 수가 VRAM 예측에 부적합한 이유.

KV cache quantisation이 가치 있는 경우

cache도 가중치처럼 quantisation할 수 있습니다. F16은 요소당 2바이트를 사용하지만, Q8 옵션은 평균 1.06바이트, Q4는 0.56바이트를 사용하며 오버헤드는 블록별 스케일에서 발생합니다. 모든 주요 runtime이 이를 지원합니다. llama.cpp는 cache-type-k 및 cache-type-v로, vLLM은 kv-cache-dtype 플래그로 이를 제공합니다.

문제는 메모리가 절약되는지 여부가 아닙니다. 절약된 양이 유의미한지 여부이며, 이는 전체 footprint에서 cache가 차지하는 비중이 얼마나 되는지에 달려 있습니다. Q4_K_M 가중치와 32K context 환경에서:

Command R은 플래그 하나로 20.3 GB를 확보하는데, 이는 48 GB 카드 2장이 필요한 상황과 1장으로 충분한 상황의 차이입니다. Llama 3.3 70B는 이미 grouped-query attention으로 cache가 작아져서 동일한 플래그로 5.1 GB를 확보합니다. 이 패턴은 일반적으로 적용됩니다. KV quantisation은 긴 context의 multi-head 모델에서는 혁신적이지만, 짧은 context의 grouped-query 모델에서는 효과가 미미합니다. 적용하기 전에 위 분석의 KV cache 부분을 확인하십시오. 해당 막대가 매우 얇다면 이 플래그는 도움이 되지 않습니다.

비용은 실재하지만 제한적입니다. Q8 cache는 품질 측면에서 거의 공짜나 다름없으므로 긴 context 작업 시 기본적으로 활성화할 가치가 있습니다. Q4 cache는 긴 context의 핵심인 입력 데이터 깊숙이 숨겨진 특정 사실에 대한 정확한 회상을 저해합니다. 요약이나 일반적인 대화는 잘 견디지만, 긴 문서 검색, needle-in-haystack 조회, 다중 파일 코드 추론은 그렇지 않습니다. 또한 알아두어야 할 비대칭성이 있는데, key가 value보다 quantisation에 더 민감하다는 점입니다. 따라서 runtime에서 각각 설정할 수 있다면 Q8 key cache와 Q4 value cache 조합이 둘 다 Q4인 것보다 보통 더 좋습니다.

실패하지 않는 규칙은 가중치를 먼저 quantize하고 cache를 나중에 하는 것입니다. 거의 모든 경우에 Q4_K_M 가중치와 F16 cache 조합이 동일한 총 크기의 Q6_K 가중치와 Q4 cache 조합보다 우수합니다. 가중치 quantisation이 cache quantisation보다 훨씬 더 철저하게 연구되고 튜닝되었기 때문입니다.

24 GB 카드 2장은 48 GB 카드 1장이 아닙니다

모델을 여러 GPU에 분할하는 것은 가능하며, 대형 모델의 경우 유일한 경제적 대안입니다. 하지만 산술적으로 단순히 더해지는 것이 아니며, 그 차이는 가용 용량과 디코딩 속도라는 두 가지 측면에서 나타납니다.

용량 측면에서, 단일 카드는 드라이버, 디스플레이 출력, 할당자 파편화로 인해 일부를 손실합니다. 이 계산기는 소비자용 카드는 약 93%, 디스플레이가 연결되지 않은 워크스테이션 또는 데이터센터 카드는 약 95%를 사용할 수 있다고 가정합니다. 멀티 카드 분할은 각 카드가 자체 런타임 컨텍스트와 활성화 버퍼 복사본을 유지해야 하고 레이어 분할이 거의 균등하게 나누어지지 않기 때문에 약 90% 수준으로 손실이 더 큽니다. 따라서 두 개의 RTX 4090은 약 43.2 GB의 작업 공간을 제공하는 반면, 동일한 명목상 48 GB 용량의 단일 RTX 6000 Ada는 45.6 GB를 제공합니다.

그 2.4 GB의 차이가 실제 사용 가능 여부를 결정합니다. 8K 컨텍스트를 사용하는 Q4_K_M 설정의 Llama 3.3 70B는 46.4 GB가 필요하므로 둘 다 사용할 수 없습니다. 캐시를 Q8로 변경하면 45.1 GB가 되어 단일 48 GB 카드에는 들어가지만, 여전히 두 장의 카드 조합에는 맞지 않습니다. 두 개의 4090에서 실행하려면 가중치를 42.5 GB인 Q4_0으로 낮춰야 합니다. 동일한 명목상 메모리 용량이지만, 두 가지 추가적인 타협이 필요합니다.

속도 측면에서 흔히 두 장의 카드가 두 배 빠를 것이라 기대하지만, 단일 스트림 디코딩에서는 그렇지 않으며 모델이 하나에 들어갈 경우 오히려 단일 카드보다 느린 경우가 많습니다. llama.cpp 및 대부분의 단일 노드 설정에서 기본 분할 방식은 파이프라인 병렬 처리입니다. 즉, 0~39 레이어는 1번 카드에, 40~79 레이어는 2번 카드에 배치됩니다. 토큰 생성 시 80개 레이어를 순차적으로 거치기 때문에, 한 순간에는 정확히 하나의 GPU만 작업을 수행하고 나머지는 대기하며, 경계에서 PCIe를 통한 히든 스테이트 전송이 발생합니다. 당신은 처리량이 아닌 용량을 구매한 것입니다. 이 계산기는 이를 단일 카드 대비 대역폭 효율이 0.75에서 0.6으로 감소하는 것으로 모델링합니다. 이로 인해 70B 모델에서 두 개의 RTX 4090은 초당 약 13 토큰, 단일 RTX 6000 Ada는 초당 약 16 토큰의 성능을 보이며, 카드당 원시 대역폭은 두 장의 조합이 더 높음에도 불구하고 결과는 이와 같습니다.

vLLM과 TensorRT-LLM이 사용하는 텐서 병렬 처리가 대안입니다. 모든 레이어를 모든 카드에 걸쳐 분할하고 동시에 작업하는 방식입니다. 이는 디코딩 속도를 실제로 향상시키지만, 모든 레이어에서 카드 간 all-reduce가 필요하므로 NVLink 또는 각 카드에 최소한 전체 x16 PCIe 레인이 필요합니다. 두 번째 카드를 x4로 실행하는 소비자용 메인보드에서는 텐서 병렬 처리가 파이프라인 병렬 처리보다 느릴 수 있습니다. 또한 어텐션 헤드 수가 카드 수로 나누어떨어져야 하므로 3카드 설정은 다루기 어렵습니다.

실용적인 요약: 이미 실행 가능한 모델을 더 빠르게 만들기 위해서가 아니라, 실행할 수 없는 모델을 실행하기 위해 카드를 추가하십시오. 같은 가격에 큰 카드 한 장과 작은 카드 두 장 중 선택해야 한다면, 단순성, 전력 소비, 가용 용량 및 단일 스트림 지연 시간 면에서 단일 카드가 유리합니다. 멀티 카드는 배치 처리를 통해 모든 카드를 바쁘게 유지할 수 있는 동시 요청 처리 시에 유리합니다.

시스템 RAM으로 오프로드하면 어떤 일이 발생하는가

모델이 맞지 않으면 llama.cpp와 Ollama는 일부 레이어를 시스템 RAM에 유지하고 CPU에서 실행합니다. 작동은 하지만, 속도가 완만하게 저하되지 않기 때문에 사용자는 하드웨어가 고장 났다고 결론 내리는 지점이기도 합니다.

그 이유는 디코딩이 연산이 아닌 메모리 대역폭에 의해 제한되기 때문입니다. 토큰 하나를 생성하기 위해 런타임은 모든 활성 가중치와 전체 캐시를 한 번 읽습니다. 8K 컨텍스트의 Q4_K_M 설정 Llama 3.3 70B의 경우 토큰당 약 45.5 GB를 읽어야 합니다. 이를 해당 메모리의 대역폭으로 나누면 연산이 시작되기도 전에 성능의 한계치가 결정됩니다.

RTX 4090의 읽기 속도는 1008 GB/s입니다. 일반적인 데스크탑의 듀얼 채널 DDR5는 약 90 GB/s입니다. 이는 11배의 차이이며, 이것이 핵심입니다. 70B 모델이 4090에 완전히 들어간다면 초당 약 17 토큰으로 디코딩될 것입니다. 하지만 들어가지 않습니다. 46.4 GB 중 22.3 GB만 상주하므로, 토큰 읽기의 52%가 9분의 1 속도인 시스템 RAM에서 발생합니다. 결과적으로 초당 약 2.6 토큰이 나옵니다. 모델의 48%를 빠른 장치에 유지하고 속도의 84%를 잃은 셈입니다.

모든 규모에서 동일한 양상이 나타납니다. Llama 3.1 8B는 토큰당 5.9 GB를 읽습니다. 4090에서는 초당 약 127 토큰이지만, 90 GB/s RAM의 CPU에서만 실행하면 약 11 토큰입니다. Q4_K_M 설정의 Qwen3 32B는 22.8 GB가 필요하므로, 16 GB RTX 5080에서는 약 65%가 상주하며 예상 속도는 초당 약 33 토큰에서 약 8 토큰으로 떨어집니다.

두 가지 세부 사항 때문에 실제 체감 성능은 이 수치보다 더 나쁩니다. CPU 레이어에서의 프롬프트 처리는 대역폭이 아닌 연산에 의해 제한되므로, 이후 스트리밍 속도가 괜찮아 보이더라도 긴 프롬프트는 첫 토큰이 나오기까지 몇 분이 걸릴 수 있습니다. 또한 런타임이 호스팅하는 레이어에 대한 작업 버퍼가 여전히 필요하므로 GPU 측에서도 오프로딩은 공짜가 아닙니다.

오프로딩이 적절한 경우: 기다릴 필요가 없는 배치 작업, 초당 몇 토큰으로도 충분한 모델, 소수의 레이어만 넘치는 경우입니다. 10% 오프로딩은 50%보다 훨씬 적은 비용이 듭니다. 잘못된 경우: 대화형 작업입니다. DIMM을 통해 느리게 실행되는 큰 모델보다는 적절한 quantisation이 적용된 작은 모델이 거의 항상 더 나은 성능을 제공합니다. 더 큰 모델의 기능이 필요하다면 데스크탑에서 억지로 실행하는 것보다 API를 호출하는 것이 더 빠르고 저렴합니다.

Apple Silicon 및 통합 메모리

Apple Silicon에는 별도의 VRAM이 없습니다. CPU와 GPU가 동일한 패키지의 LPDDR 풀을 공유하므로, 128 GB 메모리를 탑재한 Mac은 시중의 어떤 소비자용 GPU도 담을 수 없는 모델을 로드할 수 있습니다. 이는 확실한 장점이며 로컬 추론 환경에서 Mac이 흔히 사용되는 이유입니다. 다만 뒤늦게 발견하게 되는 두 가지 제약이 있습니다.

첫째, 전체를 다 사용할 수 없습니다. macOS는 기기에서 실행되는 다른 모든 작업을 위해 메모리를 예약하고 GPU가 고정할 수 있는 메모리 양을 제한합니다. 이 계산기는 모델에 약 75%를 사용할 수 있다고 가정하므로, 128 GB 통합 메모리는 약 96 GB의 예산이 되고 16 GB Mac mini는 약 12 GB가 됩니다. iogpu wired limit 설정을 통해 제한을 높일 수 있지만, 물리적 총량에 가깝게 설정하면 시스템 스와핑 위험이 있으며, 모델 스와핑은 로드하지 않는 것보다 더 나쁩니다.

둘째는 대역폭입니다. 통합 메모리는 넓지만 GDDR만큼 넓지는 않습니다. M4 Max는 약 546 GB/s로 RTX 4090의 1008 GB/s나 RTX 5090의 1792 GB/s에 비해 낮으며, Mac mini의 기본 M4는 약 120 GB/s로 5년 된 RTX 3060의 3분의 1 수준입니다. Q4_K_M 설정의 Llama 3.1 8B에서 이는 M4 Max에서 초당 약 60 토큰, 기본 M4 Mac mini에서 약 13 토큰, RTX 3060에서 약 45 토큰으로 나타납니다. 용량과 속도는 별개의 구매 항목이며, Apple은 가격 대비 용량은 많이 제공하지만 속도는 상대적으로 적게 제공합니다.

프롬프트 처리가 더 큰 문제입니다. 디코딩은 대역폭 제한적이라 Apple이 다소 뒤처지는 수준이지만, 프리필(prefill)은 연산 제한적이라 전용 텐서 코어를 갖춘 최신 NVIDIA 카드와의 격차가 훨씬 큽니다. Mac의 채팅에 30,000 토큰 문서를 붙여넣으면 스트리밍 자체는 괜찮아 보이더라도 첫 토큰이 나오기까지 상당한 시간이 걸릴 수 있습니다. 긴 프롬프트와 짧은 답변이 주된 작업이라면, 구매 전 이 수치를 테스트해야 합니다.

Mac이 확실히 우위를 점하는 부분은 외장 그래픽 카드로 합리적인 가격에 도달할 수 없는 중간 범위입니다. Q4_K_M 설정의 Llama 3.3 70B는 128 GB M4 Max에서 초당 약 8 토큰으로 원활하게 실행되며, 192 GB M2 Ultra는 약 11 토큰으로 실행하면서 100 GB가 넘는 모델도 수용할 수 있습니다. NVIDIA 하드웨어로 이를 구현하려면 여러 장의 카드, 이를 지원할 레인을 갖춘 메인보드, 그에 맞는 파워 서플라이가 필요합니다. 가능하면 일반 백엔드 대신 MLX를 사용하십시오. 이 메모리 모델을 위해 작성되었으며 동일한 기기에서 대안들보다 일관되게 더 나은 성능을 보입니다.

한 번에 여러 명 서비스하기

위의 모든 내용은 한 번에 하나의 요청을 가정합니다. 모델을 다른 사람들이 사용하는 엔드포인트 뒤에 배치하는 순간, 가중치는 공유되지만 모든 동시 요청은 각자의 KV 캐시를 가집니다. 이로 인해 캐시는 부차적인 항목에서 지배적인 비용 요소가 됩니다. 8K 컨텍스트의 Q4_K_M 설정 Llama 3.1 8B에서 동시성이 증가함에 따라:

16명의 동시 사용자일 때 캐시는 모델보다 커집니다. 32명일 때는 8B 모델이 단일 사용자의 70B 모델보다 더 많은 메모리를 필요로 합니다. 이는 노트북에서 프로토타입을 만들고 8명이 접속했을 때 왜 서버가 다운되는지 의아해하는 팀들이 놀라는 수치입니다.

장점은 GPU가 낭비되지 않는 곳이 바로 동시성(concurrency)입니다. 단일 스트림 디코딩은 메모리 대기 때문에 대부분의 컴퓨팅이 유휴 상태가 되지만, 배치 처리는 하나의 가중치 읽기를 여러 시퀀스로 분산하므로 총 처리량이 메모리 사용량보다 훨씬 빠르게 증가합니다. 또한 페이지드 캐시(vLLM)가 시퀀스가 실제로 증가할 때 블록 단위로 캐시를 할당하므로 최악의 경우를 미리 예약하지 않아도 되므로 캐시가 제 역할을 합니다. 서버 용량을 산정할 때는 최대 컨텍스트와 최대 사용자 수를 곱한 값이 아니라 실제 동시성과 실제 중간값 프롬프트 길이에 맞춰 캐시 용량을 설정하세요.

GPU 규모 산정 시 흔한 실수

사람들이 실제로 묻는 질문

7B 또는 8B 모델을 실행하려면 VRAM이 얼마나 필요한가요?

8K context의 Q4_K_M 기준 약 6.6 GB가 필요하며, 이는 8 GB 카드에 약간의 여유를 두고 들어갑니다. BF16에서는 동일 모델이 17.9 GB를 필요로 하므로 24 GB 카드가 적합합니다. 128K context를 모두 사용하려면 22.8 GB까지 증가하므로, 여기서는 precision만큼이나 context가 중요합니다.

왜 8 GB 모델이 8 GB 카드에서 로드되지 않나요?

세 가지 이유가 복합적으로 작용합니다. 드라이버와 데스크톱이 이미 카드의 약 7%를 점유하고 있고, KV cache가 가중치 위에 할당되며, 런타임이 작업을 시작하기 전에 약 0.65 GB의 context 및 커널 공간을 필요로 합니다. 파일 크기는 이러한 요소들을 전혀 포함하지 않은 수치입니다.

24 GB 카드로 70B 모델을 실행할 수 있나요?

VRAM만으로는 불가능합니다. Llama 3.3 70B는 Q4_K_M 및 8K에서 46.4 GB가 필요하며, 2K context의 IQ2_XXS에서도 가용 VRAM 약 22.3 GB를 초과하는 22.5 GB가 필요합니다. 시스템 RAM으로 오프로드하여 초당 몇 개의 token을 얻거나, 대신 32B 모델을 실행하여 초당 30개를 얻을 수 있습니다.

Q4_K_M으로 충분한가요?

거의 모든 경우에 충분하며, 기본값으로 설정된 데에는 이유가 있습니다. 가중치당 4비트가 아닌 4.85비트를 저장하여 attention 및 embedding tensor를 더 높은 precision으로 유지합니다. Q8_0과의 측정 가능한 차이는 작지만 메모리 절감 효과는 거의 절반에 달합니다. 모델을 아예 실행할 수 없는 상황이 아니라면 이보다 낮은 설정은 피하세요.

낮은 precision의 더 큰 모델이 높은 precision의 더 작은 모델보다 나은가요?

약 4비트까지는 그렇습니다. Q4_K_M의 70B 모델은 비슷한 메모리 점유율에서 대부분의 작업 시 Q8_0의 32B 모델보다 성능이 좋습니다. 3비트 미만에서는 중소형 모델의 경우 중복성이 적어 성능 순위가 뒤바뀝니다. 매우 큰 모델은 작은 모델보다 2비트 포맷을 훨씬 더 잘 견딥니다.

왜 3.8B 모델의 KV cache가 27B 모델보다 큰가요?

Phi-3.5 mini는 1024 token당 0.375 GB를 사용하는 32개의 key-value head를 가진 전체 multi-head attention을 사용하는 반면, Gemma 3 27B는 6개 레이어 중 5개에 1024-token sliding window를 적용하기 때문입니다. 128K에서 이는 48 GB 대 10.4 GB가 됩니다. cache 크기는 파라미터 수가 아닌 attention 레이아웃을 따릅니다.

KV cache를 quantize해야 할까요?

context가 길 때는 항상 Q8을 활성화하세요. 비용이 거의 들지 않습니다. cache가 메모리 점유율의 큰 비중을 차지하고 작업이 recall-heavy하지 않은 경우에만 Q4를 고려하세요. 32K의 Command R 35B에서는 Q8이 20.3 GB를 절약합니다. 동일한 context의 Llama 3.3 70B에서는 grouped-query attention이 이미 최적화를 수행했기 때문에 5.1 GB가 절약됩니다.

24 GB 카드 두 장이 48 GB 카드 한 장과 같나요?

아닙니다. 각 카드가 자체 런타임 context를 가지고 레이어 분할이 균등하지 않기 때문에 45.6 GB가 아닌 약 43.2 GB만 사용할 수 있습니다. pipeline parallelism으로 인해 한 카드가 계산하는 동안 다른 카드는 대기해야 하므로 단일 스트림 속도도 향상되지 않습니다. 카드 두 장은 용량을 늘려주며, 동시성 작업 시 처리량(throughput)을 높여줍니다.

실제 실행 속도는 어느 정도인가요?

메모리 대역폭을 token당 읽는 바이트 수로 나누세요. Q4_K_M의 Llama 3.1 8B는 token당 5.9 GB를 읽으므로, 1008 GB/s의 RTX 4090은 효율 손실을 고려하면 초당 약 127 token을 처리합니다. 이 추정치는 decoding에만 해당합니다. Prompt processing은 연산 집약적(compute bound)이며 다른 곡선을 따릅니다.

시스템 RAM으로 오프로드하면 실제로 어떤 일이 벌어지나요?

속도가 완만하게 줄어드는 것이 아니라 급격하게 떨어집니다. RTX 4090에 레이어의 48%를 올리고 나머지를 DDR5에 둔 Llama 3.3 70B는 완전히 VRAM에 상주할 때의 17 token/s 대신 초당 약 2.6 token으로 decoding합니다. 약간의 오버플로는 감당할 수 있지만, 모델의 절반이 시스템 RAM에 있는 것은 감당할 수 없습니다.

Mac은 로컬 inference에 좋은 기기인가요?

가격 대비 용량 측면에서는 좋습니다. 128 GB M4 Max는 약 96 GB의 가용 메모리를 제공하며 70B 모델을 초당 약 8 token으로 실행합니다. 순수 속도 면에서는 좋지 않습니다. RTX 5090의 1792 GB/s 대비 546 GB/s의 대역폭을 가지며 prompt processing은 더 느립니다. latency가 아닌 대형 모델 실행과 정숙한 작동을 위해 구매하세요.

Mixture-of-experts 모델은 메모리를 절약하나요?

공간이 아니라 시간을 절약합니다. Qwen3 30B-A3B는 모든 expert가 상주해야 하므로 여전히 20.1 GB가 필요하지만, token당 약 3.3B 파라미터만 읽으므로 동일한 메모리 점유율의 dense 32B 모델보다 몇 배 더 빠르게 decoding합니다. MoE 모델은 전체 크기로 적합성을 판단하고, active 파라미터로 속도를 판단하세요.

Flash attention이 VRAM을 줄여주나요?

대규모 중간 attention 행렬을 제거하여 긴 prompt의 prefill 과정에서 실질적인 절감 효과를 주며 prompt processing을 더 빠르게 합니다. context에 따라 증가하는 KV cache를 줄이지는 않습니다. 무조건 활성화하세요. 단, 이 페이지의 총계 수치가 변할 것이라고 기대하지는 마세요.

작은 context를 설정했는데 왜 nvidia-smi는 카드가 꽉 찼다고 표시하나요?

아마도 vLLM을 실행 중일 것입니다. vLLM은 시작 시 카드의 일정 부분을 고정적으로 점유하고 내부적으로 paged cache pool을 관리합니다. llama.cpp는 요청한 context에 필요한 만큼만 할당합니다. 여기에 표시된 수치는 vLLM이 할당해야 하는 작업 세트(working set)를 설명하며, llama.cpp가 직접 보고하는 수치와 같습니다.

모델을 실행하는 것이 아니라 fine-tune하려면 VRAM이 얼마나 필요한가요?

훨씬 더 많이 필요하며, 이 계산기는 이를 모델링하지 않습니다. 전체 fine-tune은 파라미터당 약 16 바이트의 가중치, gradient, optimizer 상태를 유지하므로 8B 모델은 activation을 제외하고도 약 130 GB에 달합니다. 4-bit 기반의 QLoRA는 inference 점유율에 activation 메모리를 더한 수준에 가까우며, 이것이 단일 소비자용 카드에서 가능한 유일한 현실적인 옵션인 이유입니다.

Vision 모델은 계산 방식을 바꾸나요?

여기에 나열된 multimodal 모델의 파라미터 수에는 vision encoder가 포함되어 있으므로 가중치 수치는 정확합니다. 총계에 반영되지 않은 점은 이미지가 언어 모델에 도달하기 전에 많은 수의 token으로 확장된다는 것입니다. 따라서 고해상도 이미지 몇 장은 텍스트 한 페이지보다 더 많은 context를 소비하고, 결과적으로 더 많은 cache를 사용하게 됩니다.

아무것도 들어가지 않으면 어떻게 하나요?

가장 비용이 적게 드는 context를 먼저 줄이고, 그다음 cache를 Q8로 quantize한 뒤, 가중치를 한 단계 낮추세요. 그래도 부족하다면 시스템 RAM을 사용하여 느려지는 큰 모델보다 적절한 quantization을 적용한 작은 모델이 더 낫습니다. 또는 무료 API를 통해 동일한 open-weight 모델을 호출하세요 그리고 하드웨어는 다른 사람이 관리하게 하세요.