VRAM 수치를 추측이 아닌 측정으로 보여주는 'Can I run this LLM?' 사이트를 만들다

문제점: 다섯 개의 사이트, 네 가지의 다른 답변

Kimi K3가 출시되자마자 저도 다른 사람들처럼 "kimi k3 vram requirements"를 검색했습니다.
인기 있는 페이지 5곳이 다음과 같은 정보를 보여주었습니다:

• 594 GB
• 1.51 TB
• 1.68 TB
• "실행할 수 없다, 아예"
• 한 페이지는 Q4가 "약 800 GB에 들어간다"고 했고, 다른 페이지는 1.2 TB라고 했습니다.

이 모든 것이 맞을 수는 없습니다. 그렇다고 모두 틀린 것도 아니에요. 이들은 같은 공식인 params × bits / 8를 사용하여 서로 다른 것들을 계산하고 있기 때문입니다: 임베딩 테이블(Q2 빌드에서도 종종 양자화되지 않음), 더 높은 정밀도로 유지되는 어텐션 텐서, 출력 헤드, 컨테이너 오버헤드를 무시합니다. Kimi K3와 같은 1T-parameter MoE의 경우, 이러한 "작은" 누락들이 수백 기가바이트에 달하는 차이를 만듭니다.

해결책: 계산을 멈추고 측정을 시작하다

모든 인기 모델의 GGUF 양자화(quant)는 이미 Hugging Face에서 파일 형태로 공개되어 있습니다. 파일 크기 자체가 답입니다. 다운로드하는 것이고, 메모리에 로드되는 것이니까요. 공식이 필요 없습니다.

그래서 저는 ModelFit을 만들었습니다:

1. fetch.py는 HF API(공개, 키 불필요)를 순회합니다: 트렌딩 GGUF 리포지토리 + 다운로드 상위권 + 화제성 키워드별로 합니다. 각 리포지토리는 트리 구조를 탐색합니다 (대형 모델은 양자화된 파일을 Q4_K_M/ 하위 디렉터리에 저장하며, 샤드 파일 같은 -00001-of-00012.gguf는 합산됩니다). 그리고 정확한 KV-cache 계산을 위해 config.json을 가져옵니다.
2. build.py는 필요 메모리(need) = 가중치 + KV 캐시 + 오버헤드를 계산하고, 모델별 페이지를 렌더링합니다: 양자화별 표, RTX 3060부터 Mac Studio 512GB까지의 GPU에 대한 판정,

측정된 수치가 실제로 보여주는 것

Kimi K3 (unsloth의 레포에서 합산한 샤드):

솔직한 한계점

• 읽기 쉬운 config.json이 없는 레포는 평평한 오버헤드 규칙(~20% + 1.5GB)을 따릅니다. 페이지에 표시되어 있습니다.
• MoE 모델은 총 크기를 계산합니다. 각 토큰마다 일부만 활성화되더라도 모든 전문가(experts)가 메모리에 상주합니다. 이는 '활성 파라미터' 마케팅 수치에 익숙한 사람들에게 놀라운 점입니다.
• 기본 컨텍스트는 8K입니다. KV 캐시는 선형적으로 증가하며, 각 페이지에서 수학적 원리를 설명합니다.
• CPU 추론 속도는 별개의 문제입니다 (용량(capacity)이 아닌 메모리 대역폭(memory bandwidth)). FAQ에서는 정확한 수치를 주장하기보다 대략적인 tok/s 범위를 제공합니다.

전체 파이프라인은 세 개의 스크립트로 구성되어 있으며 데이터는 공개적입니다:
modelfit-eight.vercel.app — 만약 좋아하는 모델이 누락되었거나 숫자가 잘못되었다면, 어떤 것인지 알려주세요. 제가 레포를 직접 확인해 보겠습니다.

데이터: Hugging Face 공개 API. 모델 크기는 업로더(unsloth, bartowski, lmstudio-community 등—실제 양자화 작업을 하는 커뮤니티)에게 속합니다.