3GK AI3GK AIDocumentation
Routage & souverainetéRoutage vLLM / Scaleway

Routage vLLM / Scaleway

La gateway choisit dynamiquement le backend qui exécute chaque requête de chat/completions. Deux fournisseurs sont possibles, tous deux hébergés en France : nos instances vLLM internes et l'API Scaleway Generative APIs (Paris).

souveraineté FRconfigurable

Schéma logique#schema

Le routage se fait en plusieurs étapes, dans l'ordre :

  1. Résolution de l'alias public (3gk-llm, ou un identifiant legacy toléré) vers le modèle servi.
  2. Vérification du flag global forceFallback (toggle admin).
  3. Sélection d'une instance vLLM servant ce modèle (round-robin).
  4. Application du mode de routage (local, fallback, auto).
  5. Pour le mode auto, ping de joignabilité de l'instance vLLM (cache 5 s, single-flight).

Modes de routage#modes

ModeComportement
localvLLM uniquement. Si l'instance est HS, la requête échoue (502/504) sans bascule.
fallbackScaleway uniquement. L'alias demandé est résolu vers le modèle Scaleway correspondant.
autovLLM en priorité. Bascule vers Scaleway si le ping vLLM échoue (modèle Scaleway défini par instance ou globalement).

Le mode actif est défini globalement par l'administrateur de la plateforme. Il n'est pas contrôlable par le client via le body de la requête.

Alias stables#alias

Lorsque vous envoyez model: "3gk-llm", la gateway résout l'alias dans cet ordre :

  1. Une instance vLLM activée servant le modèle (round-robin entre les instances).
  2. À défaut, le modèle Scaleway de secours configuré par l'admin.
  3. Si rien n'est configuré : 503 upstream_error.
Rétrocompatibilité. L'ancien alias default et les anciens identifiants de modèles restent acceptés en entrée pendant une période de transition ; les réponses renvoient toujours l'alias canonique 3gk-llm.

Force fallback#force-fallback

L'administrateur peut activer un toggle forceFallback qui bypass entièrement le routage normal et force toutes les requêtes vers Scaleway. Utile en cas d'incident majeur sur l'infrastructure vLLM (panne GPU, maintenance prolongée, etc.). Aucune action n'est requise côté client — l'API reste compatible et continue de répondre.

Comportement en erreur#comportement

  • Timeout vLLM ou Scaleway → 504 upstream_timeout. Pas de retry automatique côté gateway en V1.
  • Erreur réseau / 5xx upstream → 502 upstream_error avec message tronqué (300 caractères) dans error.message.
  • Mode local sans instance disponible → 503 upstream_error. Aucune bascule automatique : l'admin doit changer le mode pour utiliser Scaleway.

Souveraineté & RGPD#souverainete

Tout reste en France. Que ce soit en mode local ou fallback, vos prompts et complétions ne sortent jamais du territoire français. vLLM tourne sur nos GPU privés, Scaleway Generative APIs est hébergé à Paris. Aucun fournisseur hors UE n'est sollicité.

La gateway n'enregistre jamais le contenu des prompts ni des réponses dans ses logs — seuls les compteurs de tokens, la latence et le statut HTTP sont conservés à des fins de facturation et de monitoring. Cette politique est documentée dans nos CGU et DPA.