OpenRouter Fusion API

 (openrouter.ai)
6P by GN⁺ | ★ favorite | 댓글 1개
  • 여러 모델의 결과를 종합(synthesize) 하면 개별 모델 단독 성능을 크게 능가할 수 있다는 발견에서 출발
  • 단일 프롬프트를 여러 전문가 모델이 병렬로 분석한 뒤 심판 모델(judge model) 이 결과를 종합해 최종 답변을 작성하는 멀티 모델 심의(multi-model deliberation) 방식
  • 패널 모델은 웹 검색과 웹 페치를 활성화한 상태로 병렬 분석을 수행하며, 심판 모델이 합의, 모순, 부분적 일치, 고유 통찰, 사각지대를 구조화한 분석으로 정리
  • 기본값은 Quality 프리셋이며, Budget 프리셋으로 저렴한 모델 전환 또는 fusion 플러그인 필드로 패널·심판 완전 재정의 가능
  • 단일 모델로 충분치 않은 리서치, 전문가 비평, 오답 비용이 추가 완성 비용을 상회하는 상황에 적합
  • 패널 구성원 전원과 심판 호출을 모두 실행하므로, 요청 비용은 단일 모델이 아닌 개별 완성(completion) 합산 방식으로 책정

동작 방식

  • 단일 프롬프트를 소규모 멀티 모델 심의로 전환하는 방식
    • 전문가 모델 패널이 웹 검색(web search) 과 웹 페치(web fetch) 를 활성화한 상태로 프롬프트를 병렬 분석
    • 심판 모델이 패널 응답을 종합해 합의(consensus), 모순(contradictions), 부분 커버리지(partial coverage), 고유 통찰(unique insights), 사각지대(blind spots) 로 구조화한 분석 생성
    • 구조화된 분석을 기반으로 심판 모델이 최종 답변 작성

패널 구성 및 설정

  • 기본 패널은 Quality 프리셋 사용
    • 더 저렴한 구성원을 원하면 Budget 프리셋 으로 전환 가능
    • fusion 플러그인의 analysis_models 및 model 필드로 패널과 심판을 완전히 재정의(override) 가능
  • 단일 모델이 충분치 않을 때 사용 권장
    • 리서치, 전문가 비평, 또는 오답 비용이 추가 완성 비용을 초과하는 영역에 적합

가격 및 제약

  • 패널 구성원 전원과 심판 호출을 모두 실행하므로, 요청 비용은 단일 모델 기준이 아닌 개별 완성의 합산으로 책정
    • 실제 실행된 모델 확인은 Activity 페이지에서 가능
  • 컨텍스트 한도는 선택한 모델에 따라 달라짐

프리셋에서는 6개의 모델을 사용

  • 최고 품질: Claude Opus, OpenAI GPT, Google Gemini Pro
  • 최저 비용: Google Gemini Flash, DeepSeek V4 Flash, MoonshotAI Kimi

관련 발표: "Fusion으로 프론티어 성능을 넘어서다"

  • 여러 모델의 결과를 종합해 개별 모델 단독 성능을 능가하는 도구로, 참가 모델 패널과 결과를 융합하는 judge 모델을 직접 선택해 단일 모델처럼 호출
  • DRACO 벤치마크의 deep research 과제 100개 측정에서 패널이 개별 모델을 일관되게 능가
    • Fable 5 + GPT-5.5 융합이 69.0% 로 단독 Fable 5(65.3%) 포함 모든 개별 모델 능가
    • 저가형 패널(Gemini 3 Flash + Kimi K2.6 + DeepSeek V4 Pro)이 비용 50% 로 Fable 5 점수에 1% 이내 근접, GPT-5.5·Opus 4.8 능가
  • 프롬프트를 패널 모델에 병렬 전송, judge가 합의점·모순·고유 통찰·맹점을 분석하고 호출 모델이 이를 근거로 최종 답변 작성
  • 전체 파이프라인이 server-side에서 실행되어 개별 모델 호출과 동일한 방식으로 사용 가능
  • Opus 4.8을 자기 자신과 융합한 경우에도 65.5%로 단독(58.8%) 대비 6.7점 상승, synthesis 단계 자체의 효과 확인
  • 패널 모델이 채점 루브릭을 온라인에서 찾는 오염 위험 발견, web search·web fetch 제외 목록을 한 줄 설정으로 적용해 차단
  • 사용 방법 4가지: Chatroom(코드 불필요), Model slug(문자열 교체), Server tool(최고 수준 제어), Plugin(패널 지정)
  • Fable의 drop-in 대체재 아님, Fable이 강점인 long-horizon 과제는 미포함, 코딩에서는 선택적 호출 도구로 활용

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 몇 달 전에 OpenRouter를 쓰는 MCP로 Fusion을 만들어 봤음. Claude가 막혔을 때 찾아갈 “전문가 패널”을 주자는 아이디어였음
    테스트와 벤치마크를 많이 해보니, 한 모델에게 다른 모델의 답을 평가시키는 건 실제로 더 나은 답을 주지 않았음. 결국 “이 답이 네가 했을 답과 얼마나 비슷하냐”를 묻는 셈이고, 추가 라운드나 떠오르는 “당연한” 해결책들은 사실상 온도를 올리는 것과 비슷했음. 해결책은 찾았지만 비용이 말도 안 되게 비쌈. 이 방식이 더 주목받으면 내 것도 공개할지도 모르겠음

    • 프롬프트가 중요함. 다른 모델의 의견을 원한다면 당연히 같은 프롬프트로 처음부터 생성하게 한 뒤 종합해야 하고, 원하면 기존 응답을 대상으로 작업하는 것도 가능함
      나는 명시적으로 심각도별 문제를 찾게 하고, 그 문제들을 판정 모델 패널에 통과시킨 뒤 특정 임계값을 넘는 것만 원래 응답에서 고치게 함. 결과가 크게 좋아진 깨달음은 판정 모델에게 진실성과 “유용성/고쳐야 하는가” 축을 따로 평가하라고 하는 것임. 문제를 찾도록 강제하면 결국 사소한 흠잡기가 생기기 때문이고, 진실성 축은 내 용도에 맞는 문제 탐지 모델을 평가하는 데도 더 좋았음. 이런 설명을 생성할 때 일부 적용됨: https://hanzirama.com/character/%E6%9D%A5#explain — 지금은 이 사이트가 내 LLM 평가 장치의 작은 사이드 제품이 됐음. 최고 품질이 필요하면 OpenRouter에서 제공자를 고정해야 할 가능성이 큼. :exacto만으로는 특히 오픈 가중치 모델에서 반복 가능한 좋은 결과를 얻기 어려움
    • 판정 모델에게 답이 작고 약한 로컬 LLM에서 나왔다고 말하면 답을 아주 가혹하게 뜯어보는 걸 본 적 있음. 다만 체계적으로 해본 건 아니라 내 느낌을 넘어 일반화되는지는 모르겠음
      LLM을 “우월하다고 느끼는” 모드로 속일 수 있으면 꽤 잘 못되게 군다고 느낀 사람 또 있는지 궁금함
    • 2024년에 이 아이디어의 거친 버전을 만들었는데[0], 아직도 이 발상이 이어지는 게 흥미로움. 품질 임계값을 설정할 수 있었지만 별 차이는 없어 보였고, 최전선 모델들은 거의 항상 서로 동의하며 답에 높은 점수를 줬음
      2년 전과는 완전히 다른 판이 됐으니 다시 살펴볼 만함. [0] https://github.com/Ceroxylon/konsensis
    • 답이 검증 가능한지에 따라 달라진다고 봄
      내 앱에서 판정 모델 두 개를 테스트했음. 첫째는 이력서 맞춤 모델용 판정 모델로, 결과 이력서를 원본 이력서와 채용공고와 비교해 적합성과 정직성을 10점 만점으로 평가했는데 잘 작동하고 유용했음. 둘째는 LLM 트레이딩 봇 플랫폼의 검토 모델로, 메인 모델의 결정을 검토함. 여기서는 봇이 모호성을 다루기 때문에, 잘못된 캔들 가격으로 판단하거나 SELL이어야 할 때 BUY하는 식의 명백한 실수를 잡지 않는 한 오히려 해가 될 수 있음. 먼저 결정 지연이 추가되어 Gemma 4 31B 기준 30초가 60초처럼 두 배로 늘어남. 또 검토 모델이 BUY/SELL 결정에만 돌고 HOLD에는 돌지 않으므로, 지연과 비용 때문에 거래 수가 늘기보다 봇이 지나치게 조심스러워질 수 있음. 그래서 답이 쉽게 검증되지 않는다면 검토 모델보다 더 좋은 모델로 한 번에 처리하는 편이 낫다고 봄. 그렇다면 판정 모델이 왜 필요하고, 같은 에이전트가 스스로 검토하게 하지 않는 이유도 애매함. 게다가 Gemma 4 같은 추론 모델의 추론 텍스트를 읽어보면 이미 스스로 검토하고 있음. 최선을 다하고 있는 셈이라 재검토가 정보를 많이 더하지 않음. 흥미로운 실험이지만 건별로 평가해야 함
    • 같은 경험임. 객관적으로 더 나은 답을 찾는 게 생각보다 쉽지 않았고, 비용도 들며 느렸음

  • Claude Code만 써서 이런 식으로 쓰던 프롬프트가 있었음
    아키텍처 문제를 검토하자. 에이전트 10개를 띄우고 각자 페르소나를 만들게 한 뒤 _api.go를 검토하고 reviews/-review.md에 리뷰를 쓰게 함. 각 에이전트가 각 리뷰 앞의 요약을 보고 원하는 리뷰 3개에 라운드로빈 방식으로 응답하고 response/--response.md에 쓰게 함. 그다음 응답에 대한 반박을 rebuttals/-rebuttal.md에 쓰게 함. 마지막으로 각 에이전트가 자신의 리뷰, 응답, 반박을 검토할 에이전트를 다시 띄우고 결과를 findings/-findings.md에 정리하게 함. 마지막으로 다른 에이전트가 결과를 합쳐 review-findings.md에 쓰고, 여기에는 간결한 버전을 제시하게 함. 이 방식은 최전선 모델에서도, 로컬 호스팅 모델에서도 잘 됐음. 마지막으로 썼던 건 Qwen 3.5였음

    • 여러 에이전트를 한 흐름에서 쓰는 건 익숙하지 않아서 몇 가지 궁금함
      생성된 모든 파일을 검토해서 환각이 없는지 확인하는지, 아니면 마지막의 간결한 결과 파일만 보는지 궁금함. 여러 에이전트를 거치면 환각이 서로 상쇄되어 결국 진실만 남는다는 의도인지도 궁금함. 마지막 버전에서 심하게 틀린 내용을 본 적이 있는지도 알고 싶음. 비용이 걱정됐지만 로컬 호스팅 모델을 쓰면 그 부분은 덜할 듯함. 다만 로컬 호스팅 모델은 여전히 로컬 명령 실행이나 인터넷 접근에 문제가 있지 않나? 그렇다면 프로젝트 나머지 부분을 참조하지 않고 해당 파일 문맥만으로 도는 방식인지 궁금함
    • 같은 리뷰를 n번 돌리고 결과를 합치는 것보다 장치가 꽤 많아 보임. 왜 이런 설계로 가게 됐는지 궁금함

  • 배경 맥락은 여기 있음: Surpassing Frontier Performance with Fusion
    https://news.ycombinator.com/item?id=48525392
    UI가 조금 더 나은 곳은 https://openrouter.ai/fusion임. OpenRouter의 Fusion API는 요청을 여러 모델에 동시에 보내고, 판정 모델이 답을 합쳐 최종 응답을 만듦. 시간이 더 드는 대신 성능을 크게 높인다고 함. 적어도 이들이 테스트한 딥리서치 벤치마크에서는 그랬음. Budget 프리셋은 더 싼 모델 3개로 구성돼 있고, 해당 벤치마크에서 Fable과 대략 비슷하면서 비용은 절반임. Quality 프리셋은 비싼 모델 3개로 구성돼 Fable을 이기지만 비용은 Fable의 두 배임. 파레토 그래프: https://openrouter.ai/blog/images/blog/fusion-benchmark-cost.... 흥미롭게도 같은 모델을 자기 자신과 융합해도 성능이 올랐음. 2xOpus4.8은 벤치마크에서 Fable과 대략 비슷하지만 비용은 Fable의 두 배임. 서로 다른 모델을 섞으면 추가 이득이 조금 더 있음. 주된 이득은 추가 테스트 시점 연산에서 나오는 듯함. 최근 나온 저렴한 모델, 예를 들어 DSV4를 자기 자신과 또는 Mimo와 융합하는 경우를 중심으로 더 많은 연구가 나오면 좋겠고, 병렬 테스트 시점 연산인 융합과 추론량 증가 또는 턴 증가 사이의 절충도 보고 싶음

    • “같은 모델을 자기 자신과 융합해도 성능이 올랐다”는 건 GPT-2에서 GPT-3로 가던 시절에는 꽤 흔한 방식이었음
      사실상 가능한 출력 공간에서 표본을 더 많이 뽑는 것임. 모델이 어떤 작업을 60% 확률로 해낼 수 있다면 5~10개 표본을 뽑고 다수결 같은 걸 구현하면 됨. 결과 결합이 쉬운 문제에서 모델 정확도가 높아지면서 덜 쓰이게 됐지만, 더 복잡한 판정기, 즉 유능한 LLM이 있으면 출력 공간을 더 많이 샘플링하고 좋은 부분을 골라내는 것만으로도 여전히 성능을 올릴 수 있음
    • Fable 5 + GPT 5.5 패널이 둘 중 하나의 최전선 성능을 꽤 이기는데, Gemini를 섞으면 세 모델 패널이 더 좋아지지 않고 오히려 나빠지는 점이 흥미로움
      내게는 Gemini가 해당 작업에서는 더 약하지만 자기 해법을 판정 모델에게 설득하는 능력은 더 좋은 것처럼 들림. 그리고 Opus 4.8 두 개 패널이 Fable 5 하나와 거의 정확히 같은 수준이라는 것도 수상한 냄새가 남. Anthropic이 뒤에서 그냥 이런 걸 하고 있는 건 아닌지 알 수 있나?
    • 합성 단계 때문에 얼마나 더 오래 걸리는지를 거의 다루지 않은 게 아쉬움. 딥리서치 벤치마크에서는 별로 중요하지 않을 수 있지만, 코딩 작업에는 어떻게 적용될지 흥미로움
    • 지금 모델에도 여전히 그런지는 모르겠지만, 몇 세대 전 Microsoft 연구에서 모델에게 N번 반복하게 하면 성능이 크게 좋아지고, 최적 지점이 4회 반복이라는 결과가 있었음

  • Opus 4.7이나 GPT 5.5를 직접 호출하는 것과 질적으로 어떻게 다른지 보려고 빠른 평가를 돌려봤음
    예상대로 Fusion은 7배 느리고 비용은 4배였음. 이걸 비판하려는 건 아니고, Fusion은 “필요할 때만 쓰는” 범주에 들어간다고 봄. https://3fpi5avcqq.evvl.io/

    • Fusion은 증류 대상으로는 정말 좋아 보임
    • 공유 고마움. 속도가 가장 큰 걱정이었는데, 그쪽에서는 그 부분을 언급하지 않았음
    • 어떤 모델을 밑에서 썼는지 궁금함. 인터페이스에 있는 Quality 기본값을 썼다면, 최전선 모델 3개와 그중 하나가 판정하는 구조라 비용이 약 4배인 게 말이 됨
      핵심 아이디어는 더 단순하고 저렴한 모델로 Fusion을 쓰는 것일 듯함
    • 꽤 직관과 반대라고 봄. 이게 잘 작동할 올바른 틀과 구조를 잡는 건 쉽지 않을 가능성이 큼. 모델들은 함께 잘 노는 걸 정말 싫어함
      실제 사용에서는 이들의 버전이 어떻게 버틸지 궁금함

  • 이 문제를 많이 생각해 봤고, 단순화해서 이해하기로는 각 모델을 인간 지식 위의 종 모양 분포로 볼 수 있으며 모델마다 분포가 다름
    여러 모델을 쓰면 원래 곡선 밖의 텍스트로 다른 모델의 분포를 바꿀 수 있음. 하지만 다시 생각해보면 SFP와 강화학습이 원래 텍스트 분포를 충분히 바꿔서, 모델들의 결합 출력이 더 나은 무언가가 될 만큼 다양해지는지 아니면 그냥 반향실이 되는지 의문임. 아직 증명할 방법은 없지만 나는 그렇지 않다고 믿음

  • Fusion에 대한 일화적 결과로, Fable에 썼던 같은 질의를 OpenRouter Fusion에 돌렸더니 결과가 더 나빴음
    Fable은 아주 깊은 지식/지능 층을 어느 정도 잡고, 그럴듯한 답만 하는 게 아니라 해결 항목의 우선순위를 제안하고 일부 항목은 버리자고 했는데, 그게 내게는 꽤 타당했음. 반면 Fusion은 Fable 이전의 최첨단 모델들이 내는 같은 부류 답을 조금 다양화한 느낌이었고, 내가 Fable에 접근 가능했을 때 한 아주 제한적인 테스트에서는 Fable이 닿던 깊이에 닿지 못했음

  • 주말에 새 OpenRouter Fusion 모델에서 영감을 받아, 이걸 Claude Code에서 돌릴 수 있는지와 다른 사람도 쉽게 써볼 수 있게 만들 수 있는지 보려고 작업했음
    만든 건 claude-fusion-launcher — Claude Code를 단일 모델이 아니라 모델 패널 위에서 실행함. 비용도 보여줌. https://github.com/smorinlabs/claude-fusion-launcher

    • 금방 비싸지지 않나? 웹사이트에서 해본 단발 프롬프트들이 거의 프롬프트당 1달러가 들었음

  • 같은 모델로 같은 프롬프트를 여러 번, 더 높은 온도로 재생성하는 것이 서로 다른 모델을 돌리는 것과 동등한지 궁금함
    서로 다른 최전선 모델 사이에서 느껴지는 변동성은 상당 부분 0이 아닌 온도에서 오는 무작위성 때문일 수 있다고 의심함. 모델들은 5, 10, 15처럼 보기 좋은 둥근 개수의 항목을 반환하도록 훈련된 듯함. 마케팅 자료 학습의 간섭 때문일 수도 있음. 게다가 큰 문맥에서 회상률은 100%와 거리가 멂. 그래서 코드에 버그가 27개 있다면, 여러 모델을 쓰든 같은 모델을 반복 호출하든 매 실행마다 27개 중 서로 다른 10개 문제를 찾을 수 있음

  • 이 분야에 정식 연구가 있는지 궁금함. 나도 이런 접근의 변형을 시도해 봤지만 결과가 더 나았다고 자신 있게 말하긴 어려웠음
    사업의 최적 전략을 컨설턴트 2~3명에게 각각 물어보는 것과 비슷할까 걱정됨. 답을 합친다고 실질적으로 더 나은 무언가가 나오는지 잘 모르겠음

  • 내 TrustedRouter에도 비슷한 기능을 오픈소스로, 종단 간 암호화까지 적용해 출시했음: https://trustedrouter.com/

    • 실제 개인정보 보호 약속이 보이는 건 좋음. 회피적이고 모호한 제공자 약관을 끝없이 읽는 데 시간을 많이 쓰고 있음
답변달기