2026년 9월, TypeSafe AI의 Jev가 “decision model”이라는 용어를 대중화했습니다. 2주 후인 10월 1일, Cloudflare는 Workers AI에 호스팅되고 Hugging Face에 Apache-2.0 오픈 웨이트로도 공개된 두 개의 비교 가능한 모델——Clef와 Clef-flash——를 발표했습니다.
Clef의 포지셔닝은 노골적입니다: Jev에 정면으로 도전하며, “오픈 웨이트 + 멀티모달 + 자체 호스팅 가능”을 차별점으로 내세웁니다. 27B이고, 비전 인코더를 탑재했으며, 64k 컨텍스트 윈도우를 지원하고, Jev / SystemOne API와 완전히 호환됩니다. 기술 검토를 하는 사람에게 이제 질문은 의사결정 모델이 유용한가가 아니라, 호스팅 API와 오픈 웨이트 자체 호스팅 중 무엇이 우리 팀에 더 맞는가입니다.
아래의 모든 benchmark는 Cloudflare가 공개한 내부 실행 결과에서 가져온 것입니다. 명백히 맞지 않는 후보를 걸러내는 데는 충분하지만, 자체 데이터로 다시 테스트하는 일을 대신하지는 못합니다.
요약
- 운영 부담 제로, 최대 정확도: Jev와 Clef의 호스팅 버전 모두 쓸 만합니다. Clef는 대부분의 분류 benchmark에서 앞서고, 멀티모달 입력은 Clef만의 특징입니다. 가장 빠르게 시작하려면 defapi의 Clef 호스팅 API를 유료로 체험할 수 있습니다.
- 이미지 또는 비디오 입력: Jev는 현재 텍스트만 처리합니다. Clef가 유일한 선택입니다.
- 자체 호스팅 또는 데이터 상주: Clef의 Apache-2.0 웨이트는 엄격한 요건에서 확실한 우위를 줍니다. 대가는 27B GPU 풋프린트와 운영입니다.
- 극히 낮은 지연: Clef-flash(9B, 중앙값 38.8ms)는 Jev(524ms)보다 한 자릿수 빠르며, 정확도를 다소 희생합니다.
- 일단 써보고 싶다면: 둘 다 호환 API에서 시작하지만, 공개 benchmark가 구매 검수를 대체하게 해서는 안 됩니다.
Jev vs Laya 비교를 이미 읽었다면, 이 글은 같은 프레임워크를 세 번째 후보에 적용한 것입니다.
Clef란 무엇인가
Clef는 Cloudflare가 훈련한 의사결정 모델 제품군입니다. 주요 특징은 다음과 같습니다:
| 항목 | Clef | Clef-flash |
|---|---|---|
| 백본 | Qwen3.8-27B(비전 인코더 포함) | Qwen3.5-9B |
| 입력 | 텍스트, JSON, 이미지, 비디오 | 텍스트, JSON, 이미지, 비디오 |
| 컨텍스트 | 64k | 64k |
| 출력 | 질문별 허용 선택지마다 logit 하나, 질문별 softmax | 동일 |
| 라이선스 | Apache-2.0 | Apache-2.0 |
| 호스팅 | Cloudflare Workers AI | Cloudflare Workers AI |
동작 방식은 Jev와 같은 범주지만 구현은 다릅니다: 자유 형식 텍스트 생성도, 출력 파싱도 없습니다. state(텍스트, JSON, 이미지, 비디오)와 타입이 지정된 스키마 질문 집합을 주면, 단일 forward pass로 모든 질문의 모든 허용 선택지에 대한 확률을 반환합니다.
이름과 관련해 Cloudflare는 음악 비유를 씁니다: 오선지 맨 앞의 음자리표(clef)가 선과 칸에 음이름을 부여하듯, 의사결정 모델은 이후 행동을 결정하는 컨텍스트의 영역을 정의합니다. “CF” 역시 Cloudflare를 염두에 둔 표현이기도 합니다.
아키텍처: 토큰 단위 생성이 아닌 prefill + 병렬 스코어링
Clef를 이해하는 핵심은 자기회귀적(autoregressive)이지 않다는 점입니다:
- Qwen 백본이 전체 입력에 대해 prefill 전용 forward pass를 실행합니다.
- 작은 joint schema head가 백본의 최종 hidden state를 읽고, state의 근거를 각 질문으로 라우팅하며, 모든 질문의 모든 선택지를 공동으로 스코어링합니다.
- 각 선택지에 logit이 부여되고, 질문별 softmax가 이를 확률로 변환합니다.
중간에 생성되는 텍스트가 없습니다. LLM이 추론을 생성한 뒤 JSON으로 포맷하는 것과 달리, Clef는 내부 백본 표현에서 스키마 선택을 직접 도출합니다.
Cloudflare의 2단계 attention 라우팅은 기억해 둘 만합니다: 먼저 모든 유효 선택지가 자신과 관련된 컨텍스트를 추출하고(선택지별 근거 라우팅), 그다음 필드들이 서로 그리고 원래 payload로 cross-attend한 뒤(공동 cross-field attention) 스키마 바인딩 스코어링이 이뤄집니다. 어휘 사전확률(lexical prior) 이 선택지 전반에 걸쳐 의미 의도를 보존합니다.
훈련에서는 Cloudflare가 Qwen 백본을 동결하고, rank-256 LoRA 어댑터와 함께 라우팅 헤드를 공동 최적화했습니다:
- label-smoothed cross-entropy(유효한 스키마 출력 보장)
- Brier loss(확률 보정 개선)
- RLCD(Reinforcement Learning for Calibrated Decisions)를 보조 목표로 사용해, 인접한 서수 선택지에 부분 점수를 부여하고, 완전히 정확한 레코드에 보상을 주며, 분포 이동을 막기 위해 기준 패널티를 적용합니다
여기 흥미로운 세부 사항이 있습니다: Cloudflare는 Jev가 출시된 같은 주에 DiffusionGemma 기반의 의사결정 모델 실험을 공개한 바 있습니다. Clef는 다른 백본을 쓴 그 계보의 연장선입니다. Jev 아키텍처를 베낀 것이 아니라, LLM logprob을 결정론적 확률로 노출하는 독립적인 경로를 통해 도달한 것입니다.
Jev / SystemOne과의 호환성
Clef는 완전히 호환됩니다. 동일한 POST /v1/systemone 요청 본문이 동일한 model, answers, usage 구조를 반환합니다. choice 답변에는 choice / confidence / probabilities가 있고, score 답변에는 기대하는 score / confidence / legend / probabilities가 있으며, noul 답변은 명제가 참일 확률을 반환합니다.
세 가지 프리미티브는 Jev와 일치합니다:
| 프리미티브 | 의미 | 반환 |
|---|---|---|
noul | 이진 명제, 참/거짓 | 0.0 ~ 1.0 사이의 확률 |
choice | 이름이 붙은 선택지 중 하나 선택 | 선택 + 신뢰도 + 선택지별 확률 |
score | 순서가 있는 선택지 평가 | 기대 점수 + 신뢰도 + 등급별 확률 |
이미 Jev를 통합한 시스템이라면 마이그레이션 비용이 매우 낮습니다——같은 클라이언트를 두 제공자 뒤에 두고 shadow 트래픽을 보낼 수도 있습니다. 다만 경고 하나: wire protocol 호환성은 의미적 동등성이 아닙니다. 선택지 제한, 신뢰도 공식, 보정 곡선은 모델마다 다를 수 있으므로 기존 threshold는 경계 샘플에서 다시 검증해야 합니다.
공식 예시(Cloudflare Workers AI 엔드포인트):
curl https://api.cloudflare.com/client/v4/accounts/$CLOUDFLARE_ACCOUNT_ID/ai/run/@cf/cloudflare/clef \
-X POST \
-H "Authorization: Bearer $CLOUDFLARE_AUTH_TOKEN" \
-d '{
"model": "clef",
"state": "Checkout has been failing for every customer for the last hour.",
"questions": {
"urgent": { "type": "noul", "instructions": "Is this support request urgent?" },
"team": {
"type": "choice",
"instructions": "Which team should handle this request?",
"criteria": {
"billing": "Payments, invoices, and refunds",
"technical": "Outages, errors, and configuration",
"sales": "Plans and upgrades"
}
},
"severity": {
"type": "score",
"instructions": "How severe is the customer impact?",
"criteria": ["No impact", "Minor", "Major", "Critical"]
}
}
}'멀티모달: 오늘날 Clef만 가진 역량
Jev와 비교한 Clef의 가장 명확한 제품 차이입니다. Jev는 텍스트만 분류하는 반면, Clef는 비전 인코더를 탑재해 이미지와 비디오 프레임을 읽을 수 있습니다.
사용법은 record에 images(PIL 이미지) 또는 videos(프레임 배열)를 추가하고 processor를 encode_record에 전달하는 것입니다. 선택적 processor 인자는 media_kwargs에 넣습니다. 텍스트 전용 레코드와 멀티모달 레코드는 같은 배치에 섞을 수 있습니다:
from PIL import Image
record = {
"state": {"task": "Review the attached receipt."},
"images": [Image.open("receipt.jpg")],
"questions": {
"legible": {"type": "noul", "instructions": "Is the receipt total legible?"},
},
}Cloudflare가 내세운 사례는 위협 인텔리전스입니다: 도메인과 Browser Run 스크린샷을 Clef에 넘기면 “95% 패션, 85% 이커머스, <1% 피싱” 같은 다중 레이블 확률을 출력하게 합니다. 이들은 전체 fetch, render, classify 워크플로가 Clef로는 2.2초, 가장 빠른 범용 LLM인 gpt-oss-120b로는 4.7초 걸렸고 후자는 분류를 두 개만 반환했다고 보고합니다. 유용한 지연-커버리지 비교지만, 이는 전체 워크플로를 측정한 것이지 모델 추론만 측정한 게 아니라는 점에 유의하세요.
Benchmark: 어디서 누가 앞서는가
벤더 benchmark는 검증이 필요합니다. 공식 Decision Index 0.2.1 내부 실행의 일부입니다(백분율, 높을수록 좋음):
| Benchmark | Clef | Clef-flash | Jev | 우위 |
|---|---|---|---|---|
| BFCL (case exact) | 98.5 | 98.8 | 95.8 | Clef 계열 |
| ToolRet (nDCG@10) | 69.2 | 66.4 | 65.3 | Clef |
| API-Bank (accuracy) | 91.9 | 93.1 | 88.2 | Clef 계열 |
| BANKING77 (macro-F1) | 94.2 | 90.9 | 79.7 | Clef |
| CLINC150+OOS (macro-F1) | 97.4 | 66.8 | 89.3 | Clef |
| Home appliance (case exact) | 83.0 | 97.7 | 52.3 | Clef 계열 |
| ContractNLI (macro-F1) | 81.4 | 84.3 | 71.7 | Clef 계열 |
| MMLU (accuracy) | 90.3 | 91.8 | 91.7 | 동률 |
| GPQA Diamond (accuracy) | 48.0 | 51.0 | 78.3 | Jev |
| MMLU-Pro (accuracy) | 65.9 | 65.3 | 82.7 | Jev |
| BBH (accuracy) | 73.7 | 68.9 | 92.9 | Jev |
| When2Call MCQ (accuracy) | 72.4 | 65.6 | 81.0 | Jev |
| BRIGHT (nDCG@10) | 45.9 | 39.3 | 47.5 | Jev |
결론이 “Clef의 압승”은 아닙니다. 더 정확한 해석은 이렇습니다: Clef는 분류, 도구 호출, 구조화 인덱싱에 강하고, Jev는 약간의 범용 추론이 필요한 작업(GPQA, MMLU-Pro, BBH)에서 앞섭니다. 이는 각자의 백본과 훈련 목표와 맞아떨어집니다——Clef는 Qwen 백본을 post-train해 범용 추론을 더 많이 보존하고, Jev는 일부 의사결정 특화 지표에서 앞서 나갑니다. 자신의 작업이 어느 쪽에 가까운지에 따라 고르세요.
지연(밀리초, 낮을수록 좋음):
| 지표 | Clef | Clef-flash | Jev | Laya |
|---|---|---|---|---|
| 중앙값 지연 | 209.3 | 38.8 | 524.1 | 5.8 |
| p95 지연 | 238.6 | 122.4 | 536.0 | 222.5 |
Laya는 중앙값에서 극히 빠르지만 위의 품질 benchmark에서는 확실히 뒤처집니다——“빠르지만 정확도를 희생하는” 위치입니다. Clef 제품군은 품질 대 지연 곡선에서 서로 다른 지점을 차지합니다: Clef는 품질을, Clef-flash는 속도를 최적화합니다. 이 수치들은 서로 다른 하드웨어와 배포에서 나온 것이며 행 간에 환산할 수 없습니다——상대적 신호로만 취급하세요.
워크플로 평가(TypeSafe Evals의 end-to-end 비즈니스 플로):
| 워크플로 | Clef | Clef-flash | Jev |
|---|---|---|---|
| 인보이스 처리(exact) | 64.7 | 57.1 | 61.8 |
| 고객 서비스(exact) | 76.3 | 77.0 | 76.0 |
| 보안 인시던트(exact) | 62.9 | 61.7 | 61.7 |
| Agent trace 관측성(primary) | 68.5 | 69.8 | 71.6 |
Cloudflare의 표현은 “네 번 중 세 번 승리”입니다. 공정하게 보자면 격차는 모두 한 자릿수이고, 이는 Cloudflare가 TypeSafe의 자체 eval suite를 실행한 것이므로 실제 구매에는 여전히 자체 데이터가 필요합니다.
배포와 라이선스: “오픈”이 실제로 주는 것
두 Clef 모델 모두 Apache-2.0으로 Hugging Face에 공개되며, 로컬에서 실행할 수 있는 표준 sharded safetensors를 제공합니다:
- Transformers(
image-text-to-text파이프라인) - vLLM(
vllm serve "Cloudflare/clef") - SGLang
- Docker Model Runner, llama.cpp / Ollama / LM Studio(양자화 빌드)
파일 구성도 명확합니다: 백본 웨이트, joint_head.safetensors + joint_head_config.json(joint schema head), 그리고 joint_schema_model.py(레코드 인코딩, 배칭, systemone 래퍼)입니다. Cloudflare는 torch 2.11과 transformers 5.10.2를 사용해 단일 H200에서 테스트했습니다.
여기서 “오픈소스는 무료”라는 환상을 깨야 합니다:
- Apache-2.0은 라이선스 비용을 면제하지만 GPU 비용은 당신이 냅니다. BF16의 27B는 소비자용 카드에 편하게 들어가지 않습니다. Clef-flash의 9B가 훨씬 현실적입니다.
- 운영은 당신 몫입니다. 모델 서빙, 상주 VRAM, 버전 업그레이드, 보안 패치, 모니터링이 모두 비용입니다.
- 호스팅 버전은 이런 비용을 없애줍니다: Cloudflare Workers AI 외에도 Clef나 Clef-flash 호스팅 API를 유료로 쓸 수 있으며, 대가는 종량제 청구로 바뀌는 것입니다.
Cloudflare는 엔터프라이즈 대응 관점도 강조합니다: 기본적으로 요청과 응답을 읽거나 저장하거나 훈련에 사용하지 않습니다——fine-tuning 제품에 옵트인하지 않는 한. 자체 호스팅은 데이터 경계 요건을 쉽게 충족합니다. 이는 Jev 비교에서 남았던 공백, 즉 호스팅 API의 데이터 보존을 벤더에 확인해야 했던 부분을 정확히 메워줍니다.
새로운 RL fine-tuning 플랫폼
Clef 발표에서 놓치기 쉽지만 중요한 부분이 있습니다: Cloudflare가 RL fine-tuning 서비스를 도입했습니다.
동기는 고도로 전문화된 내부 분류 요구(Trust & Safety 제출 검토, 지원 트리아지, 좋은 봇과 나쁜 봇 판별)가 많기 때문입니다. 이런 시나리오에는 수년간 축적된 라벨링된 의사결정 데이터가 있습니다. Fine-tuning은 범용 성능 일부를 특정 도메인의 더 높은 정확도와 맞바꾸는 것이며, 15년 이상의 네트워크 데이터를 가진 Cloudflare에 딱 맞는 강점입니다.
기술 스택도 눈여겨볼 만합니다:
- Cloudflare AI Gateway: AI 트래픽을 자동으로 dataset에 수집
- Workers AI: 기본 Clef 모델에 대한 rollout 생성
- Cloudflare Containers: agent 행동을 스코어링하고 재생하기 위한 RL 샌드박스
- [New] Trainer: fine-tuning된 Clef 웨이트 업데이트
- Workers AI + BYO Model: fine-tuning된 모델을 Workers AI에 다시 배포
현재는 Cloudflare의 forward-deployed engineer(FDE) 팀과 함께하는 직접 지원 형태로 운영되며, 셀프서비스 플랫폼은 나중에 계획되어 있습니다. 이미 Cloudflare를 많이 쓰는 팀에게는 라벨링된 데이터를 맞춤형 의사결정 모델로 바꾸는 경로입니다——Jev에는 현재 공개된 대응물이 없습니다.
권고: 구호가 아닌 조건
Clef(또는 Clef-flash)를 선택하는 경우
- 입력에 이미지나 비디오가 포함되고 멀티모달 분류가 필요합니다.
- 데이터가 자체 경계를 벗어날 수 없고, 자체 호스팅 또는 오프라인 배포를 위한 Apache-2.0 웨이트가 필요합니다.
- 더 긴 state를 위한 64k 컨텍스트 윈도우를 원합니다.
- Cloudflare 생태계 안에서 fine-tuning해 라벨로 맞춤형 모델을 만들고 싶습니다.
- 지연이 중요하고 정확도 희생을 감수할 수 있습니다: Clef-flash는 매우 빠릅니다.
- 지금 바로 검증하려면: defapi에서 Clef 또는 Clef-flash 요청을 한 번 실행합니다.
Jev를 선택하는 경우
- 텍스트 의사결정만 필요하고 운영 부담 없는 호스팅 API를 원합니다.
- 작업이 범용 추론(GPQA / MMLU-Pro / BBH)에 가깝고, 여기서는 현재 Jev가 앞섭니다.
- 이미 Jev 통합, threshold, 보정 곡선을 갖추고 있고, 마이그레이션 이득이 재테스트 비용을 상쇄하지 못합니다.
- 팀에 GPU 운영 역량이 없고 모델 서빙을 운영할 계획도 없습니다.
둘 다 문제없다면
- 실제 state 분포, 선택지 집합, score 기준으로 shadow 트래픽을 돌리세요.
- 정답률, 보정, p50/p95 지연, 폴백 동작, 비용을 함께 측정하세요.
- API 호환성을 마이그레이션 비용 제로로 취급하지 말고, 경계 샘플에서 threshold를 다시 검증하세요.
- 공개 benchmark에 의존하지 말고 데이터 보존, 상주, SLA, 지원 약속을 구매 심사 관문에 넣으세요.
FAQ
Clef는 정말 Jev와 완전히 호환되나요?
wire protocol 수준에서는 그렇습니다: 동일한 POST /v1/systemone 요청 본문과 동일한 answers / usage 응답 형태, 일치하는 choice / score / noul 프리미티브를 제공합니다. 하지만 선택지 제한, 신뢰도 공식, 보정 곡선은 모델 내부에서 다르므로 기존 threshold를 그대로 복사할 수는 없습니다.
Clef는 오픈소스인데 프로덕션에서 무료로 돌릴 수 있나요?
무료 라이선스가 TCO 0을 뜻하지 않습니다. 27B에는 제대로 된 GPU가 필요하고, 모델 서빙, VRAM, 모니터링, 업그레이드, 보안 패치도 따라옵니다. Clef-flash(9B)나 호스팅 버전이 대개 더 경제적입니다.
Clef와 Clef-flash 중 무엇을?
Clef는 정밀 모델로 대부분의 benchmark에서 앞서고, Clef-flash는 중앙값 38.8ms의 지연 모델로 Clef보다 약 5배 빠르지만 CLINC150과 ContractNLI 같은 작업에서 정확도 하락이 뚜렷합니다. hot path에는 flash를, 중요한 판단에는 Clef를 사용하세요. 둘 다 호스팅되어 defapi에서 유료로 체험할 수 있습니다: Clef, Clef-flash.
공식 benchmark만으로 구매 결정을 내릴 수 있나요?
아닙니다. 이는 Cloudflare의 내부 실행 결과이고, Clef는 TypeSafe의 자체 eval suite에서 비교됩니다. 명백히 맞지 않는 후보를 걸러내는 데는 괜찮지만, 최종 판단은 자체 데이터에서 동일한 dataset, 장애 정의, 신뢰도 threshold로 내려야 합니다.
이미지 입력은 실제로 어떻게 사용하나요?
record에 images(PIL 이미지) 또는 videos(프레임 배열)를 추가하고, 선택적 processor 인자를 media_kwargs에 넣은 뒤, processor를 encode_record에 전달합니다. 텍스트 레코드와 멀티모달 레코드는 배치에서 섞을 수 있습니다.
Clef 자체 호스팅에는 무엇이 필요한가요?
H200급 GPU, torch 2.11 + transformers 5.10.2, 이미지/비디오용 pillow입니다. Cloudflare는 소비자용 하드웨어에 대한 보장을 하지 않으므로, 프로덕션 전에 목표 하드웨어에서 p95를 부하 테스트하세요.
Clef가 Jev를 대체할까요?
꼭 그렇지는 않습니다. 둘은 benchmark에서 승패를 주고받고, Jev는 범용 추론 작업에서 앞서며, 순수 호스팅 경로로 남아 있습니다. 실제로 달라진 것은 의사결정 모델 범주가 단일 벤더에서 오픈 웨이트와 멀티모달 입력을 갖춘 경쟁 구도로 바뀌었다는 점이며, 이는 구매자에게 좋은 일입니다.
다음 단계
호스팅 경로를 직접 써보려면 defapi의 Clef(27B 정밀 모델) 또는 Clef-flash(9B 속도 모델)를 유료로 이용하고, Jev API와 shadow 트래픽으로 비교하세요. 이미지 입력이나 자체 호스팅이 필수 요건이라면 Hugging Face의 Clef 모델 카드와 Cloudflare 발표 글을 읽고 자체 데이터로 비교를 실행하세요. 기본기를 먼저 채우려면 Jev vs Laya 비교와 System One 입문을 참고하세요.