Chitu (赤兔) : un moteur d'inférence LLM qui mise sur le matériel hétérogène
High-performance inference framework for large language models, focusing on efficiency, flexibility, and availability.
En bref
- De quoi s’agit-il ?
- Chitu est un moteur d'inférence pour grands modèles de langage publié sous Apache-2.0 par l'équipe thu-pacman. Son axe distinctif n'est pas la vitesse brute mais la couverture matérielle, du CPU seul aux clusters multi-nœuds, en passant par les accélérateurs chinois.
- À qui s’adresse-t-il ?
- Chitu s'adresse aux équipes qui doivent servir des modèles sur du matériel non NVIDIA ou sur un mélange de CPU et d'accélérateurs, et qui acceptent de lire docs/zh/DEVELOPMENT.md avant de s'engager. Si votre parc est homogène en GPU NVIDIA et que vous voulez l'écosystème le plus large, vLLM ou SGLang restent plus directs.
- 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 5 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é : servir un LLM quand le parc matériel n'est pas homogène
La plupart des moteurs d'inférence supposent implicitement un parc homogène, généralement des GPU NVIDIA récents. Chitu part d'une contrainte différente. Le README le formule ainsi : l'objectif est de couvrir les besoins progressifs des entreprises, depuis les petits essais jusqu'au déploiement à grande échelle. Concrètement, cela veut dire qu'un même moteur doit pouvoir tourner sur du CPU seul, sur une carte unique, ou sur un cluster, et sur des puces de générations et de constructeurs différents. Le public visé n'est donc pas le développeur qui teste un modèle sur sa machine, mais l'équipe qui doit livrer un service d'inférence dans un environnement où le matériel est imposé par le fournisseur, le budget ou la disponibilité. Les journaux de versions donnent la mesure de cet effort : la v0.5.1 adapte les GPU Moore Threads, la v0.4.0 cite 昇腾, NVIDIA, 沐曦 et 海光, et la v0.3.9 revendique le premier support d'un modèle MoE de 智谱 GLM-4.5 sur 昇腾 910B. C'est un positionnement de compatibilité, pas de performance pure, et le README le reconnaît en citant les partenaires (华为, 沐曦, 海光, 燧原, 智谱, 中国电信, 并行科技) parmi les remerciements.
Ce que le dépôt laisse voir de l'architecture
Le README ne décrit pas l'architecture interne, et il faut le dire clairement : tout ce qu'on peut affirmer vient des notes de version et de l'arborescence. Trois mécanismes ressortent. D'abord la quantification à la volée : la v0.1.0 apporte une conversion FP8 vers BF16 par opérateurs, la v0.3.0 ajoute FP4 vers FP8 et BF16, avec un lien vers la version quantifiée FP4 de DeepSeek-R1 671B. Le principe est de charger un modèle dans un format compressé et de le convertir pendant l'exécution plutôt que de maintenir plusieurs copies. Ensuite l'inférence hybride CPU et GPU, introduite en v0.2.2, qui permet selon la note de faire tourner DeepSeek-R1 671B sur une seule carte en déportant une partie du calcul vers le CPU. Enfin la séparation des phases prefill et decode (PD), mentionnée dans la note v0.6.0 comme l'un des scénarios que la commande chitu.run sait orchestrer. Le dépôt mélange Python (langage principal) et des fragments repris d'autres projets, avec des sous-modules tiers dans third_party/. Les licences de ces emprunts sont tracées en SPDX dans le code et regroupées dans LICENSES/, ce qui est un point à examiner si vous redistribuez le binaire.
Mise en route : chitu.run plutôt que pip install
Le README ne donne pas de commande pip. Il oriente vers les Releases GitHub : la v0.6.0 introduit un exécutable chitu.run, décrit comme un fichier unique capable de lancer des tâches complexes, multi-nœuds, multi-instances ou avec séparation PD. La consigne est donc de télécharger le binaire depuis la page Assets de la release correspondante, puis de consulter docs/zh/DEVELOPMENT.md pour la procédure complète. C'est un choix d'empaquetage qui a des conséquences pratiques : vous ne dépendez pas de la résolution d'environnement Python de votre distribution, mais vous dépendez de la disponibilité d'un binaire pour votre plateforme. Le README renvoie aussi à docs/zh/SUPPORTED_MODELS.md pour la liste des modèles, et à docs/zh/PERFORMANCE.md pour les chiffres mesurés par l'équipe. Aucune de ces pages n'est reproduite dans le matériel fourni, donc je ne peux pas confirmer la liste exacte des modèles pris en charge ni les valeurs de débit. Le README précise d'ailleurs que ces mesures dépendent du matériel, des versions logicielles et de la charge, et que les résultats varient d'une exécution à l'autre.
Le support de maintenance est explicitement limité
C'est la partie du README qu'il faut lire deux fois. L'équipe écrit remercier les utilisateurs pour leurs retours et vouloir continuer à améliorer le moteur, puis ajoute que, compte tenu de ses moyens, elle ne peut pas garantir de traiter rapidement tous les problèmes rencontrés. Une adresse est donnée pour un service technique professionnel : solution@chitu.ai. Autrement dit, le projet est ouvert sous Apache-2.0, mais le support n'est pas inclus dans la licence. Pour une équipe qui envisage la production, cela déplace le risque : vous pouvez lire et modifier le code, mais si un blocage survient sur une puce précise, personne ne s'engage contractuellement à le corriger dans un délai donné. Le rythme des versions récentes (v0.5.6, v0.5.7, v0.6.0 entre mai et juillet 2026 selon le matériel fourni) suggère une activité soutenue, mais une cadence de publication n'est pas une garantie de support. Notez aussi que le dépôt n'est pas archivé à la date indiquée, ce qui est le minimum attendu.
Quand Chitu n'est pas le bon outil
Il y a au moins deux cas où ce moteur est un mauvais choix. Le premier est un parc homogène de GPU NVIDIA récents avec une équipe déjà familière d'un autre moteur : l'argument principal de Chitu, la couverture matérielle, ne vous apporte rien, et vous payez en revanche une documentation partiellement en chinois et un support communautaire sans engagement. Le second cas est celui d'un modèle absent de docs/zh/SUPPORTED_MODELS.md. Le README oriente vers cette page sans en donner le contenu, et rien n'indique une procédure d'ajout de modèle documentée dans le matériel disponible. Ajouter un modèle à un moteur d'inférence implique de toucher aux noyaux et au découpage du graphe, ce qui n'est pas un travail de configuration. Un troisième point mérite attention : l'inférence hybride CPU et GPU rend possible l'exécution d'un modèle de 671B sur une carte unique, mais le README ne donne aucune indication de latence dans ce mode. Faire tenir un modèle n'est pas la même chose que le servir à un débit acceptable, et le matériel fourni ne permet pas de trancher.
Face à vLLM et SGLang, la différence est le périmètre matériel
Le README cite lui-même vLLM, SGLang, TensorRT-LLM, FlashInfer, FlashAttention, KTransformers et llama.cpp parmi les projets dont l'équipe s'est inspirée et dont elle a réutilisé des fonctions. La comparaison est donc posée par les auteurs. vLLM et SGLang visent en priorité les GPU NVIDIA, avec un écosystème de contributions et de modèles plus large, et une documentation anglophone abondante. Chitu prend le chemin inverse : moins de largeur sur les modèles, plus de largeur sur les accélérateurs. Le support de 昇腾 910B, de 沐曦, de 海光 ou de Moore Threads n'est pas un détail cosmétique ; c'est ce qui détermine si vous pouvez déployer du tout dans certains environnements. Si votre contrainte est matérielle et non logicielle, l'ordre de vos critères s'inverse. Si votre contrainte est la variété des modèles et la profondeur de l'outillage, il ne s'inverse pas.
Licence et coût de mise à jour
Le projet est sous Apache License v2.0, avec un fichier LICENSE à la racine. Deux réserves figurent dans le README. Le dépôt reprend des fragments d'autres projets open source, avec des informations de copyright en SPDX dans le code et des licences regroupées dans LICENSES/. Le dépôt contient aussi des sous-modules tiers dans third_party/, chacun avec son propre fichier de licence. Si vous redistribuez Chitu, ou si vous l'intégrez dans un produit, ces deux répertoires sont les premiers à inspecter, car Apache-2.0 ne couvre pas automatiquement le code de tiers embarqué. Sur le coût de mise à jour, le matériel disponible montre une séquence de versions rapprochées, dont une v0.6.0 qui introduit un nouveau point d'entrée, chitu.run. Une équipe qui adopte cette version s'expose à un changement d'outillage entre v0.5.x et v0.6.0, ce qui plaide pour figer une version et tester la suivante sur un nœud isolé avant de basculer. Je ne peux pas évaluer la fréquence des ruptures de compatibilité : le README ne contient pas de politique de versionnement. Ce paragraphe décrit la licence telle qu'elle est déclarée, il ne constitue pas un avis juridique.
Conclusion éditoriale
Chitu s'adresse aux équipes qui doivent servir des modèles sur du matériel non NVIDIA ou sur un mélange de CPU et d'accélérateurs, et qui acceptent de lire docs/zh/DEVELOPMENT.md avant de s'engager. Si votre parc est homogène en GPU NVIDIA et que vous voulez l'écosystème le plus large, vLLM ou SGLang restent plus directs. Avant de choisir, vérifiez deux choses concrètes : que votre modèle figure dans docs/zh/SUPPORTED_MODELS.md, et que le binaire chitu.run de la version v0.6.0 se lance sur votre nœud cible.
Notes de la communauté