Aller au contenu

Guides de migrationDepuis LiteLLM

D'un proxy LiteLLM que vous exploitez à un que vous n'exploitez pas

LiteLLM, ce sont deux choses : un SDK Python qui parle à plus de 100 fournisseurs, et un proxy que vous déployez avec Postgres et Redis, qui ajoute clés virtuelles, budgets, replis et cache. Les deux fonctionnent sur vos propres clés de fournisseur, comme INFRO. Ce qui change, c'est qui exploite le proxy. Cette page fait correspondre la config du proxy à INFRO et montre comment garder le SDK.

Open source MIT par BerriAI, plus une édition Enterprise sous licence ; auto-hébergé

Les comptes INFRO sont en libre-service. Le catalogue, la documentation et le contrat d'API sont publics, la passerelle est déployée, et tout ce qui va au-delà de la v1 est marqué Plus tard. Offres et essai

Où en sont les choses

Licence et éditions

Tout ce qui est hors du répertoire enterprise/ est sous licence MIT ; Enterprise est la même image avec une clé de licence, qui ajoute SSO, SCIM, journaux d'audit, gestionnaires de secrets et support.

Avis de sécurité en 2026

Le blog de LiteLLM lui-même recense une compromission PyPI de litellm 1.82.7 et 1.82.8 le 2026-03-24 (l'image Docker officielle n'était pas touchée ; la version saine 1.83.0 est sortie le 2026-03-30), une injection SQL dans la vérification des clés du proxy corrigée en 1.83.7 (2026-04-29), et un contournement d'authentification par en-tête Host corrigé en 1.84.0 (2026-06-01). Exploiter le proxy, c'est suivre cela vous-même.

Le compte de qui sert la requête

Vous, dans les deux produits. LiteLLM ne détient jamais de compte fournisseur, INFRO non plus ; vos fournisseurs vous facturent directement.

LiteLLM est gratuit, ouvert et s'exécute n'importe où. Si ce sont les raisons pour lesquelles vous l'avez choisi, elles restent de bonnes raisons.

  • Le trafic ne doit pas quitter votre réseau, ou vous devez pouvoir lire et corriger le code de la passerelle. INFRO est hébergé et sous code fermé ; l'auto-hébergement ou l'hybride relève d'un accord Enterprise.
  • Vous utilisez le cache sémantique, les replis sur la fenêtre de contexte ou la politique de contenu, la passerelle d'agents A2A, ou des callbacks vers un fournisseur de journalisation précis. INFRO propose un cache à correspondance exacte, des règles d'échec de route, une passerelle MCP et l'export OpenTelemetry.
  • Vous appelez des fournisseurs qu'INFRO ne connecte pas, ou des endpoints qu'il ne sert pas : batches, fichiers, fine-tuning, Realtime, embeddings chez des fournisseurs autres qu'OpenAI, Azure OpenAI, Mistral ou un endpoint compatible OpenAI.
  • L'exploiter vous coûte peu, car une équipe plateforme gère déjà Postgres, Redis et les mises à jour.

Les modifications, une ligne chacune. Tout ce qui n'est pas listé ici reste tel quel.

 LiteLLMINFRO
URL de baseVotre proxy, par exemple http://0.0.0.0:4000.https://api.infro.io/v1
CléUne clé virtuelle LiteLLM (sk-...) issue de /key/generate.Une clé de passerelle INFRO, créée dans la console ou l'API de gestion. Les clés de fournisseur passent de litellm_params aux connexions INFRO.
ID du modèleUn model_name de model_list, tel que gpt-4o.Une route du même nom, pour que les appelants continuent de l'envoyer, ou directement vendor/model.
Champs du corpsmetadata { tags, trace_id, trace_user_id, generation_name }, cache { ttl, namespace }, user.metadata { user_id, session_id, tags }, cache pour le cache de réponses, X-INFRO-Trace-Id pour un identifiant de trace.

Avant · LiteLLM proxy

import OpenAI from "openai";

const client = new OpenAI({
  baseURL: "http://0.0.0.0:4000",
  apiKey: process.env.LITELLM_API_KEY, // virtual key
});

await client.chat.completions.create({
  model: "claude-default", // model_name in model_list
  messages: [{ role: "user", content: "Hello" }],
  user: "user-123",
  // @ts-expect-error LiteLLM extension
  metadata: { tags: ["production"] },
});

Après · INFRO

import OpenAI from "openai";

const client = new OpenAI({
  baseURL: "https://api.infro.io/v1",
  apiKey: process.env.INFRO_API_KEY,
});

await client.chat.completions.create({
  model: "claude-default", // an INFRO route, same name
  messages: [{ role: "user", content: "Hello" }],
  // @ts-expect-error INFRO extension
  metadata: { user_id: "user-123", tags: { env: "production" } },
});

`model_list` devient des routes

Chaque model_name avec plusieurs deployments devient une route avec ces cibles ; les poids rpm deviennent des cibles pondérées ; les router_settings.fallbacks deviennent les cibles suivantes de la route ou des fallbacks.

Garder le SDK

Le fournisseur compatible OpenAI de LiteLLM envoie tout ce qui suit openai/ comme identifiant de modèle : openai/anthropic/claude-sonnet-5.5 arrive donc chez INFRO sous la forme anthropic/claude-sonnet-5.5. Les replis ont alors lieu dans INFRO, pas dans le SDK.

Ou gardez le proxy derrière INFRO

Connectez le proxy comme connexion openai-compatible pendant la migration. Notez qu'INFRO ne voit alors que le proxy comme un seul fournisseur : le basculement et le coût par fournisseur restent donc gérés dans LiteLLM tant que vous ne connectez pas directement les fournisseurs.

Les objets de LiteLLM face à ceux de INFRO, d'après la documentation publique de LiteLLM lue le 19 octobre 2026 et vérifiés par rapport à ce que la passerelle implémente. Une ligne indique que INFRO n'a rien.

LiteLLMCe que cela y faitDans INFRO
`model_list` et `litellm_params`même formeDeployments par nom de modèle, avec les clés de fournisseur dans la config.Connexions aux fournisseurs (clés chiffrées, plusieurs par fournisseur) et routes sur celles-ci.
Clés virtuellesmême formeClés émises par le proxy avec modèles autorisés, budget, tpm et rpm, équipe et utilisateur.Clés de passerelle avec modèles et fournisseurs autorisés, plages d'IP, un environnement, une limite de dépenses et un niveau de débit de requêtes ; rotation et interrupteur d'arrêt.
Équipes, utilisateurs, budgetsmême formemax_budget et budget_duration par clé, équipe ou utilisateur.Budgets par organisation, projet, membre, clé et client final, tenus sous concurrence, 402 au plafond avant l'appel au fournisseur.
limites tpmdifférentLimites de tokens par minute par clé ou par deployment.Niveaux de débit de requêtes par clé et budgets en dollars. Pas de limite en tokens par minute.
Replis et relancesmême formefallbacks, num_retries, délais de refroidissement, allowed_fails.Cibles de route et règles d'échec par type (réessayer, basculer ou arrêter) ; fallbacks par requête.
Replis sur la fenêtre de contexte et la politique de contenudifférentUn autre modèle quand le prompt est trop long ou qu'une politique du fournisseur le refuse.Une règle d'échec moderation peut basculer vers la cible suivante. Pas de repli sur la fenêtre de contexte.
CachedifférentCaches exacts et sémantiques sur Redis, S3, GCS, Qdrant et d'autres.Correspondance exacte, sur option, pour les complétions de chat, hébergé. Pas de cache sémantique.
Garde-fousdifférentGarde-fous enfichables ; plusieurs intégrations exigent Enterprise.Règles par motifs qui bloquent, masquent ou signalent, et contrôles sur un modèle de décision, sur toutes les offres qui incluent les garde-fous.
Callbacks de journalisationdifférentCallbacks vers Langfuse et d'autres outils ; journaux de dépenses dans Postgres.Le journal des requêtes, les exports et les spans vers votre collecteur OpenTelemetry.
Suivi des dépensesdifférentCoût d'après la table de prix des modèles de LiteLLM.Coût fournisseur estimé d'après vos tarifs négociés ou le tarif public de l'éditeur, unpriced quand il est inconnu, rapproché des API de coûts d'OpenAI et d'Anthropic.
Passerelle MCPmême formeServeurs MCP derrière le proxy.Une passerelle MCP pour vos propres serveurs MCP, avec des outils approuvés et des autorisations par clé.
Passerelle d'agents A2ArienTrafic d'agent à agent via le proxy.Rien.
L'exploiter vous-mêmedifférentMIT, Docker ou pip, n'importe où.Hébergé. L'auto-hébergé ou l'hybride relève d'un contrat entreprise.Enterprise — Disponible dans le cadre d'un contrat Enterprise plutôt qu'en libre-service.

Notre lecture de la documentation publiée par LiteLLM, pas un essai ni un benchmark. Si nous avons mal lu quelque chose, dites-le-nous et nous corrigerons la ligne.

Ce que INFRO ne fait pas

  • Exécuter sur votre propre infrastructure sans accord Enterprise, ou vous laisser lire son code source.
  • Cache sémantique, replis sur la fenêtre de contexte, A2A.
  • Servir des batches, des fichiers, du fine-tuning ou du Realtime, ou des embeddings chez des fournisseurs autres qu'OpenAI, Azure OpenAI, Mistral ou un endpoint compatible OpenAI.
  • Limites de tokens par minute ; INFRO limite par débit de requêtes et en dollars.

Ce qui n'est pas repris

  • Journaux de dépenses et historique des requêtes dans votre Postgres LiteLLM. Il n'y a pas d'outil d'import.
  • Clés virtuelles. Émettez des clés de passerelle INFRO et basculez-y les appelants.
  • Callbacks et hooks personnalisés. Utilisez l'export OpenTelemetry, ou gardez cette logique dans votre code.

Questions

Puis-je continuer à utiliser le SDK Python de LiteLLM ?
Oui. Appelez INFRO via le fournisseur compatible OpenAI de LiteLLM : model="openai/<INFRO model id>" avec api_base="https://api.infro.io/v1" et votre clé INFRO.
INFRO est-il open source comme LiteLLM ?
Non. INFRO est un service hébergé ; un déploiement auto-hébergé ou hybride est possible sous un accord Enterprise.
Qui paie les fournisseurs de modèles ?
Vous, directement, comme avec LiteLLM. INFRO est un abonnement et ajoute 0 % aux dépenses de modèles.

Migrez avec nous, ou seul

Le programme de migration transpose votre configuration LiteLLM en connexions, routes et budgets INFRO lors d'un appel, et migre le premier service avec vous. Vos fournisseurs continuent de vous facturer directement ; INFRO est un abonnement et ajoute 0 % aux dépenses de modèles.

Essai de 14 jours Réserver une session de migrationINFRO vs LiteLLMLire le démarrage rapide

Sources

Chaque affirmation de cette page sur LiteLLM provient de l'une de ces sources, lues le 19 octobre 2026. Rien n'est déduit d'un essai, d'un benchmark ou d'une conversation.