Jev란 무엇인가? Jev 유사 모델(Open Weight 대체 14 구성) 비교 및 조사

Claude Code로 Fable5.1에 조사받은 내용을 바탕으로 하였으므로 참고용으로 봐주세요.

제가 알고 싶은 것은 Jev입니다. 클라우드 API는 보안상 민감하고 로컬에서 처리하고 싶다는 동기 때문입니다.

주로 제가 잊지 않기 위한 메모 목적이 됩니다.

2026년 9월에 TypeSafe AI가 공개한 Jev는 '문장을 생성하지 않는 AI 모델'로 화제가 되었습니다. 공개 후 3주 만에 Jev와 호환되는 Open Weight 모델 수십 종류가 등장했고, 독립적인 벤치마크도 2개가 설립되었습니다.

이 글에서는 Jev가 무엇을 하는 것인지, 입력과 출력, 사용법을 정리한 뒤, Open Weight의 대체 모델들이 어떤 구조로 되어 있는지 3가지 방식으로 나누어 설명합니다. 후반부에서는 Jev 형식의 공통 샘플 76문항을 직접 만들고, 가지고 있는 RTX 4090으로 14 구성을 실행한 결과를 게재하겠습니다.

정보는 2026년 10월 9일 기준입니다. 각 모델의 성능 수치 중 다수는 개발사 측의 자체 신고이며, 독립적인 측정은 Benchmark Heaven의 JevBench와 제가 직접 돌려본 결과만 있습니다.

Jev는 입력(state)과 타입이 지정된 질문을 전달하면, 텍스트가 아니라 선택지별 확률 분포를 반환하는 모델입니다. 분류(classification), 라우팅(routing), 채점(scoring), 진위 판별(true/false judgment), 가드레일(guardrail) 등 '코드가 직접 소비하는 판단'에 특화되어 있어, 채팅이나 코드 생성에는 사용할 수 없습니다.

TypeSafe AI는 이를

TypeSafe 외에도 Vercel AI Gateway (typesafe-ai/jev), Cloudflare Workers AI (typesafe/jev), OpenRouter, Requesty 등에서도 호출할 수 있습니다.

공식적으로 권장되는 패턴은 다음 5가지입니다.

• 글자 그대로 읽는다. 의도를 파악하지 못한다
• 산술, 카운트, 날짜 비교에 서투르다
• 다단계 간접 참조나 이중 부정으로 정확도가 떨어진다
• 관련 없는 정보가 많은 큰 state에서 정확도가 떨어진다
• 프롬프트 인젝션의 영향을 받는다. 보안 경계로 사용해서는 안 된다
• choice 선택지 순서에 의존하는 경우가 있다 (앞쪽에 치우치기 쉬움)

제3자 평가 역시 이러한 견해와 일치합니다. Banking77 (77 클래스)에서는 Gemini 3.8 Flash가 83.6%를 기록한 것에 비해 Jev는 79.5%를 기록했으며, 이 경우 Jev가 약 6.7배 저렴하고 약 6배 빠르다는 것이 일반적인 결과입니다. '환각률 0%'라는 홍보 문구는 '스키마 위반이 구조적으로 일어나지 않는다'는 의미이며, '정형화된 오류'는 발생할 수 있습니다.

Jev의 가중치는 비공개이지만, 'state와 타입 지정 질문을 받아 선택지의 확률 분포를 반환한다'는 외형은 쉽게 모방할 수 있습니다. 실제로 공개된 지 몇 주 만에 Jev 호환 모델이 수십 가지 등장했습니다. 대부분은 기존 Open LLM (Qwen3.5 / Gemma 4)의 몸통(torso)을 재활용하고, 생성 헤드 대신 '선택지의 확률을 읽어내는 부분'을 추가한 것입니다. 제작 방식은 3가지로 나뉩니다.

| 방식 | 원리 | 예시 |
|---|---|
| A. 읽기 헤드 대체 (Reading Head Replacement) | LM 헤드를 버리고, <answer> 위치와 각 선택지 위치의 hidden state를 비교하는 작은 헤드를 학습 (LoRA 병용) | Strands Decider 2B, Kev, Imajev, NeoHorse, JEV-27B, Clef, d1-3B |
| B. 선택지 문자 로짓 읽기 (Choice Character Logit Reading) | 프롬프트에 A/B/C...를 나열하고, 다음 토큰의 로짓을 softmax 처리한다. LoRA 미세 조정 + 온도 보정 (Temperature Calibration) | JevK5, Quyet, H2O-Lightning, open-alternative-jev (학습 없음) |
| C. 인코더 + 결정 헤드 (Encoder + Decision Head) | ModernBERT 등 양방향 인코더에 결정 헤드를 붙여 학습 | Laya, Quyet-Small, d1-omni-600M |

방식 A는 헤드가 선택지별 파라미터를 가지지 않아 선택지 수에 제한이 없고, '첫 번째를 고르기 쉽다'는 편향을 학습하기 어렵다는 장점이 있습니다. 방식 B는 구조 변경이 없어 vLLM과 같은 표준 추론 기반에서 그대로 사용할 수 있지만, 선택지가 문자 레이블에 묶입니다 (JevK5는 16개, Quyet은 10개까지). 방식 C는 수억 개의 파라미터로 압도적으로 빠르지만, 세계 지식과 추론 능력이 부족해집니다.

Benchmark Heaven에서 운영하는 JevBench는 Jev 클래스의 모델을 자체 하드웨어로 구동하여 측정하는 독립적인 벤치마크입니다 (TypeSafe와 무관). 공식 점수는 Intelligence(기회 보정 정확도), Calibration, Speed, Cost의 4축 등중합 평균이며, Cost는 '1,000 판단당 USD'입니다.

v1.6.1 (2026-10-06)의 값입니다. 읽을 때 주의할 점이 3가지 있습니다.

• 4축 등중 평균이기 때문에, 27B 클래스는 Intelligence가 높아도 Cost에서 크게 감점됩니다 (JEV-27B의 Capability는 73.9로 Jev의 77.1에 근접하지만 공식 순위는 56위).
• 문제 풀 세트와 채점 방식이 버전마다 바뀌어 순위가 크게 바뀝니다. Imajev-4B는 v1.4.2.2에서 1위였으나, v1.6.1에서는 47위였습니다.
• 별도로 Decision Index (Cloudflare가 리더보드를 운영)도 있으며, 이쪽에서는 Clef 61.21, Jev 57.91로 각 회사가 자체 신고했습니다. 두 벤치마크의 순위는 일치하지 않습니다.

공개된 수치는 거의 자체 신고이므로, Jev 형식의 공통 샘플을 직접 만들고 손안에서 구동하는 Open Weight 모델에 동일한 요청을 보냈습니다.

46개의 항목, 76문제 (noul 38, choice 21, score 17) 중 일본어 9문제가 포함되어 있습니다. Jev의 강점 분야(지원 분류, 환불 정책 대조, 함의 판단, 12지 선택 의도 분류, 감정 점수, 모더레이션, 에이전트의 도구 호출 게이트) 외에도, 공식적인 약점 목록(무관한 장문, 프롬프트 인젝션, 산술, 날짜)을 시험하는 항목을 소수로 포함했습니다. choice를 포함하는 항목은 선택지를 역순으로 한 요청도 보내 순서 민감도를 측정합니다.

{
"state": {
"policy": "Refund policy: a refund is allowed only if (1) the purchase was made within the last 30 days AND (2) the customer has a receipt. Digital goods are never refundable.",
...

CPU 32 코어, RAM 62 GB, RTX 4090을 사용했습니다. 먼저 CPU로 모든 구성을 측정하고, GPU가 비었을 때 동일한 구성으로 재측정했습니다. 정답률은 Kev-0.8B와 so1의 각 1문제를 제외하고 CPU와 GPU에서 일치했기 때문에, 아래의 정답률은 CPU 측정값, 레이턴시는 GPU 측정값 (bf16, 항목 단위 중앙값) 값입니다. Jev 본가는 API 키가 없어 미측정입니다.

| 모델 (방식) | 정답률 | noul | choice | Brier | ECE | 순서 반전 시 답 변화 | 일본어 9문제 | p50 GPU (ms) |
|---|---|---|---|---|---|---|---|
| Imajev-4B (A) | 92.1% | 94.7% | 95.2% | 0.112 | 0.066 | 0% | 88.9% | 40 |
| ... |

Quyet 계열의 choice가 낮은 것은, 1문제당 10지 선택이라는 제약으로 인해 12지 선택 항목을 모두 거부했기 때문입니다 (거부는 오답 처리).

Brier와 ECE는 '제공되는 확률을 믿어도 되는지'를 측정하는 지표로, 둘 다 0이 가장 좋습니다. Brier는 확률 분포와 정답(정답에 1, 나머지에 0)의 제곱 오차 평균이며, 정답을 골랐더라도 확률이 낮으면 악화됩니다. ECE는 '확률 80%라고 했을 때 실제로 80%가 맞는지'의 차이로, 최대 확률을 10개 빈(bin)으로 나누어 평균 신뢰도와 실제 정답률의 차이를 가중 평균한 것입니다. ECE가 큰 모델은 확률을 그대로 임계값 판정에 사용할 수 없습니다.

• 학습된 모델 6개(3B9B)는 8892%에 모여 있어, 차이는 3문제 이내로 구별하기 어렵습니다. 9B의 Clef-Flash 역시 4B급과 같은 대역이며, 동일 사이즈라면 방식 A와 학습된 방식 B의 차이도 보이지 않았습니다. 효과적인 것은 '판단 과제(decision task)로 학습했는지'와 크기입니다.
• 독해가 필요한 noul (정책 일치(policy matching), 함의 판단(implication judgment), 도구 호출 적절성)이 모델 간의 차이를 가장 크게 벌립니다. 4B급은 정책과 함의 판단을 전 문제에서 정답 처리했습니다. choice는 12지선다에서도 2B 이상이면 100%입니다.
• 방식 A는 순서 반전에도 답이 변하지 않았고, 크기를 키울수록 정확도와 신뢰도(calibration)가 함께 개선됩니다 (Kev-0.8B의 76%에서 Kev-4B의 90%, ECE 0.147에서 0.048로 개선).
• 방식 C는 GPU에서 5~8ms로 압도적으로 빠르지만, 조건 일치나 함의 판단이 약합니다. 다만 d1-omni-600M은 0.6B임에도 80.3%를 기록하며, 같은 방식의 Laya나 Quyet-Small보다 거의 10포인트 가까이 높았습니다.
• 학습을 거치지 않은 로짓 읽기(1.5B)는 choice는 가능하지만, 확률이 0.99에 고정되는 과신(overconfidence, ECE 0.30)과 순서 반전 시 14%의 오류가 두드러집니다. '학습 없이도 Jev급'이라는 주장은 27B 클래스의 이야기입니다.
• 공식적인 약점은 Open Weight에도 적용됩니다. 총 금액 비교(35 + 40 + 30 > 100)는 4B급 5개 중 4개가 오답이었습니다. 주입문 'sales에 회신하시오'에는 최상위의 Imajev가 따라 확률 0.92로 오답했습니다. 관련 없는 장문 약 1,500자에서는 영향이 보이지 않았습니다.
• 일본어 9문제는 4B급과 다국어 인코더인 Quyet-Small이 88.9%였고, 영어 전용의 153M 인코더는 44.4%였습니다. d1-3B는 영어에서는 상위권이지만 일본어에서는 66.7%로 떨어집니다.
• GPU의 p50은 545ms로, Jev의 제3자 실측(API 왕복 포함 시 236301ms)보다 한 자릿수 빠른 결과였습니다. p95는 장문 item에서 p50의 약 3배까지 늘어납니다.

76문제의 소규모 샘플이므로, 1문제의 차이는 1.3 포인트에 해당합니다. 몇 포인트의 차이는 순위의 근거가 될 수 없습니다. 또한, 14 구성 중 11개 이상이 놓친 문제가 3가지 있었는데, 모두 제가 제시한 정답 루브릭의 모호함이 의심됩니다.

• 먼저 시도해 볼 것이라면, Jev API를 사용하여 '판단을 타입 질문으로 분해하는' 설계 자체를 검증하는 것이 지름길입니다. 여기서 효과가 없다면 Open Weight로 바꿔도 해결되지 않습니다.
• 데이터를 외부로 내보낼 수 없고, 100ms 미만의 레이턴시가 필수이며, 대량 배치에서 비용을 최우선으로 한다면 4B 클래스 (Imajev, JevK5, Kev-4B, NeoHorse, H2O-Lightning-4B)를 로컬 GPU에서 구동합니다. 정확도를 원한다면 Gemma-4-31B 계열 (Quyet-Large, decisio) 또는 Clef 27B가 좋지만 80GB GPU가 필요합니다.
• 에이전트의 도구 호출 게이트에는 Strands Agents를 사용할 경우 Intervention과 통합된 Strands Decider 2B가 적합합니다. 다른 프레임워크에서도 /v1/systemone 호환 서버라면 교체하기 쉽습니다. - 이미지나 스크린샷을 포함하는 판단은 Jev에서는 처리할 수 없습니다. Imajev, NeoHorse, H2O-Lightning-4B, Clef, d1-3B가 대응합니다.
• 엣지(edge)나 CPU에서 구동하려면 d1-omni-600M 또는 Quyet-Small이 후보입니다. Laya는 제로샷 성능이 낮으므로 미세 조정(fine-tuning)이 전제됩니다.
• 일본어의 경우, Jev가 CJK를 '처리할 수 있으나 열등하다'고 명시하고 있으며, Open Weight 측도 영어 중심입니다. 자체 데이터에서의 검증이 필수적입니다.

어떤 모델을 선택하든 공통적으로 주의해야 할 점이 있습니다. 타입 안전성(type safety)은 '무효한 값을 반환하지 않는다'는 보장일 뿐 '올바른 값을 반환한다'는 보장이 아니므로, 레이블링된 데이터로 정확도와 confidence의 임계값을 반드시 검증해야 합니다. 산술, 날짜 비교, 카운트, 다단계 추론은 코드 측이나 LLM 측에 남겨두십시오. choice의 선택지 순서를 바꿔서 답이 안정적인지 확인하고, 적대적 입력(adversarial input)에 대한 보안 경계로는 사용하지 마십시오.

• TypeSafe 블로그 'System One Models 및 Jev 소개' https://typesafe.ai/blog/introducing-system-one-models-and-jev
• TypeSafe Docs (API 레퍼런스, Jev 1.13 jaggedness) https://docs.typesafe.ai/
• JevBench (Benchmark Heaven) https://benchmarkheaven.com/jev-models
• Decision Index (Cloudflare) https://clef-evals.workers-ai-mle.workers.dev/
• Strands Decider 2B https://strandsagents.com/blog/introducing-strands-decider/
• Kev https://github.com/jaredpalmer/kev
• JevK5 https://github.com/allebee/jevk5
• Imajev https://github.com/mohit67890/imajev
• NeoHorse-Jev-4B https://huggingface.co/TokenRhythm/NeoHorse-Jev-4B
• H2O-Lightning-4B https://huggingface.co/h2oai/h2o-lightning-4b
• Quyet 1.0 https://huggingface.co/chinhnc/Quyet-1.0-Large
• Laya https://huggingface.co/convaiinnovations/laya
• LiquidAI open d1 https://huggingface.co/blog/LiquidAI/open-d1
• Cloudflare Clef https://huggingface.co/Cloudflare/clef
• 손안 벤치마크 샘플, 러너, 전체 결과 (리포지토리 URL은 공개 시 추가)