Kimi K3와 Fable 5, 작업별 라우팅이 더 나았어요

Fireworks AI가 Kimi K3와 Fable 5를 약 1,030개 작업에서 비교했어요. 두 모델의 전체 성능은 비슷했지만 잘 푸는 문제가 달랐고, 작업마다 적합한 모델을 고른 이론적 조합은 정확도 93%를 기록했어요. 1
핵심 요약
| 구분 | 핵심 | 왜 볼만한가요 |
| 비교 규모 | 소프트웨어 수정, 터미널, 알고리듬, 다중 언어, 법률 등 약 1,030개 작업을 비교했어요 | 단일 코딩 점수가 아니라 여러 실제 작업 유형을 함께 봤어요 |
| 성능 | 대표 소프트웨어 작업에서 K3는 92.4%, Fable은 92.6%였어요 | 평균은 비슷해도 세부 영역의 우위는 달랐어요 |
| 라우팅 | 정답을 낸 모델 중 더 저렴한 선택지를 고르는 오라클 방식이 정확도 93%를 기록했어요 | 모델 하나를 고정하는 것보다 작업별 선택이 나을 여지를 보여 줬어요 |
| 비용 | K3는 다섯 작업군 모두에서 Fable보다 비용 효율이 높았어요 | 품질뿐 아니라 토큰 가격, 캐시, 실행 시간까지 함께 봐야 해요 |
1. 모델 평균 점수보다 작업별 궁합이 더 선명했어요
Fireworks AI는 저장소 버그 수정, 긴 터미널 조작, 알고리듬 문제, 6개 언어 구현, 법률 과제를 두 모델에 맡겼어요. 대표 소프트웨어 작업의 성공률은 K3 92.4%, Fable 92.6%로 거의 같았어요. 하지만 세부 결과에서는 K3가 기호 수학과 개발 도구에 강했고, Fable은 웹과 데이터 시각화에서 앞섰어요. 다중 언어 작업에서는 Fable이 Java, Python, C++에서 우세했고 K3는 JavaScript와 Rust에서 대등했어요. 2
긴 터미널 작업에서도 차이가 났어요. K3는 보안, 암호 분석, 시스템 관리처럼 셸을 여러 차례 조작하는 문제에서 더 많은 단독 성공 사례를 냈어요. 반면 다중 언어 구현 범위에서는 Fable의 성적이 조금 더 좋았어요. 평균 점수 하나만 보면 놓치기 쉬운 차이예요.
정확도 93%는 실제 라우터 성적이 아니에요
이번 결과의 93%는 오라클 라우팅으로 계산했어요. 각 작업을 두 모델에서 모두 실행한 다음, 정답을 낸 선택지 가운데 비용이 덜 드는 모델을 고르는 방식이에요. 실제 서비스에서는 답을 미리 알 수 없으므로 라우터가 어느 모델이 잘 풀지 먼저 예측해야 해요.
오라클은 작업 유형에 따라 전체 요청의 72~96%를 K3에 배정했어요. K3를 기본 선택지로 두고 일부 어려운 문제만 Fable에 보내는 구성이 비용과 품질을 함께 맞출 수 있다는 가설이에요. Fireworks AI도 실제 라우터를 입증하려면 지금보다 약 10배 많은 데이터와 운영 환경 검증이 필요하다고 밝혔어요. 2
토큰을 많이 써도 청구 비용은 낮을 수 있어요
K3는 소프트웨어 작업 하나에 평균 약 55턴과 130만 토큰을 썼어요. Fable은 약 21턴과 13만 토큰을 썼어요. K3가 약 10배 많은 토큰을 읽었지만, 낮은 토큰 가격과 프롬프트 캐시 적중 덕분에 실행 비용은 더 낮았어요.
터미널 작업에서는 흐름이 반대였어요. Fable은 평균 약 64턴과 150만 토큰까지 사용했고 일부 실행은 시간제한에 걸렸어요. Fireworks AI의 계산에서 K3는 다섯 작업군 모두 비용 효율이 높았고, 긴 작업에서는 Fable 단독 사용보다 최대 약 50배 높은 비용 효율을 보였어요. 다만 실행 단계가 많으면 응답이 늦어질 수 있어요. 빠른 대화형 기능과 장시간 백그라운드 작업은 비용 기준을 다르게 잡아야 해요. 2
왜 중요한가요
AI 모델을 고를 때 평균 벤치마크 점수만 비교하면 실제 워크로드의 차이를 놓칠 수 있어요. 코드 수정, 시각화, 보안 터미널, 법률 검토는 필요한 능력과 실행 길이가 달라요. 팀이 보유한 작업 기록으로 라우터를 평가하면 비싼 모델을 모든 요청에 쓰지 않고도 품질을 유지할 가능성이 있어요. 2
이번 수치는 Fireworks AI가 자사에서 제공하는 K3의 가격과 캐시 조건을 반영한 결과예요. 오라클은 정답을 확인한 뒤 모델을 고르므로 실제 라우터보다 유리해요. 따라서 93% 정확도와 최대 50배 비용 효율을 일반적인 운영 환경의 확정값으로 받아들이기보다, 같은 업무 데이터로 재현해야 할 비교 기준으로 보는 편이 맞아요.
실무에서는 성공률과 비용만으로 부족해요. 응답 시간, 실패 후 재시도 횟수, 데이터 처리 조건, 모델 교체 비용도 함께 기록해야 해요. 라우팅을 도입한다면 작은 트래픽으로 두 모델의 실제 성공률을 먼저 쌓고, 잘못 보낸 요청이 품질과 비용에 미치는 영향까지 확인해 보세요.
참고 자료
'IT & AI' 카테고리의 다른 글
| Bento는 560KB HTML 파일 하나에 편집기와 발표 도구를 담았어요 (0) | 2026.07.23 |
|---|---|
| AI가 구현을 싸게 만들수록 제품 전략이 더 어려워지는 이유 (0) | 2026.07.23 |
| OmniRoute, 여러 AI 구독과 무료 티어를 한 엔드포인트로 묶어요 (0) | 2026.07.23 |
| 사람과 AI 에이전트가 같은 규칙으로 접속하는 OpenMMO (0) | 2026.07.22 |
| ChatGPT 광고가 검색 광고와 다른 이유 (0) | 2026.07.22 |