분명히 말하자면, 이것은 폐쇄형 모델 (closed source models) 위에 구축된 폐쇄형 오케스트레이터 (closed source orchestrator)입니다. 이전에도 모델을 제어할 수 없었다면, 이제는 어떤 모델이 사용되는지, 혹은 얼마나 사용되는지조차 제어할 수 없습니다. 이것은 "AI 주권 (AI sovereignty)"이 아닙니다.

기술적인 부분에 대한 의견을 얻기 위해 기술 보고서 (tech report)도 읽어보았습니다:

fugu (ultra 버전 제외)는 기본적으로 매 턴마다 어떤 모델이 정답을 맞힐 가능성이 가장 높은지 선택하는 분류기 (classifier)입니다 (즉, 라우터 (router)입니다). 이로 인해 opus와 비교했을 때 SWE Bench pro에서 -10점을 기록했으며, 다른 벤치마크 (benchmarks)에서는 약간의 이득을 얻었으나 매우 미미합니다. 비용을 절감한다는 주장을 할 수도 있겠지만, 이에 대한 정보가 없으므로 오히려 그 반대일 가능성이 높습니다. 또한 그들은 프런티어 모델 (frontier models)인 "Model A, B, C"와 비교하는 오토리서치 (autoresearch) 벤치마크를 가지고 있는데, 어떤 모델과 비교하는지 투명하게 공개하지 않는 것은 정말 말도 안 되는 일입니다. 또한 분류기 (classifier)를 재학습시켜야 하기 때문에, 아마도 새로운 LLM을 즉시 추가하는 기능은 지원하지 않을 것입니다.

fugu ultra에 대해 말하자면, 이것은 기본적으로 고급 계획 모드 (advanced plan mode)이자 오케스트레이터 (orchestrator)입니다. 이는 쿼리에 대해 여러 "워크플로 (workflows)"가 포함된 계획을 출력하는 모델입니다. 제가 이해한 워크플로 (workflows)는 다음과 같습니다: "이를 달성하기 위해 모델 A의 하위 에이전트 (subagents)를 생성하고, 모델 B를 사용하여 이를 판단한 다음, 모델 C로 이를 요약하라"와 같은 방식인데, 이는 단지 테스트 시간 스케일링 연산 (test time scaling compute) 전략일 뿐입니다. 이것이 괜찮은 방식이라고 생각하지만, 에이전트들이 작업을 시작하기 전에 모든 것을 예측해야 한다는 점 때문에 한계가 있으며, 이것이 그들이 이를 5단계로 제한하는 이유입니다. 제 생각에는 t=0에서 얻은 정보가 아니라, t에서 얻은 정보를 바탕으로 t+1에 무엇을 생성할지 예측해야 합니다. 또한 Terminal Bench에서의 Fable 5 점수가 틀렸다는 점이나, LLM 풀 (LLM pool)에 어떤 모델이 있는지에 대해 매우 모호하고 불분명하다는 점 (그들은 폐쇄형 API 모델만 언급합니다) 등의 다른 문제들도 있습니다.

가장 크고 명백한 문제는 그들이 모델들에 대한 "best of N" 방식을 사용한 "테스트 시간 스케일링 (test time scaling)" 방법을 도입하면서, 벤치마크/태스크를 달성하기 위해 사용된 출력 토큰(output tokens)의 수나 비용을 말 그대로 전혀 보고하지 않는다는 점입니다.

여기서 적절한 비교 대상은 Opus가 아니라 Ultracode/workflows가 활성화된 Opus이며, Kimi가 아니라 Kimi Swarm 등입니다. 매우 매우 혼란스러운 출시입니다.