FAQ passerelle IA

Seulement si la passerelle est licenciée par instance plutôt que margée sur les tokens. GateLLM est licencié par instance de 2 Go (Pro 400 $/mois) — jamais de marge par token, aucun supplément de plateforme ou de paiement ; vous payez les fournisseurs aux tarifs standard. Les vraies économies viennent de la Composition : un modèle de pointe (Claude Opus) planifie pendant que des modèles SOTA ouverts (GLM / Qwen / DeepSeek) exécutent — à ~1/7 du coût. Les agrégateurs SaaS ajoutent généralement ~5 à 8 % de frais de plateforme + paiement : un coût caché significatif à volume.

Critère honnête : un seul fournisseur, une seule équipe, aucune contrainte de conformité, une dépense mensuelle maîtrisée — appeler les API directement est plus simple et vous n’avez pas besoin de passerelle. Une passerelle commence à être rentable lorsque vous avez besoin de bascule multi-fournisseurs, d’imputation des coûts par équipe, de conformité / résidence des données, ou de visibilité en temps réel sur les dépenses incontrôlées. N’en adoptez pas une avant d’en avoir réellement besoin.

L’appel direct à un seul fournisseur est un point de défaillance unique — une panne met toute votre application à terre. GateLLM prend en charge le repli entre fournisseurs : lorsque le principal renvoie une 5xx ou expire, le trafic bascule vers un fournisseur de secours sans modification de code. Séparément, pour les appels à enjeux élevés, vous pouvez lancer une revue de code multi-modèles dans votre couche d’orchestration (par exemple une revue parallèle GitHub Actions) — la passerelle fournit l’interopérabilité protocolaire pour que plusieurs modèles vérifient la même requête.

Une passerelle SaaS ajoute un saut supplémentaire hors de votre réseau. GateLLM est auto-hébergé dans votre VPC ; le saut supplémentaire vers l’API du fournisseur est une communication inter-processus locale — une surcharge inférieure à la milliseconde, avec un impact négligeable sur le délai du premier token en diffusion.

Oui. La Composition de GateLLM prend en charge une politique selon le mode : les administrateurs verrouillent les paliers plan / exécution — modèles fermés de pointe pour la planification, SOTA ouverte pour l’exécution — pour ~97 % de capacité à ~14 % du coût. Vous pouvez aussi classer selon le nombre de tokens ou la complexité pour router dynamiquement, évitant de tout envoyer sur le modèle le plus cher.

Un mauvais proxy le fait : il tamponne le flux, casse les fragments JSON de tool_calls ou trébuche sur les différences de format d’appel d’outils entre fournisseurs. GateLLM transmet les flux nativement sans tampon et assure la normalisation des capacités — unifiant l’appel d’outils, les sorties structurées, le cache de prompts, les tokens de raisonnement et trois autres points de couplage entre fournisseurs derrière une seule interface, afin que le mélange de modèles ne casse jamais sur une dérive de format.

Un relais transmet vos requêtes via ses propres serveurs — vos prompts, clés et sorties lui sont tous exposés, avec de vrais risques de substitution de modèle, de dégradation ou de fuite de l’opérateur (une étude du CISPA a relevé des échecs de vérification d’identité dans 45,83 % des tests d’empreinte de modèle, arxiv.org/abs/2603.01919). GateLLM est BYOK et auto-hébergé : les clés résident uniquement en mémoire de la passerelle, les requêtes vont directement aux API des fournisseurs, aucun tiers dans le chemin — aucune place pour substituer, dégrader ou disparaître.

Oui. GateLLM se déploie entièrement dans votre réseau — les données ne sortent jamais, ce qui satisfait la conformité à l’exportation des données. Il parle nativement le protocole DashScope pour atteindre les modèles nationaux (Tongyi / Zhipu / DeepSeek / Doubao). Le trafic des modèles fermés est réduit via la Composition, ce qui diminue les appels transfrontaliers.

Les factures mensuelles arrivent trop tard. Token Ops de GateLLM impute le coût par requête — par équipe / agent / modèle / client — avec une visibilité en temps réel sur le rythme de consommation et des plafonds budgétaires par agent qui arrêtent réellement les appels. La facturation résistante aux plantages (pré-débit → règlement → remboursement) reste correcte malgré les plantages de processus ; l’API de gestion exporte les données de rapprochement vers votre système de facturation interne.

Avec un agrégateur SaaS, vous ne pouvez que lui faire confiance — aucune vérification cryptographique ne prouve qu’il ne glisse pas discrètement un modèle plus petit pour garder la marge (OpenRouter lui-même ne vérifie pas l’identité des modèles). GateLLM est BYOK et auto-hébergé : vous utilisez vos propres clés et les requêtes vont de votre passerelle directement au point de terminaison de l’API du fournisseur — l’identité du modèle est garantie par l’API du fournisseur elle-même, sans saut remplaçable entre les deux.

Oui. Pointez le base_url de votre SDK OpenAI vers GateLLM (avec /v1) — aucun autre changement de code — et appelez tous les modèles via une interface unifiée. Un seul remplacement de base_url suffit à migrer : aucune dérive de fonctionnalité, aucune cale de proxy — votre client OpenAI pilote directement un point de terminaison unifié équivalent au fournisseur.

Non — une seule passerelle sert les trois. Pointez le base_url du SDK OpenAI vers la passerelle (avec /v1) ; pointez le SDK Anthropic vers la racine de la passerelle (le SDK ajoute lui-même /v1/messages, clé via l’en-tête x-api-key) ; le SDK Google Gemini se connecte directement (clé via l’en-tête x-goog-api-key). La passerelle traduit dans les deux sens entre quatre protocoles d’entrée + quatre de sortie (OpenAI / Anthropic / Gemini / DashScope) — les protocoles client et amont peuvent différer : appelez Claude depuis le SDK OpenAI, GPT depuis le SDK Anthropic, ou DeepSeek depuis le SDK Gemini sans aucun changement de code ; des clients tiers comme Cherry Studio utilisent l’entrée compatible OpenAI. Voir la matrice d’interopérabilité des protocoles sur docs.gatellm.io reference/protocol-matrix.

Oui. Bedrock se connecte comme amont (protocole aws_converse / aws_invoke, clé API Bedrock + point de terminaison régional d’exécution, profils d’inférence pris en charge) ; les clients continuent d’utiliser les SDK OpenAI / Anthropic / Gemini et la passerelle traduit le protocole. Les Claude / GLM hébergés sur Bedrock et les modèles de fournisseurs directs peuvent se mélanger dans le même routage / répartiteur de charge sous un seul plan de gouvernance.

Oui. La passerelle dispose d’un proxy MCP intégré : il agrège plusieurs serveurs d’outils MCP externes (HTTP streamable / SSE) derrière un point de terminaison /mcp unique, de sorte que Claude Desktop ou tout client MCP les appelle tous avec une seule clé de passerelle. Les ACL d’outils par groupe de clés et les budgets de contexte gouvernent l’accès, avec une recherche BM25 intégrée lorsque la liste d’outils s’allonge. L’admission des outils, la limitation de débit et l’audit partagent le même plan de gouvernance que le trafic des modèles.

Oui. La passerelle fait le pont pour les sessions WebSocket sur /v1/realtime (protocoles OpenAI Realtime et DashScope Realtime). Les sessions vocales longue durée s’exécutent en parallèle du trafic HTTP : même authentification et admission par clé, mesure par tour (response.create → response.done) dans le même pipeline de statistiques / facturation / journaux que le HTTP — un grand livre de coûts cohérent.

Cinq couches : les groupes de clés délimitent les modèles et répartiteurs de charge que chaque locataire peut atteindre ; les clés d’accès + les règles Header ACL distinguent les clients par en-tête de requête ; le mappage de modèles par identité route un même nom de modèle vers des amonts différents selon le locataire ; les limites RPM / concurrence / TPM par clé plafonnent l’usage ; et l’imputation du coût par requête fait que chaque locataire ne voit que ses propres dépenses. Voir le guide d’isolation multi-locataire sur docs.gatellm.io usecases/multi-tenant-isolation.

Oui. GateLLM détourne la recherche au niveau de la passerelle : configurez un moteur de recherche (serper, testable directement dans la console), puis des bascules à trois positions par modèle (suivre la capacité / forcer / désactiver) contrôlent l’injection. Les résultats sont synthétisés en blocs de recherche natifs selon le protocole du client (Anthropic server_tool_use / OpenAI url_citation / Responses web_search_call) — les modèles ouverts bénéficient aussi de l’ancrage par recherche. Les échecs de recherche se dégradent gracieusement sans bloquer les requêtes, et la recherche détournée est exclue de la facturation à l’usage. Voir console/search sur docs.gatellm.io.

Oui. Un amont peut contenir plusieurs clés API avec une distribution pondérée : un hachage pondéré déterministe (FNV-1a) lie chaque appelant à la même clé (affinité de cache), et lorsqu’une clé échoue la passerelle réessaie avec la clé suivante non essayée dans cet amont. Les clés de poids 0 sont en veille — utilisées seulement après l’échec de toutes les clés de poids >0. L’état de liaison est observable ligne par ligne dans la console. Voir reference/upstreams-models-fields sur docs.gatellm.io.

Oui. Tout point de terminaison compatible OpenAI fonctionne comme amont : définissez une URL de base personnalisée et les services vLLM / Ollama / TGI sont gouvernés aux côtés des fournisseurs cloud. Les proxys sortants (socks5 / http), les en-têtes de requête personnalisés et le DNS par amont sont tous configurables pour les réseaux privés et les topologies particulières.

Aucun YAML requis. GateLLM fournit une console visuelle : amonts / modèles / répartiteurs de charge / contrôle d’accès / MCP / statistiques / journaux se configurent tous dans l’interface, avec bascule instantanée chinois/anglais. Les changements par lots suivent préparer → prévisualiser (ensemble complet des conflits d’espace de noms) → validation atomique, avec annulation de tout le lot au moindre conflit. Les comptes de la console ont des rôles administrateur / superviseur (lecture seule), et chaque opération et connexion est auditée.

LiteLLM est un excellent proxy LLM open source. GateLLM et LiteLLM partagent une base de capacités commune (routage, appel d’outils, sorties structurées, mise en cache, SSO via OIDC + SAML 2.0 + SCIM). Les différenciateurs de GateLLM sont le binaire Rust unique, les 15 formes de protocoles (les 4 familles de protocoles de chat se traduisent de tout vers tout, le reste selon la matrice d’interopérabilité), l’injection automatique du cache côté passerelle et une console sans YAML ; LiteLLM mène sur son écosystème entreprise (gestionnaires de secrets, callbacks de guardrails tiers, callbacks d’observabilité). Voir /compare/litellm.

Oui. Entièrement auto-hébergé dans votre VPC ; clés BYOK en mémoire uniquement, jamais sur disque ; SSO entreprise (OIDC : Azure AD / Okta / générique, plus SAML 2.0 et provisionnement automatique SCIM 2.0) ; journaux d’audit au niveau de la requête, exportables ; prêt pour le RGPD ; contrôles SOC 2 Type II / ISO 27001 alignés (certification en préparation). Voir /security.

Dans Console → Paramètres → Facturation, créez un instantané de prix manuel pour le modèle — il est marqué comme épinglé (badge jaune). Un prix épinglé devient courant et masque la base automatique en dessous ; les actualisations du système ignorent ce modèle et n’écrasent jamais votre prix manuel. Le supprimer revient à la ligne automatique suivante et se répare de lui-même.

Non. Les instantanés de prix sont ordonnés par created_at et chacun ne couvre que sa propre fenêtre [date propre, date suivante) — le plus ancien remplit l’historique, le plus récent s’étend indéfiniment vers l’avenir. Créez un nouvel instantané avec une date d’effet future pour planifier la baisse afin qu’elle n’affecte que les mois suivants, ou remplissez un prix historique pour chiffrer précisément les mois passés.

Définissez un quota de coût quotidien / mensuel (montant en USD) sur la clé d’accès — deux cycles indépendants évalués sur le jour et le mois calendaires UTC, renvoyant 429 quota_exceeded et arrêtant le service dès que l’un ou l’autre est atteint (la fenêtre quotidienne porte Retry-After). Les quotas héritent de clé → groupe → global ; un quota de groupe est un plafond par clé au sein du groupe (pas un grand livre partagé), et entre les groupes le plus large l’emporte.