Kev-4B

모델 요약

Kev-4B는 의사결정 모델입니다. 하나의 문서(상태)와 그에 관한 일련의 타입 지정된 질문을 읽고, 각 질문에 함께 주어진 선택지들 위의 캘리브레이션된 확률 분포를 한 번의 포워드 패스로, 텍스트를 생성하지 않고 반환합니다. 문서를 분류, 라우팅, 트리아지, 검사하고, 임계값을 적용할 수 있는 확률이 필요한 개발자를 위한 것입니다(예를 들어 불확실한 사례를 사람 검토로 보내기 위해). TypeSafe의 공개 System One API(POST /v1/systemone)를 구현하므로, TypeSafe SDK가 변경 없이 이를 대상으로 동작합니다. Qwen3.5-4B-Base 위의 LoRA 어댑터와 포인터 헤드로, 24 GB GPU 한 장이나 32 GB Apple Silicon Mac에 들어갈 만큼 작습니다. 이 카드는 Kev 1.0의 체크포인트를 설명하며, 2026-09-24에 처음 공개되었습니다.

모델 세부 사항

입력. 하나의 상태(텍스트, 또는 레이블이 붙은 텍스트로 렌더링된 JSON 객체나 배열)와 임의 개수의 이름 붙은 질문, 각 질문은 세 가지 유형 중 하나입니다:

각 질문은 공유 상태에서 이어지는 자기 자신의 행으로 답변되므로, 질문들이 서로 영향을 줄 수 없습니다. 상태는 한 번만 계산되어 캐시됩니다.

의도된 용도

• 수천 토큰 규모 문서에 대한 타입 지정 결정: 분류, 라우팅, 트리아지, 추출 선택, 정책 및 자격 검사, 그리고 명시된 기준에 비추어 제안된 답을 판정하기.
• 신뢰도에 따라 행동하는 워크플로: 확신 있는 사례를 자동화하고 나머지를 대기열에 넣되, 임계값은 사용자 자신의 워크로드에서 레이블된 표본에 고정.
• 보통 수준의 하드웨어에서 System One 엔드포인트를 대체하는 셀프 호스팅 드롭인, 그리고 사용자 자신의 레이블로 파인튜닝하기 위한 출발점(kev.train --init_from jaredpalmer/kev-4b).

범위 밖 용도

• 텍스트 생성, 대화, 요약, 또는 개방형 질의응답. 모델은 주어진 선택지에만 점수를 매깁니다.
• 사람에게 법적, 의료적, 금융적, 고용상 또는 이와 유사한 결과를 초래하는 완전 자동화된 결정을, 사람의 검토 없이 내리는 것.
• 답이 상태에 없고 일반 상식도 아닌 사실에 의존하는 질문, 그리고 지식 집약적 시험(한계와 트레이드오프 참고).
• KEV_DATE_FACTS=1 전처리기 없이 일 단위 정밀도의 날짜 산술, 65,536 토큰보다 긴 상태, 그리고 영어 이외의 언어.

사용 방법

Kev 저장소로 서빙합니다. CUDA에서는 융합된 DeltaNet 커널과 CUDA graphs와 함께 bf16으로 실행됩니다(L40S 한 장, H100, 또는 약 16 GB가 남는 아무 GPU). Apple Silicon에서는 같은 명령이 MLX를 통해 서빙하며, 자동으로 선택됩니다.

git clone https://github.com/jaredpalmer/kev.git && cd kev && uv sync --extra serve
uv run --extra serve python -m kev.serve --run jaredpalmer/kev-4b --port 8008           # Kev 1.0 (this card)
uv run --extra serve python -m kev.serve --run jaredpalmer/kev-4b@v1.0 --port 8008      # the same weights, pinned

from typesafe_sdk import Choice, Noul, TypeSafeClient

client = TypeSafeClient(api_key="local", base_url="http://127.0.0.1:8008", model="kev-latest")
response = client.system_one(
    state="I was charged twice for order 1182. Please refund one of the charges.",
    questions={
        "team": Choice(instructions="Which team should handle this?",
                       criteria={"billing": "Charges and refunds", "shipping": "Deliveries", "returns": "Exchanges"}),
        "urgent": Noul(instructions="Does this need a reply today?"),
    },
)
print(response.choices["team"].choice, response.nouls["urgent"].noul)

캘리브레이션된 온도는 기본적으로 적용됩니다. KEV_TEMPERATURE=1.0은 원시 확률을 반환합니다. KEV_DTYPE=fp32는 평가에 사용된 정확한 경로를 선택합니다. KEV_DATE_FACTS=1은 상태에서 찾은 날짜 쌍마다 그 사이 일수를 덧붙이며, 모델은 이를 사용하도록 학습되었습니다. 65,536 토큰을 넘는 상태는 거부되며, 토큰 수를 알려주는 422가 반환됩니다.

학습 데이터

첫 단계 이후의 각 파인튜닝 단계는 decision-v7의 레코드를 재생합니다(2,000, 2,000, 4,000). Jev(TypeSafe의 호스팅 의사결정 모델)의 출력은 전혀 사용되지 않았습니다. CodeReviewer와 FlakeFlagger는 Zenodo에서 왔고, CFPB 서술은 미국 정부 저작물입니다. 소스별 라이선스와 revision은 스위트 manifest에 기록되어 있습니다. 아래의 평가 전용 스위트(breadth-v1, tasksource-heldout-v1, transfer-v4, longdoc-v1, 그리고 devtools-v1의 When2Call 및 프롬프트 인젝션 소스)는 학습에 전혀 들어가지 않습니다.

학습 절차

1. 베이스 레시피. 베이스에서 decision-v7에 대해 두 epoch: LoRA rank 16, α 32; 학습률 5e-5, one-cycle 스케줄; 유효 batch 8(4 × 2 누적); bf16 autocast, 그래디언트 체크포인팅; seed 2. 손실은 각 질문의 선택지에 대한 교차 엔트로피입니다. 선택지 순서를 섞고, “해당 없음”(none of the above) 선택지와 방해 선택지(distractor)를 무작위로 삽입하며, choice 레코드의 4분의 1은 최소 대조 쌍(minimal pair)도 생성합니다(“해당 없음” 선택지가 있는 그 질문을, 정답 선택지가 있을 때와 제거했을 때 한 번씩).
2. 날짜와 결측 증거. 단계 1에서 학습률 2e-5로 한 epoch, 2,000개 레코드 재생.
3. 실제 문서. 단계 2에서 documents-v1 train에 대해 학습률 2e-5로 한 epoch, 2,000개 레코드 재생; batch 2 × 4 누적; 상태 최대 7,552 토큰.
4. 기술. 단계 3에서 hard-v1과 devtools-v1 train을 함께, 학습률 2e-5로 한 epoch, 4,000개 레코드 재생; batch 2 × 4 누적; 상태 최대 7,552 토큰; seed 1; 옵티마이저 스텝 1,915회.
5. 캘리브레이션. 단일 온도(temperature) T = 2.41, 단계 4 트라이얼의 decision-v7 개발 행(질문 1,264개)에서 음의 로그 우도를 최소화. 이들은 학습 코퍼스의 홀드아웃 항목입니다. 홀드아웃 데이터셋에서의 재적합(refit)을 평가했으나 채택하지 않았습니다(캘리브레이션 참고).

평가

방법론. 별도 언급이 없으면 모든 숫자는 배포된 온도에서의 fp32 평가 경로입니다. 개발 파티션은 선택에 사용되었고, 테스트 파티션은 이 체크포인트를 위해 한 번 읽었습니다. transfer-v4 테스트는 잠겨 있으며(후보마다 한 번 읽음) 사전에 고정된 기준선에 비추어 판정되었습니다. 짝지은 구간은 전체 레코드를 재표본추출하는 95 % bootstrap(2,000회 재표본)이므로, 같은 상태를 공유하는 질문들은 함께 움직입니다. 차이는 퍼센트 포인트(pp)로 표시합니다. Jev(TypeSafe의 호스팅 모델, Vercel AI Gateway를 통해 쿼리)는 같은 항목에서 읽은 곳에 표시합니다. 스위트는 다음과 같습니다:

• breadth-v1: 다섯 영역(지식, 언어, 검색, 도구, 예술)의 홀드아웃 공개 데이터셋 14개, 학습한 적 없음.
• tasksource-heldout-v1: 공개 멀티태스크 컬렉션의 24개 전체 태스크 패밀리, 학습한 적 없음(패밀리 이름 비공개).
• transfer-v4: 학습한 적 없는 여섯 공개 소스(QNLI, SciQ, TweetEval-offensive, PAWS, MMLU, Emotion)의 도메인 외 결정, 그리고 홀드아웃 정책 및 규칙 구조.
• hard-v1: 위의 기술 패밀리; 테스트 분할은 학습된 생성기의 템플릿을 홀드아웃합니다.
• devtools-v1: 라이선스 검증을 거친 여섯 소스(네 개 학습, 두 개 평가 전용)의 개발자 도구 결정.
• documents-v1 / documents-v2: CFPB 민원 서술; v2는 비공개 홀드아웃 테스트 세트.
• longdoc-v1: CUAD 상업 계약과 생성된 계약 번들, 상태 4k~64k 토큰.

“감사됨(audited)”으로 표시된 헤드라인 패널은 레이블 감사에서 부적절하다고 판명된 항목을 제외합니다¹. 제외할 때마다 비교의 양쪽에서 같은 행을 제거합니다.

홀드아웃 데이터(학습한 적 없음).

학습된 패밀리(홀드아웃 항목과 템플릿).

Jev의 devtools-v1 수치는 개발 질문 1,074개 전체에 대한 것입니다. Kev의 행은 스위트 빌더가 두 레코드에 재사용한 CodeReviewer id(질문 2개)를 제외합니다.

이전 버전과 비교(문서 단계 체크포인트, tag r8-documents-release, 자체 온도 2.96에서; 등록된 기준, 각 테스트를 한 번씩 읽음):

긴 문서.

• 검증된 컨텍스트 길이: 8,192 토큰, 즉 학습 길이. 16k 버킷은 허용 범위를 벗어납니다. 하한이 −3.4 pp로 −3 pp 아래이므로, 더 긴 길이는 검증되지 않았습니다.
• 규칙, 읽기 전에 고정: 검증된 길이는 16,384 토큰부터 위로, 그 버킷과 그것과 8,192 사이의 모든 버킷이 허용 범위 안에 드는 가장 큰 버킷의 명목 크기입니다. 허용 범위 안이란 8k 버킷(상태 6,553–7,618 토큰, 즉 학습 길이)과의 CUAD 정확도 차이가, 같은 계약·반복·질문에서 짝지어졌을 때 95 % 하한이 최소 −3 pp이고 모든 레코드가 답변되었음을 뜻합니다. 16k 버킷이 실패하면 검증된 길이는 8,192 토큰입니다.

명목 상태 길이별 CUAD 정확도, ECE, 그리고 8k 버킷과의 짝지은 차이(longdoc-v1 개발):

배포된 T = 2.41에서의 ECE. Δ는 두 길이에서 같은 계약에 대해 물은 445–447개 질문에서 짝지어집니다. 4k 버킷은 다른 계약을 담고 있어 규칙의 기준이 아닙니다. 출처: runs/r28-readout/context.json(라운드 28의 등록된 판독 결과, runs/r28-4b-r10-longdoc).

캘리브레이션(기대 캘리브레이션 오류, ECE, 배포된 T = 2.41에서; 낮을수록 좋음):

배포된 온도는 학습 코퍼스의 홀드아웃 항목에서 적합되었는데, 프로젝트 규칙은 이제 새 릴리스에 이를 허용하지 않습니다. 홀드아웃 데이터셋의 648개 질문(transfer-r3의 캘리브레이션 분할, 여덟 소스, 그리고 200개 MMLU-Pro 질문)에 대한 등록된 재적합은 T = 2.30(90 % bootstrap 구간 [2.05, 2.52])을 줍니다. 감사된 breadth-v1 및 tasksource-heldout-v1 개발 질문 4,468개에서 그것은 배포된 값을 개선하지 못합니다: Brier는 둘 다 0.368이고 차이는 −0.0001 [−0.0005, +0.0003]이며, ECE는 0.025 대 0.024입니다. 규칙은 0보다 낮은 Brier 구간과 더 낮은 ECE를 요구했으므로 T = 2.41이 유지됩니다. 답은 T에 의존하지 않습니다.

기타 결과.

서빙. CUDA, 융합 커널과 CUDA graphs를 쓴 bf16; 새 상태 / 반복 상태에 대한 요청당 모델 시간(20회 중앙값):

상주 GPU 메모리는 14.3 GB입니다. 서빙되는 확률은 280개 질문에서 fp32 평가 경로와 0.017 이내로 유지되며, 바뀐 답은 없습니다. fp32 평가 경로(H100)에서 16k / 32k / 64k 토큰의 상태는 3.0 / 6.8 / 17.2 s가 걸리고, 가중치 위로 4.3 / 8.6 / 17.2 GiB를 차지합니다.

Apple Silicon (MLX, bf16, 32 GB M5; 질문 3개, 그중 하나는 60 % 깊이에 심어 둔 사실에 관한 것; 상태는 1,024-토큰 청크로 prefill됨):

60개 짧은 상태 질문에서 MLX 경로는 fp32 평가 경로와 0.018 이내이며, 바뀐 답은 없습니다.

¹ 감사된 패널에서 제외됨: breadth-v1 데이터셋 네 개(routerbench, 그 상태가 물은 정보를 결여함; cfcolor와 humicroedit, 모든 시스템에서 우연 수준; chessbench, 모든 시스템에서 하한); 레이블이 유효하지 않거나 복구 불가능한 tasksource-heldout-v1 패밀리 일곱 개(이름 비공개); 상태가 레이블을 결정하지 못하는 devtools-v1 태스크 두 개(flakeflagger, commit 변경 유형).

² 커뮤니티 Decision Index 0.2의 우연 보정 지수: 데이터셋마다 (score − chance) / (1 − chance), 각 영역 안에서 평균한 뒤, 100 × 다섯 영역의 평균. Jev의 지수는 같은 테스트 항목을 별도로 한 번 읽은 데서 나온 것입니다.

한계와 트레이드오프

• 가장 큰 이득은 분포 내에 있습니다. hard-v1, devtools-v1, documents-v1의 학습 분할이 학습 데이터에 들어 있고, hard-v1 테스트 항목은 학습된 생성기의 새 템플릿입니다. 홀드아웃 데이터셋에서는 breadth-v1 지수에서 Jev에 16점 뒤처지며, 분포 외 점검인 JevBench 공개 hard 등급에서는 기술 단계의 이득이 hard-v1에서의 약 3분의 1입니다(+9.0 pp [+2.7, +15.3], 항목 111개).
• 일부 devtools-v1 레이블은 대리(proxy)입니다. 학습 전에는 점수를 매긴 모든 모델(Jev 포함)이 CodeReviewer와 FlakeFlagger에서 거의 우연 수준이었고, 그 소스들로 학습한 뒤에는 개발에서 0.633과 0.693에 도달합니다. 이는 결정 자체가 아니라 레이블링 휴리스틱을 학습한 것일 수 있습니다.
• 지식은 베이스가 정합니다. MMLU-Pro는 0.565로 Jev의 0.840에 대비됩니다.
• 날짜 산술이 가장 약한 패밀리입니다: deadline 정책 질문에서 0.65로 Jev의 0.95에 대비됩니다. KEV_DATE_FACTS=1 전처리기가 도움이 됩니다(이것이 파생된 더 이른 체크포인트에서는 0.60 → 0.85). 이 체크포인트에서는 다시 측정하지 않았습니다.
• 캘리브레이션은 하나의 분포 내 온도입니다. 홀드아웃 데이터셋에서는 잘 캘리브레이션되어 있고(breadth-v1 테스트 ECE 0.029), 학습된 기술 및 문서 패밀리에서는 덜합니다(ECE 0.084–0.101). 단일 온도는 신뢰도의 순서를 바꿀 수 없습니다. 도메인 외에서 ≤ 5 % 오류의 커버리지는 개발에서 0.620으로 Jev의 0.70에 대비됩니다.
• 학습되지 않은 길이. 학습 상태는 최대 7,552 토큰이었습니다. 더 긴 상태는 65,536 토큰까지 서빙됩니다. 정확도가 얼마나 유지되는지는 위의 검증된 컨텍스트 길이입니다.
• 선택지 순서가 답을 바꿀 수 있습니다. 질문 격리는 이를 막지 못합니다.

편향, 위험 및 윤리적 고려사항

• 캘리브레이션된 확률은 부당한 신뢰를 낳을 수 있습니다. 온도는 학습 분포의 개발 행에서 적합되었으며 모든 워크로드로 전이되지 않습니다. 임계값을 설정하기 전에, 자신의 데이터에서 레이블된 표본으로 정확도와 캘리브레이션을 측정하고, 그곳에서 온도를 재적합하십시오(python -m kev.calibrate).
• 정확도와 캘리브레이션은 도메인이 바뀌면 이동합니다. 위의 숫자에 의존하기보다 프로덕션 오류율을 모니터링하십시오.
• 사람에 관한 중대한 자동 결정을 사람의 검토 없이 내리는 데 사용하지 마십시오. 베이스 모델과 학습 데이터(다른 모델이 생성한 레이블 포함)의 편향은 측정되지 않았습니다.
• 상태에는 개인정보나 기밀 데이터가 포함될 수 있습니다. 셀프 호스팅은 입력을 자신의 하드웨어에 둡니다. KEV_API_KEY를 설정하지 않으면 서버는 열려 있으므로, 자체 접근 제어와 데이터 처리 정책을 적용하십시오.

컴퓨트

• 베이스 레시피: NVIDIA H100 한 장에서 약 56분(피크 24.6 GB). 날짜 단계: H100 한 장에서 9분.
• 문서 단계: NVIDIA H200 한 장에서 43분. 기술 단계: H200 한 장에서 1.4시간(피크 47.7 GB).
• 평가 및 서빙 점검: Modal의 단일 H100 / H200 / L40S GPU; MLX 측정은 Apple M5에서.

출처와 재현성

• 코드, 스위트, 평가 보고서: github.com/jaredpalmer/kev. 릴리스 숫자: runs/release/kev-4b-r10.json(scripts/release_numbers.py --release kev-4b-r10), 잠긴 판독 runs/locked/kev-4b-r10-ungated/, 2026-09-30 패밀리 판독 runs/fam-4b-breadth/, runs/fam-4b-breadthtest/, runs/fam-4b-docs1test/ 및 runs/fam-breadth-test-report/, 캘리브레이션 재적합 runs/r28-readout/round28.json, 서빙 runs/serve-4b-l40s/, runs/grouping-4b-h100/, runs/long-state-4b-h100/, runs/mlx-long-states/, runs/mlx-full-4b/.
• 단계: 베이스 트라이얼 q35-4b-s23/00-trial-0(tag v7-base); 날짜 night2-4b-du/00-trial-0(tag night2-du-release); 문서 라운드 8 r8-small/00-trial-0(tag r8-documents-release); 기술 라운드 10 r10-skills/00-trial-0(experiments/round10/skills.json, 규칙 experiments/rounds/r10.json). 캘리브레이션 재적합: 라운드 28 arm 4b-r10(experiments/rounds/r28.json).
• 공개 가중치: Hub revision 139fdd94; 어댑터 sha256 90e81735…, head.pt sha256 dd633435…(T = 2.4061).
• 릴리스 이력: 2026-09-24에 라운드 10의 확정 후보로 공개되었고, Kev 1.0에 변경 없이 포함되었습니다. 이것이 어떻게 선정되었는지에 대한 기록 — 이후 건전하지 않다고 폐기된 스위트(scienthoon, WANLI-v2, TypeSafe) 포함 — 은 Hub revision 139fdd94의 README와 git tag research-archive-2026-09-24의 PLAN.md입니다.

인용

@misc{palmer2026kev4b,
  title        = {Kev-4B: a calibrated decision model on Qwen3.5-4B},
  author       = {Palmer, Jared},
  year         = {2026},
  howpublished = {\url{https://huggingface.co/jaredpalmer/kev-4b}},
  note         = {Kev 1.0}
}

연락처

질문과 이슈: github.com/jaredpalmer/kev/issues.