Clef-Flash는 토큰을 전혀 생성하지 않는 9B 모델이다 — 그리고 Cloudflare의 블로그는 가중치 공개 거의 하루 뒤에 올라왔다

Cloudflare/clef-flash는 상태와 타입이 지정된 질문들의 스키마를 입력받아 허용된 모든 답변에 대한 확률을 반환하는 90억 개 매개변수의 멀티모달 모델입니다. 텍스트를 생성하지 않습니다. "텍스트를 형편없이 생성한다"는 것이 아니라 — 텍스트 출력 경로 자체가 전혀 없습니다. 이 모델의 저장소는 2026년 9월 30일 21:15 UTC에 Apache-2.0 라이선스로 Hugging Face에 나타났습니다. 더 큰 27B Cloudflare/clef와 함께 이 모델을 소개하는 Cloudflare의 발표 게시물은 다음 날 15:34 UTC에 게시되었습니다. 약 18시간 동안 오픈 가중치와 호스팅된 Workers AI 엔드포인트는 벤더가 이들에 대해 한마디도 하기 전에 공개적으로 존재했으며, 이러한 순서가 이번 릴리스에서 가장 흥미로운 사실입니다 — 파이프라인에 이것을 연결할지 결정하는 사람이라면 누구에게나, 어떤 단일 벤치마크 행보다도 더 흥미롭습니다.

이틀 후, 두 번째이자 더 작은 문제가 나타났다. 제3자 런타임의 clef-flash 라이브러리 페이지, 즉 이 기사의 레이더가 그 모델을 처음 발견한 곳은 모델 표에 "256K 컨텍스트 윈도우"라고 적어 두면서, 몇 줄 위에는 Cloudflare 자체의 리드미 텍스트 — "64K 컨텍스트 윈도우: Jev의 32K 윈도우가 보유한 상태의 두 배" — 를 렌더링한다. 두 숫자가 모두 맞을 수는 없으며, 공급업체의 문서는 더 작은 쪽으로 결론을 내린다. 그런 종류의 어긋남은 처음부터 짚고 갈 가치가 있다. 이 글의 나머지 모든 내용이 같은 질문에서 파생되기 때문이다: 어떤 숫자가 공급업체의 것이고, 어떤 것이 미러의 것이며, 어떤 것이 공급업체가 아닌 누군가에 의해 검증된 것인가.

실제로 출시된 것은 무엇이며, 어떤 순서였나요?

기록, 순서대로:

• 2026년 9월 30일 21:15:35 UTC — Cloudflare/clef, 27B 모델이 Hugging Face에서 생성되었습니다.

• 2026년 9월 30일 21:15:36 UTC — Cloudflare/clef-flash가 1초 후에 생성됩니다. 둘 다 Qwen 베이스 모델을 파인튜닝한 것입니다: Clef는 Qwen3.8-27B, Clef-Flash는 Qwen3.5-9B를 기반으로 합니다.

• 2026년 10월 1일 15:23 UTC — clef-flash의 저장소가 마지막으로 수정된 시점으로, 이는 우리가 인용하고 있는 모델 카드 텍스트가 작성된 무렵과 비슷합니다.

• 2026년 10월 1일 15:34 UTC — “Clef 소개: 우리의 오픈소스 의사결정 모델과 새로운 RL 파인튜닝 플랫폼”이 Cloudflare 블로그에 게시되며, 두 모델을 Workers AI에서 호스팅하고 이를 기반으로 한 파인튜닝 서비스를 출시합니다.

• 2026년 10월 2~3일 — 서드파티 런타임이 가중치를 받아들이기 시작하고, 서드파티 런타임의 라이브러리 페이지와 양자화된 커뮤니티 빌드가 등장한다.

그래서 이것은 유출도, 조용한 출시도, 독자가 소문으로 취급해야 하는 예고 없는 체크포인트도 아니다. 그것은 블로그 글, Cloudflare 자체 엣지 GPU에서 호스팅되는 API, 가중치에 적용된 Apache-2.0 라이선스, 그리고 함께 제공되는 상용 파인튜닝 플랫폼을 갖춘 GA 릴리스다. 유일하게 정말 이상한 점은 저장소가 발표보다 18시간 먼저 나왔다는 것뿐이다. 모델이 공개되었는데도 벤더 자체의 마케팅 페이지는 아직 존재하지 않을 만큼 길었고, Cloudflare 외부의 누구도 그것을 의미 있게 실행해 보지 못했을 만큼 짧았다.

의사 결정 모델은 소형 언어 모델입니다.

Cloudflare의 글에서 제시하는 프레이밍은 의사결정 모델이 별개의 범주라는 것이며, 아키텍처는 그 주장을 장식하는 것이 아니라 뒷받침한다. Clef-Fai는 비전 인코더를 포함한 Qwen3.5-9B 백본을 동결한 채로 유지한다. 그 위에는 작은 트랜스포머 헤드가 있는데 — 릴리스에서 가중치 243.5MB로, 약 18.8GB에 달하는 네 개의 샤딩된 백본 파일과 대비된다 — 이 헤드는 상태로부터의 증거를 각 질문으로 라우팅하고 모든 질문의 모든 선택지를 단일 패스로 채점한다. Cloudflare는 이를 "비자기회귀(non-autoregressive)"라고 부른다: 토큰별 생성도, 중간 추론 텍스트도, 출력 파싱도 없다. 허용된 선택지마다 로짓을 얻고, 질문별로 소프트맥스를 적용하면 분포가 나온다.

요청의 형태는 그로부터 나온다. 여러분은 state — 문자열, 또는 JSON 객체나 배열 — 그리고 선택적인 이미지 또는 비디오 프레임 목록, 그리고 1개에서 64개까지의 이름 붙은 질문을 제공한다. 각 질문은 type을 선언한다: noul은 참/거짓 판정으로 참일 확률을 반환하고, choice는 이름 붙은 옵션 집합으로 선택된 옵션과 옵션별 확률 및 신뢰도를 반환하며, score은 순서형 척도로 확률 가중치가 부여된 수준을 반환한다. 기준은 noul에서는 선택 사항이고 나머지에서는 사실상 필수이며, 문서는 한 가지 함정에 대해 이례적으로 단호하다: 신뢰도는 "확률이 얼마나 집중되어 있는지를 보여준다. 그것은 답이 맞을 확률이 아니다." 자신 있게 답하는 모델이 반드시 정확하게 답하는 것은 아니며, 캘리브레이션 측정만이 그 둘을 구분한다.

그 구분이 바로 관심을 가질 만한 전부의 이유다. 범용 모델에게 지원 티켓을 분류해 달라고 요청한 뒤 그 답변을 파싱하려고 해 본 적이 있다면, 이 설계가 없애 주는 비용을 이미 치른 셈이다. Clef-Flash는 "This looks like a billing issue, probably?"라는 문장을 만들 수 없다. 문장 자체를 생성할 수 없기 때문이다. 그것은 {"choice": "billing", "probabilities": {"billing": 0.981, ...}, "confidence": 0.924} 를 반환하며 — 이 예시는 Cloudflare 자체 문서에서 바로 가져온 것이다 — 여러분의 코드는 여기에 임계값을 적용한다.

숫자들, 그리고 그것을 운영한 사람들

아래의 모든 수치는 Cloudflare의 모델 카드나 블로그 게시물에서 나온 것이며, Cloudflare가 그 모든 평가를 직접 수행했습니다. 이 스위트는 Jev Decision Index입니다. 이는 TypeSafe가 공개한 리더보드로, TypeSafe는 Clef-Flash가 벤치마크 대상으로 삼는 모델인 Jev의 공급업체입니다. 따라서 이 비교는 공급업체 자사 제품을 경쟁사의 지수에서 측정한 것이고, 그 측정 역시 공급업체가 실행한 것입니다. 아직 Clef-Flash에 대한 독립적인 평가는 없으며, 이 글은 그렇지 않은 척하지 않습니다.

의사결정 특화 벤치마크에서 Clef-Flash는 마케팅과 분리해 볼 가치가 있을 만큼 진짜로 강하다: BFCL case-exact 98.8, API-Bank 93.1, 가전 시뮬레이션 97.7, ContractNLI macro-F1 84.3, RouterBench 79.9. 이 모델은 더 큰 27B Clef를 BFCL(98.8 대 98.5), API-Bank(93.1 대 91.9), 가전 제품군(97.7 대 83.0)에서 앞선다. 마지막 항목은 14점 차이로, 이는 표에서 단연 가장 놀라운 셀이며 Cloudflare 밖에서는 아무도 확인하지 않은 항목이다.

손실도 똑같이 실재하며 같은 문단에 들어가야 한다. 범위 밖(out-of-scope) 처리를 포함한 CLINC150에서 clef-flash는 macro-F1 66.8점을 기록한 반면 27B는 97.4점, Jev는 89.3점이다 — "기타" 버킷이 있는 의도 탐지에서 30점 낙차이며, 이는 라우팅 계층이 가장 자주 보는 요청의 형태와 정확히 일치한다. ANLI에서는 59.1점 대 Jev의 74.8점이고, When2Call에서는 65.6점 대 Jev의 81.0점이며, GPQA Diamond에서는 51.0점 대 Jev의 78.3점이다. 그리고 코드 라벨링 벤치마크인 POP909-CL에서는 1.6점을 기록한다 — 이 숫자는 데이터 형식 불일치이거나 실제 실패인데, 카드에는 어느 쪽인지 나와 있지 않다.

지연 시간 표는 이 모델이 이름값을 하는 부분이다. 중앙값 요청 지연 시간은 38.8ms, p95는 122.4ms이며, 이는 27B Clef의 209.3 / 238.6, Jev의 524.1 / 536.0과 비교된다. Cloudflare가 자체 인프라에서 측정한 것이므로 절대 밀리초 값은 다른 환경에서 보게 될 수치의 상한으로 생각해야 하지만, 순서 — flash 변형은 자체의 더 큰 형제 모델보다 중앙값 기준 약 5.5배 빠르고 Jev보다 13배 빠르다 — 는 설계가 광고한 대로 작동하고 있음을 보여준다.

리스팅들이 서로 엇갈리는 단 하나의 수치

컨텍스트 윈도는 사람들을 골탕 먹일 숫자입니다. 왜냐하면 바로 그 값이 잘못 복사되었기 때문입니다. Cloudflare의 Workers AI 문서에서 @cf/cloudflare/clef-flash는 컨텍스트 윈도를 65,536 토큰으로 명시합니다. 블로그 게시물은 "우리 모델은 64k 컨텍스트 윈도를 가지고 있습니다 (Jev의 32k와 비교하면)"라고 말합니다. 모델 카드 자체의 인코딩 헬퍼는 기본값이 max_length=16,384 토큰입니다. 한편 한 서드파티 런타임의 라이브러리 목록은 자사 표에서 256K를 광고합니다.

세 공급업체 소스는 대략 64K로 일치하고, 한 서드파티 목록은 그 네 배라고 말합니다. 라이브러리 페이지를 근거로 256K 예산에 맞춰 프롬프트 크기를 산정하고 있다면, 요청 시점에 알게 될 것입니다. 정직한 해석은 문서화된 상한으로서 65,536 토큰이며, Cloudflare 자체 릴리스 노트가 카드의 16,384토큰 기본값을 그 상한과 결코 일치시키지 않는다는 단서가 붙습니다 — 기본값이지 한도는 아니지만, 번들 로더를 그대로 사용하면 보내는 상태의 양을 조용히 좌우하게 될 것입니다.

그것을 어디에서 호출할 수 있는지, 어디에서는 호출할 수 없는지

Clef-Flash는 아직 OrcaRouter의 라우트 중 하나가 아닙니다. 저희 카탈로그에서는 이에 대해 404를 반환하며, 이 글의 어떤 내용도 저희의 제공 가능성 주장으로 해석되어서는 안 됩니다 — 오늘 바로 사용하고 싶다면 Cloudflare가 Workers AI에서 백만 입력 토큰당 $0.09에 호스팅하고 있고, Apache-2.0 가중치는 직접 로컬에서 실행할 수 있습니다.

이 기사가 실제로 다루고 있는 그 결정에 이것이 의미하는 바는, 한 벤더의 플랫폼을 통해서만 접근할 수 있는 스코어러는 그 정확도와 함께 지연 시간과 가용성까지 물려받게 된다는 것입니다. 라우팅 경로가 있는 호스팅 대안은 TypeSafe의 Jev 1.13으로, OrcaRouter에서 백만 입력 토큰당 $0.042에 65,536 토큰 컨텍스트로 제공되며, Cloudflare가 벤치마크 상대 모델로 선택한 모델이기도 합니다. 두 모델이 API 호환되기 때문에 의도적으로 그렇게 한 것입니다. Clef-Flash는 동일한 /v1/systemone 요청 형태를 사용하므로, 두 모델은 얇은 어댑터 뒤에서 서로 교체할 수 있습니다. 하나의 키로 둘 다에 접근할 수 있고 제공자 목록 가격이 마크업 없이 그대로 전달된다는 점이, 아키텍처를 먼저 출시된 모델 쪽으로 확정해 버리기보다 그 비교를 계속 살려 두어야 하는 이유입니다.

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

세 가지, 그것들이 판도를 얼마나 바꿀 수 있는지 순서대로.

Cloudflare 외부의 누군가가 CLINC150+OOS와 가전제품 셀을 재현해야 합니다. 왜냐하면 이 둘은 서로 반대 방향을 가리키는데, 카드는 어느 쪽에 대해서도 메커니즘을 제시하지 않기 때문입니다. 범위 밖 의도 탐지에서의 66.8이 가전제품 제어에서의 97.7 옆에 놓이는 것은 매끄러운 성능 곡선이 아닙니다. 이는 훈련 분포에 있는 분류 형태에는 매우 능하지만, 정답이 "이들 중 어느 것도 아님"일 때 분류를 거부하는 데는 훨씬 약한 모델을 시사합니다. 독립적 테스트에서도 그것이 유지된다면, 그것은 clef-flash에 관한 가장 중요한 운영상의 사실이며, 하이라이트 섹션에는 없습니다.

64K 대 256K 표기 불일치는 바로잡아야 할 출처가 필요하다. 현재 그것은 미러에서 바깥으로, 사람들이 실제로 읽는 곳들로 퍼져 나가고 있기 때문이다. 벤더 문서는 보통 런타임의 카드에 반대하는 논쟁에서 이기기 위해 인용해야 하는 대상이 아니다. 그리고 이번은 정말 그런 작은 사례다.

그리고 그 범주는 실제 워크로드와의 접촉을 견뎌내야 합니다. Cloudflare의 자체 설명에 따르면, 의사 결정 모델은 에이전트의 핵심 경로에 놓입니다. 그들의 Threat Intelligence 예시에서는 웹사이트를 가져오고, 렌더링하고, 분류하는 데 2초가 걸리는 반면, 같은 작업에서 그들의 가장 빠른 범용 LLM은 4.7초가 걸립니다. 이는 실제적이고 구체적인 워크플로에 관한 실제적이고 구체적인 주장이며, 이는 표가 아니라 그것을 실행해 보는 사람들에 의해 판가름 나는 종류의 주장입니다.