LitGPT : réimplémenter chaque LLM plutôt que l'envelopper

Le problème : la pile d'abstractions entre le chercheur et la matrice

La plupart des bibliothèques de modèles de langage empilent des couches : un chargeur, un wrapper de configuration, un moteur d'attention interchangeable, un gestionnaire de génération. Chaque couche masque un détail, et quand une forme de tenseur ne correspond pas ou qu'un masque d'attention est mal construit, il faut descendre dans du code qui n'appartient pas au projet. LitGPT prend le chemin inverse. Le README affirme que chaque modèle est implémenté depuis zéro, avec pour objectif affiché de maximiser la performance et de supprimer les couches d'abstraction. Le public visé n'est donc pas celui qui veut appeler une API de génération en trois lignes, mais celui qui doit comprendre pourquoi un modèle consomme tant de mémoire, ou qui doit adapter une architecture à un nouveau jeu de données. La page d'accueil insiste sur « no abstractions » et « single file implementations », ce qui situe le projet du côté de la lisibilité et du débogage plutôt que de la couverture fonctionnelle.

Un fichier par architecture, une recette YAML par scénario

Le mécanisme central tient en deux éléments visibles dans la documentation. D'abord, chaque modèle dispose de sa propre implémentation, ce qui signifie que la définition de l'attention, du MLP et du bloc transformer est propre à chaque famille (Llama, Gemma, Phi, Qwen, Falcon). Ensuite, les entraînements sont décrits par des recettes au format YAML, listées dans la section Recipes du README. Cette séparation est le point d'architecture le plus intéressant : la recette porte les hyperparamètres et la stratégie de parallélisme, tandis que le code Python porte l'architecture. On peut donc comparer deux recettes de finetune sans lire de Python, et modifier une architecture sans toucher aux scripts de lancement. Le revers est immédiat : toute correction de bug d'attention doit être appliquée modèle par modèle, puisque rien n'est mutualisé. Le README mentionne Flash Attention et FSDP comme briques disponibles, sans préciser comment elles sont câblées dans chaque fichier de modèle, et cette information n'est pas vérifiable à partir du seul README.

Installation et première génération

L'installation tient en une commande : pip install 'litgpt[extra]'. Le README donne aussi la variante depuis les sources, avec git clone, puis uv sync --all-extras ou pip install -e ".[extra,compiler,test]" selon l'outil retenu. L'usage minimal passe par la classe LLM : on importe LLM depuis litgpt, on appelle LLM.load("microsoft/phi-2"), puis llm.generate avec une phrase à corriger. L'exemple du README montre la correction orthographique d'une phrase anglaise et la sortie attendue. Deux points méritent l'attention. Le paquet s'installe avec l'extra, ce qui suggère que les dépendances lourdes ne sont pas tirées par défaut. Et le chargement se fait par nom de modèle au format Hugging Face, ce qui indique un pont avec les poids publiés sur le Hub, sans que le README détaille le format de conversion utilisé. La documentation renvoie vers tutorials/python-api.md pour l'API complète, que je n'ai pas consultée ici.

Ce que la promesse « 1 à 1000+ GPU » laisse en suspens

Le README annonce une échelle de 1 à 1000+ GPU et TPU, avec FSDP et la quantification fp4, fp8, fp16 et fp32. Ces affirmations décrivent des capacités, pas des performances mesurées, et le matériel fourni ne contient aucun chiffre de débit, de mémoire ou de temps d'entraînement. Il faut donc les lire comme un périmètre fonctionnel. La contrainte réelle de ce type de projet est ailleurs : réimplémenter une architecture signifie aussi réimplémenter sa tokenisation et sa conversion de poids. Quand un modèle amont publie une révision de ses poids ou change son tokenizer, la compatibilité dépend du travail de mise à jour côté LitGPT, pas d'un mécanisme automatique. C'est le coût caché d'un dépôt sans abstraction : la surface à maintenir croît avec le nombre de modèles listés, qui dépasse la vingtaine. Un utilisateur qui a besoin d'un modèle absent de la liste devra écrire son propre fichier d'architecture, ce qui est précisément l'objectif du projet mais représente un travail non trivial.

Pourquoi vLLM reste le choix par défaut en production

vLLM et LitGPT ne résolvent pas le même problème. vLLM se concentre sur le service d'inférence : il gère la mémoire du cache KV par pagination, regroupe les requêtes en continu et expose un serveur compatible avec l'API OpenAI. On ne réimplémente pas d'architecture, on charge des poids existants et on maximise le débit sous charge concurrente. LitGPT, à l'inverse, assume l'implémentation du modèle et met l'accent sur l'entraînement et le finetune, avec LoRA, QLoRA et Adapter mentionnés dans le README. La différence d'approche est donc nette : chez vLLM le modèle est une donnée, chez LitGPT c'est du code. Si votre besoin est de servir un modèle à plusieurs centaines de requêtes par seconde avec une latence stable, la pagination du cache KV de vLLM répond à une question que LitGPT ne prétend pas traiter. Si votre besoin est de modifier la boucle d'entraînement ou d'inspecter l'attention, l'inverse est vrai.

Licence Apache-2.0 et coût de mise à jour

Le dépôt est publié sous Apache-2.0, ce que le README présente comme une garantie d'usage en entreprise sans restriction. C'est exact pour le code de LitGPT lui-même. Cela ne dit rien des poids : chaque modèle listé conserve la licence de son auteur d'origine, et le README renvoie pour chacun vers une publication externe (Meta AI, Google DeepMind, Microsoft Research, Alibaba, TII, Stability AI). Une équipe qui déploie un modèle Llama doit donc vérifier la licence du poids, pas seulement celle du dépôt. Sur la maintenance, les versions récentes s'espacent : v0.5.11 en septembre 2025, v0.5.12 en décembre 2025, v0.5.13 en juin 2026. Le rythme n'est pas celui d'une publication hebdomadaire, ce qui est cohérent avec un projet qui doit suivre les sorties de modèles amont. La conséquence pratique est qu'une montée de version peut changer une signature d'API ou une recette YAML, et qu'il faut lire les notes de version avant de mettre à jour un pipeline d'entraînement en cours.

Quand LitGPT est le mauvais outil

Trois cas de figure rendent le projet inadapté. Le premier est le service d'inférence multi-modèles avec routage dynamique : rien dans le README n'indique de mécanisme de ce genre, et la logique de chargement par nom de modèle suppose un modèle actif à la fois. Le deuxième est la recherche de compatibilité maximale avec l'écosystème Hugging Face, adaptateurs PEFT interchangeables et formats de quantization standardisés : LitGPT implémente ses propres chemins, ce qui crée une friction à chaque échange de fichiers avec un autre outil. Le troisième est l'équipe sans compétence en PyTorch distribué. Le README cite FSDP et une échelle de 1 à 1000+ GPU, mais ne fournit pas de guide de dimensionnement dans le matériel disponible ; lancer un finetune sur plusieurs nœuds demande de comprendre la configuration de parallélisme, et une erreur de configuration se traduit par une consommation de mémoire inattendue plutôt que par un message d'erreur explicite.

Conclusion éditoriale

LitGPT convient à qui veut lire, modifier et entraîner un modèle de bout en bout, avec FSDP, LoRA ou quantification fp4/fp8, et qui accepte de gérer lui-même la conversion de poids et le suivi des sorties de modèles. Il ne convient pas à qui cherche un serveur d'inférence prêt à l'emploi avec routage multi-modèles, ni à qui veut un écosystème d'adaptateurs interchangeables. Avant d'adopter, vérifier deux choses dans le dépôt : le fichier de configuration du modèle visé dans config_hub, et la commande litgpt convert qui fait le pont avec les poids Hugging Face.

Sources officielles

1. License: Apache-2.0
2. Lightning-AI/litgpt on GitHub
3. Project website
4. README
5. Releases