Baseten rend Serverless Loops généralement disponible pour le post-entraînement

Le 6 novembre 2026, Baseten a annoncé que Serverless Loops est désormais disponible, ouvrant à tous l’accès à son SDK géré pour le réglage fin supervisé et l’apprentissage par renforcement sur des modèles ouverts. Le service facture l’entraînement au jeton et offre un chemin direct des points de contrôle à Baseten Dedicated Inference.

Loops repose sur une répartition des tâches : les utilisateurs fournissent le signal d’entraînement, tandis que Baseten gère les GPU, les noyaux, les architectures de modèles et le système dorsal d’entraînement distribué. Le SDK Python entraîne des adaptateurs LoRA en gardant gelés les poids du modèle de base. Les utilisateurs choisissent le modèle de base, le rang LoRA, le taux d’apprentissage, la fonction de perte, les données ou l’environnement et l’algorithme ; Baseten exécute l’entraîneur et l’échantillonneur, synchronise les poids et gère l’infrastructure nécessaire.

Un module de compatibilité conserve les instructions d’importation Tinker ainsi que les principaux appels d’entraînement et d’échantillonnage pour les équipes qui migrent leurs scripts existants. Le guide de migration précise néanmoins que l’authentification doit utiliser une clé API Baseten, que les points de contrôle sont renvoyés sous forme d’URL de fichiers paginées, que les images doivent être fournies en ligne et que la couverture des modules LoRA est définie selon la famille de modèles. La compatibilité couvre l’API d’entraînement, mais laisse aux équipes le soin d’adapter plusieurs détails propres à l’infrastructure.

Modèles sans serveur et facturation

Le catalogue sans serveur comprend trois modèles : Qwen/Qwen3.6-35B-A3B et zai-org/GLM-5.3-Flash pour le texte et la vision, et zai-org/GLM-5.3 pour le texte uniquement. Chacun prend en charge une longueur de séquence maximale de 262 144 jetons. La configuration à long contexte de GLM-5.3 ne prend pas en charge cross_entropy ni dpo les fonctions de perte. Le mode dédié donne accès à un catalogue de modèles plus vaste, facture le temps d’utilisation des GPU et ajoute des options de contrôle pour les réplicas, la réutilisation à chaud et la capacité spot.

Les exécutions sans serveur utilisent une capacité partagée sans réservation de GPU et facturent les jetons utilisés pour l’entraînement et l’échantillonnage. Le temps consacré à consulter les résultats, à modifier une fonction de récompense ou à attendre sans rien faire n’entraîne aucuns frais de jetons. La sélection du mode par défaut peut basculer vers une capacité dédiée si le modèle, le rang LoRA ou la longueur de séquence n’est pas pris en charge, ou si une exécution réutilise les déploiements d’une autre exécution. En définissant la portée sur « sans serveur », une requête non prise en charge échoue plutôt.

L’activation d’un modèle ne garantit pas son approvisionnement. Des restrictions d’accès propres à l’espace de travail, l’indisponibilité des GPU et les limites imposées par l’organisation aux entraîneurs peuvent encore empêcher une exécution, ce qui fixe des limites pratiques de capacité au modèle de facturation au jeton, au-delà du catalogue publié.

Points de contrôle et inférence en production

Le guide de démarrage rapide présente quatre opérations essentielles : forward_backward pour le calcul des pertes et des gradients, optim_step pour mettre à jour les adaptateurs, sample pour la génération et save_state pour reprendre un entraînement. La publication des poids de l’échantillonneur crée un point de contrôle déployable et un client d’échantillonnage associé à celui-ci. Une opération distincte save_state préserve l’état du modèle et de l’optimiseur. La première requête d’échantillonnage peut prendre plusieurs minutes, le temps que la capacité sans serveur démarre ; il s’agit d’un élément à prendre en compte pour les expériences courtes.

Un point de contrôle de l’échantillonneur se déploie sous la forme du modèle de base avec l’adaptateur LoRA entraîné chargé. Les points de contrôle subsistent après la fin de leurs exécutions et peuvent être déployés au moyen de l’interface en ligne de commande, de l’API REST ou du tableau de bord à l’aide d’un jeton d’accès Hugging Face, car le déploiement télécharge les poids de base. Le point de terminaison compatible avec OpenAI qui en résulte facture l’utilisation de son GPU tant qu’il est actif. La suppression de ce déploiement met fin aux frais liés au GPU sans supprimer le point de contrôle ; la désactivation de l’exécution Loops ne supprime pas le déploiement.

Pour le lancement de la disponibilité générale, Baseten a amélioré la gestion des erreurs réseau temporaires et des pannes de GPU, réduit la surcharge au démarrage et accéléré les transferts de poids entre les entraîneurs et les échantillonneurs. Selon Baseten, ces changements permettent de prendre en charge davantage de charges de travail client simultanées et sa pile d’inférence en production traite plus de 15 milliards de requêtes par jour. Le parcours de production comprend la mise à l’échelle automatique, la gestion des déploiements et des métriques d’inférence ; les utilisateurs peuvent également télécharger les poids au format Safetensors de Hugging Face.

Validation et premiers cas d’utilisation chez les clients

Baseten indique avoir validé le service à l’aide de tests numériques et d’expériences d’apprentissage par renforcement de bout en bout utilisant des tâches τ-bench dans les domaines de la vente au détail, du transport aérien et des services bancaires, puis en les évaluant sur des tâches difficiles mises de côté. Le projet τ-bench décrit un banc d’essai visant à déterminer si des agents peuvent dialoguer avec des utilisateurs, appeler des outils, récupérer des connaissances et respecter des politiques dans différents secteurs d’entreprise, les résultats étant vérifiés par rapport à des données de base de données vérifiables.

Baseten indique que NVIDIA a procédé au post-entraînement de Nemotron Super 3.5 VL sur des tâches textuelles et visuelles, faisant passer la précision de la classification des intentions de 76,8 % à 94 % et atteignant un score F1 de validation de 87 % pour l’extraction de reçus ; ces travaux comprenaient également de l’apprentissage par renforcement pour le dénombrement d’objets visuels. Datadog utilise l’apprentissage par renforcement agentique en plusieurs tours pour tester des idées d’entraînement destinées à son agent SRE, tandis qu’Ambience Healthcare a procédé au post-entraînement de modèles afin de corriger les erreurs de transcription clinique et de restituer avec précision la terminologie médicale et la mise en forme.

LangChain Labs entraîne des modèles après leur préentraînement à partir de traces d’agents pour LangSmith Engine, notamment en leur faisant lire un dépôt GitHub afin de diagnostiquer un problème et rédiger la consigne ou la modification de code à proposer dans une demande de fusion. Il peut basculer vers un modèle plus petit à poids ouverts pour classer les traces selon le mode et la gravité de la défaillance, ou les associer à des problèmes existants. Le processus de LangChain montre comment le comportement d’une application devient la cible de l’entraînement, la taille du modèle et sa spécialisation étant choisies en fonction de la tâche.

Les comptes clients font état d’une utilisation avant l’annonce de la disponibilité générale et illustrent le cycle d’infrastructure prévu : les données de l’application deviennent des données d’entraînement, les points de contrôle sont évalués, puis les modèles sélectionnés sont acheminés vers la production. Pour les équipes d’infrastructure, la limite de coûts est tout aussi claire. Les exécutions sans serveur prises en charge évitent les réservations de GPU et la facturation des jetons pendant les périodes d’inactivité, tandis qu’un point de terminaison d’inférence actif continue d’entraîner des frais pour son GPU ; le catalogue sans serveur et la capacité de l’espace de travail déterminent où l’option sans serveur peut s’appliquer.