Soup: Fine-Tuning mit einer YAML-Datei und Layer-Streaming für 4 GB VRAM
Fine-tune LLMs from one YAML. Layer streaming trains an 8B model on a 4 GB laptop GPU.
Auf einen Blick
- Was ist das?
- Soup ist ein Python-CLI-Werkzeug, das SFT, DPO und QLoRA über eine YAML-Konfiguration steuert. Der interessanteste Teil ist Layer-Streaming, das den eingefrorenen Basismodell-Speicher aus dem VRAM heraushält. Es ist als BETA markiert, und die Release-Notes dokumentieren genau, wo die Grenzen liegen.
- Für wen ist es gedacht?
- Soup ist sinnvoll für Einzelpersonen und kleine Teams, die auf einer Consumer-GPU mit 4 bis 8 GB VRAM ein 8B-Modell per LoRA oder QLoRA anpassen wollen und dafür keine Cloud-Instanz mieten möchten. Wer volle Kontrolle über den Trainingsloop, eigene Loss-Funktionen oder Multi-Node-Verteilung braucht, ist mit einem direkt geschriebenen Trainer auf Basis von transformers und peft besser bedient.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Das Repository hat innerhalb des letzten Tages neue Commits erhalten.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Python, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Welches Problem Soup adressiert und für wen es gedacht ist
Der Ausgangspunkt ist ein Satz aus der README: Teams verbringen 30 bis 50 Prozent ihrer Zeit mit Infrastruktur statt mit Modellverbesserung. Soup setzt genau dort an. Statt Trainingsskripte, Quantisierungskonfiguration, Batch-Size-Suche und GPU-Erkennung von Hand zu verdrahten, beschreibt eine YAML-Datei das Vorhaben, und ein Befehl führt es aus. Die Zielgruppe ist erkennbar: Menschen mit einer einzelnen GPU, nicht mit einem Cluster. Die Projektbeschreibung nennt ein 8B-Modell auf einer 4-GB-Laptop-GPU als Referenzfall. Die Themenliste des Repositories (consumer-gpu, low-vram, local-ai, ollama, gguf) bestätigt diese Ausrichtung. Wer bereits eine funktionierende Trainingspipeline mit eigenen Datacollators und Evaluationsschleifen besitzt, gewinnt hier wenig. Wer zum ersten Mal ein Modell an eigene Daten anpassen will, ohne sich mit Accelerate-Startskripten und DeepSpeed-Zonen auseinanderzusetzen, gewinnt sehr viel.
Layer-Streaming: der Mechanismus hinter der 4-GB-Zusage
Der Kern ist eine Umverteilung des Speichers. Normalerweise liegt das eingefrorene Basismodell vollständig im VRAM, obwohl es keine Optimierer-Schritte erhält. Soup hält es stattdessen außerhalb und schiebt es Decoder-Schicht für Decoder-Schicht auf die GPU. Die README beschreibt für Llama-3.1-8B auf einer 4-GB-Karte einen Basisspeicher von 3,60 GB, der im RAM gehalten wird, verteilt über 32 Schichten, plus zwei VRAM-Puffer von je 113 MB. Das ist ein konkretes Zahlenbild, kein Slogan. Die Option ist opt-in über den Schlüssel stream_layers: true und ausdrücklich als BETA gekennzeichnet. Bemerkenswert ist die Korrektheitszusage: Der gestreamte Lauf soll bit-identisch zum residenten Lauf sein. Dafür gibt es laut README ein Colab-Notebook, das den Prozess auf 4 GB begrenzt und dann die Bit-Gleichheit prüft. Wer diese Zusage nicht selbst nachvollziehen will, sollte sie als Herstellerangabe behandeln, nicht als geprüfte Eigenschaft.
Der fp32-Fehler in v0.74.0 und was er über die Reife sagt
Die Release-Notes zu v0.74.0 sind ungewöhnlich offen: Jeder SFT-Ladevorgang hob das eingefrorene Basismodell stillschweigend auf fp32 an, auf allen drei Ladepfaden. Ein Basismodell, das nie einen Optimierer-Schritt bekommt, wurde also mit doppelter Checkpoint-Präzision materialisiert. Auf einer H100 mit Llama-3.1-8B und LoRA nennt die Release-Note eine Reduktion von 48.241 MiB auf 18.658 MiB Spitzenverbrauch, ein Faktor von 2,59 und 28,9 GB, byte-identisch über drei Wiederholungen. Ein trainierbares Basismodell lädt weiterhin absichtlich in fp32. Diese Notiz ist aus zwei Gründen lesenswert. Erstens zeigt sie, dass die Speicherzusagen des Projekts nicht konstant waren. Zweitens zeigt sie, dass die Maintainer Fehler mit Messwerten und Wiederholungsanzahl dokumentieren statt sie zu beschönigen. Für eine Adoptionsentscheidung heißt das: Die Versionsnummer ist relevant, und ein Upgrade kann den Speicherbedarf deutlich verändern, in beide Richtungen.
Installation und Konfiguration: die tatsächlichen Befehle
Der Einstieg ist kurz. Die README zeigt drei Zeilen: pip install "soup-cli[train]", dann soup init --template chat, dann soup train. Das Extra [train] ist nötig, um überhaupt zu fine-tunen; ohne es installiert man nur das leichte CLI. Es gibt ein zweites Extra namens mlx, und die Release-Notes zu v0.74.0 erwähnen, dass pip install "soup-cli[train,mlx]" vorher nicht auflösbar war, weil die beiden Extras unvereinbare Versionsbereiche deklarierten. Wer beide Extras kombiniert, sollte das auf einer aktuellen Version tun. Die Konfiguration selbst liegt in einer YAML-Datei, deren Schlüssel die README nur exemplarisch zeigt (stream_layers: true). Ein vollständiges Schema wird im bereitgestellten Material nicht abgedruckt; dafür verweist das Repository auf docs/commands.md und docs/models.md. Wer die YAML produktiv einsetzen will, muss diese beiden Dateien lesen, weil sich aus der README allein nicht ableiten lässt, welche Felder Pflicht sind. Für Cloud-Läufe existiert soup train --cloud lambda, das laut Release-Notes standardmäßig nur plant und die Beendigung in einem finally-Block samt Nachfrage-Polling ausführt.
Wo Soup scheitert: Plattformgrenzen und Sicherheitsentscheidungen
Die wichtigste Einschränkung steht in den Release-Notes zu v0.74.0: Auf dem kostenlosen Colab- und Kaggle-Tier funktionierte Layer-Streaming überhaupt nicht. T4, P100, V100 und GTX 16xx stürzten ab, weil peft die LoRA-Adapter in der Checkpoint-Dtype anlegt, während der fp16-GradScaler fp32-Gradienten benötigt. Das trifft genau die Hardware, die die 4-GB-Zusage attraktiv macht. Wer also mit einer T4 liebäugelt, sollte zuerst prüfen, ob die installierte Version diesen Pfad repariert hat. Zweitens: soup serve beendet sich jetzt mit Exit-Code 2, wenn es an einen Nicht-Loopback-Host gebunden wird, ohne dass --tool-auth-token gesetzt ist. Früher war das nur eine Warnung. Das ist eine bewusste Breaking Change, und sie betrifft jeden, der den Server bisher ohne Token betrieben hat. Drittens nennt die README eine bekannte Grenze: Die deklarierte Untergrenze torch>=2.5.0 funktioniert nicht mit trl>=0.29, weil trl bei torch 2.5.1 nicht importierbar ist. Eine frische Installation löst eine neuere torch-Version auf, eine bestehende Umgebung möglicherweise nicht.
Vier SSRF-Bypässe und was sie über die Angriffsfläche sagen
Die Release-Notes zu v0.74.0 listen vier SSRF-Bypässe derselben Bauart: abgekürzte, dezimale, hexadezimale und oktale IPv4-Schreibweisen (127.1, 2130706433, 0x7f000001, 0177.0.0.1) erreichten den Telemetrie- und Webhook-Schutz. Über einen Pfad, den der erste Fix nie berührte, erreichten sie zusätzlich den OTLP-Tracing-Validator. Das ist keine Randnotiz. Ein Trainingswerkzeug, das Webhooks und Telemetrie-Endpunkte konfigurierbar macht, hat eine Netzwerkgrenze, und diese Grenze war an mindestens zwei Stellen umgehbar. Die Tatsache, dass alle vier Varianten dieselbe Form hatten, deutet auf einen einzelnen Normalisierungsschritt hin, der fehlte. Wer Soup in einer Umgebung mit ausgehendem Netzwerkzugriff und konfigurierbaren Webhooks betreibt, sollte die installierte Version gegen diese Liste prüfen. In einer rein lokalen Umgebung ohne Webhook-Ziele ist die Relevanz geringer, aber nicht null, weil der OTLP-Pfad denselben Validator nutzt.
Wann ein direkt geschriebener Trainer die bessere Wahl ist
Die Alternative zu Soup ist kein anderes CLI, sondern der Verzicht auf die Abstraktion: ein eigenes Skript auf Basis von transformers, peft und trl, das den Trainingsloop selbst aufbaut. Der Unterschied liegt nicht in der Leistung, sondern in der Kontrolle. Soup entscheidet über Batch-Size, GPU-Erkennung und Quantisierung automatisch. Genau das ist sein Wert und gleichzeitig seine Grenze. Sobald man eine eigene Loss-Funktion braucht, eine nicht standardisierte Datenaufbereitung, eine gewichtete Stichprobenziehung über mehrere Datensätze oder eine Evaluationsschleife, die während des Trainings in einen externen Dienst schreibt, wird die YAML-Datei zum Hindernis. Ein direkt geschriebener Trainer kostet mehr Einrichtungszeit, aber jede Änderung ist eine Codeänderung statt eines Umwegs um die Konfigurationsschicht. Für den Referenzfall (ein 8B-Modell, LoRA, eine GPU, ein Datensatz) ist Soup dagegen schneller einsatzbereit, und die dokumentierte Bit-Gleichheit zum residenten Lauf nimmt einem die Sorge, dass die Streaming-Abstraktion stillschweigend das Ergebnis verändert.
Wartung, Lizenz und was vor dem Einsatz zu klären ist
Das Projekt steht unter Apache-2.0, einer permissiven Lizenz mit Patentgewährung und ohne Copyleft-Pflichten für abgeleitete Werke. Wer Soup in ein kommerzielles Produkt einbettet, muss die Lizenzbedingungen einhalten, insbesondere die Beibehaltung der Urheberrechts- und Lizenzhinweise; das ist eine allgemeine Beobachtung zur Lizenzidentifikation und keine Rechtsberatung. Zur Wartung: Die Release-Kadenz ist hoch (v0.73.2, v0.73.3, v0.74.0 innerhalb weniger Wochen), und die Notiz zu v0.73.3 vermerkt, dass jeder Pull Request aus dem Projektumfeld kam. v0.74.0 nennt 116 von 120 zusammengeführten Pull Requests von außerhalb des Maintainers, verteilt über 25 Personen. Eine hohe externe Beteiligung kann ein Zeichen für ein gesundes Projekt sein, sie kann aber auch bedeuten, dass die Richtung von Beitragenden statt von einer Roadmap bestimmt wird. Für die Upgrade-Kosten ist entscheidend, dass v0.74.0 eine Breaking Change an soup serve enthält und dass sich der VRAM-Bedarf durch den fp32-Fix um Faktor 2,59 verändert hat. Ein Upgrade ist also nicht neutral. Wer Soup produktiv einsetzt, sollte die Versionsnummer in der Umgebung festnageln und vor jedem Sprung die Release-Notes auf Änderungen an serve, den Extras und den Lade-Pfaden prüfen.
Redaktionelles Fazit
Soup ist sinnvoll für Einzelpersonen und kleine Teams, die auf einer Consumer-GPU mit 4 bis 8 GB VRAM ein 8B-Modell per LoRA oder QLoRA anpassen wollen und dafür keine Cloud-Instanz mieten möchten. Wer volle Kontrolle über den Trainingsloop, eigene Loss-Funktionen oder Multi-Node-Verteilung braucht, ist mit einem direkt geschriebenen Trainer auf Basis von transformers und peft besser bedient. Vor dem ersten produktiven Lauf sollte man prüfen, ob die installierte torch-Version mit trl>=0.29 zusammenpasst, denn die deklarierte Untergrenze torch>=2.5.0 funktioniert laut Release-Notes nicht mit trl>=0.29. Ebenso sollte man die Layer-Streaming-Leistung auf der eigenen Karte nachmessen, weil die veröffentlichten 119,6 tok/s auf v0.72.2 gemessen wurden und seit der Korrektur in v0.73.0 nicht erneut auf einer 4-GB-Karte reproduziert wurden.
Community-Notizen