Retour au catalogue
LiteLLM: The Universal LLM Gateway (v1.82 - 2026 Edition)
Une série de podcasts complète sur LiteLLM, allant du Python SDK et de la gestion unifiée des exceptions jusqu'au Proxy Server, au load balancing, aux virtual keys, à l'observability, et aux fonctionnalités d'entreprise comme le RBAC et la MCP Gateway.
Lecture en cours
Click play to start
0:00
0:00
1
La pierre de Rosette des LLMs : Le Python SDK
Découvrez l'identité fondamentale de LiteLLM : une interface Python unifiée pour plus de 100 LLMs. Apprenez à intégrer LiteLLM dans votre base de code existante pour appeler Anthropic, Vertex ou Ollama sans modifier votre logique de parsing compatible OpenAI.
2
La magie de la traduction des paramètres
Ne vous souciez plus de savoir quel fournisseur prend en charge quel hyperparamètre. Découvrez comment le SDK de LiteLLM traduit automatiquement les inputs standards d'OpenAI comme temperature, tools et max_tokens pour tous les modèles en amont.
3
Gestion unifiée des exceptions
Écrivez vos blocs try-except une seule fois. Découvrez comment LiteLLM intercepte les erreurs personnalisées d'AWS, Google et Azure, en les mappant parfaitement vers les exceptions standards d'OpenAI comme RateLimitError.
4
La LLM Gateway : Configuration du Proxy Server
Sortez LiteLLM de votre code local pour l'intégrer à une plateforme centralisée. Apprenez à lancer le Proxy Server de LiteLLM via Docker et à configurer vos premiers endpoints à l'aide du fichier config.yaml.
5
Gestion centralisée des secrets
Gardez vos clés d'API hors des configurations en texte clair. Apprenez à connecter LiteLLM à des gestionnaires de secrets d'entreprise comme AWS Secrets Manager ou Azure Key Vault pour récupérer dynamiquement vos credentials.
6
Model Aliases : La mise à jour fantôme
Migrez vos utilisateurs vers de nouveaux modèles de manière silencieuse. Découvrez comment utiliser les Model Aliases dans LiteLLM pour mapper les requêtes d'un modèle vers un endpoint complètement différent sans altérer le code côté client.
7
Load Balancing pour un haut débit
Évitez les rate limits et les temps d'arrêt en routant le trafic intelligemment. Découvrez pourquoi simple-shuffle est la stratégie recommandée pour le load balancing en production sur plusieurs déploiements.
8
Pannes d'API et Fallbacks
Ne subissez plus jamais de temps d'arrêt de votre IA. Apprenez à configurer des fallbacks de modèles dans LiteLLM pour que, si votre fournisseur principal échoue, le trafic soit automatiquement redirigé vers un fournisseur de secours.
9
Context Window Fallbacks
Arrêtez de payer trop cher pour des fenêtres de contexte massives sur des prompts courts. Apprenez à utiliser les vérifications pre-call et les context window fallbacks pour router les documents surdimensionnés vers des modèles spécialisés.
10
Maîtriser les requêtes bloquées avec les Timeouts
Ne laissez pas des APIs lentes geler votre application. Découvrez comment configurer des global timeouts et des stream timeouts dans LiteLLM pour annuler les requêtes bloquées et déclencher des fallbacks rapides.
11
Virtual Keys pour le FinOps
Verrouillez l'utilisation de votre API avec précision. Apprenez à générer des virtual keys avec LiteLLM, en définissant des limites strictes de RPM, TPM et de budget pour protéger votre organisation contre les coûts d'IA incontrôlés.
12
Suivi des dépenses et Custom Tags
Attribuez chaque centime de dépense LLM avec précision. Apprenez à passer des tags de métadonnées dans vos requêtes et à générer des rapports de dépenses complets à l'aide de LiteLLM.
13
Caching pour la vitesse et les économies
Arrêtez de payer pour les mêmes réponses LLM encore et encore. Apprenez à configurer l'exact caching avec Redis et le semantic caching avec Qdrant pour réduire drastiquement la latence et les coûts d'API.
14
RBAC : Responsabiliser les Team Admins
Distribuez la gestion de la plateforme en toute sécurité. Comprenez le Role-Based Access Control (RBAC) de LiteLLM, en déléguant le pouvoir aux Org Admins et aux Team Admins sans compromettre la sécurité globale.
15
Security Guardrails
Ajoutez une couche de sécurité invisible à vos requêtes LLM. Apprenez à configurer des guardrails pre-call et post-call dans LiteLLM pour bloquer les prompt injections et masquer les PII avant qu'elles n'atteignent les fournisseurs externes.
16
Gestion dynamique des Callbacks
Donnez aux microservices le pouvoir de la confidentialité. Apprenez à utiliser le header x-litellm-disable-callbacks pour permettre aux requêtes d'API sensibles de se désengager du logging centralisé d'observability.
17
Observability prête à l'emploi
Obtenez une visibilité instantanée sur votre trafic LLM. Apprenez à acheminer la télémétrie, les traces et les exceptions vers des outils comme Langfuse et Sentry en utilisant de simples callbacks de succès et d'échec.
18
Métriques Prometheus et santé des Pods
Prenez le pouls de votre proxy. Découvrez comment exposer l'endpoint /metrics à Prometheus, suivre les in-flight requests et utiliser des custom tags pour segmenter les données dans Grafana.
19
Text-to-Speech universel
Standardisez votre génération vocale. Découvrez comment appeler des modèles Text-to-Speech de Gemini, Vertex et AWS Polly en utilisant exactement le même format d'endpoint audio compatible OpenAI.
20
Le pont Assistants API
Gérez l'état des conversations sans effort entre les fournisseurs. Apprenez comment LiteLLM enveloppe les modèles non natifs dans l'interface standard de l'Assistants API d'OpenAI, vous permettant d'utiliser les Threads et les Messages partout.
21
La MCP Gateway
Boostez vos modèles avec des outils de manière centralisée. Découvrez comment configurer des serveurs Model Context Protocol (MCP) HTTP, SSE ou STDIO dans LiteLLM, donnant à n'importe quel LLM accès à des capacités externes.
22
A2A : Suivi des agents autonomes
Prenez le contrôle des agents autonomes. Apprenez à invoquer des agents complexes LangGraph ou Bedrock via le proxy en utilisant le protocole A2A, permettant le regroupement des traces et le suivi unifié des dépenses.
23
Rotations de clés Zero-Downtime
Réalisez des transitions de sécurité sans temps d'arrêt. Apprenez à configurer des rotations de clés automatiques programmées et des périodes de grâce pour les virtual keys d'entreprise dans LiteLLM.
24
L'Admin UI et l'AI Hub
Rendez votre plateforme d'IA accessible à tous. Apprenez à gérer l'Admin UI, à ajuster les credentials de l'interface et à utiliser l'AI Hub pour permettre aux développeurs de découvrir en toute sécurité les modèles et agents autorisés.
Épisodes
1
La pierre de Rosette des LLMs : Le Python SDK
3m 44sDécouvrez l'identité fondamentale de LiteLLM : une interface Python unifiée pour plus de 100 LLMs. Apprenez à intégrer LiteLLM dans votre base de code existante pour appeler Anthropic, Vertex ou Ollama sans modifier votre logique de parsing compatible OpenAI.
Salut, c'est Alex de DEV STORIES DOT EU. LiteLLM : The Universal LLM Gateway, épisode 1 sur 24. Tu remplaces ta clé API OpenAI par une clé Anthropic, et soudain, toute ton application plante. Chaque provider structure ses inputs et outputs différemment, ce qui t'oblige à écrire et maintenir une logique de parsing custom pour chaque nouveau modèle. La pierre de Rosette des LLMs, le SDK Python LiteLLM, résout complètement ce problème.
On croit souvent à tort que LiteLLM est en concurrence avec LangChain. Ce n'est pas le cas. LiteLLM n'est pas un framework d'agents. Il n'orchestre pas les tools, ne gère pas la mémoire et ne chain pas les tâches entre elles. C'est simplement un drop-in replacement pour le client OpenAI.
Le SDK Python LiteLLM traduit plus d'une centaine d'APIs de providers différents vers le format exact de chat completion d'OpenAI. Tu n'as pas besoin d'apprendre les subtilités des APIs Vertex AI, Anthropic ou Hugging Face. Tu écris ton code une seule fois en utilisant le standard OpenAI, et LiteLLM gère la couche de traduction en background.
Le cœur de ce SDK est une interface unique et unifiée appelée la fonction completion. Quand tu utilises cette fonction, tu fournis une string pour le modèle. Cette string indique à LiteLLM quel provider contacter. Tu passes aussi les paramètres OpenAI standards, comme la temperature, les max tokens et la liste des messages. LiteLLM prend ces paramètres standards et les map aux bons champs pour le provider cible.
Imagine un scénario où tu veux appeler Claude 3.5 Sonnet. En utilisant le SDK Anthropic standard, tu devrais structurer tes blocs de prompt selon les exigences spécifiques de leur API de messages. Avec LiteLLM, tu appelles juste la fonction completion. Tu passes le nom du modèle pour Claude. Tu passes ton array de messages standard, en utilisant des dictionnaires avec les rôles user et system. Enfin, tu fournis ta clé API Anthropic, soit comme paramètre, soit comme variable d'environnement.
Voici le point clé. L'objet de réponse retourné par cette fonction est structuré exactement comme un objet chat completion d'OpenAI.
Quand tu veux extraire le texte généré par Claude, tu parcours exactement le même chemin que pour un modèle GPT. Tu regardes l'array choices. Tu prends le premier élément. Tu accèdes à l'objet message. Tu lis la propriété content. La logique de ton application n'a aucune idée que c'est Anthropic qui a généré le texte. La requête réseau sous-jacente a été traduite, envoyée au provider, et la réponse a été mappée vers le schéma OpenAI avant même d'atteindre tes variables.
Cette abstraction s'applique à toute l'interaction. Elle couvre les erreurs, les statistiques d'utilisation des tokens, et même les réponses en streaming. Si Anthropic retourne une erreur de rate limit, LiteLLM la map vers l'exception rate limit standard d'OpenAI. Ton code de gestion d'erreurs existant l'attrape sans modification. Si tu demandes une réponse en streaming, LiteLLM renvoie des chunks qui ressemblent exactement aux chunks de streaming d'OpenAI.
Tu peux itérer sur différents modèles en changeant simplement la valeur de la string du paramètre model, et en remplaçant la variable d'environnement pour la clé API. Le reste de ton code Python reste complètement statique. Tu n'es plus bloqué dans un seul écosystème juste parce que tu as écrit ton code d'intégration pour un provider spécifique.
La vraie valeur de l'interface unifiée de completion, c'est de découpler la logique de ton application des variations infinies des APIs des providers de modèles, transformant des changements d'infrastructure complexes en de simples remplacements de strings.
Merci d'avoir écouté, et happy coding à tous !
2
La magie de la traduction des paramètres
3m 26sNe vous souciez plus de savoir quel fournisseur prend en charge quel hyperparamètre. Découvrez comment le SDK de LiteLLM traduit automatiquement les inputs standards d'OpenAI comme temperature, tools et max_tokens pour tous les modèles en amont.
Salut, c'est Alex de DEV STORIES DOT EU. LiteLLM : La gateway LLM universelle, épisode 2 sur 24. Est-ce que Claude attend max tokens, max tokens to sample, ou complètement autre chose ? À chaque fois que tu changes de provider de modèle, tu dois généralement réécrire tout le payload de ta requête API pour coller à leurs conventions de nommage spécifiques. Parameter Translation Magic, c'est la feature qui fait disparaître ce problème.
Quand tu appelles la fonction de completion dans LiteLLM, tu écris ta requête uniquement avec le format de paramètre standard d'OpenAI. Tu n'as pas besoin de chercher les clés de dictionnaire spécifiques pour Anthropic, Vertex AI ou Cohere. La librairie intercepte tes inputs au format OpenAI et les traduit automatiquement dans la structure exacte dont le provider cible a besoin.
Regardons un scénario spécifique. Tu veux requêter un modèle Gemini de Vertex AI. Tu as besoin qu'il utilise le function calling, et tu veux que les réponses soient très déterministes, donc tu règles la temperature sur zéro virgule deux. Si tu codais une intégration directe, Vertex a sa propre façon, unique et très imbriquée, de définir les tools et de régler les configurations de génération du modèle. Avec LiteLLM, tu ignores ça complètement. Tu construis ton array de tools en utilisant la syntaxe JSON standard d'OpenAI. Tu passes cet array, avec ta valeur de temperature, directement dans le call de completion. LiteLLM récupère ces arguments OpenAI, les décompose, et construit le bon payload pour l'API Vertex AI avant d'envoyer la requête réseau.
Ce mapping automatique est incroyablement efficace, mais il introduit un edge case. Qu'est-ce qui se passe si tu passes un paramètre OpenAI que le modèle cible ne supporte tout simplement pas du tout ? Peut-être que tu spécifies une presence penalty, mais que le provider n'a pas de concept correspondant. Par défaut, LiteLLM est strict. Il va lever une exception et faire échouer le call de completion. C'est un choix de design délibéré. Ça t'empêche de perdre silencieusement une configuration qui pourrait être critique pour le comportement de ton application.
L'échec strict est sûr, mais ça peut être frustrant si tu routes dynamiquement les prompts utilisateurs vers des dizaines de modèles différents en production. Si tu veux que le call réussisse malgré des petites différences de paramètres, tu ajoutes un flag appelé drop params mis sur true dans ton call de completion. Quand tu actives ça, LiteLLM traduit quand même tout ce qu'il arrive à mapper avec succès. Mais s'il rencontre un paramètre OpenAI que le provider cible ne reconnaît pas, il supprime simplement ce paramètre non supporté du payload et envoie le reste de la requête. Le call réussit, et le paramètre non supporté est ignoré en toute sécurité.
Si tu préfères gérer les capacités proprement dans ton propre code plutôt que de te reposer sur des suppressions silencieuses, il y a un tool d'introspection intégré. Tu peux appeler une fonction helper nommée get supported openai params. Tu lui passes le nom du modèle en argument, et elle te retourne une liste de tous les paramètres OpenAI standards qui se mappent avec succès sur ce modèle spécifique. Ça te permet de vérifier ce qu'un modèle supporte réellement au runtime avant d'exécuter le call de completion.
Voici l'idée clé. La vraie valeur de la parameter translation, c'est qu'elle fait passer la spécification de l'API OpenAI d'un schéma spécifique à un vendor à un langage d'interface universel pour toute ta stack applicative.
Merci d'avoir écouté, happy coding tout le monde !
3
Gestion unifiée des exceptions
3m 06sÉcrivez vos blocs try-except une seule fois. Découvrez comment LiteLLM intercepte les erreurs personnalisées d'AWS, Google et Azure, en les mappant parfaitement vers les exceptions standards d'OpenAI comme RateLimitError.
Salut, c'est Alex de DEV STORIES DOT EU. LiteLLM : La gateway LLM universelle, épisode 3 sur 24. Écrire une logique de gestion d'erreurs custom pour quinze API d'IA différentes, c'est un super moyen de gâcher ton week-end. Chaque API a sa propre façon de te dire que tu envoies trop de requêtes ou que ton token est invalide. Pour t'éviter d'écrire des conditions à n'en plus finir, LiteLLM utilise le Unified Exception Handling.
Au lieu d'apprendre comment Anthropic, Cohere ou Google remontent leurs erreurs, tu n'as besoin de gérer qu'un seul standard. LiteLLM mappe directement toutes les exceptions des providers sous-jacents vers les types d'exceptions standards d'OpenAI. Si une requête échoue, la gateway intercepte l'erreur brute, la traduit en fonction du status code HTTP et de la réponse du provider, puis lève l'erreur OpenAI correspondante.
Imagine un scénario où tu utilises un endpoint d'inférence Hugging Face. Pendant les heures de pointe, l'endpoint est saturé de trafic. Hugging Face va rejeter la requête. Si tu appelais leur API directement, tu devrais parser leur erreur HTTP cinq zéro trois service unavailable spécifique, ou un message de throttling custom. Avec le mapping unifié des exceptions, tu n'as pas besoin d'un exception handler spécifique pour Hugging Face.
Tu structures ton code en utilisant un bloc try standard autour de ton appel de génération. Juste en dessous, tu ajoutes un bloc except conçu pour catcher une Rate Limit Error d'OpenAI. À l'intérieur de ce bloc, tu déclenches ta fonction d'exponential backoff standard. Ton application se met en pause, attend, et retry la requête. Si plus tard tu remplaces Hugging Face par Vertex AI, ta logique de backoff reste exactement la même. La Rate Limit Error d'OpenAI catche l'événement de throttling de Vertex de façon tout aussi fiable.
Ce mapping couvre l'ensemble des erreurs standards. Tu peux catcher une API Timeout Error d'OpenAI quand un serveur distant ne répond plus. Tu peux catcher une Authentication Error quand une clé API tourne ou expire. Tu peux gérer une API Connection Error en cas de coupure réseau, ou une Bad Request Error si ton payload est malformé. Le code de ton application traite tout l'écosystème IA comme s'il communiquait uniquement avec un seul provider prévisible.
Voici le point clé. Parfois, une abstraction trop propre masque trop de contexte. Une Bad Request Error générique d'OpenAI te dit que l'appel a échoué, mais tu as souvent besoin de savoir exactement pourquoi. Azure, par exemple, applique des filtres de content policy stricts. Si Azure rejette un prompt parce qu'il enfreint les règles de sécurité, le mapper vers une erreur OpenAI générique risque de faire sauter le safety flag spécifique que tu dois logger ou montrer à l'utilisateur.
Pour résoudre ça, LiteLLM attache un attribut appelé provider specific fields à l'objet exception. Quand tu catches une exception OpenAI dans ton code, tu peux inspecter cet attribut. Il contient un dictionnaire qui garde les données d'erreur originales, non mappées, qui viennent directement du provider. Tu obtiens le flow unifié try et except pour le routing et les retries, mais tu gardes les données granulaires pour le debugging et l'audit.
Tu construis tes systèmes résilients, tes retries et tes circuit breakers entièrement autour des classes d'exceptions d'OpenAI. Standardiser tes error boundaries empêche les modes d'échec spécifiques aux providers de déborder sur la logique cœur de ton application.
Merci d'avoir écouté, et happy coding à tous !
4
La LLM Gateway : Configuration du Proxy Server
3m 08sSortez LiteLLM de votre code local pour l'intégrer à une plateforme centralisée. Apprenez à lancer le Proxy Server de LiteLLM via Docker et à configurer vos premiers endpoints à l'aide du fichier config.yaml.
Salut, c'est Alex de DEV STORIES DOT EU. LiteLLM : La gateway LLM universelle, épisode 4 sur 24. Et si toute ton entreprise pouvait partager un seul endpoint LLM sans jamais exposer les clés d'API brutes du provider ? Passer d'une intégration SDK locale à une architecture centralisée change ta façon de gérer les accès. Voici la gateway LLM : Configurer le serveur proxy.
Beaucoup de développeurs pensent qu'introduire un proxy middleware custom nécessite d'écrire du code client custom pour communiquer avec. C'est faux. Le proxy LiteLLM parle le format natif de l'API OpenAI. N'importe quelle librairie, application ou script qui sait comment parler à OpenAI a juste besoin de mettre à jour sa base URL pour pointer vers ton nouveau proxy.
Pour démarrer le serveur proxy, tu as besoin d'un fichier de configuration. C'est un fichier YAML qui définit ta logique de routing. Le cœur de ce fichier est une section appelée la model list. Cette liste mappe les noms de modèles que tes applications internes vont requêter vers les vrais modèles du provider backend.
À l'intérieur de la model list, chaque entrée a besoin de deux éléments principaux. Premièrement, le model name. C'est l'alias que tu exposes à tes utilisateurs. Tu pourrais l'appeler internal-chat-model. Deuxièmement, un bloc appelé LiteLLM parameters. C'est là que tu configures la vraie destination. Cette distinction est importante. Le model name est ce que ton client demande, mais le bloc LiteLLM parameters définit ce qui traite réellement la requête.
Si tu fais du routing vers un deploy Azure OpenAI, ton bloc LiteLLM parameters va contenir la string spécifique du modèle Azure, ta base URL d'API Azure, et la version de l'API. Tu indiques aussi à LiteLLM quelle variable d'environnement contient la clé d'API. Tu ne hardcodes pas la clé directement dans le fichier YAML.
Une fois le fichier de configuration prêt, tu déploies le proxy en utilisant Docker. Tu utilises l'image officielle LiteLLM du GitHub Container Registry. Quand tu run le container Docker, tu exécutes trois étapes spécifiques. Tu mappes ton port local quatre mille sur le port quatre mille du container. Tu montes ton fichier de configuration YAML dans le container pour que le proxy puisse lire ta model list. Enfin, tu passes tes credentials de provider dans le container comme variables d'environnement.
Une fois que le container tourne, le proxy est live et écoute sur localhost port quatre mille. Tu le testes exactement comme tu testerais l'API officielle d'OpenAI. Tu fais une requête HTTP POST standard en utilisant un outil comme cURL. Tu cibles localhost port quatre mille, suivi du path slash chat slash completions. Dans le body de la requête, tu spécifies l'alias que tu as défini plus tôt comme model, et tu fournis ton array de messages.
Le proxy reçoit ce payload standard. Il lit l'alias demandé, le cherche dans ton fichier de configuration, et extrait les paramètres Azure. Il signe ensuite la requête avec ta clé d'API Azure, la forward à Microsoft, et traduit la réponse dans le format exact que ton client attend.
Voici le point clé. Le proxy abstrait complètement le provider backend de la couche applicative. Si tu décides de remplacer ton deploy Azure par un provider complètement différent le mois prochain, tu ne touches pas à une seule ligne de ton code applicatif. Tu mets juste à jour les LiteLLM parameters dans ton fichier de configuration YAML et tu restart le container.
La valeur principale du serveur proxy, c'est que tes applications clientes ne savent jamais, et n'ont jamais besoin de savoir, quel cloud provider génère réellement les tokens.
Merci d'avoir écouté, et happy coding tout le monde !
5
Gestion centralisée des secrets
3m 13sGardez vos clés d'API hors des configurations en texte clair. Apprenez à connecter LiteLLM à des gestionnaires de secrets d'entreprise comme AWS Secrets Manager ou Azure Key Vault pour récupérer dynamiquement vos credentials.
Bonjour, ici Alex de DEV STORIES DOT EU. LiteLLM : The Universal LLM Gateway, épisode 5 sur 24. Si la master API key de ton entreprise traîne en plaintext dans un fichier YAML sur un serveur de production, ton équipe de sécurité va passer un sale quart d'heure. Les credentials hardcodés sont un incident qui ne demande qu'à arriver. La solution, c'est le Centralized Secret Management.
Quand tu fais tourner une gateway, elle a besoin d'accéder aux API keys de ton provider upstream pour router le trafic correctement. L'approche par défaut, c'est souvent de les balancer dans une variable d'environnement locale ou directement dans le fichier de configuration principal. Le Centralized Secret Management change complètement ce pattern. Ça permet à la gateway de lire dynamiquement les credentials depuis un vault d'entreprise externe, comme AWS Secrets Manager, Azure Key Vault, Google Secret Manager ou HashiCorp Vault.
Pour activer cette connexion, tu configures deux champs spécifiques dans le bloc general settings de ton fichier de configuration. Le premier champ, c'est le key management system. Ici, tu définis l'identifiant de ton provider de vault. Si tu utilises AWS, tu le mets sur aws_kms. Le deuxième champ, ce sont les key management settings. C'est une structure imbriquée où tu fournis les paramètres de connexion exacts que ton vault spécifique demande, comme la région AWS cible ou d'autres détails d'authentification requis.
Une fois la connexion au vault établie, tu dois dire à tes configurations de routing de modèles individuelles de récupérer leurs clés depuis ce vault. Tu fais ça en utilisant un préfixe de string spécifique à la place de la clé réelle.
Voici le point clé. Au lieu de taper une string de clé réelle, tu tapes la phrase os point environ slash, suivie immédiatement du nom exact de ton secret tel qu'il existe dans le vault.
Prenons un scénario concret. Tu veux router le trafic vers un modèle Azure, et la vraie API key est stockée de manière sécurisée dans AWS Secrets Manager sous le nom azure api key production. Dans ton fichier de configuration, tu mets en place le bloc de routing du modèle. Mais pour le champ api key, tu mets la valeur sur os point environ slash azure api key production.
Quand la gateway process une requête pour ce modèle, elle voit le préfixe. Elle sait qu'elle ne doit pas utiliser cette string comme une clé littérale. À la place, elle fait un call sécurisé vers AWS Secrets Manager, demande la valeur pour ce nom de secret exact, et récupère la vraie clé pour authentifier la requête. La clé en plaintext ne touche jamais ton disque. Ton fichier de configuration reste complètement propre et safe pour être commit dans le version control.
Ça, ça couvre la récupération des credentials upstream dans la gateway. Mais l'intégration du secret manager va dans les deux sens. Elle peut aussi écrire de la data. Quand tu utilises la gateway pour générer de nouvelles clés de proxy virtuelles pour tes équipes d'ingénierie internes, tu peux configurer le système pour sauvegarder automatiquement ces clés nouvellement générées directement dans ton secret manager. Ça garantit que les credentials internes que tu émets sont stockés et gérés avec exactement les mêmes contrôles de sécurité que les credentials provider que tu consommes.
Tes fichiers de configuration définissent la structure de ton infrastructure de routing, mais ils ne devraient jamais contenir ses secrets. L'endroit le plus sûr pour stocker une API key dans la configuration de ta gateway, c'est nulle part.
Merci d'avoir écouté, happy coding tout le monde !
6
Model Aliases : La mise à jour fantôme
3m 29sMigrez vos utilisateurs vers de nouveaux modèles de manière silencieuse. Découvrez comment utiliser les Model Aliases dans LiteLLM pour mapper les requêtes d'un modèle vers un endpoint complètement différent sans altérer le code côté client.
Salut, c'est Alex de DEV STORIES DOT EU. LiteLLM : La gateway LLM universelle, épisode 6 sur 24. Et si tu pouvais migrer l’ensemble de ta base d'utilisateurs d’OpenAI vers Anthropic sans leur demander de mettre à jour une seule ligne de leur code d’intégration ? Ou faire passer discrètement un utilisateur du free-tier sur une alternative open-source sans casser la logique existante de son application ? Le mécanisme qui rend cette transition silencieuse possible s’appelle les Model Aliases.
Il est facile de confondre les alias avec le routing, alors séparons les deux. Le routing gère le load balancing entre plusieurs deployments du même modèle. Si tu as trois instances Azure OpenAI distinctes qui font tourner la même version de GPT-4, le routing distribue le trafic entrant équitablement entre elles pour éviter les rate limits. Les alias font quelque chose de complètement différent. Un alias intercepte le nom du modèle demandé et le mappe vers un modèle complètement différent derrière le proxy.
Tu appliques ce mapping au moment où tu crées une virtual key pour un client. Quand tu envoies ta requête à l'endpoint de génération de clés de LiteLLM, tu inclus un objet aliases dans ton payload. Cet objet est simplement un dictionnaire qui fait correspondre le nom du modèle que le client va demander avec le nom du modèle que tu as vraiment l'intention de servir.
Regardons un scénario concret. Tu as un segment d'utilisateurs du free-tier. Ils ont initialement construit leurs outils autour de GPT-4, et cette string exacte est actuellement hardcodée dans leurs requêtes réseau. Servir du GPT-4 à des utilisateurs non payants coûte cher, alors tu décides de rediriger leurs prompts vers un endpoint Mistral 7B interne et hautement optimisé.
Pour faire ça, tu génères une nouvelle virtual key spécifiquement pour ce groupe d'utilisateurs. Dans le payload de génération, tu définis un alias qui mappe la string GPT-4 directement vers le nom de ton deployment Mistral 7B. Tu donnes cette nouvelle virtual key aux utilisateurs. Ils ne modifient pas le code de leur application. Ils continuent d'envoyer des requêtes de chat completion standards à ton proxy, en demandant explicitement GPT-4.
Voici le point clé. Le proxy LiteLLM reçoit la requête entrante et authentifie la virtual key. Il lit la configuration liée à cette clé spécifique et repère ta règle d'alias. Avant de router le payload vers un provider externe, le proxy réécrit le paramètre model en mémoire. Il retire GPT-4 et le remplace par Mistral 7B. La requête part vers ton deployment Mistral interne, génère le texte, et route la réponse en retour vers le client à travers le proxy.
L'application cliente reçoit le format de réponse standard qu'elle attend. Ses parsers fonctionnent parfaitement, et l'application continue de fonctionner normalement. Les développeurs qui maintiennent cette application cliente ignorent complètement que le modèle de langage sous-jacent a été changé.
Parce que les alias sont attachés directement à des virtual keys individuelles plutôt qu'à la configuration globale du serveur, tu gardes un contrôle absolu sur tes différents segments d'utilisateurs. Une clé peut faire un alias du trafic vers un modèle moins cher pour les utilisateurs gratuits, pendant qu'une autre clé laisse passer le trafic premium sans modification. Tu peux aussi utiliser exactement la même logique pour gérer les deprecations de modèles. Quand un provider retire un ancien modèle, tu as juste à faire un alias de l'ancien nom vers la nouvelle version, ce qui évite à tous tes clients de devoir pusher des mises à jour de code en urgence. L'aspect le plus puissant d'une gateway de modèles n'est pas juste de gérer le trafic réseau, mais de découpler les attentes du client de la réalité physique de ton architecture backend.
Merci d'avoir écouté, happy coding tout le monde !
7
Load Balancing pour un haut débit
3m 08sÉvitez les rate limits et les temps d'arrêt en routant le trafic intelligemment. Découvrez pourquoi simple-shuffle est la stratégie recommandée pour le load balancing en production sur plusieurs déploiements.
Salut, c'est Alex de DEV STORIES DOT EU. LiteLLM : The Universal LLM Gateway, épisode 7 sur 24. Tu as enfin obtenu l'accès en production à Azure OpenAI, tu as lancé ton app, et tu as immédiatement rencontré une énorme erreur de rate limit lors de ton premier gros pic de trafic. Tu as le quota, mais c'est bottleneck dans une seule région. Le Load Balancing pour le High Throughput résout ce problème. Pour gérer de gros volumes de requêtes sans taper les limites, tu dois distribuer ton trafic sur plusieurs deploys identiques. Dans LiteLLM, tu fais ça en configurant un router. Tu regroupes plusieurs endpoints backend sous un seul nom de modèle logique. Disons que tu as une app qui tourne sur cinq deploys Azure répartis dans cinq régions géographiques différentes. Quand ton app demande une completion, le router décide laquelle de ces cinq régions reçoit la requête. Tu contrôles cette logique de décision en définissant une routing strategy dans les paramètres de ton router. L'approche intuitive, c'est le usage-based routing, où le système envoie la requête au deploy qui a actuellement le trafic le plus faible. Mais faire ça nécessite de tracker l'utilisation exacte des tokens en temps réel. Tracker le state en temps réel implique de faire un appel réseau vers un cache comme Redis pour chaque requête, avant même que le prompt ne parte. Ça ajoute une taxe de latence permanente à ton app. Pour les environnements de production à haut throughput, tu veux éviter ce hop supplémentaire. L'approche recommandée est une stratégie appelée simple-shuffle. Simple-shuffle ne tracke pas le state en direct. Il sélectionne aléatoirement un endpoint dans ton pool en fonction de poids prédéfinis. Quand tu ajoutes tes cinq deploys Azure à ton fichier de configuration, tu attribues une limite à chacun, généralement en Requests Per Minute, ou RPM. Tu peux aussi utiliser les Tokens Per Minute, ou TPM. Si ta région principale a une limite RPM de dix mille, et qu'une région secondaire a une limite RPM de cinq mille, simple-shuffle lit ces nombres et les traite comme des poids. Il va automatiquement router deux fois plus de trafic vers la région principale. Sous le capot, le router prend la liste des deploys disponibles pour ce modèle, prend en compte leurs poids RPM, et les mélange dans une liste randomisée pour cette requête spécifique. Il essaie le premier deploy de la liste. Comme la randomisation respecte strictement les limites RPM que tu as configurées, ton trafic se distribue parfaitement sur les cinq régions au fil du temps, esquivant les rate limits sans l'overhead d'un monitoring en temps réel. Pour mettre ça en place, tu ouvres ton fichier de configuration et tu définis le paramètre routing strategy sur simple-shuffle. Ensuite, dans ta model list, tu définis tes cinq endpoints Azure. Tu leur donnes à tous exactement le même nom de modèle. Enfin, tu attaches le paramètre RPM à chaque définition d'endpoint avec le poids que tu souhaites. Quand ton app appelle le router en utilisant ce nom de modèle, le router gère les maths et la randomisation automatiquement. Tu obtiens les avantages d'une architecture distribuée sans avoir besoin d'une dépendance Redis. La meilleure façon de gérer un scale massif, c'est souvent d'échanger un tracking en temps réel parfait contre une randomisation stateless et statistiquement prévisible. Merci d'avoir écouté, et happy coding à tous !
8
Pannes d'API et Fallbacks
3m 19sNe subissez plus jamais de temps d'arrêt de votre IA. Apprenez à configurer des fallbacks de modèles dans LiteLLM pour que, si votre fournisseur principal échoue, le trafic soit automatiquement redirigé vers un fournisseur de secours.
Salut, c'est Alex de DEV STORIES DOT EU. LiteLLM : La gateway LLM universelle, épisode 8 sur 24. Quand ton provider de modèle de langage principal subit une panne, est-ce que ton application plante avec lui, ou est-ce qu'elle pivote silencieusement vers un backup ? Aujourd'hui, on parle des pannes d'API et des fallbacks, le mécanisme exact qui garde ton système en ligne quand les endpoints externes plantent.
D'abord, c'est utile de distinguer ça d'un concept similaire. Les fallbacks, ce n'est pas du load balancing. Le load balancing distribue ton trafic de manière proactive sur plusieurs deployments actifs pour éviter de surcharger un seul endpoint. Les fallbacks, en revanche, sont des sauvetages strictement réactifs. Ils restent inactifs pendant le fonctionnement normal et ne s'activent qu'après une panne définitive.
Le but principal, c'est de maintenir un uptime élevé, idéalement d'atteindre la barre des 99,9 %, même quand tes providers en amont n'y arrivent pas. Les API externes vont inévitablement renvoyer des erreurs 500 internal server error ou des exceptions 429 rate limit. Quand ça arrive, une configuration de fallback dit au proxy d'intercepter l'erreur au vol et de router la requête vers un provider alternatif, ce qui protège complètement le code de ton application de l'interruption.
Tu configures ça dans le fichier YAML de configuration de ton proxy en utilisant un array fallbacks. Prenons un scénario concret. Ton deployment principal est gpt-4. Tu veux t'assurer que si gpt-4 tombe hors ligne, le proxy essaiera automatiquement claude-3-opus à la place.
Dans ton fichier de configuration, tu définis le setup de ton modèle gpt-4 comme d'habitude. À l'intérieur de cette définition de modèle spécifique, tu ajoutes une clé fallbacks. La valeur de cette clé est simplement un array de strings, où chaque string est le nom d'un autre modèle défini dans ta configuration. Tu ajoutes claude-3-opus à cet array.
Quand ton application envoie un prompt au proxy pour demander gpt-4, LiteLLM le route vers l'endpoint principal. Si cet endpoint renvoie une erreur, la logique du proxy l'attrape. Si tu as configuré des retries, il essaiera peut-être l'endpoint principal encore quelques fois. Mais une fois que le principal échoue définitivement, le proxy déclenche la séquence de fallback.
C'est là que ça devient intéressant. Le proxy prend exactement le prompt et les paramètres d'origine. Comme LiteLLM normalise le format de l'API, il traduit de manière transparente la requête au format OpenAI vers le format Anthropic requis par Claude. Il envoie immédiatement la requête traduite à l'endpoint de backup. Le code de ton application n'a pas besoin de gérer la logique d'erreur, de réécrire le prompt, ou de gérer les clés d'API pour le deuxième provider. Le proxy gère tout le pivot en interne.
Tu n'es pas limité à un seul backup. L'array fallbacks accepte une liste de modèles. Si ton gpt-4 principal échoue, et qu'ensuite ton premier fallback claude-3-opus échoue aussi, le proxy passe au nom suivant dans l'array. Il parcourt la liste séquentiellement. S'il atteint la fin de l'array et que chaque modèle de backup échoue, c'est seulement à ce moment-là que le proxy renvoie une erreur à ton application cliente.
Voici le point clé. En empilant divers modèles de fallback dans ta configuration, tu isoles efficacement le code de ton application de l'instabilité externe, transformant les pannes sévères de providers en de simples pics de latence invisibles pour tes utilisateurs finaux.
Merci d'avoir écouté, happy coding à tous !
9
Context Window Fallbacks
3m 10sArrêtez de payer trop cher pour des fenêtres de contexte massives sur des prompts courts. Apprenez à utiliser les vérifications pre-call et les context window fallbacks pour router les documents surdimensionnés vers des modèles spécialisés.
Salut, c'est Alex de DEV STORIES DOT EU. LiteLLM : La gateway LLM universelle, épisode 9 sur 24. Utiliser un modèle avec un contexte de 128k qui coûte cher pour chaque requête utilisateur, c'est un énorme gaspillage d'argent. Mais si tu utilises par défaut un modèle plus petit et moins cher, un utilisateur qui upload un énorme PDF va immédiatement faire crasher ton application. Le mécanisme qui résout ce problème s'appelle les Context Window Fallbacks.
Tu pourrais penser que le fallback routing n'intervient qu'après que l'API du provider ait renvoyé un code d'erreur. C'est vrai pour les fallbacks de fiabilité généraux, mais les limites de contexte fonctionnent différemment. LiteLLM peut gérer la taille des prompts de manière proactive grâce à un paramètre appelé enable pre-call checks. Quand tu passes ce booléen à true dans la configuration de ton router, le proxy stoppe la requête et calcule le nombre exact de tokens du prompt avant même que le provider ne la voie.
Voici l'idée clé. Tu configures un modèle principal, comme un modèle très économique, et dans ce même bloc de configuration, tu définis une liste de context window fallbacks qui pointe vers un modèle beaucoup plus grand. Quand une nouvelle requête arrive, le pre-call check s'exécute. Si le nombre de tokens calculé rentre dans la limite du modèle principal, la requête se poursuit normalement. Si le prompt est trop grand, LiteLLM abandonne complètement la route principale. Il transfère instantanément la requête vers le modèle de fallback plus grand.
Ça veut dire que tu ne reçois jamais d'erreur de context length de la part de l'API upstream. Ça veut aussi dire que tu évites la pénalité de latence liée à l'attente qu'un provider rejette le payload initial. L'application qui fait la requête n'a aucune idée que le routing a changé en arrière-plan.
LiteLLM s'appuie sur son model registry interne pour connaître les limites de contexte exactes des différents providers. Cependant, tu pourrais vouloir imposer des limites plus strictes. Peut-être que tu veux déclencher le fallback plus tôt pour laisser plus de place aux output tokens générés, ou peut-être que tu fais du routing vers un custom deployment avec une allocation mémoire non standard. Tu gères ça en surchargeant le paramètre max input tokens directement dans la configuration de ton modèle. Spécifier cette valeur force le proxy à utiliser ton plafond personnalisé lors de l'évaluation du pre-call check.
Pense à un trafic applicatif standard. Un utilisateur pose une simple question texte. Le proxy compte cinquante tokens, valide que ça passe, et le route vers GPT-3.5. Quelques minutes plus tard, ce même utilisateur upload un énorme PDF contenant quatre-vingt mille tokens. Le proxy calcule la nouvelle taille, voit que ça dépasse la limite de GPT-3.5, et le redirige automatiquement vers GPT-4-128k. La logique de ton application reste complètement statique. Tu ne paies pour le modèle premium que quand le payload l'exige vraiment.
Déplacer la validation des tokens hors du code de ton application et vers la couche proxy transforme ta stratégie de fallback d'un simple filet de sécurité passif en un moteur actif d'optimisation des coûts.
Merci d'avoir écouté, happy coding tout le monde !
10
Maîtriser les requêtes bloquées avec les Timeouts
4m 01sNe laissez pas des APIs lentes geler votre application. Découvrez comment configurer des global timeouts et des stream timeouts dans LiteLLM pour annuler les requêtes bloquées et déclencher des fallbacks rapides.
Bonjour, c'est Alex de DEV STORIES DOT EU. LiteLLM : la gateway LLM universelle, épisode 10 sur 24. Rien de pire pour l'expérience utilisateur qu'un chatbot qui affiche un loading spinner pendant quarante-cinq secondes juste parce qu'une API en amont a planté silencieusement. Tu as besoin d'un moyen fiable de couper instantanément les connexions mortes pour que ton système puisse récupérer. On résout ça en maîtrisant les requests bloquées grâce aux timeouts.
Quand tu routes du trafic vers des modèles de langage externes, les latences réseau et les pannes de provider sont inévitables. Si un provider arrête de répondre, le comportement par défaut de beaucoup de clients HTTP est de garder la connexion ouverte pendant longtemps. LiteLLM intercepte ce problème en utilisant deux mécanismes de timeout distincts. Le premier, c'est le paramètre de timeout standard. Ce paramètre dicte le temps total maximum que LiteLLM va attendre pour qu'une request complète se termine, du moment où elle est envoyée jusqu'au dernier caractère généré.
Si tu définis un timeout standard de trente secondes, et que le modèle met trente-et-une secondes pour écrire une longue réponse, LiteLLM va annuler la request. Ça marche très bien pour les tâches en background ou les générations courtes sans streaming. Cependant, appliquer un timeout total à une application en streaming crée un problème structurel. Une réponse complète peut légitimement prendre soixante secondes à streamer vers l'utilisateur. Si tu définis un timeout total court pour attraper les requests bloquées, tu vas tuer accidentellement des générations longues et parfaitement saines.
C'est là que ça devient intéressant. LiteLLM propose un deuxième paramètre appelé stream timeout. Ce paramètre mesure spécifiquement le temps jusqu'au premier token. Il contrôle exactement combien de temps la gateway va attendre pour recevoir le premier chunk de données du provider. Une fois que ce premier morceau de données arrive, le chrono du stream timeout s'arrête, et la connexion reste ouverte pour le reste de la génération.
Prenons un scénario concret. Tu routes du trafic vers un endpoint Azure OpenAI principal. Dans ton fichier de configuration, tu définis ton bloc de modèle et tu ajoutes le paramètre stream timeout, en le réglant sur deux secondes. Un utilisateur soumet un prompt complexe. LiteLLM transfère cette request à Azure. Normalement, le serveur en amont traite le prompt et renvoie le premier chunk en une fraction de seconde. Mais dans ce cas précis, le nœud Azure spécifique plante.
La gateway commence à compter. Une seconde passe. Deux secondes passent. Le premier chunk n'arrive pas. Comme tu as défini un stream timeout de deux secondes, LiteLLM refuse d'attendre que le timeout HTTP standard se déclenche. Il coupe la connexion de force exactement au bout de deux secondes.
Annuler la request morte n'est que la moitié de l'avantage architectural. En forçant un échec rapide, LiteLLM active immédiatement ta logique de fallback. Au moment où la request Azure fait un timeout, la gateway reroute exactement le même prompt utilisateur vers le prochain nœud sain et disponible dans ta liste de déploiement. L'utilisateur subit un délai de deux secondes à peine perceptible avant que le texte ne commence à streamer, évitant complètement une interface figée.
Tu as la flexibilité d'appliquer ces règles à différents niveaux. Tu peux appliquer un timeout global sur toutes les requests routées, ou tu peux les ajuster finement par modèle. Un modèle lourd de raisonnement logique pourrait nécessiter un stream timeout plus souple de cinq ou dix secondes, alors qu'un modèle de classification rapide devrait faire un failover après juste une seconde.
La réactivité de ton application dépend non seulement de la vitesse à laquelle ton provider principal réussit, mais aussi de l'agressivité avec laquelle tu forces une connexion bloquée à échouer. Merci d'avoir écouté, happy coding tout le monde !
11
Virtual Keys pour le FinOps
3m 38sVerrouillez l'utilisation de votre API avec précision. Apprenez à générer des virtual keys avec LiteLLM, en définissant des limites strictes de RPM, TPM et de budget pour protéger votre organisation contre les coûts d'IA incontrôlés.
Salut, c'est Alex de DEV STORIES DOT EU. LiteLLM : La passerelle LLM universelle, épisode 11 sur 24. Un script hors de contrôle écrit par un développeur junior peut facilement faire grimper une facture OpenAI à dix mille dollars en une nuit. La plateforme du provider sous-jacent continue d'accepter les requêtes aussi vite que la boucle peut les envoyer. Les virtual keys pour le FinOps sont le moyen d'empêcher ça avant que ça n'arrive.
Il y a une confusion fréquente entre les master keys et les virtual keys. Tu ne dois jamais donner ta master key à un développeur. La master key est ton credential d'administration. Son but principal est d'authentifier ta plateforme pour créer des virtual keys. Les virtual keys sont les credentials restreints que tu donnes vraiment aux développeurs ou aux applications pour qu'ils les utilisent dans leur code.
Tu crées un nouveau credential en faisant une requête HTTP POST sur l'endpoint key generate de ton proxy LiteLLM. Tu autorises cette requête en utilisant ta master key comme bearer token. C'est dans le body de cette requête que tu définis les garde-fous financiers.
Imagine un scénario où tu provisionnes un accès pour un stagiaire d'été. Tu veux t'assurer qu'il a suffisamment d'accès pour construire un prototype, mais tu as besoin d'une garantie absolue qu'il ne va pas cramer ton budget d'infrastructure. Tu passes deux paramètres spécifiques dans ton payload JSON pour imposer ça.
Premièrement, tu définis le plafond financier en configurant le paramètre max budget. Si tu mets cette valeur à dix, tu alloues exactement dix dollars américains à cette clé spécifique. C'est une hard limit à vie. Une fois que le coût total de tous les prompts et completions liés à cette clé atteint dix dollars, la clé est automatiquement désactivée et rejettera toutes les requêtes suivantes.
Deuxièmement, tu contrôles la vélocité de ces requêtes en configurant le paramètre RPM limit. RPM signifie requests per minute. Si tu mets le RPM limit à un, le proxy impose strictement une fenêtre d'une requête toutes les soixante secondes. Si une boucle infinie accidentelle dans le code du stagiaire essaie de lancer cent requêtes d'un coup, le proxy traite la première et rejette immédiatement les quatre-vingt-dix-neuf autres avec une erreur de rate limit standard.
Quand tu envoies ce payload à l'endpoint generate, LiteLLM traite les règles et renvoie une réponse contenant la virtual key qui vient d'être générée. Cette clé a l'air identique à un credential de provider standard, commençant généralement par un préfixe sk. Tu donnes cette string au stagiaire.
Voici le point crucial. Le développeur utilise cette virtual key exactement comme il le ferait avec une clé OpenAI ou Anthropic, en faisant pointer sa client library standard vers l'URL de ton proxy LiteLLM au lieu de l'internet public. Quand une requête arrive, le proxy l'intercepte. Il interroge sa base de données interne pour vérifier que la virtual key existe. Il vérifie ensuite si la clé a dépassé son budget de dix dollars ou sa limite de vélocité d'une requête par minute.
Si la requête passe les deux vérifications, le proxy échange la virtual key contre ta vraie clé API d'entreprise et transfère le payload au provider. Quand le provider répond, le proxy calcule le coût exact des tokens de prompt et de completion en se basant sur les prix publics de ce modèle spécifique. Il déduit cette fraction de centime du budget de dix dollars de la virtual key, enregistre la transaction, et renvoie la réponse au développeur. Le développeur n'a absolument pas conscience du swap de credential sous-jacent ou de la comptabilité interne.
En appliquant les limites au niveau de la couche proxy, les virtual keys interceptent les requêtes non autorisées ou hors de contrôle avant même qu'elles n'atteignent le provider de facturation, garantissant mathématiquement qu'un script compromis ou mal écrit ne pourra jamais dépasser son budget alloué.
Merci d'avoir écouté, et happy coding à tous !
12
Suivi des dépenses et Custom Tags
3m 28sAttribuez chaque centime de dépense LLM avec précision. Apprenez à passer des tags de métadonnées dans vos requêtes et à générer des rapports de dépenses complets à l'aide de LiteLLM.
Salut, c'est Alex de DEV STORIES DOT EU. LiteLLM : Le gateway LLM universel, épisode 12 sur 24. Ton directeur financier vient de débarquer et te demande exactement quelle nouvelle feature du produit est en train de cramer le budget IA mensuel. Tu ouvres le dashboard de ton provider, mais tout ce que tu vois, c'est une seule énorme facture globale pour toute la boîte. Tu n'as aucune réponse. Le Spend Tracking et les custom tags dans LiteLLM règlent ce problème.
Quand tu routes des requêtes via LiteLLM, le proxy calcule automatiquement le coût de chaque completion en fonction du modèle spécifique et du nombre de tokens. Un montant total en dollars ne sert à rien si tu ne peux pas l'attribuer à une source précise. La façon la plus simple de regrouper ces dépenses, c'est d'utiliser le paramètre user standard dans ton call de chat completion. Tu passes une string unique qui représente ton client final. LiteLLM intercepte ça, calcule le coût et le loggue sur cet user ID spécifique.
Le tracking par user résout un problème, mais souvent, un seul user déclenche plusieurs process backend. Disons que tu as un workload de classification de documents, et que le service facturation a besoin d'un rapport qui regroupe les dépenses par background jobs spécifiques. Un user ID ne t'aide pas ici. C'est là que les custom tags entrent en jeu. LiteLLM te permet d'attacher un array de strings à n'importe quelle requête, et il va tracker les dépenses sur ces strings exactes.
Voici le point clé. Les librairies standard comme le SDK officiel d'OpenAI ou LangChain ne connaissent pas nativement les metadata de LiteLLM. Si tu essaies de passer un paramètre non reconnu appelé metadata, le SDK va le virer ou throw une erreur avant même que la requête n'atteigne le proxy. Pour contourner ça, tu utilises un paramètre appelé extra body. C'est une escape hatch standard intégrée dans les SDK modernes, spécifiquement pour injecter des custom fields.
Voyons comment faire ça avec une requête LangChain. Tu configures ton objet chat model standard. Quand tu appelles la méthode invoke, tu passes ton prompt comme d'habitude. En plus du prompt, tu passes un paramètre nommé extra body. Tu le définis sur un dictionnaire. À l'intérieur de ce dictionnaire, tu crées une clé appelée metadata. Dans metadata, tu ajoutes une clé appelée tags, qui pointe vers un array de strings. Tu pourrais passer une string comme job ID quatre zéro deux. LangChain package cet extra body exactement tel quel et l'envoie sur le réseau. LiteLLM reçoit le payload, extrait tes tags du bloc metadata, et attache le coût précis de ce call LLM au job ID quatre zéro deux.
Ça, c'est pour les inputs. Qu'en est-il des outputs ? Une fois que ton trafic passe avec ces tags, tu dois pull les données. Tu fais ça en requêtant l'endpoint global spend report sur ton proxy LiteLLM. Tu fais une requête HTTP GET standard vers cet endpoint. Le proxy retourne un payload JSON qui détaille exactement où l'argent est parti. Il regroupe tes dépenses totales par clé API, par user, et surtout, par chaque custom tag que tu as fourni. Tu peux donner ça directement à ton service facturation. Ils peuvent voir instantanément que le job de classification de documents a coûté exactement quatre dollars et vingt centimes, peu importe quel modèle sous-jacent a géré le routing réel.
Tagger ton trafic au niveau du proxy signifie que la granularité de ta facturation n'est plus dictée par la façon dont ton cloud provider structure ses factures ; elle est entièrement définie par le contexte de ta propre application.
Merci d'avoir écouté, et happy coding tout le monde !
13
Caching pour la vitesse et les économies
3m 21sArrêtez de payer pour les mêmes réponses LLM encore et encore. Apprenez à configurer l'exact caching avec Redis et le semantic caching avec Qdrant pour réduire drastiquement la latence et les coûts d'API.
Bonjour, ici Alex de DEV STORIES DOT EU. LiteLLM : la Gateway LLM universelle, épisode 13 sur 24. Pourquoi payer une API externe pour générer mille fois la même explication de base ? Tu crames des crédits et tu obliges les utilisateurs à attendre des calculs qui ont déjà été faits. Résoudre cette inefficacité, c'est tout l'enjeu du caching pour gagner en vitesse et faire des économies.
LiteLLM gère le caching entièrement au niveau du proxy. Quand une requête arrive, le proxy vérifie s'il a déjà vu exactement ce prompt. Si c'est le cas, il renvoie immédiatement la réponse stockée. La latence passe de plusieurs secondes à quelques millisecondes, et le coût de l'API tombe à zéro. Pour mettre ça en place, tu utilises ton fichier config point yaml. Tu actives le caching dans ton bloc global settings en mettant cache sur true, et tu spécifies ton type de cache. Redis est le backend standard pour le caching en exact match. Tu fournis ton host, ton port et ton mot de passe Redis, et le proxy s'occupe de stocker les paires input-output.
Mais le caching exact est fragile. Il cherche un string match parfait. Si un utilisateur demande, écris un poème sur LiteLLM, et qu'un autre demande, crée un poème LiteLLM, un cache exact voit deux requêtes complètement différentes. Il transfère la deuxième requête au modèle de langage lourd, ce qui fait perdre du temps et de l'argent sur une tâche redondante juste parce que la formulation a légèrement changé.
C'est là qu'intervient le semantic caching. Au lieu de comparer des strings de texte brut, le semantic caching compare le sens profond des prompts. LiteLLM supporte Qdrant, une base de données vectorielle, pour gérer ça. Quand tu configures le semantic caching, tu dois spécifier un modèle d'embedding en plus de ton modèle de génération principal. Quand une requête arrive, le proxy passe d'abord le prompt au modèle d'embedding. Ce modèle convertit le texte en un vecteur, qui est une représentation mathématique du sens du prompt.
Le proxy interroge ensuite Qdrant pour voir si un vecteur similaire existe déjà dans le cache. Parce que, écris un poème, et, crée un poème, partagent la même intention sémantique, leurs vecteurs se retrouvent très proches dans l'espace. Qdrant détecte cette similarité. Si le match est assez proche, le proxy récupère la réponse en cache du premier utilisateur et la livre au deuxième. Tu sautes complètement l'étape lourde de génération de texte, et tu ne paies qu'une fraction de centime pour le lookup rapide de l'embedding.
Configurer ça demande quelques lignes de plus dans ton config point yaml. Tu changes le type de cache pour qdrant semantic. Tu définis les paramètres spécifiques à Qdrant, comme l'URL du endpoint Qdrant et ton API key. Plus important encore, tu définis un similarity threshold. C'est une valeur décimale entre zéro et un. Un threshold élevé, comme zéro virgule quatre-vingt-dix-neuf, exige une formulation quasi identique. Un threshold plus bas, comme zéro virgule huit, capte des variations plus larges, mais augmente le risque de renvoyer une réponse obsolète ou un peu hors sujet si deux prompts se ressemblent mais ont des intentions différentes.
Voici l'idée clé. Le semantic caching n'est pas juste un mécanisme de stockage, c'est un filtre actif pour l'intention de l'utilisateur. Ajuster ton similarity threshold est la seule chose qui te sépare d'une réduction massive des coûts et du renvoi de réponses non pertinentes à tes utilisateurs.
Merci d'avoir écouté, happy coding tout le monde !
14
RBAC : Responsabiliser les Team Admins
3m 25sDistribuez la gestion de la plateforme en toute sécurité. Comprenez le Role-Based Access Control (RBAC) de LiteLLM, en déléguant le pouvoir aux Org Admins et aux Team Admins sans compromettre la sécurité globale.
Bonjour, ici Alex de DEV STORIES DOT EU. LiteLLM : La Gateway LLM universelle, épisode 14 sur 24. Tu es platform engineer, et tu passes la moitié de ta journée à répondre à des messages qui demandent de nouvelles clés API ou des augmentations de budget. Chaque onboarding de développeur se transforme en ticket IT qui bloque son travail et te fait perdre du temps. La solution, c'est de déléguer le contrôle sans perdre la supervision, en utilisant le Role-Based Access Control.
LiteLLM supporte quatre rôles utilisateurs spécifiques pour gérer cette délégation. Ce sont le proxy admin, l'org admin, le team admin et l'internal user. Le proxy admin est tout en haut. Si tu fais un deploy de LiteLLM, tu es le proxy admin. Tu configures les modèles, tu mets en place la base de données et tu définis les règles globales. Mais tu ne devrais pas gérer les demandes de clés au quotidien. C'est là que la hiérarchie entre en jeu.
Tu peux regrouper ton entreprise en organisations, qui représentent d'énormes départements, et en teams, qui sont des groupes de travail spécifiques au sein de ces départements. L'org admin peut gérer les teams au sein de son organisation spécifique. Mais le vrai pouvoir opérationnel appartient au team admin.
Voici l'idée clé. Tu peux déléguer toutes les tâches administratives locales à un chef de département en le nommant team admin. En tant que proxy admin, tu configures la structure initiale une bonne fois pour toutes. Tu crées une team, tu appliques une limite de budget stricte de cinq cents dollars par mois, et tu assignes le lead developer comme team admin. Après ça, tu sors complètement de la boucle.
Le team admin a maintenant l'autonomie pour gérer ses propres ingénieurs. Il peut se connecter à l'UI ou utiliser l'API pour ajouter de nouveaux utilisateurs à sa team. Il peut générer de nouvelles clés API pour ces développeurs et surveiller les dépenses globales de son groupe spécifique. Point crucial, toute clé créée par le team admin ou ses ingénieurs est automatiquement liée à ce budget d'équipe de cinq cents dollars. Le team admin a un contrôle local total, mais il ne peut pas dépenser un seul centime au-delà de la limite imposée par le proxy admin.
En dessous du team admin, il y a l'internal user. C'est le rôle attribué aux développeurs standards qui écrivent le code. Un internal user a un accès restreint. Il peut voir ses propres dépenses de tokens et, si le team admin l'autorise, générer ses propres clés API personnelles. Sa vision du système est strictement limitée à lui-même. Il ne peut pas voir le budget global de la team, il ne peut pas voir les clés qui appartiennent à ses collègues, et il ne peut certainement pas modifier les paramètres de la team.
Pour configurer ça de manière programmatique, le proxy admin fait une seule requête API vers l'endpoint de création de team. Tu passes le nom de la team, le paramètre de budget max, et un array d'user IDs taggés avec le rôle team admin. Le système retourne un team ID. À partir de là, le chef de département utilise ce team ID pour router ses propres requêtes de gestion, en contournant complètement l'équipe de platform engineering.
Le Role-Based Access Control dans LiteLLM, ce n'est pas juste masquer des boutons dans une UI, c'est contraindre physiquement les dépenses de tokens au niveau du groupe, tout en repoussant la gestion des clés vers les personnes qui dirigent réellement les projets.
Merci d'avoir écouté, happy coding tout le monde !
15
Security Guardrails
3m 37sAjoutez une couche de sécurité invisible à vos requêtes LLM. Apprenez à configurer des guardrails pre-call et post-call dans LiteLLM pour bloquer les prompt injections et masquer les PII avant qu'elles n'atteignent les fournisseurs externes.
Salut, c'est Alex de DEV STORIES DOT EU. LiteLLM : La gateway LLM universelle, épisode 15 sur 24. Compter sur un modèle de langage pour bien se comporter n'est pas une stratégie de sécurité. Si un utilisateur colle par erreur des données client sensibles dans un prompt, demander au modèle de les ignorer poliment, c'est déjà trop tard. Il te faut un videur à l'entrée, et c'est exactement ce qu'offrent les Security Guardrails.
Les Security Guardrails dans LiteLLM agissent comme une couche de sécurité invisible entre les clients de ton application et les providers de modèles de langage. Ils interceptent le trafic API en deux phases distinctes. La première phase s'appelle pre call. Elle s'exécute après que LiteLLM a reçu la requête entrante de ton application, mais juste avant de transférer ce payload au provider externe. La deuxième phase s'appelle post call, et elle se déclenche après que le modèle a généré sa réponse, mais avant que LiteLLM ne renvoie cette réponse au client initial.
Tu définis toute cette logique de routage directement dans ton fichier config point yaml. Dans le bloc des paramètres du proxy, tu définis tes guardrails en spécifiant un endpoint ou une intégration supportée, puis en lui assignant un mode, soit pre call, soit post call.
Prenons un scénario concret avec un guardrail pre call. Imaginons qu'un employé demande à un modèle hébergé dans le cloud de résumer un ticket de support, mais que ce ticket contienne des numéros de sécurité sociale américains. Tu ne veux absolument pas que ces numéros quittent ton réseau interne. Tu peux configurer Microsoft Presidio comme ton guardrail pre call. Quand l'application envoie le prompt, LiteLLM intercepte la requête et transmet le texte à Presidio. Presidio scanne le texte, repère le numéro de sécurité sociale et le remplace par un masque générique. LiteLLM prend ensuite ce prompt nettoyé et l'envoie sur internet au cloud provider. Le modèle externe génère un résumé à partir du texte masqué, et le code de ton application continue de tourner comme si de rien n'était.
Et voici le point clé. Tu n'as pas besoin d'appliquer ces règles globalement sur tout ton trafic. LiteLLM te permet d'attacher des guardrails au niveau spécifique du modèle. C'est crucial quand tu gères une architecture hybride. Tu peux configurer ton routage pour que n'importe quel prompt envoyé à un modèle dans le cloud public passe par le guardrail strict de masquage des PII. Par contre, si tu routes exactement le même prompt vers un modèle open source qui tourne sur ton propre hardware on-premise, tu laisses simplement le guardrail en dehors du bloc de configuration de ce modèle. Le modèle local traite les données brutes, non masquées, parce que l'information ne franchit jamais la limite de ton réseau. Tu évites un overhead de traitement inutile et tu préserves le contexte exact.
Le mode post call fonctionne avec exactement le même flux, mais sur le trajet retour. Quand le modèle externe répond, LiteLLM fait passer l'output à travers tes guardrails post call. Ça te permet d'évaluer le texte pour détecter du langage toxique, des URL internes hallucinées ou des mentions non autorisées de concurrents avant même que l'utilisateur ne le voie. Si le guardrail post call flag le contenu, LiteLLM intercepte le trajet retour. Il bloque le texte et renvoie une erreur de sécurité au client au lieu de livrer l'output dangereux.
En gérant ça directement au niveau du proxy, l'architecture de ton application reste complètement inchangée. Tes développeurs envoient juste des requêtes de complétion standards, et le proxy applique tes règles de conformité. Les couches de sécurité les plus fiables sont celles dont le code de ton application n'a jamais à se soucier. Merci d'avoir écouté, et happy coding à tous !
16
Gestion dynamique des Callbacks
3m 35sDonnez aux microservices le pouvoir de la confidentialité. Apprenez à utiliser le header x-litellm-disable-callbacks pour permettre aux requêtes d'API sensibles de se désengager du logging centralisé d'observability.
Bonjour, ici Alex de DEV STORIES DOT EU. LiteLLM : The Universal LLM Gateway, épisode 16 sur 24.
Tu veux logger tout le trafic LLM pour le debugging, mais que se passe-t-il quand un microservice soumet des données de conformité ultra sensibles qui ne peuvent absolument pas être sauvegardées ? Tu pourrais te dire qu'il faut désactiver l'observabilité globalement, rendant tout ton système aveugle juste pour protéger quelques routes API spécifiques. Le Dynamic Callback Management résout ce problème en te permettant de contrôler le logging requête par requête.
Dans un setup LiteLLM standard, les callbacks gèrent l'envoi des payloads de tes requêtes et réponses vers des plateformes d'observabilité externes. Tu configures des plateformes comme Langfuse ou Datadog au niveau du proxy, et par défaut, elles capturent tout ce qui passe. L'idée reçue, c'est que ce logging est un système du tout ou rien. On pense souvent que pour gérer des données sensibles, il faut faire un deploy d'un proxy complètement séparé avec le logging désactivé. Le Dynamic Callback Management t'évite tout ce travail supplémentaire.
Prenons l'exemple d'un microservice qui gère des dossiers médicaux. L'application doit traiter les symptômes des patients via un modèle de langage, mais envoyer ces données sensibles à une stack de logging tierce enfreint les règles de conformité. Pour éviter cette fuite, le microservice ajoute simplement un header HTTP spécifique à sa requête sortante. Ce header s'appelle x-litellm-disable-callbacks. Tu définis sa valeur avec une liste séparée par des virgules des plateformes spécifiques que tu veux contourner.
Pour le service de dossiers médicaux, le microservice passe le header avec la valeur langfuse virgule datadog. Quand le proxy LiteLLM reçoit cette requête, il évalue le header avant de déclencher le modèle de langage. Le prompt est envoyé au provider, et la réponse est renvoyée au client comme d'habitude. L'intervention se fait pendant la phase de télémétrie. Le proxy lit le header disable et bloque activement le transfert du payload vers les endpoints d'observabilité spécifiés pour cette seule transaction. Pendant ce temps, toutes les autres applications qui tapent sur le même proxy en simultané continuent de logger leur trafic sans aucune interruption.
C'est là que ça devient intéressant. Donner aux clients le pouvoir de désactiver leurs propres logs d'audit introduit un risque de sécurité potentiel. Dans les environnements très réglementés, les développeurs ne devraient pas toujours avoir l'autorité de masquer leur trafic. Si ton infrastructure exige une piste d'audit stricte et inaltérable pour chaque prompt, tu dois l'imposer de manière centralisée.
Tu gères ça en utilisant le verrouillage de conformité. Dans le fichier de configuration du proxy, dans le bloc des paramètres généraux, tu définis un paramètre nommé allow dynamic callback disabling sur false. Ce simple paramètre établit une politique globale stricte qui prend le pas sur toute instruction côté client.
Si un microservice essaie de passer le header disable callbacks pendant que ce verrouillage est actif, le proxy n'ignore pas silencieusement le header. Au lieu de ça, il rejette entièrement la transaction et renvoie une erreur HTTP 403 Forbidden. Ce mécanisme garantit que le trafic respecte la politique de logging globale obligatoire, ou qu'il est rejeté avant d'atteindre le modèle de langage.
La véritable utilité du Dynamic Callback Management, c'est qu'il déplace la confidentialité des données d'un deploy d'infrastructure rigide vers un paramètre agile au niveau de la requête, tout en laissant aux ingénieurs de la plateforme le dernier mot sur la conformité.
Merci pour ton écoute, bon code à tous !
17
Observability prête à l'emploi
3m 15sObtenez une visibilité instantanée sur votre trafic LLM. Apprenez à acheminer la télémétrie, les traces et les exceptions vers des outils comme Langfuse et Sentry en utilisant de simples callbacks de succès et d'échec.
Salut, c'est Alex de DEV STORIES DOT EU. LiteLLM : The Universal LLM Gateway, épisode 17 sur 24. Quand un utilisateur se plaint que l'IA lui a donné une réponse bizarre il y a trois jours, comment tu retrouves le prompt exact qui a causé ça ? Parser les logs de l'application pour chercher des payloads JSON multilignes, c'est un cauchemar. Tu as besoin de données de trace structurées, mais développer des intégrations custom pour chaque outil de monitoring, ça bouffe des heures de dev. C'est exactement ce problème que gère la Drop-in Observability.
Au lieu d'écrire des fonctions wrapper custom pour chronométrer tes appels d'API, compter les tokens et attraper les timeouts, LiteLLM intercepte le trafic nativement. Il expose deux hooks principaux dans tes settings : le success callback et le failure callback. Ces callbacks agissent comme des mécanismes de routage automatique pour ta télémétrie. Ils acceptent un array de strings qui représentent les fournisseurs d'observabilité externes supportés. Tu as juste à nommer l'outil que tu veux utiliser, et LiteLLM traduit ses données de requête internes dans le format exact que cet outil attend.
Prends le success callback. Il se déclenche au moment où un modèle de langage renvoie une réponse valide. Quand ça arrive, LiteLLM capture automatiquement un snapshot de la transaction. Ça inclut le prompt d'input exact envoyé au modèle, l'output généré, le temps que ça a pris pour générer, et l'utilisation précise des tokens. Pour envoyer ces données à un outil externe, tu ouvres tes settings LiteLLM et tu définis la variable du success callback sur une liste qui contient la string langfuse. Tant que tes clés d'authentification Langfuse sont présentes dans tes variables d'environnement, le système gère le reste. Voici le point clé. Le processus de logging se fait de manière asynchrone en background. Le thread principal de ton application ne bloque jamais en attendant que le fournisseur d'observabilité accuse réception de la trace. Tes utilisateurs ne subissent aucune latence supplémentaire.
Ça, c'est pour le happy path. Pour les erreurs, tu utilises le failure callback. Il se déclenche quand un appel d'API fait un timeout, atteint un rate limit du fournisseur, ou échoue complètement. Sans un tracing adéquat, une erreur LLM remonte souvent comme un status code opaque. En définissant ta variable de failure callback sur une liste contenant la string sentry, tu mappes les exceptions LLM directement sur ton workflow de tracking d'erreurs existant. Quand une requête échoue, LiteLLM package le type d'exception, le nom du modèle et l'input tenté, puis pousse ce contexte directement dans Sentry.
Pour setup ça dans ton code, tu n'as pas besoin de modifier tes vrais appels d'API. Tu touches uniquement à la configuration globale. Tu assignes les outils que tu as choisis aux arrays de callbacks une seule fois, au démarrage de l'application. À partir de là, chaque appel de completion que tu fais est monitoré. Ta logique principale reste entièrement découplée de ton infrastructure de logging. Si tu décides de remplacer Langfuse par un autre fournisseur le mois prochain, tu changes une seule string dans un array.
La vraie puissance des drop-in callbacks, ce n'est pas juste d'éviter le code boilerplate. C'est de standardiser la forme de ta télémétrie sur des dizaines de fournisseurs LLM différents, pour que ta plateforme de monitoring voie exactement un seul format cohérent, peu importe quel modèle sous-jacent a répondu au prompt.
Merci d'avoir écouté, happy coding tout le monde !
18
Métriques Prometheus et santé des Pods
3m 09sPrenez le pouls de votre proxy. Découvrez comment exposer l'endpoint /metrics à Prometheus, suivre les in-flight requests et utiliser des custom tags pour segmenter les données dans Grafana.
Salut, c'est Alex de DEV STORIES DOT EU. LiteLLM : La gateway LLM universelle, épisode 18 sur 24. Si une requête LLM prend dix secondes, est-ce que le provider d'IA est lent, ou est-ce que l'event loop de ton proxy est complètement saturée ? Tu ne peux pas corriger un bottleneck tant que tu ne sais pas exactement où il se trouve. Les metrics Prometheus et le pod health dans LiteLLM te donnent exactement cette visibilité.
LiteLLM expose un endpoint de metrics standard sur le chemin slash metrics. Une erreur classique quand tu monitores des gateways IA, c'est de traiter tous les délais de réponse comme de la latence du provider LLM. C'est faux. Il y a deux périodes d'attente bien distinctes. D'abord, il y a la latence de la queue pré-ASGI. C'est le temps qu'une requête passe à attendre dans ton infrastructure avant même que le proxy ne commence à la traiter. Ensuite, il y a la vraie latence LLM, qui est le temps passé à attendre qu'OpenAI, Anthropic ou un autre provider te renvoie des tokens. L'endpoint de metrics sépare ces chiffres pour que tu saches exactement à qui la faute en cas de réponse lente.
Pour monitorer ton pod health, tu te bases sur une jauge spécifique appelée litellm in flight requests. Cette metric tracke le nombre exact de requêtes concurrentes activement traitées par un pod à une milliseconde donnée. C'est une mesure en temps réel de la queue depth. Quand le trafic fait un spike, ce nombre grimpe.
Prends un scénario concret. Ton dashboard de monitoring montre un énorme spike dans la durée totale des requêtes. Les utilisateurs se plaignent de réponses lentes. Si tu regardes seulement le temps total, tu pourrais supposer qu'OpenAI a une outage. Mais quand tu checkes l'endpoint de metrics, la latence du provider est stable à deux secondes. C'est là qu'est l'info clé. Tu regardes litellm in flight requests et tu vois que c'est passé de vingt à deux cents. Ça prouve que le délai ne vient pas d'OpenAI. La queue de ton pod est complètement surchargée. Armé de cette jauge précise, tu peux configurer ton infrastructure pour déclencher un event d'auto-scale au moment où les in-flight requests dépassent un certain seuil, en déployant de nouveaux pods proxy avant que l'event loop ne sature.
Tu dois aussi savoir qui génère ce trafic. LiteLLM supporte les tags Prometheus custom. Quand une requête tape la gateway, tu peux passer des metadata custom dans le payload de la requête, comme un ID de projet, un département ou un nom d'application. LiteLLM extrait ces tags custom et les attache comme labels aux metrics Prometheus. Au lieu de juste voir que la gateway a traité dix mille tokens, tu vois que l'application marketing a traité sept mille tokens et que le dashboard analytique en a traité trois mille. Ça donne aux DevOps la possibilité de grouper l'utilisation des tokens, la queue depth et la latence par tenant spécifique.
Le point le plus critique à retenir pour les performances de la gateway, c'est ça. Ne fais jamais d'auto-scale de ton proxy IA en te basant sur la latence de réponse totale, parce que tu vas gaspiller de l'argent à scale up quand le provider externe est juste lent ; fais ton scale en fonction de ta jauge d'in-flight requests pour réagir uniquement quand la queue de ta propre infrastructure est vraiment pleine.
Merci d'avoir écouté, happy coding tout le monde !
19
Text-to-Speech universel
3m 45sStandardisez votre génération vocale. Découvrez comment appeler des modèles Text-to-Speech de Gemini, Vertex et AWS Polly en utilisant exactement le même format d'endpoint audio compatible OpenAI.
Bonjour, ici Alex de DEV STORIES DOT EU. LiteLLM : La gateway LLM universelle, épisode 19 sur 24. Tu veux ajouter la génération vocale à ton app, mais écrire du code d'intégration custom pour le format audio de chaque provider demande une maintenance constante. À chaque fois que tu passes d'un modèle vocal OpenAI à un modèle vocal Google, les champs JSON requis, les paths d'API et les types de retour audio changent complètement. Le mécanisme qui résout ça, c'est le Text-to-Speech universel en utilisant le bridge audio-speech de LiteLLM.
Au lieu de maintenir des clients API séparés pour OpenAI, Vertex AI et Gemini, tu standardises ton application sur un format unique. LiteLLM expose un endpoint unifié qui imite exactement la route audio-speech standard d'OpenAI. Tu construis une requête contenant ton texte, le nom du modèle choisi et une préférence de voix, et tu l'envoies à LiteLLM comme si tu parlais directement à OpenAI. La gateway traduit ensuite ce payload standardisé dans le format spécifique requis par ton provider cible.
Voici le point clé. Beaucoup de providers d'IA ne proposent pas d'API Text-to-Speech simple et dédiée qui stream des fichiers audio out of the box. Selon le provider, accéder nativement à un modèle vocal nécessite souvent de router la requête via un endpoint de text completion générique. Tu vas peut-être devoir passer des flags de configuration très spécifiques, envoyer un system prompt complexe, puis extraire des strings audio encodées en base64, profondément imbriquées dans une réponse JSON. LiteLLM abstrait toute cette couche de traduction. Il gère la négociation d'API, décompresse la structure de réponse propriétaire et isole les données audio réelles.
Prenons un scénario concret. Tu décides de générer de l'audio parlé en utilisant le modèle preview Gemini Flash TTS de Google. Dans le code de ton application, tu fais pointer ton client HTTP standard vers l'URL de ton proxy LiteLLM sur le path audio-speech. Tu définis le paramètre model pour qu'il pointe vers le modèle Gemini Flash TTS. Tu assignes ton plain text au paramètre input, et tu spécifies un identifiant de voix valide.
Quand tu exécutes la requête, LiteLLM intercepte le payload. Il s'authentifie de manière sécurisée auprès de Google Cloud ou Vertex AI selon ton setup. Il repackage ton plain text et ta sélection de voix dans le schéma JSON spécifique que l'API Google demande. Quand le modèle Google traite le texte et renvoie le résultat, LiteLLM intercepte la réponse propriétaire. Plutôt que de forcer ton application cliente à parser un payload Google Cloud custom, LiteLLM extrait les bytes audio bruts. Il fait le bridge de manière transparente sur la couche transport, en streamant immédiatement un fichier MP3 standard en retour vers ton client. Ton application frontend ou backend reçoit un stream audio standard, sans du tout se rendre compte que la génération sous-jacente a été effectuée par Google au lieu d'OpenAI.
Cette logique de bridge signifie que tu écris ton intégration client Text-to-Speech une seule et unique fois. Si un nouveau modèle audio plus rapide est sorti par Vertex demain, tu as juste besoin de changer la string du modèle dans ta requête. Le code de l'application qui gère le stream MP3 reste entièrement intact. Traiter la génération audio exactement de la même manière que tu traites la génération de texte te permet de standardiser la logique de ton application. En forçant toutes les requêtes Text-to-Speech via une seule interface unifiée, tu peux router, load-balancer et configurer des failovers pour ta génération audio à travers des providers complètement différents, sans écrire une seule ligne de code de fallback spécifique au provider. Merci d'avoir écouté, happy coding tout le monde !
20
Le pont Assistants API
3m 22sGérez l'état des conversations sans effort entre les fournisseurs. Apprenez comment LiteLLM enveloppe les modèles non natifs dans l'interface standard de l'Assistants API d'OpenAI, vous permettant d'utiliser les Threads et les Messages partout.
Salut, c'est Alex de DEV STORIES DOT EU. LiteLLM : La gateway LLM universelle, épisode 20 sur 24. OpenAI gère le state des conversations de manière remarquable, ce qui permet de garder ton code client entièrement stateless. Mais enfermer ton architecture chez un seul provider juste pour garder cette gestion du state, c'est un prix fort à payer. Le bridge Assistants API dans LiteLLM résout ce problème.
Ce bridge est une feature du proxy LiteLLM qui expose les endpoints exacts de l'Assistants API d'OpenAI. Tu tapes sur des chemins standards, comme les endpoints v one assistants et v one threads, mais tu routes la génération de texte vers le modèle de ton choix.
Les interfaces de chat completion standards sont stateless. À chaque fois que tu poses une question, ton client doit renvoyer tout l'historique de la conversation au serveur. Ça consomme de la bande passante et ça complexifie ton code côté client. L'Assistants API résout ça en gardant l'historique de la conversation sur le serveur, dans un objet Thread. Tu as juste à ajouter les nouveaux messages au thread et à dire au serveur de lancer un run de l'assistant. Le problème, c'est que la plupart des autres providers, des setups locaux aux alternatives cloud d'entreprise, n'offrent pas cette interface stateful nativement.
Le bridge LiteLLM vient polyfill cette fonctionnalité manquante. Pour que ça marche, tu configures le proxy LiteLLM pour qu'il se connecte à une base de données. Cette base de données va servir de storage layer pour le state de ta conversation. Ensuite, tu pointes ton client OpenAI existant vers l'URL du proxy LiteLLM au lieu des serveurs OpenAI par défaut.
Le flow logique commence par la création d'un assistant. Tu envoies une requête au proxy qui définit les instructions de l'assistant et spécifie un modèle cible. Ça peut être un deploy Azure OpenAI ou un modèle Astra compatible OpenAI. Le proxy sauvegarde cette configuration dans sa base de données.
Ensuite, tu crées un thread. Un thread, c'est simplement un conteneur vide stocké par le proxy. Quand un utilisateur dit quelque chose, tu envoies une requête pour ajouter un message à ce thread spécifique. Le proxy sauvegarde le message. Jusque-là, le large language model sous-jacent n'a pas du tout été contacté.
Voici le point clé. Le bridge ne parle à ton modèle cible que lorsque tu déclenches un run. Quand tu dis au proxy de lancer un run de l'assistant sur un thread spécifique, LiteLLM récupère tout l'historique des messages depuis sa base de données. Il formate cet historique en un payload de chat completion standard et stateless. Il envoie ensuite ce payload plat au modèle sous-jacent que tu as configuré plus tôt.
Le modèle évalue la conversation et renvoie une réponse au proxy. LiteLLM prend ce texte, le package comme un nouveau message de l'assistant, le sauvegarde dans la base de données du thread, et met à jour le statut du run sur completed. Ton client poll le proxy, voit le statut completed, et fetch le dernier message exactement comme il le ferait normalement.
Le code de ton application reste complètement inchangé. Il pense toujours qu'il parle à un système stateful natif. Le proxy gère la traduction de manière transparente, en prenant une requête client stateful, en exécutant un call de modèle stateless, et en maintenant la persistence layer entre les deux.
Cette séparation des responsabilités signifie que ton architecture client peut s'appuyer sur une interface d'API moderne avec gestion du state, pendant que ton infrastructure reste entièrement libre de swapper les modèles sous-jacents en fonction des besoins de coût, de privacy ou de performance.
Merci d'avoir écouté, happy coding tout le monde !
21
La MCP Gateway
3m 29sBoostez vos modèles avec des outils de manière centralisée. Découvrez comment configurer des serveurs Model Context Protocol (MCP) HTTP, SSE ou STDIO dans LiteLLM, donnant à n'importe quel LLM accès à des capacités externes.
Bonjour, c'est Alex de DEV STORIES DOT EU. LiteLLM : La gateway LLM universelle, épisode 21 sur 24. Tu as un modèle Llama open-source qui tourne en local, mais tu veux qu'il déclenche des actions ou lise des fichiers en utilisant exactement les mêmes intégrations GitHub que ton agent Claude Code. Tu ne veux pas réécrire la logique de ton application pour supporter un nouveau toolset pour chaque nouveau modèle. La gateway MCP résout ce problème.
D'abord, séparons MCP du routing A2A, ou Agent-to-Agent. Une confusion courante est de les considérer comme la même chose. Le routing A2A, c'est quand tu rediriges un prompt utilisateur vers un agent externe spécialisé pour générer une réponse texte. MCP est totalement différent. MCP signifie Model Context Protocol, et ça consiste à fournir un set de tools standardisés à un modèle, en le laissant décider quand et comment les invoquer pour accomplir une tâche.
La feature de gateway MCP permet au proxy LiteLLM d'agir comme un pont entre n'importe quel modèle de langage et tes serveurs MCP. Au lieu d'écrire du code pour enregistrer des tools dans chaque application cliente que tu crées, tu les définis de manière centralisée dans le proxy. À partir de là, n'importe quel modèle qui tape sur le proxy peut utiliser ces tools.
LiteLLM se connecte aux serveurs MCP via deux méthodes principales. La première, c'est STDIO, ou Standard Input and Output. C'est utilisé pour les tools locaux. Tu configures le proxy pour exécuter une commande locale spécifique, comme lancer un script Node ou un fichier Python, directement sur la machine hôte. La deuxième méthode, c'est HTTP avec Server-Sent Events, ou SSE. C'est utilisé pour se connecter à des serveurs MCP distants via un réseau.
Regardons un scénario concret. Tu veux ajouter un serveur MCP Zapier distant pour que tes modèles puissent interagir avec des web apps externes. Tu fais ça entièrement dans le fichier YAML de configuration du proxy. Sous le bloc de configuration principal, tu ajoutes une section MCP servers. Tu nommes l'intégration, par exemple, zapier-integration. Tu définis le type de transport sur SSE. Ensuite, tu fournis l'URL du endpoint de ton serveur MCP Zapier. Comme c'est une connexion distante, tu vas aussi spécifier les headers d'authentification requis, comme un bearer token, directement dans cette définition YAML.
Maintenant, le proxy sait comment parler à Zapier. L'étape suivante, c'est l'exécution. Quand ton application cliente envoie une requête de chat completion standard à LiteLLM, elle a juste besoin d'inclure un header spécifique indiquant quels tools MCP elle veut charger.
Voici le point clé. L'application cliente n'a pas besoin de savoir quels tools Zapier offre réellement. Le proxy intercepte la requête du client, contacte le serveur MCP Zapier via la connexion SSE, et récupère dynamiquement la liste actuelle des tools disponibles. Le proxy injecte ensuite ces définitions de tools dans le payload et transfère tout le paquet au modèle de langage.
Si le modèle de langage décide d'invoquer un tool Zapier, il renvoie un tool call au proxy. Le proxy l'attrape, exécute l'action sur le serveur MCP Zapier, récupère le résultat, et le renvoie au modèle. Ton application cliente est complètement isolée de cette négociation d'allers-retours. Elle reçoit juste des réponses de tools standards compatibles OpenAI.
La vraie puissance de la gateway MCP, c'est le découplage entre l'implémentation des tools et le choix du modèle, ce qui veut dire qu'une intégration construite pour un écosystème fonctionne instantanément sur des dizaines de modèles différents sans écrire de code d'adapter custom.
Merci d'avoir écouté, happy coding tout le monde !
22
A2A : Suivi des agents autonomes
3m 12sPrenez le contrôle des agents autonomes. Apprenez à invoquer des agents complexes LangGraph ou Bedrock via le proxy en utilisant le protocole A2A, permettant le regroupement des traces et le suivi unifié des dépenses.
Salut, c'est Alex de DEV STORIES DOT EU. LiteLLM : The Universal LLM Gateway, épisode 22 sur 24.
Quand ton agent autonome part dans une boucle de raisonnement de cinquante étapes, comment tu relies la facture à la request initiale ? Si l'agent fait des dizaines de calls isolés à différents modèles de langage, tes logs de facturation deviennent un fouillis illisible de requests déconnectées. La solution à ça, c'est la gateway d'agent LiteLLM, aussi connue sous le nom de protocole A2A.
Avant d'explorer comment ça marche, on doit dissiper une confusion fréquente. Les auditeurs confondent souvent ça avec le Model Context Protocol, ou MCP. MCP sert à fournir des tools externes à un modèle de langage. A2A fait exactement l'inverse. Il traite un agent autonome externe comme si c'était un modèle de langage standard, ce qui te permet de l'invoquer et de le tracker via une gateway centralisée.
Pour configurer ça, tu définis ton agent dans le fichier de configuration de LiteLLM exactement comme tu définirais un modèle de langage standard. Tu donnes un nom au modèle, tu configures la base URL qui pointe vers l'endpoint d'API de ton agent, et tu spécifies le provider comme un endpoint OpenAI custom. Maintenant, LiteLLM sait comment router les requests client entrantes directement vers ton agent.
Quand un client envoie une request qui demande cet agent, LiteLLM agit comme un pass-through pour les headers de contexte. Il prend les métadonnées liées à la request, comme les identifiants utilisateur, les tags de routing d'équipe et les limites de budget, et les intègre dans des headers HTTP spécifiques. Le plus important d'entre eux, c'est le header X-LiteLLM-Trace-Id. LiteLLM transmet ces headers en même temps que le prompt à ton agent.
Voici le point clé. Ton agent reçoit cette request, démarre sa boucle autonome, et commence à faire ses propres calls internes pour traiter la tâche. Si l'agent fait ces calls directement à un provider public, tu perds le contexte de tracking. Au lieu de ça, l'agent doit router ses calls internes pour qu'ils repassent par LiteLLM. Quand il fait ça, il doit inclure le trace ID qu'il a reçu dans la request originale.
Prenons un scénario concret. Tu invoques un agent LangGraph local. Un client envoie un prompt via LiteLLM pour démarrer le process. LiteLLM assigne un trace ID unique et transmet le payload à l'endpoint LangGraph. Ton application LangGraph lit les headers HTTP entrants et extrait le X-LiteLLM-Trace-Id. Quand LangGraph a besoin d'évaluer une étape ou de résumer des données, il utilise son client interne pour renvoyer un call de completion à LiteLLM. Point crucial, il attache exactement le même header de trace ID à sa request sortante.
Parce que chaque call interne transporte le même identifiant de trace, LiteLLM les groupe ensemble automatiquement. Quand tu regardes ta plateforme d'observabilité ou tes logs de budget, tu ne vois pas cinquante requests aléatoires provenant de sources inconnues. Tu vois une seule trace unifiée. Tu sais exactement quel utilisateur a déclenché l'agent, combien a coûté toute la boucle de raisonnement, et quelles étapes autonomes spécifiques ont consommé le plus de budget.
Traiter les agents comme des endpoints de modèle standards transforme les workflows d'agents complexes et multi-étapes en unités de compute trackables et facturables.
Merci d'avoir écouté, bon code à tous !
23
Rotations de clés Zero-Downtime
3m 01sRéalisez des transitions de sécurité sans temps d'arrêt. Apprenez à configurer des rotations de clés automatiques programmées et des périodes de grâce pour les virtual keys d'entreprise dans LiteLLM.
Salut, c'est Alex de DEV STORIES DOT EU. LiteLLM : la gateway LLM universelle, épisode 23 sur 24. Faire la rotation des API keys en production, ça implique généralement du downtime planifié, une coordination frénétique, et l'espoir qu'aucun système backend ne se retrouve avec un credential mort. Un cutover brutal est une mesure de sécurité stricte, mais c'est aussi un moyen super fiable de casser les requêtes en cours. La solution à ce problème, ce sont les Zero-Downtime Key Rotations.
Dans un setup de proxy d'entreprise, garder des virtual keys statiques pour toujours, c'est un risque de sécurité inacceptable. LiteLLM gère ça en te permettant de planifier des rotations de clés automatiques. Au lieu de générer manuellement de nouveaux credentials et de coordonner le moment exact pour faire le switch, tu laisses le proxy gérer le lifecycle. Mais le simple fait d'automatiser la création d'une nouvelle clé ne résout pas le problème de fiabilité de fond. Si la gateway rejette immédiatement l'ancienne clé à la seconde où une nouvelle est créée, tout service qui n'a pas encore synchronisé le nouveau credential va instantanément planter.
Pour corriger ça, LiteLLM utilise une grace period. Quand tu crées ou mets à jour une virtual key, tu configures deux paramètres spécifiques. D'abord, tu définis l'intervalle d'auto rotate, qui détermine exactement à quelle fréquence une nouvelle clé doit être générée. Ensuite, tu définis la grace period, qui indique au système combien de temps l'ancienne clé doit rester valide après la rotation.
Prends l'exemple d'une architecture microservices standard où ta politique de sécurité exige de faire la rotation des clés d'accès LLM tous les trente jours. Tu fais une requête sur l'endpoint de génération de clés de LiteLLM. Dans cette requête, tu règles le paramètre auto rotate sur 30 jours. Dans la même requête, tu règles le paramètre grace period sur 24 heures. Le proxy stocke cette policy et lance le chrono.
Au bout de trente jours, la rotation se déclenche. LiteLLM génère automatiquement une toute nouvelle virtual key. C'est ça la partie importante. Pendant les 24 heures qui suivent, tu as deux clés parfaitement valides qui pointent vers exactement la même configuration, le même budget et la même logique de tracking.
Pendant cette fenêtre d'overlap, ton secrets manager récupère la nouvelle clé et l'injecte doucement dans ton environnement de production. Au fur et à mesure que les containers tournent ou que les config maps se mettent à jour, les services basculent indépendamment vers le nouveau credential. Si un background worker spécifique utilise encore l'ancienne clé douze heures après le début de la grace period, LiteLLM accepte la requête sans broncher. La gateway route le trafic vers le Large Language Model et loggue la transaction normalement.
Une fois que la grace period de 24 heures est exactement écoulée, LiteLLM invalide automatiquement la clé d'origine. Tout système restant qui essaie encore d'utiliser l'ancien credential recevra une erreur d'authentification. La migration est terminée.
Tu as totalement découplé la création du nouveau secret de la destruction de l'ancien. Séparer ces deux événements transforme la rotation des clés : on passe d'une panique d'infrastructure fragile et ultra-coordonnée à une routine en background silencieuse et fiable.
Merci d'avoir écouté, happy coding tout le monde !
24
L'Admin UI et l'AI Hub
3m 36sRendez votre plateforme d'IA accessible à tous. Apprenez à gérer l'Admin UI, à ajuster les credentials de l'interface et à utiliser l'AI Hub pour permettre aux développeurs de découvrir en toute sécurité les modèles et agents autorisés.
Salut, c'est Alex de DEV STORIES DOT EU. LiteLLM : La gateway LLM universelle, épisode 24 sur 24. Ton équipe plateforme a construit une gateway LLM ultra sécurisée et parfaitement routée. Mais quand les développeurs internes ont vraiment besoin de développer quelque chose, comment savent-ils quels modèles et agents ils ont le droit d'utiliser ? Sans mécanisme de discovery, ta gateway est une boîte noire invisible. Cette visibilité est apportée par l'Admin UI et l'AI Hub.
L'Admin UI est un dashboard visuel intégré directement au proxy LiteLLM. Gérer une gateway LLM uniquement via des fichiers de configuration et des requêtes de base de données, ça scale très mal quand plusieurs équipes commencent à demander des accès. L'Admin UI donne aux opérateurs de la plateforme un endroit centralisé pour gérer le proxy. Via cette interface, tu peux générer de nouvelles clés API, tracker la dépense en tokens des différentes équipes, monitorer les logs de requêtes en live, et configurer les règles de routing des modèles.
Quand tu lances le proxy LiteLLM pour la première fois, ce dashboard est activé par défaut et sécurisé avec des credentials de login par défaut. Pour des tests en local, c'est pratique. Pour la production, c'est une vulnérabilité. Tu dois changer ces credentials par défaut immédiatement. Tu fais ça en définissant des variables d'environnement spécifiques pour le username et le password admin avant de démarrer le container.
Voici le point clé. Tu pourrais ne pas vouloir exposer de dashboard graphique du tout sur ta gateway de production. Beaucoup d'équipes plateforme provisionnent leur infrastructure strictement via des scripts automatisés et ne veulent pas d'un control plane interactif accessible sur le réseau. Si ça correspond à ton modèle de sécurité, tu peux désactiver le dashboard complètement. En mettant une variable d'environnement appelée disable admin ui sur true, tu supprimes complètement l'interface. Le proxy continuera de router le trafic et d'appliquer les règles, mais le serveur web ne servira pas les écrans d'administration.
Ça, c'est pour les opérateurs de la plateforme, mais les ingénieurs qui consomment l'API ont besoin d'une perspective différente. C'est là que l'AI Hub entre en jeu. Alors que l'Admin UI sert au contrôle, l'AI Hub sert à la discovery. Il agit comme un portail développeur interne pour ton organisation.
Au lieu d'envoyer un message à l'équipe plateforme pour demander quels modèles sont actuellement approuvés ou où se trouve la documentation d'un agent interne, les développeurs visitent l'AI Hub. Ils s'authentifient, généralement via le provider SSO de ton organisation, et se retrouvent face à un catalogue. Ils peuvent voir exactement quels modèles ils sont autorisés à call, vérifier les rate limits appliqués à ces modèles, et découvrir des agents préconfigurés créés par d'autres équipes.
Plus important encore, l'AI Hub permet aux développeurs d'être en self-service. Ils peuvent générer leurs propres clés API liées au budget spécifique de leur équipe sans attendre qu'un ingénieur plateforme en provisionne une manuellement. Ça change fondamentalement la façon dont ton organisation interagit avec l'IA générative. Ça fait le pont entre les ingénieurs infrastructure qui sécurisent la gateway et les ingénieurs produit qui développent les applications.
La gateway n'est utile que si elle est accessible, et l'AI Hub transforme un proxy verrouillé en une plateforme self-service qui permet à tes équipes d'ingénierie d'aller vite sans exploser ton budget. Ça conclut notre série sur LiteLLM. Je t'encourage à explorer la documentation officielle, à tester ces configurations hands-on, et à visiter dev stories dot eu pour suggérer des sujets pour de futures séries. Merci de ton écoute, et happy coding tout le monde !