Sakana Fugu: 모델을 소유하는 것보다 오케스트레이션하는 것이 더 강력할 때

요약

Sakana AI가 출시한 Fugu는 자체 프런티어 모델을 훈련하는 대신, 기존의 강력한 모델들을 지휘하고 라우팅하는 오케스트레이션 시스템입니다. 7B 규모의 작은 모델이 작업을 분석해 최적의 모델에 할당함으로써 주요 벤치마크에서 최상위 모델들과 대등하거나 능가하는 성능을 보여줍니다.

핵심 포인트

Fugu는 모델 소유가 아닌 모델 간 오케스트레이션을 통해 성능을 극대화함
7B 규모의 라우팅 모델이 Gemini, Claude, GPT 등 다양한 모델을 지휘
SWE-Bench Pro 등 주요 벤치마크에서 프런티어 모델들을 능가하는 결과 보고
단일 벤더 의존성을 줄이는 리스크 관리 및 장애 조치(failover) 수단으로 활용 가능

올해의 모든 거대한 AI 이야기는 동일한 방향을 가리키고 있습니다. 즉, 경쟁의 우위가 모델 자체에서 그 주변을 둘러싼 레이어 (layer)로 이동하고 있다는 점입니다. Sakana AI가 새로 출시한 Fugu (그리고 더 무거운 Fugu Ultra)는 이러한 아이디어를 가장 문자 그대로 구현한 버전입니다. 이는 자체적인 프런티어 모델 (frontier model)을 훈련하지 않고도, 프런티어 모델들을 지휘 (conducting) 함으로써 그들을 이기는 시스템입니다.

이것의 실체

Fugu는 더 큰 LLM (대규모 언어 모델)이 아닙니다. 이는 라우팅 (routing)을 수행하도록 훈련된 작은 (~7B) 모델입니다. 즉, 작업을 가져와서 풀 (pool) 안에 있는 어떤 강력한 모델(Gemini 3.1 Pro, Claude Opus 4.8, GPT-5.5 등)이 각 부분을 처리해야 할지 결정하고, 작업을 할당한 뒤, 하나의 답변으로 합성합니다. 긴 작업에 대해서는 자기 자신을 재귀적으로 호출할 수 있습니다 (실행하고, 이전 출력을 읽고, 수정하는 과정). 하나의 OpenAI 호환 API 뒤에 두 가지 티어 (tier)가 제공됩니다: 일상적인 속도와 품질을 위한 일반 Fugu, 그리고 더 넓은 전문가 풀을 활용하여 까다로운 다단계 작업을 수행하는 Fugu Ultra입니다.

주장된 결과 — 그리고 주의사항

Sakana는 Fugu가 11개의 벤치마크 중 10개에서 Opus 4.8, Gemini 3.1 Pro, GPT-5.5를 능가했다고 보고합니다:

SWE-Bench Pro: Fugu Ultra 73.7 vs Opus 4.8 69.2, GPT-5.5 58.6, Gemini 3.1 Pro 54.2.
Humanity's Last Exam: 50.0으로, Opus 4.8 (49.8)을 근소하게 앞섬.
GPQA-D: 95.5로, 해당 분야 최고 수준.
유일한 패배: MRCRv2 (GPT-5.5 94.8 vs Fugu Ultra 93.6).

숫자만큼이나 중요한 두 가지 주의사항이 있습니다: 결과는 공급업체가 보고한 것이며 독립적으로 검증되지 않았고, Anthropic의 가장 강력한 모델들(Fable 5, Mythos)은 공개되지 않았기 때문에 풀 (pool)에 포함되지 않았습니다. 따라서 Fugu는 절대적인 최강의 모델이 아니라, 자신이 접근할 수 있는 모델들을 오케스트레이션 (orchestrating) 함으로써 프런티어 모델과 대등해지는 것입니다. 리더보드를 하나의 주장으로 읽으십시오.

진정한 통찰: 기능으로서의 회복탄력성 (resilience)

Sakana의 핵심적인 제안은 벤치마크가 아닙니다. 바로 오케스트레이션 (orchestration)을 **보험 (insurance)**으로 프레이밍하는 것입니다. 여러 제공자 (providers)를 가로질러 라우팅 (routing)한다는 것은, 특정 모델이 제한되거나, 속도 제한 (rate-limited)이 걸리거나, 가격이 재조정되거나, 혹은 서비스가 중단되더라도 Fugu가 나머지 풀 (pool)로 경로를 재설정한다는 것을 의미합니다. 이는 조달 (procurement) 측면에서의 논리이며, 매우 설득력이 있습니다. 단일 벤더 (single-vendor) 의존성은 실제 운영상의 리스크이기 때문입니다. 라우팅 레이어 (routing layer)는 "우리 제공업체에 문제가 생겨서 우리 AI가 중단되었다"라는 상황을 "장애 조치 (failover)가 이루어졌다"로 바꿔 놓습니다.

시사점 (The takeaway)

정확한 수치가 유지되는지 여부와 상관없이, Fugu는 올해의 조용한 가설을 명확하게 드러냅니다: 오케스트레이션 (orchestration) 그 자체로 하나의 프런티어 역량 (frontier capability)이 되고 있다는 점입니다. 프런티어급 결과물을 얻기 위해 더 이상 프런티어 모델을 직접 소유할 필요는 없습니다. 단지 존재하는 모델들을 가로질러 라우팅하고, 거버넌스 (govern)를 수행하며, 합성 (synthesize)할 수 있는 엔지니어링 역량만 있으면 됩니다. 물론 트레이드오프 (tradeoffs)도 실재합니다: 지연 시간 (latency) 및 비용의 증가, 그리고 호출하는 모든 제공자에게 데이터 노출 범위가 넓어진다는 점입니다 (이는 주권 (sovereignty)을 위해 오픈 웨이트 (open-weight) 모델을 셀프 호스팅 (self-hosting)하는 것의 거울 이미지와 같습니다). 대부분의 진지한 플랫폼들은 의도적으로 이 두 가지 방식을 모두 채택하게 됩니다.

부동산 / 프롭테크 (PropTech) 관점을 포함한 전체 버전은 VSBD 블로그에서 확인할 수 있습니다. 출처: Sakana AI — Fugu.

AI 자동 생성 콘텐츠

원문 바로가기