Utiliser LiteLLM avec des modèles open source hébergés dans l’UE

LiteLLM se compose de deux parties. Le SDK Python appelle plus d’une centaine de fournisseurs via une seule fonction completion(). Le serveur proxy, souvent appelé passerelle IA LiteLLM, expose une API compatible OpenAI à vos équipes et ajoute devant les fournisseurs configurés des clés virtuelles, le suivi des dépenses, des limites de débit, des modèles de secours, des garde-fous et de la journalisation.

Beaucoup d’entreprises exploitent ce proxy comme passerelle centrale, pour que agents de code, interfaces de chat et applications internes partagent un même point d’accès. Ajouter inference.eu comme fournisseur dans cette passerelle met les modèles open-weight européens à disposition de tous, sans modifier chaque client.

Dans le config.yaml du proxy, chaque entrée de model_list associe un model_name public à une route. Le préfixe openai/ dans litellm_params.model indique à LiteLLM d’appeler un point d’accès Chat Completions compatible OpenAI ; la suite est l’identifiant inference.eu. api_base est l’URL de base terminée par /v1, et os.environ/INFERENCE_EU_API_KEY lit la clé dans l’environnement.

Dans le SDK Python, la même route s’écrit litellm.completion(model="openai/gpt-oss-120b", api_base=..., api_key=...). Les clients du proxy ne voient que model_name : vous pouvez donc changer le modèle inference.eu sous-jacent sans toucher à leur configuration.

Exposez les modèles dont vos équipes ont besoin sous des noms clairs. qwen3-coder-480b-a35b-instruct convient aux agents de code et aux intégrations d’IDE qui passent par la passerelle. glm-5.3 et kimi-k3 sont de solides modèles généralistes pour les agents et les longs documents, et gpt-oss-120b un choix rapide pour le chat, les résumés et les outils internes à fort volume.

LiteLLM peut regrouper plusieurs entrées sous un même model_name pour répartir la charge, ou définir des modèles de secours entre noms. Gardez ces secours au sein d’inference.eu, par exemple de kimi-k3 vers glm-5.3, pour qu’une nouvelle tentative n’envoie jamais de données à un fournisseur hors de l’UE.

Une erreur 404 Not Found sur la route indique le plus souvent une api_base sans le suffixe /v1 ou avec des segments en trop ; LiteLLM ajoute lui-même /chat/completions. Une erreur 401 signifie que le processus du proxy ne dispose pas de INFERENCE_EU_API_KEY, ce qui arrive souvent sous Docker quand la variable n’est pas transmise.

« LLM Provider NOT provided » signifie que le préfixe openai/ manque dans litellm_params.model. Si les appels d’outils ou l’usage en streaming semblent incorrects, mettez LiteLLM à jour, car les correctifs de compatibilité sont fréquents. Vérifiez que l’identifiant après le préfixe correspond exactement à inference.eu, et testez la route via le point d’accès /health du proxy.

Les requêtes dirigées vers inference.eu sont traitées dans des centres de données de l’UE et ne servent jamais à l’entraînement. Nous signons un accord de sous-traitance au titre de l’article 28 du RGPD, publions la liste de nos sous-traitants et facturons en euros.

La passerelle voit elle-même chaque prompt : son emplacement compte donc. Hébergez le proxy dans l’UE et passez en revue ses callbacks de journalisation, car les intégrations qui envoient traces ou prompts à des services d’observabilité les conservent selon leurs propres conditions. Retirez de la liste les fournisseurs hors UE, ou limitez-les par des droits d’équipe, si votre politique l’exige.