bitsandbytes: k-bit-Quantisierung für PyTorch, ohne die Modellgröße zu ändern

Welches Problem bitsandbytes löst und für wen

Ein Modell mit mehreren Milliarden Parametern passt in float32 nicht auf eine einzelne GPU. Selbst in bfloat16 bleibt der Speicherbedarf hoch, und beim Training kommen Optimizer-Zustände hinzu, die pro Parameter mehrere Werte speichern. bitsandbytes setzt genau dort an: Das Projekt beschreibt drei Hauptfunktionen, die den Speicherverbrauch beim Inferenzbetrieb und beim Training senken sollen, ohne die Rechengenauigkeit aufzugeben. Die Zielgruppe sind damit keine Anwendungsentwickler, die ein fertiges Modell über eine API aufrufen, sondern Teams, die PyTorch-Modelle selbst laden, quantisieren und gegebenenfalls nachtrainieren.

Der README nennt die drei Bausteine ausdrücklich: 8-Bit-Optimizer mit blockweiser Quantisierung, LLM.int8() für die Inferenz und QLoRA für das Training. Wer nur ein Modell auf einer kleineren Karte inferieren will, greift zu LLM.int8(). Wer auf einer Karte ein Modell nachtrainieren will, das sonst nicht in den Speicher passt, greift zu QLoRA. Die 8-Bit-Optimizer wiederum sind unabhängig von der Modellquantisierung nutzbar und adressieren den Optimizer-Zustand, nicht die Gewichte.

Blockweise Quantisierung, Outlier-Behandlung und LoRA-Adapter

Die drei Verfahren arbeiten auf unterschiedlichen Ebenen. LLM.int8() quantisiert laut README die meisten Merkmale auf 8 Bit und behandelt Ausreißer getrennt: Diese Ausreißer laufen weiterhin über 16-Bit-Matrixmultiplikationen. Das ist der Kern der vector-wise quantization, also einer Quantisierung entlang von Vektoren statt über ganze Tensoren. Der Vorteil dieser Aufteilung: Einzelne extreme Aktivierungswerte, die bei großen Sprachmodellen regelmäßig auftreten, ziehen nicht die gesamte Skala eines Tensors nach oben und zerstören damit die Auflösung für alle übrigen Werte.

QLoRA geht anders vor. Das Modell wird auf 4 Bit quantisiert, und in die so entstandene Struktur werden kleine trainierbare Low-Rank-Adapter-Gewichte eingesetzt. Trainiert werden also nicht die quantisierten Basismatrizen, sondern nur die Adapter. Die 8-Bit-Optimizer schließlich nutzen blockweise Quantisierung, um nach Angabe des README 32-Bit-Leistung bei einem Bruchteil des Speicherbedarfs zu halten. Der gemeinsame Nenner aller drei Verfahren ist die Blockbildung: Statt einen ganzen Tensor mit einer einzigen Skala zu versehen, werden kleinere Blöcke separat quantisiert, was die Fehler pro Block begrenzt.

Auf der API-Ebene erscheint das als `bitsandbytes.nn.Linear8bitLt` und `bitsandbytes.nn.Linear4bit`, dazu das Modul `bitsandbytes.optim` für die Optimizer. Wer diese Klassen direkt verwendet, ersetzt einzelne `torch.nn.Linear`-Schichten und wählt einen Optimizer aus `bitsandbytes.optim`. Der übliche Weg führt jedoch über die Integrationen in Transformers, Diffusers und PEFT, die der README verlinkt.

Installation und die Frage nach der richtigen Plattform

Der README nennt als Mindestanforderungen Python 3.10 oder neuer und PyTorch 2.4 oder neuer. Für die beste Erfahrung empfiehlt das Projekt die jeweils aktuelle PyTorch-Version, auch wenn es nach eigener Aussage breite Rückwärtskompatibilität anstrebt. Die Installation selbst läuft über PyPI; der README dokumentiert den Paketnamen `bitsandbytes` und verweist für Details auf die offizielle Dokumentation unter huggingface.co/docs/bitsandbytes.

Interessanter als der Installationsbefehl ist die Support-Tabelle. Sie listet für Linux mit glibc 2.24 oder neuer, für Windows 11 beziehungsweise Windows Server 2022 oder neuer und für macOS 14 oder neuer, welche Kombination aus Architektur und Beschleuniger welche der drei Funktionen trägt. Auf x86-64 unter Linux sind CPU, NVIDIA-GPU, AMD-GPU, Intel-GPU und Intel Gaudi aufgeführt. Für Intel Gaudi gilt dabei eine Einschränkung: QLoRA ist nur teilweise unterstützt, die 8-Bit-Optimizer gar nicht. Auf aarch64 unter Linux ist LLM.int8() auf der CPU mit einem Sternchen versehen, das laut Fußnote auf fehlende Performance-Optimierungen hinweist. Unter macOS ist die Metal-Unterstützung für 8-Bit-Optimizer als geplant markiert, LLM.int8() und QLoRA laufen dort auf Apple M1 oder neuer.

Für NVIDIA-GPUs nennt die Tabelle SM60 als Minimum und SM75 als Empfehlung. Bei AMD sind konkrete gfx-Ziele aufgeführt, getrennt nach CDNA und RDNA, wobei die Windows-Liste kürzer ausfällt als die Linux-Liste. Wer eine Karte besitzt, die in keiner dieser Zeilen auftaucht, sollte nicht davon ausgehen, dass die Bibliothek funktioniert.

Wo die Bibliothek nicht die richtige Wahl ist

Die Support-Tabelle ist die erste Einschränkung, aber nicht die einzige. Der README weist ausdrücklich darauf hin, dass die Tabelle den Stand des Entwicklungszweigs widerspiegelt und für das stabile Release ein Dokument am Tag 0.50.0 verlinkt ist. Das bedeutet: Wer den Hauptzweig installiert, kann Funktionen erhalten, die im stabilen Release noch nicht oder anders vorhanden sind. Umgekehrt kann eine ältere Wheel-Version eine Beschleunigerkombination nicht abdecken, die im Hauptzweig bereits aufgeführt wird. Diese Trennung zwischen `continuous-release_main` und den nummerierten Releases ist praktisch relevant, weil sie die Fehlersuche erschwert: Ein Fehlerbericht gegen den Hauptzweig lässt sich nicht ohne Weiteres auf eine veröffentlichte Version übertragen.

Ein zweiter Punkt betrifft die Erwartung an die Genauigkeit. Der README formuliert für LLM.int8() "without any performance degradation" und für QLoRA, dass die Speichertechniken die Leistung nicht beeinträchtigen. Solche Aussagen sind an Modell, Aufgabe und Messgröße gebunden und keine Zusage für jeden Anwendungsfall. Wer Quantisierung einsetzt, sollte die Ergebnisse auf der eigenen Aufgabe prüfen, statt sich auf eine pauschale Aussage zu verlassen.

Schließlich ist bitsandbytes kein Ersatz für verteiltes Training. Die Bibliothek reduziert den Speicherbedarf pro Beschleuniger. Wer mehr Rechenleistung braucht, als eine Karte liefert, löst das nicht durch Quantisierung, sondern durch Modell- oder Datenparallelität, und dafür ist bitsandbytes nicht der adressierte Baustein.

Alternativen: GGUF und llama.cpp verfolgen einen anderen Ansatz

Der naheliegende Vergleich ist llama.cpp mit dem GGUF-Format. Beide Projekte quantisieren Modellgewichte, aber der Unterschied liegt im Ausführungsmodell. bitsandbytes ist eine PyTorch-Bibliothek: Das Modell bleibt ein PyTorch-Modul, die Quantisierung geschieht über `Linear8bitLt` und `Linear4bit` innerhalb des bestehenden `nn.Module`-Graphen, und der Rest der PyTorch-Werkzeugkette bleibt verfügbar. Genau deshalb funktionieren die Integrationen in Transformers, Diffusers und PEFT, die der README verlinkt.

llama.cpp dagegen bringt eine eigene Inferenz-Engine mit, die Gewichte liegen in einem eigenen Dateiformat vor, und die Ausführung erfolgt außerhalb von PyTorch. Das ist von Vorteil, wenn kein PyTorch benötigt wird, etwa in einer C++-Anwendung oder auf Geräten, auf denen die Installation von PyTorch samt CUDA-Abhängigkeiten zu aufwendig wäre. Der Preis ist, dass Trainingsverfahren wie QLoRA und die 8-Bit-Optimizer, die bitsandbytes als Kernfunktionen anbietet, in diesem Modell nicht zur Verfügung stehen. Wer ein Modell nachtrainieren will, ist mit bitsandbytes besser bedient; wer nur inferieren und dabei die PyTorch-Abhängigkeiten vermeiden will, mit llama.cpp.

Ein zweiter Unterschied betrifft die Hardware-Abdeckung. bitsandbytes nennt in der Tabelle ausdrücklich Intel-GPUs über `xpu` und Intel Gaudi über `hpu` neben NVIDIA und AMD. Diese Breite ist für Teams relevant, die nicht ausschließlich auf CUDA setzen, und sie ist einer der Gründe, warum die Bibliothek in den Hugging-Face-Bibliotheken als Standardweg für Quantisierung verankert ist.

Wartung, Releases und Lizenz

Das Projekt veröffentlicht zwei Arten von Artefakten. Neben nummerierten Releases wie 0.50.1 und 0.50.2 existiert ein `continuous-release_main`-Wheel, das den Stand des Hauptzweigs abbildet. Für den produktiven Einsatz ist das nummerierte Release die sinnvollere Wahl, weil es einen festen Bezugspunkt für Fehlerberichte bietet. Der Preis dafür ist die Verzögerung: Funktionen, die im Hauptzweig bereits in der Support-Tabelle stehen, können im stabilen Release noch fehlen.

Ein Blick auf die Release-Bezeichnungen zeigt, wie eng die Versionen an Hardware-Termine gekoppelt sind. Das Release 0.50.1 trägt den Titel "RTX Spark Support". Das ist ein Hinweis darauf, dass neue Beschleunigergenerationen eigene Anpassungen erfordern und dass ein Upgrade nicht nur Fehlerkorrekturen, sondern auch Hardware-Abdeckung mitbringt. Wer auf neuer Hardware arbeitet, muss daher unter Umständen schneller aktualisieren als es der eigene Release-Zyklus vorsieht.

Die Lizenz ist MIT. Das ist eine permissive Lizenz, die kommerzielle Nutzung, Veränderung und Weitergabe erlaubt, sofern der Urheberrechtshinweis und der Lizenztext beibehalten werden. Für die Einbindung in ein proprietäres Produkt entstehen daraus keine Copyleft-Pflichten. Ob die im Projekt verwendeten Abhängigkeiten und die verteilten Wheels dieselbe Lizenz tragen, lässt sich aus dem vorliegenden Material nicht ableiten und sollte vor einer Auslieferung geprüft werden. Rechtsberatung ist das nicht.

Was vor dem Einsatz zu klären ist

Die praktische Prüfliste ergibt sich aus der Struktur des Projekts. Zuerst die Hardware: Die Support-Tabelle im README ist die einzige belastbare Quelle dafür, ob die eigene Kombination aus Architektur und Beschleuniger die gewünschte Funktion trägt. Besonders bei Intel Gaudi und bei macOS mit Metal fallen Zeilen auf, in denen einzelne Spalten nicht oder nur teilweise unterstützt sind. Zweitens die Version: Ob der Hauptzweig oder ein nummeriertes Release verwendet wird, entscheidet darüber, welche Zeilen der Tabelle überhaupt gelten. Drittens die Einbindung: Wer nicht direkt `bitsandbytes.nn` verwendet, sondern über Transformers, Diffusers oder PEFT geht, sollte die dortige Quantisierungsdokumentation lesen, weil die Konfigurationsschlüssel dort gesetzt werden und nicht in bitsandbytes selbst.

Was der README nicht beantwortet, ist die Frage nach dem konkreten Genauigkeitsverlust auf einer bestimmten Aufgabe. Die Aussagen zu LLM.int8() und QLoRA sind allgemein gehalten. Eine Bewertung für das eigene Modell erfordert eine eigene Messung, und die lässt sich aus der Dokumentation nicht vorwegnehmen.

Redaktionelles Fazit

Wer ein PyTorch-Modell auf einer einzelnen GPU mit begrenztem Speicher trainieren oder betreiben will und dabei auf CUDA, XPU oder HPU setzt, findet in bitsandbytes die passenden Primitive. Wer keine NVIDIA-, AMD-, Intel- oder Gaudi-Beschleunigerkarte einsetzt oder auf einer Metal-GPU unter macOS trainiert, sollte zuerst die Support-Tabelle prüfen, denn dort ist 8-Bit-Optimierung als geplant markiert. Vor dem Einsatz lohnt ein Blick auf die Versionshinweise: Der Wechsel zwischen Hauptzweig und stabilem Release kann sich auf die Accelerator-Unterstützung auswirken, wie der Hinweis im README zur Tabelle des Tags 0.50.0 zeigt.

Offizielle Quellen

1. bitsandbytes-foundation/bitsandbytes on GitHub
2. License: MIT
3. Project website
4. README
5. Releases