Clef는 의도적으로 Jev의 API를 모방한다 — 그리고 바로 그 점이 흥미로운 부분이다

Clef는 270억 개의 매개변수를 가진 Cloudflare의 멀티모달 모델로, 입력된 질문에만 답하고 다른 것은 하지 않는다. 여기에 상태(텍스트, JSON, 이미지, 비디오 프레임)와 최대 64개의 명명된 질문 스키마를 제공하면, 한 번의 순방향 패스로 모든 허용된 옵션에 대한 확률을 반환한다. 생성된 텍스트도, 파서도, 디코딩 루프도 없다. 무엇이 Cloudflare/clef를 읽을 가치가 있게 만드는가? 그것은 그것이 차용한 그 설계가 아니라, 그것이 선택한 와이어 포맷이다: Cloudflare는 Clef가 요청 및 응답 본문을 말하도록 만들었는데, 그 대상은 Jev System One이다. 이 모델은 TypeSafe가 처음 출시한 결정 모델로, 동일한 POST /v1/systemone 경로에서 제공된다. 여기서 상호 운용성이 전체 상업적 논거이다. 파이프라인이 이미 그 형태로 결정 모델에 질문을 던지고 있다면, Clef는 마이그레이션이 아니라 URL 변경과 모델 문자열에 불과하다.

릴리스 게시물이 묻어두기에는 이례적인 일이며, Cloudflare는 그것을 묻어두지 않는다 — 모델 카드에는 API가 "Jev 및 SystemOne과 완전히 호환된다"라고 단호히 적혀 있고, 블로그는 TypeSafe가 이 범주를 세상에 알린 공로를 인정하는 것으로 시작한 뒤 Clef를 내부 실험의 2세대 버전으로 위치시킨다. 따라서 이 릴리스를 정직하게 해석하면 세 부분이다: 호환성 결정이 가져다주는 것, Cloudflare 자체 수치가 Clef가 어디서 이기고 지는지에 대해 말하는 것, 그리고 그 표의 모든 수치가 이 모델을 출시한 공급업체에 의해 산출되었기 때문에 무엇이 아직 검증되지 않았는지.

카테고리는 다른 곳에서 왔습니다

Cloudflare의 글은 그 계보에 대해 솔직하다. 산문이 아니라 경계가 정해진 구조화된 출력을 반환하는 모델이라는 아이디어는 TypeSafe의 Jev System One에 공로가 돌아간다. Cloudflare가 들어온 경로는 확산 모델을 비틀어 logprobs를 노출함으로써 결정론적 확률을 내보내게 만든 이전 데모, 그리고 Matt Mastracci가 추론 엔진이 그 패턴을 처리하도록 만든 커뮤니티 작업이었다. Clef는 다른 백본, 목적에 맞게 제작된 스코어링 헤드, 그리고 — 상업적으로 중요한 부분인 — 기존 업체의 것과 일치하는 요청 본문을 갖추고 그 개념을 발전시킨다.

벤더가 경쟁사의 와이어 포맷을 복사하면서 동시에 경쟁사의 인덱스를 기준으로 자사를 벤치마킹한다면, 그 호환성은 모델에 붙는 각주가 아니라 제품 전략이다. 기존 엔드포인트 뒤에 있는 의사결정 모델을 갈아 끼우는 것은 신규 진입자가 시험대에 오를 수 있는 가장 저렴한 방법이며, 이미 이런 것 중 하나를 연동해 둔 팀에게는 가능한 가장 저렴한 실험이다.

실제로 출시된 것, 그리고 그 비용

• 매개변수 — 27B, Qwen3.8-27B를 비전 인코더와 함께 동결하고 그 위에 공동 스키마 헤드와 rank-256 저랭크 어댑터를 훈련하여 구축했습니다.

• 형제 모델 — Clef-Flash, Qwen3.5-9B에서 9B 규모로 구현한 동일한 레시피. 별도의 글, 별도의 트레이드오프.

• 컨텍스트 — Workers AI 모델 페이지와 블로그 게시물에 따르면 65,536 토큰입니다. 함께 제공되는 인코딩 헬퍼의 기본값은 max_length=16,384인데, 이는 상한이 아니라 기본값이지만, 로더를 제공된 그대로 사용할 때 적용되는 기본값입니다.

• 질문 유형 — noul(참/거짓, 참일 확률 반환), choice(2~26개의 이름 지정된 옵션), score(2~26개의 순서형 레벨). 요청당 질문 1~64개.

• 가격 — Cloudflare의 Workers AI에서 백만 입력 토큰당 $0.24이며, 또는 열두 개의 샤드에 걸쳐 약 55GB에 달하는 Apache-2.0 가중치로 자체 호스팅할 수 있습니다.

• 라이선스 — Apache 2.0, Qwen3.8-27B 기본 체크포인트를 따릅니다.

{{1}}강점이 있는 곳, 그리고 그렇지 않은 곳{{/1}}

Cloudflare의 Decision Index 실행은 이 섹션의 모든 내용에 대한 출처이며, 이를 호스팅하는 리더보드도 Cloudflare의 것이다. 아래 내용 중 독립적으로 재현된 것은 아무것도 없다. 공급업체가 내세우는 최선의 시나리오로 읽고, 그것이 얼마나 불균등한지 주목하라.

사내에서 훈련된 분류기가 마땅히 이겨야 할 승리 군집이다. Clef는 BANKING77 인텐트 macro-F1에서 94.2로 Jev의 79.7을 앞서고, 범위 외(out-of-scope) 처리를 포함한 CLINC150에서 97.4로 89.3을 앞선다 — 30점 격차는 표에서 가장 의사결정에 중요한 셀인데, 분류를 거부하는 것이 라우팅의 어려운 절반이기 때문이다. 또한 CRUXEval에서 86.7, CLadder에서 94.0, 가정용 가전 시뮬레이터에서 83.0을 차지한다.

손실도 못지않게 실재하며 같은 문단에 들어가야 한다. 일반 지식과 어려운 추론에서는 구형 Jev가 완승한다: GPQA Diamond 78.3 대 48.0, MMLU-Pro 82.7 대 65.9, BBH 92.9 대 73.7. 이는 표에서 가장 큰 세 가지 격차이며 모두 같은 방향을 가리킨다. Clef 역시 보안 도메인 PhishNChips 세트에 대한 자체 비교에서 최고 모델이 아니다. 여기서 Clef는 79.6을 기록했고 경쟁 항목이 더 높은 점수를 받는다.

TypeSafe 자체 공개 평가 세트에서 가져와 합의 레이블에 대해 채점한 네 가지 엔드투엔드 워크플로 평가에서, 둘은 동전 던지기라고 해도 될 만큼 박빙이다. Clef는 정확한 작업 기준 인보이스 처리에서 64.7 대 61.8로, 보안 사고 세트에서는 62.9 대 61.7로 앞선다. Jev는 에이전트 트레이스 관측성에서 71.6 대 68.5로 앞선다. 고객 서비스는 76.3 대 76.0의 무승부로, 그 정도 차이는 아무 의미가 없다.

지연 시간은 격차가 주변적이라기보다 구조적인 지점이다. Cloudflare는 Clef의 경우 중앙값 209.3ms, p95 238.6ms를 보고했으며, Jev의 경우 524.1과 536.0이었다. 그 순서는 벤치마크의 특이점이 아니라 비자기회귀 설계에서 비롯되며, 그래서 이 수치가 실제 배포와 맞닥뜨려도 가장 살아남을 가능성이 높다. 절대 밀리초 값은 Cloudflare 자체 하드웨어에서 측정된 것이며 그 자체만으로는 의미가 거의 없다.

이번 발표에서 가장 설득력 있는 데이터 포인트는 벤치마크 행이 아니다. Cloudflare에 따르면, 자사의 위협 인텔리전스 팀이 브라우저 렌더링 서비스와 함께 한 도메인을 Clef에 넘겼고, 같은 워크플로에서 자사에서 가장 빠른 범용 LLM이 4.7초 걸린 데 비해 Clef는 2.2초 만에 범주 판정을 받았으며, 반환된 분류 결과도 더 많았다. 내부 일화일 뿐 연구는 아니다. 하지만 이것은 누군가가 일반 모델에 프롬프트를 넣는 대신 왜 이런 것을 만들었는지를 설명해 주는 바로 그런 이야기다.

API 레퍼런스가 알려주는 두 가지, 그리고 알려주지 않는 한 가지

문서화된 함정들은 작고, 무엇이든 포팅하기 전에 읽을 가치가 있습니다. 신뢰도 필드는 확률이 얼마나 집중되어 있는지를 측정하는 것이지, 답이 정답일 확률을 측정하는 것이 아닙니다 — 잘 보정된 모델은 신뢰도가 낮은 정답을 반환할 수 있고, 신뢰도가 높은 오답을 반환할 수도 있습니다. 그리고 두 옵션이 동점일 때, 답은 모델의 옵션 순서를 따르므로, 선호하는 옵션을 먼저 두십시오. 그 두 문장을 읽지 않고 프롬프트 기반 분류기를 포팅하는 사람은 자신의 로그를 잘못 읽게 될 것입니다.

더 큰 제약은 구조적이기 때문에 어디에도 문서화되어 있지 않다. Clef에는 텍스트 생성 경로가 전혀 없으며, 이는 답변 초안을 작성하거나, 스레드를 요약하거나, 도구를 호출하거나, 대화를 나눌 수 없다는 뜻이다. 또한 당신이 선언하지 않은 범주를 만들어내지도 않는다. 전체 설계는 허용된 답변을 미리 열거할 수 있다고 가정한다. 이는 많은 부류의 문제를 조용히 배제하며, 아무리 뛰어난 벤치마크 성능도 이것을 바꾸지 못한다.

호환성 논거는 얼마나 가치가 있는가

여기서부터 릴리스는 모델 리뷰가 아니라 아키텍처 질문이 됩니다. Clef가 Jev의 요청 형태를 지원한다면, 결정 엔드포인트 뒤의 모델은 구성 값이 되며, 이를 도입하는 합리적인 방법은 대체가 아니라 병행입니다 — 자체 트래픽을 대상으로 둘 다 실행하고, 데이터에서 더 나은 측정 결과를 내는 쪽을 유지하며, 전환이 저렴하게 유지되도록 하세요.

Clef 자체는 당사 라우트 목록에 없습니다. OrcaRouter 카탈로그는 이에 대해 404를 반환하며, 여기 어떤 내용도 당사의 가용성 주장으로 읽혀서는 안 됩니다. 당사가 실제로 제공하는 것은 이를 대체하기 위해 만들어진 기존 모델입니다. TypeSafe의 Jev 1.13은 65,536 토큰 컨텍스트에 걸쳐 백만 입력 토큰당 $0.042에 등록된 라우트이며, 동일한 POST /v1/systemone 본문을 통해 제공되므로, 둘 사이의 A/B 테스트는 재작성이 아니라 모델 문자열 하나로 끝납니다. 둘 모두를 하나의 키 뒤에 두는 것 — 200개 이상의 모델, 프로바이더 정가를 토큰당 마크업 없이 그대로 전달, 프로바이더 간 자동 페일오버 — 이 바로 누군가 그것에 신경 쓰기로 마음먹은 그 한 주가 지난 뒤에도 그 테스트가 계속 돌아가게 해 주는 것이며, 설정 파일 속의 낡은 주석으로 전락하는 일이 없게 합니다. 결정 모델이 내리는 결론에 따라 행동하기 위해 곁에 두는 범용 모델은 두 번째 계약이 아니라 바로 그 동일한 키에서 접근할 수 있습니다.

무엇이 이 읽기를 바꿀까요?

Cloudflare 외부의 누군가가 Decision Index를 다시 실행해야 합니다. 이 스위트는 공개되어 있고 평가는 재현 가능하다고 설명되므로, 제3자 실행은 공급업체의 표와 사실 사이의 차이를 만듭니다 — 그리고 가장 중요한 셀은 서로 반대 방향을 가리키는 셀들입니다. 범위 외 의도 감지에서 97.4가 GPQA Diamond에서 48.0과 나란히 있는 모습은 매끄러운 역량 곡선이 아닙니다. 그것은 훈련 분포에 있는 분류 형태에는 매우 뛰어나지만, 보지 못한 추론에는 훨씬 약한 모델을 묘사합니다. 만약 독립 테스트에서도 이것이 유지된다면, 이는 Clef에 관한 운영상 가장 중요한 사실이며, 하이라이트에는 들어 있지 않습니다.

프로덕션 트래픽 역시 지연 시간 표에 부합해야 합니다. H200 한 대에서 측정한 209ms 중앙값은 동시성 상황에서의 p95에 대해 아무것도 말해주지 않으며, 이 설계의 핵심 셀링 포인트는 바로 핫 패스에 자리한다는 점입니다.

그리고 파인튜닝 플랫폼은 뭔가를 내놓아야 합니다. Cloudflare의 글은 RL 루프를 설명합니다 — AI Gateway로 자체 트래픽에서 데이터셋을 수집하고, Workers AI로 롤아웃을 생성하며, Containers를 스코어링 샌드박스로, Trainer로 가중치를 업데이트한 뒤 다시 Workers AI에 재배포하는 — 모델을 발표하는 같은 글 안에서, 고객 결과물은 붙이지 않은 채로. 기반 모델이 훈련받은 적 없는 작업에서 기반 모델을 능가하는 파인튜닝된 Clef라면, 표의 어떤 행보다 이 범주에 훨씬 강력한 증거가 될 것입니다.

그때까지 공정한 요약은 이렇다: Cloudflare는 실제로, 허용적 라이선스로, 진정으로 빠른 의사결정 모델을 내놓았고, 그것을 처음 나온 모델과 손쉽게 맞바꿀 수 있게 했다. 이는 대부분의 오픈 릴리스가 제공하는 것보다 나은 이야기이며, 지금까지는 여전히 전적으로 벤더 자신의 자기 설명일 뿐이다.