Résidence & modèles

Les en-têtes de divulgation, les alias gérés et le catalogue de modèles en direct, avec les notes de disponibilité et de repli.

En-têtes de réponse

Les appels à un alias sluis/* divulguent la route résolue via les en-têtes de réponse x-sluis-* ; tout appel comportant un document en ligne indique comment ce document est parvenu au modèle. Un appel provider/model ordinaire sans document ne porte ni l'un ni l'autre. La résidence elle-même est une politique d'organisation, appliquée à l'envoi, jamais un en-tête de requête.

Alias gérés

Les alias gérés sont des noms de modèle réservés sluis/.... sluis/auto choisit par requête parmi les routes que votre politique autorise : un classifieur interne au déploiement Sluis peut choisir la route de raisonnement sans qu’aucun texte n’en sorte ; sinon, un classifieur hébergé lit trois courts extraits du prompt après la protection des données, et uniquement sur un modèle d’un fournisseur détenu dans l’UE qui traite dans l’UE. Les alias par usage choisissent depuis des snapshots quotidiens des benchmarks Artificial Analysis curés par Sluis. Artificial AnalysisChaque alias se résout d’abord dans la politique de résidence du tenant, donc la règle de souveraineté passe avant le rang du benchmark.

Appelez un alias partout où vous passeriez un id provider/model. Les en-têtes de réponse montrent la route demandée et le modèle concret exécuté.

curl https://api.sluis.ai/v1/chat/completions \
  -H "Authorization: Bearer $SLUIS_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "model": "sluis/auto", "messages": [{ "role": "user", "content": "Plan a GDPR-safe rollout" }] }'

# response headers:
# x-sluis-route: sluis/auto
# x-sluis-model: mistral/mistral-large-latest

x-sluis-route est l’alias géré ou tenant qui a résolu la requête. x-sluis-model est la cible provider/model concrète après politique de résidence, shadowing et routage. Si le fournisseur refuse l’identifiant pour le modèle d’une route gérée, l’appel passe au modèle conforme suivant de la route ; un provider/model concret ou un alias tenant n’est jamais remplacé.

Modèles pris en charge

Sluis expose les fournisseurs intégrés via des clés gérées lorsqu'un identifiant de plateforme est configuré ; connectez votre propre clé (BYOK) ou ajoutez un fournisseur compatible OpenAI personnalisé dans la Console pour remplacer ou étendre le catalogue. Chaque identifiant appelable porte le préfixe du fournisseur : passez provider/model (p. ex. mistral/mistral-large-latest) et Sluis le route selon votre politique de résidence. Le catalogue tient compte des identifiants et de la politique, utilise les catalogues en direct des fournisseurs lorsqu'ils sont disponibles et peut revenir aux modèles déclarés si le catalogue en amont échoue. La disponibilité UE des candidats Vertex est vérifiée séparément par sonde. Nebius Token Factory est détenu dans l’UE, mais ses modèles publics nebius/... n’ont aucune garantie de région : ils relèvent de GLOBAL et exigent une autorisation GLOBAL explicite. Seul nebius-eu, les endpoints dédiés de l’opérateur dans une région de l’UE, compte comme UE.

tok/s correspond au débit de sortie, mesuré sur des requêtes réelles via Sluis sur les 7 derniers jours — pas sur un banc d'essai synthétique. Un nombre sans marque exclut l'attente du premier token ; un ‡ l'inclut encore ; un † signale un chiffre publié par l'éditeur du modèle via Artificial Analysis, que nous n'avons pas mesuré. n/a signifie que nous n'avons pas encore de trafic pour ce modèle et que l'éditeur ne publie rien.

# models callable through Sluis platform credentials — no auth
curl https://api.sluis.ai/public/models.json | jq '.models[] | "\(.provider)/\(.model)"'

# per key: the models your policy, credentials and allow-list actually reach
curl https://api.sluis.ai/v1/models -H "Authorization: Bearer $SLUIS_KEY"