Kev-0.8B

Modellzusammenfassung

Kev-0.8B 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 implementiert die öffentliche System One API von TypeSafe (POST /v1/systemone), sodass das TypeSafe-SDK unverändert damit funktioniert. Es ist der kleinste Kev: ein LoRA-Adapter und ein Pointer-Head auf Qwen3.5-0.8B-Base, der auf einem Laptop oder einer 4-GB-GPU läuft. Es ist dort gedacht, wo Speicher oder Kosten die größeren Größen ausschließen und die Aufgabe dem ähnelt, worauf es trainiert wurde; außerhalb der Domäne ist es deutlich weniger genau als Kev-4B. 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 nahe an ihren Trainingsfamilien (Dokumentklassifikation, Routing, Policy-Prüfungen über angegebene Regeln) auf Hardware, die zu klein für Kev-4B ist: ein Laptop, eine L4 oder eine 4-GB-GPU.
• Ein Startpunkt für Feinabstimmung auf den eigenen Labels des Nutzers, wo Trainingskosten zählen (kev.train --init_from jaredpalmer/kev-0.8b).
• Prototyping gegen die System One API, bevor zu einem größeren Kev gewechselt wird.

Verwendungen außerhalb des Umfangs

• Textgenerierung, Chat, Zusammenfassung oder offene Fragebeantwortung. Das Modell bewertet nur die Optionen, die ihm gegeben werden.
• Tool-Call-Routing (ob ein Tool aufgerufen, ein fehlender Parameter erfragt oder abgelehnt werden soll): Seine When2Call-Genauigkeit liegt unter dem Zufall (siehe Grenzen).
• Vollautomatische Entscheidungen mit rechtlichen, medizinischen, finanziellen, beschäftigungsbezogenen oder ähnlichen Folgen für Menschen, ohne menschliche Prüfung.
• Wissensintensive Fragen, Datumsarithmetik, 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 L4 reicht); 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-0.8b --port 8008        # Kev 1.0 (this card)
uv run --extra serve python -m kev.serve --run jaredpalmer/kev-0.8b@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. Ein Zustand über 65,536 Token wird mit einem 422 abgelehnt, der seine Token-Anzahl nennt.

Trainingsdaten

Die beiden Feinabstimmungsstufen wiederholen 2,000 und 6,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 1e-4, One-Cycle-Zeitplan; Batch 8; bf16-Autocast; 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 4e-5 mit 2,000 wiederholten Datensätzen.
3. Dokumente und Skills. Eine Epoche von Stufe 2 auf allen drei Trainingssets zusammen bei Lernrate 2e-5 mit 6,000 wiederholten Datensätzen; Batch 4 × 2 Akkumulation; Zustände von höchstens 7,552 Token; Gradient Checkpointing; Seed 1; 2,818 Optimizer-Schritte.
4. Kalibrierung. Eine einzige Temperatur, T = 2.35, die die negative Log-Likelihood auf den decision-v7-Development-Zeilen des Stufe-3-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 (Tag night2-du-release, bei ihrer eigenen Temperatur 2.41; 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 −8.5 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.35. Δ 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-08b-r15-longdoc).

Kalibrierung (erwarteter Kalibrierungsfehler, ECE, bei der ausgelieferten T = 2.35; 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.52 (90-%-Bootstrap-Intervall [2.19, 2.83]). Auf den 4,468 auditierten Development-Fragen von breadth-v1 und tasksource-heldout-v1 ist er besser kalibriert: ECE 0.037 gegenüber 0.048, Brier um 0.0020 [0.0014, 0.0025] niedriger. Auf den trainierten Familien ist er schlechter, jeweils um mehr als die registrierte Toleranz von 0.005: hard-v1 ECE 0.124 gegenüber 0.112, devtools-v1 (auditiert) 0.099 gegenüber 0.092, documents-v1 0.078 gegenüber 0.059. Der Refit qualifizierte sich daher nicht, und T = 2.35 bleibt. Nutzer, deren Arbeitslast eher zurückgehaltenen öffentlichen Datensätzen als Kevs Trainingsfamilien ähnelt, können es beim Refit-Wert mit KEV_TEMPERATURE=2.52 bedienen; die Antworten hängen nicht von T ab.

Weitere Ergebnisse.

Serving. CUDA, bf16 mit fusionierten Kernels und CUDA-Graphen, auf einer L4; Modellzeit pro Anfrage (Median aus 20) für einen neuen / wiederholten Zustand: 22.7 / 16.1 ms für sechs Fragen zu einem kurzen Zustand, 108.6 / 32.3 ms für fünf Fragen zu einem 2,200-Token-Zustand; 62.8 Anfragen/s bei 64 Clients. Der residente GPU-Speicher beträgt 3.8 GB. Bediente Wahrscheinlichkeiten bleiben auf 280 Fragen innerhalb von 0.017 des fp32-Evaluationspfads, mit 1 geänderten Antwort.

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):

Gegenüber fp32-PyTorch auf der CPU bei denselben Anfragen weichen die MLX-Antworten bei 8k Token um höchstens 0.0076 und bei 16k Token um 0.0052 ab, mit keinen geänderten Antworten. Bei 100 Kurzzustands-Fragen liegt der MLX-Pfad innerhalb von 0.020 des fp32-Evaluationspfads, mit 1 geänderten Antwort.

¹ 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

• Außerhalb der Domäne ist es ein Sub-1B-Modell. Es liegt 21 Punkte hinter Jev auf transfer-v4-Development und 31 Punkte hinter dem breadth-v1-Index; Wissen (MMLU-Pro 0.230) und Paraphrase liegen nahe der untrainierten Basis. Verwende Kev-4B, wo Genauigkeit zählt.
• Seine Zugewinne liegen in der Verteilung. Die Trainings-Splits von documents-v1, hard-v1 und devtools-v1 sind in seinen Trainingsdaten; bei JevBenchs öffentlichem Hard-Tier, einer Out-of-Distribution-Prüfung, bewegte ihn die Dokument-und-Skills-Stufe um +2.7 pp [−1.8, +7.2], nicht von null unterscheidbar.
• Tool-Call-Routing wurde schlechter. When2Call, eine reine Evaluationsquelle, fiel von 0.260 auf 0.167 im Development und von 0.233 auf 0.133 im Test, unter die Ein-in-vier-Rate des Ratens unter seinen vier Optionen. Verwende es nicht für Tool-Call-Routing.
• Ein devtools-v1-Ergebnis ist unerklärt. FlakeFlagger bewegte sich von 0.500 → 0.520 im Development, aber von 0.507 → 0.813 im Test, bei 150 Fragen pro Split; behandle es als unerklärt, nicht als Skill.
• Datumsarithmetik ist seine schwächste Familie: 0.35 bei den deadline-Policy-Fragen gegenüber Jevs 0.95; der KEV_DATE_FACTS=1-Präprozessor hilft den größeren Modellen mehr als diesem.
• Regelkomposition ist schwach: Beide Geschwister eines zurückgehaltenen Policy-Minimalpaars sind in 0.422 der Fälle korrekt.
• Die Kalibrierung ist eine In-Distributions-Temperatur (siehe Kalibrierung). Sie kann Konfidenzen nicht umsortieren: Die Abdeckung bei ≤ 5 % Fehler außerhalb der Domäne ist 0.145 im Development gegenüber Jevs 0.70, sodass bei einem strikten Fehlerbudget wenige Entscheidungen automatisiert werden können.
• 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, und bei dieser Größe stärker als bei größeren. Ü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 20 Minuten auf einer NVIDIA H100. Datumsstufe: 9 Minuten.
• Dokument- und Skill-Stufe: 52 Minuten auf einer NVIDIA H200 (Peak 23.9 GB).
• Evaluations- und Serving-Prüfungen: einzelne H100-/H200-/L4-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-08b-r15.json (scripts/release_numbers.py --release kev-08b-r15), der gesperrte Read runs/locked/kev-08b-r15-ungated/, die Familien-Reads vom 2026-09-30 runs/fam-08b-breadth/, runs/fam-08b-breadthtest/ und runs/fam-breadth-test-report/, der Kalibrierungs-Refit runs/r28-readout/round28.json, Serving runs/serve-08b-l4/, runs/mlx-long-states/, runs/mlx-full-0.8b/.
• Stufen: Basisversuch q35-08b/02-trial-2 (Tag v7-base); Daten night2-08b-du2/00-trial-0 (Tag night2-du-release); Dokumente und Skills Runde 15 r15-08b/00-trial-0 (experiments/round15/joint.json, Regel experiments/rounds/r15.json). Kalibrierungs-Refit: Runde 28 Arm 08b-r15 (experiments/rounds/r28.json).
• Veröffentlichte Gewichte: Hub-Revision 9a45d25e; Adapter sha256 9b908623…, head.pt sha256 f400bd12… (T = 2.3511).
• Release-Historie: veröffentlicht am 2026-09-24 als bestätigter Kandidat von Runde 15; 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 9a45d25e und PLAN.md am Git-Tag research-archive-2026-09-24.

Zitat

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

Kontakt

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