Alternativas ao Cloudflare AI Gateway: encaminhamento, pagamentos e margem de apps

Compare as alternativas de Cloudflare AI Gateway pelo caminho de solicitação e relação de pagamento que você deseja alterar. OpenRouter, LiteLLM, Portkey e Kong abordam requisitos selecionados de acesso a modelos, gateway ou monetização. ShareAI trata de um roteamento de aplicativo existente elegível para inferência por meio de um acordo aprovado com o Builder, com uma sobretaxa de aplicativo permitida e ganhos atribuídos. Estas são responsabilidades diferentes, mesmo quando várias opções expõem uma API de modelo compatível.

Revisado em 23 de outubro de 2026. ShareAI publica esta comparação e opera um programa discutido. Os fatos do produto vêm de referências oficiais atuais, com capturas de tela das fontes reais. O código executado é um ledger sintético offline. Nenhuma migração de gateway ao vivo, pagamento em stablecoin, cobrança de cliente, qualificação de endpoint ou benchmark de desempenho foi realizada.

Cloudflare já documenta faturamento unificado, chaves de provedores, provedores HTTPS personalizados e um caminho beta de pagamento por máquina. Uma comparação que presume que ele apenas encaminha solicitações pagas por meio da conta do provedor do proprietário do aplicativo ignora o escopo atual. Comece com a configuração real de credenciais, crédito e pagamento, depois avalie qualquer jornada comercial de aplicação ausente.

O que o atual Cloudflare AI Gateway já suporta

A referência de faturamento unificado descreve créditos pré-pagos para acesso a modelos elegíveis e uma taxa de 5% na compra de créditos, com taxas de inferência do provedor repassadas. Essa taxa de compra e uma sobretaxa de aplicativo downstream são cobranças diferentes. Razões para mantê-lo: avalie o gateway atual quando seu acesso a modelos e controles operacionais já se ajustam à arquitetura implantada do aplicativo e aos requisitos de pagamento.

A documentação de provedores personalizados cobre explicitamente endpoints HTTPS, incluindo exemplos de modelos auto-hospedados. O caminho de compatibilidade unificada exige o formato documentado de chat-completions; o caminho específico do provedor suporta sua própria estrutura de solicitação e caminho de URL anexado. Fornecer seu próprio endpoint, portanto, não é uma distinção exclusiva do ShareAI. Compare a autenticação real, o mapeamento de caminhos e a aceitação de integração da implementação selecionada.

A referência de pagamentos automáticos descreve um caminho beta usando uma carteira de stablecoin para modelos abertos selecionados. Os requisitos atuais incluem uma conta baseada nos EUA e um cartão de crédito registrado. Seu caminho de solicitação e negociação de pagamento suportado é mais restrito do que todo o tráfego do gateway. Não transforme essa capacidade documentada em uma alegação de que todo usuário ou provedor de aplicativo automaticamente recebe o mesmo percurso de pagamento.

Um aplicativo de revisão de código por IA precisa de um pagador explicável para cada solicitação.

Considere um aplicativo hipotético de revisão de código com clientes empresariais existentes. Ele utiliza uma chave de provedor de produção armazenada, um alias de chave diferente para experimentação, um modelo HTTPS personalizado e respostas em cache. O produto deseja oferecer inferência paga pelo cliente com uma margem do aplicativo. As finanças precisam saber se cada revisão entregue consumiu crédito do provedor, crédito do gateway ou outra autorização de pagamento suportada.

Um rótulo de modelo e uma etiqueta de custo são evidências insuficientes. O aplicativo deve distinguir uma revisão lógica de tentativas repetidas, identificar a credencial realmente usada e preservar se a resposta veio do cache. Uma nova tentativa ainda pode gerar uso do provedor. Uma resposta em cache pode ser entregue sem a mesma atividade upstream. O preço para o cliente precisa de uma política explícita para ambos os casos, em vez de copiar cegamente um custo de solicitação exibido.

O cenário também precisa de um caminho de exceção. Uma chave de produção expira enquanto um alias armazenado diferente permanece válido. O gateway retorna com sucesso uma revisão usando outra fonte de financiamento. Isso é operacionalmente útil, mas as finanças ainda podem receber uma fatura inesperada. Compare a prioridade das credenciais e o financiamento de fallback antes de concluir que uma resposta bem-sucedida significa que o cliente ou conta pretendido pagou.

Escolha a responsabilidade que você deseja que uma alternativa assuma.

Um aplicativo pode reter componentes do Cloudflare enquanto avalia outro caminho de inferência ou comercial. Isso requer uma integração real e uma explicação clara para o cliente. Não há sincronização automática, conector nativo ou carteira compartilhada entre os produtos implícitos. Cada solicitação cobrada precisa de um responsável por admissão, tentativas, correções e pagamento.

Rastreie a revisão desde a admissão até o recebimento do dinheiro

Mantenha essas observações vinculadas sem tratá-las como intercambiáveis. Uma tag pode atribuir custo a um espaço de trabalho sem autorizar uma alteração de preço. Um painel pode exibir uma margem sem coletá-la. Uma autorização de pagamento pode preceder a liquidação final. Produto, suporte e finanças devem ser capazes de explicar a mesma revisão lógica e seus ajustes explícitos.

OpenRouter: compare acesso gerenciado e inferência financiada pelo usuário

O OpenRouter quickstart descreve acesso gerenciado entre provedores de modelo. Seu guia OAuth permite explicitamente que os usuários autorizem um aplicativo com uma chave controlada pelo usuário e paguem solicitações com seus próprios créditos do OpenRouter. Prós: compare essa jornada suportada quando o aplicativo de revisão de código deseja que os clientes financiem sua própria inferência em vez de cobrar cada solicitação do proprietário do aplicativo.

Compromissos: qualifique a autorização do usuário, o manuseio de chaves, os provedores permitidos, o financiamento de fallback e os termos atuais da conta. A referência de atribuição de aplicativos descreve a associação com uso e classificações. Essa associação documentada, por si só, não estabelece uma sobretaxa de aplicativo ou um acordo de liquidação recebido. A inferência paga pelo usuário não é exclusiva do ShareAI; compare o arranjo comercial completo aprovado.

Para o cliente de revisão de código, ensaie uma desconexão do usuário, uma cota esgotada e um modelo cujo provedor muda. Preserve a identidade do usuário e do aplicativo sem enviar uma credencial do servidor para o navegador. Verifique a conta pagadora real e qualquer preço de aplicação acordado separadamente. Uma resposta bem-sucedida do modelo não prova, por si só, que um aplicativo gerou receita.

LiteLLM: compare preços personalizados e margens de faturamento interno

A LiteLLM referência de preços personalizados documenta custos de modelos, descontos de provedores e margens de provedores para faturamento interno. Vantagens: compare esses controles existentes quando o aplicativo de revisão de código deseja avaliar seu próprio mapeamento de custos e alocação de cobranças. Uma alegação de que todos os outros gateways carecem de margens ignoraria esse escopo documentado.

Compromissos: qualifique a implantação selecionada, a consulta de preços, os orçamentos e o fluxo de trabalho de cobrança. A referência atual observa que custos de entrada e saída explicitamente zero ignoram verificações de orçamento, incluindo escopos de chave e equipe. Também explica o mapeamento de provedores de preços quando provedores de roteamento e preços diferem. Um valor zero exibido, portanto, precisa de investigação em vez de uma suposição de que a carga de trabalho é gratuita.

Para o modelo de revisão personalizado, inspecione uma solicitação conhecida com valor diferente de zero e seu preço configurado antes de habilitar a política de orçamento de produção. Compare separadamente o custo original do provedor, um valor alocado internamente e o preço comercial aceito pelo cliente. Um cálculo correto de margem interna não fornece as condições de checkout do aplicativo, acordo com o cliente ou liberação financeira ao redor.

Portkey: compare controles de gateway e observabilidade

A documentação atual do Portkey descreve as capacidades de gateway, observabilidade, guardrail e administração, com referências separadas para implantação e recursos. Prós: compare o escopo selecionado quando as equipes de revisão de código precisam entender o tráfego do modelo e aplicar controles de gateway. Avalie o produto e a implantação reais em vez de inferir todos os recursos comerciais a partir de um título de contagem de modelos.

Tradeoffs: qualifique a edição exata, hospedagem, política de roteamento, dados retidos e propriedade de pagamento. Um rastreamento e um controle de gastos abordam questões diferentes de receber um pagamento de cliente. Da mesma forma, uma referência de auto-hospedagem não estabelece automaticamente que todo painel gerenciado, recurso empresarial ou obrigação de suporte está incluído em uma implantação escolhida.

Para o aplicativo de revisão, compare a tentativa de provedor falhada, a resposta de fallback e o resultado em cache como observações separadas dentro do mesmo trabalho lógico. Preserve a atribuição confiável do cliente e o erro real mostrado no aplicativo. O resultado útil é uma revisão entregue explicável com seu financiamento real e tratamento comercial, em vez de apenas uma contagem de solicitações bem-sucedidas.

Kong: compare a política de gateway com medição e faturamento.

A Kong página de monetização de IA descreve um caminho mais amplo de gateway e monetização. Sua referência atual de direitos conecta direitos gerenciados de tabela de preços com a aplicação separada no gateway. Prós: avalie os serviços selecionados quando o aplicativo de revisão deseja que a política de gateway e a comercialização de uso sejam consideradas juntas.

Tradeoffs: qualifique a compatibilidade de serviço e implantação, a aplicação real de políticas, a medição e a integração de cobrança. Um gateway na infraestrutura da empresa é um fato arquitetônico diferente da localização de seu serviço de faturamento gerenciado. Evite comparar toda uma família de produtos com um único endpoint proxy ou assumir que todas as capacidades hospedadas estão incluídas em um gateway on-premises.

Para o cliente em revisão, inspecione como um direito adquirido se torna uma decisão de tempo de execução real e como revisões falhas ou repetidas chegam ao registro comercial. Preserve a regra selecionada no momento de sua vigência. Um saldo e um plugin de aplicação podem coexistir enquanto o aplicativo ainda precisa qualificar sua integração completa e explicar correções financeiras.

ShareAI: compare uma sobretaxa aprovada de aplicativo e liquidação

O ShareAI Builder Program refere-se a um aplicativo que já existe com seus próprios usuários. O tráfego de IA elegível é roteado através do ShareAI, o Builder configura uma sobretaxa ou margem permitida, e o cliente final paga ao ShareAI por essa inferência. Os ganhos atribuídos ao aplicativo seguem o programa. Prós: avalie este arranjo quando o aplicativo em revisão desejar um pagamento de inferência aprovado e uma jornada de atribuição.

Compromissos: aprovação de aplicativo, tráfego elegível, acesso ao modelo e termos de conta são importantes. Builders de empresas validadas têm um período de revisão de 45 dias antes do pagamento. Atualmente, indivíduos acumulam valor de inferência para uso no ShareAI, sem possibilidade de saque ou transferências de conta. O aplicativo permanece construído, hospedado, distribuído e mantido em outro lugar. Outras assinaturas, entrega de suporte e responsabilidades financeiras permanecem responsabilidades explícitas.

Fornecer infraestrutura de modelo ou um endpoint personalizado pertence ao onboarding aplicável de Provedor ou Prosumer, separadamente da atribuição do Builder. Provedores personalizados Cloudflare e outros gateways já abordam o controle de endpoints. Compare aceitação real, roteamento, pagador e liquidação em vez de reivindicar exclusividade. ShareAI não estabelece um protocolo nativo de pagamento por máquina, um serviço geral de merchant-of-record ou um substituto para todas as políticas de gateway.

A prioridade de credenciais pode alterar qual conta financia uma solicitação

O guia de faturamento unificado prioriza a credencial do provedor de solicitação, depois um alias de provedor padrão armazenado, e então o crédito de faturamento unificado elegível. Aliases armazenados que não são padrão não são usados por esse caminho unificado. A referência BYOK descreve a configuração separada de chaves armazenadas e aliases. Uma chave que existe na conta, portanto, não é prova de que uma solicitação específica a utiliza.

Para o aplicativo de revisão, verifique o caminho escolhido quando a chave de produção estiver ausente ou falhar. Controles documentados podem exigir credenciais do provedor ou impedir o fallback de faturamento unificado de terceiros elegíveis; o Workers AI possui um modo separado. Revise a configuração exata e a cobertura do provedor. Também distinga a política de retenção zero de um provedor da própria configuração de registro do gateway, que precisa de uma decisão explícita própria.

Custo personalizado, pagamento negociado e preço de um aplicativo diferem

A referência de custo personalizado descreve o mapeamento de taxas de entrada, saída e tokens de cache, incluindo formatos de token específicos do provedor e custo zero registrado para acessos ao cache do gateway. Essas análises, por si só, não estabelecem um preço de revenda downstream aceito. Preserve o custo real upstream, a política do cliente e a correção em vez de assumir que um custo exibido é uma fatura paga.

O caminho beta de pagamento por máquina exige negociação explícita do método de pagamento e suporta um endpoint de solicitação definido e um conjunto de modelos. Sua autorização máxima assinada difere do valor real liquidado. Compare esses requisitos documentados antes de recomendá-lo ao aplicativo de revisão. Nenhuma transação de stablecoin ou compatibilidade com ShareAI foi testada ou implicada aqui.

Apenas para aritmética, 1000 USD de inferência mais uma sobretaxa hipotética de 15% produzem 150 USD de sobretaxa bruta e 1150 USD no total. Esses valores sintéticos não são taxas de Cloudflare ou ShareAI, ganhos recebidos, lucro líquido ou um resultado tributário. Taxas reais de compra de crédito, reembolsos, correções e elegibilidade afetam o resultado comercial.

Verifique a aritmética sem confundi-la com pagamento

O fixture executado abaixo deduplica atividades idênticas, rejeita um duplicado conflitante e registra um ajuste explícito usando centavos inteiros em USD. Ele não seleciona uma chave de provedor, envia uma revisão, autoriza uma carteira ou coleta um pagamento. Esses resultados exigem evidências reais de aplicação e comerciais em torno do cálculo.

import assert from "node:assert/strict";
const records = [
  {id: "usage-a", customer: "demo", cents: 60000n, kind: "usage"},
  {id: "usage-b", customer: "demo", cents: 50000n, kind: "usage"},
  {id: "usage-a", customer: "demo", cents: 60000n, kind: "usage"},
  {id: "adjustment-b", customer: "demo", cents: -10000n, kind: "adjustment"}
];
function netCents(rows) {
  const seen = new Map();
  let total = 0n;
  for (const row of rows) {
    assert.equal(row.customer, "demo");
    const fingerprint = [row.customer, row.cents.toString(), row.kind].join("|");
    if (seen.has(row.id)) {
      if (seen.get(row.id) !== fingerprint) throw new Error("Conflicting duplicate");
      continue;
    }
    if (row.cents < 0n && row.kind !== "adjustment") throw new Error("Invalid sign");
    seen.set(row.id, fingerprint);
    total += row.cents;
  }
  return total;
}
const base = netCents(records);
assert.equal(base, 100000n);
assert.throws(() => netCents([...records,
  {id: "usage-a", customer: "demo", cents: 1n, kind: "usage"}
]));
const numerator = base * 1500n; // Hypothetical 15 percent in basis points.
if (numerator % 10000n !== 0n) throw new Error("Define contractual rounding first");
const surcharge = numerator / 10000n;
assert.equal(surcharge, 15000n);
const usd = cents => `${cents / 100n}.${(cents % 100n).toString().padStart(2, "0")}`;
console.log(JSON.stringify({baseUSD: usd(base), grossSurchargeUSD: usd(surcharge),
  totalUSD: usd(base + surcharge), paidReceiptVerified: false}));

A saída observada é uma inferência ilustrativa de 1000 USD, um acréscimo bruto de 150 USD e um total de 1150 USD, sem recibo de pagamento verificado. Preserve a identidade lógica da revisão, as tentativas reais, o financiamento e as correções explícitas em produção. Uma soma correta não pode estabelecer qual conta pagou ou quando o valor atribuído se torna disponível.

Mova um fluxo de trabalho de revisão com sua exceção de financiamento primeiro.

• Inventarie controles reais de gateway, credenciais, provedores e preços para clientes.
• Selecione a inferência, o gateway ou a responsabilidade comercial que precisa ser alterada.
• Preserve a identidade confiável do cliente e da revisão lógica em tentativas repetidas e acertos de cache.
• Reproduza credenciais ausentes, financiamento de fallback e uma correção explícita.
• Verifique evidências reais de pagamento sem coleta duplicada ao vivo.
• Retenha os registros originais e reverta até que a jornada completa do cliente seja qualificada.

Mantenha Cloudflare quando o arranjo atual for adequado. Compare as alternativas selecionadas por uma solicitação explicável, cobrança aceita do cliente e liquidação real. Comece com uma revisão cuja admissão, roteamento, entrega útil e exceção financeira possam ser explicadas de forma consistente por produto, suporte e finanças.

Perguntas frequentes