LLM 모델 선택 시 어떤 벤치마크를 참고해야 하나요?

Agentic 코딩에서는 SWE-bench Verified와 Terminal Bench 2.0이 가장 직접적인 지표입니다. SWE-bench는 실제 GitHub 버그를 수정하는 능력을, Terminal Bench는 터미널 명령어 사용 능력을 측정합니다.

FP8 모델의 메모리 사용량은 얼마인가요?

FP8 모델은 파라미터 수와 동일한 GB의 메모리를 사용합니다. 예를 들어 24B 모델은 24GB, 110B 모델은 110GB의 VRAM이 필요합니다.

KV Cache 메모리는 어떻게 계산하나요?

KV Cache 메모리 = 2 × num_layers × num_kv_heads × seq_len × head_dim × bytes_per_param 공식으로 계산합니다. BF16 사용 시 bytes_per_param은 2입니다. 예를 들어 Devstral-24B 모델에서 128K 컨텍스트는 약 20GB의 KV Cache가 필요합니다.

KV Cache 양자화를 권장하지 않는 이유는 무엇인가요?

KV Cache를 양자화하면 컨텍스트가 길어질수록 품질 손상이 체감됩니다. 16bit(BF16)를 사용하는 것을 권장하며, Agentic 코딩에서는 모델 양자화도 8bit 아래로는 내려가지 않는 것이 좋습니다.

(폐쇄망 LLM 2) 모델 선택과 메모리 요구량

폐쇄망/내부망에서 로컬 LLM 모델 선택을 위한 벤치마크 분석과 VRAM 메모리 요구량 계산법. FP8 모델과 KV Cache 메모리 산정 방법을 다룹니다.

Posted Dec 27, 2025 Updated Apr 6, 2026

LLM 모델 VRAM 메모리 요구량

By 이준범

18 min read

(폐쇄망 LLM 2) 모델 선택과 메모리 요구량

이전 글: 목표 설정
이 글은 망분리 환경 AI 배포 시리즈의 두 번째 글입니다.
다음 글: 추론 속도와 MoE 모델

어떤 모델을 써야 할까?

모델 선택의 기준은 크게 세 가지입니다:

직접 사용해보기
벤치마크 점수
커뮤니티 반응

당연히 직접 써보는 게 가장 좋습니다. GLM 과 MiniMax는 저렴하게 coding plan 을 제공하고 있고 claude-code 에 직접 연동해서 사용 가능합니다. Devstral 은 현재 (수정일 2026년1월 기준) API 가 무료고 Mistral Vibe 와 연동해 사용해 볼 수 있습니다. 다른 모델들을 더 다양하게 사용해 보고 싶다면 openrouter라는 선택지도 있습니다.

그런데 모델 하나를 제대로 평가하려면 시간과 노력이 상당히 들어갑니다. 다양한 태스크를 돌려봐야 하고, 양자화 설정도 바꿔가며 테스트해야 하고, 충분한 시간 동안 써봐야 진짜 성능을 알 수 있거든요.

벤치마크 둘러보기

그래서 가장 빠르게 성능을 파악하는 방법은 벤치마크입니다. 숫자로 딱 나오니까요.

주요 벤치마크 설명:

MMLU-Pro: 쉽게 말해 “AI 수능”입니다. 14개 분야에서 10지선다 문제를 풀게 하는데, 대학원 수준의 난이도라 기존 MMLU(4지선다)보다 훨씬 어렵습니다. “이 모델이 얼마나 똑똑한가?”를 보는 지표죠.
SWE-bench Verified: “실제 개발자처럼 버그 고칠 수 있나?” 테스트입니다. 진짜 GitHub에 올라온 버그 리포트 500개를 주고 코드를 수정하게 합니다. 사람이 일일이 검증한 문제들이라 신뢰도가 높습니다. Claude Code 같은 코딩 도구에서 모델 성능을 가장 직접적으로 보여주는 지표입니다.
SWE-bench Multilingual: 위와 같은데 Python만이 아니라 Java, TypeScript, Go, Rust, C, C++까지 7개 언어로 테스트합니다. 실무에서는 여러 언어를 쓰니까요.
Terminal Bench 2.0: “터미널 잘 쓰는가?” 테스트입니다. grep으로 파일 찾기, 서버 설정, 코드 컴파일 같은 실제 개발자가 터미널에서 하는 작업을 시킵니다. 위험한 명령어(rm -rf / 같은) 실행을 거부하는 능력도 봅니다.
LiveCodeBench: 코딩 대회 문제 풀이 능력입니다. 매달 새 문제가 추가됩니다. AI가 학습할 때 기존 문제를 이미 봤을 수 있기 때문입니다. 새 문제로 테스트해서 진짜 AI 코딩 실력을 테스트 해봅니다.

Agentic coding에서 직접적인 영향을 주는 점수는 **SWE-bench**와 **Terminal Bench**입니다.

이 점수가 높아야 실제로 코드 수정하고 터미널 명령 실행하는 작업을 잘 합니다.

커뮤니티 반응

Reddit의 r/LocalLlama가 이 분야 논의의 중심입니다. 새 모델이 나오면 바로 리뷰가 올라오고, 실사용 경험이 공유되죠.

다만 커뮤니티 반응이 항상 정확한 건 아닙니다.

Devstral-small-2: 커뮤니티에서 초기 반응이 좋지 않았습니다. 이유는 크게 세 가지였습니다. 첫째, vLLM과 Mistral Vibe 쪽에 버그가 있었습니다. 둘째, 양자화 설정에 따라 성능 편차가 컸습니다. 셋째, r/LocalLlama는 대부분 로컬에서 개인용으로 쓰다 보니 4bit 양자화를 선호하는데, 이 모델은 4bit에서 성능이 많이 떨어졌습니다. 저는 출시된 지 2주 뒤에 FP8 모델 + BF16 KV-cache로 돌리고 있는데, 성능이 놀라울 정도로 좋다고 느끼고 있습니다. 커뮤니티 평가보다 실제 성능이 훨씬 낫다고 느꼈습니다.

GLM-4.5-air: 반대로 커뮤니티에서 엄청난 호평을 받은 모델입니다. 그런데 제 경험은 조금 달랐습니다. 추론에 시간을 너무 많이 들여서 답답할 때가 있고, 단순한 질문(Python quicksort 구현 같은 짧은 질문)에서 무한 사고 루프에 빠지는 경험을 여러 번 했습니다. 물론 복잡한 태스크에서는 좋은 성능을 보여주긴 합니다.

결국 벤치마크, 커뮤니티 반응, 직접 사용 경험을 종합적으로 판단해야 합니다.

그럼 제일 좋은 걸 쓰면 되지 않나요?

그냥 제일 좋은 모델을 쓰면 되는데 문제가 있습니다…

메모리…

GLM-4.7 을 소비자용 GPU에서 구동 시도할 경우

자, 그러면 글을 쓰고 있는 현시점(2025-12-30) Hugging Face에서 trending 기준 최상단에 위치한 GLM-4.7을 살펴보겠습니다. 다음은 벤치마크입니다.

Benchmark	GLM-4.7	Kimi K2	DeepSeek-V3.2	Gemini 3.0 Pro	Claude Sonnet 4.5	GPT-5.1-High
MMLU-Pro	84.3	84.6	85.0	90.1	88.2	87.0
GPQA-Diamond	85.7	84.5	82.4	91.9	83.4	88.1
AIME 2025	95.7	94.5	93.1	95.0	87.0	94.0
SWE-bench Verified	73.8	71.3	73.1	76.2	77.2	76.3
SWE-bench Multilingual	66.7	61.1	70.2	-	68.0	-
Terminal Bench 2.0	41.0	35.7	46.4	54.2	42.8	47.6
LiveCodeBench-v6	84.9	83.1	83.3	90.7	64.0	87.0

거의 상용 모델에 준하는 성능입니다. 커뮤니티 반응도 좋습니다. 저도 실제로 코딩 플랜 끊어서 사용 중인데 만족스럽습니다. 그런데 이 모델은 358B 파라미터입니다.

메모리 요구량 계산하기

메모리… 메모리… 로컬 모델을 배포할 때 고민의 처음과 끝은 메모리입니다. 예산의 처음과 끝도 메모리이구요…

어떤 모델을 쓸 때 메모리를 얼마나 사용하는지 미리 계산해볼 필요가 있습니다. 양자화에 대해서는 다른 섹션에서 자세히 다루겠지만, 일단 FP8(8bit) 모델을 쓴다고 가정하고 논의를 진행하겠습니다.

모델

FP8 모델을 쓴다고 하면 계산은 간단합니다. xB 모델을 사용한다고 하면 정확히 xGB만큼 메모리를 사용합니다. GLM-4.5-AIR-FP8 모델의 파라미터는 대략 110B입니다. 그러면 모델이 110GB 정도의 메모리를 사용하는 거죠. Devstral-Small-2-24B-Instruct-2512는 24B 파라미터니까 대략 24GB 정도의 메모리를 사용할 겁니다.

Reddit을 보면 6bit, 4bit, 심지어 2bit까지 사용하는 분들이 많습니다. 하지만 제 경험상 8bit에서도 분명히 품질 손상이 있습니다. Agentic 코딩을 할 거라면 8bit 아래로는 내려가지 마세요. 양자화에 대한 자세한 내용은 별도 글에서 다룹니다.

KV Cache

메모리 사용은 모델로 끝나지 않습니다. 각 요청별로 KV Cache를 사용하게 됩니다. KV Cache가 없으면 매 토큰 생성마다 이전 모든 토큰을 다시 계산해야 하므로 실용적인 속도를 낼 수 없습니다. 트랜스포머의 Self-Attention에서 각 토큰은 이전 모든 토큰과의 attention을 계산해야 하는데, KV Cache가 없다면 매번 처음부터 다시 계산해야 합니다.

KV Cache는 메모리를 더 써서 속도를 향상시키는 기술입니다. (정확히 말하면 KV Cache가 없으면 LLM이랑 대화가 불가능할 정도로 속도가 안 납니다.)

제 경험상 KV Cache는 16bit(BF16)를 추천합니다. KV Cache를 양자화하면 컨텍스트가 길어질수록 품질 손상이 체감됩니다.

KV Cache의 메모리 계산 공식은 다음과 같습니다:

KV-cache Memory = 2 × num_layers × num_kv_heads × seq_len × head_dim × bytes_per_param

각 파라미터의 의미:

2: Key와 Value 두 가지 캐시
num_layers: 모델의 레이어 수
num_kv_heads: KV 헤드 수
seq_len: 컨텍스트 길이 (토큰 수)
head_dim: 헤드 차원 (config.json에 명시되어 있거나, hidden_size / num_attention_heads로 계산)
bytes_per_param: BF16은 2 bytes

위 숫자들은 모델 파일의 config.json에 저장되어 있습니다. 예시로 다음 모델을 한번 찬찬히 뜯어보며 계산해 보시죠.

예시: Devstral-small-2 (FP8 모델 + BF16 KV Cache)

먼저 Devstral-Small-2-24B-Instruct-2512에 들어가서 Files and versions -> config.json을 클릭하면 다음과 같은 정보가 있습니다:

  
{
  ...
  "text_config": {
    ...
    "head_dim": 128,
    "hidden_size": 5120,
    ...
    "num_attention_heads": 32,
    "num_hidden_layers": 40,
    "num_key_value_heads": 8,
    ...
  },
  ...
}

위 파일에 따르면 다음 숫자 확인 가능합니다:

num_layers: 40
num_kv_heads: 8
head_dim: 128

컨텍스트 별로 계산을 해보면:

컨텍스트 길이	KV Cache 메모리	계산식
8K (8,192)	1.25 GB	2 × 40 × 8 × 8,192 × 128 × 2
16K (16,384)	2.5 GB	2 × 40 × 8 × 16,384 × 128 × 2
32K (32,768)	5 GB	2 × 40 × 8 × 32,768 × 128 × 2
128K (131,072)	20 GB	2 × 40 × 8 × 131,072 × 128 × 2
256K (262,144)	40 GB	2 × 40 × 8 × 262,144 × 128 × 2

와… 벌써 부담이 됩니다. KV Cache는 요청당 필요한 메모리입니다. 예를 들어, 128K 컨텍스트 요청 2개가 들어 오면 모델 메모리 + 20 GB x 2 = 40 GB 메모리가 추가로 필요합니다..

계산용 작업 공간: Activation 버퍼

모델과 KV Cache 외에도 계산용 작업 공간이 필요합니다.

비유를 들어볼게요. 주방에서 요리할 때를 생각해 보세요:

모델 = 요리사의 뇌 (레시피를 알고 있음)
KV Cache = 지금까지 만든 요리들을 보관하는 냉장고
계산용 작업 공간 = 재료를 썰고 볶는 조리대

조리대가 없으면 요리를 할 수가 없겠죠? LLM도 마찬가지입니다. 질문을 받으면 그 질문을 처리하는 동안 중간 계산 결과를 어딘가에 놓아둬야 합니다. 이게 바로 작업 공간입니다.

vLLM 같은 서빙 도구에서는 이 작업 공간을 서버 시작할 때 미리 확보해 둡니다. 왜냐하면:

갑자기 긴 질문이 여러 개 들어오면 작업 공간이 부족해질 수 있음
그때그때 확보하려고 하면 “메모리 부족” 에러가 날 위험이 있음
미리 확보해 두면 안정적으로 운영 가능

이 작업 공간 크기는 vLLM을 사용한다면 다음 두 가지 설정 값으로 결정됩니다:

max_num_batched_tokens: 한 번에 처리할 최대 토큰 수
max_num_seqs: 동시에 처리할 최대 요청 수

작업 공간 크기 ≈ max_num_batched_tokens × max_num_seqs × (모델별 상수)

예를 들어 max_num_batched_tokens=16384, max_num_seqs=6이면 약 98,000 토큰분의 작업 공간이 예약됩니다.

트레이드오프가 있습니다: 작업 공간을 크게 잡으면 KV Cache(냉장고)에 쓸 수 있는 메모리가 줄어듭니다. 반대로 너무 작게 잡으면 긴 질문 처리가 느려집니다.

실제 운영 시나리오

자, 그러면 실제 상황을 가정해보겠습니다.

팀원: 8명
프로그래밍 가능 팀원: 6명
vLLM 설정: max_num_batched_tokens=16384, max_num_seqs=6
워스트 케이스: 동시 사용자 4명 & 사용자당 컨텍스트 128K 토큰

모델 가중치:        24 GB
KV Cache (4명):    20 GB × 4 = 80 GB
계산용 작업 공간:   약 15~20 GB
─────────────────────────────
총 필요 메모리:     약 120~125 GB

여유 메모리까지 고려하면 140GB 정도 VRAM이 필요합니다. RTX Pro 6000 Blackwell 96GB × 2 정도가 필요할 것 같네요.

제가 방금 말씀드린 건 24B 모델입니다. GLM-4.7 같은 모델은 메모리가 얼마나 필요할까요? 358B 모델이니까 358B / 24B = 14.9배… 2.5TB가 필요할까요? 그 정도는 아닙니다. GLM은 Mixture-of-Experts(MoE) 모델이고, Devstral은 Dense 모델이라 조금 다르거든요. 이건 KV Cache 메모리에도 영향을 주지만 속도에도 영향을 줍니다.

지금까지 메모리 얘기를 했으니 다음 글 에서 속도 얘기를 하면서 MoE 모델에 대해 살짝 다뤄 보겠습니다.

시리즈 목차: AI 활용 - 망분리 환경 AI 배포

AI 활용, 망분리 배포

This post is licensed under CC BY 4.0 by the author.