LiteLLM vs Kong AI Gateway
Les deux sont auto-hébergeables et les deux sont open-core. La ligne qui tranche vraiment : votre passerelle est-elle une passerelle LLM, ou une passerelle API générale qui parle aussi aux modèles ?
LiteLLM et Kong AI Gateway sont comparés parce qu’ils sont les deux options auto-hébergeables que la plupart des équipes présélectionnent. Ce ne sont pas le même type de logiciel. LiteLLM est un proxy LLM — toute sa surface est faite de modèles, de fournisseurs et de routage compatible OpenAI. Kong est une passerelle API générale (plugins, amonts, limitation de débit pour du trafic HTTP arbitraire) à laquelle des plugins IA ont été ajoutés. Cette différence entraîne toutes les autres lignes ci-dessous : points d’entrée protocolaires, granularité de la gouvernance et part de ce que vous devez construire vous-même.
Trois passerelles, cinq critères
Chacune des deux premières colonnes est une lecture en une ligne de la page de comparaison correspondante. La colonne GateLLM est notre propre position, pas une évaluation tierce — pesez-la en conséquence.
| Critère | LiteLLM | Kong AI Gateway | GateLLM |
|---|---|---|---|
| Déploiement | OSS auto-hébergé | OSS auto-hébergé (+ Konnect managé) | Entièrement auto-hébergé (Docker / Helm), sans plan de contrôle fournisseur |
| Ancrage de la facturation | OSS gratuit ; Enterprise facturé à l’usage | OSS gratuit ; plugins réservés à Enterprise | Licence par instance ; sans marge sur les tokens, sans frais par siège |
| Points d’entrée protocolaires | Centré OpenAI | Compatible OpenAI + plugins IA | Quatre entrées x quatre sorties (OpenAI / Anthropic / Gemini / DashScope) |
| Gouvernance | SSO (plafond 5 utilisateurs) / RBAC dans Enterprise | RBAC / SSO dans Enterprise | SSO / SCIM / RBAC + ACL et plafonds budgétaires par groupe de clés |
| Indépendance du fournisseur | Indépendant (BerriAI) | Indépendant (Kong Inc.) | Indépendant (Fluxon LLC) |
Quand LiteLLM, quand Kong, quand aucun des deux
Choisissez LiteLLM si le trafic que vous gouvernez est du trafic de modèles et rien d’autre : routage par modèle, repli entre fournisseurs et imputation des coûts sans apprendre un DSL de plugins, et si vous êtes à l’aise avec l’exploitation d’un service Python. C’est le chemin le plus court de « appeler de nombreux fournisseurs » à « appeler de nombreux fournisseurs via un seul point de terminaison ».
Choisissez Kong si vous exploitez déjà Kong pour du trafic API non-LLM. Réutiliser la passerelle que vous avez — ses plugins, sa limitation de débit, ses runbooks d’exploitation — bat généralement l’introduction d’une seconde passerelle rien que pour l’IA. Les plugins IA sont la moitié la moins importante de cette décision.
Aucun des deux, si un seul fournisseur, une seule équipe et une facture mensuelle maîtrisée correspondent à votre situation réelle. Appeler directement l’API du fournisseur est plus simple que l’une ou l’autre option, et aucune passerelle ne justifie son coût d’exploitation tant que vous n’avez pas besoin de bascule multi-fournisseurs, d’imputation des coûts par équipe ou de contrôles de conformité que le fournisseur ne peut pas vous donner.