Kev-27B

Modellzusammenfassung

Kev-27B 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 von bis zu 64k Token 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. Diese Karte beschreibt Version 2, veröffentlicht am 2026-09-30: ein Full-Weight-Fine-Tune von Qwen3.8-27B, gemittelt mit Version 1.

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

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 (das Modell kann nichts nachschlagen), und wissensintensive Prüfungen (siehe Grenzen).
• Zustände länger als 65,536 Token, andere Sprachen als Englisch und Hardware unterhalb einer GPU der 80-GB-Klasse oder einem Mac mit etwa 96 GB Speicher (siehe Grenzen).

Verwendung

Bediene es mit dem Kev-Repo auf einer B200, H200 oder H100 80 GB. Die Gewichte belegen 51 GB und der Server etwa 65.5 GB resident; ein 64k-Token-Zustand erreichte einen Peak von 87.1 GB auf einer H200 und ein 32k-Token-Zustand 78.7 GB, sodass die längsten Zustände mehr als 80 GB brauchen.

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

Auf Apple Silicon bedient derselbe Befehl über MLX (automatisch gewählt) und lädt die vollständigen bf16-Gewichte so, wie sie gespeichert sind, ohne dass etwas gemerged wird. Dieser Pfad sollte auf einem 96–128-GB-Mac funktionieren, wurde in dieser Größe aber noch nicht ausgeführt (siehe Grenzen).

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. Der Server verwendet bf16, fusionierte DeltaNet-Kernels und CUDA-Graphen; KEV_DTYPE=fp32 wählt den exakten Pfad, der zur Evaluation verwendet wird.

Trainingsdaten

Eine Epoche über einen privaten Korpus von 145,840 Datensätzen (337,130 Fragen) mit Zuständen von höchstens 32,768 Token. Nur sein Manifest ist öffentlich (evals/sft-v2-r22/manifest.json im GitHub-Repo).

Quellen und Labels. Die öffentlichen Datensätze sind in den Metadaten dieser Karte aufgeführt; zwei Entwickler-Tooling-Quellen, CodeReviewer und FlakeFlagger, stammen von Zenodo, und CodeReviewer-Diffs werden nur aus permissiv lizenzierten Projekten behalten. Generierter Text und Labels stammen aus Code oder aus offenen Gewichtungsmodellen (GLM-5.3, DeepSeek-V4-Pro, Inkling, Mistral Large 3, gpt-oss-120b, MiMo-V2.6-Pro). Die Verbraucherbeschwerden-Labels stammen aus offenen Gewichtungsmodellen, gefiltert durch Judges geschlossener Modelle und Adjudikation. Es wurde keine Ausgabe von Jev (TypeSafes gehostetem Entscheidungsmodell) verwendet.

Lizenzen. Vier der begrenzten öffentlichen Datensätze sind Share-Alike: ARC (CC-BY-SA-4.0), HotpotQA (CC-BY-SA-4.0), Natural Questions (CC-BY-SA-3.0) und SNLI (CC-BY-SA-4.0); die anderen sind CC-BY-4.0, MIT oder Apache-2.0. Die CFPB-Beschwerdeerzählungen sind Werke der US-Regierung. GLM-5.3s Lizenz ist MIT-artig mit einer Bedingung für sehr große Model-as-a-Service-Betreiber. Lizenzen, Revisionen und Attributionen pro Quelle sind in den Komponenten-Manifesten festgehalten.

Kontaminations-Screening. Vor dem Training wurde jeder Datensatz gegen 102 Evaluationspartitionen (76,549 Referenz-Items) geprüft: jede eingefrorene Kev-Suite, das private Evaluationsset, JevBenchs öffentliche Items und die untenstehenden reinen Evaluations-Suites. Ein Datensatz wurde bei einer exakten normalisierten Zeichenkettenübereinstimmung, einer Wort-8-Gramm-Jaccard-Ähnlichkeit über 0.2 oder einer Containment von mindestens 0.5 entfernt; 6,388 Trainingsdatensätze wurden entfernt.

Trainingsverfahren

1. Full-Weight-Feinabstimmung. Eine Epoche von Qwen/Qwen3.8-27B auf 8 NVIDIA H200 GPUs (FSDP2). AdamW (β 0.9 / 0.999, Weight Decay 0.01) mit fp32-Master-Gewichten und -Momenten über einem bf16-Backbone; Lernrate 2e-6 für das Backbone und 1e-4 für den Head, One-Cycle-Zeitplan mit 10 % Warm-up; Gradientennorm auf 1.0 geklippt; 128 Datensätze pro Optimizer-Schritt (8 pro GPU, 2 Akkumulationsschritte), 1,140 Schritte; Seed 0. Der Verlust ist Cross-Entropy über die Optionen jeder Frage (Soft-Targets, wo die Daten sie haben). Die Optionsreihenfolge wird gemischt, und “none of the above”-Optionen und Distraktoren werden zufällig eingefügt. Ein Viertel der Choice-Datensätze mit Zuständen von höchstens 8,192 Token ergibt zusätzlich ein Minimalpaar: die Frage mit einer “none of the above”-Option, einmal mit vorhandener richtiger Option und einmal mit entfernter. Jeder Zustand wird einmal ausgeführt, und seine Fragen verzweigen von ihm.
2. Gewichtsmittelung. Jeder Backbone-Tensor ist 0.85 × das feinabgestimmte Gewicht + 0.15 × v1s Gewicht (v1s LoRA-Adapter in fp32 in die Basis gemerged), in fp32 berechnet und einmal auf bf16 gerundet. Der Pointer-Head des feinabgestimmten Modells wird behalten. Das Verhältnis wurde unter sechs Blends (0.85 / 0.70 / 0.50, mit jeweils einem der beiden Heads) auf Development-Daten gewählt.
3. Kalibrierung. Eine einzige Temperatur, T = 1.32, die die negative Log-Likelihood auf 648 Fragen aus zurückgehaltenen Datensätzen minimiert, auf denen kein Elternteil trainiert wurde: 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). Es wurde keine Partition irgendeines Trainingskorpus verwendet, und eine Prüfung fand keine Überschneidung mit den Trainingsdaten.

Evaluation

Methodik. Jeder Vergleich erfolgt gegen Kev-27B v1 auf identischen Items, jedes Modell bei seiner eigenen bedienten Temperatur. 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 (Genauigkeit ≥ 0.886, Brier ≤ 0.165). Intervalle sind 95-%-gepaarte 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). 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 derselben Multi-Task-Sammlung wie die lizenzierte Komponente, aus dem Training herausgehalten.
• hard-v1: programmatisch beschriftete Skill-Datensätze (lange Policies, Abwägungen, Wahrscheinlichkeit, Multi-Hop, Daten und Zahlen, Beurteilung, Abstention); der Test-Split hält Templates trainierter Generatoren zurück.
• devtools-v1: Entwickler-Tooling-Entscheidungen aus lizenzgeprüften öffentlichen Quellen (Code-Review, Commit-Nachrichten, Sicherheit, flakige Tests).
• documents-v1 / documents-v2: US-Verbraucherfinanz-Beschwerdeerzählungen (CFPB); v2 ist ein privates zurückgehaltenes Test-Set.
• transfer-v4: Out-of-Domain-Entscheidungen aus sechs nie trainierten öffentlichen Quellen plus zurückgehaltene Policy-Strukturen.
• longdoc-v1: CUAD-Handelsverträge von bis zu 64k Token und generierte Vereinbarungsbündel.

Headline-Panels schließen Items aus, die ein vor dem Bau dieses Checkpoints abgeschlossenes Label-Audit als untauglich befand¹; jeder Ausschluss entfernt dieselben Zeilen von beiden Modellen.

Ergebnisse gegen v1 (Test-Partitionen).

Vergleich mit anderen Entscheidungsmodellen auf dem breadth-v1-Test (alle 14 Datensätze), bewertet mit dem zufallskorrigierten 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). Jev wurde über Vercel AI Gateway abgefragt und AutoJev-27B (denis-pplx/autojev-27b, ein Full-Weight-Fine-Tune derselben Basis) über seinen eigenen Server, jeweils einmal, auf denselben Items.

Gegen v1 beträgt die Indexdifferenz +2.1 [−0.4, +4.6]. Es wurde kein gepaartes Intervall gegen Jev berechnet.

Lange Dokumente (CUAD-Verträge im longdoc-v1-Test, Genauigkeit / ECE nach Zustandslänge in Token):

Genauigkeitsdifferenz über alle Längen: −1.6 [−3.0, −0.3]. Auf den generierten Vereinbarungsbündeln (2,400 Fragen) erreichen beide Modelle 1.000.

Kontextlänge. Validierte Kontextlänge: 65,536 Token, das Serving-Limit, aus longdoc-v1-Development (gepaarte CUAD-Genauigkeitsdifferenz zum 8k-Bucket, pp [95 % CI]: 16k +0.2 [−0.7, +1.2], 32k −0.2 [−1.2, +0.7], 64k −1.1 [−2.4, +0.0]; je 445–447 Fragen). Die Regel ist die, die auf jede Kev-1.0-Größe angewandt wird: 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, das heißt, die CUAD-Genauigkeitsdifferenz zum 8k-Bucket, gepaart auf demselben Vertrag, Repeat und derselben Frage, hat eine 95-%-Untergrenze von mindestens −3 pp, wobei jeder Datensatz beantwortet wurde.

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

Auf den 648 Fitting-Fragen senkt eine 5-fache gruppen-disjunkte Kreuzvalidierung den ECE von 0.048 (roh) auf 0.038 (out of fold); die beiden Intervalle überlappen. Das 90-%-Bootstrap-Intervall der Temperatur ist [1.20, 1.45]. An seinen Enden bewegen sich die Headline-Panels in entgegengesetzte Richtungen: breadth-v1 ECE steigt auf 0.026 bei T = 1.20 und tasksource-heldout-v1 ECE auf 0.067 bei T = 1.45.

Weitere Ergebnisse.

Der transfer-r3-Test ist ein Kurzzustands-Panel aus denselben acht zurückgehaltenen Quellen wie der Kalibrierungspool; decision-v7 ist v1s Trainingsverteilung; transfer-v9 enthält MMLU-Pro und Items, deren entscheidende Evidenz entfernt wurde. SemIf (handverfasste Entscheidungen aus dem SemIf-Projekt), WANLI-v2 (Natural-Language-Inference-Paare aus dem WANLI-Test-Split) und TypeSafe (SemIfs Auswahl von TypeSafe-Workflow-Fällen) werden nur berichtet: Das Label-Audit befand sie als zu klein, gesättigt oder verrauscht, um Modelle zu ranken. WANLI-v2 und TypeSafe wurden am 2026-09-30 als Evaluationen zurückgezogen (etwa ein Viertel der WANLI-Paare wurde von seinen zwei Annotatoren unterschiedlich beschriftet, mit dem Gold auf eines der beiden Labels gesetzt; TypeSafes Gold ist die gemittelte Antwort zweier geschlossener Frontier-Modelle, auf zu wenigen Fragen, um Checkpoints auseinanderzuhalten); ihre Zahlen bleiben als Aufzeichnung erhalten.

Serving-Parität (H200, bf16 mit fusionierten Kernels und CUDA-Graphen, 200 decision-v7-Development-Datensätze / 280 Fragen):

¹ Von den Headline-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); und zwei devtools-v1-Aufgaben, deren Labels der Zustand nicht bestimmt (flakeflagger, Commit-Änderungstyp). Die transfer-r3-Quelle emotion (distante Keyword-Labels) wird in den Grenzen vom Kurzzustands-Panel ausgeschlossen.

Grenzen und Kompromisse

• Auswahl. Der veröffentlichte Checkpoint wurde ausgewählt, nachdem die Testergebnisse eines früheren Kandidaten bekannt waren, und auf denselben Test-Sets bestätigt. Behandle die Test-Margen als optimistisch.
• Kein Zugewinn bei kurzen Zuständen. Er ist bei kurzen Eingaben nicht besser als v1: −0.8 pp [−2.0, +0.5] im gesperrten transfer-v4-Test, −0.9 pp [−2.0, +0.1] im Kurzzustands-Development-Panel (transfer-v4-Development und transfer-r3-Test ohne emotion) und −2.1 pp [−3.5, −0.8] im ganzen transfer-r3-Test.
• Schlechter und überkonfident auf langen Verträgen. Auf CUAD ist er 1.6 pp weniger genau als v1 und sein ECE ist bei jeder Länge zwei- bis viermal so hoch wie der von v1 (0.053 gegenüber 0.007 insgesamt). CUADs Fragen enthalten einige falsche oder umstrittene Gold-Labels, aber die Lücke ist über die Längen hinweg konsistent. Für die Vertragsprüfung fitte die Temperatur auf deinen eigenen beschrifteten Dokumenten neu (python -m kev.calibrate) oder verwende v1.
• In-Distributions-Zugewinne. Die Trainings-Splits von hard-v1, devtools-v1 und documents-v1 sind in den Trainingsdaten, und die Suites ood-v2, agents-ood-v1 und guardrails-ood-v1 sind zurückgehaltene Domänen von Generatoren, die auch Trainingsdaten erzeugt haben. Zugewinne dort messen zurückgehaltene Items trainierter Familien, keinen Transfer auf neue Aufgaben.
• Unbekanntes Basistraining. Die Basis ist Qwens nachtrainierte Veröffentlichung; ihre Trainingsdaten sind nicht bekannt, sodass eine Überschneidung zwischen ihr und irgendeiner Evaluation nicht ausgeschlossen werden kann.
• Wissen. Wissen wird von der Basis bestimmt: MMLU-Pro liegt bei 0.675 gegenüber Jevs 0.840 auf denselben Items.
• Untrainierte Längen. Zustände von 32k–64k Token wurden evaluiert (longdoc-v1), aber nicht trainiert.
• Zurückgezogene Suite. Eine Support-Ticket-Suite, die zur Auswahl von v1 verwendet wurde (scienthoon), wurde vor dem Bau von v2 als untauglich zurückgezogen, sodass v2 darauf kein Ergebnis hat. v2s nicht gemittelter feinabgestimmter Elternteil lag dort 5.5 pp [−7.8, −3.2] unter v1.
• Temperaturunsicherheit. Das Intervall der Temperatur ([1.20, 1.45]) bewegt den Test-ECE um bis zu etwa 0.02.
• Hardware. Es braucht eine Rechenzentrums-GPU der 80-GB-Klasse (mehr als 80 GB für die längsten Zustände). Apple Silicon über MLX: v2s vollständige bf16-Gewichte brauchen etwa 51 GB plus Arbeitsspeicher, sodass ein 64-GB-Mac grenzwertig ist und ein 96–128-GB-Mac passen sollte. Das wird aus Messungen an kleineren Modellen erwartet, nicht auf einem großen Mac gemessen: Das Laden eines Full-Weight-Kev-4B über denselben Pfad erreichte einen Peak von der Größe seiner Gewichte (8.4 GB), und seine Antworten lagen innerhalb von 0.015 des fp32-Evaluationspfads (runs/mlx-full-4b). v1 (der LoRA-Adapter, Tag v1-lora) wurde von einem externen Beitragenden über MLX auf einem 128-GB-M5-Max bedient (PR #175): 0.849 Genauigkeit auf transfer-v4-Development gegenüber den veröffentlichten 0.848, 52 GB im Dauerbetrieb und 97 GB im Peak, während der Adapter gemerged wurde.

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, bevor du Schwellenwerte setzt.
• Genauigkeit und Kalibrierung verschieben sich bei Domänenwechsel (zum Beispiel auf langen Verträgen). Ü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

• Feinabstimmung: 8 × NVIDIA H200 für 16.2 h Trainingszeit (129 GPU-Stunden), ohne Neustarts und Evaluation.
• Gewichtsmittelung: etwa 6 Minuten auf der CPU.
• Evaluations- und Serving-Prüfungen: einzelne H200-GPUs auf Modal.

Herkunft und Reproduzierbarkeit

• Code, Suites und Evaluationsberichte: github.com/jaredpalmer/kev. Release-Zahlen: runs/release/kev-27b-r23.json (scripts/release_numbers.py --release kev-27b-r23).
• Fine-Tune: Versuch von Runde 22 r22-27b-lr2e6/00-trial-0 (experiments/round22/lr2e6.json), Gewichte sha256 3fa0182a…. Blend: Runde 23 Arm 27b-k-w85 (scripts/interpolate_checkpoint.py --toward; interpolation.json im Hub-Repo), Auswahlregel und Bestätigungsstufen in experiments/rounds/r23.json; Ergebnisse in runs/r23-readout/, runs/r23-verdict/, runs/r23-breadth-report/, runs/serving-27b-r23*/.
• Blend-Quelle: v1 bei jaredpalmer/kev-27b@01b81998 (Versuch r6-27b-v2/01-trial-1), jetzt Tag v1-lora.
• Veröffentlichte Gewichte sha256 d27af6ab2be16824166ac639907b4dba40979ff338599c2872721aa6c5072022; head.pt sha256 7968f17b03479c1ef9d1c0f3ab8a15e31ecb441cf40691b07ee945ab554d45ad (T = 1.3195). Gewichte veröffentlicht im Hub-Commit 28be62e9.
• Verifikation: anonym vom Hub auf einer H200 geladen, reproduzierte es die Logits der Vorab-Evaluation exakt auf 252 von 252 SemIf-Zeilen und 764 von 764 transfer-v4-Development-Zeilen (runs/release/kev-27b-r23-published.json, runs/release/kev-27b-r23-staging.json).

Zitat

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

Kontakt

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