같은 작업을 Fable 5 하나로만 처리하면 어떤 경우 최대 50배 더 비쌉니다. Kimi K3라는 오픈모델을 같이 써서 작업을 나눠 맡기면, 정확도는 오히려 오르면서 비용은 크게 줄어듭니다.

AI 모델 호스팅 업체 Fireworks AI가 오픈모델 Kimi K3와 Anthropic의 Fable 5를 실전 에이전트 작업 1,030개에 나란히 돌려 비교했습니다. 두 모델을 상황에 맞게 번갈아 쓰는 라우팅 방식으로 93%의 정확도를 기록했고, 긴 에이전트 작업에서는 비용을 최대 50배까지 줄였다는 결과입니다.
출처: Kimi K3 is competitive with Fable; Kimi K3 + Fable is SoTA – Fireworks AI
전체는 비슷한데, 영역별로는 완전히 다른 승자
Fireworks는 실제 코드 저장소 버그 수정(SWE), 터미널 조작, 알고리즘 문제, 6개 언어 구현, 법률 문서 처리까지 다섯 가지 유형의 작업을 준비했습니다. 두 모델에 같은 작업 환경을 주고 풀게 한 뒤 정답률을 비교했습니다.
전체 평균만 보면 두 모델은 거의 동률입니다. 대표 지표인 SWE 벤치마크에서 K3는 92.4%, Fable은 92.6%를 기록했습니다. 언뜻 보면 “둘 다 비슷하네”로 끝날 결과입니다.
문제는 그 평균 안을 들여다봤을 때입니다. SWE 작업을 세부 영역별로 쪼개보면 K3는 수학 기호 처리와 개발 도구 관련 버그에서 강했고, Fable은 웹 프론트엔드와 데이터 시각화 작업에서 앞섰습니다. 여러 프로그래밍 언어를 오가는 작업에서도 Fable이 자바, 파이썬, C++에서 우위를 보인 반면 K3는 자바스크립트와 러스트에서 동등한 성적을 냈습니다.
터미널 작업에서는 차이가 더 뚜렷했습니다. 셸을 직접 조작하며 수십 번 명령을 주고받아야 하는 긴 작업 89개 중, K3는 Fable이 끝내 풀지 못한 문제들을 혼자 해결했습니다. 7z 압축파일 해시 분석, 암호 취약점 분석, 유출된 비밀정보 추적, 실시간 보안 취약점 대응 같은 작업들입니다. 89개 중 K3 단독 승리가 11건, Fable 단독 승리가 7건이었고, 보안·암호 관련 작업군은 K3가 통째로 가져갔습니다.
비용 차이는 성능이 아니라 ‘일하는 방식’에서 나온다
품질은 거의 동률인데 가격 격차는 왜 그렇게 클까요. Fireworks가 턴수와 토큰 사용량을 함께 측정해보니 답이 나왔습니다. 같은 작업이라도 두 모델이 일하는 방식 자체가 달랐습니다.
SWE 작업에서 K3는 평균 55번의 턴을 거치며 130만 토큰을 사용했습니다. 반면 Fable은 21턴, 13만 토큰 정도로 훨씬 적게 움직였습니다. 그런데 터미널 작업에서는 정반대 양상이 나타났습니다. 이번엔 Fable이 64턴, 150만 토큰을 쓰며 헤맸고 때로는 시간 제한에 걸려 아예 실패했습니다.
정리하면 어느 모델도 모든 영역에서 효율적이지는 않습니다. K3는 SWE에서 더 많이 고민하고, Fable은 터미널 작업에서 더 오래 헤맵니다. 여기에 프롬프트 캐싱(반복되는 입력을 다시 계산하지 않고 재사용하는 기법)까지 더해지면서, K3 쪽의 가격 우위가 실제 청구 비용에서 크게 벌어집니다.
실전에서는 이미 이렇게 나눠 쓰고 있다
이 라우팅 전략이 실험실 얘기만은 아닙니다. Together AI의 엔지니어 Zain Hasan은 실제로 어려운 문제는 프론티어 모델인 Fable에, 상대적으로 단순한 작업은 저렴한 오픈모델 GLM 5.2에 맡기는 방식으로 일하고 있습니다. GLM 5.2는 출력 토큰당 4.40달러로, Anthropic의 Opus 4.8보다 5분의 1, Fable보다 10분의 1 수준입니다.
Hasan은 아직 많은 개발자가 이런 계산을 하지 않는다고 말합니다. 회사에서 AI 비용을 딱히 통제하지 않다 보니, 남의 돈으로 쓸 때는 그냥 제일 강력한 모델부터 고르는 게 합리적인 선택이 되어버린다는 겁니다. Fireworks의 분석대로라면 이런 습관 자체가 미국 프론티어 랩들을 지켜주는 가장 큰 방어막인 셈입니다.
Fireworks는 오라클 라우팅(모든 작업을 두 모델에 각각 돌려본 뒤 가장 저렴한 정답을 고르는 이론상 최선의 방법)을 기준으로 삼았을 때, K3가 전체 작업의 72~96%에서 선택된다는 결과도 함께 제시했습니다. 실제 환경에서는 작업을 미리 두 모델에 다 돌려볼 수 없으니 라우터가 어느 모델이 나을지 예측해야 하는데, 이 예측 정확도를 끌어올리려면 지금보다 훨씬 많은 라우팅 데이터가 필요하다고 밝혔습니다.
참고자료: AI Coding Assistant Strategy Slashes Token Bills – IEEE Spectrum

답글 남기기