Les poids ouverts de StepFun Step 5 Preview déplacent la compétition des modèles d’agents vers le déploiement

StepFun a publié les poids ouverts de Step 5 Preview dans deux formats principaux le 15 octobre, transformant un aperçu via API en un modèle que les développeurs peuvent examiner et déployer. L’entreprise a mis en ligne des checkpoints BF16 et FP8 sur Hugging Face et ModelScope, accompagnés de code et d’un blog technique détaillé.

Cette initiative est importante car Step 5 Preview n’est pas conçu comme un modèle local léger. Il contient environ 600 milliards de paramètres au total, en active 27 milliards par token et prend en charge une fenêtre de contexte pouvant atteindre un million de tokens. Son exécution à pleine échelle exige du matériel de centre de données, une inférence distribuée et une gestion rigoureuse de la mémoire.

Cette publication crée donc une tension intéressante. StepFun a rendu les poids du modèle accessibles, mais le contrôle pratique reste limité par l’infrastructure. La véritable compétition ne se résume pas aux poids ouverts face aux API fermées. Elle consiste à déterminer si les équipes peuvent transformer des poids inspectables en agents fiables et abordables, capables d’accomplir de longues tâches.

Cela met la pression sur d’autres développeurs de modèles à poids ouverts en concurrence sur les mêmes charges de travail agentiques, notamment DeepSeek, Qwen et Kimi. Cela offre également aux équipes d’infrastructure un nouveau test exigeant pour vLLM, SGLang, la quantification, la gestion du contexte et le service multi-nœuds.

Les poids ouverts de StepFun Step 5 Preview sont désormais déployables

La publication d’octobre fait passer Step 5 Preview d’une promesse hébergée à un modèle que des équipes qualifiées peuvent exécuter sous leur propre contrôle.

StepFun a d’abord présenté le modèle comme un système phare pour le travail agentique. L’entreprise avait promis une publication en poids ouverts après la disponibilité initiale de l’API. Le 15 octobre, elle a tenu cet engagement avec des fichiers de modèle et des instructions de déploiement.

Le checkpoint FP8 officiel vise à réduire la charge mémoire nécessaire au service d’un modèle de cette taille. FP8 stocke de nombreuses valeurs du modèle avec une précision en virgule flottante sur huit bits, réduisant l’usage mémoire par rapport à BF16 tout en conservant une plage numérique plus large que la quantification entière.

StepFun a également publié un checkpoint BF16 distinct. BF16 utilise des valeurs en virgule flottante sur 16 bits et offre généralement une référence plus prudente pour l’évaluation, l’adaptation et la comparaison numérique.

Ces fichiers sont également disponibles via la publication ModelScope, offrant aux développeurs une autre voie de distribution. C’est particulièrement important pour les équipes dont l’infrastructure ou les flux de téléchargement dépendent déjà de ModelScope.

La différence entre les deux checkpoints est opérationnelle, et non cosmétique. StepFun avertit que l’activation d’une option d’exécution BF16 ne transforme pas les poids FP8 en BF16. Les équipes doivent télécharger le checkpoint correspondant à la précision qu’elles souhaitent servir.

La fiche du modèle présente des voies de déploiement pour vLLM, SGLang et une implémentation Transformers autonome. vLLM comme SGLang peuvent exposer le modèle via une interface compatible OpenAI. Les applications existantes peuvent donc s’y connecter sans adopter un format de requête entièrement nouveau.

Le déploiement exige toujours une ingénierie conséquente. La configuration de référence de StepFun répartit le checkpoint FP8 sur quatre GPU Nvidia B300 ou huit GPU H200. La configuration BF16 utilise huit GPU B300 ou deux nœuds comprenant 16 GPU H200.

Ces exemples décrivent des configurations de départ, et non une capacité garantie pour chaque charge de travail. Une requête d’un million de tokens requiert également de la mémoire pour le cache clé-valeur, les tampons d’exécution et les séquences simultanées. Les poids ne représentent qu’une partie de l’empreinte du système.

La documentation BF16 comporte une autre réserve importante. StepFun indique que son processus complet de conversion BF16 fragmentée en fichiers et de génération n’a pas fait l’objet d’une validation intégrale de bout en bout. L’entreprise a validé les formes des checkpoints, des tests de conversion plus réduits et l’inférence à poids diffusés sur le modèle complet.

Cette précision renforce la crédibilité de la publication, plutôt qu’elle ne la diminue. Le déploiement ouvert expose les outils incomplets et les limites de mise à l’échelle qu’une API gérée peut masquer. Il permet aussi à des ingénieurs externes de reproduire les défaillances et de proposer des correctifs.

La publication est donc significative sans être sans friction. Les développeurs disposent désormais des artefacts du modèle, d’exemples de service et d’une explication architecturale. Ils doivent encore bâtir un environnement d’exploitation capable de les utiliser.

Pourquoi StepFun a conçu un modèle d’agent plus étroit et plus profond

Le pari central de StepFun est qu’un calcul interne profond importe davantage que le simple nombre de paramètres actifs lors de longues sessions agentiques riches en outils.

Step 5 Preview utilise une architecture sparse mixture-of-experts. Dans cette conception, le réseau contient de nombreux groupes de paramètres spécialisés, mais un routeur n’en active qu’un sous-ensemble pour chaque token.

Le modèle compte environ 600 milliards de paramètres au total et 27 milliards de paramètres actifs par token. L’activation creuse vise à préserver une large capacité sans appliquer l’ensemble du réseau à chaque étape. Elle n’élimine pas la charge de stockage ou de communication liée au maintien du modèle complet.

StepFun décrit le modèle comme « étroit mais profond ». Il contient 92 blocs transformer, plaçant davantage d’étapes de traitement séquentiel entre l’entrée et la sortie. L’entreprise estime que la profondeur favorise un raisonnement latent en plusieurs étapes lors du traitement de longs prompts.

Cette conception cible une caractéristique délicate des agents logiciels. Un agent de programmation lit à répétition des fichiers, reçoit des résultats d’outils, modifie du code, exécute des tests et met à jour son plan. Une grande partie de son raisonnement doit se produire pendant le traitement du contexte accumulé, et pas seulement via du texte de raisonnement visible.

Un réseau plus profond offre aux représentations davantage de couches pour se développer. Toutefois, la profondeur rend aussi l’optimisation plus difficile. StepFun rapporte des explosions numériques et des pics de gradient apparus lors de la mise à l’échelle du modèle.

L’architecture technique de l’entreprise décrit trois réponses. Elle a conservé les états cachés et leurs gradients en FP32, stocké les échelles de normalisation en FP32 et introduit un écrêtage fin des gradients.

Selon StepFun, les états cachés en FP32 ont réduit les pics d’activation extrêmes de près d’un ordre de grandeur. L’entreprise indique que ce changement n’a ajouté qu’une surcharge d’entraînement marginale par rapport à une gestion BF16 conventionnelle.

Le changement de normalisation traitait les valeurs proches de moins un, où la précision BF16 peut devenir insuffisante. StepFun a constaté que certains canaux alternaient entre une suppression totale et une réouverture, produisant un comportement de sortie instable.

Son écrêtage des gradients ne ciblait que 0,00004 % des valeurs de gradient par couche. StepFun indique que ces rares valeurs pouvaient s’amplifier au travers des couches intermédiaires et créer des pics. Leur limitation aurait produit une convergence plus régulière.

Il s’agit d’observations d’entraînement rapportées par l’entreprise, et non de réplications indépendantes. Leur inclusion rend néanmoins le blog plus utile qu’une annonce de benchmarks. Les chercheurs peuvent comparer ces techniques au comportement observé dans d’autres modèles profonds.

La conception de l’attention constitue l’autre moitié de l’argument architectural. Step 5 Preview alterne trois couches d’attention efficaces avec une couche d’attention complète creuse. Les couches efficaces utilisent une attention à fenêtre glissante contrôlée, qui limite la région récente examinée par chaque token.

Le chemin d’attention complète utilise ce que StepFun appelle Sparse GQA. L’attention à requêtes groupées, ou GQA, permet à plusieurs têtes de requête de partager des représentations de clé et de valeur. StepFun y ajoute un mécanisme de sélection qui récupère les blocs historiques pertinents au lieu de lire la séquence complète.

Son indexeur fusionne les tokens en blocs de huit. Le modèle sélectionne un budget de 4 096 tokens, correspondant à 512 blocs. StepFun affirme que la fusion des blocs réduit d’un facteur huit les coûts d’indexation et de sélection supérieure.

Ce mécanisme répond à un problème concret. L’attention complète standard devient de plus en plus coûteuse à mesure qu’une séquence grandit, car les tokens se comparent à un historique en expansion. Ce coût devient difficile à gérer à un million de tokens.

La sélection creuse réduit l’historique examiné lors de chaque opération. Toutefois, tout sélecteur peut manquer des informations qui s’avèrent ensuite importantes. StepFun rapporte une couverture de tokens de 78,06 % pour sa configuration sélectionnée, contre 79,09 % pour une configuration de référence plus fine.

Cette faible différence rapportée soutient la conception, mais ne tranche pas la question de la qualité applicative. La structure d’un dépôt, les sorties d’outils bruitées et des détails séparés par des centaines de milliers de tokens peuvent révéler d’autres échecs de récupération.

L’architecture se comprend mieux comme un mécanisme d’efficacité assorti d’un compromis. Elle rend les contextes extrêmes plus réalisables, tout en créant un composant supplémentaire dont les décisions exigent des tests.

Les poids ouverts se heurtent au coût d’une véritable infrastructure d’agents

StepFun réduit la barrière à l’inspection et à la modification du modèle, mais les exigences matérielles maintiennent l’auto-hébergement courant hors de portée de la plupart des développeurs individuels.

Les poids ouverts offrent des capacités qu’une API ne fournit pas. Une équipe peut inspecter les fichiers de configuration, contrôler les journaux de service, choisir où les prompts sont traités et tester le comportement du modèle sans envoyer de données propriétaires à l’extérieur.

Les chercheurs peuvent évaluer le même checkpoint avec différents paramètres de décodage. Les ingénieurs d’infrastructure peuvent modifier les noyaux, expérimenter le parallélisme ou créer de nouvelles quantifications. Les organisations réglementées peuvent placer l’inférence dans un environnement contrôlé.

Ces avantages comptent pour les systèmes agentiques, car les agents touchent à des données sensibles. Un agent de programmation peut lire des dépôts privés et des configurations de déploiement. Un agent métier peut traiter des contrats, des rapports internes, des dossiers clients et des modèles financiers.

L’auto-hébergement offre un contrôle opérationnel plus fort sur ces flux de travail. Il ne les rend pas automatiquement sûrs. Les organisations ont toujours besoin de règles d’accès, de pistes d’audit, de restrictions sur les outils, de défenses contre l’injection de prompts et d’une surveillance des actions non intentionnelles.

La première contrainte est la mémoire. Le chemin de référence de StepFun répartit l’inférence FP8 sur quatre GPU B300 ou huit GPU H200. BF16 étend cette exigence à huit GPU B300 ou 16 GPU H200 répartis sur deux nœuds.

Le parallélisme tensoriel divise les calculs du modèle entre les appareils. Le parallélisme d’experts distribue les composants mixture-of-experts. Le parallélisme des données peut prendre en charge un débit supplémentaire de requêtes, bien qu’il duplique ou redistribue différentes parties de la charge de service.

Chaque approche introduit des coûts de communication. Les performances dépendent de la bande passante d’interconnexion, des opérations collectives, de la prise en charge des noyaux, du traitement par lots et du schéma exact des experts activés. Une commande de lancement fonctionnelle ne garantit pas un service de production efficace.

La fenêtre de contexte crée une autre contrainte. StepFun indique une limite combinée d’entrée et de sortie de 1 048 576 tokens dans ses exemples de service. La longueur réellement utilisable dépend de la mémoire réservée au cache clé-valeur.

Un cache clé-valeur stocke les informations d’attention des tokens précédents afin que le modèle ne recalcule pas toute la séquence pour chaque nouveau token. À des longueurs extrêmes, ce cache devient un consommateur majeur de mémoire.

Les équipes doivent arbitrer entre longueur de contexte, concurrence, latence et capacité de sortie. Servir une session exceptionnellement longue peut évincer de nombreuses requêtes plus petites. Une concurrence plus élevée peut imposer une séquence maximale plus courte ou une compression plus agressive du cache.

StepFun indique qu’une tête de prédiction MTP-3 apporte environ 30 % d’amélioration de vitesse de bout en bout. La prédiction multi-token, ou MTP, permet au système de proposer plusieurs tokens futurs probables et de les vérifier ensemble.

L’entreprise fait également état d’un gain supplémentaire d’environ 20 % grâce à l’exécution native de modèles mixture-of-experts en FP8, tout en atteignant une qualité comparable au BF16. Ces affirmations doivent être reproduites par des tiers sur différents matériels, prompts, niveaux de concurrence et frameworks d’agents.

StepFun affirme en outre que le parallélisme coordonné des experts, le déport du cache vers le CPU, le stockage compressé des poids et l’entraînement du cache en FP8 multiplient par huit à douze la capacité effective du cache. Cette fourchette reflète une pile système complète, et non un simple réglage du modèle.

L’adversaire concret n’est donc pas une entreprise rivale isolée. C’est l’écart entre la disponibilité des poids et une infrastructure d’agents réellement déployable. StepFun a ouvert la première couche, tout en laissant les acheteurs résoudre la seconde.

Cet écart laisse aux fournisseurs de services managés une marge de concurrence. Les API fermées offrent un accès immédiat, une intégration prévisible et des opérations externalisées. Les systèmes à poids ouverts offrent contrôle, personnalisation et traitement local des données, mais exigent davantage de capital et d’efforts d’ingénierie.

Les grandes entreprises et les fournisseurs d’inférence sont les candidats les plus probables à l’auto-hébergement précoce. Les petites équipes peuvent encore utiliser des endpoints hébergés tout en étudiant la fiche du modèle et en attendant des variantes communautaires compressées.

La publication donne aussi aux développeurs un cadre d’approvisionnement plus précis. Ils peuvent dissocier la qualité du modèle de l’économie du serving, puis mesurer les deux face à leurs charges de travail. Un score élevé sur un benchmark ne peut compenser une latence ou un coût d’infrastructure inacceptables.

Les affirmations de benchmark nécessitent encore des tests indépendants

La publication de Step 5 Preview permet une évaluation sérieuse, mais des benchmarks sélectionnés par l’entreprise ne peuvent, à eux seuls, établir sa fiabilité en production.

StepFun positionne le modèle autour de l’ingénierie logicielle, de l’exécution sur longue durée, du travail intellectuel professionnel et de la finance. Ces catégories correspondent à des charges de travail d’agents à forte valeur, où une tâche achevée peut compter davantage que l’aisance conversationnelle.

L’entreprise affirme que Step 5 Preview obtient de solides résultats en génération de code, correction de bugs, refactorisation, documentation et optimisation des performances. Sa présentation du modèle propose également des exemples de longue durée destinés à illustrer un comportement d’agent soutenu.

Les checkpoints ouverts rendent ces affirmations vérifiables. Des groupes indépendants peuvent exécuter des bancs de test fixes, conserver les transcriptions, comparer les paramètres de décodage et publier les cas d’échec. Ce processus est plus instructif que la comparaison de captures d’écran d’interfaces de chat managées.

La reproductibilité des benchmarks peut toutefois rester difficile. Les scores des agents dépendent de l’échafaudage qui entoure le modèle, notamment des outils disponibles, des modèles de prompts, des politiques de nouvelle tentative, des limites de temps et de la compression du contexte.

Un modèle peut aussi bénéficier de données spécifiques au benchmark ou de faiblesses de l’évaluateur. StepFun évoque ouvertement le model hacking, où des agents exploitent les spécifications d’une tâche sans résoudre le problème visé. Son pipeline de données inclurait des contrôles anti-hacking.

Cette reconnaissance identifie le bon problème, mais ne démontre pas que ces contrôles sont suffisants. Les évaluateurs externes devraient examiner si les exécutions réussies produisent des résultats corrects et maintenables, plutôt que de simplement réussir des tests étroits.

L’évaluation sur longue durée soulève des questions supplémentaires. Un agent peut achever une tâche isolée dans un dépôt, puis dériver au cours d’un travail s’étalant sur plusieurs heures. Il peut répéter des actions, écraser des modifications correctes, mal interpréter les résultats d’outils ou perdre des hypothèses après compression du contexte.

Le système d’apprentissage par renforcement de StepFun se concentre sur la durée, la profondeur et le pouvoir discriminant. La durée mesure le travail soutenu, tandis que la profondeur couvre les changements d’état accumulés. Le pouvoir discriminant mesure si une tâche distingue les rollouts réussis des rollouts échoués.

L’entreprise indique avoir créé plus d’un million d’environnements exigeants et vérifiables dans l’ingénierie logicielle, le raisonnement scientifique, la recherche en machine learning et le travail professionnel. Ce chiffre décrit des environnements construits, et non des déploiements de production uniques.

StepFun indique également un taux de perte d’échantillons de bout en bout inférieur à 1 %. La perte d’échantillons importe, car les défaillances d’infrastructure éliminent souvent les trajectoires les plus longues et les plus difficiles, biaisant silencieusement l’entraînement vers des tâches plus simples.

Ces détails suggèrent que StepFun a traité l’entraînement des agents comme un problème de systèmes. Pourtant, les éléments de preuve proviennent toujours du développeur du modèle. Des équipes indépendantes devraient reproduire les résultats avec le matériel déclaré, les versions de frameworks et les budgets d’évaluation indiqués.

La licence mérite une attention similaire. Hugging Face qualifie la licence du dépôt d’« other », tandis que StepFun présente sa Model License 1.0 comme étant dans l’esprit d’Apache-2.0. La licence ajoute des exigences d’attribution et des conditions commerciales propres à l’utilisation, la modification et la distribution du modèle.

Cela fait de « open weights » la description exacte. Cela ne signifie pas que chaque utilisation bénéficie des mêmes autorisations sans restriction associées à une licence logicielle open source standard.

Les organisations devraient lire la licence complète avant de distribuer des dérivés, de proposer des services commerciaux ou d’intégrer le modèle dans des produits destinés aux clients. L’accès aux poids et l’autorisation juridique sont liés, mais ils ne sont pas identiques.

Les tests de sécurité sont tout aussi importants. Un agent opérant sur longue durée peut accéder à davantage de fichiers, effectuer davantage d’appels d’outils et accumuler davantage d’occasions d’erreur. Une persistance accrue augmente à la fois l’utilité et l’impact potentiel d’une mauvaise décision.

Le modèle devrait donc être évalué par étapes. Les équipes peuvent commencer par des tâches en lecture seule, des dépôts contrôlés et des données synthétiques. Elles peuvent ensuite mesurer les violations d’autorisations, le comportement de récupération, le mauvais usage des outils et les modifications introduites sans preuve.

Les développeurs devraient également comparer les résultats en FP8 et en BF16. StepFun affirme que le FP8 natif égale la qualité du BF16, mais de petites différences peuvent se cumuler au fil de longues trajectoires. Un seul choix d’outil modifié peut rediriger chaque étape ultérieure.

La publication ouverte rend ces expériences possibles. Elle ne rend pas les réponses favorables par défaut.

Les trois prochains signaux définiront l’impact de Step 5 Preview

La publication ne deviendra déterminante que si des résultats indépendants, une prise en charge plus large du serving et une adoption durable dans le monde réel suivent les poids.

Le premier signal est une évaluation reproductible des agents. Des chercheurs indépendants devraient tester Step 5 Preview sur le codage, l’analyse de documents, la finance et la récupération dans des contextes longs, avec des journaux d’exécution complets.

Les comparaisons les plus utiles maintiendront l’échafaudage de l’agent constant. Les modèles devraient recevoir des outils, budgets, prompts et limites de nouvelle tentative identiques. Les évaluateurs devraient divulguer le matériel, la précision, les versions de frameworks et les paramètres de contexte.

De solides résultats indépendants conforteraient l’affirmation centrale de StepFun selon laquelle une architecture étroite et profonde favorise le travail sur longue durée. De fortes baisses en dehors de la configuration de l’entreprise affaibliraient cet argument et déplaceraient l’attention vers les avantages de l’échafaudage.

Le deuxième signal est la maturité de l’infrastructure. StepFun fournit déjà des voies de lancement pour vLLM, SGLang et Transformers autonome. Le prochain test sera de savoir si ces voies deviennent plus simples, plus rapides et plus portables.

Les équipes devraient surveiller la disponibilité d’un support upstream stable, de configurations GPU supplémentaires, de kernels optimisés et de quantifications maintenues de manière indépendante. Elles devraient également vérifier si le flux de travail BF16 réparti en fragments de fichiers reçoit une validation complète.

Une pile de déploiement mature réduirait la distance entre des poids téléchargeables et un service utilisable. Des échecs persistants de configuration laisseraient le modèle concentré entre les mains d’un petit nombre d’opérateurs spécialisés.

Le troisième signal est l’adoption dans des produits d’agents réels. Les étoiles de dépôts et les téléchargements de modèles peuvent signaler de la curiosité, mais ils ne montrent pas si les utilisateurs font confiance au modèle pour un travail conséquent.

Une adoption significative se manifesterait par des intégrations en production, une utilisation répétée, des études de cas publiques et des taux mesurables d’achèvement des tâches. Elle générerait également des rapports détaillés sur la latence, la récupération après échec et l’utilisation de l’infrastructure.

C’est là que les concurrents subissent la pression la plus nette. DeepSeek, Qwen, Kimi et d’autres développeurs de modèles à poids ouverts se disputent les développeurs qui veulent du contrôle sans sacrifier des performances d’agents de niveau frontière.

La publication de StepFun donne à ce public une autre architecture sérieuse à évaluer. Elle relève également les attentes en matière de transparence technique. Un checkpoint paraît désormais incomplet sans instructions de serving, variantes de précision, détails d’architecture et conseils d’évaluation reproductible.

Les fournisseurs de modèles fermés font face à un test différent. Ils peuvent toujours se distinguer par leur fiabilité, leurs systèmes de sécurité, l’intégration à leur écosystème et leur infrastructure managée. Ils doivent justifier pourquoi la commodité des API l’emporte sur le contrôle et l’inspectabilité offerts par les poids ouverts.

Pour les développeurs, l’action immédiate consiste à effectuer des tests rigoureux plutôt qu’une migration généralisée. Sélectionnez une tâche représentative, conservez son contexte de travail complet, puis comparez le taux de réussite, la latence et la fréquence des interventions.

Les longues évaluations d’agents produisent de vastes collections de journaux, de décisions et de sources. Une base de connaissances IA consultable peut aider les équipes à conserver ces éléments plutôt que de réduire les résultats à un unique score final.

La publication des poids ouverts de StepFun Step 5 Preview constitue donc un point de départ. Les fichiers tranchent la question de savoir si l’entreprise fournirait l’accès. Ils ne tranchent pas celle de savoir si l’architecture l’emporte dans des conditions indépendantes.

Dans les mois à venir, observez qui peut reproduire les résultats, qui peut exploiter le modèle efficacement et qui continue de l’utiliser après les premiers tests. Ces signaux révéleront si Step 5 Preview devient une infrastructure ou reste un checkpoint impressionnant.