Bolmo 1B Stage 1 und Bolmo 7B Stage 1: Protokoll für lokale Inferenz zur Bewertung bytebasierter Repräsentationen

Bytebasierte Architektur: von Subword-Tokenisierung zu UTF-8-Bytes

Die meisten heutigen Sprachmodelle verarbeiten diskrete Einheiten, sogenannte Tokens, die mithilfe von Subword-Verfahren wie BPE oder WordPiece erzeugt werden. Das ist zwar effizient, kann aber feingranulare Informationen verdecken. Problematisch ist das insbesondere bei wissenschaftlichen Daten, etwa Quellcode oder biologischen Sequenzen, deren Bedeutung von einzelnen Zeichen abhängen kann. Bolmo, entwickelt vom Allen Institute for AI (Ai2), ist eine Modellfamilie, die Text direkt als UTF-8-Bytes verarbeitet. Damit entfällt die Abhängigkeit von sprach- oder domänenspezifischen Tokenizer-Vokabularen.

Ai2 verfolgt dafür ein zweistufiges Verfahren, mit dem sich bestehende Subword-Modelle mit geringem zusätzlichem Trainingsaufwand in bytebasierte Modelle umwandeln lassen. Die Architektur ist auf unterschiedliche Sprachen, Schriftsysteme und Anwendungsbereiche ausgelegt und kann bei Aufgaben mit Zeichenverständnis Vorteile bieten. Die direkte Byteverarbeitung vermeidet eine vorgelagerte Subword-Zerlegung. Daraus folgt jedoch nicht automatisch, dass ein Modell mit beliebigen Eingaben fehlerfrei umgeht oder bei jeder Aufgabe bessere Ergebnisse erzielt: Solche Eigenschaften müssen für den jeweiligen Einsatz empirisch geprüft werden.

Hardware- und Speicherbedarf bei lokaler Inferenz

Bei lokaler Inferenz müssen die Speicherressourcen sorgfältig geplant werden. Die Projektunterlagen nennen für Bolmo 1B Stage 1 insgesamt 1,5 Milliarden Parameter und für Bolmo 7B Stage 1 insgesamt 7,6 Milliarden. Diese Größenordnungen helfen bei der Vorauswahl, reichen aber nicht aus, um den tatsächlichen VRAM- oder RAM-Bedarf zu bestimmen. Die verfügbaren Primärquellen nennen keine exakten Mindestwerte für eine lokale Ausführung und legen auch keine einheitlichen Bedingungen für eine effiziente Inferenz fest.

Der Speicherbedarf hängt unter anderem vom Datentyp der Gewichte, der Implementierung, der Sequenzlänge, der Batch-Größe und dem zusätzlichen Speicherbedarf für Zwischenergebnisse ab. Bei einer bytebasierten Eingaberepräsentation kann dieselbe Textmenge in Bytes eine längere Modellsequenz ergeben als bei einer Subword-Repräsentation. Deshalb sollte die benötigte Speicherkapazität nicht allein aus der Parameterzahl abgeleitet werden. Vor einer Hardwareentscheidung sind die jeweilige Modellkonfiguration zu prüfen und Belastungstests mit realistischen Eingaben durchzuführen.

Bei Stage 1 wurden laut Projektbeschreibung die neu hinzugefügten lokalen Komponenten trainiert, während das globale Modell eingefroren blieb. Das beschreibt den Trainingsumfang, nicht eine Garantie für geringeren Speicherbedarf bei der Inferenz. Die Parameter des Modells müssen weiterhin geladen werden. Für Edge-Geräte kann das 1B-Modell aufgrund seiner geringeren Parameterzahl ein sinnvoller erster Kandidat sein; ob es auf einer konkreten Zielhardware passt und die gewünschte Leistung erreicht, muss jedoch gemessen werden.

Datenschutz und Isolierung sensibler Daten

Lokale Inferenz kann Teams dabei helfen, sensible Eingaben innerhalb ihrer eigenen Infrastruktur zu verarbeiten, statt sie an einen externen Inferenzdienst zu senden. Das kann für Unternehmensdaten, Forschung oder proprietären Quellcode wichtig sein. Der Datenschutzvorteil entsteht jedoch nicht allein dadurch, dass ein Modell lokal läuft: Auch Protokolle, Telemetrie, Zugriffsrechte, Backups, Netzwerkverbindungen und die Verwaltung der Modellgewichte müssen geprüft werden.

Eine bytebasierte Architektur verzichtet auf die Subword-Tokenisierung als vorgelagerten Verarbeitungsschritt. Das kann die Verarbeitung unterschiedlicher Schriftsysteme und ungewöhnlicher Zeichenfolgen vereinheitlichen. Es beweist aber weder, dass Zeichen in jeder Anwendung korrekt interpretiert werden, noch dass die gesamte Verarbeitung einfacher oder sicherer ist. Für produktive Systeme sollte das Team die konkrete Eingabe- und Ausgabepipeline prüfen und mit den Zeichen testen, die im eigenen Datenbestand tatsächlich vorkommen.

Für einen lokalen Einsatz sind außerdem die Beschaffung und das Laden der Checkpoints zu berücksichtigen. Das Projekt stellt Beispiele für die Inferenz mit der Hugging-Face-Schnittstelle bereit; die Installation kann dennoch zusätzliche Pakete und passende Hardwarekonfigurationen erfordern. In einer abgeschotteten Umgebung sollte der Abruf der Gewichte vorab eingeplant und anschließend überprüft werden, ob während der Inferenz unerwünschte Netzwerkverbindungen oder externe Dienste verwendet werden.

Pilotprotokoll: Bedingungen, Messwerte und Auswertung

Ein belastbarer Vergleich beginnt mit einer klaren Fragestellung. Geht es darum, ob ein Checkpoint auf einer bestimmten GPU läuft, wie viel Speicher er benötigt oder welche Latenz er bei einer festen Eingabe erreicht? Diese Fragen sollten getrennt erfasst werden. Die Projektunterlagen dokumentieren die Checkpoints Bolmo 1B Stage 1 und Bolmo 7B Stage 1 sowie ein Inferenzbeispiel für Bolmo. Sie liefern jedoch keine kontrollierte Messung, die für alle lokalen Umgebungen übernommen werden kann.

Für den Pilotversuch sollten beide Modelle unter möglichst gleichen Bedingungen laufen: auf derselben Hardware, mit derselben Softwareumgebung, denselben Eingaben und vergleichbaren Generierungsparametern. Zu dokumentieren sind mindestens Modellkennung und Checkpoint, Datentyp, Laufzeitbibliotheken, Treiberversion, Eingabeinhalt und -länge, Batch-Größe sowie die verwendete Anzahl neu erzeugter Bytes. Die Auswertung sollte Aufwärmläufe von den eigentlichen Messläufen trennen und mehrere Wiederholungen umfassen.

Bei bytebasierten Modellen ist die Maßeinheit besonders wichtig. Der Wert für `max_new_tokens` kann bei Bolmo die Zahl der zu erzeugenden Bytes bezeichnen. Deshalb sollte eine Messung nicht ungeprüft als Zeit pro Wort oder als Vergleich mit der Tokenrate eines Subword-Modells ausgegeben werden. Berichte sollten klar angeben, ob sie Bytes pro Sekunde, Zeichen pro Sekunde oder eine andere definierte Größe messen. Latenz und Durchsatz sollten außerdem getrennt ausgewiesen werden: Eine geringe Zeit bis zum ersten Ausgabebyte ist nicht dasselbe wie eine hohe kontinuierliche Generierungsrate.

Die Ergebnisse beantworten zunächst nur eine operative Frage für die getestete Konfiguration. Sie erlauben keine allgemeine Aussage über die Qualität der Generierung oder darüber, welches Modell Aufgaben besser löst. Für Aussagen zu Qualität, Zeichenrobustheit oder mehrsprachiger Leistung braucht es eigene, vorab definierte Tests und passende Auswertungskriterien.

Grenzen der Evidenz und offene Fragen

Die verfügbaren Projektinformationen belegen, dass Stage-1-Checkpoints für Bolmo 1B und Bolmo 7B veröffentlicht wurden. Sie nennen deren Größen und Basismodelle und beschreiben Stage 1 als Training der neuen lokalen Komponenten bei eingefrorenem globalem Modell. Das ist eine belastbare Beschreibung des Trainingsumfangs, aber kein Nachweis dafür, wie gut die beiden Stage-1-Varianten bei einer bestimmten Aufgabe abschneiden.

Die Primärquellen liefern keine exakten Mindestanforderungen an VRAM oder RAM und keine kontrollierte, direkte Messung von Latenz oder Durchsatz für beide Stage-1-Checkpoints auf derselben lokalen Hardware. Entsprechend lassen sich aus der Dokumentation weder ein allgemeingültiger Hardware-Schwellenwert noch eine eindeutige Geschwindigkeitsrangfolge ableiten. Auch die Parameterzahl allein reicht nicht aus, um den realen Speicherbedarf oder die Leistung vorherzusagen.

Die Untersuchung zu Bolmo beschreibt die bytebasierte Modellfamilie und das zweistufige Umwandlungsverfahren. Die verfügbaren Angaben sind kein vollständiger Ersatz für Messungen der konkreten Stage-1-Checkpoints in einer bestimmten Umgebung. Für eine belastbare Aussage zu den hier betrachteten Varianten muss der jeweilige Checkpoint mit denselben Eingaben und Bedingungen getestet werden. Ergebnisse sollten als Resultate des eigenen Pilotversuchs gekennzeichnet und nicht als allgemeingültige Eigenschaften von Bolmo dargestellt werden.

Daher sollte die Entscheidung zwischen 1B Stage 1 und 7B Stage 1 anhand des tatsächlichen Betriebsziels getroffen werden: Passt das Modell in die verfügbare Hardware? Erfüllt es die Anforderungen an Latenz und Durchsatz? Bleiben Eingaben und Ausgaben innerhalb der vorgesehenen Sicherheitsgrenzen? Eine Entscheidung zur Aufgabenqualität erfordert zusätzliche, auf den konkreten Anwendungsfall zugeschnittene Tests.

Entscheidungsraster für den lokalen Einsatz

Für eine erste Auswahl kann ein Team die Anforderungen an Hardware, Datenschutz und Inferenzkosten getrennt bewerten. Das 1B-Modell bietet eine geringere Parameterzahl als das 7B-Modell, was es zu einem naheliegenden Kandidaten für Geräte mit begrenzten Ressourcen macht. Daraus folgt jedoch nicht automatisch, dass es in einer bestimmten Konfiguration die gewünschte Latenz erreicht. Ebenso lässt sich aus der höheren Parameterzahl des 7B-Modells nicht ohne Aufgabenmessungen auf bessere Ergebnisse schließen.

Vor dem Rollout sollte der Pilotversuch eine klare Entscheidung ermöglichen: Kann der Checkpoint mit dem verfügbaren Speicher geladen werden? Bleibt die Latenz innerhalb der betrieblichen Vorgaben? Ist der Durchsatz für das erwartete Anfragevolumen ausreichend? Werden sensible Daten im vorgesehenen Bereich verarbeitet? Und liefert das Modell bei einem separat evaluierten Testsatz akzeptable Resultate? Wenn eine dieser Fragen offenbleibt, sollte das Ergebnis als vorläufig dokumentiert und nicht als bestätigte Modelleigenschaft verallgemeinert werden.

Weiter entdecken

Korrekturen und Transparenz

Wenn du falsche oder veraltete Angaben findest, sende uns die Seite und die zu prüfende Quelle.