Kev: Qwen3.5 기반의 초소형 Jev 계열 의사결정 모델

AI 요약

Kev는 Jev의 아키텍처 설명인 Architecture Unmasked를 바탕으로 만든 소형 의사결정 모델 제품군입니다. 사전 학습된 가중치를 내려받아 바로 실행하거나, 제공된 학습 코드와 평가 데이터로 자신만의 모델을 만들 수 있습니다. API 형식은 TypeSafe의 System One과 맞춰져 있어 Python SDK의 엔드포인트만 로컬 서버로 바꿔 사용할 수 있습니다.

■ 한 요청에서 여러 판단 수행

입력은 판단 대상인 state와 여러 개의 questions로 구성합니다. 질문마다 noul, choice, score 중 하나를 지정합니다. noul은 예·아니오 판단과 yes 확률을 반환하고, choice는 1~255개 선택지 중 하나와 선택지별 확률을 반환합니다. score는 순서가 있는 2~255개 등급의 평균 인덱스와 분포를 돌려줍니다.

모든 질문은 같은 입력 텍스트를 읽지만 서로의 질문 내용은 읽지 못하게 설계했습니다. 예를 들어 고객 문의 하나에 담당 부서, 긴급한 사람 개입 여부, 고객의 불만 정도를 한 번에 물을 수 있습니다. 선택지만 돌려주는 분류기와 달리 확률 분포가 함께 나오므로, 여러 후보가 섞인 문의인지 판단할 때 정보를 더 많이 남깁니다. 다만 confidence는 측정된 정확도 비율이 아니라, 선택지 확률 분포에서 계산한 값입니다.

■ 질문 격리와 Qwen3.5의 처리 방식

Qwen3 기반 모델은 상태와 질문을 하나의 토큰 시퀀스에 넣고 attention mask로 각 질문이 상태와 자기 질문만 읽게 합니다. 질문마다 위치 ID도 상태 뒤에서 다시 시작합니다. 이 구조에서는 여러 질문을 한 번에 묻거나 각각 따로 묻어도 확률이 같아야 하며, fp32 테스트에서 두 방식의 차이는 4e-6 이내였습니다.

Qwen3.5는 일반 attention 계층과 Gated DeltaNet 계층을 섞어 씁니다. DeltaNet은 attention mask를 따르지 않는 recurrent 구조라서, Kev는 질문마다 상태와 해당 질문만 담은 별도 행을 만듭니다. 행들이 서로 독립되므로 질문 격리가 정확해지고, 상태를 처리한 캐시는 모든 행에서 재사용합니다.

각 선택지의 </opt> 은닉 상태와 질문의 <decide> 은닉 상태를 pointer head가 비교합니다. softmax를 거쳐 선택지 확률을 만들며, <decide>가 선택지 목록 뒤에 있어 전체 선택지를 읽습니다. 학습에서는 정답에 cross-entropy를 적용하고, LoRA adapter와 pointer head만 업데이트합니다. 기본 모델 가중치는 고정하며 Jev의 출력을 학습 데이터로 사용하지 않았습니다.

■ 로컬 실행과 성능

Python 3.12 이상과 uv가 필요합니다. 저장소를 내려받고 uv sync --extra serve를 실행한 뒤 KEV_DTYPE=bf16 uv run --extra serve python -m kev.serve --run jaredpalmer/kev-4b --port 8009로 Kev-4B 서버를 띄웁니다. 첫 실행 때 adapter와 기본 모델을 내려받습니다. 서버는 기본적으로 127.0.0.1에만 바인딩하고 인증을 제공하지 않으므로, 인증을 직접 추가하지 않는 한 외부에 노출하면 안 됩니다.

CUDA에서는 Qwen3.5용 flash-linear-attention을 설치하면 됩니다. H100에서 질문 다섯 개를 묻는 요청은 수십 밀리초 수준입니다. Apple Silicon에서는 DeltaNet용 빠른 커널이 없어 PyTorch 레퍼런스 구현을 사용합니다. M5에서 약 230토큰 상태에 질문 다섯 개, 질문마다 선택지 세 개를 넣은 요청의 중앙값은 Kev-0.8B가 329ms, Kev-4B가 779ms, Kev-9B가 약 2초입니다. 같은 조건의 Qwen3 세대는 각각 123ms, 174ms, 약 300ms였습니다. Mac에서 지연 시간이 중요하면 당분간 Qwen3 모델을 선택해야 하며, Qwen3.5용 MLX backend가 다음 계획입니다.

웹 playground에서는 입력과 질문을 편집하고, 모든 질문을 한 번에 묻는 방식과 질문별로 따로 묻는 방식을 비교할 수 있습니다. Permute 기능은 선택지 순서를 여섯 가지로 바꿔 결과가 달라지는지 확인합니다. 체스 데모에서는 보드 상태를 입력으로 넣고 합법적인 수를 선택지로 제시하며, 별도 score 질문으로 포지션을 평가합니다.

■ 평가 결과와 보정

세 모델은 같은 데이터와 학습 설정을 사용합니다. 새 출처 데이터의 개발 세트와 테스트 세트 정확도는 Kev-0.8B가 0.643/0.668, Kev-4B가 0.797/0.837, Kev-9B가 0.822/0.852입니다. Brier score는 각각 0.513/0.473, 0.299/0.255, 0.286/0.237이며 낮을수록 좋습니다. Jev는 새 출처 개발 세트에서 정확도 0.857, Brier score 0.211을 기록했습니다. Kev-9B는 개발 세트에서 Jev보다 3.5포인트 낮고, Jev가 실행되지 않은 테스트 세트에서는 0.852를 기록했습니다. 두 모델의 학습 데이터가 공개되지 않았으므로 통제된 비교는 아닙니다.

Kev-4B와 Kev-9B는 2026년 9월 21일 생성 예제로 두 번째 짧은 학습을 거쳤습니다. 날짜 수가 명시된 정책 사례와 판단 근거를 삭제한 사례를 추가하고, 후자에는 균등한 답을 학습시켰습니다. 그 결과 Kev-9B 테스트 정확도는 0.837에서 0.852로 올랐고 95% 신뢰구간은 +0.8~+2.9포인트였습니다. Kev-4B는 0.832에서 0.837로 올랐습니다. 이전 가중치는 v7-base revision에 남아 있습니다.

새 출처에서 원시 확률은 과신하는 경향이 있습니다. Kev-9B는 틀린 답에 0.9 이상 확률을 부여하는 비율이 8.7%였고, KEV_TEMPERATURE=2.0을 적용하면 4.4%로 줄었습니다. calibration error도 0.106에서 0.050으로 낮아졌습니다. KEV_DATE_FACTS=1은 상태에 등장하는 두 절대 날짜 사이의 일수를 텍스트로 덧붙입니다. 날짜 계산 자체에는 약하지만, 날짜 차이가 명시되면 마감 정책 질문의 Kev-9B 정확도가 0.80에서 0.90으로 올랐습니다. Jev는 0.93이었습니다.

■ 학습과 도메인 미세 조정

공개 데이터셋 10,000개, 생성한 정책 예제 896개, 60개 규칙 구조에서 만든 예제 1,680개를 포함한 decision-v7으로 학습합니다. 두 epoch 동안 LoRA rank 16과 cross-entropy를 사용하며, 학습률은 0.8B에서 1e-4, 4B와 9B에서 5e-5입니다. Qwen3.5에서는 DeltaNet projection도 adapter 대상에 포함합니다.

자체 라우팅 범주나 에스컬레이션 규칙, 다른 언어를 다루려면 수백 개의 라벨 예제로 짧게 미세 조정하는 편이 프롬프트 변경보다 효과적이라고 설명합니다. 이때 공개 checkpoint를 --init_from으로 불러와 기존 지식을 유지해야 합니다. 한 사용자의 836개 지원 도구 결정 실험에서 기본 모델에서 바로 학습한 결과는 Kev 자체 평가 세트에서 0.33에 그쳤지만, 공개 모델에서 시작한 결과는 0.83을 유지했고 새 도메인에서는 0.88을 기록했습니다. --init_from 학습에는 2e-5 정도의 더 작은 학습률을 권장합니다.

■ 현재 한계

선택지 순서가 바뀌면 답이 바뀔 수 있습니다. 질문 격리는 선택지 사이의 상호 영향을 막지 않습니다. 학습에서는 상태를 최대 384토큰, 상태와 한 질문을 합쳐 1,024토큰까지만 사용했지만, 서빙 API는 상태에 최대 8,192토큰을 허용합니다. 긴 입력에 대한 성능은 학습 범위 밖입니다.

서버는 한 번에 하나의 요청만 처리하고, 서로 다른 호출자의 요청을 batch로 묶지 않습니다. MMLU에서는 Kev 0.74 대 Jev 0.90, MMLU-Pro에서는 0.52 대 0.84로 지식형 질문의 격차가 큽니다. Qwen3.5-9B base가 마감 정책 질문에서 0.82를 기록했지만 첫 Kev-9B는 날짜 산술을 학습한 뒤 0.72로 떨어진 사례도 있습니다. 작은 결정 모델을 실제 자동화 임계값에 연결하기 전에 자체 데이터에서 정확도와 calibration을 측정해야 합니다.

■ Hacker News 반응

• @dunlin — 이 분야의 무언가를 계속 기다리고 있었습니다. Qwen3.5 기반 Jev 계열 모델은 내부 라우팅 로직을 꽤 단순하게 만들 수 있어 보입니다.
• @mugul — 사람들이 오픈소스 Jev 계열 모델을 만드는 데 쏟는 에너지가 상당히 인상적입니다. 열풍은 이해하지만, 이런 모델의 용도가 무엇인지 궁금합니다. 코딩 에이전트에 쓸 수 있나요, 아니면 전혀 다른 상황에 더 적합한가요?
• @Havoc — 저도 같은 생각입니다. API를 사용할 수 있게 된 뒤에도 당장 쓸 곳이 떠오르지 않았습니다.
• @lucrbvi — 코드에서 어느 정도 지능이 필요한 JSON 같은 구조를 만들 때 Jev 계열 모델을 호출하면 됩니다. Jev를 똑똑한 if 문이라고 생각하면 됩니다.
• @saejox — 2D 로그라이크 플랫폼 게임의 스마트 AI를 만들 때 쓰고 싶습니다. 시스템이 너무 많이 움직여서 전통적인 상태 머신 AI로는 부족하고, 직접 개발할 시간도 없습니다. 낮은 지연 시간이 매력적입니다.
• @vidarh — LLM이 선택지나 범주만 출력하도록 강제하는 모든 상황을 생각해 보면 됩니다. 그런 workflow라면 비용과 지연 시간을 크게 줄일 수 있다는 약속을 받은 셈입니다. 코딩 에이전트에서는 일부 상황에만 유용합니다. 예를 들어 bash 도구 호출을 안전하거나 위험한 것으로 분류하는 용도입니다.
• @NitpickLawyer — 코딩 에이전트에도 쓸 수 있습니다. 가장 분명한 용도는 느리고 비싼 에이전트인 cc, Codex, OpenCode를 곁에서 빠르게 제어하고 피드백하는 모델입니다. 긴 프롬프트에서 목표를 떼어내 행동과 검증자로 나눌 수 있습니다. 각 행동마다 검증자를 만들고, 행동이 끝날 때마다 검증자를 실행해 작업 완료 여부와 후속 조치 필요 여부를 결정하는 식입니다. 예를 들어 저장소에 인증을 구현하라는 작업을 받으면 계획을 만들고, 각 항목의 검증자를 만든 뒤 구현하고 검증하고 승인하거나 후속 작업으로 넘깁니다. 프로젝트 규칙을 따르는지, 다른 작업의 파일을 건드렸는지 같은 질문을 검증자로 만들 수 있습니다.
• @jeeeb — 이 용도는 그리 좋지 않다고 생각합니다. 일반 LLM으로 이미 훨씬 잘할 수 있습니다. Jev 같은 모델의 문제는 매우 멍청한 모델이라는 점입니다.
• @monkeydust — Jev가 계속 쏟아져 나오고 있습니다. 분류 모델은 오래전부터 있었는데, 우리가 더 단순하고 잘 이해하는 시대로 돌아가서 그런 것인가요?
  • @Tycho — 실용적이고, 이전에는 비현실적이던 일을 가능하게 했기 때문입니다.
• @petesergeant — 기존 모델의 tool calling으로 이미 해결한 일이 많다고 생각합니다. 어떤 benchmark를 보느냐에 크게 달렸습니다. BANKING77 비교에는 문제가 많지만 DeepSeek 4.1 Flash와 크게 멀지 않다는 점을 보여줍니다. BoolQ에서는 Qwen3.6보다 조금 나은 정도입니다. MMLU-Pro에서는 두 Qwen 모델보다 크게 앞섭니다. 분명 어느 정도 이점은 있지만, 열풍이 말하는 만큼 큰 변화인지는 모르겠습니다. 기존 도구로 이미 충분히 실용적이었던 일이 많습니다.
• @anentropic — 용도마다 별도의 모델을 미세 조정하지 않아도 된다는 점이 매력적입니다. 유연성을 유지하면서 제품과 비즈니스 로직을 계속 만들고 바꿀 수 있습니다.
• @badatnames — Ansible이 잘했던 사용자 소통이 떠오릅니다. 기반 기술은 오래전부터 있었지만, 일반 개발자에게 작은 JSON만으로도 ML을 이해하고 쓸 수 있다고 보여준 점이 뛰어났습니다. 그 기여를 과소평가하면 안 됩니다.
  • @colordrops — 다만 실제로는 잘 작동하지 않습니다. 내부에서 계속 깨지고, NixOS 같은 전체 시스템 관리가 없으면 카드로 만든 집에 가깝습니다.
  • @badatnames — 저도 개인적으로 Ansible을 좋아하지는 않지만, 설치 기반 규모를 생각하면 실제로 작동하지 않는다고 말하는 건 놀라운 주장입니다.
  • @embedding-shape — Ansible은 작동합니다. 지금 내려받아 사용할 수 있고, 설명한 일을 합니다. 모든 인프라 용도에 가장 좋은 해법인가요? 물론 아닙니다. 그런 도구는 없습니다. 사람들이 잘못 사용하나요? 물론 그렇습니다. 어떤 도구를 쓰든 우리는 모두 카드로 만든 집을 짓고 있고, 상황에 따라 다른 요구사항과 균형을 맞추며 그 카드를 붙잡고 있습니다.
• @reacharavindh — Jev와 Laya를 아직 사용해 보지는 않았지만, 분류기는 ML 분야에 늘 있었고 익숙한 도구였습니다. 보통은 무엇으로 분류할지뿐 아니라 입력을 분류할 가중치도 정해야 합니다. Jev는 원한다면 분류기를 직접 학습하거나 가중치를 정하지 않아도 된다는 마법을 더했고, 분류된 답을 바로 얻습니다. 사람들이 이 기술을 반짝이는 눈으로 보는 이유가 거기에 있다고 생각합니다.
• @justincormack — Jev와 비슷한 도구를 특정 문제용 분류기와 비교한 결과가 궁금합니다. Laya도 문제별 모델을 만들자고 제안한 것으로 압니다. 에이전트가 맞춤형 해법을 효과적으로 만들어주는 시대에 아무것도 직접 하지 않는 마법 같은 해법을 원하는 수요가 많은 점은 조금 이상합니다.
• @BoorishBears — Jev는 제게 일종의 정체성 위기를 일으킵니다. 분류기라는 말을 반복하는, 정말 아무것도 모르는 사람들이 이렇게 많이 나타난 것은 CS에서 처음 보는 대규모 집단 현상입니다. 조금만 만져봐도 이것이 BERT나 과거의 분류 모델과 ChatGPT가 Markov Chain 생성기와 비슷한 정도 이상으로 다르다는 사실을 알 수 있습니다. 그런데도 사람들이 새롭고 흥미로운 개발 방향을 값싼 조롱으로 자신 있게 깎아내립니다.
• @kingkongjaffa — 저는 정말 아무것도 모릅니다. 어떻게 더 배울 수 있나요? Jev가 BERT 같은 분류 모델이나 전통적인 ML보다 근본적으로 나은 이유가 무엇인가요? 관련 내용을 조사하고 설명하도록 LLM에 넣을 프롬프트를 추천해도 좋습니다.
  • @mlloyd — 방금 직접 프롬프트를 작성한 것 아닌가요? LLM에 질문을 넣고, 답하지 못한 부분을 다시 구체적으로 물어보겠습니다. 저는 어제 그렇게 시작했다가 깊이 빠져들었고, 머릿속에 제품 아이디어 세 개가 생겼습니다.
• @nullbio — 이런 결정 모델이 큰 context window를 지원하면 프론트엔드 스타일 규칙과 React 컴포넌트 생성 규칙을 강제하는 데 좋을 것 같습니다. 스타일 가이드와 styling skill 대신 결정 트리로 스타일과 컴포넌트 규칙을 검사하면 drift나 중복을 막을 수 있습니다. 지금 가장 많은 시간을 쓰는 일이 기능을 추가할 때마다 생기는 UX/UI 문제를 계속 고치는 것입니다.
  • @spockz — 예전에는 자체 stylesheet와 class 사용을 엄격하게 강제해 UX/UI 문제를 막았습니다. 나중에는 회사 UX 컴포넌트만 사용했습니다. 새 요소를 만들고 관리하며 합의를 얻는 과정은 어려웠지만 전체적으로 매우 잘 작동했습니다. 모든 것을 기본 블록부터 쌓지 말고 재사용 가능한 컴포넌트를 만들면 됩니다. 에이전트 개발이라고 해서 우리가 배운 것을 모두 버릴 필요는 없습니다. 사람이 품질과 속도를 높였던 방식은 에이전트에도 도움이 됩니다.
• @raahelb — 이 결정 모델에는 tool calling이 없기 때문에 knowledge cutoff가 문제가 될 수 있습니다. 로컬에서 계속 학습시키거나, Jev 같은 폐쇄형 모델을 쓸 때는 매달 새 버전으로 바꿔야 할지도 모릅니다.

원문: Hacker News / 번역·요약: Trawling