일본 Sakana AI의 멀티에이전트 시스템으로, API 하나로 부르면 안에서 코디네이터 모델이 여러 프론티어 모델에 일을 나눠 맡기고 결과를 합쳐 답 하나로 돌려준다. 속도보다 답의 깊이가 중요한 어렵고 여러 단계로 된 작업에 쓴다.
| 방식 | 특징 | 이럴 때 쓴다 |
|---|---|---|
| 단일 모델 직접 호출 | 모델 하나가 바로 답한다 | 빠르고 예측 가능한 응답이 필요할 때 |
| Fugu | 지연이 짧은 기본 버전 | 조율은 맡기되 속도도 중요할 때 |
| Fugu Ultra | 품질 최우선 | 고난도 추론, 복잡한 코딩 |
| 직접 만든 멀티에이전트 | 모델 선택·폴백·합성을 직접 구현한다 | 내부 흐름을 통제하고 추적해야 할 때 |
2026년 6월에 나왔고, 지연이 짧은 기본 버전 Fugu 위에 품질을 최우선으로 둔 상위 버전이다.
Fugu Ultra 자체도 약 70억 파라미터 규모의 LLM이지만, 질문에 직접 답하도록 훈련되지 않았다. 요청이 오면 작업을 분석해 자신이 관리하는 모델 풀에서 알맞은 모델을 1~3개 고르고, 각 모델에 일을 맡긴 뒤 나온 결과를 검증하고 합친다.
여러 전문가를 둔 에이전시를 떠올리면 쉽다. 클라이언트는 에이전시에 일만 맡기고, 어떤 전문가를 투입할지는 에이전시가 정한다. 그동안 직접 구현해야 했던 모델 선택, 폴백, 결과 합치기를 API 호출 한 번에 넘기는 셈이다.
OpenAI 호환 API라서, OpenAI SDK를 쓰던 코드라면 base URL을 Sakana 쪽으로 바꾸고 모델을 sakana/fugu-ultra로 지정하면 바로 연결된다. 메시지 형식은 기존 그대로 써도 된다.
모든 요청을 Fugu Ultra로 보낼 필요는 없다. 여러 단계로 따져야 하는 분석이나 까다로운 코딩 문제만 Fugu Ultra로 보내고, 짧은 질의응답이나 분류 같은 단순 작업은 기존 단일 모델에 남겨 두면 지연과 비용을 함께 줄일 수 있다.
| 주의점 | 이유 | 대응 |
|---|---|---|
| 추적이 어렵다 | 어떤 모델이 무엇을 처리했는지 알 수 없다 | 디버깅·감사가 필요하면 직접 구현 |
| 지연이 길다 | 여러 모델을 차례로 호출한다 | 실시간 응답에는 단일 모델이나 Fugu |
| 비용 예측이 어렵다 | 요청마다 호출하는 모델이 달라진다 | 실제 작업으로 먼저 측정 |
| 지역 제한 | 출시 당시 EEA 등 일부 지역은 접근 제한 | 쓰려는 지역에서 접근되는지 확인 |
품질이 얼마나 좋아지는지는 작업마다 다르다. 자주 맡길 실제 작업을 몇 개 골라 기존 모델과 Fugu Ultra에 똑같이 보내 보고, 답의 품질과 응답 시간, 청구 금액을 비교한 뒤 어디까지 맡길지 정하는 게 안전하다.
가장 흔한 방식은 기존 앱의 기본 모델은 그대로 두고, 막히는 어려운 요청만 Fugu Ultra로 보내는 것이다. OpenAI 호환이라 모델명만 바꿔 끼우면 돼서 이렇게 나눠 쓰기 쉽다.
| 어디서 | 어떻게 쓰나 |
|---|---|
| 코딩 에이전트 | 평소엔 단일 모델로 돌리다가, 까다로운 버그나 설계 문제가 나온 단계만 Fugu Ultra로 |
| 분석·리서치 작업 | 여러 단계로 따져야 하는 분석을 맡기고, 응답이 느려도 되는 배치 작업으로 돌린다 |
| OpenAI SDK 기반 앱 | base URL과 모델명만 바꿔, 어려운 질의만 Fugu Ultra로 보내는 분기를 둔다 |