Die Frage ist nicht mehr, ob ein offenes Modell mit einem proprietären konkurrieren kann, sondern bei welchen konkreten Aufgaben es das tut und zu welchem realen Preis. Im Laufe des Jahres 2025 haben viele Teams einen Teil ihres KI-Stacks auf herunterladbare Gewichte migriert und dabei zwei Dinge entdeckt: dass die Einsparungen bei der API nicht immer die Infrastrukturkosten aufwiegen und dass die Lizenz mehr zählt, als es scheint, wenn das Produkt in die Produktion geht.
Hier finden Sie kein flaches Ranking. Sie finden, welche Familien offener Modelle verteidigungsfähige Ergebnisse liefern, wo sie gegenüber den kostenpflichtigen Modellen zurückbleiben und wie Sie mit Kriterien entscheiden, die den nächsten Launch überstehen.
Die reale Landkarte: Was „Open Source» bei Sprachmodellen bedeutet
Bevor man vergleicht, sollte man eine Mehrdeutigkeit auflösen, die zu falschen Entscheidungen führt. Kaum ein Modell, das als offen bezeichnet wird, erfüllt die strenge Definition der OSI. Üblich sind herunterladbare Gewichte mit Community-Nutzungslizenzen, die Einschränkungen auferlegen: Begrenzungen der monatlichen Nutzerzahl, Verbot der konkurrierenden Nutzung, Pflicht zur Nennung des Modellnamens in der Oberfläche oder Klauseln zur kommerziellen Skalierung.
Das hat eine praktische Konsequenz: Ein Modell kann für das Prototyping kostenlos und beim Wachstum – rechtlich gesehen – teuer sein. Die Llama-Familie ist das klassische Beispiel einer Lizenz mit Nutzerschwelle; Qwen und DeepSeek veröffentlichen einen Großteil ihrer Gewichte unter Apache 2.0, was die kommerzielle Integration ohne rechtliche Reibung erleichtert; Mistral kombiniert Apache-Lizenzen bei seinen kleinen Modellen mit Forschungslizenzen bei den großen. Bevor Sie anhand von Benchmarks auswählen, prüfen Sie die Lizenz des konkreten Modells, das Sie einsetzen werden, nicht die des Repositorys im Allgemeinen.
Offene Modelle, die 2025 einen Test verdienen
Llama (Meta) bleibt der De-facto-Standard des Ökosystems. Sein Vorteil ist nicht die rohe Leistung, sondern die Reife des Toolings: fertige Quantisierungen, Unterstützung in Ollama, vLLM und llama.cpp sowie eine Community, die Fragen schnell beantwortet. Die 8B-Variante ist ein Arbeitstier für Klassifizierung, Extraktion und Zusammenfassungen; die größeren Größen konkurrieren beim Reasoning, erfordern aber Hardware, die selten auf dem Schreibtisch eines Entwicklers steht.
Qwen hat bei mehrsprachigen Aufgaben und Code-Aufgaben an Boden gewonnen. Seine kleinen Versionen überraschen bei der SQL-Generierung und beim Verstehen von Anweisungen mit striktem Format, und die Apache-Lizenz bei vielen seiner Gewichte beseitigt die rechtliche Debatte. Bei Tests zur Extraktion strukturierter Daten aus ungeordnetem Text reicht ein mittelgroßes Qwen-Modell oft dort aus, wo ein großes proprietäres Modell überdimensioniert wäre.
DeepSeek hat gezeigt, dass ein Labor mit weniger Ressourcen wettbewerbsfähige Modelle für mathematisches Reasoning und Code veröffentlichen kann. Die Kehrseite ist die Undurchsichtigkeit bezüglich der Trainingsdaten und die Notwendigkeit, Verzerrungen in regulierten Domänen zu validieren.
Mistral vertritt einen europäischen Ansatz mit guten Ergebnissen bei Instruktionsaufgaben und einer aktiven Community rund um seine Quantisierungsformate.
Gemma (Google) bietet offene Gewichte mit einem konservativen Sicherheitsansatz, nützlich, wenn Sie ein Modell benötigen, das standardmäßig keine problematischen Inhalte erzeugt, wobei seine Lizenz ebenfalls Nutzungsbedingungen enthält.
Wo das offene Modell ohne Diskussion gewinnt
Es gibt Szenarien, in denen der Vergleich nicht einmal Sinn ergibt, weil der proprietäre Anbieter nicht bieten kann, was Sie brauchen.
Daten, die Ihre Infrastruktur nicht verlassen dürfen
Wenn Sie klinische Verläufe, Rechtsakten oder personenbezogene Daten unter strengen Vorschriften verarbeiten, erfordert das Senden von Prompts an eine externe API eine Risikoanalyse, die viele Rechtsabteilungen nicht genehmigen. Ein lokal ausgeführtes offenes Modell beseitigt die Datenübertragung. Es beseitigt nicht die Verantwortung: Sie müssen weiterhin protokollieren, welches Modell Sie verwendet haben, mit welcher Version und mit welchen Prompts, denn Nachvollziehbarkeit ist ebenfalls eine Pflicht.
Hohes und vorhersehbares Volumen
Wenn Ihre Last konstant ist und das Modell auf eine GPU passt, die Sie bereits haben, tendieren die Grenzkosten pro Token gegen null. Ein typischer Fall: die Klassifizierung Tausender täglicher Tickets in feste Kategorien. Ein auf 4 Bit quantisiertes 7-8B-Modell läuft auf einer Consumer-GPU und erledigt diese Aufgabe mit einer Genauigkeit, die nach einem leichten Feintuning mit eigenen Beispielen viel größere proprietäre Modelle in dieser engen Domäne erreicht. Der Schlüssel ist, dass die Aufgabe begrenzt ist; wenn Sie offenes Reasoning benötigen, ändert sich die Rechnung.
Kontrollierte Latenz und keine Abhängigkeit von Dritten
Für interaktive Anwendungen, bei denen 300 ms mehr die Erfahrung ruinieren, oder für Produkte, die sich einen Ausfall des Anbieters nicht leisten können, gibt die eigene Bereitstellung Kontrolle. Sie gibt auch die Pflicht, sie zu überwachen – etwas, das viele Teams unterschätzen.
Wo das kostenpflichtige Modell weiterhin die vernünftige Wahl ist
Ehrlichkeit verpflichtet, es zu sagen: Bei komplexem mehrstufigem Reasoning, beim Befolgen langer Anweisungen und bei Aufgaben, die Kontext von Hunderttausenden von Tokens erfordern, behalten die proprietären Frontier-Modelle ihren Vorsprung. Ein mittelgroßes offenes Modell kann eine korrekte Funktion schreiben; verlangt man von ihm, über ein ganzes Repository zu reasoning und eine kohärente Refaktorisierung vorzuschlagen, sind die Ergebnisse oft fragil.
Es gibt auch einen Faktor, der in Vergleichen selten auftaucht: die Wartungskosten. Ein offenes Modell zu wählen bedeutet, Gewichte zu versionieren, Updates zu verwalten, kontinuierliche Evaluierung aufzusetzen und zu akzeptieren, dass die Community eines Tages die Quantisierung, die Sie nutzen, nicht mehr pflegt. Diese Arbeit hat einen Preis in Ingenieursstunden, der in kleinen Teams die API-Ausgaben über Monate hinweg übersteigt.
Ein häufiger Fehler, den ich immer wieder beobachtet habe
Teams, die auf ein offenes Modell migrieren, weil es in einem öffentlichen Benchmark gut abschneidet, und dann feststellen, dass ihr konkreter Anwendungsfall – zum Beispiel das Extrahieren von Feldern aus gescannten Rechnungen mit heterogenen Vorlagen – systematisch scheitert. Der Benchmark maß allgemeines Reasoning, nicht die Fähigkeit, ein JSON-Schema mit verschachtelten Feldern und Nullwerten einzuhalten. Die Lehre: Stellen Sie ein Evaluierungsset mit 50-100 realen Beispielen aus Ihrer Domäne zusammen, bevor Sie entscheiden. Wenn das offene Modell diesen Test nicht besteht, ist die Einsparung fiktiv.
Wie man vergleicht, ohne in das Rauschen der Rankings zu geraten
Die Leaderboards ändern sich jede Woche und vermischen Aufgaben, die sich nicht ähneln. Ein nützlicherer Ansatz ist, Ihre eigene Entscheidungsmatrix mit vier Achsen aufzubauen:
- Lizenz und Compliance: Erlaubt sie kommerzielle Nutzung ohne Schwellen? Verlangt sie Namensnennung? Was passiert, wenn Sie ein bestimmtes Volumen überschreiten?
- Hardware-Eignung: Passt sie auf Ihre GPU mit der Quantisierung, die Sie benötigen? Welchen realen Durchsatz erzielen Sie mit vLLM oder llama.cpp?
- Qualität in Ihrer Domäne: Ergebnisse in Ihrem Evaluierungsset, nicht in MMLU.
- Gesamtkosten: API gegenüber Infrastruktur plus Wartungsstunden.
Ein technisches Detail, das Unterschiede macht und oft übersehen wird: Die Quantisierung beeinträchtigt manche Aufgaben stärker als andere. Kreative Generierung verträgt 4 Bit gut; mathematisches Reasoning und präzise Datenextraktion leiden mehr. Dieselbe Aufgabe mit dem Modell in fp16 und in quantisierter Form zu testen, zeigt Ihnen, ob die VRAM-Einsparung den Verlust rechtfertigt.
Hybride Strategie: Was in der Praxis funktioniert
Die Dichotomie kostenlos gegen kostenpflichtig ist irreführend. Die Architektur, die in realen Projekten die beste Leistung bringt, kombiniert beides: ein kleines offenes Modell für den Großteil des Traffics (Klassifizierung, Filterung, kurze Zusammenfassungen, FAQ-Antworten) und ein proprietäres Modell als Rückfall für die Anfragen, die das kleine Modell wegen geringer Konfidenz weiterleitet. Dieses Muster senkt die Kosten, ohne die Qualität in den schwierigen Fällen zu opfern, und ist gegenüber dem Business leichter zu rechtfertigen als eine vollständige Migration.
Man sollte auch bedenken, dass es „kostenlos» bei der Inferenz nicht gibt: Jemand zahlt den Strom, die GPU und die Zeit derjenigen, die die Bereitstellung warten. Die richtige Frage ist nicht, welches kostenlos ist, sondern welches für Ihr Volumen und Ihr Team geringere Gesamtkosten verursacht.
Worauf in den kommenden Monaten zu achten ist
Das Tempo der Veröffentlichung offener Gewichte sinkt nicht, und die Lücke zu den Frontier-Modellen schließt sich bei einigen Aufgaben, während sie bei anderen bestehen bleibt. Zwei Fronten verdienen Aufmerksamkeit: die Lizenzen, die dazu tendieren, strenger zu werden, wenn ein Modell populär wird, und die Evaluierungswerkzeuge, die weiterhin das schwächste Glied sind. Ein Modell ohne ein gutes eigenes Evaluierungssystem ist eine Blackbox mit guter Presse.
Wenn ich das Kriterium zusammenfassen müsste: Testen Sie offene Modelle zuerst bei begrenzten und messbaren Aufgaben, reservieren Sie die proprietären für das, was umfassendes Reasoning erfordert, und treffen Sie keine Entscheidung ohne ein Evaluierungsset, das mit Ihren eigenen Daten erstellt wurde. Das ist der einzige Vergleich, der im nächsten Monat nicht veraltet ist.