Un seul AI Gateway se place devant un pool de serveurs AI travailleurs. Les applications se connectent à la passerelle avec une URL et une clé uniques, exactement comme s'il s'agissait d'un seul AI Server ; derrière, la passerelle équilibre la charge de chaque requête entre les travailleurs, contrôle la santé de chacun, et redirige le trafic d’un travailleur défaillant vers un travailleur sain avant que l’appelant ne s’en aperçoive [1]. Ce n’est pas un produit distinct. AI Gateway est AI Server fonctionnant en mode front-end de ferme, donc les interfaces compatibles OpenAI /v1/* et compatibles Ollama /api/* exposées par un seul serveur sont exactement celles que la ferme expose [1].
Une URL et une clé uniques, une ferme derrière
La passerelle équilibre tous les types de requêtes que la plateforme sert : chat, embeddings, génération d’images, vision et audio, y compris le WebSocket de parole en direct [1]. Les requêtes sont réparties selon une stratégie que vous choisissez — round-robin, latence minimale, connexions minimales, pondéré ou collant par client. Le routage conscient des modèles envoie une requête à un travailleur qui a déjà le modèle demandé chaud, ce qui évite une pénalité de chargement à froid lorsqu’une machine plus froide aurait autrement pris l’appel [1].
Ajoutez une machine GPU et la capacité augmente ; les clients ne changent rien. Mettez une machine hors service pour maintenance et son trafic se vide en douceur, sans qu’aucune requête en cours ne soit abandonnée. Nous tuons des travailleurs en pleine charge dans notre propre suite de tests pour garantir cette promesse : un travailleur qui meurt est réessayé sur un travailleur sain, et le basculement se fait à l’intérieur de la passerelle avant que le client ne voie une erreur [1][3].
La frontière de confiance qu’introduit une ferme
Une ferme modifie qui détient quelle information d’identification, et la conception maintient cette frontière étanche. La clé de la passerelle du client n’atteint jamais un travailleur. La passerelle présente à chaque travailleur sa propre clé, ainsi une clé de passerelle divulguée ne peut pas être rejouée directement contre un travailleur, et les identifiants par travailleur restent à l’intérieur de la ferme [2]. L’identité de l’appelant, c’est-à-dire quelle application et quelle installation ont émis une requête, est transmise au travailleur. Le journal d’audit sans contenu de chaque travailleur enregistre donc le véritable initiateur plutôt que d’attribuer tout à la passerelle [2].
Rétropression au lieu de délais d’attente
Lorsque chaque travailleur est saturé, la passerelle renvoie un message explicite « réessayez bientôt » plutôt que de maintenir une connexion ouverte jusqu’à expiration [1]. Les appelants reçoivent un signal sur lequel ils peuvent agir. Deux contrôles de déploiement reposent sur la même couche de routage. Une mise en production canari envoie une tranche cohérente de trafic vers de nouvelles machines avant qu’elles ne supportent la charge complète. Une mise à jour sans interruption vide un travailleur, le met à jour, puis le réintègre au pool, le point d’accès restant actif tout au long [1].
Kubernetes sans modification manuelle du pool
Sur Kubernetes, les workers sont découverts automatiquement à mesure qu'ils se mettent à l'échelle, donc une ferme à mise à l'échelle automatique ne nécessite aucune modification manuelle de la liste des workers du gateway [2]. La recette propose trois configurations issues d'un seul produit : Docker Compose pour une démonstration sur une seule machine, des manifests Kubernetes, et un chart Helm pour le cluster. Le produit, les API et la licence sont identiques d’un ordinateur portable à une ferme GPU [2].
Coût d’exploitation d’une ferme
Chaque serveur, y compris le gateway, héberge son propre tableau de bord en temps réel et expose des métriques Prometheus natives pour la santé de la flotte, la latence, l’utilisation et la capacité [3]. La visibilité de la flotte se fait via un seul tableau de bord, et non une pile de surveillance assemblée avant la première requête. Le service réseau reste sécurisé à chaque nœud : une liaison non loopback échoue et ferme la connexion à moins que le nœud ne dispose d’une licence Pro et d’au moins une clé API, ce qui empêche une machine non licenciée ou sans clé de s’exposer silencieusement sur le LAN [1][4].
Une ferme de gateways constitue la topologie garantissant la disponibilité de la plateforme : le point d’accès AI reste opérationnel lorsqu’une machine tombe en panne, et ce, sans passer par un cloud fournisseur dans le chemin de la requête. Elle est licenciée dans le cadre de Pro Commercial et non vendue comme un produit séparé [4].