Kimi K3는 Fable과 경쟁하며, 두 모델의 조합은 최고 수준의 성능을 달성함

 (fireworks.ai)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 약 1,030개 에이전트 작업에서 Kimi K3와 Fable 5를 비교한 결과, 작업별 라우팅은 93% 정확도로 개별 모델보다 높은 품질을 달성함
  • SWE·터미널·알고리듬·다중 언어·법률 작업에서 전체 성능은 비슷했지만, 두 모델이 강점을 보이는 작업 영역은 서로 달랐음
  • 오라클 라우팅은 작업의 72~96%를 K3에 배정했으며, K3는 5개 작업군 모두에서 Fable보다 비용 효율적이었음
  • 긴 에이전트 루프에서 K3는 Fable 단독 사용보다 최대 약 50배 높은 비용 효율성을 보였지만, 실행 단계가 많아 처리 시간이 길어질 수 있음
  • 저렴한 오픈 모델을 기본으로 삼고 고난도 작업을 다른 모델로 보내는 워크로드 맞춤형 라우터가 품질과 비용을 함께 개선할 수 있음

실제 에이전트 작업으로 측정

  • Kimi K3와 Fable 5를 동일한 하네스에서 실행해 실제 에이전트 루프 형태의 약 1,030개 작업을 수행함
    • SWE: 실제 저장소의 버그 수정과 유사한 작업 460개
    • 터미널: 보안·암호학·리버스 엔지니어링·시스템 관리 등 장기 에이전트 작업 89개
    • 알고리듬: LeetCode·AtCoder 유형 문제 100개
    • 다중 언어: 6개 언어 구현 작업 225개
    • 법률: 변호사가 채점하는 법률 에이전트 작업 120개
  • 여러 작업 유형을 대상으로 한 벤치마크 결과를 평균해 두 모델을 비교함

오라클 라우팅의 의미와 한계

  • 오라클 라우팅은 각 작업을 모든 모델에서 실행한 뒤, 정답을 낸 선택지 가운데 가장 저렴한 모델을 고르는 이론적 측정 방식임
  • 실제 라우터는 작업을 여러 모델에서 미리 실행할 수 없으므로, 비용과 품질의 균형이 가장 좋은 모델을 사전에 예측해야 함
  • 이 방식에서는 전체 작업의 72~96%에 K3가 선택됨
  • 일상적인 작업과 최상위 모델이 필요한 긴 꼬리 작업을 구분하는 라우터가 가능할 수 있음
    • 이를 확정하려면 한 자릿수 규모가 아닌 10배 수준의 추가 라우팅 데이터와 실제 환경에서의 성능 검증이 필요함

종합 성능은 비슷하지만 강점은 다름

  • 대표 SWE 결과는 K3 92.4%, Fable 92.6% 로 거의 같았음
  • 5개 작업 유형 전반에서도 두 모델의 차이는 대체로 몇 퍼센트포인트 이내였으며, Fable은 다중 언어 코딩 범위에서 조금 앞섰음
  • 비슷한 종합 점수와 달리 세부 작업에서는 각 모델이 뚜렷하게 우세한 영역을 보임

작업 영역별 차이

  • SWE를 문제 영역별로 나누면 K3는 기호 수학과 개발 도구, Fable은 웹과 데이터 시각화 작업에서 우세했음
  • 다중 언어 작업에서는 Fable이 Java·Python·C++에서 앞섰고, K3는 JavaScript·Rust에서 대등했음
  • 수십 차례 셸을 조작하는 장기 터미널 작업에서는 K3가 강점을 보임
    • Fable이 해결하지 못한 7z 해시, FEAL 암호 분석, 유출된 비밀정보, 실제 취약점, 통제 불능 비동기 작업을 해결함
  • 정확도와 비용을 함께 비교하면 Fable은 다중 언어, K3는 터미널과 법률에서 앞섰으며 나머지는 대체로 비슷했음

비용 격차를 만드는 구조

  • K3의 비용 우위는 토큰 가격·프롬프트 캐싱·작업별 투입량에서 발생함
  • SWE 작업 하나당 K3는 약 55턴과 130만 토큰을 사용한 반면, Fable은 약 21턴과 13만 토큰을 사용함
  • 긴 터미널 작업에서는 반대로 Fable이 약 64턴과 150만 토큰까지 사용하며 때로는 시간 초과에 도달함
  • K3가 SWE에서 10배 많은 토큰을 읽어도 프롬프트 캐시 적중 덕분에 실행 비용은 Fable보다 낮았음
  • 실행 단계가 많아지면 실제 처리 시간이 길어질 수 있음
    • 2초 안에 답해야 하는 작업에서는 지연 시간이 중요함
    • 대규모 백그라운드 에이전트에서는 더 낮은 비용 청구액이 중요해짐

두 모델을 결합한 결과

  • 작업마다 더 적합한 모델로 보내면 두 모델의 중간 수준이 아니라 각 단일 모델보다 높은 성능을 얻을 수 있음
  • 작업별 오라클 라우팅은 개별 모델 실행보다 항상 높은 성능을 보였고, 전체 정확도는 93% 에 도달함
  • 트래픽의 72~96%를 비용 최적화 모델인 K3로 보내면서도 전체 품질은 각 모델보다 높고, 비용은 K3 단독 사용에 가까워짐
  • K3는 5개 작업군 모두에서 Fable보다 비용 효율적이었으며, 긴 에이전트 루프에서는 최대 약 50배 높은 비용 효율성을 기록함

단일 모델보다 워크로드별 라우팅

  • Kimi K3와 Fable을 함께 라우팅하면 서로 다른 강점을 활용하면서 비용을 낮출 수 있음
  • 모델마다 가격과 전문 영역이 다르므로, 최고 품질의 AI는 단일 제공자보다 여러 모델의 조합에서 나올 수 있음
  • 비용이 최대 50배 낮고 오라클이 대부분의 트래픽을 배정한 K3 같은 오픈 모델을 기본 선택지로 삼을 수 있음
  • 라우터는 실제 워크로드에 맞춰야 하며, 작업과 모델의 적합 관계를 지속해서 학습해야 함

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 직접 실행하고 시험해 보면 이 모델들은 모두 벤치마크에 과적합돼 있음. 어떤 지표에서 최전선 모델에 근접하더라도 실제 작업에서는 무너지고 토큰 효율도 터무니없이 낮음
    Fireworks는 폐쇄형 모델과 달리 K3 호스팅에서 큰 이익을 얻으므로 이런 제목을 내세울 유인이 매우 큼

    • 며칠간 K3, Qwen 3.8 Max Preview, Fable, Sol을 시험해 본 결과 벤치마크를 믿기 어렵고 중국 모델이 느리며 토큰 효율도 낮다는 데 일부 동의함
      그래도 이전 세대 최상위 모델인 Opus 4.8·GPT 5.5와 대략 비슷하며, https://senko.net/vibecode-bench/에서도 비교할 수 있음
      공식 API와 각각의 코딩 도구를 이용해 상세 명세만으로 간단하지만 만만치 않은 웹 앱을 만들게 했더니 K3·Qwen 3.8·Fable의 결과가 사용자 시험에서 거의 같았고, Sol의 코드 검토에서도 모두 준수했으며 Fable이 약간 앞섰음
      실무에서는 여전히 Opus 4.8과 Sol을 선호하지만 대안이 필요하다면 K3와 Qwen 3.8도 충분히 쓸 만함
    • 모두 벤치마크에 과적합됐지만 핵심은 서로 비교해 얼마나 과적합됐는가임
      정답 집합 없이 에이전트들이 서로 영향을 주는 개방형 다중 에이전트 환경에서 주로 코딩 능력을 평가하는데, 중국 모델은 광고된 모델 카드보다 미국 모델 대비 낮게 나오는 편임
      Kimi K3는 예외적으로 정말 최전선에 가깝지만 매우 느림. Muse Spark 1.1은 Fable과 Sol 다음으로 강하면서 비용 효율도 가장 높아 Llama 4 이후 크게 반전했음. 데이터는 https://gertlabs.com/rankings에 있음
    • Fable은 제법 큰 코드베이스에서도 매우 잘 작동함. 몇 번 수정하거나 방향을 잡아줘야 했지만 대부분 프롬프트의 요구사항이 불충분해서였고, 실제로 틀린 경우는 두 번 정도뿐이어서 내 직업 경력보다 오류율이 낮음
      코드 품질은 내가 작성할 수준과 같고 익숙하지 않은 영역에서는 더 나음. 리팩터링이나 통합·회귀 테스트, 감사 로그 및 오류 알림 점검처럼 사람이 미루거나 지루해할 작업도 꾸준히 수행해 전체 소프트웨어 엔지니어링 수준이 높아짐
      PostgreSQL을 쓰는 비교적 복잡한 Ruby on Rails 실서비스이며, 월 200달러 Max 요금제에서 토큰 예산은 문제가 되지 않았고 비용도 충분히 가치 있음
    • 글은 읽지 않았지만 추론 서비스 업체가 자사에서 제공하는 Mythos급 모델을 내세우는 제목부터 수상했음. Kimi K3보다 매개변수가 3분의 1도 안 되는 GLM 5.2가 여전히 주력 모델임
    • 이 평가는 모두 현재로서는이라는 단서가 필요함. 추세를 보면 코딩에 충분히 좋은 수준이 아직 아니더라도 곧 도달할 것이 분명하며, 공개 모델이 거의 모든 소프트웨어 작업을 수행하는 세계에 대비해야 함

  • 약 1,000개 작업을 소프트웨어 공학·법률 등 5개 분야로 나눠 Kimi K3와 Fable을 시험한 점이 흥미로움
    정답을 내는 데 어느 모델이 더 저렴할지 예측하는 라우터 모델을 앞단에 두며, 궁극적으로는 각자의 작업 부하로 계속 학습시켜야 한다고 봄
    라우터는 분야별로 72~96%의 작업에서 Kimi를 골랐고, 분야에 따라 1.5~50배의 비용 절감을 달성함

    • 여기서 라우터는 두 모델을 모두 실행해 통과 여부를 확인한 뒤 더 싼 모델을 고르는 오라클 기준점임
      같은 결과를 사전에 예측하는 라우터가 존재할 때 비용을 절감할 수 있다는 Fireworks의 가정일 뿐이며, 그 존재 여부가 큰 전제임
    • 비슷한 라우터는 https://openrouter.ai/openrouter/auto 등 여러 개 있음

  • 사람처럼 대화하는 모델이라면 벤치마크 점수 5% 하락도 감수할 수 있음

    • 오히려 사람처럼 말하려 하지 않는 모델을 선호함
    • 5%를 포기할 필요 없이 Fable 출력을 Gemini Flash에 넣어 더 읽기 쉬운 문장으로 다시 쓰게 하면 됨
    • 모델이 내 인간적인 말투를 따라 하지 않기를 강하게 선호함. Claude가 친구처럼 굴며 농담에 LOL이라고 답하는 행동은 우스울 뿐 아니라 해롭기까지 함
    • Opus는 기본적으로 내가 Claude어라고 부르는 문체를 출력함. 지나치게 단순화되고 문법적으로 불완전한 문장이라 읽기 괴로우며, 모델에는 읽고 쓰기 쉬울지 몰라도 인간에게는 그렇지 않음
      예를 들어 긴 논문 안내를 “지금 한 번 훑고 Part II를 읽으며 다시 참고하라” 같은 명령형 단편과 굵은 키워드, 화살표로 빽빽하게 연결해 한 줄로 출력했음
    • LLM은 인간이 아닌데 굳이 사람처럼 말해야 할 이유가 없음

  • Anthropic은 로마 제국을 고속 재생하는 모습으로, IPO도 하기 전에 정점을 지나 쇠퇴 국면에 들어선 듯함

  • Kimi K3 코딩 요금제를 구독할 때 데이터 거버넌스와 개인정보 보호가 어떻게 적용되는지 궁금함. Anthropic에서 옮기고 싶음

    • https://platform.kimi.ai/docs/agreement/modeluse에 따르면 콘텐츠를 서비스 제공·유지·개발·개선 등에 사용할 수 있고, 학습 제한이 필요한 고객은 별도의 기업 계약이나 서면 합의를 논의해야 함
      Claude와 달리 모델 학습에 대한 사용 거부 선택권이 없으며, 약관상 Kimi가 고객 코드를 학습에 사용할 수 있음
    • 서구권 제공업체가 호스팅하기 시작할 때까지 기다려야 함
    • 가장 간단한 방법은 OpenRouter에 가입해 데이터 무보존(ZDR) 이 아닌 제공업체를 모두 제외하는 것임. 다만 API 요금은 코딩 요금제보다 비쌀 수 있으며, MiniMax의 월 20달러 요금제에서 제공하는 17억 토큰은 입출력·캐시 비율에 따라 API 기준 200~500달러 이상의 가치가 있음
      중국 업체를 직접 상대하기 싫다면 AtlasCode 월 20달러, OpenCode Go 월 10달러, Cline Pass 월 10달러가 일부 인기 공개 가중치 모델에 2~6배 사용량을 제공함
      개인적으로 Z.ai를 월 17달러에 구독하고 MiMo v2.5, Hy3, Qwen 3.7 Plus, DeepSeek v4는 각 원 제공업체에 API 요금을 내고 있음
    • 개인정보 보호 약관은 https://www.kimi.com/user/agreement/zh/userPrivacy에서 확인할 수 있음

  • 공개 모델을 띄우려 돈을 받고 이런 글을 쓸 수 있는지, 그렇다면 목적이 무엇인지 궁금함
    현대적인 SaaS 제품에서 FastAPI·Python과 Spring Boot·Java 작업을 해 본 결과, 잘하면서 효율적인 공개 모델은 Qwen 3.7 Max뿐이었음
    GLM 5.2와 Kimi는 코드를 쓰기 전에 거의 7만~8만 토큰 동안 코드베이스를 검색하고도 결국 코드를 깨뜨리는 경우가 많음. 1년 전처럼 매우 상세한 명세를 줘야 잘하지만 Qwen 3.7은 별다른 수고 없이 작업을 끝냄

    • 좋은 콘텐츠 마케팅임. Fireworks는 Kimi K3 접근권을 판매하는 대형 모델 추론 제공업체임
    • Fireworks는 공개 모델을 빠르게 실행하는 데 특화됐고 수익 대부분을 중국 모델에서 얻으므로, 경제적 유인이 곧 사업 모델 전체임
    • 기술 분야 영향력 사업에는 돈이 많지만 대부분은 OpenAI의 tbpn 인수나 일부 인플루언서 대상 조기 접근처럼 대형 업체에서 나옴
    • Lin Qiao가 Fireworks AI 공동 창업자이자 CEO임. LLM은 미중 냉전의 우주 경쟁에 해당하므로 돈보다 민족·문명적 우월성을 입증하려는 유인이 더 클 수 있음

  • 여기서 Kimi만 특별히 나은 점이 있는지 궁금함. 가격은 Sonnet 5와 비슷한 것으로 아는데 Sonnet 5와 Fable을 쓰거나 더 저렴한 Grok 4.5를 쓰면 어떻게 되는지 의문임

    • 글에서는 Kimi가 일부 작업에서 Fable보다 낫다고 하지만 Sonnet에는 해당하지 않을 가능성이 큼
    • 공개 모델은 대기업이 자체 데이터센터에서 로컬 실행과 미세조정을 할 수 있다는 장점이 있음

  • 중국 모델을 매우 좋아하며 DeepSeek만 사용하고, 이제 Kimi K3도 고급 코딩 작업의 훌륭한 계획 도우미로 활용함
    DeepSeek v4 Flash는 매우 빠르고 Rust, PostgreSQL, Angular, Terraform에서 맡긴 거의 모든 작업을 처리함
    Bifrost를 LLM 게이트웨이로 직접 호스팅하지만, 업체들이 선불 충전과 자동 재충전 대신 VPS처럼 월별·일별 실제 사용량을 자동 청구했으면 함. 환불되지 않는 최소 잔액을 여러 업체에 유지하기보다 정확한 사용량만 내고 싶음
    OpenRouter가 도움이 되지만 서비스 자체와 추가 요금은 마음에 들지 않음

    • 요즘 DeepSeek v4 Pro를 주력으로 쓰며 동시 작업이 많아 속도는 덜 중요함. 실패하면 대화 도중 GPT 5.5로 바꿔 문제를 찾게 한 뒤 그 분석을 문맥에 남긴 채 다시 DeepSeek로 전환함
      Kimi k2.5/6는 더 느리고 성능도 나빠진 데다 engine overloaded 오류가 늘었고, k3는 오래 사고하지만 결과가 눈에 띄게 좋아지지 않음. 연산 자원 압박 때문에 일시적으로 모델을 양자화했을 가능성이 있다고 봄
      최근에는 주로 DeepSeek v4 Pro를 쓰고 강력한 모델이 필요할 때 GPT 5.5를 사용함. GLM 5.2는 일부 작업에는 좋지만 다른 작업에서는 매우 나빴고, Google이나 Anthropic 모델은 아직 인상적이지 않았음
    • reasonix나 whale 같은 도구를 쓰면 캐시 적중률 약 98% 를 달성해 요청 비용이 사실상 무료에 가까워짐. Cloudflare나 DigitalOcean처럼 보조금 없는 미국 제공업체에서도 가능함
    • 선불제는 사용자가 추론 자원을 대량 소비한 뒤 카드를 취소하고 사라지는 일을 막아줌. VPS는 장기 투자라 전환이 더 어렵고, 일부 사용자가 한 달 요금을 떼먹어도 제공업체 비용이 상대적으로 작음
    • Bifrost를 검토 중이라 왜 LLM 게이트웨이를 선택했는지 궁금함
      OpenRouter는 거의 모든 모델을 출시 당일부터 제공하지만, Bifrost를 쓰면 나중에 OpenRouter를 떠나도 나머지 기술 구성을 건드릴 필요가 없다는 점이 매력적임. 자체 호스팅이 현실화되면 OpenAI·Anthropic·OpenRouter 의존도를 낮추고, 의존하던 모델이 갑자기 폐기될 위험도 줄일 수 있음
    • 추가 요금 외에 OpenRouter 서비스의 어떤 점이 마음에 들지 않는지 궁금함

  • 공개 모델 호스팅 회사가 공개 모델이 훌륭하다고 말하는 상황임

    • 방법론과 결과를 공개했고, 다른 곳에서는 보지 못한 Kimi와 Fable의 상대적 장단점을 알게 됐음. 모델 호스팅 사업을 한다는 이유만으로 결과를 공유할 자격까지 없어지는 것은 아님
    • Fireworks는 공개 가중치 모델만 호스팅하지 않으며, 큰 소식이 신규 고객을 유치할 수 있다고 해서 내용이 거짓이 되는 것은 아님
    • 직접 써 본 사람이라면 이들의 평가가 사실임을 알 수 있음

  • 글에서 설명한 것처럼 Claude Code와 함께 쓸 수 있는 라우팅 도구나 다른 좋은 라우팅 플랫폼을 찾고 있음. 이 글의 라우터가 오라클 방식이라는 점은 알고 있음

    • https://github.com/code-yeongyu/oh-my-openagent는 원문의 오라클 패턴을 11개 역할에 걸쳐 구현함
      각 역할마다 여러 제공업체의 권장 LLM 순위가 있으며, 예를 들어 Sisyphus (claude-opus-4-8 / kimi-k3 / glm-5)를 주 오케스트레이터로 사용함
답변달기