Escolher um gateway de API de IA não é o mesmo problema de dois anos atrás. Em 2024, a maioria dos desenvolvedores chamava a OpenAI diretamente ou subia o LiteLLM localmente. Agora há opções hospedadas com painéis de preços, limites de crédito por chave e catálogos de modelos que abrangem dezenas de provedores. A categoria cresceu o suficiente para que escolher errado signifique desfazer trabalho real de integração mais tarde.
Este artigo compara quatro gateways que aparecem repetidamente em discussões entre desenvolvedores: CometAPI, Portkey, LiteLLM e Cloudflare AI Gateway. O objetivo não é escolher um vencedor — cada um faz sentido para uma situação diferente — mas explicar o que cada um realmente faz para que você associe a ferramenta ao seu caso de uso.
Nota sobre nomes de modelos: Os identificadores de modelo usados neste artigo (como
gpt-5.4,claude-opus-4-7) são identificadores da plataforma CometAPI. Eles não são nomes oficiais da OpenAI ou da Anthropic, cujas convenções de nomenclatura são diferentes.
O que essas ferramentas realmente fazem
Antes de comparar recursos, vale ser preciso sobre o que um gateway de API de IA faz. No mínimo: ele fica entre seu aplicativo e um ou mais provedores de IA, encaminhando solicitações e retornando respostas. A partir desse mínimo, os gateways divergem significativamente.
Alguns gateways — o Cloudflare AI Gateway, por exemplo — são principalmente uma camada de passagem que adiciona registro e cache sem mexer na sua chave de API ou nos preços. Outros, como o CometAPI, atuam como revendedores: você paga a eles, eles pagam ao provedor subjacente, e a diferença de preço faz parte da proposta de valor. O LiteLLM é diferente de novo — é software que você executa por conta própria, não um serviço hospedado.
Entender essa distinção importa antes de avaliar qualquer recurso específico.
Comparação de recursos
A tabela abaixo usa informações da documentação oficial de cada produto ou do painel público em maio de 2026. Recursos marcados com um traço (—) não estavam confirmados em fontes oficiais no momento da redação.
| Recurso | CometAPI | Portkey | LiteLLM | Cloudflare AI Gateway |
|---|---|---|---|---|
| Implantação | Hospedado (SaaS) | Hospedado + auto-hospedagem | Auto-hospedado (código aberto) | Hospedado (edge da Cloudflare) |
| Catálogo de modelos | 500+ modelos entre provedores | 1,600+ LLMs via API unificada | Depende da sua configuração | OpenAI, Anthropic, Workers AI |
| Modelo de preços | Revenda (você paga à CometAPI) | Repasse + taxa de plataforma | Apenas custo de infraestrutura | Repasse (camada gratuita disponível) |
| API compatível com OpenAI | Sim (api.cometapi.com/v1) | Sim (api.portkey.ai/v1) | Sim (local ou remoto) | Sim (via URL do gateway) |
| Limites de crédito por chave | Sim (painel) | Sim | Sim (via configuração) | — |
| Rácios de preço por grupo | Sim (0.8x padrão, 0.1x interno) | — | — | — |
| Registro de solicitações | Sim (4 tipos de log) | Sim | Sim | Sim |
| Monitoramento da taxa de sucesso | Sim (visão de uptime de 30 dias) | Sim | Sim | Sim |
| Camada gratuita | Sim (novas contas) | Sim | Código aberto (custo de infra) | Sim |
| Opção de auto-hospedagem | Não (enterprise: servidor dedicado) | Sim | Sim (caso de uso principal) | Não |
Fontes: CometAPI dashboard, Portkey homepage, LiteLLM GitHub, Cloudflare AI Gateway documentation
Conectando a cada gateway
Os quatro gateways expõem um endpoint compatível com OpenAI, o que significa que a mesma estrutura de cliente funciona para todos — você muda o base_url, as credenciais e, no caso do Portkey, como especifica o modelo.
Python
import osfrom openai import OpenAIdef require_env(name: str) -> str: """Raise a clear error if a required environment variable is missing.""" val = os.environ.get(name) if not val: raise ValueError(f"Missing required environment variable: {name}") return val# ── CometAPI ────────────────────────────────────────────────────────────────# Hosted reseller with 500+ models. Use CometAPI model identifiers (e.g. "gpt-5.4").cometapi_client = OpenAI( base_url="https://api.cometapi.com/v1", api_key=require_env("COMETAPI_KEY"),)# ── Portkey ─────────────────────────────────────────────────────────────────# Hosted gateway with observability and 1,600+ LLMs.# Route to a provider by prefixing the model name: "@openai/gpt-4o", "@anthropic/claude-3-5-sonnet", etc.# x-portkey-api-key is required; it authenticates requests to Portkey's gateway.portkey_client = OpenAI( base_url="https://api.portkey.ai/v1", api_key=require_env("PORTKEY_API_KEY"), default_headers={ "x-portkey-api-key": require_env("PORTKEY_API_KEY"), },)# ── LiteLLM ──────────────────────────────────────────────────────────────────# Self-hosted proxy. Provider credentials (OPENAI_API_KEY etc.) are set server-side.# By default the proxy does not validate the client API key — "anything" works.# If you have enabled virtual keys on your LiteLLM instance, pass a virtual key instead.litellm_client = OpenAI( base_url=os.environ.get("LITELLM_BASE_URL", "http://localhost:4000"), api_key=os.environ.get("LITELLM_API_KEY", "anything"),)# ── Cloudflare AI Gateway ───────────────────────────────────────────────────# URL-based pass-through. Keep your real provider API key — Cloudflare does not replace it.cf_account_id = require_env("CF_ACCOUNT_ID")cf_gateway_id = require_env("CF_GATEWAY_ID")cloudflare_client = OpenAI( base_url=( f"https://gateway.ai.cloudflare.com/v1" f"/{cf_account_id}/{cf_gateway_id}/openai" ), api_key=require_env("OPENAI_API_KEY"),)def ask(client: OpenAI, model: str, question: str) -> str: """ Minimal wrapper showing the common call pattern across all four gateways. Model format varies by gateway: CometAPI: "gpt-5.4", "claude-opus-4-7", etc. (CometAPI identifiers) Portkey: "@openai/gpt-4o", "@anthropic/claude-3-5-sonnet", etc. LiteLLM: whatever model names you configured in your proxy Cloudflare: standard OpenAI model names, e.g. "gpt-4o" This function does not handle finish_reason, tool_calls, or provider errors. For production error handling, see: How to Debug Failed AI API Generations. """ response = client.chat.completions.create( model=model, messages=[{"role": "user", "content": question}], ) return response.choices[0].message.content or ""
Node.js
import OpenAI from "openai";function requireEnv(name) { const val = process.env[name]; if (!val) throw new Error(`Missing required environment variable: ${name}`); return val;}// ── CometAPI ────────────────────────────────────────────────────────────────const cometClient = new OpenAI({ baseURL: "https://api.cometapi.com/v1", apiKey: requireEnv("COMETAPI_KEY"),});// ── Portkey ─────────────────────────────────────────────────────────────────// Route to a provider by prefixing the model: "@openai/gpt-4o", "@anthropic/claude-3-5-sonnet"const portkeyClient = new OpenAI({ baseURL: "https://api.portkey.ai/v1", apiKey: requireEnv("PORTKEY_API_KEY"), defaultHeaders: { "x-portkey-api-key": requireEnv("PORTKEY_API_KEY"), },});// ── LiteLLM ──────────────────────────────────────────────────────────────────// Self-hosted. Default mode accepts any API key value.// Set LITELLM_BASE_URL if your server runs on a different host or port.const litellmClient = new OpenAI({ baseURL: process.env.LITELLM_BASE_URL ?? "http://localhost:4000", apiKey: process.env.LITELLM_API_KEY ?? "anything",});// ── Cloudflare AI Gateway ───────────────────────────────────────────────────const cfClient = new OpenAI({ baseURL: `https://gateway.ai.cloudflare.com/v1/${requireEnv("CF_ACCOUNT_ID")}/${requireEnv("CF_GATEWAY_ID")}/openai`, apiKey: requireEnv("OPENAI_API_KEY"),});/** * Minimal wrapper showing the common call pattern. * Model format varies by gateway — see Python example above for details. * Does not handle finish_reason or error recovery; add those for production use. */async function ask(client, model, question) { const response = await client.chat.completions.create({ model, messages: [{ role: "user", content: question }], }); return response.choices[0].message.content ?? "";}
O padrão de conexão é o mesmo nos quatro. As diferenças significativas aparecem em outros pontos: o que você pode observar, o que pode controlar e o que acontece quando algo quebra.
Pontos fortes de cada ferramenta
CometAPI
A principal oferta da CometAPI é um catálogo hospedado com mais de 500 endpoints de modelos, incluindo modelos de geração de imagem e vídeo ao lado de modelos de texto. A precificação funciona com um sistema de rácios por grupo — o grupo padrão aplica um multiplicador de 0.8x sobre as tarifas base da CometAPI. Você pode configurar diferentes grupos de rácios para uso interno (0.1x) versus clientes pagantes, o que torna viável construir um produto com camadas sem gerenciar contas separadas.
O painel oferece quatro tipos de logs (chamadas padrão de API, geração de imagens, geração de vídeo, Midjourney), uma visão de uptime de 30 dias e limites de crédito por chave. Os limites de crédito permitem fornecer chaves de API a clientes ou prestadores com um teto rígido de gasto, o que resolve um problema real ao distribuir acesso a uma conta compartilhada.
O que a CometAPI não oferece: auto-hospedagem (clientes enterprise podem solicitar um servidor dedicado, mas isso não é uma opção de auto-hospedagem padrão), limitação de taxa no nível do gateway ou SSO.
Melhor para: Desenvolvedores independentes e pequenas equipes que querem rotear por muitos modelos — incluindo imagem e vídeo — com uma única chave de API e um único relacionamento de cobrança, e que precisam de controles de orçamento por chave.
Portkey
A Portkey é um gateway hospedado construído em torno de observabilidade. Ela dá acesso a 1,600+ LLMs por meio de uma API unificada, com roteamento feito ao prefixar o nome do modelo com o provedor (@openai/gpt-4o, @anthropic/claude-3-5-sonnet). Isso significa que você não precisa de configurações de cliente separadas para cada provedor — um único cliente Portkey atende a todos, e você troca a string do modelo.
Além do roteamento, a Portkey fornece rastreamento de solicitações, versionamento de prompts e roteamento de fallback que você configura no painel em vez de no código. A opção de auto-hospedagem permite executar a Portkey na sua própria infraestrutura, se houver exigências de conformidade.
O repositório do GitHub do gateway open source da Portkey é mantido ativamente — verifique a contagem atual de estrelas diretamente em vez de confiar em qualquer número citado aqui, pois muda com frequência.
Melhor para: Equipes que precisam de trilhas de auditoria, roteamento multi-provedor com uma única configuração de cliente ou que querem gerenciar a exposição de chaves de API entre desenvolvedores.
LiteLLM
O LiteLLM é um pacote Python e um servidor proxy, não um serviço hospedado. Você o executa por conta própria. Esta é uma distinção significativa: não há terceiros tratando suas solicitações ou armazenando suas chaves de API. As credenciais dos provedores (sua chave real da OpenAI, da Anthropic, etc.) são definidas como variáveis de ambiente no servidor; o cliente apenas aponta para o proxy local.
Por padrão, o LiteLLM não valida a chave de API que os clientes enviam — qualquer valor funciona. Se você habilitar a gestão de chaves virtuais, os clientes passam chaves virtuais que o LiteLLM valida contra seu próprio banco de dados. Em ambos os casos, o proxy traduz solicitações no formato OpenAI para o formato que o provedor upstream espera, de modo que seu código de aplicação não muda quando você adiciona um novo provedor.
A contrapartida é a sobrecarga operacional: você é responsável por executar, escalar e atualizar o servidor.
Melhor para: Equipes com capacidade de devops, organizações com restrições de conformidade que proíbem proxies de API de terceiros ou quem quer roteamento entre provedores sem confiar o conteúdo das solicitações a um fornecedor SaaS.
Cloudflare AI Gateway
O Cloudflare AI Gateway é estruturalmente diferente dos outros três. Você não muda sua chave de API nem paga à Cloudflare pelo acesso aos modelos. Em vez disso, você substitui a URL base do provedor por uma URL gerenciada pela Cloudflare que adiciona registro, cache e limitação de taxa na edge.
Como a Cloudflare fica entre seu aplicativo e o provedor, ela pode armazenar em cache solicitações idênticas — útil se seu aplicativo envia os mesmos prompts repetidamente. A camada gratuita cobre a maioria dos casos de desenvolvedores independentes. A limitação é o escopo: a Cloudflare não agrega modelos entre provedores. Você ainda precisa de contas e chaves separadas para cada provedor que usa.
Melhor para: Desenvolvedores que já estão na infraestrutura da Cloudflare ou quem quer cache e registro sobre contas de provedores existentes sem introduzir um novo relacionamento de cobrança ou mudar chaves de API.
Correspondência de cenários
| Cenário | Ferramenta recomendada | Motivo |
|---|---|---|
| App indie, quer testar 10+ modelos com uma chave de API | CometAPI | Catálogo amplo, configuração simples, limites por chave |
| Precisa de geração de imagem + vídeo na mesma integração | CometAPI | Endpoint unificado para modelos de texto, imagem e vídeo |
| Equipe de 5, precisa rastrear quem usa qual modelo | Portkey | Rastreamento de solicitações, gestão de equipe |
| Roteamento para 1,600+ LLMs com uma configuração de cliente | Portkey | Roteamento @provider/model, sem setup por provedor |
| Quer fallback entre provedores sem mudar o código | Portkey | Configuração declarativa de fallback no painel |
| Enterprise com exigências de residência de dados | LiteLLM (auto-hospedado) | Sem terceiros manipulando o tráfego |
| Orçamento zero, confortável em se auto-gerenciar | LiteLLM | Código aberto, sem custo de plataforma |
| Já usa OpenAI diretamente, quer cache | Cloudflare AI Gateway | Apenas troca de URL, sem novo relacionamento de cobrança |
| Precisa de RBAC para várias equipes | Portkey ou LiteLLM | Ambos têm gestão de equipes/papéis; CometAPI e Cloudflare não |
O que estas quatro não cobrem
Esta comparação cobre os gateways que aparecem com mais frequência nas discussões de desenvolvedores independentes. O mercado inclui outras opções que vale conhecer: Helicone foca em observabilidade sem atuar como proxy, OpenRouter se especializa em roteamento para modelos de pesquisa e open-weight, e AWS Bedrock é o serviço gerenciado de IA da Amazon voltado a workloads enterprise. Se seus requisitos não se encaixam em nenhuma das quatro acima, esses são os próximos lugares a olhar.
Fazendo a mudança
Se você atualmente chama um provedor diretamente e considera um gateway, a mudança de código é pequena. Para a CometAPI, você adiciona uma variável de ambiente e muda o base_url. Para a Portkey, você adiciona um header e muda como especifica o modelo (@openai/gpt-4o em vez de gpt-4o). Para a Cloudflare, você muda a URL sem tocar na sua chave de API do provedor. Para o LiteLLM, você executa um servidor local primeiro e depois aponta seu cliente para ele.
A questão maior não é como fazer a mudança, mas se você precisa dela. Se você chama um único provedor, não tem problemas de visibilidade de custo e não precisa de roteamento entre modelos, um gateway adiciona complexidade sem benefício. Se você usa vários provedores, distribui chaves para prestadores ou percebe que contas inesperadas são um problema recorrente, a sobrecarga de integração compensa.
FAQ
Posso usar esses gateways juntos?
Sim. Algumas equipes executam o LiteLLM auto-hospedado para workloads sensíveis e a CometAPI para todo o resto. O Cloudflare AI Gateway pode ficar à frente das requisições para a CometAPI se você quiser a camada de cache da Cloudflare por cima — embora isso adicione um salto de rede.
Esses gateways armazenam minhas prompts?
Depende da ferramenta e da sua configuração. Portkey e CometAPI registram solicitações por padrão; ambas têm configurações de retenção. O LiteLLM só armazena o que você configurar para armazenar, na sua própria infraestrutura. O comportamento de registro da Cloudflare está descrito na documentação do AI Gateway. Leia os termos de privacidade de qualquer serviço hospedado antes de enviar conteúdo sensível por ele.
O que acontece se o gateway ficar fora do ar?
Para gateways hospedados (CometAPI, Portkey, Cloudflare), a indisponibilidade do gateway significa que seu aplicativo não consegue alcançar o provedor de IA por esse caminho. O LiteLLM rodando localmente tem as mesmas características de disponibilidade do seu próprio servidor. Antes de adotar qualquer gateway hospedado em produção, verifique o SLA e se ele oferece fallback direto ao provedor caso o próprio gateway fique indisponível.
Há uma forma gratuita de avaliar cada um antes de me comprometer?
Sim. CometAPI e Portkey têm camadas gratuitas. LiteLLM é open source e custa apenas a infraestrutura que você usar. O Cloudflare AI Gateway é gratuito dentro de limites generosos. Você pode testar os quatro com os mesmos prompts antes de decidir.
Como escolher os nomes de modelo corretos para cada gateway?
Cada gateway tem sua convenção. A CometAPI usa identificadores próprios (gpt-5.4, claude-opus-4-7). A Portkey usa o formato @provider/model-name (@openai/gpt-4o, @anthropic/claude-3-5-sonnet). O LiteLLM usa os nomes de modelo que você definir na configuração do seu proxy. A Cloudflare passa os nomes de modelo padrão do provedor sem alterações. Verifique a documentação de cada gateway para a lista atual de modelos antes de escrever código.
Mudar de gateway afeta meus limites de taxa existentes?
Sim. Se você passar de chamadas diretas à OpenAI para um gateway que gerencia o relacionamento com o provedor (como a CometAPI), seus limites de taxa efetivos são determinados pela conta do gateway com a OpenAI, não pela sua conta pessoal. Verifique o comportamento de limites com o gateway antes de migrar tráfego de produção.
