Kolibri: Aktive Parameter sind nur ein Teil des Deployment-Budgets

Am 3. Oktober veröffentlichte Aleph Alpha Kolibri, ein Mixture-of-Experts-Modell mit offenen Gewichten für Deutsch und Englisch unter Apache 2.0. Die Modellkarte nennt insgesamt 78B Parameter und 3.46B aktive Parameter pro Token. Die Zahlen beschreiben unterschiedliche Aspekte desselben Modells. Die kleinere Zahl bedeutet nicht, dass der Download oder das bereitgestellte Modell nur 3.46B umfasst. [1] [2]

In der öffentlichen Reddit-Diskussion geht es unter anderem um private Hardware und den Kontext von einer Million Token. Daraus ergibt sich eine sinnvolle Frage vor einer Anschaffung: Welche Ressource beschreibt die hervorgehobene Zahl eigentlich? Aus unserer Sicht braucht jede Bereitstellungsentscheidung getrennte Budgets für die Berechnung pro Token, die vorgehaltenen Gewichte und den Zustand der Anfragen. Keines ersetzt die anderen beiden.

Die FP8-Modellkarte nennt einen Speicherbedarf der Gewichte von etwa 78 GB. Für die separat veröffentlichte BF16-Version werden etwa 156 GB angegeben. Das sind Schätzungen des Herausgebers für die Gewichte, keine Zusage, dass ein Rechner mit genau dieser Speichermenge die gewünschte Arbeitslast bedienen kann. Die Präzision verändert das Speicherbudget; die Sparsität betrifft die für jedes Token ausgewählten Berechnungen. [2] [3]

Die Modellkarte erklärt ausdrücklich, dass das gesamte Modell im Speicher gehalten werden muss, obwohl jeweils nur ein Teil aktiv ist. Ein für ein Token ungenutzter Experte kann für das nächste benötigt werden. Eine belastbare Kapazitätsplanung berücksichtigt deshalb auch Anfrage-Caches, Laufzeitpuffer und Betriebsreserven. Den Gesamtspeicherbedarf anhand des Anteils aktiver Parameter herunterzurechnen, ist nicht zulässig. [2]

Offloading oder weitere Quantisierung können zusätzliche Möglichkeiten eröffnen. Eine denkbare Möglichkeit ist aber noch keine getestete Konfiguration. Datenübertragungen, Präzisionsänderungen und andere Rechenkerne können Latenz oder Qualität beeinflussen. Jede vorgeschlagene Konfiguration mit Consumer-Hardware sollte daher als Experiment mit eigenen Abnahmekriterien gelten. Aus der Zahl aktiver Parameter lässt sich keine Kompatibilität ableiten.

Kolibris Modellkarte unterscheidet zwischen einer nativ trainierten Kontextlänge von 262,144 Token und einer Validierung bis 1,048,576 Token. Für komplexe Aufgaben sowie latenz- und durchsatzkritisches Serving empfiehlt sie höchstens 262,144 Token. Auch der Abschnitt zu langem Kontext im Bericht beschreibt eine aufgabenabhängige Verschlechterung jenseits der trainierten Länge. Erweiterte Grenze, Empfehlung und Nachweise für die jeweilige Arbeitslast gehören zusammen. [2] [4]

Angenommen, mehrere Personen sollen gleichzeitig lange Dokumente abfragen. Dass ein Server eine sehr lange Anfrage annehmen kann, zeigt noch nicht, wie viele solcher Anfragen er gleichzeitig gut verarbeitet. Anfragezustände konkurrieren um Speicher, die Verarbeitung der Eingaben um Rechenleistung. Messen Sie die Wartezeit bis zur ersten Antwort, die Gesamtdauer und den gleichzeitigen Bedarf mit den tatsächlichen Dokumenten. Aus der maximalen Kontextlänge wird dadurch noch kein Leistungsversprechen.

Langer Kontext bleibt nützlich. Zusammenhängende Belege gemeinsam vorzuhalten, kann die Nachteile einer Zerstückelung verringern. Entscheidend ist, ob das zusätzliche Material die Aufgabe ausreichend verbessert, um seinen Ressourcenbedarf zu rechtfertigen. Vergleichen Sie eine kompakte, relevante Eingabe mit dem vollständigen Dokument und prüfen Sie sowohl die Antwort als auch die sie stützenden Passagen.

Aleph Alphas Bericht misst den Serving-Durchsatz auf einem Knoten mit acht B200-GPUs und synthetischen Prompts. Er durchsucht geeignete Parallelisierungskonfigurationen, misst nahe der durch den KV-Cache begrenzten Parallelkapazität und berichtet die schnellste gemessene Konfiguration für die Dekodierung. Außerdem schätzt er den Durchsatz des dekodierten Textes anhand der tokenizerabhängigen Bytezahl pro Token. Diese Bedingungen sind für die Einordnung des Qualitäts-Kosten-Vergleichs wesentlich. [4]

Dekodierdurchsatz bei vielen gleichzeitigen Anfragen kann für einen stark ausgelasteten Dienst oder umfangreiche Generierungsaufgaben relevant sein. Er sagt aber nicht direkt, wie lange die Dokumentabfrage eines einzelnen Nutzers dauert. Eingabeverarbeitung, Warteschlange, Länge der Modellüberlegungen und Ergebnisprüfung beeinflussen die tatsächliche Erfahrung. Der Bericht setzt außerdem voraus, dass FP8-Serving die Benchmarkwerte der Referenzmodelle erhält. Diese Annahme ist kein allgemeiner Nachweis gleichwertiger Qualität bei unterschiedlichen Präzisionen. [4]

Auch der umgekehrte Schluss hilft nicht: Ein größerer Speicherbedarf der Gewichte beweist keine schlechte Wirtschaftlichkeit. Ein sparsames Modell kann vorgehaltene Kapazität effizient nutzen, wenn genügend passende Arbeit es auslastet. Vergleichen Sie die Zahl akzeptabler abgeschlossener Aufgaben pro Kosteneinheit unter der erwarteten Last und berücksichtigen Sie ruhige Zeiten. Eine einzelne Parameterzahl entscheidet den Vergleich nicht.

Das veröffentlichte Inferenz-Repository stellt ein vLLM-Plugin mit Kolibri-spezifischer Architektur sowie Parsern für Modellüberlegungen und Werkzeugaufrufe bereit. Laut README unterstützt jede Version eine vLLM-Nebenversion; zum Zeitpunkt dieser Prüfung war das 0.29. Offene Gewichte ermöglichen den Zugriff auf das Modell. Sie belegen keine Kompatibilität mit jeder Inferenzanwendung oder deren installierter Version. [5]

Dokumentieren Sie Modellrevision, Präzision, Plugin- und Laufzeitversionen, Kontextgrenze und Parsereinstellungen gemeinsam. Prüfen Sie die Trennung von Modellüberlegungen und endgültigem Antworttext, die Verarbeitung von Werkzeugargumenten, lange Eingaben und unterbrochene Anfragen. Dass ein Client das Antwortformat akzeptiert, ist nur ein Teil einer funktionierenden Integration. Diese Spezifikation erleichtert auch die Bewertung späterer Upgrades oder Rücknahmen.

Ein Team, das mit deutschen oder englischen Dokumenten arbeitet, sollte mit repräsentativen Anfragen beginnen und die Antworten unabhängig anhand der bereitgestellten Belege prüfen. Ein Entwicklungsteam sollte die tatsächlichen Werkzeug-Schemas und die von der Anwendung zu verarbeitenden Ausgaben einbeziehen. Infrastrukturverantwortliche sollten erwartete Lastspitzen und ruhige Zeiten vergleichen. Die Ausrichtung auf zwei Sprachen ist ein Anlass, passende Sprachaufgaben zu prüfen, kein Beweis für Überlegenheit bei jeder Aufgabe in beiden Sprachen.

Ein kleiner Versuch sollte drei Fragen beantworten: Erfüllen die Ergebnisse die Qualitätsanforderungen? Kann die vorgesehene Maschine die benötigte Arbeitslast dauerhaft tragen? Kann das Team den Serving-Stack warten? Verwenden Sie beim Vergleich von Alternativen dieselben Dokumente, Ausgabeanforderungen und Abnahmeregeln. Rechnen Sie Wiederholungsversuche und abgelehnte Ergebnisse in die Kosten ein.

Kolibri ist eine interessante neue Option, weil die veröffentlichten Materialien diese Abwägungen nachvollziehbar machen. Die 3.46B aktiven Parameter beschreiben die sparsame Berechnung. Die größeren Gewichte und die Anfragezustände bleiben reale Anforderungen an die Bereitstellung. Der praktische Fortschritt ist ein weiteres Modell, das sich für eine klar definierte Aufgabe prüfen lässt. Speichergrenzen, Betriebsarbeit und unabhängige Ergebnisprüfungen sind damit nicht verschwunden.