Innerhalb weniger Tage sind drei Sprachmodelle mit offenen Gewichten erschienen, die sich an Entwicklungsteams richten. Offene Gewichte heißt: Die trainierten Modellparameter stehen zum Download bereit und lassen sich auf eigener Infrastruktur betreiben, statt ausschließlich über die API eines Anbieters. Für Projekte mit strengen Datenschutzanforderungen oder kalkulierbaren Kostenzielen ist das der entscheidende Unterschied.

Gemeinsam ist den drei Veröffentlichungen der Anwendungsfokus: agentisches Programmieren. Gemeint sind Modelle, die nicht nur Codeschnipsel vorschlagen, sondern mehrstufige Aufgaben abarbeiten – Dateien lesen, Befehle in einer Shell ausführen, Testergebnisse auswerten und daraus den nächsten Schritt ableiten.

Ripple-65B Preview: schlank und auf Terminalaufgaben getrimmt

Ricursive Intelligence hat Ripple-65B Preview veröffentlicht, ein offenes Modell mit 65 Milliarden Parametern. Laut Unternehmen erreicht es auf dem Coding-Benchmark TerminalBench 2.1 den Bestwert unter offenen US-Modellen. TerminalBench misst, wie zuverlässig ein Modell Aufgaben in einer Kommandozeilenumgebung tatsächlich zu Ende bringt – ein Szenario, das dem Alltag in Entwicklungsprojekten näher kommt als reine Code-Vervollständigung.

Bemerkenswert ist die genannte Kostenangabe: 32 Millionen Dollar Gesamtkosten für das Modell. Auf anderen Benchmarks bleibt Ripple allerdings deutlich hinter dem zeitgleich veröffentlichten Inkling 2 Small zurück. Das Modell ist damit kein Allrounder, sondern ein Spezialist – was für klar umrissene Einsatzszenarien durchaus genügen kann.

Inkling 2 Small: stärkste westliche Option, aber hungrig

Thinking Machines, das Start-up der ehemaligen OpenAI-CTO Mira Murati, positioniert Inkling 2 Small als stärkstes westliches Open-Weight-Modell. Technisch handelt es sich um ein Mixture-of-Experts-Modell mit 594 Milliarden Parametern. Bei dieser Architektur ist das Modell in viele Teilnetze – die Experten – aufgeteilt, von denen pro Verarbeitungsschritt nur ein Bruchteil aktiviert wird. Das senkt den Rechenaufwand gegenüber einem gleich großen dichten Modell.

Die bessere Agentenleistung wird jedoch durch einen deutlich höheren Tokenverbrauch erkauft. Das ist ein Punkt, der in Benchmark-Tabellen selten auftaucht, in der Praxis aber direkt auf die Rechnung durchschlägt: Ein Modell, das für dieselbe Aufgabe mehr Zwischenschritte und längere Gedankengänge produziert, verbraucht mehr Rechenzeit – unabhängig davon, ob über API abgerechnet oder selbst gehostet wird.

Der Name „Small“ bezieht sich offenkundig auf die Einordnung innerhalb der eigenen Modellfamilie, nicht auf den absoluten Ressourcenbedarf. Für den Eigenbetrieb eines Modells dieser Größenordnung ist entsprechende GPU-Infrastruktur erforderlich.

ERNIE 5.5 Flash Base: Rohmaterial statt fertiger Assistent

Baidu verfolgt mit ERNIE 5.5 Flash Base einen anderen Ansatz. Das Mixture-of-Experts-Modell hat 280 Milliarden Parameter, von denen pro Token nur 14 Milliarden aktiv sind – ein Verhältnis, das auf effizienten Betrieb ausgelegt ist. Vortrainiert wurde es auf 33,5 Billionen Token.

Entscheidend ist die Freigabe als Basismodell ohne Feintuning. Ein solches Modell ist kein einsatzfertiger Chat- oder Coding-Assistent, sondern Ausgangsmaterial: Es hat Sprach- und Weltwissen aufgenommen, wurde aber nicht darauf trainiert, Anweisungen zu befolgen oder in einem bestimmten Stil zu antworten. Diese Anpassung überlässt Baidu der Community und damit Organisationen, die eigene Trainingsdaten und Zielvorgaben einbringen wollen.

Für Unternehmen bedeutet das zweierlei. Der Aufwand bis zum produktiven Einsatz ist höher als bei einem fertig instruierten Modell. Dafür ist der Spielraum größer, das Verhalten auf eine konkrete Domäne, einen bestimmten Codebestand oder interne Konventionen auszurichten.

Wie sich die Angaben zueinander verhalten

Die drei Meldungen stammen aus derselben Quelle und liegen zeitlich eng beieinander, sind aber nicht direkt vergleichbar. Ripple-65B wird über einen spezifischen Terminal-Benchmark eingeordnet, Inkling 2 Small über einen breiteren Leistungsanspruch, ERNIE 5.5 Flash Base vor allem über Architektur und Trainingsumfang. Ein sauberer Dreiervergleich lässt sich daraus nicht ableiten.

Hinzu kommt: Sämtliche Leistungsangaben stammen von den jeweiligen Anbietern. Unabhängige Nachprüfungen stehen in der Regel aus, und Benchmark-Bestwerte in einer eng definierten Kategorie – etwa „offene US-Modelle“ – sagen wenig über das Verhalten in einem konkreten Projekt aus.

Worauf es bei der Bewertung ankommt

Für die Auswahl eines offenen Modells sind in der Praxis andere Fragen relevant als die reine Benchmark-Platzierung:

  • Tatsächlicher Ressourcenbedarf im Betrieb: Parameterzahl allein genügt nicht. Bei Mixture-of-Experts-Modellen müssen alle Parameter im Speicher liegen, auch wenn pro Token nur ein Teil rechnet.
  • Tokenverbrauch pro gelöster Aufgabe: Ein Modell mit besseren Ergebnissen, das dafür deutlich mehr Schritte benötigt, kann in der Gesamtrechnung teurer ausfallen.
  • Reifegrad: Preview-Stände und Basismodelle ohne Feintuning erfordern zusätzliche Arbeit, bevor sie produktiv nutzbar sind.
  • Lizenz- und Herkunftsfragen: Offene Gewichte sind nicht automatisch mit jeder kommerziellen Nutzung vereinbar; die konkreten Bedingungen sind zu prüfen.
  • Eignung für den eigenen Technologie-Stack: Ein Modell, das in Terminalaufgaben stark ist, muss nicht gleich gut mit dem im Projekt eingesetzten Framework umgehen.

Einordnung für Web- und Softwareprojekte

Die Dichte an Veröffentlichungen zeigt, dass offene Modelle im Coding-Bereich zunehmend eine ernsthafte Alternative zu proprietären APIs darstellen – gerade dort, wo Quellcode oder Kundendaten das eigene Netz nicht verlassen dürfen. Realistisch ist das aber kein Selbstläufer: Betrieb, Anpassung und laufende Bewertung der Modellqualität binden Ressourcen, die bei einer API-Anbindung beim Anbieter liegen.

Für die meisten mittelständischen Projekte empfiehlt sich deshalb ein zweistufiges Vorgehen: zunächst den konkreten Anwendungsfall mit einem verfügbaren Dienst validieren, parallel die Architektur so auslegen, dass das Modell austauschbar bleibt. Dann lässt sich später ohne Bruch auf ein selbst gehostetes offenes Modell wechseln, wenn Datenschutz, Kosten oder Verfügbarkeit es nahelegen.

Quellen