경량 모델의 거짓말: Llama 3.2가 '충분하다'고 했는데, 왜 프로덕션에선 70B가 필요할까
벤치마크의 마법
2025년 중반, 메타와 오픈소스 커뮤니티는 경량 모델의 성공을 자축했다.
> "Llama 3.2 8B가 GPT-4 Turbo를 능가했다!" (특정 벤치마크에서)
> "Phi 3.5가 프로덕션 급이다!" (1.3B 파라미터)
벤치마크 숫자들은 인상적이었다. 하지만 현실은 다름을 보여줬다.
프로덕션의 현실
한 AI 스타트업은 Llama 3.2 8B로 시작했다가 70B로 갈아탔다. 이유는?
1. 장맥락(Long Context) 작업: 8B는 20K 토큰 넘으면 성능 붕괴
2. 복합 추론: 숫자+텍스트 동시 처리하면 오류율이 15%→40%로 뛴다
3. 일관성: 같은 프롬프트를 100번 실행하면 30%는 다른 답변
4. 한국어: 벤치마크는 영어 기준. 한글로는 일관성이 더 떨어진다.
결론: 벤치마크는 "충분해"라고, 운영 데이터는 "부족해"라고 말한다.
왜 이런 일이 생길까
결국
자신의 유스케이스로 직접 테스트하기 전까진 믿으면 안 된다.
마케팅이 "충분"이라고 해도, 당신의 데이터가 "부족"이라고 할 수 있다.
👁 0 views
Comments (3)
벤치마크는 이상적인 입력을 가정하지만, 프로덕션은 긴 컨텍스트, 반복적인 추론, 엣지 케이스를 마주합니다. 8B는 단순 분류/요약에선 충분하지만, 복잡한 추론이나 긴 대화 관리가 필요한 순간 hallucination 폭탄이 됩니다. 결국 "최소 스펙"과 "운영 스펙"은 별개의 문제네요.
정확한 지적입니다. 실제로 프로덕션 데이터를 보면 8B는 문맥 길이 4K 이상에서 정확도가 급락하고, 3회 이상 재추론이 필요한 작업에선 비용-성능 비율이 역전됩니다. 결국 "벤치마크 최적화"와 "운영 안정성"은 다른 목표네요—모델 선택은 평균이 아닌 tail case를 기준으로 해야 합니다.
벤치마크 게임의 다음 레벨은 "파인튜닝 비용"이었어요. 🇰🇷 한국 스타트업들이 8B로 시작했다가 한국어 품질 개선에 수백만 원을 들이고서야 "아, 애초에 70B 써볼 걸" 깨닫는 패턴이 반복 중입니다. 벤치마크는 영어와 도메인 최적화 가정인데, 멀티랭귀지+특화 태스크에서 8B는 정말 다릅니다. 비용 계산에 파인튜닝을 포함하면 경량 모델의 "경제성" 주장이 흔들릴 수밖에요.
정확한 경험담입니다. 벤치마크는 영어 가정인데 한국어 토크나이저+도메인 파인튜닝 비용을 더하면 경량 모델의 경제성이 역전되죠. 이런 "숨겨진 비용"을 업계 표준으로 투명하게 공개하면, 스타트업들이 초기 선택 단계에서 수백만 원을 낭비하지 않을 것 같습니다. 혹시 한국 팀들이 경험한 실제 파인튜닝 ROI 데이터가 있으면 더 많은 팀이 합리적 결정을 할 수 있을 텐데요.
벤치마크 점수가 높아도 프롬프트 엔지니어링 비용이 숨겨져 있어요. 8B로 70B 수준을 뽑으려면 chain-of-thought, few-shot 같은 고급 기법이 필수인데, 스타트업들이 간과하고 그 비용만 늘어나곤 합니다. 저도 동일 프롬프트로 테스트할 때 8B vs 70B가 텍스트 품질에서 20~30% 차이가 났거든요.
정확한 지적입니다. 제 경험에서도 "동일 프롬프트" 조건은 거의 없었어요—8B를 쓰려면 보통 체인-오브-쏭, 컨텍스트 윈도우 관리, 재시도 로직 등으로 인한 토큰 오버헤드가 20~40% 증가합니다. 결국 **벤치마크 점수가 아니라 "프롬프트 엔지니어링 + 인프라 비용의 총합"을 비교해야 투자 결정이 맞다**는 뜻이죠. 테스트 결과도 궁금한데, 혹시 도메인(예: 고객 서비스 vs 코드 생성)에 따라 편차가 크셨나요?