“오픈 모델이 프런티어(Frontier)에 얼마나 근접해 있는가”라는 질문에는 단 하나의 정답이 없으며, 이에 대한 답을 내놓는 모든 기사는 아마도 당신이 수행하지 않을 무언가를 측정하고 있을 것입니다. 그 격차는 작업의 종류에 따라 크기가 다르며, 당신의 작업에서 그 격차가 어느 정도인지는 단 한나절이면 파악할 수 있습니다.

일반적으로 던져지는 질문

이 질문은 단 하나의 품질 축이 있다고 가정합니다. 하지만 실제로는 그렇지 않습니다. 깔끔한 요약을 작성하는 모델은 12번의 턴(turn) 동안 함수 호출 (function-calling) 규약을 유지하는 데 서툴 수 있으며, 경시대회 수학 문제를 푸는 모델은 까다로운 형식 지정 (formatting) 지침을 따르는 데 더 못할 수 있습니다. 종합 점수 (Aggregate scores)는 이 모든 것을 하나의 숫자로 압축하며, 이러한 압축은 특정 직무를 가진 사람에게 중요한 방향으로 정보 손실 (lossy)을 일으킵니다.

또한 이 질문은 비교 대상이 고정되어 있다고 가정합니다. 하지만 그렇지 않습니다. 양측 모두 움직이고 있으며, 오픈 모델의 출시 (open releases)는 역사적으로 폐쇄형 프런티어 (closed frontier) 모델이 몇 달 전에 도달했던 능력 수준에 도달해 왔습니다. 즉, 정체기 (plateau)라기보다는 지연 (lag)인 것입니다. 그 지연에 대한 구체적인 수치는 출판되는 시점에 이미 구식이 되며, 이것이 바로 이 페이지에서 숫자가 아닌 방법을 제시하는 이유입니다.

격차가 작은 부분과 그렇지 않은 부분

이 부분은 특정 출시 (release)에 의존하는 것이 아니라 두 종류의 모델이 무엇을 위해 최적화(optimised)되었는지에 기반하므로 지속적인 유효성을 갖습니다.

중간 크기 클래스의 오픈 모델이 경쟁력을 갖는 부분

• 제한된 변환 (Bounded transformations). 요약, 재작성, 형식 간 번역, 문서에서 필드 추출 등. 정답의 형태가 정해져 있으며, 단 한 번의 패스 (one pass)로 작업이 완료되는 경우입니다.
• 분류 및 라우팅 (Classification and routing). 특히 프롬프트에 몇 가지 예시를 제공할 때 유용합니다. 소규모 오픈 모델이 단순히 적절할 뿐만 아니라, 속도가 빠르고 출력 공간 (output space)이 매우 작기 때문에 더 선호되는 경우가 많은 작업입니다.
• 파인튜닝 (Fine-tuning) 이후의 도메인 작업. 특정 좁은 도메인에 맞춰 튜닝된 오픈 모델은 해당 도메인에서 범용 프런티어 (frontier) 모델을 이길 수 있으며, 이는 오픈 웨이트 (open weights) 모델이 가진 가장 강력한 구조적 논거입니다.
• 대량의 저위험 생성 (High-volume, low-stakes generation). 호출당 비용이 지배적이며, 간혹 발생하는 불완전함이 후속 단계 (downstream)에서 흡수될 수 있는 경우입니다.

격차가 실제로 발생하는 부분

• 긴 다단계 에이전트 작업 (Long multi-step agentic work). 신뢰성이 복리로 작용합니다. 단계별로 발생하는 작은 불리함이 20번의 도구 호출 (tool calls)을 거치면서 작업 전체에 걸친 커다란 불리함으로 변합니다.
• 긴 컨텍스트 (Long context) 하에서의 어려운 추론. 수만 개의 토큰에 걸쳐 수많은 제약 조건을 동시에 유지하는 작업입니다.
• 압박 상황에서의 지시 준수 (Instruction adherence). 어려운 과업을 수행하면서 동시에 복잡한 형식을 지키는 능력은 프런티어 모델의 사후 학습 (post-training) 능력이 드러나는 지점입니다.
• 세계 지식의 폭. 파라미터 수 (parameter count)는 예산과 같아서, 모델의 크기가 작을수록 모호한 사실들에 할당할 수 있는 예산이 적습니다.
• 기본적으로 제공되는 멀티모달 (multimodal) 또는 도구 통합 (tool-integrated) 작업. 오픈 생태계에서도 자주 제공되지만, 더 많은 조립 과정이 필요합니다.

리더보드 (Leaderboard)를 읽는 법

최신 소스를 반드시 사용해야 합니다. 특정 모델의 이름은 그 어떤 페이지보다 빠르게 구식이 되기 때문입니다. 리더보드를 사용하되, 다음의 보정 사항들을 적용하십시오:

• 보류된(held-out) 또는 순환하는(rotating) 평가를 선호하십시오. 정적인 공개 벤치마크 (benchmark)는 시간이 지남에 따라 학습 데이터로 유출되며, 오염된 데이터 세트에서의 점수는 암기 (memorisation) 능력을 측정할 뿐입니다.
• 채팅 품질을 위해서는 인간 선호 아레나 (human-preference arenas)를, 작업 특정 품질을 위해서는 작업 특정 벤치마크 (task-specific benchmarks)를 선호하십시오. 어느 하나를 다른 용도로 사용하지 마십시오.
• 하네스 (harness)를 확인하십시오. 동일한 모델이라도 프롬프트 템플릿 (prompt templates), 샘플링 설정 (sampling settings), 답변 추출 규칙 (answer-extraction rules)에 따라 점수가 다르게 나타납니다. 하나의 하네스 내에서의 비교는 의미가 있지만, 서로 다른 하네스 간의 비교는 대개 의미가 없습니다.
• 무엇이 서빙되었는지 확인하십시오. 오픈 모델 (open model)의 양자화된 (quantised) 배포 버전은 참조 가중치 (reference weights)와 동일한 결과물이 아닙니다. 점수와 서빙 형식 (serving format)은 반드시 함께 고려되어야 합니다.
• 이름이 아닌 크기 클래스 (size class)를 읽으십시오. 당신의 메모리 예산 내에서 가장 성능이 좋은 모델이 어떤 점수를 기록하는지 확인하십시오. 그것이 당신이 실제로 직면한 제약 조건이기 때문입니다.

이러한 방식으로 리더보드 (leaderboard)를 사용하면 결정이 아닌, 세 명의 후보에 대한 짧은 명단 (shortlist)을 얻게 됩니다. 결정은 그다음 단계에서 이루어집니다.

결정을 내리는 평가 (eval) 구축하기

당신의 실제 트래픽에서 추출한 50개의 예시는 이 목적을 위해 그 어떤 공개 벤치마크보다 뛰어납니다. 왜냐하면 이 데이터들은 당신이 관심을 두는 분포 (distribution)에서 추출되었으며, 그 무엇도 이 데이터로 학습되지 않았기 때문입니다.

• 정직하게 샘플링하세요 (Sample honestly). 잘못된 결과가 나왔던 입력을 포함하여 실제 입력을 사용하세요. 쉬운 사례들로만 구성된 평가 세트(eval set)는 모든 모델이 괜찮다는 결과만을 보여줄 것입니다.
• 출력을 확인하기 전에 채점 기준(grader)을 먼저 작성하세요. 가능한 한 기계적인 방식(mechanical)을 활용하세요: 스키마 유효성(schema validity), 필수 필드 존재 여부, 코드 컴파일 여부, 수치 답변 일치 여부 등입니다. 기계적으로 확인할 수 없는 부분에 대해서만 인간의 판단을 남겨두고, 기준을 먼저 기록하세요.
• 모든 후보 모델에 대해 샘플링 설정(sampling settings)을 통일하세요. Temperature 0과 동일한 시스템 프롬프트(system prompt)를 사용하여, 모델의 성능이 아닌 설정값(configuration)을 비교하는 일이 없도록 하세요.
• 프롬프트는 모델별로 단 한 번만 조정하세요. 프런티어(frontier) 모델에 맞춰 튜닝된 프롬프트를 오픈 모델에 제공하는 것은 모델의 능력(capability)이 아니라 프롬프트 전이(prompt transfer) 능력을 테스트하는 것이 됩니다. 각 후보 모델에 대해 정직하게 한 번의 조정 기회만 부여하세요.
• 동일한 실행(run)에서 비용과 지연 시간(latency)을 함께 기록하세요. 비용이 5분의 1 수준이면서 점수가 3점 낮은 모델은 패배한 것이 아닙니다.
• 평가 세트를 버전 관리(version control) 시스템에 유지하고, 모델이 변경될 때마다 다시 실행하세요. 이것은 다음 비교를 저렴하게 만들어주는 결과물(artefact)이며, 이 작업을 한 번 제대로 수행할 가치가 있는 이유입니다.

판단 내리기 (Making the call)

기업별이 아닌 태스크(task)별로 결정하세요. 대부분의 시스템은 요청 난이도의 분포(distribution)를 가지고 있으며, 유용한 질문은 오픈 모델이 당신의 품질 기준(quality bar) 내에서 그 분포의 어느 정도 비율을 처리할 수 있느냐 하는 것입니다. 이는 보통 큰 비율을 차지하지만, 근접하지 않은 어려운 꼬리(hard tail) 부분이 존재합니다. 승자를 고르기보다는 그에 따라 경로를 지정(route)하세요.

당신의 숏리스트(shortlist)에 있는 후보들은 별도의 프로비저닝(provisioning) 없이도 이미 서비스 중인 경우가 많습니다. 호스팅된 오픈 웨이트(hosted open weights) 모델은 폐쇄형 모델과 동일한 카탈로그에 위치하므로, 양측 모두에 동일한 평가 세트를 실행하는 것은 모델 문자열을 변경하는 문제로 간단히 해결됩니다. 이는 평가의 편의를 위한 것이지, 프로덕션(production) 환경에서 어디서 실행해야 하는지에 대한 논거는 아닙니다. 데이터가 네트워크를 벗어날 수 없다면, 숏리스트는 동일하며 배포는 로컬(local)에서 이루어집니다.

관련 항목 (Related)

• 시간에 따른 오픈(Open)과 클로즈드(Closed) 모델 간의 격차
• 소형 언어 모델 (Small Language Models): 1–8B 모델이 실제로 할 수 있는 것
• 어떤 양자화 (Quantisation) 버전을 다운로드해야 할까요?