파라미터가 몇 B라는 말이 갑자기 들리는 순간 — 모델 사이즈의 진짜 뜻

📍 AI 공부 지도 — 10/29편

이 글은 AI의 기초부터 Meta-Harness·응용 비교까지 순서대로 읽는 29편 시리즈의 10편입니다.
📚 전체 지도 보기

← 이전 편: F6. 학습이란 무엇인가 · 다음 편: B1. Agent란 무엇인가 →

이 글은 「AI 공부 지도 20부작」의 7편(F7) 입니다.
앞 편: F6 — 모델 학습 gradient descent
다음 편: P1 — AI 모델 지도 시작 [예정]

Table of Contents

0. 들어가기 전에 — 지도의 현재 위치

F1 부터 F6 까지 오시면서 LLM 이 “다음 토큰을 예측하는 함수” 라는 것, Transformer 가 어떻게 그 예측을 가능하게 만들었는지, attention·embedding 이 무슨 일을 하는지, 그리고 마지막 F6 에서 학습이란 파라미터를 조금씩 고치는 반복 이라는 얘기까지 감각을 잡으셨을 거예요.

이번 편은 그 파라미터(parameter) 라는 단어 자체를 한 번 더 깊이 파보는 글이에요. F2 와 F6 에서 “파라미터는 학습되는 가중치” 라는 설명은 이미 드렸으니까, 이 글은 거기서 한 단계 더 내려갑니다.

뉴스 기사나 개발자 블로그에서 이런 표현 계속 나오잖아요.

“Llama 3.1 405B 를 오픈소스로 공개”
“DeepSeek-V3 671B 파라미터, 활성 37B MoE“
“Mixtral 8x7B, 실제로는 47B”
“Claude Opus 는 파라미터 수가 공개되지 않았다”

이 숫자들이 구체적으로 뭘 뜻하는지, 왜 이 숫자가 중요한지, 왜 어떤 회사는 공개하고 어떤 회사는 안 하는지, 그리고 “671B 중에 37B 만 활성” 이라는 말이 대체 무슨 소린지. 여기까지 감각 잡는 게 이 글 목표예요.

한 줄로 요약하자면 파라미터 수는 모델의 VRAM·비용·지능 한계를 동시에 결정하는 단 하나의 숫자 라는 얘기예요. 그래서 이 숫자가 안 밝혀진 모델에 대해 뭔가를 추정하려면, 다른 단서로 역산해야 합니다.

1. 파라미터 한 번 더 — F2·F6 에서 한 단계 깊이

F2 에서 Transformer 내부에 여러 층이 쌓여 있고, 각 층마다 가중치 행렬(weight matrix) 이 있다는 얘기를 드렸어요. F6 에서는 그 가중치들을 gradient descent 로 조금씩 고치는 게 학습이라고 했고요.

파라미터는 그 가중치들 하나하나의 개수 입니다. 행렬 안에 숫자가 1,024 × 4,096 = 약 419만 개 들어 있으면, 이 행렬 하나만 해도 파라미터가 420만 개 있는 거예요. Transformer 블록 하나 안에 이런 행렬이 수십 개 있고, 블록이 수십~수백 개 쌓여 있으니까 파라미터가 수십억~수천억 개가 되는 겁니다.

파라미터가 갖는 성격을 다시 정리하면 이래요.

학습으로 값이 바뀌는 숫자들 (bias 포함)
입력이 들어오면 이 숫자들과 곱하고 더해서 출력을 만든다
학습이 끝나면 고정 된다 (추론할 때는 더 이상 안 바뀜)

여기까지는 F6 얘기 복습이에요. 지금부터가 F7 본론이에요. 이 숫자들의 “개수” 가 실무에서 뭘 결정하나.

세 가지를 결정합니다.

VRAM 사용량 — 모델을 GPU 에 올리려면 얼마나 메모리가 필요한가
계산량(FLOPs) — 한 번 추론 돌릴 때 얼마나 연산을 돌리나
지능의 상한 — 이 모델이 배울 수 있는 지식의 양

이 세 개가 모두 파라미터 수에 직접 묶여 있어요. 그래서 “이 모델이 몇 B 냐” 라는 질문이 실무에서 가장 먼저 나옵니다.

2. FP16 × 2 바이트 규칙 — 파라미터 수가 VRAM 을 직접 결정한다

이 글에서 가장 기억에 남기셨으면 하는 숫자 하나가 있어요.

FP16 기준, 파라미터 N 개 모델을 로드하려면 대략 N × 2 바이트의 VRAM 이 필요하다.

70B 모델이라면 70 × 10⁹ × 2 = 140 × 10⁹ 바이트 = 약 140 GB VRAM. 405B 모델이면 약 810 GB VRAM.

왜 2 바이트냐. 파라미터 하나는 그냥 소수점 숫자예요. 이 숫자를 컴퓨터 메모리에 어떻게 저장하냐에 따라 크기가 달라지는 거죠.

FP32 (float32): 파라미터 1개 = 4 바이트. 가장 정밀하지만 무거움
FP16 / BF16 (float16 / bfloat16): 파라미터 1개 = 2 바이트. 2026 년 표준
INT8 (8-bit 양자화): 파라미터 1개 = 1 바이트. 추론 최적화용
INT4 (4-bit 양자화): 파라미터 1개 = 0.5 바이트. 로컬 구동용 극한 압축

요즘 프론티어 모델은 학습·추론 모두 FP16 이나 BF16 이 기본이라서 N × 2 바이트 가 현실적인 기준점입니다.

FIG 1. 파라미터 수 → VRAM (FP16, 가중치만)

8B (Llama 3.1 8B)16 GB

70B (Llama 3.1 70B)140 GB

405B (Llama 3.1 405B)810 GB

671B (DeepSeek-V3 총)1,342 GB

※ FP16 가중치만 계산한 수치. KV 캐시·활성치 포함 시 실제로는 1.4~1.6 배가 더 든다. H100 한 장 = 80 GB 라는 점을 기준으로 보면, 70B 는 H100 2 장·405B 는 11 장·DeepSeek-V3 는 17 장이 필요하다.

그런데 여기서 끝이 아니에요. 실제 추론에는 가중치 외에도 메모리가 더 듭니다.

KV 캐시 (Key-Value Cache): 지금까지 처리한 토큰의 attention key·value 를 저장해둠. 컨텍스트 길이가 길수록 커짐
활성치 (Activations): forward pass 중 중간 계산 결과를 저장
CUDA 오버헤드·배치 여유분

실무에서는 파라미터 × 2 바이트 × 1.4~1.6 이 실질 VRAM 이라고 봅니다. 70B 모델은 가중치만 140 GB 지만 실제로는 약 200 GB 가 있어야 긴 컨텍스트로 돌릴 수 있어요. 이게 왜 실무 GPU 선택을 결정하는지 바로 감이 오시죠. apxml 하드웨어 규칙

그리고 “N × 2 바이트” 규칙은 추론 기준 이에요. 학습할 때는 여기에 gradient·옵티마이저 상태(Adam 같은 경우 파라미터 수의 2~4 배 공간이 더 듦) 까지 얹으니까 총 VRAM 은 추론의 4~6 배가 듭니다. 그래서 학습은 진짜 대형 인프라가 없으면 아예 불가능한 작업이에요.

3. 2026 년 모델 사이즈 지도

이제 구체적인 숫자로 풍경을 보시죠. 2026 년 4 월 기준으로 실제로 돌아가고 있는 모델들 중 파라미터가 공개된 것들만 정리했어요.

모델	총 파라미터	활성 파라미터	종류	라이선스	소스
Llama 3.1 8B	8B	8B	Dense	Llama Community	Meta
Llama 3.1 70B	70B	70B	Dense	Llama Community	Meta
Llama 3.1 405B	405B	405B	Dense	Llama Community	HF
Llama 4 Scout	109B	17B	MoE (16 experts)	Llama 4	llama.com
Llama 4 Maverick	400B	17B	MoE (128 experts)	Llama 4	llama.com
Llama 4 Behemoth	약 2T	—	MoE (학습 중)	—	llama.com
Qwen 3 (Dense)	0.6B~32B	= 총	Dense	Apache 2.0	Qwen
Qwen 3 30B-A3B	30B	3B	MoE	Apache 2.0	Qwen
Qwen 3 235B-A22B	235B	22B	MoE	Apache 2.0	Qwen
DeepSeek-V3	671B	37B	MoE (256 routed + 1 shared)	MIT	HF · 논문
Mixtral 8x7B	47B	13B	MoE (8 experts, top-2)	Apache 2.0	Mistral
Mixtral 8x22B	141B	39B	MoE	Apache 2.0	Mistral
GPT-5 / Claude Opus / Gemini Ultra	비공개	비공개	비공개	비공개	—

두 가지 포인트가 바로 눈에 들어오죠.

첫째, Dense 와 MoE 가 완전 다른 풍경. Llama 3.1 405B 는 총=활성 이니까 추론할 때마다 405B 전부 쓰이지만, DeepSeek-V3 는 671B 중에 단 37B 만 매 토큰마다 켜집니다.

둘째, 프론티어 클로즈드 모델(GPT / Claude / Gemini)은 숫자가 아예 없어요. 이건 섹션 6 에서 따로 다룰게요.

지금 주목하실 건 활성 파라미터 < 총 파라미터 라는 MoE 구조예요. 이게 2024~2026 년 LLM 산업을 가장 크게 바꾼 아키텍처 변화입니다.

4. MoE — 671B 중에 37B 만 쓴다는 말의 정체

Mixture of Experts (MoE) 는 간단한 발상에서 출발해요. “모델 전체가 모든 토큰을 처리할 필요가 없다. 질문 종류에 따라 담당 영역을 나누면 된다.”

비유 하나 쓸게요. 대형 종합병원을 생각해보시면 돼요. 소아과·정형외과·안과·심장내과… 전문의가 256 명 있는 병원이에요. 환자가 한 명 오면, 접수처(= 라우터) 가 증상을 보고 “이분은 정형외과 + 안과로 보내세요” 라고 배정합니다. 환자 한 명 진료에 실제로 움직이는 의사는 2~8 명이에요. 나머지 250 명은 다른 환자를 보거나 대기 중이고요.

DeepSeek-V3 가 딱 이 구조예요.

총 671B 파라미터 (병원 전체 의사 수)
각 Transformer 층마다 256 개 전문가(routed experts) + 1 개 공유 전문가(shared expert)
라우터가 매 토큰마다 상위 8 개 전문가 를 골라서 활성화
매 토큰 실제 활성 파라미터 = 37B (의사 8 명)

FIG 2. MoE 구조 — DeepSeek-V3 671B / 37B

전체 모델 671B (VRAM 에 로드됨)

매 토큰 활성 = 37B (라우터 선택)

나머지 634B (대기)

※ VRAM 은 671B 모두 로드해야 한다. 하지만 한 토큰 생성하는 계산량(FLOPs)은 37B 모델과 비슷하다. “메모리 부자 + 계산 검소” 구조.

여기서 두 가지 실무 감각이 필요해요.

VRAM 은 총 파라미터가 결정합니다. 라우터가 고르기 전에 671B 전체를 GPU 에 올려놓아야 해요. 의사 8 명만 쓴다고 해서 나머지 250 명을 집으로 보낼 수 있는 게 아니에요. 언제 부를지 모르니까 다 대기시켜야 합니다. 그래서 DeepSeek-V3 의 VRAM 요구량은 1,342 GB 로, H100 17 장이 필요해요.

계산량(FLOPs)은 활성 파라미터가 결정합니다. 매 토큰 생성할 때마다 실제로 계산되는 건 37B 뿐이에요. 그래서 추론 속도와 전기 비용은 70B Dense 모델이랑 비슷합니다. 이게 MoE 의 핵심 이득이에요. 똑똑함은 671B 수준, 추론 비용은 37B 수준. epoch.ai MoE vs Dense

그래서 요즘 프론티어 연구소가 전부 MoE 로 넘어오고 있는 거예요. Mixtral 8x7B (47B/13B), Mixtral 8x22B (141B/39B), Llama 4 Scout·Maverick, Qwen 3 MoE 시리즈… 전부 같은 발상이에요.

한계도 있어요. VRAM 을 많이 잡아먹으니까 소비자 GPU 로는 안 돌아갑니다. 8B dense 는 RTX 4090 한 장에 들어가지만, 47B MoE 는 4090 으로는 못 돌려요. 또 라우터 학습이 까다로워서 MoE 를 처음 학습시키는 건 dense 보다 훨씬 어렵습니다. 그래서 스타트업이 밑바닥부터 MoE 를 만드는 경우는 드물고, 보통 거대 연구소가 만든 MoE 모델 weights 를 가져다 쓰는 식이에요.

5. Chinchilla 법칙 — 파라미터당 토큰 얼마면 적당한가

이제 학습 쪽으로 와볼게요. F6 에서 “데이터를 많이 먹여서 학습한다” 는 얘기는 드렸는데, 그럼 파라미터 수 대비 데이터 양은 얼마가 적정 일까요.

2022 년에 DeepMind 가 이 질문에 답을 냈어요. 유명한 Chinchilla 논문 (Hoffmann et al., 2022).

결론만 말씀드리면 이래요.

고정된 학습 연산 예산 아래서는, 파라미터 1 개당 약 20 개 토큰을 학습시키는 게 최적이다.

예를 들어 70B 파라미터 모델을 학습한다면 70B × 20 = 1.4T (1.4 조) 토큰 을 먹여야 학습 효율이 가장 좋다는 얘기예요. 이것보다 데이터를 덜 주면 (파라미터가 넘치는 상태) “under-trained”. 이것보다 많이 주면 (데이터가 넘치는 상태) “over-trained” 인 셈이에요.

이 법칙이 발표되기 전까지만 해도 업계는 “파라미터를 크게 만들면 장땡” 이라는 분위기였어요. GPT-3 (175B) 이 300B 토큰만 학습했거든요. Chinchilla 법칙 기준으로 보면 GPT-3 는 크게 under-trained 였던 거예요. 파라미터를 5 배 줄이고 데이터를 5 배 늘리면 더 똑똑했을 거란 얘기죠.

그런데 이 법칙이 Llama 3.1 에 오면 재밌는 전개가 있어요.

Llama 3.1 은 모든 크기(8B / 70B / 405B)를 15T 토큰 으로 학습했습니다.

405B × 20 = 8.1T → 405B 는 Chinchilla 기준에 가까움 (살짝 넘김, 약 37 토큰/param)
70B × 20 = 1.4T → 70B 는 Chinchilla 기준의 약 10 배 데이터 (214 토큰/param)
8B × 20 = 160B → 8B 는 Chinchilla 기준의 약 94 배 데이터 (1,875 토큰/param)

70B·8B 는 심하게 over-trained 예요. 왜 이렇게 학습했을까요.

답은 “학습 비용 최적화” 가 아니라 “추론 비용 최적화” 에 있어요. Chinchilla 법칙은 “학습 연산 예산 최소화” 를 목표로 한 법칙이에요. 그런데 실제로 모델이 공개되면 추론은 수억 번·수십억 번 돌아가요. 학습은 한 번이에요. 그래서 “작은 모델에 데이터를 잔뜩 부어서 추론 때 싸게 쓰자” 는 전략이 합리적이 돼요. Meta Llama 3.1 블로그

학습 비용: 15T 토큰을 8B 로 학습 → 비쌈
추론 비용: 8B 는 가벼움 → 한 번 학습해두면 수십억 번 쓸 때 이득이 쌓임

이 전략 전환이 2024 년부터 업계 표준이 됐어요. “Chinchilla-optimal 은 학습 최적, 우리는 추론 최적을 본다.” Llama·Qwen·Mistral 모두 비슷한 철학이에요.

실무 감각 하나만 더. “8B 모델이 좋다” 는 말은 애매해요. 8B 라도 2022 년 기준 Chinchilla-optimal 8B 와 2024 년 over-trained 8B 는 완전 다른 모델이에요. 같은 8B 라도 학습 토큰이 10 배 다르면 품질이 확 차이 납니다. 그래서 “Llama 3.1 8B 는 Llama 2 7B 보다 훨씬 좋다” 같은 평가가 나오는 거예요. 파라미터 수는 같아도 학습 데이터 양이 다르니까.

6. 왜 GPT·Claude·Gemini 는 파라미터를 안 밝히나

이제 이 글에서 가장 흥미로운 부분이에요. 한번 찾아보세요. GPT-4 가 몇 파라미터인지, Claude Opus 가 몇 파라미터인지, Gemini Ultra 가 몇 파라미터인지. 공식 숫자는 없습니다.

OpenAI·Anthropic·Google DeepMind 는 모두 프론티어 모델의 파라미터 수를 공개하지 않아요. Anthropic 의 Claude 3 모델 카드 를 포함해 공식 문서 어디에도 이 숫자가 없어요. 모델 카드에는 “compute 가 크다” 정도의 서술만 있고요.

이게 왜 그럴까요. 세 가지 이유가 섞여 있는 걸로 추정됩니다.

① 영업 비밀 (trade secret). 파라미터 수가 공개되면 경쟁사가 학습 레시피를 역산할 수 있어요. Chinchilla 법칙 + 파라미터 수 + 공개된 compute 추정치를 조합하면 “얘네가 몇 조 토큰을 학습했다” 는 추정이 나와요. 모델 구조 레벨의 미묘한 노하우가 파라미터 수라는 단 하나의 숫자를 통해 새 나가는 셈이죠.

② 벤치마크 해석 혼란 방지. 숫자가 공개되면 “이 벤치마크 점수를 같은 파라미터의 오픈 모델이랑 비교해보자” 라는 얘기가 나와요. GPT-4 가 Llama 3.1 405B 보다 성능이 좋다고 해도 파라미터가 2T 였다면 “당연한 거 아닌가” 라는 얘기가 되죠. 이 프레이밍 논쟁을 회사는 안 하고 싶어해요.

③ MoE 를 공개해버리는 게 싫음. 대부분 프론티어 모델이 MoE 라는 건 암묵적으로 알려져 있어요. 그런데 “총 X, 활성 Y” 숫자를 주는 순간 경쟁사의 MoE 설계와 직접 비교가 가능해져요. 라우터 설계·전문가 수 같은 핵심 세팅이 노출될 수 있고요.

Anthropic 의 policy 는 일관돼요. Claude 3, 3.5, 4, Opus 4, Sonnet 4.7 어떤 모델 카드에도 파라미터 수가 적혀 있지 않아요. 대신 모델 카드에서는 capabilities·safety·limitations 을 중심으로 서술합니다. 회사로서는 “모델의 내재 특성이 파라미터 수가 아니라 학습 과정 전체” 라는 입장인 거예요.

실무자가 이 상황을 다루는 방법은 두 가지예요.

첫째, API 가격으로 역산. 토큰당 가격은 추론 비용을 반영해요. Claude Opus 의 토큰당 가격이 Llama 3.1 405B 호스팅 가격보다 훨씬 비싸다면, 활성 파라미터가 405B 보다 크다는 추정이 가능해요.

둘째, 벤치마크로 역산. MMLU·GPQA·HumanEval 같은 벤치마크 점수를 오픈 모델들과 비교하면 “이 정도 성능은 몇 B 수준” 이라는 감을 잡을 수 있어요. 단, 학습 데이터 양도 영향을 주니까 정확하진 않아요.

그래서 “GPT-5 는 몇 B 예요?” 라는 질문에 정답은 “아무도 공식적으로 모른다” 예요. 유출 문서나 커뮤니티 추정치가 돌아다니지만 공식은 아닙니다. 이 구조 자체가 오픈 소스와 클로즈드 소스 모델의 가장 큰 차이예요.

7. 한 문장 닫음

파라미터 수는 “모델이 얼마나 크냐” 라는 애매한 질문을 VRAM·FLOPs·학습 데이터·가격이라는 구체 숫자로 바꿔 주는 단 하나의 열쇠 값 이에요. FP16 × 2 바이트 규칙으로 VRAM 이 튀어나오고, 활성 파라미터로 추론 속도가 결정되고, Chinchilla 법칙으로 학습 데이터 적정량이 잡히고, 공개 여부로 모델 회사의 전략이 드러납니다. 70B 라는 숫자 하나를 보고 “이건 H100 2 장짜리 모델이고 추론 비용은 중간 정도” 라는 감을 잡으실 수 있다면, 이 글의 목적은 달성된 거예요.

8. 자주 묻는 질문 (FAQ)

Q1. 내 노트북에서 70B 모델을 돌리고 싶어요. 방법이 있나요?

INT4 양자화(4-bit) 로 압축하면 70B 는 약 35 GB 까지 줄어들어요. RTX 4090 (24GB) 한 장으로는 여전히 빡빡하지만, 최근 Apple M3 Max (64~128 GB 통합 메모리) 이나 M4 Pro 에서는 돌아갑니다. 대신 양자화하면 품질이 약간 떨어져요 (벤치마크 기준 1~3% 감소). 실무 감각으로는 “양자화된 70B = 본래의 30B~50B 수준” 이라고 보시는 편이 마음 편해요. 로컬에서 진짜 쾌적하게 쓰려면 8B 급 (Llama 3.1 8B, Qwen 3 8B) 이 현실적입니다.

Q2. MoE 모델은 왜 소비자 GPU 에 안 맞나요?

활성 파라미터가 작아도 VRAM 은 총 파라미터가 결정 하기 때문이에요. Mixtral 8x7B 는 활성 13B 지만 VRAM 은 47B 기준 = 약 94 GB 가 필요해요. RTX 4090 (24GB) 으로는 INT4 양자화해도 부족해요. 그래서 MoE 는 “클라우드에서 API 로 쓸 때 추론이 싸다” 는 이득이지, “내 PC 에서 돌리기 좋다” 는 이득은 아닙니다. 로컬 구동이 목적이라면 Dense 모델이 훨씬 편해요.

Q3. 파라미터가 많으면 무조건 똑똑한가요?

아니에요. 파라미터는 지능의 상한선 이지 지능 그 자체 가 아니에요. 8B 모델에 15T 토큰을 잘 학습시키면 2022 년의 40B 모델보다 똑똑할 수 있어요. 그리고 파라미터가 많아도 학습 데이터 품질이 나쁘거나 RLHF 가 제대로 안 됐으면 품질이 낮아져요. “파라미터 크기 × 학습 데이터 양 × 학습 기법 × 사후 튜닝” 의 곱이 최종 품질을 결정합니다. 이 중 하나라도 부족하면 다른 걸 채워도 메꿔지지 않아요.

Q4. Llama 5 나 GPT-6 는 몇 B 가 될까요?

공식은 아무도 모르지만, 업계 흐름으로 보면 Dense 는 거의 안 커질 거예요. 405B 가 Dense 의 사실상 한계예요. 그 이상은 추론 비용이 감당이 안 되거든요. 대신 MoE 의 총 파라미터는 계속 커집니다. Llama 4 Behemoth 가 약 2T 고, 업계에서는 “활성 파라미터는 30~70B 수준에 고정, 총 파라미터는 수조 단위로 늘어나는” 추세가 이어질 걸로 봅니다. “더 넓은 병원 + 더 똑똑한 라우터” 방향이에요.