busbar

Busbar agit comme une frontière d’application exploitée par le client pour les systèmes d’IA, plutôt qu’un reverse proxy générique. Il se place dans le chemin des requêtes entre les applications et agents d’IA, et les destinations en aval, notamment les fournisseurs de LLM, les outils MCP et les agents A2A, ce qui permet aux opérateurs de vérifier, gouverner, router et enregistrer les appels de modèles, l’usage d’outils et la délégation d’agents avant que les requêtes n’atteignent les destinations approuvées. Le projet est entièrement auto-hébergé, sans service hébergé managé, sans inscription obligatoire et sans comportement sortant de type phone-home ; tous les identifiants des fournisseurs restent dans l’infrastructure de l’opérateur, à la frontière d’application. Il prend en charge nativement six protocoles filaires de LLM en entrée comme en sortie : OpenAI, OpenAI Responses, Anthropic, Gemini, Cohere et Bedrock Converse, couvrant les 36 paires possibles de protocoles entrée-vers-amont. Les routes de même protocole transmettent directement les octets de la requête d’origine, offrant une parité octet pour octet avec les appels directs aux fournisseurs, tandis que les routes inter-protocoles traduisent les champs de requête pour correspondre au format natif du fournisseur cible. L’intégration côté client ne nécessite que de changer l’URL de base et la clé API pour pointer vers une instance Busbar, sans modifier les workflows existants des SDK natifs. Le déploiement est conçu pour minimiser la charge opérationnelle : Busbar est distribué sous forme d’un binaire Rust statique unique, sans interpréteur, base de données ou sidecar séparé, ou sous forme d’une petite image de conteneur compressée. La configuration est définie dans un seul fichier YAML, avec une commande intégrée de validation de configuration qui s’exécute sans accès réseau ni serveur en cours d’exécution, adaptée à une inclusion dans des pipelines CI. Des charts Helm officiels sont fournis pour un déploiement Kubernetes, avec des valeurs par défaut de sécurité renforcées, notamment une exécution non-root, un système de fichiers racine en lecture seule et la suppression des capacités Linux inutiles. Les capacités opérationnelles principales incluent des pools de modèles pondérés avec limites de concurrence par voie, des disjoncteurs attribués aux fautes et un basculement en vol qui change de fournisseur avant que le premier octet de réponse n’atteigne le client, même pour les requêtes en streaming. Les contrôles de gouvernance intégrés incluent des clés API virtuelles, des budgets et un suivi des dépenses au niveau des groupes, la prise en charge native de TLS et mTLS, la télémétrie Prometheus et OTLP, et des webhooks d’audit par requête. Le modèle plus large de frontière d’exécution du projet étend ce même schéma d’application à la gouvernance des outils MCP (autorisations d’appelant, schémas approuvés, application des budgets, quarantaine en cas de dérive) et à la confiance des agents A2A (vérification, épinglage, contrôle de sortie, identifiants liés à la cible). Le projet publie des mesures de performance pour sa propre implémentation, notamment une latence ajoutée p50 de 73 microsecondes, 67 837 requêtes par seconde soutenues sans échec, 7,3 MiB de mémoire résidente au repos et une image de conteneur compressée de 5,74 MiB, avec des comparaisons publiques avec d’autres outils courants de passerelle d’IA et de passerelle API générale. Le projet est publié sous licence Apache 2.0, avec un contrat stable SemVer pour sa surface HTTP du plan de données et les contrats de protocoles filaires pris en charge entre versions majeures.