결정 모델이 조용히 에이전트 루프의 LLM을 대체하고 있다

Cloudflare는 10월 첫날에 아무것도 작성하지 않는 두 가지 모델을 출시했다. Clef와 Clef-flash는 입력과 함께 타입이 지정된 질문 세트를 읽고, 허용된 모든 답변에 대한 확률을 반환한다. 산문도, 사고의 사슬(chain of thought)도, 한 번에 하나씩 생성되는 토큰도 없다. 그저 구조화된 선택일 뿐이다.

숫자를 보기 전까지는 퇴보처럼 들린다. 표준 의도 분류 벤치마크인 BANKING77에서 Clef는 매크로 F1 94.20을 기록해, 결정 모델 카테고리를 처음 선보인 Jev의 79.74를 앞선다. 더 작은 9B 버전인 Clef-flash도 90.93을 달성한다. 지연 시간 격차는 더 크다. Clef-flash는 중앙값 38.8밀리초 만에 답변을 반환하는 반면 Jev는 524.1밀리초가 걸린다. Cloudflare는 Clef가 10개 결정 벤치마크 중 7개에서 Jev를 앞선다고 말한다.

두 모델 모두 Hugging Face에 Apache 2.0 라이선스로 공개되었고, 둘 다 Jev API와 호환되므로 이미 Jev를 기반으로 구축한 팀은 통합을 다시 작성하지 않고도 전환할 수 있다. Hacker News 스레드는 하루 만에 602점과 200개 이상의 댓글을 기록했다.

더 작은 모델이 더 좁은 작업에서 이길 수 있는 이유

결정 모델은 대부분의 개발자가 찾는 챗봇과는 형태가 다르다. 대규모 언어 모델은 개방형 텍스트를 생성한다. 결정 모델은 상태와 허용된 답변 목록을 읽고 각각에 점수를 매긴다. 이 카테고리는 Typesafe AI가 Jev로 개척했으며, 에이전트 라우팅이나 분류 작업에는 400B 범용 모델이 필요하지 않다는 것을 보여주었다. 필요한 것은 범위가 한정되고 저렴하며 빠른 출력이다.

Cloudflare의 Clef는 Qwen3.8-27B를 기반으로 구축되었으며, 토큰을 순차적으로 생성하는 대신 스키마 선택지를 병렬로 채점하는 프리필 전용(prefill-only) 아키텍처를 사용한다. 지연 시간은 바로 여기서 발생한다. 범용 모델은 토큰을 하나씩 내보내야 하지만, 결정 모델은 질문을 읽고 결정만 내리면 된다.

주목할 만한 컨텍스트 차이도 있다. Clef는 64k 토큰 윈도우 내에서 텍스트, JSON, 이미지, 동영상을 아우르는 멀티모달 입력을 받아들인다. Jev는 32k로 텍스트만 처리한다. 스크린샷이나 PDF를 기준으로 라우팅하는 에이전트에게 이는 작은 우위가 아니다.

커뮤니티의 첫 번째 반론은 옳았다

Hacker News 토론에서 가장 유용한 반박은 벤치마크를 문제 삼지 않았다. 그것은 명칭을 문제 삼았다. 한 댓글 작성자는 "오픈 웨이트지, 오픈 소스가 아니다"라고 썼다. 가중치에는 허용적 라이선스가 적용되지만, 학습 데이터와 파이프라인은 공개되지 않아 모델을 처음부터 재현할 수 없다.

이 구분은 이것을 어디에서 실행할지 결정하는 사람에게 중요하다. Clef는 독점적인 Qwen 출발점을 기반으로 학습되었다. 가중치는 무료로 다운로드하고 호스팅할 수 있어 실제 비용 절감이 되지만, 오픈소스 소프트웨어처럼 감사할 수는 없다. 엄격한 공급망 검토 정책을 가진 팀은 Apache 2.0 태그가 문제를 해결해 준다고 가정하기 전에 라이선스와 모델 카드를 읽어봐야 한다.

같은 주, Amazon은 노트북에 하나를 넣었다

Cloudflare만이 아니었다. AWS의 Strands Labs는 가중치와 학습 스크립트를 포함한 오픈 결정 모델인 Strands Decider 2B를 공개했는데, 로컬에서 실행되어 수십에서 수백 밀리초 내에 신뢰도 점수가 매겨진 선택지를 반환하도록 설계되었다. Cloudflare는 또한 Workers AI에서 자사 결정 모델을 위한 RL 파인튜닝 서비스를 추가했다.

패턴은 하나의 작업을 잘 수행하며 데이터 가까이에서 실행되는 소형 모델이다. 도구 호출을 막거나, 요청이 근거에 기반하는지 검증하거나, 에스컬레이션 여부를 2B 모델로 40밀리초 만에 결정할 수 있다면, 모든 단계를 프런티어 모델을 통해 에이전트를 라우팅하는 경제성은 낭비처럼 보이기 시작한다.

Jev가 도입한 패러다임, 그리고 정착하는 데 1년이 걸린 이유

Typesafe AI의 Jev는 출시 당시 무시하기 쉬운 주장을 했다. 에이전트가 모델에 요청하는 일의 대부분은 생성이 아니라 분류라는 것이다. 이 티켓을 라우팅하고, 이 도구를 고르고, 이 작업에 승인이 필요한지 결정하는 것. 그러한 작업에서는 문단을 작성하는 모델이 필요한 것보다 훨씬 많은 일을 하고 있는 셈이다.

Jev는 좁은 접근 방식이 자체 벤치마크에서 범용 모델을 이길 수 있음을 입증했다. 하지만 그 카테고리가 시급하게 느껴지게 만들지는 못했다. 단일 벤더가 결정 모델 하나를 파는 것은 진기한 일에 불과하다. Cloudflare가 Jev의 API와 호환되는 Apache 2.0 버전을 출시한 것은 상황이 다르다. 이제 누구나 호스팅하고, 라이선스를 검토하고, 다시 작성하지 않고 교체할 수 있기 때문이다. 같은 주에 Amazon이 자체 오픈 디사이더를 들고 나타나면서 진기함은 하나의 카테고리가 되었다.

시기는 에이전트가 실제로 구축되는 방식과 맞아떨어진다. 1세대 에이전트 프레임워크는 가장 단순하다는 이유로 모든 단계를 하나의 대형 모델을 통해 라우팅했다. 그러한 시스템이 프로덕션으로 넘어가면서 라우팅 비용이 팀이 체감하는 문제가 된다. 루프를 언어가 필요한 부분은 언어 모델로, 그렇지 않은 부분은 디사이더로 나누는 것이 명백한 해결책이며, 좋은 디사이더의 오픈 공개가 있어야 그것이 실용화되었다.

파인튜닝이라는 관점

Cloudflare는 또한 Workers AI에서 자사 결정 모델을 위한 RL 파인튜닝 서비스를 추가했는데, 이는 이 카테고리가 다음에 어디로 향할지 보여준다. 범용 디사이더도 유용하다. 하지만 자체 라우팅 이력, 자체 에스컬레이션 규칙, 자체적인 범위 개념으로 파인튜닝된 디사이더는 더 유용한데, 비즈니스에 중요한 경계를 학습하기 때문이다.

이것은 또한 팀을 신중하게 만들어야 하는 부분이기도 하다. 파인튜닝된 디사이더는 잘못된 결정을 포함해 과거의 결정을 그대로 담는다. 팀이 에스컬레이션했어야 할 환불을 승인하곤 했다면, 모델은 그 패턴을 학습해 인간이 할 수 있는 것보다 더 빠르게 적용할 것이다. 캘리브레이션은 양방향으로 작용한다.

에이전트 파이프라인에서 이것이 들어갈 자리

환불을 처리하는 지원 에이전트를 떠올려 보자. 환불 도구를 호출하기 전에, 이런 질문에 답해야 하는 무언가가 필요하다. 이 요청이 범위 안에 있는가, 고객 계정이 이를 허용하는가, 사람이 개입해야 하는가. 이들은 정해진 답변 집합을 가진 결정 질문이다. 결정 모델이 확률을 반환하면 에이전트는 임계값에 따라 행동한다.

핵심은 비용 구조다. 그러한 검사 하나하나를 400B 모델로 라우팅하면 호출당 비용이 들고 수백 밀리초의 지연이 추가된다. 이를 로컬 2B 또는 9B 디사이더로 넘기면 실제로 언어가 필요한 부분—답변 작성, 긴 스레드 요약, 모호한 사례 처리—에 프런티어 모델을 남겨둘 수 있다. 비용 예산과 지연 예산이 모두 줄어든다.

함정이 있다. 결정 모델은 확률을 반환하는데, 확률은 자신감 있게 틀릴 수 있다. 0.92 점수로 환불 승인을 자동화한다면, 위험을 모델의 문구에서 임계값으로 옮긴 것이다. 지켜봐야 할 숫자는 원시 정확도가 아니라 캘리브레이션이다. 지연 시간과 비용은 측정하기 쉽지만, 잘 캘리브레이션된 0.9는 더 어렵다.

다음에 지켜볼 것

툴링은 이미 모델을 따라가고 있다. llama.cpp는 결정 모델 지원을 추가했고, Perplexity와 Hugging Face도 같은 방향에 베팅하고 있다. 이 카테고리가 유지된다면, 흥미로운 질문은 어떤 결정 모델이 벤치마크에서 이기는가가 아니라 어떤 결정을 확률에 맡길 의향이 있는가로 바뀐다.

에이전트 개발자에게 실용적인 움직임은 루프를 감사하여 유창한 텍스트가 전혀 필요 없었던 단계를 찾는 것이다. 분류, 라우팅, 도구 선택, 사전 작업 검사가 일반적인 후보들이다. 바로 그 단계에서 정해진 선택지 집합에 대한 40밀리초짜리 답변이 느리고 비싼 생성을 대체할 수 있다. 나머지 에이전트는 이미 사용하던 모델에 그대로 남겨두면 된다.