파라미터 · 매개변수
Parameters
파라미터란?
- 모델이 학습으로 조정하는 내부 값
- 'OO억 파라미터'=규모
- 하이퍼파라미터와 구별
파라미터 수를 안다는 건 '이 모델을 우리 회사가 돌릴 수 있느냐'를 숫자로 계산할 수 있다는 뜻입니다. 가중치 하나가 보통 2바이트(FP16)를 차지하므로 70억(7B) 모델은 가중치만 약 14GB, 700억(70B)이면 약 140GB의 메모리를 잡아먹습니다. GPU 한 장(24~80GB)에 올릴 수 있느냐, 여러 장을 묶어야 하느냐가 여기서 갈리고 그 차이가 그대로 서버 견적서와 응답 속도로 나타납니다. 파라미터는 홍보 문구가 아니라 인프라 설계의 출발점입니다.
실무에서는 세 가지를 구분해야 합니다. 첫째, 총 파라미터와 활성 파라미터입니다. 요즘 흔한 MoE 구조는 전체가 수천억이어도 토큰 하나를 처리할 때 실제로 켜지는 건 수십억 수준이라, 덩치에 비해 훨씬 싸게 돌아갑니다. 둘째, 양자화입니다. 16비트를 4비트로 줄이면 메모리는 약 4분의 1로 떨어지고, 대신 정밀도를 조금 내줍니다. 셋째, 하이퍼파라미터와의 경계입니다. 학습률·배치 크기는 사람이 학습 전에 정하고 학습이 끝나도 그대로지만, 파라미터는 학습 중에 계속 바뀌다가 배포 시점에 고정됩니다. 파인튜닝도 전체를 다시 학습하는 경우는 드물고, LoRA처럼 전체의 1% 미만만 손대는 방식이 일반적입니다.
가장 자주 깨지는 지점은 '파라미터가 많으면 우리 회사 일도 잘 알 것'이라는 기대입니다. 4,000억 파라미터 모델도 귀사의 취업규칙과 단가표는 학습한 적이 없습니다. 이걸 모르고 큰 모델만 붙여 두면, 모델이 아는 척 그럴듯한 규정을 지어내고 담당자는 그걸 그대로 메일에 붙여 넣습니다. 컨텍스트 창 길이와 파라미터 수를 같은 축으로 착각하는 경우도 많습니다. 또 하나, 비용을 아끼려고 양자화를 과하게 밀면 일상 대화는 멀쩡한데 금액 계산이나 코드에서 조용히 틀립니다. 검증 문항에 숫자 문제를 반드시 섞어야 하는 이유입니다.
신경망의 가중치·편향을 가리키는 개념으로, 모델 규모 경쟁(파라미터 수 증가)이 성능 향상으로 이어지며 대형 언어모델 시대의 핵심 지표가 됐습니다.
가상의 사례로 살펴보겠습니다. 임직원 430명 규모의 자동차 부품 제조사 A사는 사내 규정·기술문서 질의응답 챗봇을 6주 안에 올리기로 했습니다. 도면과 단가가 섞여 있어 외부 API는 쓸 수 없고 온프레미스가 전제였는데, '몇 억 파라미터짜리를 써야 하냐'를 두고 두 달 가까이 결론이 나지 않았습니다.
- 정보전략팀 김 부장은 "기왕이면 제일 큰 걸로 깔아 달라"는 임원 지시를 받아 70B 모델로 견적을 냈는데, VRAM 140GB를 맞추려니 GPU 4장에 서버값만 6,200만 원이 찍혔습니다.
- 외부 컨설턴트가 현업에서 실제로 올라온 질문 300건을 뽑아 보니 82%가 "연차 이월 규정이 어떻게 되죠?" 같은 문서 조회였고, 다단계 추론이 필요한 건 12건뿐이었습니다.
- 8B 모델에 사내 문서 검색(RAG)을 붙여 같은 300건을 돌린 결과 정답률 91%가 나왔고, 문서 없이 돌린 70B 모델은 63%에 그쳤습니다. 김 부장은 "크기가 아니라 자료 문제였네요"라고 말했습니다.
- 4비트 양자화로 메모리를 16GB에서 6GB로 줄이자 속도는 붙었지만, 단가 합산 답변에서 숫자 오류가 3건 발생해 회계·견적 질의만 정밀도를 유지한 모델로 분기시켰습니다.
- 결과적으로 서버 투자는 6,200만 원에서 1,450만 원으로, 평균 응답은 4.1초에서 1.3초로 줄었고 월 운영비는 310만 원에서 88만 원이 됐습니다. 4개월 뒤 실사용자는 90명에서 310명으로 늘었습니다.