Fireworks AI rend l’API d’entraînement généralement disponible

Fireworks AI, le 31 août 2026, a annoncé la disponibilité générale de son API d’entraînement et de Fireworks Lab, ouvrant son infrastructure gérée d’entraînement et de déploiement aux équipes ML souhaitant exécuter des boucles d’entraînement personnalisées sur des modèles ouverts. L’API d’entraînement connecte la boucle d’entraînement Python d’un client à l’infrastructure de calcul distribué gérée par Fireworks, couvrant à la fois l’entraîneur qui calcule les gradients et met à jour le modèle et le déploiement de génération qui produit des échantillons à partir de celui-ci.

Selon l’arrangement décrit dans l’annonce, le client orchestre la boucle depuis l’endroit de son choix, conservant le contrôle sur la fonction de perte ou de récompense, les données et l’environnement. Fireworks gère l’interaction entre l’entraîneur et le déploiement, y compris la synchronisation des poids, la récupération en cas d’échec d’échange et l’alignement entraînement‑déploiement. L’entreprise présente l’API comme une réponse aux contraintes que, selon elle, les équipes ML ont signalées dans les flux de travail d’entraînement existants : choix limité de modèles et de méthodes, contrôle restreint des paramètres et des boucles d’entraînement, calcul rigide et infrastructure fragmentée d’entraînement et de déploiement.

Calcul sans serveur et dédié

L’API d’entraînement propose deux options de calcul. L’entraînement sans serveur permet aux clients de former des adaptateurs LoRA sur une infrastructure partagée avec facturation au token, le prélèvement s’exécutant dans la même session ; Fireworks le décrit comme adapté à l’itération d’expériences, à la réduction des risques pour les exécutions plus importantes, ou à l’exécution de boucles d’apprentissage par renforcement alternant entre déploiement et entraînement. L’entraînement dédié vise l’entraînement à paramètres complets, les modèles au‑delà du pool sans serveur, des longueurs de contexte ou des rangs LoRA plus grands, et un débit soutenu, facturé à l’heure GPU sur une capacité élastique dimensionnée pour chaque exécution.

Le niveau sans serveur se connecte à un pool partagé toujours actif avec une liste sélectionnée de modèles populaires, une capacité partagée et des limites de débit par compte. Le niveau dédié provisionne un entraîneur et un déploiement par exécution, prend en charge les modes LoRA et à paramètres complets jusqu’aux plus grands modèles à mélange d’experts, et ne comporte aucune contention ni limite de débit. Les points de contrôle prometteurs peuvent être déployés en inférence de production via l’interface ou l’API, et le déploiement multi‑LoRA offre à chaque client ou cas d’usage son propre modèle ajusté sans infrastructure séparée, indique l’entreprise.

Trois surfaces d’entraînement

L’API d’entraînement coexiste avec deux autres surfaces sur la plateforme d’entraînement Fireworks. L’entraînement géré, destiné aux ingénieurs ML, exécute des tâches intégrées dans lesquelles le client choisit une méthode — SFT, DPO ou RL — et un modèle de base, en lançant depuis l’interface ou l’API. Fireworks Lab, également généralement disponible depuis l’annonce, intègre des chercheurs et ingénieurs déployés en avant‑première au sein des équipes clientes ; les engagements débutent par un diagnostic définissant la capacité, la ligne de base, les critères de succès et le périmètre, puis passent à une implémentation à durée limitée, et le client conserve le modèle prêt pour la production, le cadre d’évaluation, les pipelines de données, la boucle d’entraînement et les recettes.

L’API d’entraînement elle‑même s’adresse aux chercheurs ML et prend en charge SFT, DPO, ORPO, RL et la distillation, du LoRA sur calcul sans serveur à l’entraînement à paramètres complets sur des clusters dédiés.

Apprentissage par renforcement à grande échelle

Fireworks affirme être parmi les rares organisations hors des laboratoires de pointe à avoir exploité l’apprentissage par renforcement sur plus de 10 000 GPU, et elle structure l’entraînement RL autour de trois exigences : la justesse, l’efficacité des performances et la rapidité de développement.

En ce qui concerne la justesse, l’entreprise a indiqué que le moteur de déploiement et l’entraîneur doivent partager la même définition numérique, car une petite dérive numérique peut corrompre le signal d’apprentissage via le découpage de tokens ou l’effondrement de la récompense alors que tout semble fonctionner. Fireworks aligne les formats numériques de bout en bout, y compris BF16, FP8 par blocs et NVFP4, aligne les noyaux et le comportement de réduction sur les deux chemins, et utilise Router Replay pour préserver les décisions de routage du mélange d’experts entre le déploiement et la passe arrière, en parallèle avec des noyaux invariants par lot et des réductions déterministes. L’entreprise affirme valider cet alignement en exécutant des séquences identiques à travers le moteur de déploiement et l’entraîneur et en mesurant la divergence KL entraînement‑inférence, avec une validation continue pour tous les modèles lancés sur Fireworks training.

En matière de performances, Fireworks indique qu’elle exécute un RL asynchrone, superposant la collecte de déploiement à l’entraînement de sorte que les GPU de déploiement commencent à générer le lot suivant pendant que l’entraîneur met à jour le lot précédent, avec une obsolescence des poids bornée lorsque l’algorithme le permet. Après chaque étape d’entraînement, les poids mis à jour sont chargés à chaud dans le déploiement de déploiement en cours plutôt que d’être arrêtés et de recharger un modèle complet. Pour les points de contrôle à paramètres complets, l’entreprise déclare calculer une différence XOR entre les poids actuels et précédents et appliquer une compression zstd, produisant jusqu’à une réduction de 10 fois de la bande passante de transmission.

Concernant la rapidité de développement, l’entreprise décrit une boucle continue d’entraînement, déploiement, évaluation et réentraînement sur une même plateforme, les points de contrôle étant directement transférés vers le service et les traces de production, les évaluations et les retours alimentant l’exécution suivante. Elle indique que les équipes signalent deux à quatre fois plus d’itérations pour le même budget d’entraînement.

Résultats clients cités

L’annonce a cité plusieurs clients. Harvey a post‑entraîné Kimi K3 pour des travaux juridiques à long terme en utilisant du RL asynchrone ; son modèle Harvey Tenet a obtenu un taux de réussite de 19,7 % sur LAB contre 11,5 % pour Claude Fable 5, à environ un tiers du coût par tâche, selon Fireworks. Vercel a utilisé le réglage fin par renforcement et le décodage spéculatif pour l’auto‑correcteur de la version 0, atteignant un taux de génération sans erreur de 93 % et une amélioration de la latence de bout en bout de 40 fois, d’après l’entreprise. Heidi Health a transféré son scribe clinique sur des modèles ouverts ajustés, passant du proof of concept à la production en quatre semaines avec une latence 3,5 fois plus faible. Factory a ajusté finement deux petits adaptateurs LoRA sur une base Qwen ouverte pour filtrer les secrets exposés ; avec un budget de fausses alertes de 5 %, le modèle entraîné a détecté environ 70 % des vrais secrets contre environ 59 % pour GPT‑5.5, a rapporté Fireworks.

L’API d’entraînement est dès à présent disponible via l’inscription en libre‑service de Fireworks, l’accès sans serveur ne nécessitant aucune provision, et l’entreprise oriente les équipes souhaitant un accompagnement pratique vers des consultations Fireworks Lab.