FastDeploy : servir des LLM et VLM PaddlePaddle sur du matériel chinois
High-performance Inference and Deployment Toolkit for LLMs and VLMs based on PaddlePaddle
En bref
- De quoi s’agit-il ?
- FastDeploy est la boîte à outils de déploiement d'inférence de PaddlePaddle, avec PD disaggregation, cache KV unifié et compatibilité API vLLM. Le point intéressant n'est pas la liste de fonctionnalités, c'est le portage sur XPU, DCU, GCU et Gaudi.
- À qui s’adresse-t-il ?
- FastDeploy s'adresse aux équipes déjà engagées sur PaddlePaddle ou ERNIE, et surtout à celles qui doivent faire tourner de l'inférence sur Kunlunxin XPU, Hygon DCU, Enflame GCU, Iluvatar, Metax ou Intel Gaudi, là où vLLM ne couvre pas la cible. Si votre parc est exclusivement NVIDIA et que votre modèle est un Llama ou un Mistral, l'écosystème vLLM reste plus large et FastDeploy n'apporte rien.
- 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 21 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 réel : servir ERNIE sans passer par NVIDIA
La plupart des serveurs d'inférence open source supposent un GPU NVIDIA et un modèle au format HuggingFace. FastDeploy part d'une contrainte différente. Le projet est construit sur PaddlePaddle, et son catalogue de modèles est organisé autour de la famille ERNIE : les topics du dépôt mentionnent ernie, ernie-45 et ernie-45-vl, et les notes de version de v2.3 documentent l'ajout du déploiement d'ERNIE-4.5-VL-28B-A3B-Thinking et de PaddleOCR-VL-0.9B sur plusieurs plateformes matérielles. Le public visé est donc une équipe qui a déjà des poids PaddlePaddle, ou qui doit les exécuter sur un accélérateur non-NVIDIA. Le README énumère sept familles : NVIDIA GPU, Kunlunxin XPU, Iluvatar CoreX, Enflame S60, Hygon DCU, Metax GPU et Intel Gaudi, chacune avec sa propre page d'installation dans docs/zh/get_started/installation/. C'est là que se situe la valeur du projet, pas dans le débit brut sur une carte NVIDIA, terrain où la concurrence est dense.
PD disaggregation : séparer prefill et decode, puis rééquilibrer
La fonction mise en avant est la «负载均衡式PD分解», que le README décrit comme une solution de niveau industriel avec cache de contexte et commutation dynamique du rôle des instances. Le principe de la disaggregation prefill/decode est connu : le prefill, gourmand en calcul matriciel, et le decode, gourmand en bande passante mémoire, n'ont pas le même profil de ressources, donc on les place sur des instances distinctes. Ce que FastDeploy ajoute selon sa documentation, c'est la commutation dynamique des rôles : une instance peut changer de rôle plutôt que rester figée dans la fonction qui lui a été assignée au démarrage. C'est un choix de conception qui a un coût. Une commutation de rôle implique de vider ou de migrer un état de cache, et le README ne détaille pas la granularité de cette opération ni son impact sur les requêtes en vol. Le Router, documenté dans docs/zh/online_serving/router.md, est le composant qui prend ces décisions d'ordonnancement. Si votre charge est stable et homogène, cette machinerie apporte de la complexité opérationnelle sans bénéfice évident.
Le transfert de cache KV entre instances
Dès que prefill et decode sont séparés, le cache KV doit voyager d'une instance à l'autre. FastDeploy fournit pour cela une bibliothèque de transfert décrite comme légère et performante, avec sélection automatique entre NVLink et RDMA. Le choix du transport n'est pas anodin : NVLink suppose que les instances soient sur le même nœud physique, RDMA permet de traverser le réseau. Une sélection automatique signifie que la topologie détectée détermine le chemin emprunté, et donc que le comportement en production dépend de la façon dont vos nœuds sont câblés. Le projet documente aussi une «全局Cache池化», un pool de cache global, dans docs/zh/features/global_cache_pooling.md. Ces deux mécanismes vont ensemble : un pool partagé n'a d'intérêt que si le transport sous-jacent est assez rapide pour que le coût du déplacement reste inférieur au gain du préfixe réutilisé. La documentation du dépôt ne fournit pas de chiffres de latence pour ce trajet, et c'est une zone à mesurer vous-même sur votre topologie avant de dimensionner un cluster.
Compatibilité vLLM : ce que cela couvre vraiment
Le README annonce un «OpenAI API服务与vLLM兼容» et un déploiement en une seule commande. Les remerciements précisent que FastDeploy a repris une partie du code de vLLM pour maintenir la compatibilité des interfaces. Il faut lire cette compatibilité pour ce qu'elle est : une compatibilité d'interface, côté API et côté client, pas une compatibilité de moteur. Un client qui parle à vLLM peut donc viser FastDeploy, ce qui réduit le coût de migration. En revanche, les formats de poids, le chargeur de modèles et le planificateur restent ceux de PaddlePaddle. Un modèle au format HuggingFace devra passer par une étape de conversion, et le README renvoie pour cela à docs/zh/supported_models.md, qui explique comment télécharger les modèles et comment prendre en charge le format torch. C'est un point à vérifier tôt : la liste des modèles supportés est le document qui décide si le projet vous convient.
Installation : Linux, Python 3.10 à 3.12, et une page par accélérateur
Les prérequis annoncés sont stricts : Linux, et Python entre 3.10 et 3.12. Le badge du README pointe sur Python 3.10. Il n'y a pas de variante Windows ou macOS documentée. L'installation ne se fait pas par une commande unique mais par une page dédiée selon le matériel : docs/zh/get_started/installation/nvidia_gpu.md, kunlunxin_xpu.md, iluvatar_gpu.md, Enflame_gcu.md, hygon_dcu.md, metax_gpu.md et intel_gaudi.md. Le point d'entrée de la documentation est paddlepaddle.github.io/FastDeploy/zh/get_started/installation/nvidia_gpu/. Le README renvoie ensuite vers un guide de démarrage en dix minutes et une page de service en ligne dans docs/zh/online_serving/README.md. Les fonctionnalités avancées ont chacune leur page : quantization/README.md, features/disaggregated.md, features/speculative_decoding.md, features/prefix_caching.md, features/chunked_prefill.md. C'est une documentation volumineuse, et le fait qu'elle soit répartie par matériel plutôt que centralisée signifie que chaque plateforme a ses propres écarts.
Quantification et décodage spéculatif
Le README liste les formats pris en charge : W8A16, W8A8, W4A16, W4A8, W2A16 et FP8. La note de version v2.5 mentionne l'ajout d'une méthode W4AFP8. Cette étendue de formats est cohérente avec la cible matérielle du projet : les accélérateurs non-NVIDIA n'ont pas tous le même support des types basse précision, et proposer W2A16 ou FP8 revient à couvrir des capacités de silicium hétérogènes. Il faut noter que le README ne dit pas quels formats sont disponibles sur quelles plateformes. Un format listé globalement peut très bien n'être implémenté que pour un sous-ensemble de backends. Côté accélération, le projet documente le décodage spéculatif, le multi-token prediction (MTP) et le chunked prefill. La v2.4 indique avoir renforcé les capacités de MTP. Ces techniques se cumulent mal en pratique : MTP et décodage spéculatif modifient tous deux la boucle de génération, et leur combinaison avec la PD disaggregation n'est pas décrite dans les documents fournis.
Ce que le projet ne couvre pas
Trois limites ressortent du matériel disponible. D'abord, la portabilité : Linux uniquement, Python 3.10 à 3.12, sans alternative documentée. Ensuite, l'ancrage à PaddlePaddle. Le projet n'est pas un serveur agnostique vis-à-vis du framework : il est bâti sur PaddlePaddle, et l'essentiel de son intérêt se concentre sur les modèles ERNIE et les modèles convertis. Si votre stack est PyTorch de bout en bout, l'adoption implique une dépendance supplémentaire. Enfin, la documentation est principalement en chinois, avec un README_EN.md en anglais et des pages de documentation dont les chemins visibles sont sous docs/zh/. Ce n'est pas un défaut en soi, mais cela détermine qui peut réellement diagnostiquer un problème en production. Sur le plan de la maintenance, le rythme de publication est soutenu : v2.3 en novembre 2025, v2.4 en janvier 2026, v2.5 en avril 2026, avec 170 corrections et optimisations annoncées pour cette dernière. Un rythme aussi rapide signifie que les correctifs arrivent vite, mais aussi que les notes de version deviennent une lecture obligatoire avant chaque mise à jour.
Licence Apache-2.0 et alternatives
FastDeploy est distribué sous Apache-2.0, ce qui autorise l'usage commercial, la modification et la redistribution, avec les obligations habituelles de conservation de la notice de licence et de mention des modifications. Le point à ne pas manquer est que le projet indique avoir repris du code de vLLM, lui-même sous Apache-2.0. Cette compatibilité de licences est ce qui rend la reprise possible, mais si vous redistribuez FastDeploy modifié, l'attribution couvre les deux projets. Rien là de bloquant pour un usage interne. L'alternative la plus directe est vLLM, et la différence n'est pas une question de fonctionnalités : vLLM est construit autour de PyTorch et de l'écosystème HuggingFace, avec un catalogue de modèles beaucoup plus large. FastDeploy est construit autour de PaddlePaddle et couvre des accélérateurs que vLLM ne cible pas. Le choix se fait donc sur deux axes : le framework de vos poids, et le silicium de votre cluster. Si vous êtes sur NVIDIA avec des modèles HuggingFace, vLLM est le chemin court. Si vous devez servir ERNIE sur du Kunlunxin XPU ou du Hygon DCU, FastDeploy est l'une des rares options documentées.
Conclusion éditoriale
FastDeploy s'adresse aux équipes déjà engagées sur PaddlePaddle ou ERNIE, et surtout à celles qui doivent faire tourner de l'inférence sur Kunlunxin XPU, Hygon DCU, Enflame GCU, Iluvatar, Metax ou Intel Gaudi, là où vLLM ne couvre pas la cible. Si votre parc est exclusivement NVIDIA et que votre modèle est un Llama ou un Mistral, l'écosystème vLLM reste plus large et FastDeploy n'apporte rien. Avant de vous engager, vérifiez deux choses concrètes : que votre modèle figure bien dans docs/zh/supported_models.md avec le format de quantification que vous visez, et que la page d'installation correspondant à votre accélérateur propose un paquet pour votre version de Python, la fourchette annoncée étant 3.10 à 3.12.
Notes de la communauté