Harveys Tenet erreicht fast das Doppelte der LAB-Quote von Kimi K3, belegt sind bisher nur Herstellerzahlen

Tenet erreicht fast das Doppelte der LAB-Quote von Kimi K3, laut Harveys eigenen Zahlen

Fireworks beschreibt in einem technischen Bericht, wie sich Kimi K3 per Reinforcement Learning spezialisieren lässt. Als Beispiel dient Tenet, Harveys erstes Modell auf Kimi-K3-Basis für juristische Langzeitaufgaben. Harvey hat es zusammen mit Fireworks asynchron per RL nachtrainiert, auf der Fireworks Training API.

Die Zahlen stammen aus einer Auswertung von Fireworks und Harvey vom August 2026. Auf dem Legal Agent Benchmark (LAB) erreicht Tenet 19,7 % All-pass. Basis-K3 kommt auf 10,8 %, Fable 5 auf 11,5 %. Tenet liegt damit beim etwa 1,8-Fachen von Basis-K3. Auf LAB Contracts sind es 11,3 % für Tenet, 9,3 % für Basis-K3 und 9,0 % für Fable 5.

Alle diese Werte sind Herstellerangaben und nicht unabhängig geprüft. Das betrifft auch die Aussagen, Tenet erreiche den Bestwert auf LAB Contracts und Platz zwei auf LAB. Die Autoren nennen die Kosteneffizienz „vielversprechend“, eine Zahl liefern sie dafür nicht.

Kimi K3 stammt von Moonshot AI. Es ist ein Open-Weight-Modell mit 2,8 Billionen Parametern und arbeitet als Mixture-of-Experts-Modell: Pro Token aktiviert es 16 von 896 Experten. Der Kontext reicht bis zu 1 Million Token. Die Gewichte stehen unter der „Kimi K3 License“. Laut Fireworks erschien das Modell am 27. Juli und ist dort in allen Serverless-Tarifen verfügbar.

Was „All-pass“ im Legal Agent Benchmark misst

LAB setzt Agenten in Sandbox-Arbeitsbereiche mit echten juristischen Dokumenten und Werkzeugen. Sie sollen fertige Ergebnisse liefern, etwa Memos, bearbeitete Verträge oder Diligence-Zusammenfassungen. Ein LLM-Judge prüft jedes Ergebnis anhand Dutzender konkreter Kriterien. All-pass zählt nur Aufgaben, bei denen sämtliche Kriterien erfüllt sind.

Die Metrik ist streng. Ein einziges verfehltes Kriterium macht eine Aufgabe zum Fehlschlag, auch wenn der Rest stimmt. Harvey begründet das so: Ein Modell kann im Durchschnitt gut abschneiden und trotzdem ein Kriterium verfehlen, das das Ergebnis unbrauchbar macht.

Daraus folgen zwei Dinge. Erstens: Absolute Quoten von höchstens 19,7 % sind bei dieser Messlatte kein Zeichen von Schwäche allein. Sie zeigen aber, dass auch das beste genannte Modell die Mehrzahl der Aufgaben nicht vollständig löst. Zweitens: Die Abstände auf LAB Contracts sind klein, 11,3 % gegenüber 9,3 % und 9,0 %. Das Material enthält weder Aufgabenzahl noch Streuung. Damit lässt sich nicht beurteilen, wie belastbar solche Differenzen sind. Außerdem urteilt ein LLM-Judge und kein menschlicher Prüfer.

Fireworks gibt an, die Gewinne übertrügen sich auf agentische Benchmarks, die das Modell im Training nie gesehen habe, ohne nennenswerten Rückgang beim juristischen Wissen. Das ist eine Herstellerangabe. Konkrete Kostenzahlen fehlen ebenfalls, die behauptete Kosteneffizienz lässt sich also nicht nachrechnen.

Wie abweichende Wahrscheinlichkeiten das Training zum Kollaps bringen können

Dass Fireworks die Abstimmung zwischen Training und Inferenz betont, ist kein hauseigenes Randthema. Das Problem ist unabhängig dokumentiert. Beim RL erzeugt oft eine separate Inferenz-Engine die Rollouts, weil das schneller geht. Sie nutzt aber andere Kernel, Präzisionen und Batch-Formen als der Trainer. So existieren zwei Implementierungen derselben Policy. Selbst bei identischen Gewichten ordnen sie demselben Token unterschiedliche Wahrscheinlichkeiten zu.

Das schlägt auf die Importance-Ratios durch, mit denen der Policy-Gradient gewichtet wird. Nach einer fachlichen Darstellung entsteht der Schaden vor allem im Schwanz der Verteilung. Ein Token, das der Sampler mit 0,02 zieht und der Trainer mit 0,10 bewertet, verstärkt seinen Gradienten entsprechend. Solche Tokens häufen sich bei flachen Verteilungen, seltenen Tokens und langen Sequenzen. Ungebremst können sie die Gradientennorm hochtreiben und das Training kollabieren lassen.

Bei MoE-Modellen kommt ein weiterer Effekt hinzu. Liegen die Router-Scores fast gleichauf, kann ein Rundungsunterschied darüber entscheiden, welche Experten feuern. Dasselbe Token läuft dann durch andere Pfade.

Zwei unabhängige Quellen stützen das. Ein arXiv-Beitrag isoliert das Phänomen in einem Null-Mismatch-Diagnoseaufbau (VeXact). Er zeigt, dass kleine numerische Abweichungen auf Token-Ebene allein einen Trainingskollaps auslösen können, und behandelt den Mismatch als Faktor erster Ordnung, nicht als harmloses Rauschen. Ein GitHub-RFC (#48305) nennt acht Konsistenzdimensionen, darunter Logprob- und Token-ID-Replay, MoE-Routing-Replay (R3), Replay der DSA-Indizes und den Datentransport zum Trainer.

Für Kimi K3 ist das plausibel relevant, weil das Modell als MoE mit 16 aus 896 Experten viele Routing-Entscheidungen pro Token trifft. Kimi-spezifische Messungen belegen diese Quellen jedoch nicht.

Die Mismatch-Zahlen stammen von GLM 5.2, nicht von Kimi K3

Die konkreten Messwerte im Material von Fireworks betreffen ein anderes Modell. Das Unternehmen ließ dieselbe RL-Aufgabe zweimal auf GLM 5.2 laufen: eine Countdown-Rechenaufgabe mit gleichem Algorithmus und gleichen Daten. Der einzige Unterschied war, ob Trainer und Rollout-Engine die Token-Wahrscheinlichkeiten gleich berechneten.

Taten sie es nicht, brach der Lauf zusammen. Die Systeme wichen um eine KL von etwa 0,013 voneinander ab. Die Standard-Schutzmaßnahmen verwarfen rund 45 % jedes Batches, um das Training stabil zu halten. Der Reward stieg auf etwa 0,9 und brach dann ein. Laut Fireworks reicht Router Replay allein nicht aus.

Die Darstellung bricht im vorliegenden Material ab. Welche Gegenmaßnahmen Fireworks einsetzt und welche Endergebnisse der korrigierte Lauf erreicht, geht daraus nicht hervor. Für Kimi K3 liegen keine eigenen Mismatch-Zahlen vor. Der Bericht betont die Konsistenz gerade für Modelle in Kimi-K3-Größe, belegt sie aber an einem anderen Modell. Dass K3 ähnlich empfindlich reagiert, ist plausibel, aber nicht gezeigt.

Auch harte Systemzahlen fehlen. Zu Durchsatz, eingesetzter Hardware und Latenz der Policy-Aktualisierung enthält das Material nichts, obwohl der Bericht genau diese Größen als Kern des RL-Betriebs beschreibt.

Drei RL-Wege bei Fireworks, offen bleibt, ob RL ohne eigenen Trainingscode buchbar ist

Fireworks unterscheidet drei Wege für RL. Beim BYOT liefert das Unternehmen nur die Rollout-Inferenz, den Trainer betreibt der Kunde. Die Training API ist der mittlere Weg: eigene Trainingslogik auf Fireworks-Infrastruktur, von LoRA bis Full-Parameter. Managed RFT gilt als schlüsselfertig, den RL-Loop betreibt der Kunde nicht selbst.

Das System ist auf verteilte Setups ausgelegt. Trainer und Rollout-Cluster können in verschiedenen Regionen oder Clouds laufen. Per Hot-Load lassen sich Full-Parameter-Checkpoints und LoRA-Adapter einspielen. Checkpoints wandern als verlustfrei komprimierte, inkrementelle Snapshots (arc_v2, typisch 20-fach und höher komprimiert) über gewöhnlichen Objektspeicher, ohne spezielles RDMA-Netz. Das Design ist für asynchrones bzw. Off-Policy-Training gedacht.

Serverless-Training nutzt einen gemeinsamen Trainer-Pool. Laut Doku unterstützt es LoRA-SFT, DPO, ORPO, RL, Distillation und eigene Loops. Der Checkpoint-Speicher ist derzeit kostenlos. Für Full-Parameter-Training oder nicht gelistete Modelle verweist die Doku auf Dedicated Training. Daneben bietet Fireworks Co-Development an: 6 bis 10 Wochen bis zum eigenen Modell, inklusive Daten-Check, Evals und Serving-Design.

Hier widerspricht sich die Dokumentation. Eine Seite nennt Managed RFT als schlüsselfertigen RL-Weg. Eine andere sagt, SFT und DPO liefen als Managed-Jobs, RL aber nur auf der Training API. Die Produktseite beschreibt Managed-Jobs als SFT, DPO und ORPO, ausschließlich mit LoRA. Dahinter stehen womöglich unterschiedliche Produktnamen oder Dokumentationsstände. Das Material klärt es nicht. Relevant ist die Frage für Unternehmen mit Domänenwissen, die keinen eigenen RL-Loop betreiben wollen. Als Beispiele nennt Fireworks Harvey (Training API, laut Bericht) und Genspark (Reinforcement Fine-Tuning, laut Kimi-Modellseite). Ob RL ohne eigenen Trainingscode buchbar ist, lässt sich aus den Quellen nicht beantworten. Harvey nutzte nach eigener Darstellung die Training API, also den Weg mit eigener Logik.

Die Aussagen des Herstellers sind nicht überprüft. Genspark habe laut Kimi-Modellseite per Reinforcement Fine-Tuning auf Kimi geschlossene Modelle übertroffen: 12 % bessere Qualität, 33 % mehr Tool-Calls, 50 % geringere Kosten. Metrik und Vergleichsmodell nennt Fireworks nicht. Dasselbe gilt für die Behauptung, Kimi-Modelle kosteten nur „ein Zehntel“ geschlossener Modelle. Zu EU-Datenschutz oder rechtlichen Fragen enthält das Material nichts.