Soup : fine-tuner un LLM depuis un seul YAML, avec le streaming de couches en option

Le problème visé : la configuration, pas l'algorithme

Le README chiffre le problème ainsi : les équipes passeraient entre 30 et 50 % de leur temps à se battre contre l'infrastructure plutôt qu'à améliorer les modèles. Soup attaque ce point précis. Le projet ne propose pas de nouvelle méthode d'adaptation : il enveloppe des briques existantes (QLoRA, PEFT, TRL, Transformers) derrière un fichier YAML et une commande. La cible est donc l'ingénieur ou le développeur qui dispose d'un GPU local, y compris modeste, et qui veut un SFT ou un DPO sans écrire la boucle d'entraînement, la détection du matériel ou le calcul du batch size. Le README promet une détection automatique du GPU, du batch size et de la quantification. C'est un choix assumé : moins de contrôle, moins de code à maintenir. Les équipes qui ont déjà des recettes d'entraînement éprouvées n'y gagneront pas grand-chose, et perdront la granularité sur les hyperparamètres exposés.

Le layer streaming : garder la base gelée hors de la VRAM

C'est la partie la plus intéressante du projet et la plus fragile. Le mécanisme est décrit dans le README : la base gelée reste hors de la VRAM et est envoyée au GPU une couche de décodeur à la fois. La documentation annonce un magasin de base de 3,60 Go épinglé en RAM sur 32 couches, plus deux tampons VRAM de 113 Mo, pour un pic mesuré à 3,32 Go sur une RTX 3050 Laptop 4 Go avec Llama-3.1-8B-Instruct en NF4, LoRA, batch 1, séquence 512. Le README précise que le résultat est bit-à-bit identique à un run résident normal, et qu'il a été reproduit sur un H100. Trois réserves, toutes issues du README. D'abord, le débit de 119,6 tok/s a été mesuré sur la v0.72.2, avant la réparation de correction de la v0.73.0 qui a coûté 4,8 % à 32B, et n'a pas été remesuré sur une carte 4 Go depuis. Ensuite, l'option est désactivée par défaut : il faut stream_layers: true. Enfin, elle est étiquetée BETA. La version 0.74.0 indique aussi que le palier gratuit Colab/Kaggle ne pouvait pas streamer du tout avant cette release, T4, P100, V100 et GTX 16xx plantant parce que peft crée les adaptateurs LoRA dans le dtype du checkpoint alors que le GradScaler fp16 a besoin de gradients fp32.

Mise en route : deux commandes et un fichier

L'installation se fait depuis PyPI, avec un extra qui décide de ce que vous installez : pip install "soup-cli[train]" pour fine-tuner, le paquet nu restant un CLI léger. Suivent soup init --template chat, qui génère la configuration, puis soup train, qui lance l'entraînement. La fenêtre de compatibilité Python annoncée est 3.10 à 3.12. Le reste de la surface visible dans le matériel fourni concerne le service : soup serve, et l'option --cloud lambda pour un entraînement distant, en plan-only par défaut, avec une terminaison placée dans un finally qui vérifie ensuite qu'elle a bien eu lieu. Le README ne détaille pas les clés YAML au-delà de stream_layers, donc je ne peux pas en dire davantage sur la structure du fichier généré par soup init. Il existe un notebook Colab gratuit, notebooks/proof-4gb.ipynb, qui plafonne le processus à 4 Go puis vérifie qu'un modèle streamé est bit-identique à un modèle normal. C'est le moyen le plus direct de valider le mode bêta sur votre propre matériel avant de l'utiliser sérieusement.

La limite qui compte : la contrainte de dépendances non résolue

Le README signale lui-même une limitation connue qui mérite d'être lue avant l'installation : le plancher déclaré torch>=2.5.0 ne fonctionne pas avec trl>=0.29, car à torch 2.5.1 trl ne peut pas s'importer. Une installation neuve résout une version plus récente de torch et passe, mais un environnement épinglé sur torch 2.5.x se cassera. C'est le genre de détail qui coûte une demi-journée. Autre point de friction : la v0.74.0 a corrigé un bug où la base gelée était chargée en fp32 sur les trois chemins de chargement, ce qui divisait le pic VRAM par 2,59 sur une configuration inchangée (48 241 MiB à 18 658 MiB sur un H100 avec Llama-3.1-8B et LoRA). Une base entraînable reste volontairement chargée en fp32. Cela signifie que les mesures de VRAM antérieures à la v0.74.0 ne sont pas comparables aux actuelles. Enfin, la v0.74.0 change un comportement : soup serve sort désormais avec le code 2 lorsqu'il est lié à un hôte non-loopback sans --tool-auth-token, au lieu d'afficher un avertissement. Un script qui tolérait l'avertissement échouera maintenant.

Sécurité : quatre contournements SSRF de même forme

La v0.74.0 documente quatre contournements SSRF de même structure, atteignant le garde-fou de télémétrie et de webhook via des écritures IPv4 abrégées, décimales, hexadécimales et octales : 127.1, 2130706433, 0x7f000001, 0177.0.0.1. Un chemin non touché par le premier correctif menait aussi au validateur de traçage OTLP. Que ces variantes aient été trouvées et corrigées est une bonne chose, mais le fait qu'elles partagent toutes la même forme suggère que la validation d'adresses était centralisée tardivement. Si vous exposez soup serve ou des webhooks, la v0.74.0 est le minimum à installer. Le README indique également que /v1/tools/bash a été réactivé derrière une isolation OS, ce qui implique que l'endpoint exécute réellement des commandes : la protection par jeton n'est pas décorative.

Ce à quoi Soup ne convient pas

Le projet est explicitement orienté GPU grand public et mono-machine. Rien dans le matériel fourni ne mentionne de parallélisme de tenseurs, de pipeline multi-nœuds ou d'orchestration de plusieurs GPU pour un même run. Une équipe qui entraîne des modèles de plusieurs dizaines de milliards de paramètres sur un cluster aura besoin d'outils qui exposent ces stratégies, et Soup ne les expose pas. Le layer streaming lui-même a un coût : il échange de la bande passante mémoire et de la latence contre de la VRAM, ce qui n'a aucun intérêt si votre GPU a déjà la place d'héberger la base. Sur une machine confortable, activez-le et vous perdez du débit pour rien. Enfin, le mode étant en bêta, l'utiliser pour un run de production non supervisé est un pari.

L'alternative : garder la main sur la boucle

L'alternative directe n'est pas un autre CLI mais l'assemblage manuel des mêmes briques : un script Python qui utilise peft pour les adaptateurs LoRA, trl pour les entraîneurs SFT et DPO, et transformers pour le chargement. C'est exactement la pile que Soup enveloppe, comme l'indique la liste des dépendances citées dans les notes de version (Transformers 5.x, TRL 0.29, PEFT 0.20). La différence n'est pas la qualité de l'entraînement, elle est dans le contrôle. Avec un script maison, vous décidez du dtype de la base, de la stratégie de chargement, du format de sauvegarde et de l'intégration dans votre CI. Avec Soup, vous obtenez la détection automatique du matériel, un fichier YAML et une commande, au prix de la flexibilité. Le layer streaming est l'argument qui départage : c'est une fonctionnalité que peu de gens écrivent eux-mêmes, et elle est le seul élément du projet qui ne se remplace pas par vingt lignes de configuration PEFT.

Maintenance, licence et ce qu'il faut vérifier

Le rythme de publication est rapide : v0.73.2, v0.73.3 et v0.74.0 s'échelonnent sur quelques semaines, et les intitulés de version décrivent des corrections de correction, ce qui suggère un projet encore en train de stabiliser ses fondations. La v0.73.3 note que toutes les pull requests de cette release venaient de l'extérieur, et la v0.74.0 en compte 116 sur 120 provenant de 25 personnes. C'est un signal sur la gouvernance, pas une garantie de qualité. Côté licence, le code est sous Apache-2.0, ce qui autorise l'usage commercial et la modification avec conservation des mentions. Cette licence ne couvre pas les poids des modèles que vous téléchargez : chaque modèle a sa propre licence, et c'est elle qu'il faut lire avant de publier un modèle ajusté. La surface de mise à jour est celle d'un paquet Python ordinaire, mais les changements de comportement comme la sortie code 2 de soup serve imposent de relire les notes de version avant chaque montée. Pour un premier essai, le notebook Colab fourni est le point de départ le moins coûteux : il plafonne le processus à 4 Go et vérifie l'équivalence bit-à-bit, ce qui teste la promesse centrale du projet sur votre propre environnement.

Conclusion éditoriale

Soup convient à qui possède un GPU grand public, une carte 4 Go ou une session Colab gratuite, et veut un SFT ou un DPO sans écrire de boucle d'entraînement. Il ne convient pas aux équipes qui ont besoin d'un entraînement multi-nœuds avec parallélisme de tenseurs, ni à celles qui refusent un mode bêta dans leur chemin critique. Avant d'adopter, vérifiez trois choses : que votre version de torch satisfait bien la contrainte réelle de trl>=0.29, que stream_layers: true produit une base identique à un run résident sur votre matériel, et que la licence du modèle que vous téléchargez autorise l'usage prévu, Apache-2.0 ne couvrant que le code de Soup.

Sources officielles

1. License: Apache-2.0
2. MakazhanAlpamys/Soup on GitHub
3. Project website
4. README
5. Releases