bert4torch : une réimplémentation PyTorch des modèles transformers, avec une API inspirée de Keras
An elegent pytorch implement of transformers
En bref
- De quoi s’agit-il ?
- bert4torch propose de charger des poids pré-entraînés (BERT, RoBERTa, T5, ChatGLM, Llama, Qwen) et de les fine-tuner dans PyTorch avec une boucle d'entraînement de style Keras. Le dépôt est maintenu par une seule personne, ce qui est un critère de décision aussi important que ses fonctionnalités.
- À qui s’adresse-t-il ?
- bert4torch convient à un ingénieur ou un chercheur qui veut fine-tuner un transformer ou servir un LLM en PyTorch sans écrire de boucle d'entraînement, et qui accepte de dépendre d'un projet maintenu par une seule personne. Il ne convient pas à une équipe qui a besoin d'un écosystème large, de garanties de support ou d'une compatibilité stricte avec les scripts de l'écosystème Hugging Face.
- Puis-je l’utiliser commercialement ?
- Oui. MIT 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 122 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
Le problème visé : fine-tuner sans réécrire la boucle d'entraînement
Charger un poids pré-entraîné et l'adapter à sa tâche demande, dans PyTorch brut, d'écrire une boucle d'entraînement, de gérer les callbacks, la barre de progression, la journalisation et la sauvegarde. bert4torch prend en charge cette partie. Le README décrit une API de type Keras, avec un fit personnalisable, une barre de progression affichant la loss et les métriques définies, un Logger par défaut et Tensorboard. Le projet se présente comme une réimplémentation de transformers en PyTorch, avec bert4keras comme ancêtre revendiqué. Le public visé est donc celui qui connaît Keras ou bert4keras et qui veut le même confort en PyTorch.
Le périmètre de modèles est large : bert, roberta, albert, xlnet, nezha, bart, RoFormer, RoFormer_V2, ELECTRA, GPT, GPT2, T5, GAU-alpha, ERNIE pour le fine-tuning, et chatglm, llama, baichuan, ziya, bloom pour l'inférence et le fine-tuning de grands modèles. Le dépôt contient des exemples classés par tâche : llm, pretrain, sentence_classification, sentence_embedding, sequence_labeling, relation_extraction, seq2seq, serving. C'est un point concret : la structure du dépôt montre quelles tâches sont outillées, pas seulement quels modèles sont supportés.
Ce que la version 0.6.2 change dans les dépendances
La table des versions du README indique, pour le 13 mai 2026, la version 0.6.2 avec torch4keras 0.3.4. Les ajouts listés sont qwen3_vl, deepseek ocr et glm_ocr, ainsi que la suppression de la dépendance à transformers, remplacée par des classes AutoTokenizer et AutoProcessor propres au projet. C'est un changement d'architecture plus qu'une simple entrée de journal : le projet cesse de s'appuyer sur la bibliothèque de référence pour le chargement des tokenizers et des processeurs.
La version 0.6.0, en septembre 2025, ajoutait Qwen3-moe et le support de gptq et awq comme formats de quantification. La 0.6.1, en janvier 2026, ajoutait paddleocr-vl et retirait des configurations de modèles codées en dur. Ces trois versions dessinent une direction : réduire les dépendances externes et internaliser la configuration des modèles. Pour un utilisateur, cela signifie que la compatibilité avec l'écosystème transformers n'est plus garantie par construction. Le README mentionne toutefois un tutoriel dédié au chargement de modèles de la bibliothèque transformers, donc l'interopérabilité existe, mais elle passe par une couche d'adaptation du projet.
Installation et lancement d'un service de LLM en ligne de commande
L'installation tient en une commande : pip install bert4torch pour la version stable, ou pip install git+https://github.com/Tongjilibo/bert4torch pour la version de développement. Le README signale explicitement que la publication sur PyPI est en retard sur la branche git, et que les poids peuvent nécessiter une conversion. C'est une contrainte à intégrer au moment de choisir entre les deux modes d'installation.
Le point le plus concret du projet est la commande de service. Le README donne ces exemples : bert4torch serve Qwen/Qwen2-0.5B-Instruct pour télécharger tous les fichiers depuis le réseau, ou bert4torch serve /data/pretrain_ckpt/Qwen/Qwen2-0.5B-Instruct pour charger un modèle local, à condition que bert4torch_config.json soit présent dans le même répertoire. Le mode d'exposition se choisit avec --mode : cli pour le terminal, gradio pour une page web, openai pour une API compatible avec le format OpenAI. Le README affirme que les scripts d'inférence sont communs à tous les modèles, donc pas de script à maintenir par architecture. C'est la promesse la plus intéressante du dépôt, et aussi celle qu'un utilisateur devrait vérifier en premier sur son propre modèle.
Tricks d'entraînement et comparaison avec transformers
Le README publie un tableau comparatif entre bert4torch et transformers. Les deux cochent la barre de progression, l'entraînement distribué dp/ddp, les callbacks (journalisation, tensorboard, earlystop, wandb), l'inférence de grands modèles en streaming et par lots, le fine-tuning de LLM (LoRA via peft, pv2 intégré). La ligne sur les tricks d'entraînement est marquée comme absente côté transformers : le dépôt fournit un répertoire examples/training_trick présenté comme utilisable immédiatement, avec l'entraînement adversarial cité en exemple. La ligne sur la simplicité du code et la marge de personnalisation est également marquée comme absente côté transformers, avec un argument de réutilisation et de style Keras.
Le tableau indique aussi, en toute honnêteté, que la maintenance, l'influence, l'usage et la compatibilité penchent du côté de transformers. Le README précise que le dépôt est maintenu par une personne. Cette ligne n'est pas un détail : elle conditionne la tolérance au risque de l'adoption. Un projet avec des tricks prêts à l'emploi et une API courte a de la valeur pour un prototype ou une expérimentation ; il en a moins pour une équipe qui doit garantir des mises à jour de sécurité sur plusieurs années.
Limites et cas où bert4torch n'est pas le bon outil
La première limite est la maintenance individuelle, reconnue dans le tableau du README. Un projet maintenu par une seule personne implique un délai de réponse aux problèmes et aux pull requests qui dépend d'une disponibilité, et un risque de rupture si le mainteneur s'arrête. Le dépôt n'est pas archivé et la dernière poussée date du 16 mai 2026, mais cela ne change pas la structure du risque.
La deuxième limite est la compatibilité de version de torch. Le README indique que le développement se faisait avec torch==1.10 et qu'il est passé à torch2.0, en invitant à signaler les incompatibilités avec d'autres versions. Autrement dit, aucune matrice de compatibilité n'est publiée. Sur un environnement figé, c'est un point de vérification obligatoire avant de s'engager.
La troisième limite concerne le chargement des poids. Le README avertit que les poids peuvent nécessiter une conversion, et la suppression de la dépendance transformers en 0.6.2 déplace la responsabilité du chargement vers les classes AutoTokenizer et AutoProcessor du projet. Si votre modèle vient d'un dépôt Hugging Face récent, il faut vérifier que le tokenizer et le processeur sont reconnus, en particulier pour les modèles multimodaux ajoutés récemment (qwen3_vl, deepseek ocr, glm_ocr). Un modèle absent de la liste des versions n'a aucune raison de fonctionner, même si l'architecture semble proche d'une autre.
Alternatives et différence d'approche
L'alternative la plus directe est la bibliothèque transformers de Hugging Face, avec son Trainer. La différence n'est pas une question de fonctionnalités mais de conception : transformers expose un objet de configuration par modèle, un tokenizer associé et une classe Trainer qui encapsule la boucle d'entraînement, avec un écosystème de modèles et de formats très large. bert4torch choisit une API plus proche de Keras, avec un fit personnalisable et des scripts d'inférence mutualisés entre architectures. Le prix de cette mutualisation est la couverture : elle dépend de ce que le projet a implémenté, pas de ce que la communauté publie.
Une deuxième alternative est d'écrire la boucle d'entraînement soi-même dans PyTorch. Cela donne un contrôle total et aucune dépendance à un mainteneur unique, mais il faut alors réimplémenter la barre de progression, les callbacks, la journalisation, la reprise sur checkpoint et le service d'inférence. bert4torch se situe entre les deux : moins de code à écrire que dans une boucle maison, moins de garanties d'écosystème que dans transformers.
Licence et coût de mise à jour
Le dépôt est publié sous licence MIT, ce qui autorise l'usage commercial, la modification et la redistribution, sous réserve de conserver l'avis de licence et de copyright. Ce n'est pas un avis juridique : les poids pré-entraînés que vous chargez ont leurs propres licences, distinctes de celle du code, et c'est ce point qu'il faut examiner avant une mise en production.
Sur le coût de mise à jour, le rythme observé est de deux versions majeures par an environ (0.6.0 en septembre 2025, 0.6.1 en janvier 2026, 0.6.2 en mai 2026), et chaque version couple bert4torch à une version de torch4keras (0.3.2, 0.3.3, 0.3.4). Mettre à jour bert4torch implique donc souvent de suivre torch4keras, qui est un paquet séparé du même auteur. La 0.6.2 a par ailleurs retiré la dépendance à transformers, ce qui est un changement cassant pour du code qui s'appuyait sur cette dépendance. Une montée de version ne se fait pas par simple changement de numéro : il faut relire la table des versions et vérifier le modèle concerné.
Conclusion éditoriale
bert4torch convient à un ingénieur ou un chercheur qui veut fine-tuner un transformer ou servir un LLM en PyTorch sans écrire de boucle d'entraînement, et qui accepte de dépendre d'un projet maintenu par une seule personne. Il ne convient pas à une équipe qui a besoin d'un écosystème large, de garanties de support ou d'une compatibilité stricte avec les scripts de l'écosystème Hugging Face. Avant d'adopter, vérifier la version de torch installée par rapport à celle utilisée en développement (torch2.0 selon le README), et contrôler que le modèle visé figure bien dans la table des versions plutôt que dans un exemple isolé.
Notes de la communauté