GGUF ersetzt bitsandbytes für LoRA-Training mit geringem VRAM auf lokaler Hardware

Ein neues Open-Source-Rezept zeigt, wie Low-Rank Adaptation (LoRA)-Training auf großen Sprachmodellen mit deutlich weniger Videospeicher durchgeführt werden kann als bisher für möglich gehalten. Durch die Nutzung des GGUF-Dateiformats anstelle herkömmlicher Quantisierungsbibliotheken können Entwickler Modelle wie Qwen3.6-35B nun mit nur 16 GiB VRAM feinabstimmen, ohne auf langsames CPU-Offloading angewiesen zu sein. Diese Entwicklung deutet darauf hin, dass GGUF dazu bestimmt ist, bitsandbytes als Standard-Basismodellformat für effizientes lokales Training zu ersetzen.

Was passiert ist

Der Entwickler hinter dem Repository woct0rdho/transformers5-qwen3.5-recipe hat eine technische Tiefenanalyse zu Trainingsmethoden mit geringem VRAM veröffentlicht, die speziell auf die Strix-Halo-Hardwarearchitektur zugeschnitten sind. Die Arbeit stellt die gängige Annahme in Frage, dass das Training großer Modelle massive GPU-Cluster oder umfangreiches Memory-Swapping erfordert. Stattdessen wird gezeigt, dass selbst Consumer-Grade- oder integrierte Hochleistungs-Hardware mit der richtigen Kombination aus quantisierten Basismodellen und optimierten Kernels erhebliche Feinabstimmungsaufgaben bewältigen kann.

Die Kernleistung besteht darin, mehrere State-of-the-Art-Open-Weight-Modelle vollständig innerhalb von VRAM-Grenzen zu trainieren, die zuvor als unzureichend galten. Beispielsweise wurde das Modell Qwen3.6-35B-A3B mit nur 16 GiB VRAM trainiert. Der Autor merkt an, dass diese Effizienz impliziert, dass größere Varianten wie Qwen3.5-122B-A10B in 64 GiB und das massive Modell Qwen3.5-397B-A17B in 192 GiB trainiert werden könnten. Ebenso wurde das Modell DeepSeek-V4-Flash, das 284 Milliarden Parameter enthält, in 90 GiB VRAM trainiert, während das Modell Qwen3.8-Flash-Next 40 GiB benötigte.

Diese Entwicklung ist bedeutend, weil sie Open-Weight-KI ähnlich wie Open-Source-Software behandelt, bei der Benutzer die Gewichte nicht nur ausführen, sondern auch modifizieren. Die Möglichkeit, Gewichte lokal ohne prohibitive Hardwarekosten zu ändern, senkt die Einstiegshürde für die Anpassung von Grundmodellen. Allerdings ist die aktuelle Implementierung spezifisch für Strix Halo optimiert, was bedeutet, dass zusätzlicher Engineering-Aufwand erforderlich ist, um diese Optimierungen auf andere GPU-Architekturen zu portieren.

Wie es funktioniert

Die Methode basiert darauf, die Bibliothek bitsandbytes durch GGUF als Basismodellformat zum Laden quantisierter Gewichte zu ersetzen. GGUF, ursprünglich durch llama.cpp für Inferenz populär gemacht, wird nun durch einen benutzerdefinierten Fork der Transformers-Bibliothek für Trainings-Workflows adaptiert. Dieser Ansatz verwendet einen GGUF-Quantizer, der sich direkt in die Trainingsschleife integriert, sodass das Modell während der Berechnung im komprimierten Zustand bleibt, anstatt vollständig in hochpräzise Formate zu dekomprimieren, die übermäßigen Speicher verbrauchen.

Mehrere spezialisierte Kernels und Optimierungstechniken machen dies möglich. Das System nutzt abgestimmte General Matrix Multiply (GEMM)-Operationen und Mixed Precision Quantization (MMQ), ähnlich denen in llama.cpp. Für Mixture of Experts (MoE)-Schichten verwendet das Rezept AITER-Triton-Kernels mit spezifischen Konfigurationen für nicht quantisierte LoRA-Adapter. Es implementiert zudem schnelle Rückwärtsformeln für LoRA-Updates, ähnlich denen in Unsloth, um die Gradientenberechnungen für lineare und MoE-Schichten zu beschleunigen.

Weitere Speichereinsparungen werden erzielt, indem bestimmte Funktionen deaktiviert werden, die für die Trainingsstabilität nicht zwingend erforderlich sind, wie der autoregressive Decoding-Cache und der Load-Balancing-Loss. Das System verwendet Non-Reentrant-Gradient-Checkpointing und einen 8-Bit-AdamW-Optimizer von bitsandbytes, um den Speicherbedarf zu minimieren. Zusätzlich wird torch.compile auf die GGUF-Dequantisierungsfunktion angewendet, um die VRAM-Nutzung während der Ladephase zu reduzieren und sicherzustellen, dass der Overhead für die Handhabung komprimierter Gewichte überschaubar bleibt.

Wichtige Details

• Qwen3.6-35B-A3B trainiert in 16 GiB VRAM unter Verwendung der APEX-I-Mini-Quantisierung, die nur 13,3 GiB belegt.
• DeepSeek-V4-Flash (284 Mrd. Parameter) trainiert in 90 GiB VRAM unter Verwendung der IQ2_XXS-Quantisierung.
• Qwen3.8-Flash-Next trainiert in 40 GiB VRAM plus 27 GiB für Engrams unter Verwendung der GSQ-RCO Q2_0-Quantisierung.
• Die Lösung nutzt einen benutzerdefinierten Transformers-Fork mit GGUF-Unterstützung, der im Hugging-Face-Issue #40070 verfolgt wird.
• Zu den Optimierungen gehören abgestimmtes GEMM, MMQ, AITER-Triton-Kernels und RMSNorm von Liger Kernel.
• Aktuelle Kernels und Parameter sind spezifisch für Strix-Halo-Hardware optimiert und erfordern Anpassungen für andere GPUs.

Warum es wichtig ist

Für Ingenieure, die Produkte mit KI entwickeln, reduziert dieser Wandel die Kosten und Komplexität des Feinabstimmens großer Modelle. Traditionell erforderte das Training entweder teure Cloud-Instanzen mit hunderten Gigabytes VRAM oder komplexe Setups mit CPU-Offloading, was die Trainingszeiten drastisch verlangsamt. Indem der gesamte Trainingsprozess unter Verwendung effizienter Quantisierung im VRAM gehalten wird, können Entwickler schneller iterieren und mit größeren Modellen auf zugänglicherer Hardware experimentieren. Dies demokratisiert den Zugang zur Modell-Anpassung und ermöglicht kleineren Teams, Grundmodelle für ihre spezifischen Domänen anzupassen, ohne massive Infrastrukturinvestitionen.

Der Wechsel zu GGUF für das Training signalisiert auch eine Konvergenz zwischen Inferenz- und Trainings-Toolchains. Bisher mussten Entwickler separate Pipelines pflegen, um Modelle für die Inferenz (oft unter Verwendung von GGUF oder ähnlichen Formaten) und für das Training (unter Verwendung von voller Präzision oder bitsandbytes) zu konvertieren. Die Vereinheitlichung dieser Formate vereinfacht den Workflow, reduziert das Risiko von Fehlern bei der Konvertierung und stellt sicher, dass das Modellverhalten während des Trainings eng mit seinem Verhalten während des Deployments übereinstimmt. Diese Konsistenz ist entscheidend für die Aufrechterhaltung der Modellleistung und -zuverlässigkeit in Produktionsumgebungen.

Was Sie tun können

• Experimentieren Sie mit dem bereitgestellten Rezept auf Strix-Halo-Hardware, um Trainingsgeschwindigkeiten und Speichernutzung für Ihre spezifischen Anwendungsfälle zu benchmarken.
• Verfolgen Sie das Hugging-Face-Transformers-Issue #40070, um die mögliche Zusammenführung der GGUF-Quantisierungsunterstützung in die Hauptbibliothek zu überwachen.
• Prüfen Sie, ob Ihre aktuellen Feinabstimmungs-Workflows vom Wechsel von bitsandbytes zu GGUF-basierter Quantisierung für Basismodelle profitieren können.
• Untersuchen Sie die benutzerdefinierten Triton-Kernels und MMQ-Implementierungen, um zu verstehen, wie sie möglicherweise für Ihre spezifische GPU-Architektur angepasst werden können, wenn Sie nicht Strix Halo verwenden.
• Berücksichtigen Sie die Speichereinsparungen durch das Deaktivieren des autoregressiven Decoding-Caches und des Load-Balancing-Losses beim Design Ihrer Trainingsschleifen für ähnliche große Modelle.
• Erkunden Sie die Verwendung von torch.compile auf Dequantisierungsfunktionen, um die VRAM-Nutzung während des Modellladens und Trainings weiter zu optimieren.