Kev-4B

Modellzusammenfassung

Kev-4B 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-4B-Base, klein genug für eine 24-GB-GPU oder einen 32-GB-Apple-Silicon-Mac. Diese Karte beschreibt den Checkpoint in Kev 1.0, erstmals veröffentlicht am 2026-09-24.

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 bescheidener Hardware und ein Startpunkt für Feinabstimmung auf den eigenen Labels des Nutzers (kev.train --init_from jaredpalmer/kev-4b).

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, H100 oder jede GPU mit etwa 16 GB frei); 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-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)

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

Jede Feinabstimmungsstufe nach der ersten wiederholt Datensätze aus decision-v7 (2,000, 2,000 und 4,000). 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; Seed 2. 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.
3. Echte Dokumente. Eine Epoche von Stufe 2 auf documents-v1-Train bei Lernrate 2e-5 mit 2,000 wiederholten Datensätzen; Batch 2 × 4 Akkumulation; Zustände von höchstens 7,552 Token.
4. Skills. Eine Epoche von Stufe 3 auf hard-v1 und devtools-v1-Train zusammen bei Lernrate 2e-5 mit 4,000 wiederholten Datensätzen; Batch 2 × 4 Akkumulation; Zustände von höchstens 7,552 Token; Seed 1; 1,915 Optimizer-Schritte.
5. Kalibrierung. Eine einzige Temperatur, T = 2.41, die die negative Log-Likelihood auf den decision-v7-Development-Zeilen des Stufe-4-Versuchs minimiert (1,264 Fragen). Das sind zurückgehaltene Items eines Trainingskorpus. Ein Refit auf zurückgehaltenen Datensätzen wurde evaluiert und nicht übernommen (siehe Kalibrierung).

Evaluation

Methodik. Jede Zahl ist der fp32-Evaluationspfad bei der ausgelieferten Temperatur, sofern nicht anders angegeben. Development-Partitionen wurden zur Auswahl verwendet; Test-Partitionen wurden einmal für diesen Checkpoint gelesen; der transfer-v4-Test ist gesperrt (einmal pro Kandidat gelesen) und wurde gegen eine im Voraus festgelegte Messlatte beurteilt. 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.
• tasksource-heldout-v1: 24 ganze Aufgabenfamilien einer öffentlichen Multi-Task-Sammlung, nie trainiert (Familiennamen privat).
• transfer-v4: Out-of-Domain-Entscheidungen aus sechs nie trainierten öffentlichen Quellen (QNLI, SciQ, TweetEval-offensive, PAWS, MMLU, Emotion) plus zurückgehaltene Policy- und Regelstrukturen.
• 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.

Mit “audited” markierte Headline-Panels schließen Items aus, die ein Label-Audit als untauglich befand¹; jeder Ausschluss entfernt dieselben Zeilen von beiden Seiten eines Vergleichs.

Zurückgehaltene Daten (nie trainiert).

Trainierte Familien (zurückgehaltene Items und Templates).

Jevs devtools-v1-Zahl gilt über alle 1,074 Development-Fragen; Kevs Zeilen lassen eine CodeReviewer-ID weg, die der Builder der Suite für zwei Datensätze wiederverwendet hat (2 Fragen).

Gegen die vorherige Version (der Checkpoint der Dokument-Stufe, Tag r8-documents-release, bei seiner eigenen Temperatur 2.96; registrierte Kriterien, jeder Test einmal gelesen):

Lange Dokumente.

• Validierte Kontextlänge: 8,192 Token, die trainierte Länge. Der 16k-Bucket liegt außerhalb der Toleranz: Seine Untergrenze ist −3.4 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.41. Δ 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/r28-4b-r10-longdoc).

Kalibrierung (erwarteter Kalibrierungsfehler, ECE, bei der ausgelieferten T = 2.41; niedriger ist besser):

Die ausgelieferte Temperatur wurde auf zurückgehaltenen Items eines Trainingskorpus gefittet, was die Regeln des Projekts für ein neues Release nicht mehr erlauben. Ein registrierter Refit auf 648 Fragen aus zurückgehaltenen Datensätzen (der Kalibrierungs-Split von transfer-r3, acht Quellen, und 200 MMLU-Pro-Fragen) ergibt T = 2.30 (90-%-Bootstrap-Intervall [2.05, 2.52]). Auf den 4,468 auditierten Development-Fragen von breadth-v1 und tasksource-heldout-v1 verbessert er den ausgelieferten Wert nicht: Brier 0.368 bei beiden, eine Differenz von −0.0001 [−0.0005, +0.0003], und ECE 0.025 gegenüber 0.024. Die Regel verlangte ein Brier-Intervall unter null und einen niedrigeren ECE, daher bleibt T = 2.41. Die Antworten hängen nicht von T ab.

Weitere Ergebnisse.

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

Der residente GPU-Speicher beträgt 14.3 GB. Bediente Wahrscheinlichkeiten bleiben auf 280 Fragen innerhalb von 0.017 des fp32-Evaluationspfads, mit keinen geänderten Antworten. Auf dem fp32-Evaluationspfad (H100) brauchen Zustände von 16k / 32k / 64k Token 3.0 / 6.8 / 17.2 s und 4.3 / 8.6 / 17.2 GiB über den Gewichten.

Apple Silicon (MLX, bf16, M5 mit 32 GB; drei Fragen, eine zu einem in 60 % Tiefe eingepflanzten Fakt; der Zustand wird in 1,024-Token-Stücken vorbefüllt):

Bei 60 Kurzzustands-Fragen liegt der MLX-Pfad innerhalb von 0.018 des fp32-Evaluationspfads, mit keinen geänderten Antworten.

¹ Von den auditierten Panels ausgeschlossen: vier breadth-v1-Datensätze (routerbench, dessen Zustände die erfragte Information nicht enthalten; cfcolor und humicroedit, bei jedem System auf Zufallsniveau; chessbench, bei jedem System am Boden); sieben tasksource-heldout-v1-Familien mit ungültigen oder nicht wiederherstellbaren Labels (Namen privat); zwei devtools-v1-Aufgaben, deren Labels der Zustand nicht bestimmt (flakeflagger, Commit-Änderungstyp).

² 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

• Seine größten Zugewinne liegen in der Verteilung. Die Trainings-Splits von hard-v1, devtools-v1 und documents-v1 sind in seinen Trainingsdaten, und ein hard-v1-Test-Item ist ein neues Template eines trainierten Generators. Auf zurückgehaltenen Datensätzen liegt es 16 Punkte hinter Jev beim breadth-v1-Index, und bei JevBenchs öffentlichem Hard-Tier, einer Out-of-Distribution-Prüfung, gewann die Skill-Stufe etwa ein Drittel so viel wie auf hard-v1 (+9.0 pp [+2.7, +15.3] über 111 Items).
• Einige devtools-v1-Labels sind Proxys. Vor dem Training lag jedes bewertete Modell, auch Jev, nahe dem Zufall bei CodeReviewer und FlakeFlagger; nach dem Training auf diesen Quellen erreicht es 0.633 und 0.693 im Development, was eher die erlernte Beschriftungsheuristik als die Entscheidung sein könnte.
• Wissen wird von der Basis bestimmt. MMLU-Pro liegt bei 0.565 gegenüber Jevs 0.840.
• Datumsarithmetik ist seine schwächste Familie: 0.65 bei den deadline-Policy-Fragen gegenüber Jevs 0.95. Der KEV_DATE_FACTS=1-Präprozessor hilft (beim früheren Checkpoint, von dem er abstammt, 0.60 → 0.85); er wurde für diesen Checkpoint nicht neu gemessen.
• Die Kalibrierung ist eine In-Distributions-Temperatur. Sie ist gut kalibriert auf zurückgehaltenen Datensätzen (breadth-v1-Test ECE 0.029), weniger auf den trainierten Skill- und Dokument-Familien (ECE 0.084–0.101), und eine einzelne Temperatur kann Konfidenzen nicht umsortieren: Die Abdeckung bei ≤ 5 % Fehler außerhalb der Domäne ist 0.620 im Development gegenüber Jevs 0.70.
• 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 Development-Zeilen der Trainingsverteilung 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: etwa 56 Minuten auf einer NVIDIA H100 (Peak 24.6 GB). Datumsstufe: 9 Minuten auf einer H100.
• Dokument-Stufe: 43 Minuten auf einer NVIDIA H200. Skill-Stufe: 1.4 Stunden auf einer H200 (Peak 47.7 GB).
• Evaluations- und Serving-Prüfungen: einzelne H100-/H200-/L40S-GPUs auf Modal; MLX-Messungen auf einem Apple M5.

Herkunft und Reproduzierbarkeit

• Code, Suites und Evaluationsberichte: github.com/jaredpalmer/kev. Release-Zahlen: runs/release/kev-4b-r10.json (scripts/release_numbers.py --release kev-4b-r10), der gesperrte Read runs/locked/kev-4b-r10-ungated/, die Familien-Reads vom 2026-09-30 runs/fam-4b-breadth/, runs/fam-4b-breadthtest/, runs/fam-4b-docs1test/ und runs/fam-breadth-test-report/, der Kalibrierungs-Refit runs/r28-readout/round28.json, Serving runs/serve-4b-l40s/, runs/grouping-4b-h100/, runs/long-state-4b-h100/, runs/mlx-long-states/, runs/mlx-full-4b/.
• Stufen: Basisversuch q35-4b-s23/00-trial-0 (Tag v7-base); Daten night2-4b-du/00-trial-0 (Tag night2-du-release); Dokumente Runde 8 r8-small/00-trial-0 (Tag r8-documents-release); Skills Runde 10 r10-skills/00-trial-0 (experiments/round10/skills.json, Regel experiments/rounds/r10.json). Kalibrierungs-Refit: Runde 28 Arm 4b-r10 (experiments/rounds/r28.json).
• Veröffentlichte Gewichte: Hub-Revision 139fdd94; Adapter sha256 90e81735…, head.pt sha256 dd633435… (T = 2.4061).
• Release-Historie: veröffentlicht am 2026-09-24 als bestätigter Kandidat von Runde 10; unverändert in Kev 1.0 enthalten. Die Aufzeichnung, wie er ausgewählt wurde, einschließlich inzwischen als untauglich zurückgezogener Suites (scienthoon, WANLI-v2, TypeSafe), ist die README bei Hub-Revision 139fdd94 und PLAN.md am Git-Tag research-archive-2026-09-24.

Zitat

@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}
}

Kontakt

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