LiteLLM vs Kong AI Gateway
Ambos são auto-hospedáveis e ambos são open-core. A linha que realmente decide: o seu gateway é um gateway de LLM ou um gateway de API geral que também fala com modelos?
LiteLLM e Kong AI Gateway são comparados porque são as duas opções auto-hospedáveis que a maioria das equipes coloca na lista curta. Eles não são o mesmo tipo de software. O LiteLLM é um proxy de LLM — toda a sua superfície é modelos, provedores e roteamento compatível com OpenAI. O Kong é um gateway de API geral (plugins, upstreams, limite de taxa para tráfego HTTP arbitrário) com plugins de IA acrescentados. Essa diferença determina todas as outras linhas abaixo: entradas de protocolo, granularidade de governança e quanto você tem de construir por conta própria.
Três gateways, cinco critérios
Cada uma das duas primeiras colunas é uma leitura em uma linha da página de comparação correspondente. A coluna GateLLM é a nossa própria posição, não uma avaliação de terceiros — pondere de acordo.
| Critério | LiteLLM | Kong AI Gateway | GateLLM |
|---|---|---|---|
| Implantação | OSS auto-hospedado | OSS auto-hospedado (+ Konnect gerenciado) | Totalmente auto-hospedado (Docker / Helm), sem plano de controle do fornecedor |
| Âncora de cobrança | OSS gratuito; Enterprise com preço por uso | OSS gratuito; plugins restritos ao Enterprise | Licença por instância; sem margem sobre tokens, sem taxa por assento |
| Entradas de protocolo | Centrado em OpenAI | Compatível com OpenAI + plugins de IA | Quatro de entrada x quatro de saída (OpenAI / Anthropic / Gemini / DashScope) |
| Governança | SSO (limite de 5 usuários) / RBAC no Enterprise | RBAC / SSO no Enterprise | SSO / SCIM / RBAC + ACL e tetos de orçamento por grupo de chaves |
| Independência do fornecedor | Independente (BerriAI) | Independente (Kong Inc.) | Independente (Fluxon LLC) |
Quando LiteLLM, quando Kong, quando nenhum
Escolha o LiteLLM se o tráfego que você governa é tráfego de modelos e nada mais: roteamento por modelo, fallback de provedores e atribuição de custos sem aprender uma DSL de plugins, e você se sente confortável em operar um serviço Python. É o caminho mais curto de "chamar muitos provedores" para "chamar muitos provedores por um único endpoint".
Escolha o Kong se você já usa o Kong para tráfego de API não-LLM. Reutilizar o gateway que você tem — seus plugins, seu limite de taxa, seus runbooks operacionais — geralmente vale mais do que introduzir um segundo gateway só para IA. Os plugins de IA são a metade menor dessa decisão.
Nenhum dos dois, se um único provedor, uma única equipe e uma conta mensal administrável forem a sua situação real. Chamar a API do provedor diretamente é mais simples do que qualquer das opções, e nenhum gateway justifica seu custo operacional até você precisar de failover entre vários provedores, atribuição de custos por equipe ou controles de conformidade que o provedor não consegue dar.