내 GPU에 올라갈까요? 드디어 답을 알려주는 계산기를 만들었습니다.

새로운 open model이 나올 때마다 Reddit과 Discord에는 같은 질문이 쏟아집니다: 내 카드로 돌아갈까? 24 GB로? 두 개로? 4비트로? 어떤 컨텍스트 길이에서?

보통의 답변은 대략적인 공식입니다. 파라미터 곱하기 가중치당 바이트 수에, 모든 레이어가 전체 컨텍스트를 보는 것처럼 계산된 KV 캐시를 더하는 식입니다. 클래식한 Llama 스타일 모델에는 이 방식이 통합니다. 하지만 지난 1년간 출시된 대부분의 모델에게는 틀렸으며, 때로는 한 자릿수(order of magnitude) 차이가 납니다.

그래서 저는 StudioTV LLM VRAM Calculator를 만들었습니다. 무료이며 계정이 필요 없고 Hugging Face의 어떤 모델과도 작동합니다. 이 계산기가 무엇을 하는지, 그리고 왜 그 수치가 여러분이 익숙했던 것과 다를 수 있는지 설명하겠습니다.

순진한 추정치가 무너지는 곳은 KV 캐시입니다

모델 가중치는 쉬운 부분입니다. 어려운 부분은 컨텍스트의 토큰마다 커지는 메모리인 KV 캐시이며, 최신 아키텍처들은 매우 다르게 캐싱합니다:

• 슬라이딩 윈도우 어텐션(Sliding-window attention). Gemma 4 31B는 60개 레이어 중 50개에 걸쳐 1,024 토큰 창을 유지합니다. 오직 10개 레이어만이 전체 컨텍스트를 기억합니다. 128K 토큰에서 실제 캐시는 10.8 GiB입니다. 모든 레이어를 전역(global)으로 취급하면 120 GiB가 나오는데, 이는 11배나 과도한 수치입니다.
• 선형 어텐션(Linear attention). Qwen3.6 35B-A3B는 40개 레이어 중 단 10개의 키와 값만 캐싱하고 나머지 30개는 작고 고정된 크기의 상태를 유지합니다. 128K에서 2.5 GiB이며, 10 GiB가 아닙니다.
• 잠재 어텐션(Latent attention, MLA). DeepSeek R1은 128개의 헤드에 대해 전체 키와 값 대신 레이어당 압축된 576 크기의 잠재값(latent)을 저장합니다. 다중 헤드 공식으로는 128K에서 약 610 GiB가 예측되지만, 실제 캐시는 8.6 GiB입니다.
• 압축 어텐션(Compressed attention). DeepSeek V4 Flash는 시퀀스를 압축하고 128 토큰 창을 유지합니다: 이는 순진한 추정치보다 약 7배 적습니다.

이 계산기는 각 모델의 구성을 레이어별로 읽고, vLLM과 llama.cpp가 실제로 할당하는 방식(FP8 캐시 형식 및 슬라이딩 윈도우 레이어에 대한 추가 창 처리 포함)으로 캐시를 계산합니다.

1. 사용 환경(Your setup). 큐레이션된 53개 모델 중 하나를 선택하거나 임의의 Hugging Face 링크를 붙여넣으세요. 작업 유형(추론, 전체 파인튜닝, LoRA 또는 QLoRA), 컨텍스트 길이, 한 번에 처리할 요청 수, 사용 GPU 및 엔진을 선택합니다. 데이터센터 카드부터 노트북 GPU, Mac 및 기타 통합 메모리 장치까지 60개의 GPU와 네 가지 엔진(vLLM, SGLang, TensorRT-LLM, llama.cpp / Ollama / LM Studio)이 있습니다.

2. 결과 예측(Your answer). 필요한 GPU 개수, 적합성 여부, 그리고 각 카드에 무엇이 채워지는지 보여줍니다.

이 예시에서 Gemma 4 31B의 Q4_K_M은 가중치(weights)로 17.1 GiB, 32K 토큰 요청에 대한 KV 캐시로 3.7 GiB, 그리고 약 3 GiB의 런타임 오버헤드(runtime overhead)를 사용합니다: RTX 5090에서 사용 가능한 28.8 GiB 중 23.7 GiB를 차지합니다. 계산기는 또한 API 가격 옆에 속도(여기서는 초당 약 54 토큰)와 백만 토큰당 비용을 추정하여 보여줍니다. API가 하드웨어 임대보다 저렴할 경우, 그 사실을 알려줍니다.

3. 더 나은 품질 vs. 더 저렴한 GPU? '적합성(Does it fit?)' 그리드는 모든 가중치 형식과 사용자의 하드웨어에 대한 모든 컨텍스트 길이를 교차 분석합니다. 셀을 클릭하여 적용할 수 있습니다.

RTX 5090 한 장으로 Gemma 4 31B 구동 시: Q4_K_M 및 Q5_K_M은 최대 32K 토큰까지, Q3_K_M은 최대 128K 토큰까지 처리 가능합니다. GGUF 크기는 llama.cpp의 실제 양자화 규칙을 따릅니다. Hugging Face에 실제로 게시된 GGUF 파일을 기준으로 확인했을 때, 중앙값 오차는 Q8_0부터 Q3_K_M까지 1% 미만입니다. 그리드 옆에는 사용자의 환경에 맞는 가장 저렴한 GPU와 해당 카드에 적합한 다른 모델 목록이 계산기 형태로 제공됩니다.

4. 임대 및 배포(Rent and deploy). RunPod, Vast.ai, Verda, Azure의 온디맨드 가격을 매시간 업데이트하며, 각 GPU별 가격 이력을 제공하고 vLLM, SGLang, llama.cpp 또는 TensorRT-LLM용 즉시 붙여넣기 가능한 명령어를 제공합니다.

작성 시점 기준으로 Vast.ai에서 RTX 5090은 시간당 $0.46부터 시작했으며, 계산기는 더 저렴한 옵션인 총 $0.29의 두 대의 RTX 3090을 알려주었습니다. 이 구성을 위한 명령어는 다음과 같습니다:

llama-server -hf unsloth/gemma-4-31B-it-GGUF:Q4_K_M \
  -c 32768 --parallel 1 -ngl 99 -fa on

적합하지 않을 때 (When it does not fit)

카드 용량보다 더 많은 것을 요청해도 막다른 길에 부딪히지 않고 오프로드 계획(offload plan)을 얻을 수 있습니다. 시스템 RAM에 유지해야 할 MoE 전문가(--n-cpu-moe) 또는 레이어(-ngl)의 개수와, 듀얼 채널 DDR4부터 쿼드 채널 DDR5까지 예상할 수 있는 속도를 알려줍니다.

모델별 페이지, 매시간 업데이트 (A page for every model, updated every hour)

각 모델별 전용 페이지가 있습니다: 모든 정밀도(precision) 및 컨텍스트 길이(context length)에서의 VRAM 사용량, 필요한 각 유형의 GPU 개수, 오늘날 실행할 수 있는 가장 저렴한 방법, KV 캐시 곡선(KV cache curve), 그리고 공개된 GGUF 파일의 실제 크기까지 제공합니다.

새로운 모델들은 자체적으로 등장합니다. 워처(watcher)가 매시간 Hugging Face를 확인하여 가중치(weights)를 다운로드하지 않고도 각 신규 모델의 config.json과 safetensors 헤더를 읽고, 아키텍처를 모델링할 수 있게 되는 즉시 페이지를 게시합니다. “New & trending” 섹션은 Hugging Face 트렌드, Ollama에서 가장 많이 사용된 모델, 그리고 최신 출시 정보를 따릅니다.

AI 비서에게 문의하기

이 계산기는 또한 MCP(Multi-Client Protocol) 서버입니다. 이를 Claude, ChatGPT 또는 모든 MCP 클라이언트에 추가한 다음, “Qwen3.6 35B가 내 RTX 4090에 들어갈까요?”라고 질문하면: 비서가 계산기를 호출하여 동일한 수치로 답변합니다. 세 가지 도구(tool)와 API 키가 필요 없습니다: estimate_vram, models_that_fit 및 gpu_prices. Claude Code에서는 다음과 같이 사용합니다:

claude mcp add --transport http studiotv-vram https://studiotvai.com/api/mcp

또한 정적 JSON API와 모델 카드에 붙여넣을 수 있는 VRAM 배지(badge)도 있습니다.

휴대폰에서도

구축 방법

• 프론트엔드 (Front end): React 19, TypeScript 및 Vite를 사용했습니다. 모든 페이지(계산기, 모델별 단일 페이지, GPU별 단일 페이지)는 정적 HTML로 사전 렌더링되므로 로딩 속도가 빠르고 검색 엔진이 숫자를 확인할 수 있습니다.
• 모델 감시자 (Model watcher): 매시간 스크립트가 Hugging Face에서 새로운 모델을 찾습니다. config.json 파일은 아키텍처 정보를 제공하며, HTTP Range 요청(수 기가바이트 대신 몇백 KiB)으로 읽는 각 safetensors 파일의 헤더를 통해 모든 텐서의 정확한 크기를 파악합니다. 이를 통해 엔진이 건너뛰는 비전 타워나 추가 예측 레이어까지도 올바르게 계산할 수 있습니다.
• 서비스 (Serving): MCP 서버는 작은 Node 서비스이며, JSON API는 일반 정적 파일입니다. 모든 것이 단일 VPS에서 Docker를 이용해 실행됩니다.
• 빌드 시 레이아웃 확인: 빌드는 변경된 모든 페이지를 너비 320px, 390px, 768px, 1280px의 헤드리스 Chrome으로 열고, 위에서 아래로 스크롤하며, 화면을 초과하거나 JavaScript 오류가 발생하면 실패합니다. 코드나 구조가 변경된 페이지에 대해서만 재확인하므로 빠릅니다. CSS 변경 후 iPhone에서 페이지 오른쪽 부분이 잘리는 문제가 있어 이 기능을 추가했습니다.

한계점 및 도움 요청 사항

이 수치들은 추정치입니다. 엔진 버전과 설정은 실제 사용량에 영향을 미치므로 여유 공간을 확보하고 nvidia-smi로 확인하시기 바랍니다. 속도 수치는 대략적이며(±30% ~ 50%) 추측 디코딩(speculative decoding)을 모델링하지 않습니다. 일부 “대여 (Rent)” 링크는 제휴 링크입니다. 이 내용은 사이트에 공개되어 있으며, 제공업체는 가격만으로 순위가 매겨집니다.

만약 표시된 수치와 일치하지 않는 부분이 있다면, vLLM 또는 llama.cpp 시작 로그를 “실제 사용량과 비교 (Compare with your real usage)” 상자에 붙여넣으세요. 계산기가 실제 할당량을 추정치와 맞춰줍니다. 이러한 피드백이 이 도구를 더 좋게 만듭니다.

사용해 보기: studiotvai.com/llm-vram-calculator