Soup 0.74.0 corrige une erreur de gestion mémoire qui pouvait faire paraître un entraînement LoRA beaucoup plus exigeant en GPU que ne le laissait prévoir sa configuration. Publiée le 4 septembre, cette version modifie trois chemins de chargement qui matérialisaient le modèle de base gelé en fp32 alors que ses poids n'étaient pas mis à jour par l'optimiseur.
Dans ses notes de version 0.74.0, le projet indique qu'un essai sur H100 avec Llama-3.1-8B et LoRA a fait passer le pic mémoire de 48 241 MiB à 18 658 MiB. Soup parle d'une réduction d'un facteur 2,59 et de trois répétitions identiques octet par octet. Ces chiffres proviennent du projet et n'ont pas fait l'objet d'une reproduction indépendante identifiée par Aipolix. Le paquet soup-cli 0.74.0 est également disponible sur PyPI.
Le problème venait du chargement, pas de la taille du modèle
Le point technique central est simple : le modèle de base gelé était chargé avec une précision numérique plus large que nécessaire. Selon Soup, les trois appels from_pretrained utilisés pour le texte, la vision et l'audio ne fixaient pas explicitement le type de données. Le modèle de base finissait donc matérialisé en fp32. Avec LoRA, ce socle reste pourtant gelé tandis qu'un ensemble bien plus réduit de paramètres d'adaptation est entraîné.
La version 0.74.0 charge désormais une base gelée dans la précision prévue par le fichier de poids du modèle. En revanche, un modèle de base réellement entraîné reste volontairement en fp32 pour un ajustement complet. Le gain mémoire ne vient donc ni d'une nouvelle compression ni d'une architecture différente, mais de la correction du format utilisé pour des poids qui n'ont pas besoin d'être optimisés.
Soup a également unifié la logique qui détermine si un entraînement est complet. Le programme d'entraînement et l'estimation préalable de mémoire utilisaient auparavant deux implémentations distinctes susceptibles de diverger. Ils partagent maintenant la même décision sur le caractère entraînable du modèle de base.
Un écart de 28,9 Go peut changer le choix du GPU
L'analyse d'Aipolix est que les choix implicites du logiciel d'entraînement doivent entrer dans le calcul de capacité, au même titre que la taille du modèle ou la quantification. Une équipe peut choisir correctement son modèle et sa configuration LoRA tout en obtenant une estimation matérielle trompeuse si le logiciel modifie silencieusement la précision effective lors du chargement.
Dans le test H100 publié par Soup, l'écart de pic mémoire atteint 28,9 Go. Une telle différence peut décider si un entraînement tient sur un accélérateur donné, s'il faut louer une instance plus grande ou si l'ajustement paramétriquement efficace reste économiquement pertinent sur l'infrastructure visée.
La leçon dépasse Soup : il faut vérifier la précision réellement utilisée en mémoire et le statut gelé ou entraînable de la base, puis comparer le pic mesuré à l'estimation du planificateur. Une intention inscrite dans un fichier de configuration ne prouve pas à elle seule ce qui s'est produit à l'exécution.
La version durcit aussi plusieurs frontières de sécurité
Soup 0.74.0 ne se limite pas à la mémoire. Plusieurs contrôles liés au service et aux outils évoluent également.
Le projet réactive /v1/tools/bash avec une isolation par espaces de noms et bac à sable du système d'exploitation. Comme cette route exécute réellement du code, soup serve s'arrête désormais avec le code 2 lorsqu'il écoute sur une adresse non locale sans --tool-auth-token; auparavant, il se contentait d'un avertissement. La version bloque aussi quatre écritures alternatives d'adresses IPv4 qui pouvaient contourner la validation des destinations de télémétrie, webhooks et OTLP. Enfin, l'intégration SGLang respecte maintenant l'option --trust-remote-code au lieu d'autoriser implicitement le code distant fourni par un modèle.
Il s'agit de comportements annoncés dans les sources du projet. Leur intérêt opérationnel tient au passage d'un avertissement ou d'une valeur implicite à un refus explicite ou à un choix volontaire.
La compatibilité progresse, avec une limite encore documentée
La version ajoute la prise en charge de Transformers 5.x, TRL 0.29 et PEFT 0.20, rétablit l'installation conjointe des extras train,mlx et ouvre le chemin Transformers aux décodeurs texte de la famille Qwen3.5. Une nouvelle commande pour Lambda prépare aussi le plan avant exécution, conserve la clé d'API localement et confie l'arrêt de l'instance à un contrôleur local.
Les notes de version signalent toutefois un défaut précis : la borne déclarée torch>=2.5.0 n'est pas réellement compatible avec trl>=0.29. Le projet a reproduit l'échec sur torch 2.5.1, où FSDPModule manque. Une installation neuve qui résout une version plus récente de Torch peut ne pas être concernée, mais un environnement figé sur 2.5.x peut perdre DPO, KTO, GRPO et BCO.
C'est un rappel utile : une résolution de dépendances réussie ne constitue pas une preuve que la combinaison a été testée.
Le facteur 2,59 reste une mesure circonscrite
Le résultat mémoire est important, mais il ne faut pas l'étendre au-delà de son protocole. Il provient d'un essai du projet sur H100, avec Llama-3.1-8B et LoRA. Soup affirme avoir obtenu trois répétitions identiques, mais Aipolix n'a trouvé aucune reproduction indépendante spécifique à la version 0.74.0.
Il serait donc excessif de promettre un facteur 2,59 pour tous les modèles, GPU, modes de quantification ou parcours d'entraînement. L'énoncé solide est plus restreint : Soup a corrigé un chargement fp32 et mesuré une forte baisse de mémoire sur une configuration documentée.
Le chargement couche par couche de Soup, autre mécanisme destiné à entraîner de grands modèles de base gelés sur de petits GPU, reste par ailleurs explicitement en version bêta.
Ce qu'il faut mesurer après la mise à jour
Les équipes qui utilisent déjà Soup devraient rejouer le cas ayant servi au dimensionnement initial. Il est utile d'enregistrer le type de données réellement chargé, les pics de mémoire GPU allouée et réservée, le statut gelé de la base, la configuration LoRA et les versions exactes de Soup, Torch, Transformers, TRL et PEFT.
La bonne question n'est pas seulement de savoir si la version 0.74.0 consomme moins de mémoire. Il faut vérifier si la consommation observée correspond désormais assez bien aux hypothèses de capacité pour rendre crédibles le choix d'instance et l'estimation des coûts.
Cette version montre qu'un entraînement efficace peut perdre son avantage en dessous du niveau algorithmique. LoRA peut être économe en paramètres, mais un défaut de chargement peut matérialiser inutilement des poids gelés dans une précision coûteuse. Corriger cette frontière peut avoir autant d'effet sur l'économie d'un entraînement que le choix de la méthode elle-même.