Alternatives à Cloudflare AI Gateway : routage, paiements et marge des applications

Comparez les alternatives de Cloudflare AI Gateway selon le chemin de requête et la relation de paiement que vous souhaitez modifier. OpenRouter, LiteLLM, Portkey et Kong répondent aux exigences sélectionnées en matière d’accès au modèle, de passerelle ou de monétisation. ShareAI concerne le routage d’une application existante permettant une inférence éligible via un arrangement approuvé avec un Builder, avec une surcharge d’application autorisée et des revenus attribués. Ce sont des responsabilités distinctes, même lorsque plusieurs options exposent une API de modèle compatible.

Examiné le 23 octobre 2026. ShareAI publie cette comparaison et exploite un programme discuté. Les faits sur le produit proviennent de références officielles actuelles, avec des captures d’écran de sources réelles. Le code exécuté est un registre synthétique hors ligne. Aucune migration de passerelle en direct, paiement en stablecoin, charge client, qualification de point de terminaison ou benchmark de performance n’a été effectué.

Cloudflare documente déjà la facturation unifiée, les clés de fournisseur, les fournisseurs HTTPS personnalisés et un chemin de paiement machine en version bêta. Une comparaison qui suppose qu’il ne fait que transmettre des requêtes payées via le compte fournisseur du propriétaire de l’application manque de portée actuelle. Commencez par la configuration réelle des identifiants, crédits et paiements, puis évaluez tout parcours commercial d’application manquant.

Ce que Cloudflare AI Gateway prend déjà en charge actuellement

La référence de facturation unifiée décrit des crédits prépayés pour l’accès au modèle éligible et une commission de 5 % sur l’achat de crédits, avec des tarifs d’inférence fournisseur répercutés. Cette commission d’achat et une surcharge d’application en aval sont des frais distincts. Raisons de la conserver : évaluez la passerelle actuelle lorsque son accès au modèle et ses contrôles opérationnels s’adaptent déjà à l’architecture déployée de l’application et aux exigences de paiement.

La documentation des fournisseurs personnalisés couvre explicitement les points de terminaison HTTPS, y compris des exemples de modèles auto-hébergés. Le chemin de compatibilité unifié nécessite le format de complétions de chat documenté ; le chemin spécifique au fournisseur prend en charge sa propre structure de requête et le chemin d’URL ajouté. Fournir votre propre point de terminaison n’est donc pas une distinction exclusive de ShareAI. Comparez l’authentification réelle, la cartographie des chemins et l’intégration acceptée de l’implémentation sélectionnée.

La référence des paiements machine décrit un chemin bêta utilisant un portefeuille stablecoin pour des modèles ouverts sélectionnés. Les exigences actuelles incluent un compte basé aux États-Unis et une carte de crédit enregistrée. Son chemin de requête et de négociation de paiement pris en charge est plus étroit que tout le trafic de la passerelle. Ne transformez pas cette capacité documentée en une affirmation selon laquelle chaque utilisateur ou fournisseur d’application reçoit automatiquement le même parcours de paiement.

Une application de révision de code IA nécessite un payeur explicable pour chaque requête.

Considérez une application hypothétique de révision de code avec des clients professionnels existants. Elle utilise une clé de fournisseur de production stockée, un alias de clé différent pour l’expérimentation, un modèle HTTPS personnalisé et des réponses mises en cache. Le produit souhaite offrir une inférence payée par le client avec une marge d’application. Les finances doivent savoir si chaque révision livrée a consommé un crédit fournisseur, un crédit passerelle ou une autre autorisation de paiement prise en charge.

Une étiquette de modèle et une balise de coût sont des preuves insuffisantes. L’application doit distinguer une révision logique des tentatives répétées, identifier la crédential réellement utilisée et préserver si la réponse provient du cache. Une nouvelle tentative peut toujours créer une utilisation fournisseur. Une réponse mise en cache peut être livrée sans la même activité en amont. La tarification client nécessite une politique explicite pour les deux cas plutôt que de copier aveuglément un coût de requête affiché.

Le scénario nécessite également un chemin d’exception. Une clé de production expire tandis qu’un autre alias stocké reste valide. La passerelle retourne avec succès une révision en utilisant une autre source de financement. Cela est utile opérationnellement, mais les finances peuvent toujours recevoir une facture inattendue. Comparez la priorité des crédentials et le financement de secours avant de conclure qu’une réponse réussie signifie que le client ou le compte prévu a payé.

Choisissez la responsabilité que vous souhaitez qu’une alternative assume.

Une application peut conserver les composants Cloudflare tout en évaluant une autre inférence ou voie commerciale. Cela nécessite une intégration réelle et une explication claire au client. Aucune synchronisation automatique, connecteur natif ou portefeuille partagé entre les produits n’est impliqué. Chaque requête facturée nécessite un propriétaire responsable pour l’admission, les tentatives, les corrections et le paiement.

Suivez la revue depuis l’admission jusqu’à l’argent reçu

Gardez ces observations liées sans les traiter comme interchangeables. Une balise peut attribuer un coût à un espace de travail sans autoriser un changement de prix. Un tableau de bord peut afficher une marge sans la collecter. Une autorisation de paiement peut précéder le règlement final. Produit, support et finance doivent être capables d’expliquer la même revue logique et ses ajustements explicites.

OpenRouter : comparer l’accès géré et l’inférence financée par l’utilisateur

Le OpenRouter quickstart décrit l’accès géré auprès des fournisseurs de modèles. Son guide OAuth permet explicitement aux utilisateurs d’autoriser une application avec une clé contrôlée par l’utilisateur et de payer les requêtes avec leurs propres crédits OpenRouter. Avantages : comparez ce parcours pris en charge lorsque l’application de revue de code souhaite que les clients financent leur propre inférence plutôt que de facturer chaque requête au propriétaire de l’application.

Compromis : qualifier l’autorisation utilisateur, la gestion des clés, les fournisseurs autorisés, le financement de secours et les conditions actuelles du compte. La référence d’attribution d’application décrit l’association avec l’utilisation et les classements. Cette association documentée seule n’établit pas de surcharge d’application ou de règlement reçu. L’inférence payée par l’utilisateur n’est pas unique à ShareAI ; comparez l’arrangement commercial complet approuvé.

Pour le client de révision de code, simulez une déconnexion utilisateur, une allocation épuisée et un modèle dont le fournisseur change. Préservez l’identité de l’utilisateur et de l’application sans envoyer un identifiant serveur au navigateur. Vérifiez le compte payant réel et tout prix d’application convenu séparément. Une réponse réussie du modèle ne prouve pas à elle seule qu’une application a généré des revenus.

LiteLLM : comparez les prix personnalisés et les marges de facturation internes.

La LiteLLM référence de tarification personnalisée documente les coûts des modèles, les remises des fournisseurs et les marges des fournisseurs pour la facturation interne. Avantages : comparez ces contrôles existants lorsque l’application de révision de code souhaite évaluer sa propre cartographie des coûts et allocation des charges. Une affirmation selon laquelle chaque autre passerelle manque de marges ignorerait cette portée documentée.

Compromis : qualifier le déploiement sélectionné, la recherche de prix, les budgets et le workflow de collecte. La référence actuelle note que des coûts d’entrée et de sortie explicitement nuls contournent les vérifications budgétaires, y compris les portées des clés et des équipes. Elle explique également la cartographie des fournisseurs de tarification lorsque les fournisseurs de routage et de tarification diffèrent. Un zéro affiché nécessite donc une enquête plutôt qu’une supposition que la charge de travail est gratuite.

Pour le modèle de révision personnalisé, inspectez une demande non nulle connue et son prix configuré avant d’activer la politique budgétaire de production. Comparez séparément le coût initial du fournisseur, un montant alloué en interne et le prix commercial accepté par le client. Un calcul correct de la marge interne ne fournit pas les conditions environnantes de paiement de l’application, l’accord client ou les conditions de libération financière.

Portkey : comparez les contrôles de passerelle et l’observabilité.

La documentation actuelle de Portkey décrit les capacités de passerelle, d’observabilité, de garde-fou et d’administration, avec des références distinctes pour le déploiement et les fonctionnalités. Avantages : comparez la portée sélectionnée lorsque les équipes de revue de code doivent comprendre le trafic du modèle et appliquer des contrôles de passerelle. Évaluez le produit et le déploiement réels plutôt que d’inférer chaque fonctionnalité commerciale à partir d’un titre sur le nombre de modèles.

Compromis : qualifiez l’édition exacte, l’hébergement, la politique de routage, les données conservées et la propriété des paiements. Une trace et un contrôle des dépenses répondent à des questions différentes de celles liées à la réception d’un paiement client. De même, une référence à l’auto-hébergement n’établit pas automatiquement que chaque tableau de bord géré, fonctionnalité d’entreprise ou obligation de support est inclus dans un déploiement choisi.

Pour l’application de revue, comparez la tentative échouée du fournisseur, la réponse de secours et le résultat mis en cache comme observations distinctes au sein du même travail logique. Préservez l’attribution client de confiance et l’erreur réelle affichée à l’application. Le résultat utile est une revue livrée explicable avec son financement réel et son traitement commercial, plutôt qu’un simple nombre de requêtes réussies.

Kong : comparez la politique de passerelle avec la mesure et la facturation.

La Kong page de monétisation AI décrit une passerelle plus large et un chemin de monétisation. Sa référence actuelle sur les droits connecte les droits de carte tarifaire gérés avec une application distincte de la passerelle. Avantages : évaluez les services sélectionnés lorsque l’application de revue souhaite que la politique de passerelle et la commercialisation de l’utilisation soient considérées ensemble.

Compromis : qualifiez la compatibilité des services et des déploiements, l’application réelle des politiques, la mesure et l’intégration de la collecte. Une passerelle sur l’infrastructure de l’entreprise est un fait architectural différent de l’emplacement de son service de facturation géré. Évitez de comparer une famille de produits entière avec un seul point de terminaison proxy ou de supposer que chaque capacité hébergée est incluse dans une passerelle sur site.

Pour le client en revue, examinez comment un droit acheté devient une décision d’exécution réelle et comment les revues échouées ou répétées atteignent le registre commercial. Préservez la règle sélectionnée à son moment effectif. Un équilibre et un plugin d’application des règles peuvent coexister tandis que l’application doit encore qualifier leur intégration complète et expliquer les corrections financières.

ShareAI : comparez une surcharge approuvée pour une application et son règlement

Le ShareAI Builder Program concerne une application existante avec ses propres utilisateurs. Le trafic IA éligible passe par ShareAI, le Builder configure une surcharge ou une marge autorisée, et le client final paie ShareAI pour cette inférence. Les revenus attribués à l’application suivent le programme. Avantages : évaluez cet arrangement lorsque l’application en revue souhaite un paiement d’inférence approuvé et un parcours d’attribution.

Compromis : l’approbation de l’application, le trafic éligible, l’accès au modèle et les conditions du compte sont importants. Les Builders validés en tant qu’entreprises ont une période de revue de 45 jours avant le paiement. Les individus accumulent actuellement une valeur d’inférence pour l’utilisation de ShareAI, sans possibilité de retrait en espèces ou de transferts de compte. L’application reste construite, hébergée, distribuée et maintenue ailleurs. Les autres abonnements, la livraison du support et les obligations financières restent des responsabilités explicites.

Fournir une infrastructure de modèle ou un point de terminaison personnalisé relève de l’intégration applicable du fournisseur ou du prosumer, séparément de l’attribution du Builder. Cloudflare les fournisseurs personnalisés et autres passerelles adressent déjà le contrôle des points de terminaison. Comparez l’acceptation réelle, le routage, le payeur et le règlement plutôt que de revendiquer l’exclusivité. ShareAI n’établit pas un protocole de paiement machine natif, un service général de marchand de référence ou un remplacement pour chaque politique de passerelle.

La priorité des identifiants peut modifier le compte qui finance une demande

Le guide de facturation unifiée donne la priorité des identifiants à une clé de fournisseur de requêtes, puis à un alias de fournisseur par défaut enregistré, puis au crédit de facturation unifiée éligible. Les alias enregistrés non par défaut ne sont pas utilisés par ce chemin unifié. La référence BYOK décrit la configuration distincte des clés enregistrées et des alias. Une clé existant dans le compte ne constitue donc pas une preuve qu’une requête particulière l’utilise.

Pour l’application de révision, vérifiez le chemin choisi lorsque la clé de production est manquante ou échoue. Les contrôles documentés peuvent exiger des identifiants de fournisseur ou empêcher le recours éligible à la facturation unifiée de tiers ; Workers AI dispose d’un mode distinct. Examinez la configuration exacte et la couverture du fournisseur. Distinguez également la politique de rétention zéro d’un fournisseur de la configuration de journalisation propre à la passerelle, qui nécessite une décision explicite.

Coût personnalisé, paiement négocié et prix d’une application diffèrent.

La référence sur les coûts personnalisés décrit la cartographie des taux d’entrée, de sortie et de jetons de cache, y compris les formats de jetons spécifiques aux fournisseurs et le coût nul enregistré pour les accès au cache de la passerelle. Ces analyses ne permettent pas à elles seules d’établir un prix de revente aval accepté. Préservez le coût réel en amont, la politique client et les corrections au lieu de supposer qu’un coût affiché est une facture payée.

Le chemin de paiement machine en version bêta nécessite une négociation explicite de la méthode de paiement et prend en charge un point de terminaison de requête défini et un ensemble de modèles. Son autorisation maximale signée diffère du montant réel réglé. Comparez ces exigences documentées avant de le recommander à l’application de révision. Aucune transaction en stablecoin ni compatibilité avec ShareAI n’a été testée ou impliquée ici.

Pour l’arithmétique uniquement, 1000 USD d’inférence plus une surcharge hypothétique de 15% produisent une surcharge brute de 150 USD et un total de 1150 USD. Ces montants synthétiques ne sont pas des frais, des revenus reçus, des bénéfices nets ou un résultat fiscal de Cloudflare ou ShareAI. Les frais d’achat de crédit réels, les remboursements, les corrections et l’éligibilité affectent le résultat commercial.

Vérifiez l’arithmétique sans la confondre avec le paiement.

Le fixture exécuté ci-dessous déduplique une activité identique, rejette un doublon conflictuel et enregistre un ajustement explicite en cents USD entiers. Il ne sélectionne pas une clé de fournisseur, ne soumet pas une révision, n’autorise pas un portefeuille ni ne collecte un paiement. Ces résultats nécessitent des preuves réelles d’application et commerciales autour du calcul.

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}));

La sortie observée est une inférence illustrative de 1000 USD, une surcharge brute de 150 USD et un total de 1150 USD, sans reçu payé vérifié. Préservez l’identité logique de la revue, les tentatives réelles, le financement et les corrections explicites en production. Une somme correcte ne peut pas établir quel compte a payé ou quand la valeur attribuée devient disponible.

Déplacez d’abord un flux de travail de revue avec son exception de financement.

• Inventoriez les contrôles de passerelle réels, les identifiants, les fournisseurs et les prix des clients.
• Sélectionnez l’inférence, la passerelle ou la responsabilité commerciale qui doit changer.
• Préservez l’identité de client de confiance et de revue logique à travers les nouvelles tentatives et les accès en cache.
• Répétez les identifiants manquants, le financement de secours et une correction explicite.
• Vérifiez les preuves de paiement réelles sans collecte en direct dupliquée.
• Conservez les enregistrements originaux et effectuez un retour arrière jusqu’à ce que le parcours complet du client soit qualifié.

Conservez Cloudflare lorsque l’arrangement actuel convient. Comparez les alternatives sélectionnées par une demande explicable, une charge client acceptée et un règlement réel. Commencez par une revue dont l’admission, le routage, la livraison utile et l’exception financière peuvent être expliqués de manière cohérente par le produit, le support et les finances.

Questions fréquemment posées