Kev-9B

Modellzusammenfassung

Kev-9B ist ein Entscheidungsmodell. Es liest ein Dokument (den Zustand) und eine Menge typisierter Fragen darüber und gibt eine kalibrierte Wahrscheinlichkeitsverteilung über die mit jeder Frage gelieferten Optionen zurück, in einem einzigen Vorwärtspass und ohne Text zu erzeugen. Es ist für Entwickler gedacht, die Dokumente klassifizieren, routen, triagieren oder prüfen und Wahrscheinlichkeiten brauchen, die sich als Schwellenwert nutzen lassen, etwa um unsichere Fälle zur menschlichen Prüfung zu schicken. Es implementiert die öffentliche System One API von TypeSafe (POST /v1/systemone), sodass das TypeSafe-SDK unverändert damit funktioniert. Es ist ein LoRA-Adapter und ein Pointer-Head auf Qwen3.5-9B-Base und passt auf eine GPU der 24-GB-Klasse. Diese Karte beschreibt Version 2, veröffentlicht am 2026-09-30 und in Kev 1.0 enthalten.

Modelldetails

Eingabe. Ein Zustand (Text oder ein JSON-Objekt oder -Array, als beschrifteter Text gerendert) und beliebig viele benannte Fragen, jede von einem von drei Typen:

Jede Frage wird als ihre eigene Zeile beantwortet, die vom geteilten Zustand fortfährt, sodass Fragen sich nicht gegenseitig beeinflussen können; der Zustand wird einmal berechnet und gecacht.

Beabsichtigte Verwendungen

• Typisierte Entscheidungen über Dokumente von einigen tausend Token: Klassifikation, Routing, Triage, Extraktionsentscheidungen, Policy- und Berechtigungsprüfungen und Beurteilung einer vorgeschlagenen Antwort gegen angegebene Kriterien.
• Workflows, die auf Konfidenz reagieren: die sicheren Fälle automatisieren und den Rest in die Warteschlange stellen, mit Schwellenwerten, die an einer beschrifteten Stichprobe der eigenen Arbeitslast des Nutzers fixiert werden.
• Ein selbst gehosteter Drop-in-Ersatz für einen System-One-Endpunkt auf einer einzelnen GPU der 24-GB-Klasse und ein Startpunkt für Feinabstimmung auf den eigenen Labels des Nutzers (kev.train --init_from jaredpalmer/kev-9b).

Verwendungen außerhalb des Umfangs

• Textgenerierung, Chat, Zusammenfassung oder offene Fragebeantwortung. Das Modell bewertet nur die Optionen, die ihm gegeben werden.
• Vollautomatische Entscheidungen mit rechtlichen, medizinischen, finanziellen, beschäftigungsbezogenen oder ähnlichen Folgen für Menschen, ohne menschliche Prüfung.
• Fragen, deren Antwort von Fakten abhängt, die nicht im Zustand und kein Allgemeinwissen sind, und wissensintensive Prüfungen (siehe Grenzen).
• Datumsarithmetik mit Tagesgenauigkeit ohne den KEV_DATE_FACTS=1-Präprozessor, Zustände länger als 65,536 Token und andere Sprachen als Englisch.

Verwendung

Bediene es mit dem Kev-Repo. Unter CUDA läuft es in bf16 mit fusionierten DeltaNet-Kernels und CUDA-Graphen (eine L40S oder H100; etwa 22 GB resident); auf Apple Silicon bedient derselbe Befehl es über MLX, automatisch gewählt.

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-9b --port 8008          # v2, Kev 1.0 (this card)
uv run --extra serve python -m kev.serve --run jaredpalmer/kev-9b@v1 --port 8008       # v1

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)

Die kalibrierte Temperatur wird standardmäßig angewandt; KEV_TEMPERATURE=1.0 gibt die rohen Wahrscheinlichkeiten zurück. KEV_DTYPE=fp32 wählt den exakten Pfad, der zur Evaluation verwendet wird. KEV_DATE_FACTS=1 hängt die Anzahl der Tage zwischen jedem im Zustand gefundenen Datumspaar an, was zu nutzen das Modell trainiert wurde. Ein Zustand über 65,536 Token wird mit einem 422 abgelehnt, der seine Token-Anzahl nennt.

Trainingsdaten

Die beiden Feinabstimmungsstufen wiederholen 2,000 und 10,000 Datensätze aus decision-v7. Es wurde keine Ausgabe von Jev (TypeSafes gehostetem Entscheidungsmodell) verwendet. CodeReviewer und FlakeFlagger stammen von Zenodo; die CFPB-Erzählungen sind Werke der US-Regierung; Lizenzen und Revisionen pro Quelle sind in den Suite-Manifesten festgehalten. Die rein zur Evaluation dienenden Suites unten (breadth-v1, tasksource-heldout-v1, transfer-v4, longdoc-v1 sowie die When2Call- und Prompt-Injection-Quellen von devtools-v1) gehen nie ins Training ein.

Trainingsverfahren

1. Basisrezept. Zwei Epochen auf decision-v7 von der Basis: LoRA-Rang 16, α 32; Lernrate 5e-5, One-Cycle-Zeitplan; effektiver Batch 8 (4 × 2 Akkumulation); bf16-Autocast, Gradient Checkpointing. Der Verlust ist Cross-Entropy über die Optionen jeder Frage. Die Optionsreihenfolge wird gemischt, “none of the above”-Optionen und Distraktoren werden zufällig eingefügt, und ein Viertel der Choice-Datensätze ergibt zusätzlich ein Minimalpaar (die Frage mit einer “none of the above”-Option, einmal mit vorhandener richtiger Option und einmal mit entfernter).
2. Daten und fehlende Evidenz. Eine Epoche von Stufe 1 bei Lernrate 2e-5 mit 2,000 wiederholten Datensätzen. Das ist v1.
3. Dokumente und Skills. Eine Epoche von v1 auf allen drei Trainingssets zusammen bei Lernrate 2e-5 mit 10,000 wiederholten Datensätzen; Batch 2 × 4 Akkumulation; Zustände von höchstens 7,552 Token; Seed 1; 3,318 Optimizer-Schritte.
4. Kalibrierung. Eine einzige Temperatur, T = 2.19, die die negative Log-Likelihood auf 648 Fragen aus zurückgehaltenen Datensätzen minimiert: 448 aus dem Kalibrierungs-Split von transfer-r3 (sechs öffentliche Datensätze, QNLI, SciQ, TweetEval-offensive, PAWS, MMLU und Emotion, plus zwei zurückgehaltene Familien generierter Policy-Datensätze) und 200 MMLU-Pro-Fragen (transfer-v9-Development). Der Pool wurde vor dem Fit gegen die Trainings-Suites des Checkpoints geprüft.

Evaluation

Methodik. Jeder Vergleich erfolgt gegen Kev-9B v1 auf identischen Items, jedes Modell bei seiner eigenen bedienten Temperatur (v1: 2.30). Die Vergleiche und ihre Messlatten wurden vor den Bestätigungs-Reads registriert; Test-Partitionen wurden einmal für diesen Checkpoint gelesen; der transfer-v4-Test ist gesperrt (einmal pro Kandidat gelesen). Gepaarte Intervalle sind 95-%-Bootstraps, die ganze Datensätze neu ziehen (2,000 Resamples), sodass Fragen, die sich einen Zustand teilen, sich gemeinsam bewegen. Differenzen sind in Prozentpunkten (pp). Jev (TypeSafes gehostetes Modell, über Vercel AI Gateway abgefragt) wird gezeigt, wo es auf denselben Items gelesen wurde. Die Suites:

• breadth-v1: 14 zurückgehaltene öffentliche Datensätze in fünf Bereichen (Wissen, Sprache, Retrieval, Tools, Kunst), nie trainiert.
• transfer-v4: Out-of-Domain-Entscheidungen aus sechs nie trainierten öffentlichen Quellen plus zurückgehaltene Policy- und Regelstrukturen.
• transfer-r3: ein Kurzzustands-Panel aus denselben acht zurückgehaltenen Quellen wie der Kalibrierungspool.
• hard-v1: die obigen Skill-Familien; der Test-Split hält Templates trainierter Generatoren zurück.
• devtools-v1: Entwickler-Tooling-Entscheidungen aus sechs lizenzgeprüften Quellen (vier trainiert, zwei nur zur Evaluation).
• documents-v1 / documents-v2: CFPB-Beschwerdeerzählungen; v2 ist ein privates zurückgehaltenes Test-Set.
• longdoc-v1: CUAD-Handelsverträge und generierte Vereinbarungsbündel, mit Zuständen von 4k bis 64k Token.

devtools-v1-Headline-Panels schließen zwei Aufgaben aus, deren Labels der Zustand nicht bestimmt (flakeflagger, Commit-Änderungstyp); dieselben Zeilen verlassen beide Seiten.

Ergebnisse gegen v1 (registrierte Bestätigung).

Zurückgehaltene Daten (nie trainiert).

Gegen v1 beträgt die breadth-v1-Genauigkeitsdifferenz +0.3 [−0.7, +1.3] im Development und +0.6 [−0.4, +1.6] im Test. tasksource-heldout-v1-Development wurde für diesen Checkpoint gelesen, sein Read-out ist aber nicht abgeschlossen; es wird hier nicht berichtet.

Trainierte Familien (zurückgehaltene Items und Templates).

Testdifferenzen gegen v1: hard-v1 +25.0 [+22.0, +28.1], devtools-v1 (alle Quellen) +15.4 [+11.0, +19.4], documents-v2 +8.0 [+5.9, +10.2].

Lange Dokumente.

• Validierte Kontextlänge: 8,192 Token, die trainierte Länge. Der 16k-Bucket liegt außerhalb der Toleranz: Seine Untergrenze ist −3.7 pp, unter −3 pp, daher ist keine längere Länge validiert.
• Regel, vor dem Read festgelegt: Die validierte Länge ist die nominelle Größe des größten Buckets ab 16,384 Token aufwärts, sodass er und jeder Bucket zwischen ihm und 8,192 innerhalb der Toleranz liegt. Innerhalb der Toleranz bedeutet, dass die CUAD-Genauigkeitsdifferenz zum 8k-Bucket (Zustände von 6,553–7,618 Token, die trainierte Länge), gepaart auf demselben Vertrag, Repeat und derselben Frage, eine 95-%-Untergrenze von mindestens −3 pp hat und jeder Datensatz beantwortet wurde. Wenn der 16k-Bucket scheitert, ist die validierte Länge 8,192 Token.

CUAD-Genauigkeit, ECE und die gepaarte Differenz zum 8k-Bucket nach nomineller Zustandslänge (longdoc-v1-Development):

ECE bei der ausgelieferten T = 2.19. Δ ist gepaart auf den 445–447 Fragen, die zu denselben Verträgen in beiden Längen gestellt wurden. Der 4k-Bucket enthält andere Verträge und ist keine Referenz für die Regel. Quelle: runs/r28-readout/context.json (registriertes Read-out von Runde 28, runs/r29-9b-r18a-longdoc).

Kalibrierung (erwarteter Kalibrierungsfehler, ECE, wie bedient; niedriger ist besser):

Das 90-%-Bootstrap-Intervall der Temperatur ist [2.05, 2.41]. v1s 2.30 wurde auf Development-Zeilen seiner eigenen Trainingsverteilung gefittet; v2 ist das erste 9B, das bei einer auf zurückgehaltenen Datensätzen gefitteten Temperatur bedient wird.

Weitere Ergebnisse.

Serving. CUDA, bf16 mit fusionierten Kernels und CUDA-Graphen; Modellzeit pro Anfrage (Median aus 20) für einen neuen / wiederholten Zustand, gemessen an v1 (dieselbe Architektur und Adapterform):

Der residente GPU-Speicher beträgt 21.9 GB. Bediente Wahrscheinlichkeiten bleiben auf 280 Fragen innerhalb von 0.017 des fp32-Evaluationspfads, mit keinen geänderten Antworten. Auf dem fp32-Evaluationspfad (H100, v2) brauchen Zustände von 16k / 32k / 64k Token 5.1 / 10.9 / 25.4 s und 4.6 / 9.1 / 18.2 GiB über den Gewichten.

Apple Silicon (MLX): Die für Kev-0.8B und Kev-4B gemachten Langzustands-Messungen wurden in dieser Größe nicht gemacht; auf dem für sie verwendeten 32-GB-M5 passten das 19.3-GB-bf16-Backbone und sein Arbeitsset nicht in den verfügbaren Speicher.

¹ Der zufallskorrigierte Index des Community Decision Index 0.2: pro Datensatz (Score − Zufall) / (1 − Zufall), gemittelt innerhalb jedes Bereichs, dann 100 × der Mittelwert der fünf Bereiche. Jevs Index stammt aus einem separaten Read derselben Test-Items.

Grenzen und Kompromisse

• Auswahl. Dieser Checkpoint wurde in einer früheren Runde auf Development-Daten trainiert und gelesen und unter einer späteren Regel neu ausgewählt, wobei diese Zahlen bekannt waren. Die Test-Partitionen und der gesperrte Read, jeweils einmal für ihn gelesen, sind der Schutz; behandle die Development-Margen als optimistisch.
• Seine großen Zugewinne liegen in der Verteilung. Die Trainings-Splits von hard-v1, devtools-v1 und documents-v1 sind in seinen Trainingsdaten; diese Zugewinne sind zurückgehaltene Items und Templates trainierter Familien, kein Transfer auf neue Aufgaben.
• Er ist bei neuer Arbeit nicht besser als v1. breadth-v1-Test +0.6 pp [−0.4, +1.6], transfer-v4-Development −0.2 pp [−2.4, +1.8], transfer-r3-Test +0.0 pp [−1.2, +1.2]. Kev-27B liegt 11 Punkte vor ihm beim breadth-v1-Index, Jev 13.
• Wissen wird von der Basis bestimmt. MMLU-Pro liegt bei 0.590, gegenüber Kev-27Bs 0.675 und Jevs 0.840.
• Datumsarithmetik ist seine schwächste Familie: 0.725 bei den deadline-Policy-Fragen gegenüber Jevs 0.95; der KEV_DATE_FACTS=1-Präprozessor hilft.
• Kalibrierung. devtools-v1 ist seine am schlechtesten kalibrierte Suite (Test-ECE 0.098). Das Intervall der Temperatur ist [2.05, 2.41]. Die Temperatur wurde mit aufgezeichnetem Grund in head.pt aus dem registrierten Pool-Fit geschrieben, weil das Kalibrierungsskript die Quellen der kombinierten Trainingsdatei nicht auflisten kann, um den Pool selbst zu prüfen; die eigene Prüfung der Runde hatte ihn abgedeckt. Diese Prüfung deckt nicht die Daten- und Fehlende-Evidenz-Daten von v1 ab, deren Manifest keine Quellen auflistet; diese Datensätze sind vier generierte Familien, keine davon im Pool.
• Untrainierte Längen. Trainingszustände waren höchstens 7,552 Token. Längere Zustände werden bis zu 65,536 Token bedient; wie weit die Genauigkeit hält, ist die obige validierte Kontextlänge.
• Die Optionsreihenfolge kann eine Antwort ändern; die Fragenisolation verhindert das nicht.

Bias, Risiken und ethische Überlegungen

• Kalibrierte Wahrscheinlichkeiten können unberechtigtes Vertrauen erzeugen. Die Temperatur wurde auf öffentlichen zurückgehaltenen Datensätzen gefittet und überträgt sich nicht auf jede Arbeitslast; miss Genauigkeit und Kalibrierung an einer beschrifteten Stichprobe deiner eigenen Daten und fitte die Temperatur dort neu (python -m kev.calibrate), bevor du Schwellenwerte setzt.
• Genauigkeit und Kalibrierung verschieben sich bei Domänenwechsel. Überwache die Produktionsfehlerraten, statt dich auf die obigen Zahlen zu verlassen.
• Verwende es nicht für folgenreiche automatisierte Entscheidungen über Menschen ohne menschliche Prüfung. Verzerrungen des Basismodells und der Trainingsdaten (einschließlich von anderen Modellen erzeugter Labels) werden nicht gemessen.
• Zustände können persönliche oder vertrauliche Daten enthalten. Self-Hosting hält Eingaben auf deiner eigenen Hardware; der Server ist offen, sofern KEV_API_KEY nicht gesetzt ist, also wende deine eigene Zugriffskontrolle und Datenbehandlungspolitik an.

Compute

• Basisrezept und Datumsstufe (v1): einzelne NVIDIA-H100-GPUs.
• Dokument- und Skill-Stufe: 2.6 Stunden auf einer NVIDIA H200 (Peak 74.1 GB).
• Evaluations- und Serving-Prüfungen: einzelne H100-/H200-/L40S-GPUs auf Modal.

Herkunft und Reproduzierbarkeit

• Code, Suites und Evaluationsberichte: github.com/jaredpalmer/kev. Release-Zahlen: runs/release/kev-9b-r27.json (scripts/release_numbers.py --release kev-9b-r27); registrierte Regel und Verdicts experiments/rounds/r27.json, runs/r27-readout/, runs/r27-verdict/; die Familien-Reads vom 2026-09-30 runs/fam-9bnew-breadth/, runs/fam-9b-breadth/ und runs/fam-breadth-test-report/; ood-v2 runs/r29-9b-r18a-ood/; Serving runs/serve-9b-l40s/, runs/serve-9b-h100/, runs/long-state-9b-h100/.
• Stufen: Basisversuch q35-9b/01-trial-1 (Tag v7-base); Daten night2-9b-du/00-trial-0 (v1, Tag v1); Dokumente und Skills Runde 18 Arm (a) r18-9b/00-trial-0 (experiments/round18/joint.json), ausgewählt und bestätigt als 9b-r18a von Runde 27.
• Veröffentlichte Gewichte: Hub-Commit b5d8c18e; Adapter sha256 2b2a70cf4ef4440b6c22899e1f72c2f8ea5c6f65b19aa344539b4b8971d1f13d, head.pt sha256 8e1dab2c… (T = 2.1936).
• Verifikation: anonym vom Hub geladen, reproduzierte es die Antworten der Vorab-Evaluation auf 252 von 252 SemIf-Zeilen und 764 von 764 transfer-v4-Development-Zeilen bei T = 2.19 (runs/rel9-public/).

Zitat

@misc{palmer2026kev9b,
  title        = {Kev-9B: a calibrated decision model on Qwen3.5-9B},
  author       = {Palmer, Jared},
  year         = {2026},
  howpublished = {\url{https://huggingface.co/jaredpalmer/kev-9b}},
  note         = {Version 2, released 2026-09-30; Kev 1.0}
}

Kontakt

Fragen und Issues: github.com/jaredpalmer/kev/issues.