Show HN : fine-tuning de Llama 80 % plus rapide, avec 50 % de mémoire en moins et 0 % de perte de précision
(github.com/unslothai)- Unsloth propose Unsloth Studio, pour exécuter et entraîner des modèles en local, ainsi que Unsloth Core, piloté par code, et prend en charge les modèles texte, audio, embeddings et vision sous Windows, Linux, WSL et macOS
- Les fonctions d’entraînement prennent en charge le fine-tuning, le RL et le pré-entraînement de plus de 500 modèles, avec comme principaux objectifs de performance jusqu’à 2× plus rapide, jusqu’à 70 % de VRAM en moins et aucune perte de précision
- Les fonctions d’inférence couvrent la recherche, le téléchargement et l’exécution de modèles GGUF, d’adaptateurs LoRA et de modèles safetensors, l’export de modèles, l’appel d’outils, la recherche web, l’exécution de code et un endpoint d’inférence d’API local
- Unsloth Studio se lie par défaut à localhost ;
--secureutilise un tunnel HTTPS Cloudflare et-H 0.0.0.0peut exposer un port brut vers l’extérieur, d’où l’importance de protéger les clés API et d’utiliser--disable-tools - La licence suit une structure double Apache 2.0 et AGPL-3.0 : le package Core est sous Apache 2.0, tandis que certains composants optionnels comme l’UI Studio sont sous AGPL-3.0
Ce que propose Unsloth
- Unsloth Studio (Beta) est une UI web permettant d’exécuter et d’entraîner des modèles en local
- Fonctionne sous Windows, Linux, WSL et macOS
- Prend en charge les modèles de texte, audio, embeddings et vision
- Unsloth Core est la version pilotée par code, avec des prérequis différents de ceux de Studio
- Les commandes d’installation de démarrage sont fournies selon l’OS
- macOS, Linux, WSL :
curl -fsSL https://unsloth.ai/install.sh | sh - Windows :
irm https://unsloth.ai/install.ps1 | iex
- macOS, Linux, WSL :
Fonctions d’inférence
- Prend en charge la recherche, le téléchargement et l’exécution de modèles, avec des formats cibles incluant GGUF, les adaptateurs LoRA et safetensors
- Permet d’enregistrer ou exporter les modèles en GGUF, safetensors 16-bit et d’autres formats
- L’appel d’outils prend en charge l’appel d’outils à auto-réparation et la recherche web
- L’exécution de code permet au LLM de tester du code dans des artifacts Claude et dans un environnement sandbox
- Via un endpoint d’inférence d’API, il est possible de déployer et d’exécuter des LLM locaux avec Claude Code et Codex tools
- Peut se connecter à des fournisseurs d’API comme OpenAI et Anthropic, ou à des serveurs comme vLLM et Ollama
- Permet de chatter avec des images, de l’audio, des PDF, du code, des DOCX, etc.
- Indique avoir corrigé, en collaboration directe avec les équipes liées à gpt-oss, Qwen3, Llama 4, Mistral, Gemma 1-3 et Phi-4, des bugs améliorant la précision des modèles
Fonctions d’entraînement et performances
- Unsloth prend en charge l’entraînement et le RL de plus de 500 modèles
- Jusqu’à 2× plus rapide
- Jusqu’à 70 % de VRAM en moins
- Aucune perte de précision
- Utilise Triton personnalisé et des kernels mathématiques
- Un exemple de collaboration avec PyTorch autour du reinforcement learning en FP8 est lié
- Un exemple de collaboration avec Hugging Face autour de MoE plus rapides est lié
- Data Recipes génère automatiquement des datasets à partir de PDF, CSV, DOCX, etc., et permet d’éditer les données dans un workflow visuel à nœuds
- Pour le reinforcement learning, il est indiqué utiliser jusqu’à 80 % de VRAM en moins pour GRPO, FP8, etc.
- Les modes d’entraînement pris en charge incluent full fine-tuning, RL, pretraining, 4-bit, 16-bit et FP8 training
- Les fonctions d’observabilité permettent de surveiller l’état de l’entraînement en temps réel et prennent en charge la loss, l’utilisation GPU et la personnalisation des graphiques
- Prend en charge l’entraînement Multi-GPU, avec de grosses améliorations prévues prochainement
Installation et conditions d’exécution
- Unsloth Studio fonctionne sous Windows, Linux, WSL et macOS
- CPU : prend actuellement en charge Chat et Data Recipes
- NVIDIA : prend en charge l’entraînement sur RTX 30/40/50, Blackwell, DGX Spark, Station, etc.
- macOS : prend en charge l’entraînement, MLX et l’inférence GGUF
- AMD : prend en charge Chat et Data ; pour l’entraînement, utiliser Unsloth Core ; la prise en charge dans Studio est prévue prochainement
- Multi-GPU : disponible actuellement, avec une mise à niveau majeure prévue
- La commande de lancement de Studio est
unsloth studio -p 8888 - L’image Docker est fournie via le conteneur unsloth/unsloth
- L’installation d’Unsloth Core fournit un exemple basé sur
uvet Python 3.13- Linux, WSL : après
uv venv unsloth_env --python 3.13, exécuteruv pip install unsloth --torch-backend=auto - Windows : installer Python 3.13 et
astral-sh.uv, puis procéder de la même manière - Sous Windows,
pip install unslothne fonctionne que si PyTorch est installé
- Linux, WSL : après
- L’installation pour GPU AMD et Intel suit respectivement l’AMD Guide et l’Intel Guide
Accès distant et conditions de sécurité
- Par défaut,
unsloth studiose lie à 127.0.0.1 et n’est accessible que depuis la machine actuelle --secureest fourni uniquement via un lien HTTPS Cloudflare gratuit- Studio reste sur localhost
- Si le tunnel ne démarre pas, il échoue de façon fermée et n’expose pas de port brut
-H 0.0.0.0lie le port brut à toutes les interfaces réseau- Il devient accessible depuis n’importe où sur le réseau et ne doit être utilisé que sur des réseaux de confiance
- Les outils côté serveur comme la recherche web, Python et l’exécution de code dans le terminal s’exécutent avec les droits de l’utilisateur et sont activés par défaut
- Toute personne ayant accès au serveur et disposant d’une clé API peut exécuter du code sur cette machine ; il faut donc garder les clés API privées et utiliser
--disable-toolslorsque Studio est exposé
Notebooks gratuits et exemples de modèles pris en charge
- Le notebook Unsloth Studio gratuit permet d’exécuter et d’entraîner des modèles dans l’UI web
- Les exemples de notebooks fournis présentent aussi les chiffres de performance et d’économie mémoire par modèle
- Gemma 4 (E2B) : 1,5× plus rapide, 50 % de mémoire en moins
- Qwen3.5 (4B) : 1,5× plus rapide, 60 % de mémoire en moins
- gpt-oss (20B) : 2× plus rapide, 70 % de mémoire en moins
- gpt-oss (20B) : GRPO : 2× plus rapide, 80 % de mémoire en moins
- Llama 3.1 (8B) Alpaca : 2× plus rapide, 70 % de mémoire en moins
- Orpheus-TTS (3B) : 1,5× plus rapide, 50 % de mémoire en moins
- Des listes de notebooks pour Kaggle, GRPO, TTS, embeddings et Vision sont également fournies séparément
- L’ensemble des modèles est consultable dans l’Unsloth Catalog, et l’ensemble des notebooks dans les Unsloth notebooks
Fonctionnalités récentes
- Connections : prise en charge des connexions à des fournisseurs d’API comme OpenAI et Anthropic, ou à des serveurs comme vLLM et Ollama
- MTP : prise en charge de l’exécution de Qwen3.6 MTP, avec configuration MTP automatiquement définie selon le matériel
- Qwen3.6 : Qwen3.6-35B-A3B peut être entraîné et exécuté dans Unsloth Studio
- Gemma 4 : le nouveau modèle de Google peut être exécuté et entraîné directement dans Unsloth
- MoE LLM : annonce un entraînement 12× plus rapide et 35 % de VRAM en moins pour DeepSeek, GLM, Qwen et gpt-oss
- Embedding models : prise en charge du fine-tuning d’embeddings environ 1,8 à 3,3× plus rapide
- 7x longer context RL : nouvel algorithme de batching offrant un RL avec un contexte 7× plus long que d’autres configurations
- 500K Context : possibilité d’entraîner un modèle 20B avec un contexte de plus de 500K sur un GPU 80 GB
- FP8 & Vision RL : possibilité d’exécuter FP8 et VLM GRPO sur des GPU grand public
Licences et projets de base
- Unsloth utilise un modèle de double licence Apache 2.0 et AGPL-3.0
- Le package Unsloth principal reste sous Apache 2.0
- Certains composants optionnels comme l’UI Unsloth Studio relèvent de l’AGPL-3.0
- Le projet mentionne llama.cpp, transformers de Hugging Face, TRL, PyTorch, Torch AO, NVIDIA NeMo DataDesigner, etc.
1 commentaires
Avis sur Hacker News
Je n’ai pas exécuté le code moi-même, mais je ne vois pas très bien comment c’est possible.
Quand on profile le fine-tuning QLoRA de Llama-2-70B avec PyTorch, l’essentiel du temps d’exécution est pris par les grosses multiplications de matrices des couches MLP, avec un peu d’attention en plus.
En interne, ce dépôt semble lui aussi appeler
torch.matmul()pour les MLP etflash_attn_func()pour l’attention, donc suivre le même chemin que HuggingFace ; je me demande donc comment il peut être tellement plus rapide.Il y a bien quelques kernels Triton, mais il ne semble pas y avoir de Triton sur les principaux goulets d’étranglement que sont les MLP ou l’attention.
Ils mentionnent aussi des améliorations plus simples comme l’inlining de fonctions ou l’optimisation mémoire, des aspects qui ont clairement du potentiel d’optimisation.
En revanche, je ne sais pas si ces gains peuvent rester réservés à la version « pro » à source fermée.
Si ce sont des fruits faciles à cueillir, il y a de fortes chances que les implémentations open source les reprennent bientôt.
En mettant de côté les critiques sur le prix, je recommanderais de trouver tout de suite un commercial ou un ingénieur solutions ayant travaillé dans une jeune entreprise de bases de données, et de commencer à faire du cold calling auprès de clients haut de gamme possédant des milliers de GPU.
Pour vendre ça, la voie la plus probable me semble être des contrats B2B à 200 000–300 000 dollars ou plus.
Pour ceux que ça intéresse, nous venons de publier un nouvel article de blog qui couvre toutes les optimisations.
Il contient aussi 59 benchmarks entièrement reproductibles : https://unsloth.ai/blog/mistral-benchmark
Les résultats semblent prometteurs et j’aimerais l’essayer moi-même.
J’ai une question sur les benchmarks de performance : pourquoi tous les résultats utilisant 2 GPU et DDP prennent-ils plus de temps qu’un seul GPU ?
Dans les deux benchmarks, on effectue la même quantité de travail avec une seule époque d’entraînement, donc cette mise à l’échelle inverse est surprenante.
Premièrement, DDP a son propre surcoût, car à chaque étape d’entraînement GPU0 et GPU1 doivent se synchroniser en transmettant les gradients à GPU0.
Deuxièmement, HuggingFace ne semble pas très bien optimisé pour DDP à cause de déplacements de données inefficaces, et nous avons corrigé ce point. Fait intéressant, cela accélère aussi l’exécution sur un seul GPU.
Ce serait bien d’avoir une chronologie qui récapitule toutes ces différentes tentatives. Il y a tellement de variantes que j’ai perdu le fil depuis un bon moment.
À moins d’accepter les métriques auto-déclarées comme des vérités, cela représenterait un assez gros travail.
Et même là, les résultats dépendent toujours du matériel et du périmètre d’utilisation.
Pour que ce soit vraiment utile, il faudrait un pipeline CI/CD avec plusieurs configurations de machines et benchmarks, ainsi qu’une manière raisonnable de présenter les résultats.
Si quelqu’un y parvient, cela deviendra vraiment indispensable.
Je suis en train d’écrire un article de blog sur https://colab.research.google.com/drive/1AOuhMVILE06mD-Go7-R..., où je montre étape par étape toutes les modifications que j’ai faites, avec les mesures de temps et les économies de mémoire.
Si ça t’intéresse, je le publierai dès qu’il sera terminé.
Je me demande comment cela se compare à Sam de PyTorch Labs et à leurs optimisations de llama2.
https://github.com/pytorch-labs/segment-anything-fast
https://github.com/pytorch-labs/gpt-fast
Nous prévoyons aussi une inférence plus rapide par la suite.
J’ai regardé GPT Fast de Chillee, et c’est vraiment incroyablement rapide.
Dans un registre un peu lié, je me demande s’il vaut encore la peine d’utiliser des P100 ou P40.
J’envisageais d’en acheter une, mais Pascal semble perdre le support dans de plus en plus de projets.
Techniquement, le code pourrait s’exécuter, mais il faudrait le modifier pour supprimer les changements liés à Triton.
Ça a l’air très intéressant, mais je ne comprends pas pourquoi la version offrant l’accélération maximale est réservée à l’Enterprise.
Il me semblerait plus logique de différencier les plans Free et Paid par les performances, et de réserver à Enterprise des éléments comme le support.
Tout cela est nouveau pour nous, donc nous construisons au fur et à mesure en expérimentant concrètement.
Ils mentionnent les GPU postérieurs à 2018 ; je me demande donc pourquoi cela ne fonctionne pas, par exemple, sur une 1080 Ti.
En regardant rapidement les spécifications matérielles, elle semble prendre en charge CUDA 8 et plus, alors qu’ici il est question de 7.5.
Quelqu’un peut-il expliquer davantage ?
La principale raison est qu’à partir de Turing, les Tensor Cores sont disponibles, et les multiplications de matrices sont devenues basées sur les Tensor Cores.