Residencia y modelos

Las cabeceras de divulgación, los alias gestionados y el catálogo de modelos en vivo, con notas de disponibilidad y alternativas.

Cabeceras de respuesta

Las llamadas a un alias sluis/* divulgan la ruta resuelta mediante las cabeceras de respuesta x-sluis-*; y toda llamada que incluyera un documento en línea revela cómo llegó ese documento al modelo. Una llamada provider/model normal sin documento no lleva ninguna de las dos. La residencia en sí es política de la organización, aplicada en el despacho, nunca una cabecera de petición.

Alias gestionados

Los alias gestionados son nombres de modelo reservados sluis/.... sluis/auto elige por petición entre las rutas que permite su política: un clasificador dentro del despliegue de Sluis puede elegir la ruta de razonamiento sin que ningún texto salga de él; si no, un clasificador alojado lee tres extractos breves del prompt tras la protección de datos, y solo en un modelo de un proveedor de propiedad europea que procesa en la UE. Los alias por caso de uso eligen desde snapshots diarios de benchmarks de Artificial Analysis curados por Sluis. Artificial AnalysisCada alias se resuelve primero dentro de la política de residencia del tenant, así que la regla de soberanía gana al ranking del benchmark.

Llame a un alias en cualquier lugar donde pasaría un id provider/model. Las cabeceras de respuesta muestran la ruta solicitada y el modelo concreto ejecutado.

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 es el alias gestionado o de tenant que resolvió la petición. x-sluis-model es el destino provider/model concreto después de política de residencia, shadowing y enrutamiento. Si el proveedor rechaza la credencial para el modelo de una ruta gestionada, la llamada pasa al siguiente modelo conforme de la ruta; un provider/model concreto o un alias de tenant nunca se sustituye.

Modelos compatibles

Sluis expone proveedores integrados mediante claves gestionadas cuando hay una credencial de plataforma configurada; conecte su propia clave (BYOK) o añada un proveedor compatible con OpenAI personalizado en la Consola para anular o ampliar el catálogo. Cada id invocable lleva el prefijo del proveedor: pase provider/model (p. ej. mistral/mistral-large-latest) y Sluis lo enruta según su política de residencia. El catálogo tiene en cuenta las credenciales y la política, usa catálogos en vivo de los proveedores cuando están disponibles y puede recurrir a modelos declarados si falla un catálogo upstream. La disponibilidad en la UE de los candidatos de Vertex se verifica por separado. Nebius Token Factory es de propiedad europea, pero sus modelos públicos nebius/... no tienen garantía de región: cuentan como GLOBAL y requieren una autorización GLOBAL explícita. Solo nebius-eu, los endpoints dedicados del operador en una región de la UE, cuenta como UE.

tok/s es el rendimiento de salida, medido sobre peticiones reales a través de Sluis en los últimos 7 días, no sobre una prueba sintética. Un número sin marca excluye la espera del primer token; un ‡ todavía la incluye; un † indica una cifra publicada por el proveedor del modelo vía Artificial Analysis, que nosotros no hemos medido. n/a significa que aún no tenemos tráfico para este modelo y el proveedor no publica nada.

# 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"