Kev 1.0

Kev 1.0 ist die erste versionierte Veröffentlichung der gesamten Kev-Familie: vier Entscheidungsmodelle, die ein Dokument und eine Menge typisierter Fragen lesen und kalibrierte Wahrscheinlichkeiten über die Optionen zurückgeben, in einem einzigen Vorwärtspass, hinter der System One API von TypeSafe. Nichts darin ist neu trainiert. Es fixiert die Checkpoints, Modellkarten, Evaluations-Suites und den Serving-Code, gegen die die nächste Generation von Kev gemessen wird, mit demselben Tag (v1.0) auf jedem Hub-Repo.

Was in 1.0 enthalten ist

Schlagzeilenzahlen (fp32-Evaluationspfad, jedes Modell bei seiner ausgelieferten Temperatur; der transfer-v4-Test ist gesperrt und wurde einmal pro Modell gelesen):

hard-v1, devtools-v1 und documents-v1 haben Trainings-Splits, auf denen jedes Kev trainiert wurde: Diese Zeilen messen zurückgehaltene Items trainierter Familien, nicht Transfer. Die Zeilen breadth-v1 und transfer-v4 sind Datensätze, auf denen kein Kev trainiert wurde. Jev wurde nur auf den Development-Partitionen und auf dem breadth-v1-Test gelesen. Jede Zahl lässt sich über docs/claims.json auf einen committeten Bericht zurückführen; die Modellkarten (docs/model-cards/) enthalten den Rest, mit Intervallen.

Was sich seit der letzten Familienveröffentlichung geändert hat

Gemessen ab der GitHub-Release kev-family, wie sie für die aktuelle Familie am 2026-09-24 erstmals zusammengestellt wurde (Kev-27B v1, Kev-9B v1 und dieselben Kev-4B und Kev-0.8B wie hier). Ihre Aktualisierungen vom 2026-09-30 (Kev-27B v2, Kev-9B v2) sind hier ebenfalls aufgeführt, da 1.0 der Punkt ist, an dem sie Teil einer versionierten Veröffentlichung werden.

• Kev-27B v2: vollständige Gewichte. Jedes Gewicht von Qwen3.8-27B eine Epoche lang auf einem Korpus mit 145,840 Datensätzen feinabgestimmt, dann 0.85 / 0.15 mit v1 gemittelt. Gegen v1 im Test: zurückgehaltene Datensätze +1.2 pp [+0.3, +2.2], zurückgehaltene Aufgabenfamilien +5.3 [+3.7, +6.8], Skills, Tooling und Dokumente +8.9 [+7.5, +10.3]; gesperrter Out-of-Domain-Test 0.889 gegenüber 0.896, Brier 0.154 gegenüber 0.160. Schlechter und überkonfident auf langen Verträgen (CUAD ECE 0.053 gegenüber 0.007). v1 liegt bei jaredpalmer/kev-27b@v1-lora.
• Kev-9B v2. v1 plus eine Epoche auf den Dokument- und Skill-Daten, die Kev-4B und Kev-0.8B bereits hatten. Gegen v1 im Test: hard-v1 + devtools-v1 +18.7 pp [+16.7, +20.8], documents-v1 +7.1 [+4.7, +9.2]; gleiches Niveau auf dem gesperrten Out-of-Domain-Test (0.852 beide) mit Brier 0.199 gegenüber 0.224. v1 liegt bei jaredpalmer/kev-9b@v1.
• Keine stille Kürzung. Der Server kürzte früher einen Zustand, der länger als sein Limit war, ohne es zu sagen. Er lehnt jetzt einen Zustand über 65,536 Token mit einem 422 ab, der die Token-Anzahl und das Limit nennt; KEV_TRUNCATE_STATES=1 schaltet zurück zur Kürzung, und jede Antwort eines solchen Servers sagt dann truncated. Die Deploy- und Fine-Tune-Skills pinnen KEV_REF auf einen Commit mit diesem Fix und den untenstehenden Langdokument- und MLX-Änderungen (71d4829), und der Space wurde nach dem Fix neu veröffentlicht.
• Lange Dokumente in jeder Größe. Der Evaluationspfad behielt fp32-Attention für lange Zeilen auf dem Mathe-Kernel, sodass Kev-0.8B, 4B und 9B bei Zuständen von 32k–64k Token der GPU-Speicher ausging. Lange Zeilen laufen jetzt mit dem speichereffizienten Kernel in fp32: Kev-4B liest einen 61k-Token-Zustand in 17.2 s mit 17.2 GiB über den Gewichten auf einer H100, und kürzere Zeilen behalten ihre Logits Bit für Bit. Das macht die oben validierten Kontextlängen messbar.
• Apple Silicon. Das MLX-Backend lädt Full-Weight-Checkpoints so, wie sie gespeichert sind, ohne Merge, was Kev-27B einen Mac-Pfad gibt (erwartet etwa 51 GB plus Arbeitsspeicher; in dieser Größe noch nicht ausgeführt). Lange Zustände werden in 1,024-Token-Schritten vorbefüllt, und der Cache wird vor einem Pass geleert, sodass Kev-4B einen 65,000-Token-Zustand auf einem 32-GB-M5 bei einem Peak von 13.0 GB bedient (84.5 s neu, 716 ms gecacht).
• Kernel-Herkunft. Jeder Evaluationsbericht und jeder Versuch erfasst jetzt das Kernel-Set, von dem seine Logits abhängen (Paketversionen, GPU, dtype, Attention- und DeltaNet-Implementierungen), nachdem festgestellt wurde, dass eine Kernel-Änderung im Evaluations-Image die Reads von Kev-27B v1 um 0.03–0.06 in der Wahrscheinlichkeit verschob, ohne Änderung an Kevs eigenem Code.
• Evaluations-Audit. Drei Suites wurden als untauglich für die Modellauswahl entfernt: scienthoon (Template-Tickets, eine Frage, die der Text nicht beantworten kann), WANLI-v2 / WANLI-v1 (ein Viertel der Gold-Labels stammt von einem von zwei uneinigen Annotatoren) und TypeSafes öffentliche Evals (Gold aus zwei geschlossenen Modellen, zu wenige Fragen). Die Headline-Panels schließen Items aus, die das Audit als unbeantwortbar oder unbeschriftet befand. Die Zahlen früherer Releases auf diesen Suites bleiben in ihren Aufzeichnungen, nicht auf den 1.0-Karten.
• Kalibrierung. Kev-4B und Kev-0.8B liefern Temperaturen aus, die auf zurückgehaltenen Items ihrer Trainingsdaten gefittet wurden. Ein registrierter Refit auf zurückgehaltenen Datensätzen wurde für beide evaluiert und für keinen übernommen: Er verbesserte Kev-4B nicht (Brier-Differenz −0.0001 [−0.0005, +0.0003]) und machte Kev-0.8B auf seinen Dokument- und Skill-Familien um mehr als die registrierte Toleranz schlechter kalibriert. Kev-9B und Kev-27B liefern bereits Temperaturen aus zurückgehaltenen Datensätzen aus.
• Trainingsdaten veröffentlicht. Die Trainings-Partitionen von documents-v1 und hard-v1 liegen im Datensatz jaredpalmer/kev-suites, sodass die Trainingsdaten der kleinen Modelle abgerufen und hash-geprüft werden können.
• Validierte Kontextlänge. Jede Karte nennt jetzt den längsten Zustand, bei dem die Genauigkeit auf CUAD-Verträgen an der 95-%-Untergrenze im Rahmen von 3 pp desselben Modells bei 8k Token bleibt. Kev-27B hält das 65,536-Token-Limit, das Serving-Limit (seine 64k-Untergrenze ist −2.4 pp). Kev-0.8B, 4B und 9B validieren nur ihre trainierten 8,192: Jedes verfehlt die Toleranz bereits bei 16k (Untergrenzen −8.5, −3.4 und −3.7 pp), daher sind ihre Antworten auf langen Dokumenten jenseits von 8k Token nicht durch die Messung abgedeckt.
• Formale Modellkarten. Alle vier Karten folgen einer Struktur: Zusammenfassung, Details, beabsichtigte und außerhalb des Umfangs liegende Verwendungen, Verwendung, Trainingsdaten und -verfahren, Evaluation, Grenzen, Risiken, Compute, Herkunft.

Bekannte Grenzen

• In-Distributions-Zugewinne. Die großen Zugewinne des letzten Jahres liegen auf Suites, deren Trainings-Splits in den Trainingsdaten enthalten sind. Auf Datensätzen, auf denen kein Kev trainiert wurde, liegt Kev-27B 1.7 Indexpunkte unter Jev auf dem breadth-v1-Test, und die kleineren Größen liegen 13–31 Punkte darunter.
• Untrainerte Längen. Kev-0.8B, 4B und 9B wurden auf Zuständen von höchstens 7,552 Token trainiert und Kev-27B auf höchstens 32,768; der Server akzeptiert 65,536. Verwende die validierte Kontextlänge, nicht das Serving-Limit.
• Kev-27B auf langen Verträgen ist weniger genau als v1 und überkonfident (CUAD-Test ECE 0.053 gegenüber 0.007); fitte die Temperatur auf deinen eigenen Dokumenten neu oder verwende @v1-lora für Vertragsprüfung.
• Kev-0.8B und Tool-Routing. Seine When2Call-Genauigkeit fiel nach seiner Dokument-und-Skills-Stufe unter den Zufall (0.133 im Test); verwende es nicht für Tool-Call-Routing.
• Datumsarithmetik ist bei jeder Größe unter 27B die schwächste Familie (deadline-Policy-Genauigkeit 0.35 / 0.65 / 0.725 gegenüber Jevs 0.95); KEV_DATE_FACTS=1 hilft.
• Wissen wird von der Basis bestimmt (MMLU-Pro 0.230–0.675 gegenüber Jevs 0.840).
• Kev-9B auf einem Mac wurde nicht gemessen, und Kev-27B auf einem Mac sollte laut Erwartung in 96–128 GB passen, wurde aber nicht ausgeführt.
• Auswahl. Kev-27B v2 und Kev-9B v2 wurden unter der auditierten Regel neu ausgewählt, wobei frühere Development-Reads bekannt waren; ihre Test-Margen sind optimistisch.
• Eine Temperatur pro Modell kann Konfidenzen nicht umsortieren, daher automatisieren die Modelle bei einem 5-%-Fehlerbudget außerhalb der Domäne weniger Entscheidungen als Jev.

Wie man es ausführt

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

Aus einem Release-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

Das TypeSafe-SDK funktioniert unverändert: TypeSafeClient(api_key="local", base_url="http://127.0.0.1:8009", model="kev-latest"). Kev-27B braucht eine B200, H200 oder H100 80 GB: --run jaredpalmer/kev-27b@v1.0. Um einen HTTPS-Endpunkt auf Modal bereitzustellen, siehe skills/kev-deploy.

Assets

Jeder Tarball enthält einen Checkpoint so, wie er auf dem Hub zu seiner Gewichte-Revision vorliegt (LoRA-Adapter, head.pt mit der Temperatur, Tokenizer-Dateien, das result.json des Trainingsversuchs, provenance.json, training_config.json, training_metrics.json und Log), die Kev-1.0-Modellkarte als README.md und den gesperrten transfer-v4-Read als locked_test.json. Sie werden von scripts/build_release_assets.py aus docs/releases/kev-1.0-assets.json gebaut, und ein erneuter Build liefert dieselben Bytes. Jede Datei darin ist auf 2026-10-01 00:00 UTC datiert, was kev.serve als das Release-Datum eines entpackten Checkpoints meldet. Die am 2026-10-01 erstmals angehängten Tarballs datierten ihre Dateien auf 1970-01-01, sodass kev.serve 1969-12-31 meldete; sie wurden noch am selben Tag durch diese ersetzt. Die Gewichte und jede andere Datei sind byte-identisch; nur die Tarball-Hashes änderten sich.

Kev-27B ist nicht angehängt, weil seine 51 GB Gewichte das Limit von GitHub von 2 GB pro Asset überschreiten. Lade es vom Hub herunter: jaredpalmer/kev-27b@v1.0 (Gewichte-Commit 28be62e9, head.pt 7968f17b…).

Auf jedem Hub-Repo zeigt das Tag v1.0 auf den Commit, der die Kev-1.0-Karte hochgeladen hat. Dieser Commit änderte nur README.md, sodass seine Gewichte dieselben Bytes sind wie die Gewichte-Revision in der ersten Tabelle: kev-0.8b bf75a6a8, kev-4b 6cfce5c2, kev-9b db029f08, kev-27b af0e6d55.

Release-Plan (für den Maintainer; nicht Teil der veröffentlichten Notes)

Erledigt 2026-10-01 (Aufzeichnung runs/release/kev-1.0.json; PLAN.md „Released: Kev 1.0”). Schritte 3 und 4: reine Karten-Commits, mit v1.0 auf jedem Karten-Commit (0.8B bf75a6a8, 4B 6cfce5c2, 9B db029f08, 27B af0e6d55; jede andere Datei unverändert). Schritte 5 und 6: Assets zweimal mit identischen Hashes gebaut, die Release veröffentlicht und als Latest markiert. Schritt 7: kev-family beibehalten, seine Assets entfernt, sein Body ein Verweis auf kev-1.0, seine alten Notes in runs/release/kev-family-notes-retired.md. Schritt 8: Pins unverändert. Schritt 9: Collection und Space geprüft; der Space wurde nicht neu veröffentlicht. Der Plan, wie er vor der Veröffentlichung geschrieben wurde, folgt. Reihenfolge:

1. Platzhalter: gefüllt (2026-10-01) aus dem registrierten Kontext-Read-out von Runde 28, runs/r28-readout/context.json (scripts/longdoc_report.py --context-margin -0.03 über runs/r28-{4b-r10,08b-r15}-longdoc, runs/r29-9b-r18a-longdoc und runs/r23-27b-k-w85-longdoc; roh runs/r28-context, ECE beim ausgelieferten T runs/r28-context-served), mit den Zahlen in docs/claims.json.

2. Merge diesen PR.

3. Hub-Karten. Lade jede 1.0-Karte nur als README.md hoch (keine Gewichte): Für einen reinen Karten-Commit ist kev.publish nicht nötig; hf upload jaredpalmer/kev-<size> docs/model-cards/kev-<size>.md README.md --commit-message "Kev 1.0 model card (weights unchanged)". Prüfe mit HfApi().model_info(..., files_metadata=True), dass adapter_model.safetensors / head.pt (27B: model.safetensors.index.json und jeder Shard) wie unten hashen.

4. Hub-Tags. v1.0 auf allen vier Repos. Standard (wie festgelegt): die exakten Gewichte-Revisionen; wenn Schritt 3 zuerst lief, tagge stattdessen den Karten-Commit, damit @v1.0 die 1.0-Karte zeigt (die Gewichte sind byte-identisch; erfasse beide Commits in PLAN.md).

   Repo	v1.0-Ziel (Gewichte)	Adapter / Head sha256
   jaredpalmer/kev-0.8b	9a45d25eb2ab761841196625383fa1dff0e56c1e	9b908623… / f400bd12…
   jaredpalmer/kev-4b	139fdd94f1b6a6ad80cc15e08fcb99cac885a101	90e81735… / dd633435…
   jaredpalmer/kev-9b	b5d8c18e44c60888d138b65cb6507ff0a5a448a0	2b2a70cf… / 8e1dab2c…
   jaredpalmer/kev-27b	main (heute ef78cc8a34d5f426fb229c52089db189218cfe5c: Gewichte 28be62e9, dann drei reine Karten-Commits)	Gewichte d27af6ab… / Head 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. Assets. uv run python scripts/build_release_assets.py --release docs/releases/kev-1.0-assets.json --out /tmp/kev-1.0-assets baut kev-0.8b.tar.gz, kev-4b.tar.gz, kev-9b.tar.gz (je: der Hub-Snapshot bei der obigen Revision, d. h. Adapter, head.pt mit der Temperatur, Tokenizer-Dateien, das result.json des Versuchs, provenance.json, training_config.json und training_metrics.json; die 1.0-Karte als README.md; den gesperrten Read als locked_test.json), SHA256SUMS.txt und manifest.json (sha256 jedes Mitglieds). Es lehnt einen Download ab, dessen Adapter- oder Head-Hash von der Spec abweicht. Kev-27B ist kein Asset (51 GB; GitHub begrenzt ein Asset auf 2 GB): Die Notes verweisen auf den Hub.

6. GitHub-Release. Tagge kev-1.0 auf dem Merge-Commit; erstelle die Release als Draft mit dem veröffentlichten Teil dieser Notes als Body (alles oberhalb dieses Abschnitts), hänge die drei Tarballs und SHA256SUMS.txt an, lade sie herunter, shasum -a 256 -c SHA256SUMS.txt, entpacke eine und bediene sie, dann veröffentliche und markiere sie als Latest.

7. Ein Release pro Größe. Die Release-Politik behält nur die beste Version jeder Größe in einer GitHub-Release. Sobald kev-1.0 veröffentlicht ist, dupliziert kev-family sie: Lösche seine drei Tarballs und SHA256SUMS.txt und ersetze seinen Body durch einen Verweis auf kev-1.0 (oder lösche die Release; Jareds Entscheidung). Frühere Versionen bleiben auf den Hub-Tags, die in jeder Karte aufgeführt sind.

8. Deploy-Pins. skills/kev-deploy und skills/kev-finetune pinnen KEV_REF 71d4829; die 1.0-Checkpoints brauchen keinen neueren Code. Verschiebe den Pin nur, wenn ein späterer Serving-Fix mit 1.0 ausgeliefert werden soll.

9. Collection und Space. Die Kev-Collection listet bereits die vier Repos. Der Space bedient Kev-4B und Kev-0.8B von main, das die 1.0-Gewichte ist; nichts neu zu veröffentlichen, es sei denn, kev/model.py, kev/api.py oder kev/checkpoint.py haben sich nach seiner letzten Veröffentlichung geändert.