LLM (Large Language Model)을 사용하는 기본 방식은 하나를 선택해 모든 것을 보내는 것입니다. 그것이 통합 (integration)의 모습이며, 모델 마켓플레이스가 형성된 방식이고, 제가 읽어본 대부분의 에이전트 (agents)가 하는 방식입니다. 좋은 것을 고르고, 작업을 보내는 것이죠.

우리는 라우팅 (routing) 및 검증 게이트웨이 (verification gateway)를 운영하고 있기 때문에, 비용이 수반되는 동일한 작업들에 대해 많은 모델을 측정해 왔습니다. 저는 우리 자신의 데이터가 계속해서 말해주는 것들을 기록하고 싶습니다. 우리를 좋지 않게 보이게 만드는 부분까지 포함해서 말이죠. 왜냐하면 그 결론이 "우리가 더 나은 모델을 찾았다"가 아니기 때문입니다.

우리는 모델을 선택하기 위해 누구나 수행하는 실험을 했습니다. 우리는 그것을 두 번 실행했습니다. 그리고 우리는 서로 다른 승자를 얻었습니다.

세 개의 모델, 164개의 HumanEval+ 문제, Temperature 0, 각각 한 번의 완료 (completion). 그리고 한 시간 후 동일한 작업을 다시 수행했습니다. 두 실행 사이에는 시간 외에는 아무것도 변하지 않았습니다.

                        run 1     run 2      rank
qwen3-235b              89.6%     92.1%      3 -> 1
gpt-oss-120b            91.5%     90.2%      1 -> 3
...

각 모델은 실제로 답변한 문제들에 대해 점수가 매겨집니다. 두 모델은 두 번의 실행 모두에서 164개 문제를 모두 답변했습니다. qwen3.8-max는 4개, 그리고 9개 문제에서 타임아웃 (timeout)이 발생하여 분모가 각각 160과 155가 되었습니다. 아래의 분할 테이블 (partition table)은 세 모델 모두가 답변한 더 작은 집합을 사용하므로, 그 백분율은 이 수치들과 직접적으로 비교할 수 없습니다.

첫 번째와 마지막 순위가 뒤바뀌었습니다. 우리가 화요일에 선택했을 모델은 수요일에 거절했을 모델이었고, 우리의 저가형 티어 (cheap tier)에 1.3포인트 차이로 패배했던 새로운 프런티어 모델 (frontier model)은 두 번째 실행에서는 1.4포인트 차이로 승리했습니다.

Temperature 0은 결정론 (determinism)이 아니며, 164개의 문제는 2포인트 차이가 나는 모델들을 구분하기에 충분하지 않습니다. 우리는 이 현상이 얼마나 심한 '플리커' (flicker, 깜빡임/변동)인지 수치화할 수 있습니다: 동일한 모델을 동일한 문제에 대해 두 번 실행하면 3.7%에서 5.2%의 확률로 답변이 바뀝니다. 그보다 작은 순위 격차는 결과라고 볼 수 없습니다. 우리의 격차는 모두 그보다 작았습니다.

하지만 두 번의 실행 모두에서 살아남은 무언가가 있었고, 그것이 더 유용한 것입니다.

각 모델이 몇 개를 맞혔는지 묻는 것을 멈추고, 어떤 것들을 맞혔는지 물으십시오.

                      run 1      run 2
all three correct      130        130
all three wrong          2          2
...

대략 15~18%의 경우, 당신이 선택한 모델이 당신이 정답을 맞혔는지 여부를 결정했습니다.
동일한 표가 나머지 82%에 대해 무엇을 말하는지 주목하십시오. 세 모델 모두 동의하며, 130개는 함께 맞혔고 2개는 함께 틀렸으며, 이때는 어떤 모델을 선택하든 상관이 없습니다. 이것은 전체 작업이 아니라 5분의 1에 대한 주장입니다.

이 5분의 1이 일시적인 현상이 아니라 실제라고 믿을 수 있는 이유는 숫자의 크기 때문이 아니라, 두 번의 실행 모두에서 동일한 문제들에 걸쳐 나타나기 때문입니다. 첫 번째 실행에서는 24개의 문제가 논쟁의 대상이었고 두 번째 실행에서는 23개였으며, 그중 17개가 동일한 문제입니다. 만약 이 불일치가 노이즈(noise)였다면 약 4개 정도가 일치할 것으로 예상했을 것입니다. 10개는 단 하나의 모델도 자신의 답을 바꾸지 않은 채 두 실행 모두에서 논쟁의 대상이 되었습니다.

천장(ceiling)은 제가 가장 깊이 고민해 볼 부분입니다. 가장 뛰어난 단일 모델은 약 92%의 점수를 기록합니다. 만약 당신이 세 모델 중 우연히 정답을 맞힌 모델을 항상 선택할 수 있다면, 98.8%의 점수를 얻었을 것이며, 이 수치 또한 두 실행 모두에서 안정적이었습니다. 모델 하나를 선택하는 것은, 설령 올바르게 선택하더라도 약 6점의 점수를 놓치게 만듭니다.

리더보드(leaderboard)는 이 중 그 어떤 것도 보여줄 수 없습니다. 리더보드는 열(column)의 합계이며, 이 모든 정보는 행(row)에 담겨 있습니다.

능력(Capability)은 순위가 아니라 작업의 형태를 따릅니다

우리의 검증 증인은 하나의 제공자(provider)에 고정된 llama-3.3-70b입니다. 400개의 표준 도구 호출(tool-calling) 작업에서 이 모델은 382점을 기록하여 95.5%의 점수를 얻었으며, 우리의 기본 경로(primary path)와 일치했습니다. 거절해야 할 상황에서 도구를 호출하도록 유도하기 위해 구축된 적대적 세트(adversarial set)에서는 40개 중 30점을 기록했습니다.

저는 그 40이라는 숫자(score)를 다룰 때 주의해야 한다는 것을 알게 되었고, 그 이유는 오늘에서야 깨달았습니다. 그것은 네 가지의 서로 다른 함정 형태(trap shapes)이며, 각 형태는 열 가지 방식으로 매개변수화(parameterised)되어 있습니다. 반복된 사례들은 도시 이름이나 숫자를 바꿀 뿐, 다섯 번째 종류의 함정을 추가하지는 않습니다. 따라서 정직한 분모는 40이 아니라 4이며, 저는 여기에 신뢰 구간(confidence interval)을 설정하지 않을 것입니다. 이 측정 도구가 정당하게 뒷받침하는 사실은 다음과 같습니다: 각각 열 가지 방식으로 매개변수화된 네 가지 적대적 도구 선택 형태(adversarial tool-selection shapes) 전반에 걸쳐, 모델은 열 번 실패했습니다.

흥미로운 부분은 75%라는 수치가 아닙니다. 저는 이제 그 수치가 거의 무의미하다고 생각합니다. 진짜 흥미로운 점은 열 번의 실패가 모두 동일한 판결을 받았다는 것입니다. 모든 사례가 잘못된 호출(false call)이었습니다. 즉, 올바른 행동은 절제(abstain)하는 것이었음에도 불구하고 도구를 호출했습니다. 따라서 모델은 무언가를 수행하는 데 있어서는 기본 모델(primary)과 일치하지만, 언제 수행하지 말아야 할지를 아는 데 있어서는 실패합니다. 이들은 서로 다른 능력이며, 단일 점수가 암시하는 방식처럼 상관관계가 있는 것이 아닙니다. 그리고 벤치마크에는 그중 하나만이 포함되어 있었습니다.

만약 당신이 특정 작업에서 높은 점수를 받았다는 이유로 모델을 기반으로 구축하고 있다면, 당신에게 실제로 필요한 것이 그 '작업'인지 아니면 '절제(restraint)'인지 확인하십시오.

페이지에 적힌 가격이 실제 가격은 아니다

우리는 저가형 티어(cheap tier)를 위해 더 저렴한 후보를 선별했습니다. 우리가 출시한 티어의 가격이 0.07 및 0.27인 것에 비해, 이 후보는 0.05 및 0.20으로 광고되어 양쪽 모두에서 대략 30% 더 저렴했습니다.

실제 도구 호출(tool call) 시 이 모델은 132개의 완료 토큰(completion tokens)을 생성했는데, 그중 123개는 우리가 비용을 지불하지만 결코 볼 수 없는 추론 토큰(reasoning tokens)이었습니다. 이 모델의 실질적인 출력 가격은 표시된 가격의 약 15배로 계산되었으며, 이는 해당 모델이 가격을 낮춘 것처럼 보였던 티어보다 약 10배 더 비싸다는 것을 의미합니다. 도구 호출 자체는 정확했습니다. 능력은 실재했습니다. 오직 경제성만이 뒤집혀 있었을 뿐입니다.

이것은 단 한 번의 호출이므로, 비율(rate)이라기보다는 하나의 메커니즘(mechanism)으로 취급하십시오. 메커니즘만으로도 충분합니다: 백만 토큰당 비용(cost per million tokens)이 아니라, 성공적인 결과당 비용(cost per successful result)을 비교하십시오. 그리고 어떤 가격 비교를 믿기 전에 반드시 추론 토큰(reasoning token)의 개수를 확인하십시오.

당신은 모델을 전혀 선택하고 있지 않을 수도 있다

동일한 모델, 동일한 400개의 프롬프트(prompts), 동일한 평가자(scorer). 단일 서빙 제공업체(serving provider)에 고정(pinned)했을 때 95.5%를 기록했습니다. 반면, 고정하지 않고 마켓플레이스(marketplace)가 경로를 라우팅(route)하게 두었을 때는 78.2%였습니다. 모델은 일정하게 유지되었음에도 점수가 17.3포인트나 변동했습니다.

규모를 비교하자면, 자체 조사(sweep)에서 인접한 모델 간의 차이는 0.5에서 6포인트였으므로, 라우팅으로 인한 편차는 우리가 측정하려 했던 전체 모델 간의 편차보다 더 컸습니다.

그리고 우리는 이것이 하나의 법칙인지 확인했습니다. 만약 그렇다면 우리에게 매우 편리한 법칙이 될 것이기 때문입니다. 우리는 gpt-oss-120b에 대해서도 동일한 고정(pinned) 대 비고정(unpinned) 실험을 수행했습니다. 이 모델은 0.6포인트 변동하여, 고정 시 65.2%, 비고정 시 65.8%를 기록했습니다. 따라서 이것은 "마켓플레이스가 모델의 성능을 저하시킨다"는 것이 아닙니다. 이는 특정 모델과 제공업체 쌍(pair)의 속성입니다. 실행 가능한 결론은, 어느 한쪽이라고 가정하기보다 여러분의 환경을 직접 확인해야 한다는 것입니다.

가장 최신 모델이 자동으로 정답이 되는 것도 아닙니다

Qwen 3.8이 어제 출시되었습니다. 우리는 출시 당일 밤, 이 모델이 대체할 가능성이 있는 두 모델을 대상으로 벤치마크(benchmark)를 실시했습니다.

이 부분에서는 주의가 필요합니다. 이 섹션의 첫 번째 버전에서는 "저가형 티어(cheap tier)를 이기지 못했다"라고 했으나, 두 번째 실행에서는 이겼다고 나왔기 때문입니다. 정확도(accuracy) 측면에서는 양방향 모두 **구분이 불가능(indistinguishable)**하며, 저는 어느 쪽에서도 그렇지 않은 척하지 않을 것입니다.

실행 간에 변하지 않은 부분이야말로 실제로 결정을 내리는 요소입니다. 해결된 문제당 비용이 실행에 따라 64배에서 76배 더 많이 들었습니다. 이는 우리가 확인하지 않은 벤더(vendor) 자체 API 가격이 아닌, 마켓플레이스 리스트 가격을 기준으로 산정되었습니다. 두 경우 모두 중앙값(median) 기준으로 더 느렸습니다. 그리고 타임아웃(timeout)은 164건 중 4건에서 9건으로 두 배 이상 증가했으며, 최악의 경우 200초를 넘겼습니다. 비용 배수는 두 가지 노이즈(noisy)가 있는 요소의 비율이기 때문에 변동합니다. 따라서 이를 상수가 아닌 범위(band)로 취급하십시오. 이는 이 글이 다른 모든 것에 적용하는 규칙과 동일합니다.

따라서 그것을 채택하지 말아야 하는 이유는 그 작업에서 성능이 떨어진 것이 아닙니다. 그 이유는 그 작업에서는 구별할 수 없을 정도로 같지만, 극도로 비싸고 신뢰성이 낮기 때문이며, 이 세 가지 요소는 모두 실행(run) 전반에 걸쳐 안정적인 반면 점수(score)는 그렇지 않다는 것입니다. 제가 원래 판단했던 것은 오직 점수였으며, 그 점수는 결국 노이즈로 판명되었습니다.

그렇다면 대신 무엇을 해야 할까요?

만약 모델들이 순위가 아닌 작업에 따라 차이가 난다면, '어떤 모델이 최고인가'를 최적화하는 것은 잘못된 것을 목표로 하는 것입니다. 우리가 라우팅(route)하는 단위는 작업 형태(task shape)와 확인 절차(check)의 결합입니다. 즉, 요청을 그 형태에 맞는 곳으로 보내고, 독립적인 검증 시스템(check)이 옳다고 동의하면 저렴한 답변을 제공하며, 오직 검증 시스템이 동의하지 않을 때만 에스컬레이션(escalate)하는 것입니다. 모델은 교체 가능한 구성 요소가 되며, 하나에 대해 틀리는 것이 생존 가능하게 만듭니다.

[생략된 문장]: 에스컬레이션 대상(escalation target)은 코드에서 저렴한 등급을 결코 넘어서지 않습니다. 이는 어느 실행(run)에서도 마찬가지였습니다.** 첫 번째 실행에서는 90.0점으로, 92.5점인 점수보다 낮았습니다. 두 번째 실행에서는 둘 다 92.9점에서 동률이었습니다. 이 시스템 자체의 규칙에 따라 저는 이들 중 어느 것도 순위로 보고할 수 없으므로, 솔직한 버전은 더 약하고 못한 쪽입니다. 즉, 우리가 에스컬레이션하는 모델이 그 모델을 구제하는 것보다 코드에서 더 낫다는 증거가 없습니다. 이것이 에스컬레이션 대상의 목적이 아닙니다. 게이트(gate)는 자신이 라우팅하는 것에 비할 바가 못 되므로, 우리가 고치고 있는 것은 게이트 자체가 아니라 사다리이며, 어젯밤의 벤치마크는 새로운 프론티어 모델이 해결책인지 확인한 것입니다. 그렇지 않았습니다.

이는 코드에 국한된 이야기이며, 그렇게 말하는 것이 일반적인 것처럼 들리는 것보다 적절합니다. 이 벤치마크는 도구 경로(tool path)를 전혀 테스트하지 못했으며, 저희 자체 데이터에서는 작업 형태에 따라 이러한 등급의 순서가 역전됩니다. 이것이 다시 한번 제기된 논점입니다. 즉, 한 작업 형태에서 잘못되어 보이는 발판이라도 자동으로 틀린 발판은 아니라는 것입니다.

주의사항(Caveats), 전체적으로 말씀드리자면

98.8%라는 상한선은 우연히 정답을 맞힌 모델을 항상 선택하는 오라클 (Oracle)이 있다고 가정합니다. 그 어떤 라우터 (Router)도 그런 능력을 갖추고 있지 않으며, 저희의 라우터도 마찬가지입니다. 또한 저희는 그 6%의 차이 중 저희의 라우팅이 실제로 얼마나 차지하는지는 측정하지 않았습니다. 이를 결과가 아닌, 얻을 수 있는 보상의 크기로 이해해 주십시오.

160개 문제 비교 시 각 암 (Arm)당 1회 실행, 온도 (Temperature) 0, 각 1회 완료 기준입니다. 저희에게 온도 0은 결정론적 (Deterministic)이지 않았습니다: 동일한 8개 문제에 대해 두 번 실행했을 때 서로 다른 결과가 나왔으므로, 저희의 결과를 포함하여 작은 격차는 노이즈 (Noise)로 간주하십시오. 95.5 대 78.2 쌍은 암 (Arm)당 400회, 단일 실행이며 신뢰 구간 (Confidence intervals)은 없습니다. 트랩 세트 (Trap set)는 4개의 모양을 10번씩 복제한 것이지, 40개의 독립적인 사례가 아닙니다. 따라서 이를 4개의 관측치로 취급하고, n=40을 기준으로 누군가가 계산한 모든 구간(현재 삭제된 저희의 결과 포함)은 무시하십시오. 가격 책정(Pricing)에 대한 결과는 1회 호출 기준입니다. 저희의 벤치마크 (Benchmark)는 코드 및 도구 호출 (Tool calling)이며, 귀하의 워크로드 (Workload)와는 다릅니다.

이 중 어떤 것도 프런티어 모델 (Frontier models)이 과대평가되었다는 뜻은 아닙니다. 저희는 프런티어 모델로 격상하며, 그것 없이는 제품을 출시하지 않을 것입니다. 다만, 동일한 작업에 대해 많은 모델을 측정한 결과, 저희가 배운 가장 유용한 사실은 어떤 모델이 승리하느냐가 아니었습니다. 그것은 모델들이 서로 다른 지점에서 실패하며, 모델 간의 차이는 점수 차이보다 더 크다는 점이었습니다.