Kev 1.0

Kev 1.0은 Kev 패밀리 전체의 첫 버전 릴리스입니다. 문서 하나와 타입이 지정된 질문 묶음을 읽고, 한 번의 포워드 패스로 선택지에 대한 캘리브레이션된 확률을 돌려주는 네 가지 의사결정 모델이며, TypeSafe의 System One API 뒤에 있습니다. 새로 학습한 것은 없습니다. 다음 세대 Kev를 비교하는 기준이 되는 체크포인트, 모델 카드, 평가 스위트와 서빙 코드를 고정하며, 모든 Hub 저장소에 같은 태그(v1.0)를 붙입니다.

1.0에 담긴 것

대표 수치(fp32 평가 경로, 각 모델을 배포된 온도로 평가, transfer-v4 테스트는 잠겨 있고 모델마다 한 번 읽었습니다):

hard-v1, devtools-v1과 documents-v1에는 모든 Kev가 학습한 학습 분할이 있습니다. 그 행들은 학습된 버킷의 홀드아웃 항목을 측정한 것이지 전이(transfer)가 아닙니다. breadth-v1과 transfer-v4 행은 어떤 Kev도 학습하지 않은 데이터셋입니다. Jev는 개발 파티션과 breadth-v1 테스트에서만 읽었습니다. 모든 수치는 docs/claims.json을 거쳐 커밋된 리포트로 추적되며, 모델 카드(docs/model-cards/)에 구간과 함께 나머지가 있습니다.

지난 패밀리 릴리스 이후 바뀐 점

현재 패밀리를 위해 2026-09-24에 처음 조립한 GitHub 릴리스 kev-family(Kev-27B v1, Kev-9B v1, 그리고 여기와 같은 Kev-4B와 Kev-0.8B)를 기준으로 측정했습니다. 2026-09-30의 업데이트(Kev-27B v2, Kev-9B v2)도 여기 나열합니다. 1.0에서 그것들이 버전 릴리스의 일부가 되기 때문입니다.

• Kev-27B v2: 전체 가중치. Qwen3.8-27B의 모든 가중치를 145,840건 코퍼스에서 한 에포크 파인튜닝한 뒤, v1과 0.85 / 0.15로 평균했습니다. 테스트에서 v1 대비: 홀드아웃 데이터셋 +1.2 pp [+0.3, +2.2], 홀드아웃 태스크 버킷 +5.3 [+3.7, +6.8], 스킬·도구·문서 +8.9 [+7.5, +10.3]; 잠긴 도메인 외 테스트 0.889 대 0.896, Brier 0.154 대 0.160. 긴 계약에서는 더 나쁘고 과신합니다(CUAD ECE 0.053 대 0.007). v1은 jaredpalmer/kev-27b@v1-lora에 있습니다.
• Kev-9B v2. v1에 Kev-4B와 Kev-0.8B가 이미 가진 문서·스킬 데이터를 한 에포크 더한 것입니다. 테스트에서 v1 대비: hard-v1 + devtools-v1 +18.7 pp [+16.7, +20.8], documents-v1 +7.1 [+4.7, +9.2]; 잠긴 도메인 외 테스트에서는 같은 수준(둘 다 0.852)이며 Brier는 0.199 대 0.224. v1은 jaredpalmer/kev-9b@v1에 있습니다.
• 조용한 잘림 없음. 서버는 예전에 한도보다 긴 state를 아무 말 없이 잘랐습니다. 이제는 65,536 토큰을 넘는 state를 토큰 수와 한도를 밝히는 422로 거부합니다. KEV_TRUNCATE_STATES=1을 주면 잘림으로 되돌아가고, 그런 서버의 모든 응답에는 truncated가 붙습니다. deploy와 fine-tune 스킬은 이 수정과 아래의 긴 문서·MLX 변경을 담은 커밋으로 KEV_REF를 고정했고(71d4829), Space는 수정 이후 다시 게시했습니다.
• 모든 크기에서 긴 문서. 평가 경로가 긴 행에 대해 수학 커널에서 fp32 어텐션을 유지해서, Kev-0.8B, 4B, 9B는 32k–64k 토큰 state에서 GPU 메모리가 바닥났습니다. 이제 긴 행은 메모리 효율 커널을 fp32로 실행합니다. Kev-4B는 H100에서 가중치 위로 17.2 GiB를 쓰며 61k 토큰 state를 17.2초에 읽고, 더 짧은 행은 로짓을 비트 단위로 그대로 유지합니다. 위의 검증된 컨텍스트 길이를 측정할 수 있게 된 이유가 이것입니다.
• Apple Silicon. MLX 백엔드는 저장된 그대로 전체 가중치 체크포인트를 병합 없이 로드하므로, Kev-27B에도 Mac 경로가 생겼습니다(약 51 GB에 작업 메모리를 더한 정도가 필요할 것으로 예상, 그 크기에서 아직 실행하지 않음). 긴 state는 1,024 토큰씩 prefill되고 캐시는 패스 전에 비웁니다. 그래서 Kev-4B는 32 GB M5에서 13.0 GB 피크로 65,000 토큰 state를 서빙합니다(신규 84.5초, 캐시 716 ms).
• 커널 출처. 이제 모든 평가 리포트와 트라이얼은 로짓이 의존하는 커널 집합을 기록합니다(패키지 버전, GPU, dtype, 어텐션과 DeltaNet 구현). 평가 이미지의 커널 변경이 Kev 자체 코드 변경 없이 Kev-27B v1의 읽기를 확률 0.03–0.06만큼 움직인다는 사실이 드러난 뒤였습니다.
• 평가 감사. 세 스위트가 모델 선택에 부적합하다고 판단되어 제거되었습니다: scienthoon(템플릿 티켓, 텍스트가 답할 수 없는 질문 하나), WANLI-v2 / WANLI-v1(금 레이블의 4분의 1이 서로 불일치하는 두 주석자 중 하나), 그리고 TypeSafe의 공개 평가(금이 두 폐쇄 모델에서 나왔고 질문이 너무 적음). 대표 패널은 감사에서 답할 수 없거나 레이블이 없는 항목을 제외합니다. 그 스위트에 대한 과거 릴리스의 수치는 기록에는 남아 있지만 1.0 카드에는 없습니다.
• 캘리브레이션. Kev-4B와 Kev-0.8B는 학습 데이터의 홀드아웃 항목으로 적합한 온도를 배포합니다. 홀드아웃 데이터셋에 대한 등록된 재적합을 둘 다 평가했으나 어느 쪽에도 채택하지 않았습니다: Kev-4B를 개선하지 못했고(Brier 차이 −0.0001 [−0.0005, +0.0003]), Kev-0.8B는 문서·스킬 버킷에서 등록 허용치보다 더 나쁘게 캘리브레이션되었습니다. Kev-9B와 Kev-27B는 이미 홀드아웃 데이터셋 온도를 배포합니다.
• 학습 데이터 공개. documents-v1과 hard-v1의 학습 파티션이 jaredpalmer/kev-suites 데이터셋에 있어, 작은 모델들의 학습 데이터를 내려받아 해시 검증할 수 있습니다.
• 검증된 컨텍스트 길이. 이제 각 카드는 CUAD 계약에 대한 정확도가 8k 토큰에서의 같은 모델 대비 3 pp(95 % 하한) 이내로 유지되는 가장 긴 state를 밝힙니다. Kev-27B는 서빙 한도인 65,536 토큰까지 유지합니다(64k 하한은 −2.4 pp). Kev-0.8B, 4B, 9B는 학습한 8,192만 검증합니다: 셋 다 16k에서 이미 허용치를 벗어나므로(하한 −8.5, −3.4, −3.7 pp), 8k 토큰을 넘으면 긴 문서에 대한 그들의 답은 측정으로 보증되지 않습니다.
• 정식 모델 카드. 네 카드가 하나의 구조를 따릅니다: 요약, 세부 사항, 의도된 용도와 범위 밖 용도, 사용 방법, 학습 데이터와 절차, 평가, 한계, 위험, 컴퓨트, 출처.

알려진 한계

• 분포 내 이득. 지난 한 해의 큰 이득은 학습 분할이 학습 데이터에 들어 있는 스위트에서 나왔습니다. 어떤 Kev도 학습하지 않은 데이터셋에서는 Kev-27B가 breadth-v1 테스트에서 Jev보다 지수 1.7점 낮고, 더 작은 크기들은 13–31점 낮습니다.
• 학습하지 않은 길이. Kev-0.8B, 4B, 9B는 최대 7,552 토큰 state로, Kev-27B는 최대 32,768로 학습했습니다. 서버는 65,536을 받습니다. 서빙 한도가 아니라 검증된 컨텍스트 길이를 사용하십시오.
• 긴 계약에서 Kev-27B는 v1보다 정확도가 낮고 과신합니다(CUAD 테스트 ECE 0.053 대 0.007). 자신의 문서로 온도를 재적합하거나 계약 검토에는 @v1-lora를 사용하십시오.
• Kev-0.8B와 도구 라우팅. 문서·스킬 단계 후에 When2Call 정확도가 우연 수준 아래로 떨어졌습니다(테스트 0.133). 도구 호출 라우팅에 쓰지 마십시오.
• 날짜 산술은 27B 아래 모든 크기에서 가장 약한 버킷입니다(deadline 정책 정확도 0.35 / 0.65 / 0.725 대 Jev의 0.95). KEV_DATE_FACTS=1이 도움이 됩니다.
• 지식은 베이스가 정합니다(MMLU-Pro 0.230–0.675 대 Jev의 0.840).
• Mac에서의 Kev-9B는 측정되지 않았고, Mac에서의 Kev-27B는 96–128 GB에 들어갈 것으로 예상하지만 실행해 본 적은 없습니다.
• 선택. Kev-27B v2와 Kev-9B v2는 이전 개발 읽기를 알고 있는 상태에서 감사된 규칙으로 다시 선택했습니다. 그 테스트 마진은 낙관적입니다.
• 모델당 하나의 온도는 신뢰도의 순서를 바꿀 수 없으므로, 5 % 오류 예산에서 이 모델들은 도메인 외에서 Jev보다 자동화하는 결정이 적습니다.

실행 방법

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@v1.0 --port 8009    # CUDA, or MLX on Apple Silicon

릴리스 tarball에서:

shasum -a 256 -c SHA256SUMS.txt
tar -xzf kev-4b.tar.gz
uv run --extra serve python -m kev.serve --run kev-4b --port 8009

TypeSafe SDK는 그대로 동작합니다: TypeSafeClient(api_key="local", base_url="http://127.0.0.1:8009", model="kev-latest"). Kev-27B는 B200, H200 또는 H100 80 GB 하나가 필요합니다: --run jaredpalmer/kev-27b@v1.0. Modal에 HTTPS 엔드포인트를 배포하려면 skills/kev-deploy를 참고하십시오.

자산

각 tarball은 가중치 revision 시점에 Hub에 있는 그대로의 체크포인트 하나를 담습니다(LoRA 어댑터, 온도가 든 head.pt, tokenizer 파일, 학습 트라이얼의 result.json, provenance.json, training_config.json, training_metrics.json과 로그), Kev 1.0 모델 카드를 README.md로, 잠긴 transfer-v4 읽기를 locked_test.json으로 담습니다. 이것들은 scripts/build_release_assets.py가 docs/releases/kev-1.0-assets.json에서 만들어 내며, 다시 빌드해도 같은 바이트가 나옵니다. 그 안의 모든 파일은 2026-10-01 00:00 UTC로 날짜가 찍혀 있고, kev.serve는 이를 압축을 푼 체크포인트의 릴리스 날짜로 보고합니다. 2026-10-01에 처음 첨부한 tarball은 파일 날짜가 1970-01-01이라 kev.serve가 1969-12-31을 보고했습니다. 그것들은 같은 날 이 tarball로 교체되었습니다. 가중치와 다른 모든 파일은 바이트 단위로 동일하고, tarball 해시만 바뀌었습니다.

Kev-27B는 첨부되지 않았습니다. 51 GB의 가중치가 GitHub의 자산당 2 GB 한도를 넘기 때문입니다. Hub에서 내려받으십시오: jaredpalmer/kev-27b@v1.0 (가중치 커밋 28be62e9, head.pt 7968f17b…).

모든 Hub 저장소에서 v1.0 태그는 Kev 1.0 카드를 업로드한 커밋을 가리킵니다. 그 커밋은 README.md만 바꿨으므로, 가중치는 첫 표의 가중치 revision과 같은 바이트입니다: kev-0.8b bf75a6a8, kev-4b 6cfce5c2, kev-9b db029f08, kev-27b af0e6d55.

릴리스 계획(메인테이너용; 공개 노트에는 포함되지 않음)

2026-10-01 완료(기록 runs/release/kev-1.0.json, PLAN.md “Released: Kev 1.0”). 3단계와 4단계: 카드만 바꾸는 커밋, 각 카드 커밋에 v1.0(0.8B bf75a6a8, 4B 6cfce5c2, 9B db029f08, 27B af0e6d55; 다른 모든 파일은 그대로). 5단계와 6단계: 자산을 두 번 빌드해 해시가 동일함을 확인하고, 릴리스를 게시하고 Latest로 표시. 7단계: kev-family는 유지하되 자산을 제거하고, 본문은 kev-1.0을 가리키게 하고, 옛 노트는 runs/release/kev-family-notes-retired.md에 두었습니다. 8단계: 핀 변경 없음. 9단계: 컬렉션과 Space 확인, Space는 다시 게시하지 않았습니다. 릴리스 전에 작성한 계획은 다음과 같습니다. 순서:

1. 자리표시자: 채움(2026-10-01) — round 28의 등록된 컨텍스트 읽기, runs/r28-readout/context.json(runs/r28-{4b-r10,08b-r15}-longdoc, runs/r29-9b-r18a-longdoc, runs/r23-27b-k-w85-longdoc에 대한 scripts/longdoc_report.py --context-margin -0.03; 원본 runs/r28-context, 배포된 T에서의 ECE runs/r28-context-served)에서 가져왔고, 수치는 docs/claims.json에 있습니다.

2. 병합 이 PR.

3. Hub 카드. 각 1.0 카드를 README.md로만 업로드합니다(가중치 없음): 카드만 바꾸는 커밋에는 kev.publish가 필요 없습니다; hf upload jaredpalmer/kev-<size> docs/model-cards/kev-<size>.md README.md --commit-message "Kev 1.0 model card (weights unchanged)". HfApi().model_info(..., files_metadata=True)로 adapter_model.safetensors / head.pt(27B: model.safetensors.index.json과 모든 샤드)가 아래와 같이 해시되는지 확인하십시오.

4. Hub 태그. 네 저장소 모두에 v1.0. 기본(명시된 대로): 정확한 가중치 revision; 3단계를 먼저 실행했다면 카드 커밋에 태그해서 @v1.0이 1.0 카드를 보여주게 하십시오(가중치는 바이트 단위로 동일, 두 커밋 모두 PLAN.md에 기록).

   저장소	v1.0 대상(가중치)	어댑터 / 헤드 sha256
   jaredpalmer/kev-0.8b	9a45d25eb2ab761841196625383fa1dff0e56c1e	9b908623… / f400bd12…
   jaredpalmer/kev-4b	139fdd94f1b6a6ad80cc15e08fcb99cac885a101	90e81735… / dd633435…
   jaredpalmer/kev-9b	b5d8c18e44c60888d138b65cb6507ff0a5a448a0	2b2a70cf… / 8e1dab2c…
   jaredpalmer/kev-27b	main (오늘 ef78cc8a34d5f426fb229c52089db189218cfe5c: 가중치 28be62e9, 이후 카드만 바꾸는 세 커밋)	가중치 d27af6ab… / 헤드 7968f17b…

   hf repos tag create jaredpalmer/kev-0.8b v1.0 --revision 9a45d25eb2ab761841196625383fa1dff0e56c1e -m "Kev 1.0"
   hf repos tag create jaredpalmer/kev-4b   v1.0 --revision 139fdd94f1b6a6ad80cc15e08fcb99cac885a101 -m "Kev 1.0"
   hf repos tag create jaredpalmer/kev-9b   v1.0 --revision b5d8c18e44c60888d138b65cb6507ff0a5a448a0 -m "Kev 1.0"
   hf repos tag create jaredpalmer/kev-27b  v1.0 --revision <main at release> -m "Kev 1.0"

5. 자산. uv run python scripts/build_release_assets.py --release docs/releases/kev-1.0-assets.json --out /tmp/kev-1.0-assets가 kev-0.8b.tar.gz, kev-4b.tar.gz, kev-9b.tar.gz를 빌드합니다(각각: 위 revision의 Hub 스냅숏, 즉 어댑터, 온도가 든 head.pt, tokenizer 파일, 트라이얼의 result.json, provenance.json, training_config.json과 training_metrics.json; 1.0 카드를 README.md로; 잠긴 읽기를 locked_test.json으로), SHA256SUMS.txt와 manifest.json(각 멤버의 sha256)도 만듭니다. 어댑터나 헤드 해시가 스펙과 다른 다운로드는 거부합니다. Kev-27B는 자산이 아닙니다(51 GB, GitHub은 자산을 2 GB로 제한): 노트가 Hub를 가리킵니다.

6. GitHub 릴리스. 병합 커밋에 kev-1.0 태그를 붙이고, 이 노트의 공개 부분(이 절 위의 전부)을 본문으로 하는 초안 릴리스를 만들고, tarball 세 개와 SHA256SUMS.txt를 첨부하고, 다시 내려받아 shasum -a 256 -c SHA256SUMS.txt로 확인하고, 하나를 풀어 서빙한 뒤 게시하고 Latest로 표시합니다.

7. 크기당 릴리스 하나. 릴리스 정책은 각 크기의 최선 버전만 GitHub 릴리스에 둡니다. kev-1.0이 게시되면 kev-family는 중복이 됩니다: tarball 세 개와 SHA256SUMS.txt를 지우고 본문을 kev-1.0을 가리키는 포인터로 바꾸십시오(또는 릴리스를 삭제, Jared의 결정). 이전 버전은 각 카드에 나열된 Hub 태그로 남습니다.

8. 배포 핀. skills/kev-deploy와 skills/kev-finetune는 KEV_REF 71d4829를 고정합니다; 1.0 체크포인트에는 더 새로운 코드가 필요 없습니다. 이후의 서빙 수정을 1.0과 함께 배포해야 할 때만 핀을 옮기십시오.

9. 컬렉션과 Space. Kev 컬렉션은 이미 네 저장소를 나열합니다. Space는 main에서 Kev-4B와 Kev-0.8B를 서빙하며, 그것이 1.0 가중치입니다; 마지막 게시 이후 kev/model.py, kev/api.py 또는 kev/checkpoint.py가 바뀌지 않았다면 다시 게시할 것이 없습니다.