
Kurzfazit: Leanstral 1.5 ist Mistrals neues offenes KI-Modell für formale Verifikation in Lean 4. Laut Mistral erreicht das Modell 100 Prozent auf miniF2F, löst 587 von 672 PutnamBench-Aufgaben und findet in realen Open-Source-Repositories mehrere bisher unbekannte Fehler. Der technische Kern ist nicht nur bessere Mathematikleistung, sondern ein Agenten-Workflow, der Compiler-Feedback, Dateiänderungen und sehr lange Beweisversuche über Millionen Token nutzt.
Mistral AI hat mit Leanstral 1.5 ein spezialisiertes Modell für formale Beweise, Lean-Entwicklung und Code-Verifikation vorgestellt. Der Release ist für die KI-Entwicklung relevanter, als es auf den ersten Blick wirkt: Während viele neue LLMs vor allem mit Chat-, Coding- oder Multimodal-Benchmarks vermarktet werden, zielt Leanstral 1.5 auf ein engeres, aber technisch hartes Problem: mathematische Aussagen und Programme so zu beweisen, dass ein formaler Prüfer sie akzeptiert.
Das ist ein anderer Qualitätsmaßstab als eine plausible Antwort im Chat. Ein Lean-Beweis muss kompilieren. Eine formale Eigenschaft muss mit Typen, Definitionen, Hilfslemmata und Compiler-Feedback zusammenpassen. Genau deshalb sind Modelle wie Leanstral interessant: Sie verschieben KI von Textgenerierung in Richtung überprüfbarer Arbeitsschritte.
Mistral veröffentlicht Leanstral 1.5 laut eigener Ankündigung unter Apache-2.0-Lizenz. Die Gewichte stehen auf Hugging Face bereit, zusätzlich nennt Mistral einen kostenlosen API-Endpunkt mit dem Modellnamen leanstral-1-5. Der Zugangszustand ist damit deutlich offener als bei vielen geschlossenen Frontier-Modellen: Die Gewichte sind öffentlich verfügbar, die API ist laut Anbieter kostenlos nutzbar, und das Modell ist auf Lean-4-Proof-Engineering spezialisiert.
Was Leanstral 1.5 technisch ist
Leanstral 1.5 ist kein allgemeines Chatmodell mit ein paar Mathematik-Beispielen im Prompt. Mistral beschreibt es als formal-reasoning Modell mit 119 Milliarden Gesamtparametern und 6 Milliarden aktiven Parametern. Diese Formulierung deutet auf eine Mixture-of-Experts-Architektur hin, bei der pro Token nur ein Teil des Gesamtmodells aktiv gerechnet wird. Wichtig ist hier aber weniger die reine Modellgröße, sondern die Spezialisierung auf Lean 4 und lange Beweisprozesse.
Lean 4 ist ein Theorem-Prover und eine Programmiersprache für formale Mathematik. Statt nur informell zu argumentieren, schreibt man Beweise so, dass ein Compiler beziehungsweise Proof-Checker sie vollständig überprüft. Für KI-Modelle ist das attraktiv, weil der Erfolg messbar ist: Ein Beweis ist nicht einfach „überzeugend“, sondern wird akzeptiert oder abgelehnt.
Mistral trainierte Leanstral 1.5 laut Blogpost in drei Stufen:
- Mid-Training, also weiteres Training auf domänenspezifischen Daten.
- Supervised Fine-Tuning, bei dem das Modell mit beispielhaften Beweis- und Agentenabläufen angepasst wird.
- Reinforcement Learning mit CISPO, wobei das Modell aus Rückmeldungen der Umgebung lernt.
Besonders relevant sind die zwei Trainingsumgebungen, die Mistral beschreibt. In einer Multiturn-Umgebung bekommt das Modell eine Theorem-Aussage, reicht einen Beweis ein, erhält Lean-Compiler-Feedback und verbessert den Versuch iterativ. In einer Code-Agent-Umgebung arbeitet Leanstral stärker wie ein Entwickler: Es editiert Dateien, führt Shell-Befehle aus und nutzt den Lean Language Server, um Ziele, Fehler und Typinformationen auszuwerten.
Das ist der eigentliche Unterschied zu klassischen Benchmark-Lösungen. Leanstral 1.5 soll nicht nur einzelne Aufgaben lösen, sondern sich durch ein echtes Repository bewegen, Hilfslemmata aufbauen, Fehler interpretieren und über mehrere Iterationen an einem Beweis arbeiten.
Die wichtigsten Benchmark-Ergebnisse laut Mistral
Die Mistral-Zahlen sind Herstellerangaben und nicht unabhängig verifiziert. Trotzdem sind sie technisch konkret genug, um sie einzuordnen. Mistral nennt mehrere Benchmarks aus formaler Mathematik und Proof Engineering.
| Benchmark | Ergebnis laut Mistral | Bedeutung |
|---|---|---|
| miniF2F Validierung und Test | 100 Prozent | Formalisierte Mathematikaufgaben bis IMO-Niveau |
| PutnamBench | 587 von 672 Aufgaben | Anspruchsvolle Wettbewerbsaufgaben mit langen Beweisketten |
| FATE-H | 87 Prozent | Abstrakte Algebra auf fortgeschrittenem Niveau |
| FATE-X | 34 Prozent | Besonders schwierige Algebra-Probleme auf PhD-Niveau |
| FLTEval Pass@1 | 28,9 Prozent | Realitätsnäherer Proof-Engineering-Benchmark |
| FLTEval Pass@8 | 43,2 Prozent | Mehrere Versuche auf echten Lean-Proof-Aufgaben |
miniF2F vollständig zu sättigen ist ein starkes Signal, aber nicht automatisch der wichtigste Teil der Meldung. Wenn ein Benchmark bei 100 Prozent angekommen ist, verliert er als Differenzierungsmaßstab an Aussagekraft. Spannender sind PutnamBench, FATE-H, FATE-X und FLTEval, weil sie längere Beweisketten, abstraktere Mathematik oder realere Repository-Arbeit abbilden.
Bei PutnamBench gibt Mistral an, dass Leanstral 1.5 mit einem Testzeitbudget von bis zu 4 Millionen Token pro Versuch 587 von 672 Aufgaben löst. Außerdem beschreibt der Anbieter eine deutliche Test-Time-Skalierung: Bei 50.000 Token seien 44 Aufgaben gelöst worden, bei 200.000 Token 244, bei 1 Million Token 493 und bei 4 Millionen Token 587.
Das ist technisch wichtig, weil es zeigt, dass das Modell mit mehr Rechen- und Kontextbudget nicht nur mehr Text ausgibt, sondern tatsächlich mehr formale Probleme löst. Für Proof Engineering ist diese Skalierung plausibel: Lange Beweise brauchen Umwege, Hilfslemmata, Fehlerkorrekturen und mehrere Versuche.
Warum der Kostenvergleich auffällt
Mistral stellt Leanstral 1.5 auch über Kosten pro gelöstem Problem dar. Laut Anbieter liege Leanstral auf PutnamBench bei ungefähr 4 US-Dollar pro Problem. Seed-Prover 1.5 im High-Setting wird von Mistral mit geschätzt 300 US-Dollar oder mehr pro Problem eingeordnet, weil dieses Setting laut Blogpost mit einem Budget von 10 H20-Tagen pro Problem arbeitet. Aleph Prover nennt Mistral mit 54 bis 68 US-Dollar pro Problem.
Diese Zahlen sollte man vorsichtig lesen. Es sind Herstellerangaben und hängen stark davon ab, wie Tokenbudget, Hardware, Parallelisierung und Erfolgsdefinition berechnet werden. Trotzdem ist die Richtung relevant: Wenn formale Verifikation praktisch werden soll, reicht ein gelegentlicher Rekordwert nicht aus. Das System muss wirtschaftlich genug sein, um es auf echte Repositories, viele Theoreme und wiederholte CI-ähnliche Prüfungen anzuwenden.
Genau hier positioniert Mistral Leanstral 1.5. Das Modell soll nicht nur in mathematischen Wettbewerbsaufgaben gut abschneiden, sondern Proof Engineering für Softwareprojekte günstiger und breiter zugänglich machen.
Der reale Test: Bugs in Open-Source-Repositories
Der interessanteste Abschnitt der Mistral-Ankündigung ist nicht der miniF2F-Wert, sondern der Bug-Finding-Test. Mistral beschreibt eine Pipeline, bei der Aeneas Rust-Code nach Lean übersetzt. Leanstral soll anschließend aus dem Code vermutete Korrektheitseigenschaften ableiten und versuchen, diese Eigenschaften zu beweisen.
Wenn vier Beweisversuche scheitern, versucht das System laut Mistral auch die Negation der Eigenschaft zu beweisen. So kann aus einem gescheiterten Beweis ein Hinweis auf eine echte Verletzung werden. In 57 getesteten Repositories habe die Pipeline 47 verletzte Eigenschaften markiert. Davon hätten 11 auf echte Bugs hingewiesen, 5 davon seien zuvor nicht auf GitHub gemeldet gewesen.
Ein Beispiel nennt Mistral aus der Bibliothek datrs/varinteger. Bei einem Spezialfall der Zigzag-Decoding-Logik sei ein Überlauf aufgetreten: Bei Eingabe des maximalen 64-Bit-Werts führe ein Ausdruck mit value plus 1 zu einem Overflow. Laut Mistral könne das im Debug-Modus zu Crashes und im Release-Modus zu stiller Datenkorruption führen.
Das ist der Punkt, an dem formale Verifikation über akademische Demos hinausgeht. Ein Fuzzer kann viele Eingaben testen, aber er beweist keine allgemeinen Eigenschaften. Ein Theorem-Prover kann allgemeiner argumentieren, ist aber traditionell aufwendig. Wenn ein KI-Agent den Schritt von Code zu Eigenschaft zu Gegenbeweis teilweise automatisiert, entsteht ein neuer Werkzeugtyp zwischen statischer Analyse, Fuzzing und menschlichem Proof Engineering.
Was Leanstral 1.5 für KI-Agenten bedeutet
Leanstral 1.5 passt in einen größeren Trend: KI-Agenten werden nicht nur daran gemessen, ob sie Code schreiben, sondern ob sie überprüfbare Zwischenergebnisse erzeugen. Ein klassischer Coding-Agent kann ein Feature implementieren, aber Tests können lückenhaft sein. Ein Formal-Verification-Agent muss mit einem strengen Checker zusammenarbeiten.
Das hat drei Folgen:
- Weniger Halluzinationstoleranz: Ein falscher Lean-Beweis kompiliert nicht. Das Modell bekommt direktes Feedback.
- Bessere Agenten-Schleifen: Compiler-Fehler, Typinformationen und Language-Server-Ausgaben liefern konkrete Korrektursignale.
- Höhere Relevanz für sicherheitskritische Software: Dort reicht „sieht plausibel aus“ nicht aus; Eigenschaften müssen nachvollziehbar geprüft werden.
Leanstral ist damit auch ein Beispiel dafür, wohin spezialisierte KI-Modelle gehen können. Nicht jedes relevante Modell muss ein allgemeiner Chatbot sein. Für Bereiche wie Mathematik, Verifikation, Compilerbau, Chipdesign oder sicherheitskritische Software können eng trainierte Modelle mit harter Feedbackschleife wertvoller sein als ein noch größerer Allzweck-Assistent.
Grenzen und offene Fragen
Trotz der starken Zahlen bleibt die Quellenlage begrenzt. Die Benchmark-Werte stammen aus der Mistral-Ankündigung. Unabhängige Reproduktionen, Drittanbieter-Tests und breitere Repository-Evaluationen stehen noch aus. Gerade bei formaler Verifikation ist wichtig, wie Aufgaben ausgewählt wurden, welche Budgets verwendet wurden und ob die Pipeline auch auf ungepflegten, schlecht dokumentierten oder sehr großen Codebasen stabil bleibt.
Auch der Tokenverbrauch ist zweischneidig. Mistral hebt hervor, dass Leanstral über Millionen Token hinweg bessere Ergebnisse erzielt. Das ist für schwierige Beweise sinnvoll, aber in der Praxis stellt sich die Frage, welche Aufgaben diesen Aufwand rechtfertigen. Für eine kritische Kryptografie-Bibliothek kann ein teurer formaler Beweis sinnvoll sein. Für alltäglichen Anwendungscode ist ein mehrmillionen-tokenlanger Agentenlauf nur dann attraktiv, wenn er gut priorisiert wird.
Dazu kommt die Integrationsfrage. Leanstral 1.5 ist laut Mistral über Hugging Face und API verfügbar, empfohlen wird die Nutzung mit Mistral Vibe. Für Teams zählt aber nicht nur der Modellzugang. Entscheidend sind Workflows: Wie werden Zieltheoreme definiert? Wie landen Proofs im Review? Wie werden falsche Eigenschaften erkannt? Wie verhindert man, dass ein Agent formal korrekte, aber praktisch irrelevante Eigenschaften beweist?
Einordnung gegenüber allgemeinen LLMs
Leanstral 1.5 konkurriert nicht direkt mit Modellen wie GPT, Claude oder Gemini im allgemeinen Chat-Einsatz. Der bessere Vergleich sind Proof- und Formal-Reasoning-Systeme wie Seed-Prover, Goedel-Architect, Aleph Prover oder spezialisierte Lean-Agenten. Mistral nennt genau solche Systeme in der Benchmark-Einordnung.
Der wichtigste Unterschied ist die Kombination aus offenem Modellzugang, relativ niedrigen aktiven Parametern und Agenten-Workflow. Wenn die Herstellerzahlen halten, könnte Leanstral 1.5 für Forschungsteams, Open-Source-Projekte und Unternehmen interessant werden, die Lean 4 bereits nutzen oder formale Methoden testen wollen.
Für die breite Entwicklerwelt bleibt die Hürde aber hoch. Lean 4 ist mächtig, aber nicht trivial. Ein Modell, das Lean-Proofs schreibt, ersetzt nicht automatisch das Verständnis formaler Spezifikation. Es kann Arbeit beschleunigen, doch jemand muss entscheiden, welche Eigenschaft überhaupt bewiesen werden soll.
Warum dieser Release wichtig ist
Leanstral 1.5 zeigt, dass der KI-Markt nicht nur aus immer allgemeineren Assistenten besteht. Ein offenes Spezialmodell für formale Verifikation ist ein anderer Weg: engerer Anwendungsfall, härtere Erfolgskriterien, klarere Rückmeldeschleifen.
Wenn Mistrals Angaben unabhängig bestätigt werden, ist Leanstral 1.5 ein relevanter Schritt für automatisiertes Proof Engineering. Besonders die Verbindung aus Lean 4, Repository-Agenten, Bug-Finding-Pipeline und offenem Zugang macht den Release technisch interessant.
Die nüchterne Einordnung lautet: Leanstral 1.5 ist kein Allzweckmodell und kein Beweis dafür, dass KI jetzt beliebige Software korrekt verifizieren kann. Es ist aber ein starkes Signal, dass formale Verifikation durch spezialisierte KI-Agenten praktischer werden könnte. Für sicherheitskritische Software, mathematische Bibliotheken und komplexe Open-Source-Projekte ist das deutlich relevanter als der nächste Chatbot-Benchmark.
Quellen und weiterführende Links
- Mistral AI: Leanstral 1.5: Proof Abundance for All
- Hugging Face: Mistral Leanstral 1.5 119B A6B
- Mistral Model Card zu Leanstral 1.5
- FLTEval von Mistral
- Leanstral SafeVerify Fork
- Weitere LLM-Analysen auf KI Tools Update
FAQ
Was ist Leanstral 1.5?
Leanstral 1.5 ist ein von Mistral AI veröffentlichtes Spezialmodell für formale Verifikation und Proof Engineering in Lean 4. Laut Mistral ist es unter Apache-2.0 lizenziert, auf Hugging Face verfügbar und zusätzlich über einen kostenlosen API-Endpunkt nutzbar.
Ist Leanstral 1.5 öffentlich verfügbar?
Ja, laut Mistral sind die Gewichte öffentlich auf Hugging Face verfügbar, und es gibt einen kostenlosen API-Zugang. Damit ist der Zugang offener als bei vielen geschlossenen Frontier-Modellen.
Welche Benchmarks nennt Mistral für Leanstral 1.5?
Mistral meldet 100 Prozent auf miniF2F, 587 von 672 gelöste PutnamBench-Aufgaben, 87 Prozent auf FATE-H und 34 Prozent auf FATE-X. Diese Werte sind Herstellerangaben und sollten durch unabhängige Tests bestätigt werden.
Warum ist Leanstral 1.5 für Entwickler relevant?
Das Modell kann laut Mistral nicht nur mathematische Beweise bearbeiten, sondern auch Eigenschaften von echtem Code untersuchen. In einer Mistral-Pipeline wurden bei 57 Repositories mehrere echte Bugs gefunden, darunter 5 zuvor nicht gemeldete Fehler.
Ersetzt Leanstral 1.5 normale Softwaretests?
Nein. Leanstral 1.5 kann formale Verifikation unterstützen, ersetzt aber keine Tests, Reviews oder menschliche Spezifikationsarbeit. Der Nutzen liegt vor allem dort, wo präzise Eigenschaften definiert und formal überprüft werden können.
