Warum wir Strom gebaut haben, ein Entscheidungsmodell als EU-Alternative

Die meisten von euch haben inzwischen wohl mit Open-Source-Entscheidungsmodellen experimentiert oder ein eigenes gebaut. Seit Jev am 15. September erschienen ist, hat sich die Idee eines Modells, das nur entscheidet (Ja oder Nein, ein Score, eine Option aus vielen), schneller verbreitet als alles, was wir bisher gesehen haben. Nach einer Zählung gab es achtzehn Tage später mehr als 1.300 Repositories für Entscheidungsmodelle auf Hugging Face.

Auch wir haben auf diesen Modellen aufgebaut. Und sind immer wieder auf dieselben Probleme gestoßen.

Woran wir gestoßen sind

Kleine Modelle verlieren an Accuracy

Entscheidungsmodelle lassen sich günstig nachbauen, und die kleinen sind verlockend, weil sie auf einem Laptop laufen. Unter ein paar Milliarden Parametern fällt die Accuracy aber schnell ab. Die klarste Kurve bisher hat die kev-Familie auf ihrer eigenen Test-Suite veröffentlicht.

Das kleinste Modell liegt fast jedes dritte Mal falsch, und seine Wahrscheinlichkeiten sind deutlich unzuverlässiger, mit einem Brier-Score von 0,416 gegenüber 0,156 bei 27B (niedriger ist besser). Beides zählt, wenn du eine Entscheidung automatisieren willst. Eine falsche Antwort mit selbstsicherer Wahrscheinlichkeit ist schlimmer als gar keine.

Die größeren Modelle zahlen sich genau dort aus, wo es für Automatisierung zählt. Von 4B auf 27B sinkt die Fehlerrate von 16 % auf 11 %, der Brier-Score von 0,242 auf 0,156, und nur das 27B-Modell hält seine Accuracy bei Inputs bis 64K Tokens, gegenüber 8K bei den kleineren. Ein Teil des Abstands liegt an der Methode, denn das 27B-Modell wurde per Full Fine-Tuning trainiert, die kleineren mit LoRA-Adaptern.

Große Modelle brauchen Datacenter-GPUs und aufwendiges Post-Training

Die 27B-Klasse und größer ist genau, läuft aber auf Datacenter-GPUs. Die Base-Weights allein bringen dich nicht dorthin. Ein kleines Modell, Laya, erreicht auf einem Decision-Benchmark vor dem Fine-Tuning 36 % und danach 77 %. Bei Entscheidungsmodellen ist das Fine-Tuning das Modell. Jedes Team, das die Accuracy will, muss für das Training bezahlen und danach für die GPUs.

Die Größe bestimmt auch, wie weit Post-Training ein Modell bringen kann. In einer Studie von 2026 zum Supervised Fine-Tuning mit Modellen bis 235B Parametern waren größere Modelle nach demselben Training deutlich besser, mit Diminishing Returns, und das stärker bei Full Fine-Tuning als mit LoRA-Adaptern. Mehr Training-Examples halfen jeder Größe um etwa denselben Anteil (O'Neill et al., 2026; siehe auch Zhang et al., 2024). Größere Modelle brauchen außerdem weniger Daten, um ihr Bestes zu erreichen. Auf synthetischen Trainingsdaten erreichte ein 8B-Modell sein Optimum bei 1 Billion Tokens, ein 3B-Modell erst bei 4 Billionen (Qin et al., 2025). Für ein Entscheidungsmodell, dessen Trainingsdaten ständig wachsen, ist genau das der Punkt, weil ein größeres Base-Model seinen Vorsprung mit jeder neuen Runde Daten behält.

Die meisten Open-Source-Projekte nutzen keine umfangreichen Trainingsdaten, bereinigen sie meist nicht gründlich genug und reichern sie nicht mit Synthetic Data an. Fairerweise muss man sagen, dass das für Open Source zu teuer ist. Für ein gutes Modell muss die ganze Data-Pipeline eine Investition sein, mit Continuous Training. Für uns heißt das, dass wir ein Modell betreiben, parallel mehrere andere trainieren und schon die Daten für die zweite Generation vorbereiten.

Jev kann keine Bilder sehen

Zuerst ein großes Dankeschön an TypeSafe AI, die Macher von Jev. Sie haben eine völlig neue Klasse von Modellen eröffnet und Begeisterung für neue Use Cases geweckt. Für die Idee und die vielen neuen Ansätze, die daraus entstehen werden, verdienen sie echten Respekt.

Ein großes fehlendes Stück, und für uns ein entscheidendes, ist, dass Jev keine Bilder verarbeitet. Für viele unserer Fälle ist das Pflicht. Manchmal ist ein Bild der Fallback, wenn der Text nicht reicht, etwa das Foto zu einer Schadensmeldung bei einer Versicherung oder der Screenshot in einem Support-Ticket. Manchmal gibt es gar keinen Text, etwa bei einem Produktfoto, das Listing-Regeln erfüllen muss, oder einer Design-Frage. Du verstehst, worauf wir hinauswollen.

Genauso wichtig sind Bilder für unsere kommende Erweiterung, einen Browser-Use-Agent. Ein Web-Agent entscheidet zusätzlich nach dem, was er sieht, etwa welchen Button er klickt, ob ein Formular richtig ausgefüllt ist, ob eine Seite einen Fehler zeigt und einen visuellen Fallback braucht und was er tut, wenn es gar kein DOM gibt, wie auf einem Canvas. Manchmal schaut er auch nur zum Double-Check hin. Der Text der Seite lässt oft genau das Entscheidende aus, also ist der Screenshot Teil des States. Ein Entscheidungsmodell, das kein Bild lesen kann, kann den Agent nicht zuverlässig steuern.

In den nächsten Beiträgen nehmen wir uns diese Use Cases mit Bildern einzeln vor, von Schadensfotos bei Versicherungsfällen und Screenshots in Support-Tickets bis zu Produktfotos mit Listing-Regeln und dem Browser-Agent.

Und unsere Daten mussten in der EU bleiben

Viele der Entscheidungen, die wir automatisieren, beruhen auf personenbezogenen Daten wie Kunden-E-Mails, Rechnungen und Fotos. Nach der DSGVO braucht jeder Anbieter, der diese Daten für dich verarbeitet, einen Auftragsverarbeitungsvertrag, und jede Übermittlung außerhalb der EU braucht eigene Garantien. Der kürzeste Weg zur Compliance war deshalb unser eigenes Modell auf GPUs in Paris, betrieben von Scaleway, einem französischen Cloud-Provider, ohne fremden AI-Provider dazwischen. Wenn der Datenschutzbeauftragte eines Kunden fragt, wohin seine Daten gehen, sollte die Antwort einfach sein. Sie werden in Frankreich verarbeitet.

Also haben wir unser eigenes trainiert

Strom ist ein großes Vision-Language-Model, per Fine-Tuning auf Geschäftsentscheidungen in derzeit 14 Domains trainiert, von Versicherung und Finance bis Maschinenbau und Office-Arbeit, mit Tasks von Rechnungen und Verträgen bis zu Machine-Logs und Web-Agents. Es nimmt Freitext, JSON oder Bilder entgegen und beantwortet benannte Fragen mit einer der Optionen, die du festlegst, und einer Wahrscheinlichkeit für jede Option. Es spricht dasselbe Request-Format wie Jev, mit Fragen vom Typ choice, score und noul. Für seine Größe und Präzision braucht es Datacenter-GPUs.

Warum es jetzt eine API ist

Gebaut haben wir Strom vor allem für uns selbst, für uprelic.com, unseren Hauptdienst, einen Co-Work-Chat. In den nächsten Beiträgen zeigen wir, wie diese Modellklasse auch Chat-Anwendungen besser machen kann, denn manche Ansätze wie Model-Routing klingen in der Theorie gut, sind aber noch nicht praktikabel. Gleichzeitig war klar, dass andere Teams dieselben Anforderungen haben, etwa Entscheidungen, die sie automatisieren wollen, Daten, die in der EU bleiben sollen, Inputs, die oft Bilder sind, und eine spottbillige Workflow-Pipeline, aber keine Kapazität, selbst ein Modell zu bauen und laufend zu verbessern.

Also öffnen wir es. Strom kostet 0,042 $ pro Million Input-Tokens, Output ist kostenlos, pro Token derselbe Preis wie bei Jev.

Wie gut Strom ist

Eine Vorbemerkung zu den Zahlen. Die eigene Test-Suite eines Modells sagt wenig darüber, wie es im Vergleich zu anderen abschneidet. kev-27B erreicht auf kevs eigener Suite 88,9 % und liegt dort vor Jev mit 85,7 %, und doch kam bisher kein offenes Modell insgesamt an Jev heran. Teams bauen ihre Tests um das herum, worauf ihr Modell trainiert wurde, oft ohne es zu wollen. Das gilt auch für uns. Deshalb bleiben wir bei öffentlichen Benchmarks, sagen, wo unsere Runs nicht ganz sauber sind, und verbessern laufend, wie wir messen, mit mehr Held-out- und unabhängigen Benchmarks.

Wir haben Strom 1.0.7 am 1. Oktober 2026 in Production gemessen, auf öffentlichen Benchmarks, für die Ergebnisse anderer Modelle veröffentlicht sind. Hier ist, was wir gefunden haben, auch da, wo Strom hinten liegt.

Gleichauf mit Jev bei JevBench

Von den 231 öffentlichen JevBench-Tasks löst Strom 201 richtig. Jev 1.13 löst laut den veröffentlichten Ergebnissen 200.

System	Richtig (von 231)	Brier	ECE
GPT-6 Astra (Reasoning, low)	231 (100 %)	0,009	0,015
GPT-5.6 Luna (ohne Reasoning)	206 (89,2 %)	0,207	0,093
Strom 1.0.7	201 (87,0 %)	0,167	0,033
Jev 1.13.0	200 (86,6 %)	0,181	0,032
Open-Jev 27B v1.1	197 (85,3 %)	0,242	–
Open-Jev 9B	179 (77,5 %)	0,322	0,086
Open-Jev 2B	150 (64,9 %)	0,475	0,127

Das Reasoning-Model löst alles, bei einem Median von 2,2 Sekunden pro Antwort. Strom antwortete im Median in 136 ms, gemessen von einem Client in Deutschland, Netzwerk inklusive. Die Latenzen in den veröffentlichten Ergebnissen stammen von anderen Clients, deshalb sind nur die Spalten zu Accuracy und Kalibrierung direkt vergleichbar.

Die Wahrscheinlichkeiten von Strom sind gut kalibriert. Ein Expected Calibration Error (ECE) von 0,033 heißt, dass die angegebene Confidence im Schnitt etwa drei Punkte davon entfernt ist, wie oft Strom tatsächlich richtig liegt. Genau das macht Thresholds brauchbar. Wenn 0,9 heißt, dass neun von zehn Antworten stimmen, kann dein Code danach handeln.

Strom löst jeden Task in Extraction, Intent, Routing, Policy, Tool Selection und Ordinal Scoring. Am schwächsten ist es bei Datums- und Zahlenfragen (5 von 15). Schwer tut es sich auch mit langen Policies (12 von 19) und Multi-Hop-Fragen, die mehrere Fakten verketten (13 von 18). Das gehen wir im nächsten Trainingszyklus an.

Wo Jev vorne liegt

Auf den Control-Suites, die Open-Jev veröffentlicht hat, liegt Jev vorne.

Suite	Strom 1.0.7	Jev 1.13.0
FizzBuzz (300)	264	299
Mailroom (921)	898	908
JF100 (300)	209	232

Die Fehler folgen einem Muster. Bei FizzBuzz verfehlt Strom „durch 5 teilbar“ nie, sagt aber bei „durch 3 teilbar“ für Zahlen wie 13 und 29 Ja. Jeder Fehler bei Mailroom ist ein False Positive, also ein falsches Ja. Bei JF100 entfallen die meisten Fehler auf Relationen, Datumsfragen und Arithmetik, während Policy-Regeln und Discourse fehlerfrei sind. Auch das beheben wir in den Trainingsdaten, eine Task-Familie nach der anderen.

Ein erstes Signal bei Bildern

Image JevBench veröffentlicht Fragen und Antworten, aber keine Bilder, deshalb haben wir einen Teil der Bilder selbst nachgebaut. Auf den 128 öffentlichen Preview-Items löst Strom 94 richtig (73,4 %). Das beste System in der eigenen Preview-Runde des Benchmarks kam auf 59,4 %. Sieh das als Sanity-Check, nicht als Score, denn 68 der Bilder stammen von uns, und einige unserer Versionen sind vermutlich leichter als die Originale. Ein echter Vergleich braucht einen Run auf dem Sealed Set des Benchmarks.

Geschwindigkeit

Die Zeit im Modell hängt vor allem davon ab, wie viel du sendest. Das Diagramm zeigt Mediane aus je 10 Requests mit jeweils neuem Inhalt, gemessen in Production.

Dazu kommt dein Netzwerk-Roundtrip, aus Deutschland etwa 100 ms. Der Latency-Guide enthält alle Messungen, auch dazu, wie sich mehr Fragen und Optionen summieren. Wir planen, an weiteren Standorten zu laufen, um die Latenz zu senken.

Worauf wir setzen

Nach achtzehn Tagen sind Entscheidungsmodelle eine eigene Kategorie. Das Format wurde von einem Open Lab, einer Runtime, einem CDN und Hunderten unabhängiger Entwickler nachgebaut. Weights allein werden für niemanden der Moat sein. Was bleibt, ist das, was ein Fine-Tuning übers Wochenende nicht liefert, nämlich kalibrierte Wahrscheinlichkeiten, auf die du Thresholds setzen kannst, und eine kontinuierliche Data-Pipeline auf einer Infrastruktur, die deine Daten in der EU verarbeitet.

Dafür ist Strom da. In den Docs steht, wie du deinen ersten Request sendest.

---

Daten und Methode

Wir haben Strom 1.0.7 am 1. Oktober 2026 in Production gemessen. Für JevBench haben wir die 231 öffentlichen Tasks mit Request-Format und Scoring des Open-Jev-Harness genutzt und die Ergebnisse anderer Systeme von der Benchmark-Seite von Open-Jev übernommen. Die Control-Suites (FizzBuzz, Mailroom, JF100) haben wir so nachgebaut, wie Open-Jev sie gebaut hat, und alle 1.521 Gold-Labels gegen die veröffentlichten Zeilen von Open-Jev geprüft. Zwei Einträge in unseren Trainingsdaten ähneln JevBench-Tasks, eine lange Policy und eine Datumsfrage, daher sind diese beiden Slices für Strom nicht ganz sauber. Die kev-Zahlen stammen aus der veröffentlichten Evaluation der kev-Familie (New-Source-Test-Split), die Laya-Zahlen aus der veröffentlichten Model Card von Convai Innovations und die Zählung des Ökosystems aus Hugging-Face-Repositories mit Tags für Entscheidungsmodelle, erstellt nach dem 15. September 2026.