FAQ do AI Gateway

Só se o gateway for licenciado por instância em vez de cobrar margem sobre tokens. O GateLLM é licenciado por instância de 2GB (Pro $400/mês) — nunca uma margem por token, sem sobretaxa de plataforma ou de pagamento; você paga aos provedores as tarifas padrão. A economia real vem da Composição: um modelo de primeira linha (Claude Opus) planeja enquanto modelos SOTA abertos (GLM / Qwen / DeepSeek) executam — a ~1/7 do custo. Agregadores SaaS normalmente acrescentam ~5–8% de taxas de plataforma + pagamento: um custo oculto relevante em volume.

Critério honesto: um único provedor, uma única equipe, nenhuma exigência de conformidade, gasto mensal administrável — chamar as APIs diretamente é mais simples e você não precisa de um gateway. Um gateway começa a se pagar quando você precisa de failover entre vários provedores, atribuição de custos por equipe, conformidade / residência de dados ou visibilidade em tempo real de gastos descontrolados. Não adote um antes de realmente precisar.

Chamar diretamente um único provedor é um ponto único de falha — uma indisponibilidade derruba todo o seu app. O GateLLM suporta fallback entre provedores: quando o primário retorna 5xx ou dá timeout, o tráfego vai para um provedor reserva sem alteração de código. Separadamente, para chamadas de maior risco você pode executar uma revisão de código multi-modelo na sua camada de orquestração (por exemplo, revisão paralela no GitHub Actions) — o gateway fornece a interoperabilidade de protocolo para que vários modelos verifiquem a mesma requisição.

Um gateway SaaS adiciona um salto extra para fora da sua rede. O GateLLM é auto-hospedado dentro do seu VPC; o salto extra até a API do fornecedor é comunicação local entre processos — sobrecarga inferior a um milissegundo, com impacto desprezível no tempo até o primeiro token em streaming.

Sim. A Composição do GateLLM suporta política ciente do modo: os admins travam as camadas de planejar / executar — modelos fechados de primeira linha para planejamento, SOTA aberto para execução — para ~97% da capacidade a ~14% do custo. Você também pode classificar por contagem de tokens ou complexidade para rotear dinamicamente, evitando que todo o tráfego vá para o modelo mais caro.

Um proxy ruim quebra: ele faz buffer do stream, rompe fragmentos JSON de tool_calls ou tropeça nas diferenças de formato de chamada de ferramentas entre fornecedores. O GateLLM repassa streams nativamente sem buffer e faz normalização de capacidades — unificando chamada de ferramentas, saída estruturada, cache de prompt, tokens de raciocínio e outros três pontos de acoplamento entre fornecedores atrás de uma interface, para que a mistura de modelos entre fornecedores nunca quebre por deriva de formato.

Um relay encaminha suas requisições pelos servidores dele — seus prompts, chaves e saídas ficam todos expostos a ele, com riscos reais de substituição de modelo, degradação ou fuga do operador (um estudo do CISPA encontrou falhas de verificação de identidade em 45,83% dos testes de impressão digital de modelos, arxiv.org/abs/2603.01919). O GateLLM é BYOK e auto-hospedado: as chaves vivem apenas na memória do gateway, as requisições vão direto para as APIs dos fornecedores, sem terceiros no caminho — não há espaço para substituir, degradar ou desaparecer.

Sim. O GateLLM é implantado totalmente dentro da sua rede — os dados nunca saem, atendendo à conformidade de exportação de dados. Ele fala nativamente o protocolo DashScope para alcançar modelos domésticos (Tongyi / Zhipu / DeepSeek / Doubao). O tráfego para modelos fechados é reduzido pela Composição, cortando chamadas transfronteiriças.

Faturas mensais chegam tarde demais. O Token Ops do GateLLM atribui custo por requisição — por equipe / agente / modelo / cliente — com visibilidade de taxa de consumo em tempo real e tetos de orçamento por agente que realmente interrompem chamadas. A cobrança à prova de falhas (pré-débito → fechamento → estorno) permanece correta mesmo com falhas de processo; a API de Gerenciamento exporta dados de conciliação para o seu sistema interno de cobrança.

Com um agregador SaaS você só pode confiar na palavra dele — não há verificação criptográfica de que ele não esteja trocando silenciosamente por um modelo menor para embolsar a margem (o próprio OpenRouter não faz verificação de identidade de modelo). O GateLLM é BYOK e auto-hospedado: você usa suas próprias chaves e as requisições vão do seu gateway diretamente para o endpoint da API do fornecedor — a identidade do modelo é garantida pela própria API do fornecedor, sem nenhum salto substituível no meio.

Sim. Aponte o base_url do seu SDK OpenAI para o GateLLM (com /v1) — nenhuma outra alteração de código — e chame todos os modelos por uma interface unificada. Uma troca de base_url conclui a migração: sem deriva de recursos, sem camada de proxy — seu cliente OpenAI fala diretamente com um endpoint unificado equivalente ao do fornecedor.

Não — um único gateway atende aos três. Aponte o base_url do SDK OpenAI para o gateway (com /v1); aponte o SDK Anthropic para a raiz do gateway (o SDK acrescenta /v1/messages por conta própria, chave pelo cabeçalho x-api-key); o SDK Google Gemini se conecta diretamente (chave pelo cabeçalho x-goog-api-key). O gateway traduz bidirecionalmente entre quatro protocolos de entrada + quatro de saída (OpenAI / Anthropic / Gemini / DashScope) — os protocolos do cliente e do upstream podem diferir: chame Claude pelo SDK OpenAI, GPT pelo SDK Anthropic ou DeepSeek pelo SDK Gemini sem alteração de código; clientes de terceiros como o Cherry Studio usam a entrada compatível com OpenAI. Veja a matriz de interoperabilidade de protocolos em docs.gatellm.io reference/protocol-matrix.

Sim. O Bedrock se conecta como upstream (protocolo aws_converse / aws_invoke, chave de API do Bedrock + endpoint de runtime regional, perfis de inferência suportados); os clientes continuam usando os SDKs OpenAI / Anthropic / Gemini e o gateway traduz o protocolo. Claude / GLM hospedados no Bedrock e modelos diretos de fornecedores podem se misturar no mesmo roteamento / balanceador de carga sob um único plano de governança.

Sim. O gateway tem um proxy MCP integrado: ele agrega vários servidores externos de ferramentas MCP (HTTP streamable / SSE) atrás de um único endpoint /mcp, para que o Claude Desktop ou qualquer cliente MCP chame todos com uma única chave do gateway. ACLs de ferramentas por grupo de chaves e orçamentos de contexto governam o acesso, com busca BM25 integrada quando a lista de ferramentas fica longa. Admissão de ferramentas, limite de taxa e auditoria compartilham o mesmo plano de governança do tráfego de modelos.

Sim. O gateway faz ponte de sessões WebSocket em /v1/realtime (protocolos OpenAI Realtime e DashScope Realtime). Sessões de voz de longa duração rodam em paralelo ao tráfego HTTP: mesma autenticação e admissão por chave, medição por turno (response.create → response.done) no mesmo pipeline de estatísticas / cobrança / logs do HTTP — um único extrato de custos consistente.

Cinco camadas: grupos de chaves delimitam quais modelos e balanceadores cada tenant pode alcançar; chaves de acesso + regras de Header ACL diferenciam clientes por cabeçalho da requisição; o mapeamento de modelo por identidade roteia o mesmo nome de modelo para upstreams diferentes por tenant; limites de RPM / concorrência / TPM por chave limitam o uso; e a atribuição de custo por requisição faz cada tenant ver apenas o próprio gasto. Veja o guia de isolamento multi-tenant em docs.gatellm.io usecases/multi-tenant-isolation.

Sim. O GateLLM intercepta a busca na camada do gateway: configure um mecanismo de busca (serper, testável no próprio console), depois alternâncias triplas por modelo (seguir a capacidade / forçar ligado / forçar desligado) controlam a injeção. Os resultados são sintetizados em blocos de busca nativos por protocolo de cliente (server_tool_use do Anthropic / url_citation do OpenAI / web_search_call do Responses) — modelos abertos também ganham fundamentação por busca. Falhas de busca degradam suavemente sem bloquear requisições, e a busca interceptada é excluída da cobrança de uso. Veja console/search em docs.gatellm.io.

Sim. Um upstream pode manter várias chaves de API com distribuição ponderada: um hash ponderado determinístico (FNV-1a) fixa cada chamador na mesma chave (afinidade de cache), e quando uma chave falha o gateway tenta a próxima chave não utilizada dentro desse upstream. Chaves com weight=0 ficam em espera — usadas apenas depois que todas as chaves com weight>0 falharam. O estado de vínculo é observável linha a linha no console. Veja reference/upstreams-models-fields em docs.gatellm.io.

Sim. Qualquer endpoint compatível com OpenAI funciona como upstream: defina uma base URL personalizada e os serviços vLLM / Ollama / TGI passam a ser governados junto com os fornecedores de nuvem. Proxies de saída (socks5 / http), cabeçalhos de requisição personalizados e DNS por upstream são configuráveis para redes privadas e topologias especiais.

Nenhum YAML é necessário. O GateLLM traz um console visual: upstreams / modelos / balanceadores de carga / controle de acesso / MCP / estatísticas / logs são todos configurados por GUI, com troca instantânea entre chinês/inglês. Mudanças em lote passam por preparar → visualizar (conjunto completo de conflitos de namespace) → commit atômico, revertendo o lote inteiro em qualquer conflito. As contas do console vêm nos papéis admin / monitor (somente leitura), e toda operação e login é auditada.

O LiteLLM é um excelente proxy de LLM de código aberto. GateLLM e LiteLLM compartilham uma base de capacidades (roteamento, chamada de ferramentas, saída estruturada, cache, SSO via OIDC + SAML 2.0 + SCIM). Os diferenciais do GateLLM são o binário Rust único, os 15 formatos de protocolo (as 4 famílias de protocolo de chat traduzem qualquer-para-qualquer, o resto conforme a matriz de interoperabilidade), a injeção automática de cache no gateway e um console sem YAML; o LiteLLM lidera no seu ecossistema empresarial (gerenciadores de segredos, callbacks de guardrail de terceiros, callbacks de observabilidade). Veja /compare/litellm.

Sim. Totalmente auto-hospedado no seu VPC; chaves BYOK apenas em memória, nunca em disco; SSO empresarial (OIDC: Azure AD / Okta / genérico, além de SAML 2.0 e provisionamento automático SCIM 2.0); logs de auditoria no nível da requisição, exportáveis; pronto para GDPR; controles SOC 2 Type II / ISO 27001 alinhados (certificação em preparação). Veja /security.

Em Console → Configurações → Cobrança, crie um snapshot de preço manual para o modelo — ele é marcado como fixado (selo amarelo). Um preço fixado se torna atual e sombreia a base automática abaixo dele; as atualizações do sistema pulam esse modelo e nunca sobrescrevem seu preço manual. Excluí-lo volta para a próxima linha automática e se autorrecupera.

Não. Os snapshots de preço são ordenados por created_at e cada um cobre apenas a própria janela [seu tempo, próximo tempo) — o mais antigo preenche o histórico, o mais recente se estende indefinidamente para frente. Crie um novo snapshot com tempo de vigência futuro para agendar previamente o corte, de modo que ele afete apenas os meses seguintes, ou preencha um preço histórico para custear os meses passados com precisão.

Defina uma cota de custo diária / mensal (valor em USD) na chave de acesso — dois ciclos independentes avaliados no dia e no mês do calendário UTC, retornando 429 quota_exceeded e interrompendo o serviço no momento em que qualquer um deles estoura (a janela diária traz Retry-After). As cotas herdam chave → grupo → global; uma cota de grupo é um teto por chave dentro do grupo (não um extrato compartilhado), e entre grupos vale a mais ampla.