Show HN: Llama-Finetuning mit 80 % mehr Geschwindigkeit, 50 % weniger Speicherverbrauch und 0 % Genauigkeitsverlust

 (github.com/unslothai)
2 Punkte von GN⁺ 2023-12-03 | 1 Kommentare | Auf WhatsApp teilen
  • Unsloth bietet mit Unsloth Studio eine Web-UI zum lokalen Ausführen und Trainieren von Modellen sowie mit Unsloth Core eine codebasierte Variante; unterstützt werden Text-, Audio-, Embedding- und Vision-Modelle unter Windows, Linux, WSL und macOS
  • Die Trainingsfunktionen unterstützen mehr als 500 Modelle für Finetuning, RL und Pretraining; zentrale Leistungsziele sind bis zu 2× schnelleres Training, bis zu 70 % weniger VRAM und kein Genauigkeitsverlust
  • Zu den Inferenzfunktionen gehören das Suchen, Herunterladen und Ausführen von GGUF-, LoRA-Adapter- und safetensors-Modellen, Modellexport, Tool Calling, Websuche, Codeausführung und lokale API-Inferenzendpunkte
  • Unsloth Studio bindet standardmäßig an localhost; --secure nutzt einen Cloudflare-HTTPS-Tunnel, während -H 0.0.0.0 rohe Ports nach außen öffnen kann, weshalb der Schutz von API-Schlüsseln und die Verwendung von --disable-tools wichtig sind
  • Das Lizenzmodell ist dual mit Apache 2.0 und AGPL-3.0: Das Core-Paket steht unter Apache 2.0, einige optionale Komponenten wie die Studio-UI unter AGPL-3.0

Was Unsloth bietet

  • Unsloth Studio (Beta) ist eine Web-UI zum lokalen Ausführen und Trainieren von Modellen
  • Unsloth Core ist die codebasierte Version und hat andere Anforderungen als Studio
  • Einstiegskommandos für die Installation werden je nach OS bereitgestellt

Inferenzfunktionen

  • Unterstützt das Suchen, Herunterladen und Ausführen von Modellen; zu den Zielformaten gehören GGUF, LoRA-Adapter und safetensors
  • Modelle können als GGUF, 16-bit safetensors oder in anderen Formaten gespeichert oder exportiert werden
  • Tool Calling unterstützt selbstheilendes Tool Calling und Websuche
  • Die Codeausführung erlaubt es LLMs, Code in Claude artifacts und einer Sandbox-Umgebung zu testen
  • Über API-Inferenzendpunkte lassen sich lokale LLMs zusammen mit Claude Code und Codex tools bereitstellen und ausführen
  • Verbindungen zu API-Anbietern wie OpenAI und Anthropic oder zu Servern wie vLLM und Ollama sind möglich
  • Es kann mit Bildern, Audio, PDFs, Code, DOCX und mehr gechattet werden
  • Laut Unsloth wurden in direkter Zusammenarbeit mit Teams rund um gpt-oss, Qwen3, Llama 4, Mistral, Gemma 1-3 und Phi-4 Bugs behoben, die die Modellgenauigkeit verbessern

Trainingsfunktionen und Leistung

  • Unsloth unterstützt Training und RL für mehr als 500 Modelle
    • Bis zu 2× schnelleres Training
    • Bis zu 70 % weniger VRAM
    • Kein Genauigkeitsverlust
  • Verwendet benutzerdefinierte Triton- und mathematische Kernels
    • Verlinkt ist ein Kollaborationsbeispiel zu FP8-Reinforcement-Learning mit PyTorch
    • Verlinkt ist außerdem ein Kollaborationsbeispiel mit Hugging Face zu schnellerem MoE
  • Data Recipes erzeugen automatisch Datensätze aus PDFs, CSVs, DOCX und mehr; Daten können in einem visuellen Node-Workflow bearbeitet werden
  • Für Reinforcement Learning mit GRPO, FP8 usw. wird ein um bis zu 80 % geringerer VRAM-Verbrauch angegeben
  • Unterstützte Trainingsarten umfassen Full Finetuning, RL, Pretraining, 4-bit-, 16-bit- und FP8-Training
  • Mit den Observability-Funktionen lassen sich Trainingsstatus in Echtzeit überwachen sowie Loss, GPU-Nutzung und Graphen anpassen
  • Multi-GPU-Training wird unterstützt; größere Verbesserungen sollen bald folgen

Installations- und Laufzeitvoraussetzungen

  • Unsloth Studio läuft unter Windows, Linux, WSL und macOS
    • CPU: unterstützt derzeit Chat und Data Recipes
    • NVIDIA: Training wird auf RTX 30/40/50, Blackwell, DGX Spark, Station usw. unterstützt
    • macOS: unterstützt Training, MLX und GGUF-Inferenz
    • AMD: Chat und Data werden unterstützt, für Training ist Unsloth Core zu verwenden; Studio-Support folgt in Kürze
    • Multi-GPU: aktuell nutzbar, größere Upgrades sind geplant
  • Das Startkommando für Studio lautet unsloth studio -p 8888
  • Ein Docker-Image wird als Container unsloth/unsloth bereitgestellt
  • Für die Installation von Unsloth Core gibt es Beispiele auf Basis von uv und Python 3.13
    • Linux, WSL: uv venv unsloth_env --python 3.13 gefolgt von uv pip install unsloth --torch-backend=auto
    • Windows: nach Installation von Python 3.13 und astral-sh.uv auf dieselbe Weise
    • Unter Windows funktioniert pip install unsloth nur, wenn PyTorch bereits installiert ist
  • Die Installation für AMD- und Intel-GPUs folgt dem jeweiligen AMD Guide bzw. Intel Guide

Remote-Zugriff und Sicherheitsbedingungen

  • Standardmäßig bindet unsloth studio an 127.0.0.1 und ist nur von der aktuellen Maschine aus erreichbar
  • --secure wird nur über einen kostenlosen Cloudflare-HTTPS-Link bereitgestellt
    • Studio bleibt auf localhost
    • Wenn der Tunnel nicht startet, arbeitet es nach dem Fail-Closed-Prinzip und legt keinen rohen Port offen
  • -H 0.0.0.0 bindet rohe Ports an alle Netzwerkschnittstellen
    • Dadurch ist der Zugriff aus dem gesamten Netzwerk möglich und sollte nur in vertrauenswürdigen Netzwerken verwendet werden
  • Serverseitige Tools wie Websuche, Python und Terminal-Codeausführung laufen mit Benutzerrechten und sind standardmäßig aktiviert
  • Wer Zugriff auf den Server und die API-Schlüssel hat, kann auf dieser Maschine Code ausführen; daher sollten API-Schlüssel privat bleiben und beim Exponieren von Studio --disable-tools verwendet werden

Kostenlose Notebooks und Beispielmodelle

  • Mit dem kostenlosen Unsloth Studio notebook lassen sich Modelle in der Web-UI ausführen und trainieren
  • Die bereitgestellten Notebook-Beispiele nennen je Modell auch Leistungs- und Speichereinsparungen
    • Gemma 4 (E2B): 1,5× schneller, 50 % weniger Speicher
    • Qwen3.5 (4B): 1,5× schneller, 60 % weniger Speicher
    • gpt-oss (20B): 2× schneller, 70 % weniger Speicher
    • gpt-oss (20B): GRPO: 2× schneller, 80 % weniger Speicher
    • Llama 3.1 (8B) Alpaca: 2× schneller, 70 % weniger Speicher
    • Orpheus-TTS (3B): 1,5× schneller, 50 % weniger Speicher
  • Zusätzlich gibt es Listen mit Notebooks für Kaggle, GRPO, TTS, Embeddings und Vision
  • Alle Modelle sind im Unsloth Catalog, alle Notebooks unter Unsloth notebooks zu finden

Aktuelle Funktionspunkte

  • Connections: unterstützt Verbindungen zu API-Anbietern wie OpenAI und Anthropic oder zu Servern wie vLLM und Ollama
  • MTP: unterstützt das Ausführen von Qwen3.6 MTP und setzt MTP-Konfigurationen je nach Hardware automatisch
  • Qwen3.6: Qwen3.6-35B-A3B kann in Unsloth Studio trainiert und ausgeführt werden
  • Gemma 4: Googles neues Modell kann direkt in Unsloth ausgeführt und trainiert werden
  • MoE LLM: für DeepSeek, GLM, Qwen und gpt-oss werden 12× schnelleres Training und 35 % weniger VRAM angegeben
  • Embedding models: unterstützt Embedding-Finetuning etwa 1,8× bis 3,3× schneller
  • 7x longer context RL: neuer Batching-Algorithmus ermöglicht im Vergleich zu anderen Setups 7× längeres Kontext-RL
  • 500K Context: Auf einer 80GB-GPU kann ein 20B-Modell mit mehr als 500K Kontext trainiert werden
  • FP8 & Vision RL: FP8 und VLM-GRPO sind auf Consumer-GPUs möglich

Lizenz und zugrunde liegende Projekte

  • Unsloth verwendet ein duales Lizenzmodell aus Apache 2.0 und AGPL-3.0
    • Das Kernpaket Unsloth bleibt unter Apache 2.0
    • Einige optionale Komponenten wie die Unsloth-Studio-UI stehen unter AGPL-3.0
  • Als Basisprojekte werden llama.cpp, Hugging Face transformers, TRL, PyTorch, Torch AO und NVIDIA NeMo DataDesigner genannt

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-12-03
Hacker-News-Kommentare

  • Ich habe den Code nicht selbst ausgeführt, aber ich verstehe nicht ganz, wie das möglich sein soll.
    Wenn man QLoRA-Finetuning von Llama-2-70B mit PyTorch profiliert, entfällt der Großteil der Laufzeit auf die großen Matrixmultiplikationen in den MLP-Schichten, dazu kommt noch etwas Attention.
    Intern scheint dieses Repository für MLP ebenfalls torch.matmul() und für Attention flash_attn_func() aufzurufen und damit denselben Pfad wie HuggingFace zu verwenden; ich frage mich also, wie es so viel schneller sein kann.
    Es gibt zwar ein paar Triton-Kernel, aber für die meisten Engpässe, also MLP oder Attention, scheint Triton nicht verwendet zu werden.

    • Als Erklärung wird optimierter Custom Autograd genannt, und da Autograd ein zentraler Bestandteil der Gradientenberechnung ist, klingt das grundsätzlich sinnvoll.
      Es werden auch einfache Verbesserungen wie Function Inlining oder Speicheroptimierung erwähnt; dort gibt es definitiv Optimierungspotenzial.
      Allerdings bin ich nicht sicher, ob diese Vorteile in einer Closed-Source-„Pro“-Version verbleiben können.
      Wenn es sich um niedrig hängende Früchte handelt, werden Open-Source-Implementierungen sie wahrscheinlich bald übernehmen.
    • Eine ausführlichere Erklärung gibt es unter https://unsloth.ai/introducing.
    • Ziemlich große Behauptungen sind hinter der kostenpflichtigen Pro-Version gesperrt. Das wirkt wie ein Warnsignal.

  • Ignoriert die Kritik an der Preisgestaltung hier erst einmal: Ich würde sofort jemanden suchen, der als Sales oder Solution Engineer bei einem frühen Datenbankunternehmen gearbeitet hat, und anfangen, High-End-Kunden mit Tausenden GPUs kalt anzurufen.
    Um das zu verkaufen, sind B2B-Deals im Bereich von 200.000 bis 300.000 Dollar oder mehr wahrscheinlich der aussichtsreichste Weg.

  • Für alle Interessierten: Wir haben gerade einen neuen Blogbeitrag veröffentlicht, der alle Optimierungen behandelt.
    Außerdem gibt es 59 vollständig reproduzierbare Benchmarks: https://unsloth.ai/blog/mistral-benchmark

  • Die Ergebnisse sehen vielversprechend aus, daher würde ich es gern selbst ausprobieren.
    Eine Frage zu den Performance-Benchmarks: Warum dauern alle Ergebnisse mit 2 GPUs und DDP länger als mit einer einzelnen GPU?
    Beide Benchmarks leisten mit einer Trainings-Epoche dieselbe Menge Arbeit, daher ist diese negative Skalierung überraschend.

    • Die Hauptgründe sind zwei Dinge.
      Erstens hat DDP selbst Overhead, weil GPU0 und GPU1 bei jedem Trainingsschritt synchronisieren müssen, indem sie die Gradienten an GPU0 übertragen.
      Zweitens scheint HuggingFace wegen ineffizienter Datenbewegungen nicht gut für DDP optimiert zu sein; das haben wir behoben. Interessanterweise wird es dadurch auch auf einer einzelnen GPU schneller.

  • Es wäre schön, eine Chronik dieser verschiedenen Ansätze zu haben. Es gibt inzwischen so viele Varianten, dass ich schon vor einer ganzen Weile den Überblick verloren habe.
    Das wäre vermutlich ziemlich viel Arbeit, sofern man selbst gemeldete Metriken nicht einfach als Wahrheit übernimmt.
    Und selbst dann hängt es immer von Hardware und Einsatzbereich ab.
    Damit es wirklich nützlich wird, bräuchte man eine CI/CD-Pipeline mit mehreren Maschinenkonfigurationen und Benchmarks sowie eine vernünftige Methode, die Ergebnisse zu kommunizieren.
    Wenn das jemand schafft, wäre es wirklich unverzichtbar.

    • Genau das dachte ich auch.
      Ich schreibe gerade einen Blogbeitrag unter https://colab.research.google.com/drive/1AOuhMVILE06mD-Go7-R..., in dem ich alle von mir vorgenommenen Änderungen Schritt für Schritt zeige, inklusive Zeitmessungen und Speichereinsparungen.
      Wenn Interesse besteht, poste ich ihn, sobald er fertig ist.

  • Mich würde interessieren, wie sich das mit Sam und den llama2-Optimierungen von PyTorch Labs vergleicht.
    https://github.com/pytorch-labs/segment-anything-fast
    https://github.com/pytorch-labs/gpt-fast

    • Das ist für Inferenz, unser Code ist für Training.
      Schnellere Inferenz ist ebenfalls geplant.
      Ich habe Chillees GPT Fast gesehen, und es ist wirklich unglaublich schnell.

  • Etwas damit verwandt: Ich frage mich, ob es sich noch lohnt, P100 oder P40 zu verwenden.
    Ich wollte mir eine kaufen, aber es scheint, als falle Pascal bei immer mehr Projekten aus dem Support heraus.

    • Die P100 dürfte wohl von Xformers’ Flash Attention unterstützt werden, aber Triton unterstützt Compute Capability 7.0 oder höher, und die P100 hat 6.0, was zum Problem wird.
      Technisch könnte der Code laufen, aber man müsste ihn anpassen, um die Triton-Änderungen zu entfernen.

  • Das sieht sehr interessant aus, aber ich bin verwirrt, warum die Version mit maximaler Beschleunigung nur für Enterprise freigeschaltet ist.
    Es ergäbe mehr Sinn, den Performance-Unterschied nur zwischen Free- und Paid-Plan zu machen und Enterprise über Dinge wie Support zu differenzieren.

    • Guter Punkt. Darüber haben wir auch nachgedacht, und da wir die Preisgestaltung noch weiter austarieren, sind alle Vorschläge willkommen.
      All das ist für uns neu, daher entwickeln wir es praktisch während des Machens.

  • Es war von GPUs ab 2018 die Rede; ich frage mich, warum es zum Beispiel auf einer 1080 Ti nicht läuft.
    Wenn man grob auf die Hardware-Spezifikationen schaut, scheint sie CUDA 8 oder höher zu unterstützen, während hier 7.5 angegeben ist.
    Kann das jemand genauer erklären?

    • Bei der 1080 Ti ist es leider so: Da Triton und Xformers CUDA 7.0 unterstützen und OpenAI sowie Meta CUDA 6.0 nicht unterstützen, ist es auch für uns schwierig, sie zu unterstützen.
      Der Hauptgrund ist, dass es ab Turing Tensor Cores gibt und sich Matrixmultiplikationen dadurch auf Tensor-Cores-Basis verändert haben.
    • Die CUDA Compute Capability der 1080 Ti ist 6.1.