Fugu는 호출한 각 구성요소를 이긴다. 별표가 중요하다.

Sakana AI가 Fugu를 내세우는 방식은 이례적입니다. 더 큰 모델 하나를 학습시키는 대신, 다른 모델들을 움직이는 일을 맡는 모델을 학습시켰기 때문입니다. 2026년 6월 22일 출시된 이 결과물은 겉으로는 단일 API 엔드포인트처럼 동작하지만, 내부에서는 프런티어 LLM 풀을 조율해 실행합니다.

Fugu는 고정 라우터가 아니라 학습된 조율자입니다

Fugu는 다른 LLM을 호출하고 조율하도록 학습된 언어 모델 그 자체입니다. 프롬프트 라우팅 래퍼도, mixture-of-experts 내부 서브네트워크도 아닙니다. 도쿄 기반 Sakana AI는 2026년 6월 22일 이를 공개 출시하면서, 교체 가능한 외부 프런티어 에이전트 묶음 중에서 선택하고, 작업을 위임하고, 결과를 종합하는 "모델로서의 멀티 에이전트 시스템"이라고 홍보했습니다 (source: MarkTechPost, 2026-06). 이 차이는 중요합니다. mixture-of-experts 모델에서 전문가들은 내부 서브네트워크입니다. 반면 Fugu에서 "전문가"는 조율자가 다루는 법을 학습한, 별도로 독립 호스팅되는 모델들입니다.

개발자에게는 그 복잡성이 보이지 않습니다. Fugu는 단일 OpenAI 호환 API 뒤에서 제공됩니다. 모델 ID 하나, 엔드포인트 하나로 사용할 수 있어 SDK 마이그레이션이 필요 없는 대체재로 포지셔닝됩니다 (source: The Decoder, 2026-06). 클라이언트에서는 요청 하나처럼 보이지만, 내부적으로는 작업 배정, 선택된 에이전트로의 위임, 에이전트 간 통신, 검증, 최종 종합까지 포함하는 전체 추론 사이클이 응답 반환 전에 모두 처리됩니다. 호출자는 어떤 모델이 어떤 순서로 실행됐는지 볼 수 없습니다. 쿼리별 라우팅 정책은 독점 기술이며 의도적으로 숨겨져 있습니다.

출시 시점에는 두 가지 티어가 제공되며, 차이는 단순한 브랜딩 이상입니다.

• Fugu(표준): 일상적인 작업에서 지연 시간과 품질의 균형에 맞춰 튜닝됐습니다. 개발자는 풀 안의 특정 제공업체나 모델을 제외할 수 있어, 엔드포인트 뒤에서 무엇이 실행되는지 어느 정도 제어할 수 있습니다 (source: The Decoder, 2026-06).
• Fugu Ultra: 모델 ID는 fugu-ultra-20260615이며, 더 어렵고 중요도가 높은 다단계 문제에서 최대 정확도를 내도록 더 깊고 고정된 에이전트 풀을 사용해 튜닝됐습니다. Ultra에서는 제공업체를 필터링할 수 없습니다. 풀이 잠겨 있습니다 (source: MarkTechPost, 2026-06).

Sakana는 팀이 실시간으로 지출을 모니터링할 수 있도록 요청별 토큰 사용량과 비용을 보고한다고 밝혔으며, 전체 설계를 프런티어 성능으로 가는 또 다른 경로로 설명합니다. 점점 더 큰 네트워크 하나를 학습시키는 대신, 기존 모델을 어떻게 조합하고 라우팅할지 학습하는 방식입니다 (source: The Decoder, 2026-06). 그런 오케스트레이션이 실제로 자신이 조율하는 모델들을 앞서는지는 이 분석의 나머지 부분에서 검증할 주장입니다.

Fugu Ultra는 대부분 앞서지만 MRCRv2에서는 뒤처집니다

Sakana가 2026년 6월 공개한 자체 스코어카드에서 Fugu Ultra(모델 ID fugu-ultra-20260615)는 공개 사용 가능한 Claude Opus 4.8을 대부분의 제시 벤치마크에서 앞섭니다. SWE-Bench Pro는 73.7 대 69.2, TerminalBench 2.1은 82.1 대 74.6, LiveCodeBench는 93.2 대 87.8, LiveCodeBench Pro는 90.8 대 84.8, GPQA-D는 95.5 대 92.0, SciCode는 58.7 대 53.5, CharXiv Reasoning은 86.6 대 84.2, Long Context Reasoning은 73.3 대 67.7이며, Humanity's Last Exam에서도 50.0 대 49.8로 근소하게 앞섭니다 . Sakana가 강조하려는 핵심 메시지는 오케스트레이터가 자신이 조율하는 개별 파운데이션 모델들을 집단적으로 넘어선다는 것입니다.

예외는 장문 컨텍스트 검색 벤치마크인 MRCRv2입니다. 여기서 Fugu Ultra는 93.6점을 받아 Opus 4.8의 87.9점보다 높지만, 해당 행의 최고점은 아닙니다. GPT-5.5가 94.8점으로 앞서고, Gemini 3.1 Pro는 84.9점으로 뒤따릅니다 . 표준 Fugu는 이 지표에서 오히려 Opus 4.8 아래로 내려가며, Opus의 87.9점에 비해 86.6점을 기록했습니다. 따라서 "자신이 호출하는 모든 것을 이긴다"는 프레이밍에는 적어도 하나의 눈에 보이는 단서가 붙습니다. 장문 컨텍스트 라우팅에 가장 직접적인 부담을 주는 워크로드에서는 Fugu가 조율하는 자체 풀 안의 한 모델이 Fugu보다 높은 점수를 냅니다.

최대 정확도보다 일상적 지연 시간에 맞춰 튜닝된 표준 Fugu도 전반적으로 경쟁력은 유지합니다. SWE-Bench Pro 59.0, TerminalBench 2.1 80.2, LiveCodeBench 92.9, HLE 47.2, GPQA-D 95.5(Ultra와 동일), CharXiv Reasoning 85.1입니다 . 두 티어의 격차가 가장 큰 곳은 에이전트형 코딩 관련 행이며, 여기서 Ultra의 더 깊고 고정된 에이전트 풀이 비용에 걸맞은 효과를 내는 것으로 보입니다.

이 수치를 확정적인 것으로 받아들이기 전에 두 가지 방법론상 유의점이 있습니다. 첫째, Sakana는 기준선 수치가 Sakana가 하나의 정규화된 하네스 안에서 재실행한 값이 아니라 제공업체가 보고한 값이라고 밝힙니다. 따라서 Opus, GPT-5.5, Gemini 수치는 각 공급사의 자체 조건에서 나온 것입니다. 둘째, Fugu의 SWE-Bench Pro 결과는 mini-swe-agent 스캐폴딩을 사용했습니다. 즉 Fugu Ultra가 가장 분명하게 이긴 행조차 단일 하네스에서의 완전한 동일 조건 비교는 아닙니다 . 스코어카드는 내부적으로 일관되고 상세하지만, 독립 리더보드 실행이 아니라 벤더 평가입니다. 다음 섹션의 동급 성능 주장으로 넘어가기 전에 붙들고 있어야 할 차이입니다.

Sakana의 가장 대담한 주장과 점수표가 보여주는 것

Sakana는 Fugu가 "Fable 5 및 Mythos Preview와 어깨를 나란히 한다"고 전면에 내세우지만, 이 주장은 공개된 어떤 표로도 검증할 수 없다. Fugu의 공개 비교 시트에서 두 모델 모두 데이터 행으로 나타나지 않기 때문이다 . Sakana가 실제로 공개한 수치는 Fugu를 Claude Opus 4.8, Gemini 3.1 Pro, GPT-5.5와 비교한다. 마케팅에서 언급한 Anthropic의 두 등급 모델이 아니다. 동등하다는 주장과 검증 가능한 점수표가 서로 다른 모델을 가리키고 있다.

"Shoulder-to-shoulder with Fable 5 and Mythos Preview," — Fugu의 프런티어 포지셔닝에 대한 Sakana AI의 프레이밍 (source: The Decoder).

이 간극은 일정으로 설명된다. Anthropic은 2026년 6월 9일 Claude Fable 5와 Mythos 5를 출시하면서, Fable 5를 Mythos급 최신 모델로 소개했다 . 사흘 뒤인 2026년 6월 12일, Anthropic은 미국 정부 지시에 따라 두 모델에 대한 접근을 중단했다 . Fugu가 2026년 6월 22일 공개 출시됐을 때는 두 모델 모두 접근할 수 없는 상태였다 . Anthropic 외부의 누구도 현재 실행할 수 없는 모델과의 비교는 구조적으로 재현 가능하지 않다.

발표 형식도 문제를 키운다. Anthropic은 Fable/Mythos 점수표를 이미지로만 공개했고, Sakana의 행 단위 시트에는 해당 항목들이 아예 빠져 있다 . 공통 표도, 겹치는 평가 하네스도, 제3자가 Fugu Ultra와 Fable 5를 같은 열에 놓고 비교할 수 있는 실시간 엔드포인트도 없다. 따라서 동등하다는 문장은 개발자가 다시 산출할 수 있는 데이터셋이 아니라, 문구와 포지셔닝 안에 존재한다.

검증 가능한 내용은 더 좁고, 분명히 말할 가치가 있다. Fugu의 공개 수치는 Claude Opus 4.8과 직접 비교된다. Anthropic은 이 모델을 2026년 5월 28일 출시했으며 가격은 입력 토큰 100만 개당 5달러, 출력 토큰 100만 개당 25달러였다 . 앞서 다룬 행 단위 승리의 기준선은 바로 이 공개되어 있고 여전히 접근 가능한 모델이다. 예컨대 SWE-Bench Pro에서 Fugu Ultra는 73.7, Opus 4.8은 69.2를 기록했고, 공개된 다른 벤치마크 묶음에서도 비슷한 격차가 나타난다 .

빌더 관점에서 실용적으로 읽으면 이렇다. "Anthropic의 프런티어와 맞먹는다"는 말을 두 개의 별도 주장으로 나눠 봐야 한다. Opus 4.8 비교는 구체적이고 확인 가능하다. Fable 5 / Mythos와의 동등성은 Sakana의 더 넓은 서사이며, 공개된 행 단위 데이터로 뒷받침되지 않는다. 이 둘을 섞어버리면 벤더의 평가 문구가 독립적인 결과처럼 반복된다.

Sakana가 말하는 '더 작다'는 표현의 함정

Sakana는 Fugu를 "더 작은" 모델들을 조율해 프런티어급 성능에 도달하는 방식으로 설명한다. 조율기 자체를 두고 보면 맞는 말이지만, 그 조율기가 움직이는 모델 풀을 두고 보면 오해의 소지가 크다. 학습된 오케스트레이터는 실제로 작다. TRINITY의 조율기는 0.6B 파라미터이고 학습 가능한 헤드는 20K 파라미터 미만이며, Conductor의 조율기는 강화학습으로 훈련된 7B 모델이다 . 하지만 이 조율기들이 호출하는 워커 모델은 비용이나 성능 어느 관점에서도 작지 않다.

Fugu의 프로덕션 풀은 공개적으로 이용 가능한 프런티어 모델들로 구성된다. Claude Opus 4.8, Gemini 3.1 Pro, GPT-5.5급 시스템들이다. 개발자가 직접 선택해 쓸 법한 유료 추론의 최상위 등급과 같다 . Opus 4.8만 해도 입력 토큰 100만 개당 5달러, 출력 토큰 100만 개당 25달러가 청구된다 . "더 작다"는 말은 지휘자를 설명할 뿐, 오케스트라를 설명하지 않는다. Sakana의 메시지는 라우팅 모델의 적당한 크기와, 그 모델이 호출하는 워커 풀의 비용 및 성능을 한데 섞어 말한다.

연구 계보에서도 같은 패턴이 보인다. TRINITY의 풀은 GPT-5, Gemini 2.5 Pro, Claude 4 Sonnet 같은 폐쇄형 프런티어 모델과 DeepSeek-R1-Distill-Qwen-32B, Qwen-3-32B 변형 같은 오픈 웨이트 시스템을 섞었다 . 오픈 웨이트 구성원조차 32B급 모델이지, 가벼운 모델이 아니다. 새로움은 학습된 조율 계층에 있지, 조율되는 기본 컴퓨트가 낮아졌다는 데 있지 않다.

이렇게 보면 빌더가 신중히 따져봐야 할 회복탄력성 주장도 달라진다. Fugu는 벤더 종속을 없애기보다는 재분배한다. 단일 프런티어 제공업체에 대한 하나의 의존성 대신, 표준 Fugu는 Anthropic, Google, OpenAI 세 곳 모두에 대한 동시 의존성을 만든다. 여기에 쿼리별 라우팅 정책은 독점적이고 숨겨져 있으며, 각 모델 간 가중치도 공개되지 않은 채 시간이 지나며 바뀔 수 있다 . Sakana의 주장은 이것이 장점이라는 것이다. 어떤 제공업체가 제한되거나 인수되거나 가격을 올리면, 오케스트레이터가 풀을 교체해 우회할 수 있다는 설명이다 . 이 절충은 실제로 존재한다. 다만 하나의 노출을 더 넓고 덜 투명한 노출로 바꾸는 것이지, 노출이 사라지는 것은 아니다.

Fugu를 뒷받침하는 ICLR 2026 논문: TRINITY와 Conductor

Fugu의 학습된 오케스트레이션은 ICLR 2026에 채택된 Sakana의 두 논문, TRINITY와 Conductor에 기반합니다. TRINITY는 0.6B 파라미터 코디네이터에 학습 가능한 파라미터가 2만 개 미만인 경량 헤드를 결합해, 최대 5턴에 걸쳐 오픈 LLM과 폐쇄형 LLM을 조율하도록 훈련합니다. 각 호출에는 Thinker, Worker, Verifier 역할이 배정됩니다 . 무엇을 누가 할지 결정하는 것은 거대한 모델이 아니라 이 작은 헤드이며, 이것이 Fugu가 이제 상용화한 핵심 아이디어입니다.

공개된 수치는 이 베팅의 이유를 보여줍니다. TRINITY는 LiveCodeBench V6 pass@1에서 0.862를 기록해 GPT-5의 0.838, Gemini 2.5 Pro의 0.672, Claude 4 Sonnet의 0.465를 앞섰습니다. 또한 홀드아웃 점수는 AIME 50.00, BigCodeBench 35.80, MT-Bench 9.60, GPQA-D 76.82로 평균 54.21을 기록해 해당 표의 모든 개별 모델을 넘어섰습니다 . 연구 풀에는 GPT-5, Gemini 2.5 Pro, Claude 4 Sonnet, Gemma-3-27B-It, DeepSeek-R1-Distill-Qwen-32B, Qwen-3-32B 변형 모델들이 포함됐습니다. 프런티어 모델과 오픈 웨이트를 의도적으로 섞은 구성입니다.

Conductor는 같은 원리를 더 크게 확장합니다. 단일 답변을 내놓는 대신, 강화학습으로 7B 코디네이터를 훈련해 작업자 LLM을 위한 자연어 기반 조율 워크플로와 커뮤니케이션 토폴로지를 작성하게 합니다. 공개된 한 비교에서 Conductor-Recursive 변형은 AIME 66.67, BigCodeBench 40.0, GPQA-D 82.32를 기록했으며, Claude Sonnet 4는 35.33/35.8/67.30, GPT-5는 46.67/33.8/72.73이었습니다 .

이 아키텍처를 평가하는 사람에게 핵심이 되는 차이는 mixture-of-experts와의 구분입니다. MoE에서는 라우터가 단일 모델의 포워드 패스 안에서 내부 전문가 서브네트워크를 활성화합니다. 그 전문가들은 사용자가 소유한 가중치입니다. 반면 Fugu의 코디네이터는 네트워크를 통해 별도로 호스팅되는 외부 프런티어 모델, 예컨대 Opus 4.8, Gemini 3.1 Pro, GPT-5.5급 시스템을 호출하고, 그 출력들을 조율하고 검증하며 종합합니다 . 지능은 특정 가중치 묶음 하나가 아니라 라우팅에 있습니다.

이 관점은 Sakana가 실제로 판매하는 것이 무엇인지도 규정합니다. “계속 더 큰 단일 모델을 훈련하는 대신, 기존 여러 모델을 조립하고 라우팅하는 방법을 학습한다”는 것이 회사가 제시한 프런티어급 성능으로 가는 대안 경로입니다 . 중요한 점은 Fugu가 코디네이터 가중치를 공개하는 것이 아니라 이 오케스트레이션 계열을 상용화한다는 것입니다. 제품은 훈련된 코디네이터와 독점 라우팅 정책입니다. 이미 직접 호출할 수 있는 하위 모델들이 아닙니다. 사용자가 구매하는 것은 의사결정 계층이며, 그 계층은 비공개로 유지됩니다.

운영 제약: EU 제외, 불투명한 모델 풀, 예측하기 어려운 청구액

폐쇄형 의사결정 계층을 도입할 때는 Fugu 채택 전에 비용에 반영해야 할 세 가지 구체적 trade-off가 있습니다. 지역 제한이 있고, 라우팅을 감사할 수 없으며, 요청당 비용을 예측하기 어렵다는 점입니다. Sakana는 GDPR 및 EU별 컴플라이언스를 준비하는 동안 출시 시점에는 Fugu를 EU/EEA에서 제공하지 않으며, 공개된 제공 시작일도 없다고 밝혔습니다 . EU 기반 개발자는 현재 다른 경로가 필요합니다. 기본 프런티어 모델을 직접 호출하거나, 이미 해당 지역에서 운영되는 제공업체를 통해 라우팅해야 합니다.

모델 풀에 대한 제어권은 요금제에 따라 달라집니다. 표준 Fugu에서는 요청별로 특정 제공업체나 하위 모델을 제외할 수 있습니다. 컴플라이언스, 데이터 레지던시, 벤더 정책상 특정 공급업체를 배제해야 할 때 유용합니다. Fugu Ultra에서는 이 선택권이 사라집니다. 에이전트 풀은 고정되어 있으며 제공업체 필터링을 할 수 없습니다 . 더 높은 중요도의 워크로드가 Ultra 정확도 등급을 필요로 한다면, Sakana가 라우팅하는 어떤 모델이든 받아들여야 합니다. 쿼리별로 공개하지 않는 인스턴스도 포함됩니다.

이 불투명성은 의도된 설계입니다. 쿼리별 라우팅 정책은 독점이며 의도적으로 숨겨져 있어, 특정 요청에 어떤 하위 모델이 답했는지 볼 수 없습니다 . Sakana는 실시간 지출 모니터링을 위해 요청별 총 토큰 사용량과 청구액을 제공하지만, 그 숫자 뒤의 구성 요소별 내역은 제공하지 않습니다 . 코디네이터가 여러 턴에 걸쳐 여러 모델, 그리고 자기 자신의 인스턴스까지 호출할 수 있기 때문에, 구조적으로 비슷한 두 요청도 매우 다른 총액을 만들 수 있습니다. 비용은 사후에 관찰할 수 있을 뿐, 사전에 예측하기는 어렵습니다.

가격도 이런 가변적인 fan-out 현실을 반영합니다. Fugu Ultra 종량제와 구독 요금제는 다음과 같습니다 :

실무적으로는 이렇게 정리됩니다. 팀이 EU에 있거나, 컴플라이언스를 위해 제공업체 수준의 제어가 필요하거나, 요청당 지출을 촘촘히 예측해야 한다면, 이 제약들은 현재로서는 단순한 예외 상황이 아니라 도입을 막는 요소입니다.

Fugu 도입 전 직접 검증해야 할 지표

프로덕션 트래픽을 Fugu로 보내기 전에, 출시 때 공개된 성적표를 그대로 믿기보다 본인 워크로드로 벤치마크해야 합니다. Sakana의 2026년 6월 평가에 따르면 Fugu Ultra는 공개 Claude Opus 4.8보다 나열된 대부분의 벤치마크에서 앞섭니다. 예를 들어 SWE-Bench Pro는 73.7 대 69.2, LiveCodeBench는 93.2 대 87.8입니다 . 하지만 이는 Sakana가 보고한 집계 수치이고, 기준선도 제공업체가 보고한 값이며, 독립적으로 정규화된 단일 실행 결과는 아닙니다 . 공개 평균은 작업별 실제 차이를 예측해 주지 않습니다. 실제 작업 분포를 Fugu Ultra에 돌리고, 접근 가능한 경우 Fugu가 조율하는 개별 프런티어 구성 모델에도 돌린 뒤, 애플리케이션에 중요한 지표로 비교하세요.

가장 중요한 측정 항목은 네 가지입니다.

• 리더보드가 아니라 내 작업에서의 품질. 이 오케스트레이터는 라우팅 대상이 되는 기반 모델들을 전반적으로 앞선다고 보고됐지만, Fugu가 모든 항목에서 1위는 아닙니다. MRCRv2에서는 Opus 4.8(87.9)이 표준 Fugu(86.6)를 앞서고, GPT-5.5가 94.8로 해당 항목을 이끕니다 . 워크로드가 그런 항목과 비슷하다면 단일 구성 모델이 여전히 더 나을 수 있습니다.
• 꼬리 지연 시간(P95/P99). 다중 홉 조율은 요청 하나마다 여러 하위 모델 호출을 거치므로, 꼬리 지연 시간이 단일 구성 모델 기준선과 크게 벌어질 수 있습니다. 중앙값 지연 시간은 이를 가립니다. 현실적인 동시성 조건에서 P95와 P99를 측정하세요.
• 쿼리당 토큰 증가량. 조율 과정에서는 하위 호출 전반에 입력 토큰이 확장됩니다. Sakana는 지출 모니터링을 위해 요청당 토큰 사용량과 비용을 보고한다고 밝힙니다 . 이는 청구서 수준에서는 도움이 되지만, 집계 총량은 개별 작업 유형의 오버헤드를 가립니다. 작업별로 추적해 오케스트레이션 비용 때문에 경제성이 떨어지는 작업을 찾아야 합니다.

먼저 표준 Fugu로 프로토타입을 만드세요. 표준 Fugu에서는 특정 제공업체나 모델을 제외할 수 있지만, Fugu Ultra의 더 깊은 풀은 고정되어 제공업체 필터링이 불가능하며, 쿼리별 라우팅 정책도 독점적이고 비공개입니다 . 이 제외 제어권이 있어야 불투명한 고정 풀에 커밋하기 전에 표준 Fugu를 컴플라이언스와 비용 통제 관점에서 감사할 수 있습니다.

핵심은 이렇습니다. Fugu를 채택할 벤치마크 헤드라인이 아니라 측정해야 할 라우팅 계층으로 다루세요. 자체 품질, P99 지연 시간, 작업별 토큰 수치가 버텨 주고, EU 제공 여부와 제공업체 필터링 제약이 발목을 잡지 않는다면 벤더 회복력 측면의 가치는 실제입니다. 그렇지 않다면 자체 얇은 라우터 뒤에 단일 프런티어 모델을 두는 편이 여전히 더 저렴하고 예측 가능할 수 있습니다.

최종 업데이트: 2026-06-23.

자주 묻는 질문

Fugu는 기존 LLM API 호출을 코드 변경 없이 대체할 수 있나요?

대체로 그렇습니다. Fugu는 단일 OpenAI 호환 API 뒤에서 제공되며, SDK 마이그레이션이 필요 없는 드롭인 대체재로 포지셔닝되어 있습니다 . 실제로는 대부분의 SDK 통합에서 새 base URL과 모델 ID를 지정하면 계속 동작한다는 뜻입니다. 프로덕션 전에는 래퍼가 보장하지 않는 엣지 케이스를 확인하세요. 스트리밍 청크 동작, 컨텍스트 윈도 제한(Fugu Ultra는 272K 토큰 초과 시 가격 구간이 바뀜), 그리고 사용 중인 특정 SDK 버전의 응답 형식 가정이 여기에 해당합니다. 엔드포인트 계약은 호환되지만, 개별 클라이언트의 엣지 처리 방식은 여전히 테스트가 필요합니다.

Fugu Ultra의 하위 모델 풀이 고정된 이유는 무엇이고, 왜 제공업체를 필터링할 수 없나요?

Sakana는 더 어렵고 중요도가 높은 다단계 문제에서 최대 정확도를 내도록 Fugu Ultra를 더 깊은 고정 에이전트 풀로 튜닝했으며, 제공업체 제외 옵션은 표준 Fugu에서만 제공합니다 . 이는 제어권과 최고 정확도 사이의 절충입니다. 풀을 고정하면 오케스트레이터가 최상의 결과를 위해 자유롭게 라우팅할 수 있지만, 사용자는 특정 제공업체나 모델을 제외할 수 없습니다. 컴플라이언스상 특정 벤더를 제외해야 한다면 Fugu Ultra는 맞는 티어가 아닙니다. 특정 제공업체를 제외할 수 있는 표준 Fugu를 사용하고, 더 낮은 벤치마크 상한을 받아들여야 합니다.

EU 개발자도 Fugu를 사용할 수 있나요?

아니요. Sakana는 출시 시점에 GDPR 및 EU별 컴플라이언스를 준비하는 동안 Fugu를 EU/EEA에서 제공하지 않는다고 밝혔습니다 . 제공 일정은 공개되지 않았습니다. EU 기반 개발자는 당분간 Fugu에 의존할 수 없으며, Sakana가 컴플라이언스를 확인하고 지역 접근을 열 때까지 자체 라우팅 계층 뒤의 단일 프런티어 모델 같은 대안이 필요합니다.

Fugu Ultra 가격은 프런티어 모델을 직접 호출하는 것과 어떻게 다른가요?

Fugu Ultra 종량제는 입력 100만 토큰당 5달러, 출력 100만 토큰당 30달러이며, 캐시 입력은 100만 토큰당 0.50달러입니다. 272K 컨텍스트를 넘으면 각각 10달러/45달러/1.00달러로 올라갑니다 . Anthropic의 공개 Claude Opus 4.8은 입력 100만 토큰당 5달러, 출력 100만 토큰당 25달러입니다(빠른 모드에서는 10달러/50달러) . 표면적인 단가는 비슷해 보이지만, 오케스트레이션에는 위임, 검증, 종합 같은 에이전트 간 토큰 오버헤드가 추가되며 이는 단일 모델 견적에는 나타나지 않습니다. 실제 비용은 쿼리 하나가 얼마나 많은 내부 호출을 유발하는지에 따라 달라지므로, 예산을 추정하기 전에 실제 작업 조합으로 벤치마크하세요.

각 Fugu 요청을 어떤 하위 모델이 처리했는지 볼 수 있나요?

아니요. 쿼리별 라우팅은 독점적이며 의도적으로 공개되지 않습니다. Sakana는 요청당 총 토큰 사용량과 비용은 보고하지만 개별 구성 모델 attribution은 제공하지 않습니다 . 실시간 모니터링을 위한 총 지출 수치는 얻을 수 있지만, Opus 4.8, Gemini 3.1 Pro, GPT-5.5급 모델 중 어떤 프런티어 모델이 특정 단계를 처리했는지에 대한 세부 내역은 제공되지 않습니다. 이 불투명성은 문서화된 설계 선택이며, 비결정적 출력 디버깅과 데이터가 정확히 어디에서 처리됐는지 알아야 하는 컴플라이언스 워크플로에는 알려진 한계입니다.