llm-foundry : la chaîne d'entraînement de Databricks, du script data_prep au déploiement ONNX
LLM training code for Databricks foundation models
En bref
- De quoi s’agit-il ?
- llm-foundry est le dépôt qui contient le code d'entraînement, de finetuning, d'évaluation et de conversion des modèles MPT et DBRX. Il est bâti sur Composer et suppose une plateforme de calcul distribué pour tenir sa promesse de montée en charge.
- À qui s’adresse-t-il ?
- llm-foundry convient aux équipes qui entraînent ou affinent des modèles de 125M à 70B paramètres sur plusieurs GPU et qui veulent un pipeline reproductible, du formatage des données jusqu'à la conversion ONNX. Il ne convient pas à qui cherche une bibliothèque légère pour faire tourner un modèle sur une seule machine : les scripts d'inférence ne sont pas le cœur du dépôt, et la documentation renvoie à Composer et à la plateforme MosaicML pour l'orchestration.
- Puis-je l’utiliser commercialement ?
- Oui. Apache-2.0 est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 174 jours.
- En quel langage est-il écrit ?
- Principalement Python, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Ce que le dépôt couvre réellement, et pour qui
llm-foundry ne se présente pas comme une bibliothèque d'inférence. Le README décrit un ensemble de scripts qui couvrent quatre étapes distinctes : conversion de corpus texte vers le format StreamingDataset dans scripts/data_prep, entraînement ou finetuning de modèles HuggingFace et MPT de 125M à 70B paramètres dans scripts/train, conversion vers HuggingFace ou ONNX et génération de réponses dans scripts/inference, évaluation sur des tâches académiques ou personnalisées en contexte dans scripts/eval. Le public visé est donc celui qui dispose déjà de plusieurs accélérateurs et qui veut industrialiser une recette d'entraînement, pas celui qui cherche à lancer un chat sur un portable. Le dépôt contient aussi un répertoire mcli pour lancer ces charges de travail via MCLI et la plateforme MosaicML, ce qui indique où se situe le centre de gravité du projet. Les modèles mis en avant sont les MPT, décrits comme des transformeurs de style GPT avec Flash Attention, ALiBi pour l'extrapolation de longueur de contexte et des ajustements de stabilité contre les pics de loss, ainsi que DBRX, un modèle à mélange d'experts de 132B paramètres totaux et 36B paramètres actifs, entraîné selon le README avec des versions optimisées de Composer, LLM Foundry et MegaBlocks.
Composer comme socle, et ce que cela impose
Le nom Composer revient dès la première phrase du README : le code sert à entraîner, affiner, évaluer et déployer des LLM avec Composer et la plateforme MosaicML. Cette dépendance structure le fonctionnement. Composer fournit la boucle d'entraînement, la gestion des callbacks et l'abstraction des périphériques ; llm-foundry apporte les modèles, les jeux de données et les utilitaires. La conséquence pratique est qu'une partie des questions d'ordonnancement, de reprise après incident et de distribution ne se règle pas dans ce dépôt mais dans Composer, dont la documentation est externe. Le README ne détaille pas les versions minimales ni les combinaisons testées, et cette information n'est pas vérifiable à partir du matériel fourni. Autre point de conception : le format de données attendu en entrée de l'entraînement est StreamingDataset, produit par les scripts de data_prep. Ce choix a un coût, puisqu'il faut convertir les corpus avant de pouvoir entraîner, et un bénéfice, puisque le même format sert ensuite à l'évaluation et à l'inférence. Pour DBRX, la pile ajoute MegaBlocks, ce qui signifie qu'un entraînement de type mixture-of-experts ne se réduit pas au chemin standard des scripts/train.
Mettre le dépôt en route : les points d'entrée documentés
Le README ne donne pas de séquence d'installation complète. Il indique que le paquet est publié sur PyPI sous le nom llm-foundry et que le dépôt contient un fichier TUTORIAL.md présenté comme un approfondissement du dépôt, avec des exemples de flux de travail et une FAQ. C'est ce fichier qu'il faut lire en premier, car le README s'arrête à la carte des répertoires. Pour l'inférence locale, la documentation renvoie explicitement vers scripts/inference/README.md et vers deux scripts, hf_generate.py pour la génération et hf_chat.py pour le dialogue, avec une section intitulée interactive generation with model.generate. Les scripts d'entraînement et d'évaluation se trouvent respectivement dans scripts/train et scripts/eval, et le sous-répertoire scripts/train/benchmarking sert à mesurer le débit d'entraînement et le MFU, tandis que scripts/inference/benchmarking mesure la latence et le débit d'inférence. Rien dans le matériel fourni ne précise les clés de configuration attendues par ces scripts, ni un exemple de fichier YAML. Cette lacune est réelle : un lecteur qui arrive avec un cluster et un corpus devra passer par TUTORIAL.md et par les README de sous-répertoires avant de pouvoir écrire sa propre configuration.
Le cas DBRX et la question du mélange d'experts
DBRX est l'argument le plus fort du dépôt, et aussi le plus difficile à reproduire. Le README indique que le modèle a été entraîné avec des versions optimisées de Composer, LLM Foundry et MegaBlocks, ce qui veut dire que le chemin d'entraînement utilisé en production n'est pas nécessairement identique à celui qu'un utilisateur obtient en installant la version publiée. Les poids sont distribués séparément, sur Hugging Face, sous les noms dbrx-base et dbrx-instruct, avec une longueur de contexte de 32768 tokens. Les poids et le code relèvent de licences distinctes : le README mentionne la Databricks Open Source License pour les poids et une Acceptable Use Policy, tandis que le dépôt de code lui-même est sous Apache-2.0. Cette séparation mérite attention, car Apache-2.0 sur le code ne dit rien des conditions d'usage des poids. Pour un lecteur qui veut seulement évaluer ou servir DBRX, le dépôt pertinent est plutôt databricks/dbrx, vers lequel le README renvoie explicitement. llm-foundry reste l'outil de celui qui veut refaire l'entraînement ou l'affinage, pas celui qui veut consommer le modèle.
MPT, ALiBi et la longueur de contexte en pratique
La famille MPT est décrite avec trois caractéristiques : Flash Attention pour l'efficacité, ALiBi pour l'extrapolation de longueur de contexte, et des améliorations de stabilité destinées à limiter les pics de loss. ALiBi est le point le plus intéressant, parce qu'il change la façon dont on raisonne sur le contexte. Le tableau du README montre des modèles entraînés à 2048 tokens comme MPT-7B, d'autres à 8192 comme MPT-30B et MPT-7b-8k, et MPT-7B-StoryWriter annoncé à 65536 tokens. La coexistence de ces valeurs dans un même dépôt illustre le principe : une même architecture, plusieurs fenêtres de contexte, selon l'entraînement. Le README signale aussi une distinction de licence au niveau des modèles et non du code : MPT-30B, MPT-30B-Instruct, MPT-7B, MPT-7B-Instruct et MPT-7B-StoryWriter sont marqués comme utilisables commercialement, tandis que MPT-30B-Chat, MPT-7b-8k-Chat et MPT-7B-Chat ne le sont pas. C'est une contrainte à vérifier avant de choisir une variante, et elle ne se lit pas dans le fichier LICENSE du dépôt.
Ce que le dépôt ne fait pas, et à quoi le comparer
Deux limites ressortent du matériel disponible. D'abord, l'écosystème communautaire listé dans le README pointe vers des projets qui prennent en charge MPT pour l'inférence sur du matériel modeste : ggml pour une version optimisée, GPT4All pour un système de dialogue local, une version 8 bits optimisée pour CPU côté Intel. Autrement dit, pour exécuter MPT sur une machine sans GPU de datacenter, l'outillage se trouve ailleurs, pas dans llm-foundry. Ensuite, la comparaison la plus directe se fait avec les bibliothèques d'entraînement adossées à Hugging Face, dont le README mentionne qu'elles sont prises en charge en entrée : les scripts/train acceptent des modèles HuggingFace. La différence d'approche tient au format de données et à la boucle d'entraînement. Là où l'écosystème Hugging Face part de fichiers chargés par un DataLoader classique, llm-foundry impose la conversion préalable vers StreamingDataset, ce qui déplace le travail en amont mais rend le flux de données indépendant du débit de lecture disque. Ce n'est pas un gain gratuit : c'est un investissement dans une étape de préparation, rentable seulement si l'on compte relancer plusieurs entraînements sur le même corpus.
Suivi des versions et coût de maintenance
Le dépôt n'est pas archivé et la dernière poussée enregistrée date du 25 mars 2026. Les versions publiées récentes suivent un rythme soutenu : v0.20.0 le 29 avril 2025, v0.21.0 le 31 mai 2025, v0.22.0 le 29 juillet 2025. Un cycle de publication d'environ un à deux mois signifie que les épinglages de dépendances bougent souvent, et qu'un environnement figé sur une version ancienne s'éloigne vite de la branche main. La licence du code est Apache-2.0, ce qui autorise l'usage commercial et la modification, avec les obligations habituelles de conservation des mentions et du fichier de licence. Cette licence ne couvre ni les poids DBRX, soumis à la Databricks Open Source License et à une politique d'usage acceptable, ni les variantes MPT marquées comme non commerciales dans le tableau du README. Pour un déploiement en entreprise, la vérification utile porte donc sur trois objets distincts : le code du dépôt, les poids du modèle choisi, et les conditions du fournisseur de calcul. Le README renvoie à un canal Slack communautaire et à des tutoriels vidéo externes, mais ne décrit pas de politique de support ni d'engagement de compatibilité entre versions.
Conclusion éditoriale
llm-foundry convient aux équipes qui entraînent ou affinent des modèles de 125M à 70B paramètres sur plusieurs GPU et qui veulent un pipeline reproductible, du formatage des données jusqu'à la conversion ONNX. Il ne convient pas à qui cherche une bibliothèque légère pour faire tourner un modèle sur une seule machine : les scripts d'inférence ne sont pas le cœur du dépôt, et la documentation renvoie à Composer et à la plateforme MosaicML pour l'orchestration. Avant d'adopter, vérifiez dans TUTORIAL.md la version de Composer attendue par la branche main, puis comparez-la à celle de votre environnement, car le dépôt publie une version mineure environ tous les deux mois.
Notes de la communauté