라우팅 DSL: Fable 5처럼 생각하는 모델 패널을 구성하세요

2년 동안 '더 많은 지능'을 위한 전략은 '다음 모델을 기다리자'였습니다. 우리는 그것이 잘못된 진보의 단위라고 생각합니다. 프론티어는 단일 체크포인트가 아닙니다 — 그것은 패널. 세 개의 좋은 모델에게 동일한 어려운 문제를 주고, 그들이 의견을 달리하게 하고, 답변 간의 중재를 하면, 패널은 구성원 중 어느 하나보다 뛰어납니다. 종종 가격표에서 다음 모델보다 더 나은 성능을 보입니다.

그 라우팅 DSL 은 해당 패널을 구축하는 방법입니다. 이는 프로그래밍 가능한 라우팅 전략 — YAML + CEL — 으로, OrcaRouter 엔드포인트를 추론 그래프로 전환합니다: 난이도별 라우팅, 작업별 라우팅, 여러 모델로 동시에 분산, 출력에 대한 판단 또는 투표, 신뢰도가 낮을 때 폴백, 그리고 비용, 지연 시간 또는 품질에 따라 전체를 조정합니다. 규칙을 작성하면 게이트웨이가 모든 요청에 대해 약 5ms 내에 이를 컴파일하고 실행합니다.

이 게시물은 엔지니어링 투어입니다: 문법, 분기할 수 있는 변수, 네 명의 중재자, 계단식 구조, 그리고 마지막에 완전한 프로덕션 규칙 세트입니다.

결과가 먼저

두 가지 예시적인 벤치마크입니다. (숫자는 예시적인 것입니다 — 그들은 보여주는 형태를 효과의 것으로, 공식 점수로 인용되어서는 안 됩니다.)

프론티어 비교 — 난이도 기반 라우팅 DSL 엔드포인트 대 단독 프론티어:

퓨전 패널 vs. 솔로 모델 — 100개 작업 중 93개에서 점수 획득 (OpenRouter 출처):

응시할 가치가 있는 세 가지:

모든 퓨전 패널은 자신의 모든 구성원을 능가합니다.Opus 4.8 + GPT-5.5 (~67.5%)는 Opus 단독 (~58.5%)과 GPT-5.5 단독 (~60%)을 7–9점 차이로 모두 능가합니다. 불일치는 신호이며, 중재가 그것을 수확합니다.

Fusion이 다음 단계에 도달합니다. 세 개의 서로 다른 패널이 크로스 Fable 5 solo (~65.5%) 아래 모델만 사용하여 아래 그것.

비싼 멤버십이 필요하지 않습니다.Opus + Opus 자체 융합(~65.5%)은 하나의 모델과 샘플러로 Fable 5와 일치합니다. 패널 저렴한 모델들 — Gemini 3 Flash + Kimi K2.6 + DeepSeek V4 Pro (~64.5%) — 은 Fable 5보다 근소하게 낮으며, 토큰당 비용의 극히 일부입니다. 이것이 전체 요지입니다: 토폴로지로 지능을 구매하고, 다음 가격 등급으로 구매하지 마십시오.

라우팅 DSL은 그 토폴로지를 수익이 나는 곳에만 투자할 수 있게 해주는 제어 표면입니다 — 쉬운 80%에는 저렴한 모델을, 어려운 꼬리 부분에는 퓨전 패널을.

30초 문법

규칙 세트는 버전, 규칙 목록 및 필수 기본값으로 구성됩니다. 규칙은 평가됩니다 위에서 아래로; 첫 번째로 참인 when: 조건이 승리합니다. when:이 없으면 "항상 일치."를 의미합니다.

버전: 1

rules:
  - id: only_rule
    use: { model: "claude-sonnet-4-6" }
default:
  delegate: balanced

when:는 CEL 부울 표현식입니다. 샌드박스 처리되고, RE2 전용 정규식이며, 루프나 I/O가 없고, 마이크로초 단위로 평가되며, 전체 규칙셋에서 공유되는 단일 5ms 데드라인이 있습니다. use:는 효과: 요청의 대상과 튜닝 방법을 나타냅니다. 제한은 의도적으로 작게 설정되어 있습니다(규칙 ≤30개, 소스 ≤16KiB, when:당 ≤200자). 따라서 규칙셋을 감사 가능한 상태로 유지할 수 있습니다.

원시 1 — 난이도와 작업별 경로

배포자는 라우팅 전에 모든 요청을 분류하고 기능을 CEL에 노출합니다. 이를 직접 분기합니다:

버전: 1

rules:
  - id: hard_reasoning
    when: difficulty > 0.8
    use:
      model: "claude-opus-4-8"
      reasoning_effort: "high"
      thinking_budget_tokens: 32000


  - id: code_path
    when: task_class == "code" && code_keyword_density > 0.5
    use: { model: "gpt-5.5" }


  - id: cheap_chat
    when: difficulty < 0.3
    use: { model: "gemini-3-flash" }


default:
  delegate: balanced

when:에서 읽을 수 있는 변수들 (약어 — 전체 참조는 문서를 참조하세요):

그룹 예시

요청 형태

request.input_tokens, request.output_max_tokens, request.stream, request.vision, request.message_count, request.has_tools

분류

task_class (chat/code/agent/vision/audio/rag/creative), difficulty (0.0–1.0), code_keyword_density, reasoning_cue_count, log_prompt_tokens, tool_count

세션 

agent_state.turn, agent_state.tools_used, agent_state.has_edited, agent_state.last_test_failed, agent_state.consecutive_errors, agent_state.models_tried

맥락

headers["x-…"], user.group, token.name, time.hour, workspace.id
…plus six macros for the things regex-over-payload is good at: system_prompt_matches(re), user_message_matches(re), tool_definitions_include(name), tool_calls_present_any([…]), tool_results_from_any([…]), header_matches(name, re).

어느 대상이든 가질 수 있습니다호출별 설정, 릴레이 어댑터에 의해 각 제공자의 기본 파라미터로 변환됩니다: reasoning_effort (low/medium/high), thinking_budget_tokens (1024–64000), samples (1–16), temperature (0.0–2.0), 그리고 차단 목록으로 보호되는 param_override / header_override. 이것만으로도 Table A에서 난이도 기반 경로 설정 엔드포인트를 구축하기에 충분합니다: 쉬운 부분에서는 저렴한 모델, 어려운 부분에서는 생각 예산을 가진 Opus.

원시 2 — 패널로 팬 아웃 (퓨전)

이것이 벤치마크 리프트가 발생하는 지점입니다. 병렬: 효과는 요청을 전달합니다 2–5개의 레그에 동시에, 그런 다음 하나의 중재자가 클라이언트가 실제로 보는 내용을 결정합니다:

- id: hard_tail_panel
  when: difficulty > 0.7 && task_class == "agent"
  use:
    parallel:
      - { model: "anthropic/claude-opus-4-8", reasoning_effort: "high" }
      - { model: "openai/gpt-5.5", thinking_budget_tokens: 16000 }
      - { model: "google/gemini-3.1-pro", temperature: 0.3 }
    arbiter:
      strategy: best_of_n
      model: "anthropic/claude-sonnet-4-6"      # the judge
      template: judge_code
    max_latency_ms: 120000
    on_disagreement:                  # majority-only escape hatch
      model: "anthropic/claude-opus-4-8"
      reasoning_effort: "high"

네 가지 중재자 전략, 각각은 "누구의 출력이 승리하는가?"에 대한 다른 답변입니다:

첫 번째 — 다리를 경쟁시키고, 첫 번째 성공을 제공하고, 패자들을 취소합니다. 최적화합니다 지연 시간 (당신은 N개 중 가장 빠른 것을 얻습니다).

다수결 — 분기 출력에 대해 추가 모델 호출 없이 구조적 투표를 수행합니다. 분기가 명확한 다수결 없이 갈라지면, 선택적 on_disagreement: 브랜치가 동점 처리 대신 새롭고 더 강력한 시도를 다시 전송합니다. 최적화를 견고성에 대해 표준 답변이 있는 작업에서 수행합니다.

best_of_n — 한 LLM 심사자 모든 후보를 읽고 순위를 매깁니다. 이것은 Table B의 Opus + GPT-5.5 → 심사자 구성입니다. 최적화합니다 품질 개방형 작업에서; 심사자가 오류를 범할 경우 첫 번째 성공으로 대체합니다.

tests_pass — 실행 기반: 패치가 실제로 테스트 스위트를 통과하게 만드는 후보자를 제공합니다. 심사관의 추측이 없습니다 — 테스트 도구가 결정합니다. 이는 코드/에이전트 작업을 위한 가장 강력한 중재자입니다. 검증자는 게이트웨이 외부에 있습니다 (VerifierProvider를 통해 연결됨); 연결된 것이 없으면, 처음 성공한 것으로 저하됩니다.

max_latency_ms (1000–600000, 기본값 120000)는 팬아웃을 제한하여 하나의 느린 레그가 응답을 지연시키지 못하도록 합니다 — 지연된 레그는 드롭됩니다. parallel 내부에 parallel을 중첩하는 것은 린트에서 거부되며, 패널은 의도적으로 한 단계 깊이로 설계되었습니다.

가용성 참고: N-way 팬아웃 런타임은 서버 플래그 뒤에 게이트되어 있습니다 ROUTING_DSL_ENSEMBLE_RUNTIME 한편, 레그별 청구는 스테이징에서 강화되었습니다 — 그렇기 때문에 fusion은 preview, GA가 아님. 플래그가 꺼져 있으면 parallel: 규칙이 첫 번째 레그를 깔끔하게 제공하므로, 지금 패널을 작성하고 섀도우할 수 있으며 fusion이 해당 지역에 출시되면 활성화할 수 있습니다.

기본 요소 3 — 대체 및 신뢰도 캐스케이드

Fan-out은 초기에 N×를 소모합니다. 한 캐스케이드는 추가로 소모합니다 첫 번째 답변이 잘못된 것처럼 보일 때만. 응답 후, on_low_confidence: 신호를 평가하고, 하나라도 발생하면 더 강력한 목적지로 재전송합니다:

- id: agent_with_safety_net
  when: task_class == "agent"
  use:
    pool: "@pool:fast"
  on_low_confidence:
    signals: [patch_invalid, self_doubt, next_turn_test_failed]
    threshold: { low_logprob: -1.5 }
    use:
      model: "claude-opus-4-8"
      reasoning_effort: "high"

신호: patch_invalid (diff가 git apply --check에 실패함), self_doubt (회피성 표현 정규식 집합), low_logprob (공급자가 노출하는 경우, 임계값 미만의 평균 토큰 로그 확률), 그리고 next_turn_test_failed (크로스 턴 래치 — 이번 턴의 프롬프트는 지난 턴의 실패한 테스트의 형태를 지닙니다). 캐스케이드는 설계상 깊이 1입니다. agent_state.models_tried와 함께 사용하여 얻을 수 있는 diversity on retry — 방금 실패한 모델로 수정을 보내지 마십시오.

다이얼 튜닝: 비용, 레이턴시, 품질

동일한 DSL이 세 가지 목표를 모두 표현합니다; 규칙별로 선택합니다:

비용 — 책임자: 가장 저렴한 모델을 유지하고, 쉬운 꼬리 부분에는 저렴한 모델을 유지하며, 난이도 > 0.7인 경우에만 팬아웃을 예약하십시오. 표 B의 저렴한 패널(~64.5% ≈ Fable 5 solo)은 존재의 증거입니다: 작은 모델의 융합이 프론티어 모델을 토큰당 비용의 일부로 대체할 수 있습니다. 하지만 명확히 하자면, 퓨전은 사용하는 "bill every leg" 모델: 3-레그 best_of_n 패널은 세 명의 후보자와 심판에게 청구합니다. 경제학이 작동하는 이유는 (a) 어려운 소수의 요청에만 팬아웃을 하고 (b) 퓨즈하는 더 저렴한 멤버들을 대체하려는 프론티어 모델보다.

지연 시간 — 중재자: { strategy: first }와 엄격한 max_latency_ms를 추가하면 N개 중 가장 빠른 것을 제공하며 상한선이 있습니다.

품질 — 개방형 작업을 위한 best_of_n, 테스트 스위트가 있을 때 기반이 되는 tests_pass. samples와 thinking_budget_tokens는 단일 레그 내에서 더 많은 것을 확보합니다.

프로덕션을 망가뜨리지 않고 운영하기

라우팅 변경은 무서운 일이므로, DSL에는 SRE가 기대하는 안전 레일이 포함되어 있습니다:

모든 저장 시 린트 — 스키마, CEL 타입 검사 (every when: 반드시 bool로 평가되어야 함), 참조 해결, 노브 범위, 헤더/파라미터 차단 목록. 오류는 {line, column, message, rule}로 반환되며 편집기에서 거터 칩으로 표시됩니다.

드라이 런 — 합성 요청(POST)을 보내고 (task_class, difficulty, agent_state, …) 일치하는 규칙, 해결된 효과, 그리고 모든 것이 실제로 배송되기 전의 평가 시간을 반환합니다.

섀도 모드 — 처음 저장 후 24시간 동안 DSL은 평가되지만 사용되지 않음; 섀도 로그는 선택될 항목을 기록하고 콘솔에는 차이(변경된 경로의 백분율, 예상 일일 비용 차이, 규칙별 실행 횟수)가 표시됩니다.

Canary — 0–100 트래픽 슬라이더. 각 슬라이스별 메트릭을 모니터링하면서 5 → 25 → 50 → 100으로 램프; 0으로 슬라이딩하여 롤백.

감사 + 롤백 — 모든 저장/롤백 시 동일한 트랜잭션에서 감사 행을 기록합니다. 동시 편집 시 현재 버전과 함께 409 오류가 발생하므로 새 상태에서 재시도해야 합니다.

테스트 케이스, 트레이스 재생, AI "이 규칙 세트 설명" 보기가 함께 제공됩니다. 대시보드 아래의routing → strategy → DSL.

완전한 룰셋

쉬운 것에는 저렴하게, 중간에는 중간으로, 어려운 에이전틱 테일에는 판단된 퓨전 패널, 그 아래에 신뢰도 캐스케이드:

버전: 1

rules:
  - id: trivial
    when: difficulty < 0.3 && !has_tools
    use: { model: "gemini-3-flash" }


  - id: standard
    when: difficulty < 0.7
    use:
      model: "gpt-5.5"
    on_low_confidence:
      signals: [self_doubt, low_logprob]
      use: { model: "claude-opus-4-8", reasoning_effort: "high" }


  - id: hard_agent_panel
    when: difficulty >= 0.7 && task_class == "agent"
    use:
      parallel:
        - { model: "anthropic/claude-opus-4-8", reasoning_effort: "high" }
        - { model: "openai/gpt-5.5", thinking_budget_tokens: 16000 }
        - { model: "google/gemini-3.1-pro" }
      arbiter:
        strategy: tests_pass        # execution-grounded; judged fallback if no harness
      max_latency_ms: 180000
      on_disagreement:
        model: "claude-opus-4-8"
        reasoning_effort: "high"


default:
  delegate: balanced

해당 엔드포인트는 표 A의 맨 위에 위치한 것입니다 — 더 나은 모델을 찾았기 때문이 아니라, 올바른 모델을 올바른 요청에 사용하고 패널이 승리하는 정확한 위치에 패널을 융합하기 때문입니다.

작성 시작

다음 능력 도약은 다음 체크포인트를 기다릴 필요가 없습니다. 오늘 오후에 작성할 수 있는 그래프입니다: 난이도별로 경로를 정하고, 어려운 꼬리에서 확장하며, 출력을 판단하거나 테스트하고, 신뢰도가 떨어질 때 계단식으로 전개합니다.

문서: https://docs.orcarouter.ai/routing/routing-dsl

UI: 라우팅 → 라우터 생성 -> 라우팅 전략 → DSL (전문가)

프론티어는 패널입니다. 자신의 것을 구축하세요.