Offene Gewichte, geschlossene Rezepte: Was vier Berichte über die wirklich ladbaren Modelle sagen

Das Argument für offene Gewichte beruhte stets auf einer Zusage: Man erhält die Datei und damit die Kontrolle. Vier zwischen Mai und September 2026 veröffentlichte Dokumente prüfen, wie viel von dieser Zusage dem Kontakt mit Messungen standhält. Sie stimmen in wenig überein. Sie stimmen aber darin überein, dass „offen“ weniger Arbeit leistet, als die Schlagzeilen vermuten lassen.

Die Vier-Monats-Zahl und was sie verbirgt

Mozilla veröffentlichte am 15. September Version 1.1 seines State of Open Source AI-Berichts, mit Daten bis zum 1. September, so Tom's Hardware. Der Hauptbefund: Das beste offene Modell lag auf dem Artificial Analysis Intelligence Index drei Punkte hinter dem geschlossenen Spitzenreiter bei 60% des Preises und zwei Punkte hinter Claude Fable 5 bei 30% des Preises. Mozillas Anpassung an METR-Task-Horizon-Daten beziffert den Abstand zwischen offenen und geschlossenen Modellen auf etwa 4,4 Monate, im Einklang mit Epoch AIs Schätzung von vier Monaten.

METR bewertet Modelle anhand der Längen von Aufgaben, gemessen in menschlicher Arbeitszeit, die sie zur Hälfte abschließen. Laut Mozillas geschätzter Anpassung bewältigen geschlossene Modelle Aufgaben, die menschlichen Experten 8 bis 12 Stunden in Anspruch nehmen. Offene Modelle erreichen dieses Niveau etwa vier Monate später, wobei sich die offene Fähigkeit laut Mozillas Berechnung alle 3,9 Monate verdoppelt, bei geschlossenen Modellen alle 5,5 Monate. Tom's Hardware verweist auf eine Einschränkung, die Mozilla selbst nennt: Die Vier-Monats-Zahl und der 30%-Token-Preis werden API zu API auf gehosteten Endpunkten zum Listenpreis gemessen.

Das Hardware-Diagramm ist das unbequeme

Derselbe Bericht enthält ein Diagramm, das sich unangenehm neben die Schlagzeile stellt. Das beste offene Modell, das auf einen Server passt, erzielt 52,6 Punkte; das beste, das auf eine GPU passt, 40. Der Abstand zum Spitzenwert beträgt jeweils 10 und 23 Punkte, eine größere Lücke als der Fähigkeitsfortschritt von vier Monaten.

Der native MXFP4-Checkpoint von Kimi K3 belegt etwa 1,56TB über 96 Shards. Mozillas Serving-Konfiguration listet 64 oder mehr Beschleuniger, während vLLM mindestens acht GB300-GPUs erfordert, mit mehreren Knoten für Produktionsverkehr. Die Formulierung im Bericht selbst lautet, dies sei offen, aber für die meisten, die es besitzen, nicht ausführbar. Tom's Hardware nannte den Speicherbedarf im Juli nahe an 1,5TB. Es gibt Ausnahmen. Thinking Machines' Inkling-Small, unter der Apache 2.0-Lizenz, hat eine NVFP4-Version, die auf eine B300 bei einem Minimum von 180GB passt. Das ist ein echter Datenpunkt, und es ist ein Modell.

Offene Gewichte sind kein Open Source, und der Unterschied trägt Last

Die Open Source Initiative machte den Unterschied in einem Beitrag vom 19. September explizit. KI-Modelle haben drei Hauptkomponenten: Trainingsdaten, Gewichte und Parameter sowie der Code für Datenaufbereitung und Training. Offen-gewichtige Veröffentlichungen veröffentlichen die Gewichte. Sie veröffentlichen nicht den Rest.

Offen-Gewichte erlauben es, einige Freiheiten auszuüben, aber nicht alle und nur in einem bestimmten Ausmaß. Wahres Open Source KI erlaubt es, alle vier ohne Einschränkung auszuüben.

Die vier betreffenden Freiheiten sind Nutzung, Studium, Modifikation und Weitergabe ohne Erlaubnis des Rechteinhabers. Die OSI beziffert den nachfragseitigen Wert des Open-Source-Ökosystems auf 8.800.000.000.000 Dollar und argumentiert, dass offen-gewichtige Modelle die Modifikation einschränken und ein volles Studium verhindern, weil ohne Code und Trainingsdaten nicht geprüft werden kann, warum ein Modell eine Ausgabe produziert hat. Mozillas Bericht zählt laut Tom's Hardware 16 bemerkenswerte offene Veröffentlichungen, von denen keine das Datendreizzept liefert, das die Definition der Open Source Initiative verlangt.

Was die Memorization-Forschung zu den Urheberrechtsstreitigkeiten beiträgt

Ein Papier auf arXiv, erstmals am 18. Mai 2025 eingereicht und bis zum 20. Juli 2026 überarbeitet, misst, wie viel von 200 Büchern 14 offen-gewichtige LLMs tatsächlich behalten. Die Autoren sind A. Feder Cooper, Mark A. Lemley, Allison Casasola, Ahmed Ahmed, Aaron Gokaslan, Amy B. Cyphert, Christopher De Sa, Daniel E. Ho und Percy Liang.

Ihr Rahmen ist pointiert: Kläger und Beklagte in Urheberrechtsverfahren zu generativer KI erheben umfassende, gegensätzliche Behauptungen über Memorization. Beide Positionen vereinfachen laut dem Papier die Beziehung zwischen Memorization und Urheberrecht drastisch. In über 3.000 Experimenten stellen die Autoren fest, dass die meisten LLMs die meisten Bücher nicht memorisieren, weder ganz noch teilweise. Aber die Ausnahmen sind relevant. Llama 3.1 70B memorisiert laut dem Papier einige Bücher vollständig, einschließlich Harry Potter and the Sorcerer's Stone. Die Memorization ist dort so umfangreich, dass das ganze Buch fast wortwörtlich deterministisch extrahiert werden kann, indem die ersten wenigen Wörter als Prompt verwendet werden. Die Autoren stellen fest, dass die Ergebnisse erhebliche Implikationen für Urheberrechtsfälle haben, auch wenn sie nicht eindeutig eine Seite bevorzugen.

Die kleineren, seltsameren Deployment-Fälle

Nicht jede offen-gewichtige Veröffentlichung jagt der Frontier hinterher. Superwhisper veröffentlichte S1-mini, einen 0.6B-Parameter-Textnormalisierer, feinjustiert aus Qwen/Qwen3-0.6B, unter Apache 2.0 plus einer Namensklausel. Er erledigt eine Aufgabe: Roh-Textausgaben von Speech-to-Text als sauberen geschriebenen Text umschreiben. Auf einem Halte-Satz von 7.519 englischen Fällen erreicht er 94,8% Token-Genauigkeit, und der quantisierte Build ist eine 462 MiB große Datei, die auf einem Laptop-CPU läuft. Die Modellkarte stellt klar, dass es kein Chat-Modell ist und keine allgemeinen Anweisungen befolgt.

Die Modellkarte dokumentiert auch eine Buchhaltungssonderheit im Hub: Die Seitenleiste berichtet 0.8B Parameter, weil die 155.6M-Parameter-Einbettung doppelt gezählt wird, was 751.6M Tensor-Elemente gegenüber 596.0M eindeutigen Parametern ergibt. Das Layout ist von Qwen3-0.6B geerbt, das aus demselben Grund 0.8B im Hub berichtet.

Die Überlegungen eines Käufers und ihre Grenzen

Ein Deployment-Bericht von James Cruce, veröffentlicht am 22. September, beschreibt die Wahl von Laya, einem 421M-Parameter-Entscheidungsmodell mit offenem Gewicht, einem ModernBERT-large-Encoder und einer 1.024-Token-Grenze, gegenüber TypeSafes gehostetem Jev-Dienst. Der Herausgeber von Laya trainierte es auf vier synthetischen Workflows: Agent-Beobachtbarkeit, Kundenservice, Rechnungsverarbeitung und Sicherheitsvorfälle.

Cruce ist explizit darüber, was der Vergleich beweist. TypeSafe listet Jev mit 0,042 Dollar pro Million Eingabe-Tokens ohne Ausgabe-Token-Gebühr und mit bis zu 255 Optionen. Laya läuft auf einer nur loopback-zugänglichen API auf seinem Mac Studio mit M3 Ultra und 256 GB Unified Memory, sodass routinemäßige Entscheidungen die Maschine nie verlassen. Er stellt klar, dass Privatsphäre und Kontrolle die entscheidenden Gründe waren und Kosten ein Nebeneffekt, ohne eine Einsparungszahl zu nennen. Er hat nicht getestet, ob Laya Jev im Allgemeinen schlägt.

Er weist auch darauf hin, dass die Modellkarte warnt, Laya sei überzuversichtlich und brauche domänenspezifische Kalibrierung, und dass eine eingegebene Antwort strukturell perfekt und faktisch falsch sein kann. Sein Schluss ist eng: Behandeln Sie es als Empfehlungssystem innerhalb eines Programms, nie als Quelle für Erlaubnis oder Wahrheit.

Was standhält

Die vier Dokumente zeigen in dieselbe Richtung, ohne dasselbe zu sagen. Mozillas Daten besagen, dass offene Gewichte bei der Fähigkeit nahe sind und bei gehostetem Listenpreis viel billiger, während sein eigenes Hardware-Diagramm sagt, dass die Modelle an der Spitze nicht etwas sind, das die meisten ausführen können. Die OSI sagt, dass die Bezeichnung über ihre Bedeutung hinaus gedehnt wird. Das Memorization-Papier sagt, dass die Prozessargumente auf beiden Seiten zu breit sind für das, was die Experimente zeigen. Cruces Bericht sagt, dass der entscheidende Grund, offene Gewichte zu wählen, die Kontrolle darüber sein könnte, wohin die Daten gehen, nicht die Benchmark-Position.

Mozillas eigene Diagrammunterschrift lautet: „Die Lücke setzt sich bei jedem Release-Zyklus zurück.“ Seine Daten enden am 1. September, und die Live-Boards haben sich seitdem bewegt. Artificial Analysis ist zu Index v4.3 mit einem anderen Bewertungssatz gewechselt; das Live-Board hat Claude Fable 5.1 bei 53 auf seiner höchsten Anstrengungseinstellung mit Kimi K3 bei 44. Das Terminal-Bench 2.1-Board von vals.ai, aktualisiert am 11. September, wird von GPT-6 Astra mit 87,27% angeführt, mit Fable 5.1 bei 85,02%.

Ein weiterer Punkt bleibt in den Unterlagen ungeklärt. K3 trägt eine Anschuldigung, die im gemeinsamen Ratgeber AA26-251A von NSA/CISA/FBI vom 8. September detailliert wird, die Mozillas Bericht als „behauptet, aber unbewiesen“ bezeichnet: dass Moonshot Claude Fable 5-Daten extrahiert hat, um K3 durch Destillation zu trainieren. Am 17. Juli hatte Artificial Analysis K3 bei 57 gegenüber Fables 5 60. Am 1. September hatte Mozilla es zwei Punkte zurück. Ob diese Verengung von unabhängigen Training oder von der behaupteten Extraktion kam, ist etwas, das keines dieser vier Dokumente feststellt.