파라미터 — 70B, 405B… 이 숫자가 뭔데요?

2026.08.23· 9분 읽기

배경 / 왜 지금 이 주제인가
핵심 데이터 & 현황
심층 분석
1) 파라미터는 정확히 무엇인가
2) 한때는 왜 숫자 경쟁이었나 — 그리고 무엇이 뒤집혔나
3) 지금 이 숫자를 못 믿는 세 가지 이유
4) 그러면 이 숫자는 언제 쓸모 있는가
실전 — 숫자를 제대로 읽는 6가지 원칙
① 메모리는 암산으로 확인한다
② 'A' 뒤 숫자를 먼저 찾는다
③ 클라우드 모델은 파라미터로 비교하지 않는다
④ 작업 난이도에 맞춰 고른다
⑤ 비용은 '크기 × 호출 횟수'로 본다
⑥ 결국은 내 데이터로 확인한다
시사점
전망 & 주목할 변수
결론
참고자료

파라미터 — 70B, 405B… 이 숫자가 뭔데요? (AI 모델 크기 완전정리와 2026 모델 선택법)

모델 이름 뒤에 붙은 B는 성적표가 아니라 설치 사양표에 가깝습니다. 이 숫자를 성능 순위로 읽는 순간, 모델 선택은 거의 반드시 틀립니다.

배경 / 왜 지금 이 주제인가

AI 모델 이름을 보다 보면 뒤에 붙은 숫자가 눈에 들어옵니다. 8B, 70B, 405B, 심지어 671B-A37B 같은 암호 같은 표기도 있습니다. 여기서 B는 billion, 즉 10억입니다. 70B는 700억 개, 405B는 4,050억 개를 뜻합니다.

문제는 그다음입니다. 대부분의 사람이 이 숫자를 자동차 배기량이나 CPU 클럭처럼 '클수록 좋은 성능 지표' 로 읽습니다. 그런데 2026년 현재 이 독법은 세 가지 이유로 통하지 않습니다. 파라미터를 많이 쓰지 않고도 잘하는 구조가 등장했고, 주요 상용 모델은 아예 크기를 공개하지 않으며, 같은 크기라도 학습 방식에 따라 결과가 완전히 달라지기 때문입니다.

시리즈 1편이 AI가 틀리는 문제, 2편이 일정하지 않은 문제, 3편이 무엇을 입력받는가의 문제였다면, 이번 편은 AI를 고를 때 무엇을 봐야 하는가의 문제입니다.

핵심 데이터 & 현황

크기의 실체: Llama 3.1 405B는 4,050억 파라미터 규모로 15조 개 이상의 토큰으로 학습됐으며, 가중치를 메모리에 올리는 데만 FP16 기준 810GB가 필요합니다(INT4로 압축 시 203GB) (Meta / Hugging Face, 2024)
크기 경쟁을 뒤집은 연구: GPT-3는 1,750억 파라미터를 3,000억 토큰으로 학습해 파라미터당 1.7토큰이었던 반면, 딥마인드의 친칠라(Chinchilla)는 700억 파라미터를 1.4조 토큰으로 학습해 파라미터당 20토큰을 썼고 더 나은 성능을 냈습니다 (Hoffmann 외, 2022)
총량과 실사용량의 분리: DeepSeek V3는 총 6,710억 파라미터를 갖지만 토큰 하나를 처리할 때 실제로 켜지는 것은 약 370억(전체의 5.5%) 입니다 (모델 카드 및 아키텍처 해설 기준)
애초에 알 수 없는 숫자: OpenAI는 GPT-4 기술보고서에서 "이 보고서는 아키텍처(모델 크기 포함), 하드웨어, 학습 연산량, 데이터셋 구성, 학습 방법에 대한 추가 정보를 담고 있지 않다"고 명시했습니다 (OpenAI, 2023)

? 해석: 두 번째 줄이 이 글의 출발점입니다. 더 작은 모델이 더 좋은 성적을 냈습니다. 그것도 실수나 예외가 아니라, 같은 연산 예산이면 모델을 키우기보다 데이터를 늘리는 편이 낫다는 체계적인 결론이었습니다. 파라미터 수는 성능을 결정하는 여러 변수 중 하나일 뿐이며, 데이터·학습량과 짝을 이룰 때만 의미가 있습니다.

심층 분석

1) 파라미터는 정확히 무엇인가

파라미터는 모델이 학습 과정에서 스스로 조정하는 숫자 하나하나입니다. 흔히 뇌의 시냅스에 비유되지만, 실무적으로는 조절 손잡이로 이해하는 편이 정확합니다. 학습이란 이 손잡이 수천억 개를 조금씩 돌려가며 "다음에 올 단어를 가장 잘 맞히는 설정"을 찾아가는 과정입니다.

그래서 파라미터 수가 뜻하는 것은 지능의 크기가 아니라 모델이 담아둘 수 있는 패턴의 총량, 즉 용량에 가깝습니다. 그릇이 크다고 요리가 맛있어지지는 않지만, 그릇이 작으면 담을 수 없는 요리가 생기는 것과 비슷합니다.

숫자를 몸으로 느껴보는 법: 파라미터 하나는 보통 2바이트(FP16)를 차지합니다. 그러면 계산이 아주 단순해집니다.

8B 모델 → 약 16GB
70B 모델 → 약 140GB
405B 모델 → 약 810GB

개인용 고급 그래픽카드의 메모리가 24GB 수준이라는 점을 떠올리면, 405B라는 숫자가 실제로 무엇을 의미하는지 바로 와닿습니다.
그것은 성능의 크기가 아니라 청구서의 크기입니다.

2) 한때는 왜 숫자 경쟁이었나 — 그리고 무엇이 뒤집혔나

2020년대 초반에는 모델을 키우면 성능이 예측 가능하게 좋아진다는 관찰(스케일링 법칙)이 업계를 지배했습니다. 그래서 발표마다 파라미터 수가 헤드라인이 됐습니다.

이 흐름에 제동을 건 것이 2022년 딥마인드의 친칠라 연구입니다. 연구진은 같은 연산 예산 안에서 모델 크기와 학습 데이터량의 균형을 다시 계산했고, 당시 대형 모델들이 데이터를 심각하게 적게 먹은 상태(undertrained)라는 결론을 내렸습니다. GPT-3가 최적으로 학습되려면 3,000억 토큰이 아니라 약 3.5조 토큰이 필요했다는 계산이었습니다(Hoffmann 외, 2022).

필자 의견: 이 연구의 진짜 의미는 "작은 모델이 이긴다"가 아닙니다. 파라미터 수만 떼어 놓고 비교하는 것이 무의미해졌다는 것입니다. 같은 70B라도 얼마나 많은 데이터로, 얼마나 잘 학습됐는지에 따라 완전히 다른 물건이 됩니다. 배기량이 같아도 엔진 세대가 다르면 다른 차인 것과 같습니다.

3) 지금 이 숫자를 못 믿는 세 가지 이유

① MoE — 총량과 실사용량이 분리됐다

최근 대형 모델들은 전문가 혼합(Mixture of Experts, MoE) 구조를 널리 씁니다. 모델 안에 여러 '전문가' 블록을 두고, 입력 토큰마다 라우터가 그중 일부만 켭니다. 나머지는 메모리에 있지만 계산에 참여하지 않습니다.

그래서 671B-A37B 같은 표기가 등장합니다. 앞은 총 파라미터, A 뒤는 토큰당 활성 파라미터입니다. DeepSeek V3의 경우 총 6,710억 중 약 370억만 실제로 작동합니다. 이 모델을 "671B급 성능"이라 부르는 것도, "37B급 모델"이라 부르는 것도 둘 다 부정확합니다. 메모리는 총량을 따르고, 속도와 연산 비용은 활성량을 따릅니다.

② 비공개 — 애초에 숫자가 없다

OpenAI는 GPT-4 기술보고서에서 경쟁 환경과 안전상의 이유를 들어 모델 크기를 포함한 세부 사항을 공개하지 않겠다고 명시했고(OpenAI, 2023), 이후 주요 상용 모델들도 대체로 같은 기조를 유지하고 있습니다. 인터넷에 도는 "○○는 몇 조 파라미터"라는 수치는 대부분 추정이거나 출처 없는 소문입니다. 즉 우리가 매일 쓰는 모델일수록 이 숫자를 알 수 없습니다.

③ 후처리 — 같은 크기, 다른 결과

사전학습 이후의 미세조정, 정렬 학습, 그리고 답하기 전에 얼마나 오래 '생각'하게 하느냐에 따라 같은 크기 모델의 결과가 크게 달라집니다. 파라미터 수는 이 모든 과정의 출발점일 뿐 도착점이 아닙니다.

4) 그러면 이 숫자는 언제 쓸모 있는가

파라미터 수가 무의미하다는 뜻은 아닙니다. 다만 읽는 용도가 다릅니다.

알고 싶은 것	파라미터 수로 알 수 있나
이 모델이 얼마나 똑똑한가	❌ (벤치마크·직접 테스트로 확인)
내 장비에서 돌아가는가	⭕ (총 파라미터 × 정밀도)
응답이 얼마나 빠를까	⭕ (MoE면 활성 파라미터 기준)
API 단가가 왜 이런가	⭕ (대체로 크기에 비례)
파인튜닝 비용이 얼마나 들까	⭕

즉 파라미터는 성능 지표가 아니라 인프라 지표입니다. "얼마나 잘하나"가 아니라 "얼마나 드나"를 알려주는 숫자입니다.

실전 — 숫자를 제대로 읽는 6가지 원칙

① 메모리는 암산으로 확인한다

필요 메모리(GB) ≈ 파라미터 수(B) × 2 (FP16 기준). 4비트로 양자화하면 대략 × 0.5로 줄어듭니다. 여기에 대화 맥락을 담는 캐시 메모리가 추가로 필요하므로, 실제로는 계산값보다 여유를 둬야 합니다.

8B 모델 → FP16 약 16GB / 4비트 약 4~6GB (일반 노트북·소비자 GPU 가능)
70B 모델 → 4비트로도 40GB 안팎 (워크스테이션급)
405B 모델 → 4비트로도 200GB 이상 (서버 다중 GPU)

② 'A' 뒤 숫자를 먼저 찾는다

MoE 모델을 볼 때는 총 파라미터보다 활성 파라미터가 실사용 감각에 가깝습니다. 메모리 확보는 총량 기준으로, 속도와 비용 예상은 활성량 기준으로 하면 대체로 맞습니다.

③ 클라우드 모델은 파라미터로 비교하지 않는다

ChatGPT, Claude, Gemini 같은 서비스형 모델은 크기가 공개되지 않으므로 애초에 비교 대상이 아닙니다. 이 경우 벤치마크 점수, 토큰당 가격, 응답 지연시간, 그리고 내 업무로 직접 돌려본 결과가 유일하게 의미 있는 지표입니다.

④ 작업 난이도에 맞춰 고른다

모든 일에 최대 모델이 필요하지는 않습니다. 오히려 대부분의 실무는 소형 모델로 충분합니다.

소형(1B~14B)으로 충분: 분류, 태깅, 정보 추출, 정형 요약, 형식 변환, 오탈자 교정
대형이 유리: 다단계 추론, 복잡한 코딩, 긴 문서 종합, 애매한 지시의 해석

⑤ 비용은 '크기 × 호출 횟수'로 본다

작은 모델을 여러 번 부르는 구조가 큰 모델을 한 번 부르는 것보다 저렴하고 빠른 경우가 많습니다. 반대로, 작은 모델이 실패해서 결국 큰 모델로 다시 돌린다면 두 배로 냅니다. 먼저 소형으로 시도하고 실패 시 대형으로 넘기는 단계 구성이 실무에서 가장 무난합니다.

⑥ 결국은 내 데이터로 확인한다

3편에서 다룬 원칙이 여기서도 그대로 적용됩니다. 공개 벤치마크는 참고치이고, 판단 근거는 자기 업무 샘플 20~30건을 돌려본 결과입니다. 파라미터 수로 고른 모델보다, 실제 문서로 테스트해 고른 모델이 거의 항상 낫습니다.

시사점

LG AI연구원이 2026년 4월 공개한 엑사원 4.5는 330억 파라미터 규모로, 자사 최대 모델의 약 7분의 1 크기이면서도 계약서·기술 도면·재무제표 같은 복합 문서 해석을 겨냥한 성능을 자사 발표 기준으로 제시했습니다(LG AI연구원, 2026). 크기를 키우는 대신 용도를 좁히는 방향입니다.

이 접근이 국내 환경에 특히 맞는 이유가 있습니다. 첫째, 오픈 웨이트로 공개된 중소형 모델은 외부 반출이 어려운 문서를 사내에서 처리하는 선택지를 열어줍니다. 둘째, 한국어 업무 문서처럼 좁고 반복적인 영역에서는 범용 초대형 모델의 폭넓은 지식보다 해당 형식에 대한 특화가 더 직접적인 성과로 이어질 가능성이 있습니다.

필자 의견: 국내 기업이 모델 도입을 검토할 때 가장 흔한 실수는 "가장 큰 모델을 쓰면 안전하다"는 판단입니다. 실제 병목은 대개 모델 크기가 아니라 자사 데이터 정리 상태에 있습니다. 같은 예산이라면 더 큰 모델보다, 중형 모델 + 잘 정리된 사내 문서 조합이 결과가 나은 경우가 많습니다.

전망 & 주목할 변수

개선 변수 — 희소화의 심화: MoE처럼 "크게 만들되 조금만 쓰는" 설계가 확산되면서, 총 파라미터와 실제 연산량의 격차는 더 벌어질 가능성이 높습니다. 이 경우 총량-활성량 병기 표기가 사실상의 표준이 될 전망입니다.
리스크 변수 — 비교 불가능성: 상용 모델의 크기 비공개가 이어지면 소비자가 모델을 객관적으로 비교할 근거는 벤치마크뿐인데, 벤치마크는 오염과 과적합 논란에서 자유롭지 않습니다. "믿을 만한 비교 기준의 부재" 자체가 앞으로의 리스크입니다.
체크포인트: ① 주요 오픈 모델의 활성 파라미터 공개 관행 정착 여부 ② 소비자 하드웨어(통합 메모리 기기)에서 실행 가능한 모델 크기의 상한 변화 ③ 국내 공공·기업의 온프레미스 도입에서 선택되는 모델 규모대

결론

B는 성능이 아니라 사양이다. 파라미터 수는 "얼마나 똑똑한가"가 아니라 "얼마나 큰 장비와 비용이 필요한가"를 알려주는 숫자입니다. 필요 메모리는 파라미터 × 2GB로 암산됩니다.
크기 하나만으로는 비교가 성립하지 않는다. 데이터량(친칠라), 활성 파라미터(MoE), 후처리 방식이 모두 결과를 바꿉니다. 게다가 우리가 가장 많이 쓰는 상용 모델은 애초에 크기를 공개하지 않습니다.
고르는 기준은 크기가 아니라 작업이다. 분류·추출·요약이라면 소형으로 시작하고, 실패할 때만 큰 모델로 올리십시오. 그리고 최종 판단은 언제나 자기 업무 샘플로 직접 돌려본 결과여야 합니다.