Feinabstimmung eines 235-Milliarden-Modells auf vier GPUs: Lehren aus einer gescheiterten Bereitstellung

Ingenieure bei Vertexcover haben das Qwen3-Modell mit 235 Milliarden Parametern erfolgreich auf einem einzelnen Rechner mit vier H100-GPUs feinabgestimmt und dabei erhebliche Genauigkeitsgewinne gegenüber kostenpflichtigen API-Modellen erzielt. Trotz des technischen Erfolgs und der reduzierten Kosten pro Token entschied sich das Team gegen die Bereitstellung der Lösung, da neuere Open-Source-Modelle die komplexe Infrastruktur überflüssig machten.

Was passiert ist

Das Team wollte teure, feinabgestimmte Modelle von OpenAI und Gemini ersetzen, die für die Entitätsklassifizierung in Kundendokumenten verwendet wurden. Sie wählten Qwen3-235B-A22B-Thinking, ein Mixture-of-Experts-(MoE)-Modell, weil es in ersten Benchmarks andere offene Modelle übertraf. Das Ziel war es, die Genauigkeit beizubehalten oder zu verbessern und gleichzeitig die Kosten durch selbst gehostete Hardware zu kontrollieren.

Nach einer Epoche des Trainings auf etwa 3.600 Beispielen verbesserte das feinabgestimmte Modell den durchschnittlichen F1-Score über alle Mandanten hinweg um 7,6 Punkte. Zudem sanken die Kosten pro Token auf etwa ein Drittel der bisherigen API-basierten Lösungen. Der Trainingsprozess dauerte 26 Stunden auf vier NVIDIA-H100-GPUs mit jeweils 80 GB Speicher.

Trotz dieser positiven Metriken wurde das Projekt auf Eis gelegt. Das Team stellte fest, dass die Bereitstellung des 235-Milliarden-Denkmodells mit geringer Latenz und angemessenen Betriebskosten eine größere ingenieurtechnische Herausforderung darstellte als die Feinabstimmung selbst. Gleichzeitig tauchten neue Open-Source-Modelle auf, die viele Klassifizierungsaufgaben ohne jegliche Feinabstimmung bewältigten, was die Notwendigkeit ihrer eigenen Infrastruktur eliminierte.

Wie es funktioniert

Qwen3-235B ist ein MoE-Modell, bei dem nur etwa 22 Milliarden seiner 235 Milliarden Parameter für ein gegebenes Token aktiv sind. Jede Schicht enthält 128 kleine Expertennetzwerke, und ein Router leitet Tokens an die relevantesten Experten weiter. Diese Architektur hält die Inferenz rechenintensiv günstiger als dichte Modelle ähnlicher Größe, erschwert aber das Speichermanagement beim Laden und Training.

Das Team verwendete QLoRA (Quantized Low-Rank Adaptation), um das Modell feinabzustimmen. Diese Methode komprimiert das Basismodell auf 4-Bit-Präzision und reduziert seinen Speicherbedarf von 470 GB auf etwa 120 GB. Kleine Adapter-Schichten werden dann auf den eingefrorenen Basisgewichten trainiert. Die Herausforderung liegt darin, Bibliotheken zur Kompression und zum Sharding zu koordinieren, die unterschiedliche Anforderungen an die Speicherung und den Zugriff auf Modellgewichte im Speicher stellen.

Für ein erfolgreiches Training war DeepSpeed ZeRO-3 mit CPU-Offload erforderlich. Diese Konfiguration hielt vollständige Kopien des 120 GB großen komprimierten Modells im System-RAM statt im GPU-Speicher. Während des Trainings wurden Schichten bei Bedarf vom RAM auf die GPUs verschoben, sodass die vier H100s die Last trotz individueller Speicherlimits bewältigen konnten. Dieser Ansatz tauschte Geschwindigkeit gegen Machbarkeit und führte zu der 26-stündigen Trainingszeit.

Wichtige Details

• Das Modell verbesserte die F1-Scores für jeden Mandanten, mit Gewinnen zwischen +4,81 und +11,96 Punkten.
• Für das Training wurden 3.600 Beispiele einschließlich Reasoning-Traces verwendet, da Qwen3 ein „Thinking“-Modell ist.
• Vier H100-GPUs mit jeweils 80 GB Speicher und 960 GB System-RAM waren erforderlich.
• Axolotl-, Unsloth- und Answer.AI’s FSDP+QLoRA-Implementierungen schlugen aufgrund von Speicher- oder Kompatibilitätsproblemen fehl.
• LlamaFactory mit Standard-FSDP scheiterte, weil Transformers während der Quantisierung speichersparende Einstellungen stillschweigend deaktivierten.
• Die endgültig funktionierende Konfiguration nutzte LlamaFactory mit DeepSpeed ZeRO-3 und CPU-Offload zur Speicherverwaltung.

Warum es wichtig ist

Dieser Fall verdeutlicht die versteckte Komplexität der Feinabstimmung massiver MoE-Modelle auf begrenzter Hardware. Ingenieure gehen oft davon aus, dass Quantisierung und Sharding große Modelle nahtlos in verfügbaren GPU-Speicher passen, aber Inkompatibilitäten zwischen Bibliotheken und Probleme bei der Speicherreihenfolge können verhindern, dass das Training überhaupt startet. Das Verständnis dieser Low-Level-Einschränkungen ist entscheidend für die Planung der Infrastruktur für Modelle mit mehr als 100 Milliarden Parametern.

Es dient auch als Erinnerung daran, dass technische Machbarkeit nicht immer eine Bereitstellung rechtfertigt. Der Aufwand, die Inferenz für ein 235-Milliarden-Modell zu optimieren, kann den Nutzen der Feinabstimmung übersteigen, besonders wenn das Basismodell bereits stark ist. Teams müssen die Gesamtbetriebskosten bewerten, einschließlich Servierlatenz und Hardwareanforderungen, und nicht nur die Trainingsgenauigkeit.

Schließlich bedeutet das rasante Tempo der Open-Source-Entwicklung, dass heutige schwierige ingenieurtechnische Probleme morgen durch ein neues Modellrelease gelöst sein könnten. Wochenlange Investitionen in eigene Feinabstimmungspipelines bergen das Risiko versunkener Kosten, falls ein Allzweckmodell genug verbessert wird, um die Aufgabe out-of-the-box zu erledigen. Strategische Geduld kann manchmal bessere Ergebnisse liefern als sofortige Anpassungen.

Was Sie tun können

• Benchmarken Sie mehrere offene Modelle, bevor Sie sich für eine Feinabstimmung entscheiden, da die Basisleistung erheblich variiert.
• Überprüfen Sie die Bibliothekskompatibilität für MoE-Modelle, insbesondere hinsichtlich der Reihenfolge von Quantisierung und Sharding.
• Stellen Sie sicher, dass ausreichend System-RAM für CPU-Offloading vorhanden ist, wenn der GPU-Speicher für das vollständige komprimierte Modell nicht ausreicht.
• Überwachen Sie Transformers-Einstellungen auf stille Änderungen am Speichermanagement während Quantisierungsprozessen.
• Bewerten Sie Inferenzkosten und Latenzanforderungen frühzeitig, nicht nur Trainingsgenauigkeit und -kosten.
• Überdenken Sie regelmäßig die Notwendigkeit einer Feinabstimmung, da neue Basismodelle Leistungslücken ohne Anpassungen schließen können.