Guide d'intégration

Faites tourner LiteLLM sur des modèles ouverts hébergés en UE

LiteLLM parle à n'importe quelle API compatible OpenAI grâce à son préfixe openai/ : Frontière AI s'y branche donc comme un fournisseur de plus — modèle openai/<modèle>, api_base pointé sur notre API, et votre clé sk-front. Vous gardez tout ce que LiteLLM vous apporte — clés virtuelles, budgets, replis, journalisation — et les modèles derrière sont des modèles à poids ouverts, ceux étiquetés souverains UE étant servis par des opérateurs européens. Chaque extrait de cette page a été exécuté contre notre gateway et les vrais fournisseurs qui la servent, avec LiteLLM 1.105.0.

Testé le 2026-10-12 avec LiteLLM 1.105.0 : chat, streaming avec usage, appel d'outils, embeddings, le proxy avec suivi des coûts, la passerelle /v1/messages et /v1/responses, et les en-têtes de routage. Ce qui n'est pas couvert : un déploiement de production du proxy avec base de données, clés et équipes — cette partie relève de LiteLLM.

Ce que ça vous apporte

LiteLLM est la couche que les équipes placent devant leurs fournisseurs de modèles : une seule interface, un seul endroit pour les clés, les budgets et les replis. Frontière AI est un fournisseur dans ce schéma — une clé API qui donne accès à un catalogue sélectionné de modèles à poids ouverts (Qwen, DeepSeek, GLM, Mistral, gpt-oss et d'autres), chacun servi par un fournisseur nommé et étiqueté avant l'appel : souverain UE, ou accès rapide quand une société américaine le sert.

Les deux ne se recouvrent pas. LiteLLM décide vers quel modèle part une requête et applique vos règles de dépense ; Frontière AI décide quel fournisseur sert ce modèle et vous dit, à chaque réponse, lequel l'a fait. Si votre LiteLLM route déjà vers OpenAI ou Anthropic, ajouter Frontière AI donne au même proxy une voie européenne pour les charges qui intéressent votre DPO.

Avant de commencer

• LiteLLM installé — pip install litellm pour le SDK, pip install 'litellm[proxy]' pour le proxy.
• Une clé API Frontière AI (tableau de bord → Clés API) et un solde non nul : sur un solde vide, les appels renvoient 402.
• Un identifiant de modèle tiré de notre catalogue. GET /models est public : vous pouvez choisir avant même d'avoir une clé — et seuls ses identifiants sont valides après le préfixe openai/.

1. SDK Python

Placez openai/ devant notre identifiant de modèle et passez notre API en api_base. C'est le préfixe qui dit à LiteLLM de parler le protocole OpenAI à une base URL qui n'est pas celle d'OpenAI ; sans lui, LiteLLM ne sait pas de quel fournisseur il s'agit et refuse l'appel.

import os
import litellm

response = litellm.completion(
    model="openai/qwen3-235b",
    api_base="https://getfrontiereai.eu/api/v1",
    api_key=os.environ["FRONTIERE_KEY"],  # votre clé Frontière AI (tableau de bord → Clés API)
    messages=[{"role": "user", "content": "Bonjour"}],
)
print(response.choices[0].message.content)

api_base s'arrête à /api/v1. LiteLLM ajoute lui-même /chat/completions — ajoutez-le vous-même et la requête tombe sur un chemin qui n'existe pas.

2. Proxy LiteLLM

Sur le proxy, chaque modèle Frontière AI devient une entrée de model_list. model_name est le nom qu'utiliseront vos clients ; litellm_params porte les trois mêmes réglages que le SDK. Gardez la clé hors du fichier avec la syntaxe os.environ/.

model_list:
  - model_name: qwen3-235b
    litellm_params:
      model: openai/qwen3-235b
      api_base: https://getfrontiereai.eu/api/v1
      api_key: os.environ/FRONTIERE_KEY
    model_info:
      # nos prix pour ce modèle, en EUR par token, marge et TVA comprises
      input_cost_per_token: 0.00000126
      output_cost_per_token: 0.00000378
  # modèle d'embedding : mêmes réglages, mode embedding
  - model_name: bge-multilingual-gemma2
    litellm_params:
      model: openai/bge-multilingual-gemma2
      api_base: https://getfrontiereai.eu/api/v1
      api_key: os.environ/FRONTIERE_KEY
    model_info:
      mode: embedding
      input_cost_per_token: 0.000000168

litellm_settings:
  drop_params: true

drop_params: true fait abandonner par LiteLLM les paramètres qu'un fournisseur ne prend pas en charge au lieu de faire échouer la requête — utile quand des clients écrits pour OpenAI envoient des options qu'un modèle à poids ouverts ignore. Les prix de model_info sont calculés pour vous depuis notre catalogue ; la section sur le suivi des dépenses les explique.

export FRONTIERE_KEY="sk-front-…"
# les versions récentes de LiteLLM refusent de démarrer sans
export LITELLM_MASTER_KEY="sk-$(openssl rand -hex 24)"
litellm --config config.yaml --port 4000

Vos clients appellent ensuite le proxy, pas nous, avec la clé du proxy — le même client OpenAI, une autre base URL :

from openai import OpenAI

client = OpenAI(base_url="http://localhost:4000/v1", api_key=os.environ["LITELLM_MASTER_KEY"])
reply = client.chat.completions.create(
    model="qwen3-235b",
    messages=[{"role": "user", "content": "Bonjour"}],
)

Clients qui parlent /v1/messages ou /v1/responses

Certains clients n'appellent pas du tout /chat/completions : les outils de style Anthropic envoient /v1/messages, les outils OpenAI récents /v1/responses. Notre API sert les chat completions ; avec le préfixe openai/, le proxy transmet donc ces deux routes vers un chemin que nous n'avons pas, et elles échouent en 404. Déclarez plutôt les modèles de chat avec le préfixe custom_openai/ — même api_base, même clé — et LiteLLM traduit les deux en chat completions avant de nous appeler.

model_list:
  - model_name: qwen3-235b
    litellm_params:
      model: custom_openai/qwen3-235b
      api_base: https://getfrontiereai.eu/api/v1
      api_key: os.environ/FRONTIERE_KEY

Nous l'avons testé avec une requête simple sur chaque route : un appel /v1/messages au format Anthropic et un appel /v1/responses sont tous deux revenus avec la réponse de notre modèle. Nous n'avons pas fait tourner Claude Code ni Codex de bout en bout par ce chemin. Gardez openai/ pour les modèles d'embedding — custom_openai/ ne gère pas les embeddings.

3. Streaming et usage

Le streaming fonctionne comme avec OpenAI. Notre gateway envoie toujours l'usage en tokens dans le dernier chunk d'un flux, mais le SDK LiteLLM ne le transmet que si l'appel le demande : sans stream_options, il ne figurait tout simplement pas dans les chunks rendus par LiteLLM. Demandez-le explicitement si votre code lit l'usage dans un flux.

stream = litellm.completion(
    model="openai/qwen3-235b",
    api_base="https://getfrontiereai.eu/api/v1",
    api_key=os.environ["FRONTIERE_KEY"],
    messages=[{"role": "user", "content": "Bonjour"}],
    stream=True,
    stream_options={"include_usage": True},  # demandez l'usage explicitement : LiteLLM ne le transmet que sur demande
)
for chunk in stream:
    if chunk.choices and chunk.choices[0].delta.content:
        print(chunk.choices[0].delta.content, end="")
    if getattr(chunk, "usage", None):
        print("\n", chunk.usage)

Derrière le proxy, la même règle vaut pour vos clients : ils reçoivent le chunk d'usage s'ils le demandent, ou toujours si vous réglez always_include_stream_usage: true sous general_settings. Dans tous les cas, notre facturation n'en dépend pas : nous comptons les tokens d'après le décompte du fournisseur lui-même, que votre client le lise ou non.

4. Appel d'outils

tools et tool_choice traversent LiteLLM et notre gateway sans modification. Dans notre test, un outil get_weather est revenu sous forme d'entrée tool_calls en bonne et due forme, avec finish_reason tool_calls et des arguments en JSON valide.

Qu'un modèle émette ou non des appels d'outils dépend du modèle et de son fournisseur : nous le mesurons donc par un appel réel par modèle plutôt que de le supposer — 24 des 24 modèles en ligne mesurés à ce jour ont renvoyé un appel d'outil valide. Les agents construits sur LiteLLM devraient partir de ceux-là.

Voir la matrice complète des appels d'outils →

5. Embeddings

Même préfixe, même api_base, via litellm.embedding — ou une entrée de model_list marquée mode: embedding côté proxy. Utilisez l'un des modèles d'embedding (bge-multilingual-gemma2 et qwen3-embedding-8b) ; un identifiant de modèle de chat sur l'endpoint d'embeddings répond 404 avec un message explicite. Avec un modèle de chat étiqueté souverain UE, les deux moitiés d'une chaîne de recherche documentaire restent alors sur une infrastructure européenne, puisque tous nos modèles d'embedding sont hébergés en UE.

vectors = litellm.embedding(
    model="openai/bge-multilingual-gemma2",
    api_base="https://getfrontiereai.eu/api/v1",
    api_key=os.environ["FRONTIERE_KEY"],
    input=["bonjour", "hello"],
)

6. Suivi des dépenses

LiteLLM embarque une liste de prix pour les modèles qu'il connaît ; les nôtres n'y figurent pas, donc par défaut il enregistre nos appels à coût nul. Donnez-lui nos prix dans model_info — input_cost_per_token et output_cost_per_token — et son suivi des dépenses, ses budgets et l'en-tête x-litellm-response-cost deviennent exacts.

Les valeurs de la configuration ci-dessus sont nos prix actuels pour ces modèles, en euros par token, marge et TVA comprises — le montant réellement débité de votre solde. Elles sont calculées depuis notre catalogue à la construction de la page : copiez-les d'ici plutôt que d'une vieille configuration.

LiteLLM ne convertit pas les devises : il multiplie les tokens par le coût par token que vous saisissez. Avec nos prix, les dépenses qu'il suit sont donc en euros — à garder en tête si le même budget couvre aussi des modèles tarifés en dollars.

Qui a servi chaque appel

Chaque réponse de notre gateway porte x-routed-provider (le fournisseur qui a servi l'appel) et x-sovereign (si ce fournisseur est de ceux que nous étiquetons souverains UE). LiteLLM les conserve : sur la réponse du proxy, ils reviennent préfixés llm_provider-, et dans le SDK ils se trouvent dans les paramètres cachés de la réponse.

# SDK — quel fournisseur a servi l'appel, et s'il est étiqueté souverain UE
headers = response._hidden_params["additional_headers"]
headers["llm_provider-x-routed-provider"]   # e.g. "scaleway"
headers["llm_provider-x-sovereign"]         # "true"

# Proxy — the same two headers on its HTTP response
curl -si http://localhost:4000/v1/chat/completions … | grep llm_provider-x-

Journalisez-les à côté du journal des requêtes de LiteLLM et vous avez, appel par appel, la trace de la juridiction qui l'a servi — la question qu'un audit pose après coup, et celle à laquelle une gateway qui mélange tout ne sait généralement pas répondre.

Ce que ça change, et ce que ça ne change pas

L'inférence part chez le fournisseur qui héberge le modèle, et l'étiquette du modèle vous dit de quelle juridiction il s'agit. LiteLLM, lui, reste là où vous l'avez déployé : votre proxy voit chaque prompt avant nous, et ses journaux comme sa base de données sont à vous de les placer. Auto-hébergé en Europe avec un modèle souverain, tout le chemin reste en Europe — notre gateway elle-même tourne à Paris chez Vercel, une société américaine, sans stocker ni prompt ni réponse (notre page de confidentialité le dit).

Une limite de plus à signaler à qui doit valider : si le même proxy route aussi vers des fournisseurs américains, les replis de LiteLLM peuvent faire passer une requête de l'un à l'autre. Pour les charges réglementées, gardez les chaînes de repli à l'intérieur des modèles étiquetés souverains UE.

RGPD contre CLOUD Act →

Dépannage

Les erreurs ci-dessous sont les messages exacts obtenus avec LiteLLM 1.105.0 :

Noms de paramètres vérifiés dans la documentation de LiteLLM le 2026-10-12 : docs.litellm.ai — OpenAI-compatible endpoints · docs.litellm.ai — proxy config.yaml · docs.litellm.ai — custom pricing · docs.litellm.ai — streaming usage · docs.litellm.ai — drop_params · docs.litellm.ai — /v1/responses & /v1/messages passthrough · PyPI — litellm

FAQ