Nace.AI veröffentlicht Drex 1.5: 9B-Entscheidungsmodell bewertet Optionen pro Forward-Pass, 93,4 % bei 128K langen Dokumenten
Laut einem MarkTechPost-Bericht vom 9. Oktober 2026 hat Nace.AI das 8,95B-Dense-Entscheidungsmodell Drex 1.5 als Open Weights veröffentlicht. Es liest einen Zustand und eine typisierte Frage und gibt Wahrscheinlichkeiten für Optionen zurück, statt Text zu generieren. Dem Bericht zufolge erreicht es einen Decision Index 0.3.1 von 58,08 und läuft lokal auf einer einzelnen GPU in bf16 oder über eine quantisierte Variante mit etwa 9,5 GB.
Was sich geändert hat
Laut einem MarkTechPost-Bericht vom 9. Oktober 2026 hat Nace.AI Drex 1.5 als Open Weights veröffentlicht, ein 8,95B-Dense-Entscheidungsmodell für Agenten- und Backend-Workflows. Das Modell generiert keinen Text: Nutzer übergeben einen Zustand (Text oder JSON) und eine benannte Frage, und das Modell gibt in einem einzigen Forward-Pass für jede Option eine Wahrscheinlichkeit zurück. Unterstützt werden drei Fragetypen: choice, noul (Ja/Nein) und ordinal score. Da keine Tokens gesampelt werden, sind temperature und top_p nicht anwendbar. Als Backbone nennt die Quelle MiMo-V2.6-Distill-Qwen-9B mit 32 Schichten und hybrider Attention (auf jede Full-Attention-Schicht folgen drei lineare Attention-Schichten); zusätzlich bewertet ein separater Pointer-Head head.pt die Hidden States. Die Schnittstelle ist POST /v1/systemone und entspricht dem Anfrageformat von TypeSafe für das Closed-Source-Modell Jev; laut Quelle genügen für bestehende Jev-Clients wenige Änderungen an Umgebungsvariablen für eine Migration. Der Kontext beträgt standardmäßig 16384 Tokens und maximal 131072. Die Gewichte wurden auf Hugging Face veröffentlicht, eine gehostete Version ist auf OpenRouter verfügbar, und die Rechenleistung soll von DeepInfra bereitgestellt werden.
Auswirkungen für Entwickler
Die unmittelbarste Änderung für Entwickler: Entscheidungsaufgaben wandeln sich von "ein Chatmodell strukturierten Text ausgeben lassen und diesen parsen" zu "in einem Forward-Pass Optionswahrscheinlichkeiten erhalten". Das spart Parsing- und Retry-Logik und macht die Entscheidungslatenz besser vorhersagbar. Dem Bericht zufolge sind lange Dokumente eine Stärke von Drex 1.5: Bei 32K bis 128K Tokens liegt die Genauigkeit bei 93,4 % und die mediane Latenz bei 2,0 Sekunden; werden dieselben Anfragen auf 8K Tokens gekürzt, sinkt die Genauigkeit auf 76,5 % bzw. 78 %. Das zeigt einen deutlichen Unterschied zwischen langem und kurzem Kontext bei Entscheidungen, was für Workflows wie Entscheidungsfindung nach RAG oder die Sortierung mehrerer Kandidaten erheblich ist. Andererseits weist der Bericht darauf hin, dass es sich um eine Entscheidungsschicht und nicht um ein Allzweckmodell handelt: Es kann weder Text noch Code noch Erklärungen generieren. Wissensintensive Aufgaben sind eine Schwäche: GPQA Diamond 45,4 % gegenüber Jev 78,6 %, MMLU-Pro 58,7 % gegenüber Jev 82,7 %. Bei ACOS erreicht die Sentimentanalyse einzelner Kommentare einen F1 von nur 7,4 %, während Jev 29,5 % erzielt. Das Training nutzte den offiziellen Trainingssatz des Index-Benchmarks, was Vorteile bei gängigen Entscheidungstypen bringt; die Quelle merkt jedoch an, dass Ergebnisse in neuen Domänen abweichen können. Auf Deployment-Ebene erfordert der lokale Weg Nace' Fork von llama.cpp und Ollama statt der Upstream-Hauptzweige. Die Gewichte stehen unter der Open-RAIL-M-Lizenz, und die Quelle empfiehlt ausdrücklich, die Bedingungen vor kommerzieller Nutzung zu prüfen. Hier zeigt sich, warum "offene Gewichte" und "Open-Source-Lizenz" getrennt zu betrachten sind: Verfügbarkeit der Gewichte bedeutet nicht automatisch permissive Lizenzbedingungen.
Integration und Bewertung
Das Folgende sind auf dem Quellenbericht basierende Empfehlungen und Konditionalanalysen, keine verifizierten Fakten. Erste Entscheidung: Sollen bestehende Jev-Aufrufstellen auf Drex 1.5 umgestellt werden? Dem Bericht zufolge sind die Anfrageformate identisch und der Änderungsaufwand beschränkt sich im Wesentlichen auf Umgebungsvariablen. Wenn der Workload überwiegend aus Optionsbewertung, Ja/Nein-Entscheidungen und ordinaler Sortierung besteht und das Team den Entscheidungsverkehr von einer Closed-Source-API wegbewegen möchte, ist ein Shadow-Traffic-Vergleich zunächst ratsamer. Ein messbares Abnahmekriterium: dieselben historischen Anfragen gleichzeitig an beide Pfade senden und die Übereinstimmungsrate der Optionen sowie den Anteil der Fälle messen, in denen die höchste Optionswahrscheinlichkeit unter einem Schwellenwert liegt. Wenn die Übereinstimmung hoch ist und der Anteil niedrig-konfidenter Stichproben nicht deutlich steigt, kann schrittweise skaliert werden. Enthält der Workload hingegen Erklärungsgenerierung oder müssen Antworten einen explizit sichtbaren Reasoning-Prozess zeigen, sollte nicht umgestellt werden, da das Modell laut Bericht keinen Text generiert. Zweite Entscheidung: Bei langen Dokumenten direkt die 128K-Stufe nutzen statt vorher zu kürzen? Der Bericht zeigt 93,4 % Genauigkeit und 2,0 Sekunden mediane Latenz für die 32K-bis-128K-Stufe, während Kürzung auf 8K die Genauigkeit auf 76,5 % bzw. 78 % senkt. Wenn die Eingabe tatsächlich ein langes Dokument ist und das Latenzbudget Sekundenaufwand zulässt, könnte das Beibehalten des langen Kontexts die ertragreichere Wahl sein. Bei der Evaluierung sollte nach Länge gruppiert werden (unter 8K, 8K bis 32K, 32K bis 128K), wobei Genauigkeit und P95-Latenz gemessen werden. Überschreitet die lange Stufe das Budget, kann Kürzung erwogen werden, allerdings mit akzeptiertem Genauigkeitsverlust. Dritte Deployment-Entscheidung: lokal oder gehostet? Dem Bericht zufolge läuft bf16 mit etwa 18 GB auf einer einzelnen 24-GB-A10G, während Q8_0 GGUF mit etwa 9,5 GB auf Apple-Chips und CPUs läuft; beide Quantisierungspfade sollen laut Quelle identische Antworten liefern. Wenn Daten das interne Netz nicht verlassen dürfen oder Offline-Inferenz nötig ist, ist lokales Deployment machbar, sofern man den Build aus Nace' Fork und die Bedingungen von Open RAIL-M akzeptiert. Abnahmekriterien sind die Übereinstimmung der Antworten von lokal und gehostet auf demselben Evaluierungsset sowie ob der Single-GPU-Durchsatz den Anforderungen pro Sekunde entspricht. Preise ändern sich; für hostingbezogene Kosten sind die aktuellen Preisseiten von OpenRouter und der Nace Console maßgeblich.
Grenzen und offene Fragen
Klarzustellen ist, dass Drex 1.5 derzeit nicht im Modellkatalog von KimiSeek erscheint und die im Bericht genannte API-Verfügbarkeit auf die Hosting-Dienste des Anbieters selbst verweist, nicht auf den Katalog dieser Seite. Die Benchmarkwerte in der Quelle (Decision Index 0.3.1 von 58,08, JevBench 86,2 %, OpenSpiel 122 Siege, 47 Unentschieden, 87 Niederlagen, 93,4 % bei langen Dokumenten) sind von Nace oder den Ranking-Anbietern berichtete Ergebnisse, die überwiegend von den Anbietern selbst auf offiziellen Evaluierungs-Suites ausgeführt wurden; diese Seite hat sie nicht unabhängig reproduziert. Der Bericht merkt außerdem an, dass für das Training der offizielle Trainingssatz des Index-Benchmarks verwendet wurde, weshalb die Leistung in neuen Entscheidungsdomänen von den Benchmarkwerten abweichen kann. Die Schwächen bei ACOS-Sentimentanalyse und wissensbasierten Tests wurden im Bericht genannt. Darüber hinaus hängen die Ollama- und llama.cpp-Pfade von Nace' Fork-Versionen ab; die Upstream-Hauptzweige müssen diese nicht zeitgleich unterstützen. Die Gewichte sind zwar offengelegt, die Lizenz ist jedoch RAIL-M mit Nutzungseinschränkungen; kommerzielle Nutzung erfordert eigene Prüfung der Bedingungen. Die im Bericht erwähnte Registrierungsprämie von 25 US-Dollar und die Hosting-Preise stammen vom Veröffentlichungszeitpunkt und können sich geändert haben; bitte die aktuellen Preisseiten konsultieren.