Paddler : équilibrer la charge d'un parc llama.cpp sans orchestration lourde
Open-source LLM/VLM load balancer and serving platform for self-hosting LLMs (and VLMs) at scale 🏓🦙 Alternative to projects like llm-d, Docker Model Runner, etc but with less moving parts and simple deployments built around ggml ecosystem. Runs on CPU and GPU.
En bref
- De quoi s’agit-il ?
- Paddler est un répartiteur de charge et une plateforme de service pour LLM et VLM auto-hébergés, écrit en Rust, articulé autour de deux composants seulement : un balancer et des agents. Le projet vise les équipes qui veulent un cluster d'inférence ggml sans la machinerie d'un orchestrateur complet.
- À qui s’adresse-t-il ?
- Paddler convient aux équipes qui possèdent déjà des machines et veulent servir du ggml derrière une seule adresse, avec un binaire et deux composants à lancer. Il ne convient pas à celles qui attendent un ordonnanceur multi-modèles sophistiqué ou un support d'autres moteurs que llama.cpp : le README ne mentionne rien de tel.
- 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 58 jours.
- En quel langage est-il écrit ?
- Principalement Rust, 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
Un répartiteur pensé pour le parc de machines que vous avez déjà
Le problème visé est concret : plusieurs machines capables de faire tourner un modèle ggml, et aucune envie de monter Kubernetes ou un ordonnanceur de plus pour les relier. Le README énumère les publics : équipes produit qui ont besoin d'inférence et d'embeddings dans leurs fonctionnalités, équipes DevOps ou LLMOps qui déploient à l'échelle, organisations soumises à des exigences de conformité et de confidentialité, et structures qui préfèrent un coût d'infrastructure prévisible à une facturation au token. La promesse tient en une phrase du README : une alternative à des projets comme llm-d ou Docker Model Runner, avec moins de pièces mobiles et des déploiements simples autour de l'écosystème ggml. C'est un positionnement par soustraction, pas par accumulation de fonctionnalités. Le projet s'adresse donc à un lecteur qui a déjà du matériel et qui cherche la couche de distribution, pas la couche d'orchestration.
Balancer, agents, slots : trois niveaux et deux binaires à déployer
L'architecture décrite dans le README tient en trois niveaux. Le balancer expose trois services distincts : le service d'inférence, que les applications clientes appellent pour obtenir des tokens ou des embeddings, le service de gestion, qui pilote la flotte en interne, et le panneau web d'administration. Les agents, eux, sont déployés sur des instances séparées et redistribuent les requêtes reçues vers des slots. Ce sont ces slots qui génèrent réellement tokens et embeddings. Point important : Paddler embarque le moteur llama.cpp, mais le README précise qu'il utilise sa propre implémentation des slots llama.cpp, chacun conservant son propre contexte et son propre cache KV. Le flux est donc linéaire : l'application parle au balancer, le balancer choisit un agent, l'agent choisit un slot, le slot infère. Les agents peuvent être ajoutés dynamiquement, ce que le README présente comme le point d'intégration avec des outils d'autoscaling. Deux autres mécanismes méritent d'être notés parce qu'ils changent la topologie : la mise en tampon des requêtes, qui permet selon le README de démarrer depuis zéro hôte, et la permutation dynamique de modèle.
Démarrer un cluster avec deux commandes
Le README donne les commandes exactes. Pour le balancer : paddler balancer --inference-addr 127.0.0.1:8061 --management-addr 127.0.0.1:8060 --web-admin-panel-addr 127.0.0.1:8062. Le drapeau --web-admin-panel-addr est optionnel, mais il ouvre l'interface dans un navigateur. Pour un agent avec quatre slots : paddler agent --management-addr 127.0.0.1:8060 --slots 4. L'agent pointe donc vers l'adresse de gestion du balancer, pas vers l'adresse d'inférence. Le binaire s'obtient de deux façons selon le README : télécharger la dernière release depuis GitHub, ou compiler depuis les sources, avec une MSRV de 1.88.0. Toute la fonctionnalité passe par la commande paddler, et paddler --help liste les sous-commandes disponibles. Le README renvoie aussi vers une page installation et une page de mise en place d'un cluster de base sur paddler.intentee.com, ainsi qu'une documentation d'API. Ce que le matériel fourni ne dit pas : comment un agent découvre un modèle, où se configure le chemin des poids, ni comment le balancer choisit entre deux agents disponibles. Ces réponses sont derrière les liens, pas dans le README.
Ce que le dépôt ne permet pas de conclure
Il faut le dire franchement : la description du dépôt et le README ne documentent pas la politique d'équilibrage. Le terme employé est LLM-specific load balancing, sans détail sur le critère retenu, nombre de slots libres, longueur de file, occupation du cache KV, ou autre. De même, la mise en tampon des requêtes est annoncée comme permettant de démarrer depuis zéro hôte, mais le comportement d'une requête pendant qu'aucun agent n'est présent (attente, expiration, code d'erreur) n'est pas décrit dans le matériel fourni. Autre limite structurelle : le moteur est llama.cpp, et rien n'indique qu'un autre backend soit pris en charge. Une équipe qui a standardisé son service sur vLLM ou sur un runtime d'inférence différent devra changer de moteur ou renoncer à Paddler. Enfin, l'écosystème ggml impose ses formats de modèles et ses contraintes de quantification. Ce sont des choix cohérents avec le positionnement, mais qui délimitent l'outil autant qu'ils le définissent.
Panneau web, application de bureau et fonctionnalités annexes
Le panneau web d'administration n'est pas un simple tableau de bord. Le README indique qu'il sert à surveiller la flotte, à ajouter et mettre à jour un modèle, à personnaliser le template de chat et les paramètres d'inférence, et à tester l'inférence depuis une interface graphique. Les captures illustrent trois écrans : tableau de bord, section modèle, section prompt. Il existe par ailleurs une application de bureau en version bêta, présentée comme une alternative à la ligne de commande pour des usages moins formels : un cluster local réparti sur plusieurs portables et PC, ou un second cerveau d'entreprise à l'échelle d'un bureau. Le README décrit même un scénario mixte : un balancer dans une baie, et un collègue avec une RTX 5090 qui branche sa machine comme agent quand il n'a pas besoin de tout son calcul. Les deux versions peuvent cohabiter. Côté fonctionnalités d'inférence, la documentation liée depuis le README couvre la génération de tokens et d'embeddings, le function calling, les grammaires et les modèles multimodaux. Le projet se présente donc comme un service LLM et VLM, pas uniquement texte.
Face à un orchestrateur généraliste
L'alternative la plus évidente est un orchestrateur de conteneurs avec un serveur d'inférence derrière un service. La différence n'est pas la fonction, c'est le nombre d'objets à maintenir. Avec Paddler, le README annonce un binaire autonome et deux composants déployables, le balancer et l'agent. Un déploiement Kubernetes suppose un plan de contrôle, des définitions de charges de travail, un équilibreur de charge réseau, et une couche de supervision. Paddler intègre dans le même binaire le service d'inférence, la gestion de flotte, des métriques d'observabilité et un panneau d'administration. Le compromis est net : vous gagnez en simplicité de déploiement, vous perdez la richesse d'un écosystème d'orchestration, la reprise après sinistre outillée et la portabilité multi-moteurs. Le README cite llm-d et Docker Model Runner comme points de comparaison, en revendiquant moins de pièces mobiles. Cette revendication est cohérente avec la structure décrite, mais elle reste une affirmation du projet, pas un résultat mesuré dans le matériel fourni.
Maintenance, licence et coût de mise à jour
Le dépôt est actif : dernière poussée le 19 juillet 2026, version 4.1.0 publiée le même jour, avec une rc1 une semaine plus tôt et une 4.0.1 début juillet. Le rythme de publication est donc soutenu, ce qui a une contrepartie : une version mineure tous les quelques mois signifie relire les notes de version avant de mettre à jour un cluster en production. La MSRV de 1.88.0 concerne la compilation depuis les sources ; si vous utilisez les binaires publiés, elle ne vous concerne pas. Le projet est sous Apache-2.0, une licence permissive qui autorise l'usage commercial et la modification, avec les obligations habituelles de conservation des mentions de licence et d'état des modifications. Ce paragraphe n'est pas un conseil juridique : pour un usage en entreprise, faites relire la licence et vérifier les licences des dépendances. Un point de gouvernance à garder en tête : le README consacre une section à l'acceptation de code généré par IA, en précisant que tout le code est relu par des humains et que la majorité est écrite à la main, avec des expérimentations réussies sur le client HTTP et sur un harnais de tests d'intégration. C'est une information utile pour juger la politique de contribution, pas une garantie de qualité.
Conclusion éditoriale
Paddler convient aux équipes qui possèdent déjà des machines et veulent servir du ggml derrière une seule adresse, avec un binaire et deux composants à lancer. Il ne convient pas à celles qui attendent un ordonnanceur multi-modèles sophistiqué ou un support d'autres moteurs que llama.cpp : le README ne mentionne rien de tel. Avant de vous engager, vérifiez la page installation de paddler.intentee.com et la commande paddler --help de la version que vous téléchargez, car la documentation liée depuis le dépôt n'est pas reproduite ici.
Notes de la communauté