Clef: Cloudflare의 27B 의사결정 모델은 실제로 무엇인가

Clef는 Cloudflare가 공개한 270억 개 파라미터 규모의 멀티모달 의사결정 모델입니다. 문자열, JSON 객체, 이미지, 동영상 클립 같은 상태(state)와 최대 64개의 타입이 지정된 질문으로 구성된 스키마를 주면, 단 한 번의 순전파(forward pass)로 모든 질문의 모든 허용 옵션에 대한 확률을 반환합니다. 파이프라인 어디에도 텍스트 생성이 없고 출력 파싱도 필요 없습니다. 모델은 허용된 옵션마다 로짓 하나를 출력하고, 질문별로 소프트맥스를 적용하면 끝입니다. 가중치는 Apache-2.0이며 Hugging Face의 Cloudflare/clef 저장소에 있고, Cloudflare는 자체 Workers AI 플랫폼에서도 이 모델을 제공합니다.

방향을 잡는 데 중요한 날짜가 두 개 있고, 그중 어느 것도 이 페이지가 존재하는 이유는 아니다. 가중치는 2026년 9월 30일에 공개되었고 Cloudflare의 발표 게시물은 2026년 10월 1일자이므로, 이 글을 쓴 날 Clef는 열이틀 되었다 — 더 이상 뉴스가 아닐 만큼 오래되었고, 이 페이지도 그것을 뉴스로 다루지 않는다. 이 페이지가 존재하는 이유는 "clef"가 사람들이 실제로 입력하는 검색어인데, 지금까지 이 블로그에서 그것에 답한 글이 없었기 때문이다. 출시는 이 모델에 날짜를 부여하는 기준이고, 아래의 참고 자료가 핵심이다.

사이즈 문제, 퍼블리셔가 정리하다

두 가지 파라미터 수치가 나란히 회자되고 있는데, 그중 하나만 이 모델에 해당합니다.

• Clef는 27B입니다. Cloudflare의 자체 모델 페이지에서는 이를 "27B 멀티모달 의사결정 모델"이라고 설명하며, Hugging Face 모델 카드도 첫 줄에서 같은 내용을 언급합니다: "Clef는 상태와 타입이 지정된 질문들의 스키마를 의사결정으로 전환하는 27B 멀티모달 모델입니다."

• 9B는 이 모델의 두 번째 크기가 아니라 다른 모델입니다. 9B 체크포인트는 Clef Flash로, 자체 저장소와 자체 모델 페이지를 가진 별도의 형제 모델입니다. 9B Clef를 검색한 사람은 Clef Flash를 찾고 있던 것입니다. 두 모델은 호환되지 않으며 수치도 서로 바꿔 쓸 수 없습니다.

• 세 번째 멤버도 있습니다. 2026년 10월 9일에 발표된 Clef Omni는 3B의 활성 파라미터를 가진 30B 전문가 혼합(mixture-of-experts) 모델로, 다른 백본을 기반으로 구축되었습니다. 오디오도 읽을 수 있습니다. Clef에 "30B"가 붙어 있는 것을 보셨다면, 그것은 Clef가 아니라 Clef Omni입니다.

그래서 이 페이지에 있는 모델의 크기는 27B입니다. 그게 전부입니다. 그리고 리포지토리는 이를 BF16 safetensors로 제공합니다. 공개된 파일 세트는 스물다섯 개 파일에 걸쳐 대략 55 GB이며, 이는 API로 호출하기보다 직접 호스팅하려는 경우 중요한 숫자입니다.

Clef가 Clef Flash와 어떤 관련이 있는지

Cloudflare는 Clef를 패밀리로 출시했는데, 그 패밀리 구조가 부수적인 요소가 아니라 유용한 부분이다. Clef와 Clef Flash는 같은 레시피를 공유한다. 더 큰 모델에는 Qwen3.8-27B 백본을, 더 작은 모델에는 Qwen3.5-9B 백본을 동결하고, 비전 인코더는 유지한 채 그 위에 작은 조인트 스키마 헤드와 로우랭크 어댑터를 훈련한다. 출력 계약은 동일하고, 용량은 다르며, 지연 시간 프로파일은 매우 다르다.

그 공유 계약이 두 모델을 함께 이해할 가치가 있는 이유입니다. 한쪽을 위해 작성한 스키마는 다른 쪽을 위한 스키마이며, 어느 쪽이 응답할지를 바꾸는 일은 재작성이 아니라 모델 식별자 변경에 불과합니다. 절충점은 속도 대 기능이고, Cloudflare가 직접 올린 10월 9일 게시물은 Clef Flash의 호스팅 가격을 백만 입력 토큰당 $0.038로 내리면서 Clef는 백만 입력 토큰당 $0.24로 남겨 두어 그 절충을 더 날카롭게 만들었습니다. 그 게시물이 또 무엇을 했는지 보십시오. Clef Flash의 호스팅 컨텍스트 창을 이전에 광고되었던 64,000개에서 24,000개 토큰으로 줄였고, Clef 자체는 64,000개에 그대로 머물렀습니다.

아키텍처: 동결된 백본 + 스코어링 헤드

Clef는 분류기 모자를 쓴 언어 모델이 아니다. 이 설계는 모델의 거의 모든 다른 속성을 설명해 주기 때문에 정확히 짚고 넘어갈 가치가 있다.

• 백본 — 비전 인코더를 포함한 Qwen3.8-27B로, 그대로 이어받아 동결되었으며, 일반적인 샤딩된 safetensors 형식으로 저장됩니다.

• 공동 스키마 헤드 — 백본의 최종 은닉 상태를 읽고, 그 상태에서 각 질문으로 증거를 라우팅하며, 한 번에 한 질문씩이 아니라 모든 질문의 모든 선택지를 공동으로 채점하는 소형 트랜스포머 헤드입니다.

• 학습 — 랭크 256 저랭크 어댑터, 레이블 스무딩 크로스 엔트로피와 보정을 위한 브라이어 손실, 그리고 Cloudflare의 "Reinforcement Learning for Calibrated Decisions" 루프.

• 출력 — 질문당 허용된 선택지마다 로짓 하나. 질문별 소프트맥스를 적용하면 확률이 나옵니다. 그 외에는 아무것도 나오지 않습니다.

결합 스코어링은 Clef를 독립적인 분류기들의 집합과 구분 짓는 부분이다. 모든 질문이 한 번의 패스에서 동일한 은닉 상태에 대해 채점되기 때문에, 질문들은 서로에게 정보를 줄 수 있고, 전체 구조는 비자기회귀적이다 — 디코드 루프가 없으며, 지연 시간 수치가 바로 여기서 나온다. Cloudflare는 추론을 프리필 전용 패스라고 설명한다.

맥락, 제한, 그리고 입력되는 내용

맥락과 양태에 관해서는 벤더의 자료가 구체적이며, 자료가 침묵하는 부분에서는 그 침묵을 덮어두기보다 기록해 둘 가치가 있다.

• 컨텍스트 윈도우 — 모델 페이지에 따르면 Cloudflare의 호스팅된 Workers AI 엔드포인트에서 65,536토큰입니다. 이는 Cloudflare의 출시 게시물이 TypeSafe의 Jev에 귀속시키는 32,000토큰 윈도우와 대비시키는 수치입니다.

• 자체 호스팅 컨텍스트 — Cloudflare의 10월 9일 게시물에 따르면, Hugging Face 가중치는 직접 실행할 경우 256,000토큰 윈도우를 지원하도록 훈련되었습니다. 해당 저장소에 포함된 인코더는 기본값으로 max_length=16,384를 사용하며, 이는 상한이 아니라 기본값이지만 로더를 배포된 그대로 사용하면 얻게 되는 값입니다.

• 최대 출력 — 공개되지 않음. 공개할 토큰 예산이 없습니다: 모델은 질문당 고정된 확률 벡터를 반환하므로, 자연스러운 상한은 토큰 길이가 아니라 스키마(질문 1~64개, 각각 2~26개의 선택지)입니다.

• 입력 모달리티 — 텍스트, JSON, 이미지 및 동영상. Workers AI 페이지는 비전을 지원됨으로 표시하며 PNG, JPEG 또는 WebP 이미지를 허용하고 요청당 최대 4개까지 받습니다. 별도로 Clef Omni는 오디오를 추가하지만, Clef 자체는 그렇지 않습니다.

• 출력 양식 — 확률값입니다. Clef는 답장을 작성하거나, 스레드를 요약하거나, 문장을 생성할 수 없으며, 사용자가 선언하지 않은 범주를 임의로 만들어내지도 않습니다.

• 라이선스 — Apache-2.0, Qwen3.8-27B 기본 체크포인트를 따릅니다. Cloudflare의 모델 페이지는 페이지 텍스트에 라이선스를 명시하는 대신 라이선스 파일로 링크하고 있으며, 라이선스 파일 자체는 Apache-2.0입니다.

하나의 구현 세부 사항은 함정으로 문서화되어 있으며 반복할 가치가 있습니다: 신뢰도 필드는 확률이 얼마나 집중되어 있는지를 알려줄 뿐, 답이 맞을 확률을 알려주지는 않습니다. 잘 보정된 모델은 낮은 신뢰도의 정답과 높은 신뢰도의 오답을 반환할 수 있습니다.

Cloudflare가 주장하는 것과 실제로 측정된 것

제목의 두 부분 사이의 간격이 넓기 때문에, 이 섹션은 주의 깊게 읽어야 합니다.

Clef에 붙은 모든 성능 수치는 Cloudflare에서 나온다. 모델 카드는 자신들이 "우리의 내부 Decision Index 0.2.1 스위트 실행"이라고 설명하는 것으로부터 40개가 넘는 행으로 이루어진 표를 공개하는데, 그 리더보드는 Cloudflare가 호스팅한다. 그 아래에 있는 워크플로 평가는 TypeSafe의 공개 평가 세트에서 가져온 것이지만, 실행은 여전히 Cloudflare의 것이다. 오늘 기준으로 나는 두 표 중 어느 것에 대해서도 독립적인 제3자 재현을 찾을 수 없다 — 외부 연구소도, 중립적인 리더보드도, 공개된 재현도 없다. 이 수치들을 측정값이 아니라 공급자의 최선의 경우로 취급하라.

그 숫자들 안에 담긴 패턴은 어떤 단일 셀보다도 더 많은 정보를 준다. Clef의 가장 강력한 결과는 분류 형태의 작업에서 나온다: Cloudflare의 실행에서 Clef는 BANKING77 인텐트에 대해 94.2 매크로-F1을 보고했는데, Jev는 79.7이었다. 그리고 범위 외 처리까지 포함한 CLINC150에서 97.4 매크로-F1을 기록했으며 Jev는 89.3이었다. 범위 외 수치가 운영상 흥미로운 지점인데, 분류를 하지 않는 것이 라우팅의 어려운 절반이기 때문이다. 또한 BFCL에서 98.5 케이스 정확도를, CRUXEval에서 86.7을 보고했다.

손실은 일관되게 같은 방향을 가리킨다. 같은 표에서 Clef는 GPQA Diamond를 48.0으로 보고하는데, Jev는 78.3이다. MMLU-Pro는 65.9 대 82.7, BBH는 73.7 대 92.9다. 이는 표에서 세 가지 가장 큰 격차이며, 모두 같은 약점을 보여준다: 모델이 훈련된 형태를 벗어난 추론. 네 가지 엔드투엔드 워크플로 평가에서는 두 모델이 충분히 비슷해서 그 순위는 유의미한 결과가 아니다.

지연 시간은 이점이 한계적이기보다 구조적인 유일한 지점이며, 따라서 프로덕션과 맞닥뜨려도 살아남을 가능성이 가장 큰 지점이다. Cloudflare는 Clef에 대해 중앙값 209.3ms와 p95 238.6ms를 보고하는데, 이는 Jev의 524.1ms와 536.0ms와 대비된다. 그 순서는 벤치마크의 변칙 때문이 아니라 비자기회귀 설계에서 비롯된다. 다만 절대적인 밀리초 수치는 Cloudflare 자체 하드웨어에서 측정된 것이어서 그 자체로는 의미가 거의 없다.

이 블로그에서 Clef 벤치마크 표를 이미 본 사람이라면 알아둘 만하다: 서빙 수치는 10월 9일에 바뀌었다. Cloudflare는 서빙을 위해 Clef를 SGLang으로 옮겼고 그 작업을 업스트림에 기여했으며, 약 800개 입력 토큰에서 중간값 1.7배, 약 3,400개 토큰에서 2.0배의 속도 향상을 보고했다. 이는 새로운 가중치가 아니라 서빙 계층의 변경이며, 모델 자체는 바뀌지 않았다. 10월 9일 이전의 지연 시간 수치를 인용하고 있다면, 그것은 오래된 것이다.

Clef를 호출하고 Cloudflare와의 관계를 제대로 정립하기

그것을 실행하는 방법은 두 가지가 있으며, 어느 쪽도 신비롭지 않습니다.

첫 번째는 Cloudflare 자체 엔드포인트입니다. Clef는 Cloudflare 자체 추론 플랫폼인 Workers AI에서 제공되며, 100만 입력 토큰당 $0.24이고 출력 토큰에는 요금이 부과되지 않습니다 — 이는 출력 토큰이 없기 때문입니다. 미디어 입력은 토큰으로 변환되어 동일한 입력 요율로 청구됩니다. 이는 퍼블리셔가 자체 모델을 호스팅하는 것이며, 그것이 이 관계의 전부입니다: 이 모델의 이름을 Cloudflare와 함께 묶는 검색들은 이를 우연히 추가한 제3자 호스트를 가리키는 것이 아닙니다. Cloudflare가 그것을 만들었습니다.

두 번째는 여러분의 자체 하드웨어입니다. 가중치는 Apache-2.0 라이선스로 Hugging Face에 있으므로 상업적 논의 없이 자체 호스팅이 허용됩니다. Cloudflare 자체 테스트에서는 단일 H200에서 torch 2.11과 transformers 5.10.2를 사용했으며, 이미지 및 비디오 입력에는 pillow가 필요했습니다. Clef가 SGLang에서도 실행된다는 내용을 읽으셨다면, 이는 10월 9일 서빙 변경 기준으로 정확합니다. 업스트림 작업은 SGLang 0.5.22에서 릴리스될 예정입니다.

API 형태는 의도적으로 새롭지 않다. Clef의 요청 및 응답 본문은 TypeSafe의 SystemOne 포맷과 호환되므로, 이미 그런 형태의 의사결정 모델에 연결해 둔 파이프라인이라면 URL과 모델 문자열만 바꿔서 Clef를 가리키게 할 수 있다. 이는 실질적인 전환 비용 논거이며 양방향으로 작용하는데, 이것이 이를 읽는 정직한 방식이다. 인터페이스가 동일하기 때문에 Clef 도입은 저렴하고, 포기하는 것도 똑같이 저렴하다. 이미 프로덕션에 의사결정 엔드포인트를 두고 있는 팀에게 합리적인 자세는 마이그레이션하는 것이 아니라 자사 트래픽에 두 모델을 모두 돌려보는 것이다. OrcaRouter를 통해 라우팅한다면 TypeSafe의 Jev 1.13이 우리 카탈로그에 등록된 모델이므로, 기존 모델과 직접 호스팅하는 모델 간의 A/B는 두 개의 계약이 아니라 하나의 키 뒤에 놓인다 — 200개 이상의 모델, 제공자 정가가 토큰당 마크업 없이 그대로 전달되며, 장애 조치도 대신 처리된다.

이 페이지가 여러분에게 알려주지 않는 한 가지는 Clef가 저희를 통해 이용 가능한지 여부입니다. Cloudflare는 이를 Workers AI와 Hugging Face에 공개하며, 저는 저희 자체 모델 목록을 통한 경로를 확인하지 않았으므로 주장할 내용은 없습니다.

아직 해결되지 않은 것은 무엇인가요?

Clef에게 일어날 수 있는 가장 유용한 단 한 가지 일은 Decision Index의 외부 재현이다. 이 스위트는 공개되어 있고 Cloudflare는 평가가 재현 가능하다고 설명하므로, 제3자 실행은 공급업체의 표와 사실을 가르는 차이다. 그것이 존재하기 전까지 Clef의 공개된 프로필에 대한 정직한 요약은, Clef가 빠른 비자기회귀적 설계를 갖춘 매우 강력한 제약 분류기이며, 벤치마크에서 비교 대상이었던 모델보다 범용 추론기로서는 상당히 약하다는 것이다.

그 해석을 바꿀 세 가지 구체적인 요소가 있습니다. BANKING77과 CLINC150의 범위 밖(out-of-scope) 수치를 중립적으로 재현한 결과—기존 모델보다 30포인트 앞선다는 격차는 전체를 설명하는 결과이거나, 아니면 아티팩트일 수 있기 때문입니다. 실제 동시성 환경에서 측정한 p95 수치—단일 H200에서 측정한 209ms 중앙값은 부하가 걸린 핫 패스에 대해 아무것도 말해주지 않기 때문입니다. 그리고 베이스가 학습한 적 없는 작업에서 베이스를 능가하는 파인튜닝된 Clef—이는 Cloudflare의 RL 파인튜닝 플랫폼이 만들어내도록 설계되었지만, 아직 고객 결과로 입증되지는 못했습니다.

그때까지 독자가 의지할 수 있는 것은 이 물건의 윤곽이다: 27B 파라미터, 비전 인코더를 갖춘 동결된 Qwen3.8-27B 백본, 조인트 스키마 헤드, 호스팅되는 컨텍스트 65,536토큰, 텍스트와 JSON, 이미지와 비디오 입력, 확률 출력, Apache-2.0. 그 정도면 이 아키텍처가 당신의 문제에 맞는지 판단하기에 충분하다. 아직 답할 수 없는 질문은 벤더 자체의 스코어보드가 이 모델에 대해 맞는지 여부이며, Cloudflare 밖의 누구도 이를 확인하지 않았다.