Residenza e modelli

Gli header di divulgazione, gli alias gestiti e il catalogo modelli dal vivo, con note sulla disponibilità e sul fallback.

Header di risposta

Le chiamate a un alias sluis/* divulgano la rotta risolta tramite gli header di risposta x-sluis-*; e ogni chiamata che includeva un documento inline rivela come quel documento è arrivato al modello. Una normale chiamata provider/model senza documento non porta nessuno dei due. La residenza in sé è policy dell'organizzazione, applicata al dispatch, mai un header di richiesta.

Alias gestiti

Gli alias gestiti sono nomi modello riservati sluis/.... sluis/auto sceglie per richiesta tra le route che la tua policy consente: un classificatore all’interno dell’installazione Sluis può scegliere la route di ragionamento senza che alcun testo ne esca; altrimenti un classificatore ospitato legge tre brevi estratti del prompt dopo la protezione dei dati, e solo su un modello di un provider di proprietà europea che elabora nell’UE. Gli alias per caso d’uso scelgono da snapshot quotidiani dei benchmark Artificial Analysis curati da Sluis. Artificial AnalysisOgni alias si risolve prima dentro la policy di residenza del tenant, quindi la regola di sovranità batte il ranking del benchmark.

Chiama un alias ovunque passeresti un id provider/model. Gli header di risposta mostrano la route richiesta e il modello concreto eseguito.

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 è l’alias gestito o tenant che ha risolto la richiesta. x-sluis-model è il target provider/model concreto dopo policy di residenza, shadowing e routing. Se il provider rifiuta la credenziale per il modello di una route gestita, la chiamata passa al modello conforme successivo della route; un provider/model concreto o un alias tenant non viene mai sostituito.

Modelli supportati

Sluis espone i provider integrati tramite chiavi gestite quando è configurata una credenziale di piattaforma; collega la tua chiave (BYOK) o aggiungi un provider compatibile OpenAI personalizzato nella Console per sovrascrivere o estendere il catalogo. Ogni id richiamabile ha il prefisso del provider: passa provider/model (ad es. mistral/mistral-large-latest) e Sluis lo instrada secondo la tua policy di residenza. Il catalogo tiene conto delle credenziali e della policy, usa i cataloghi live dei provider quando disponibili e può ripiegare sui modelli dichiarati durante un errore del catalogo upstream. I candidati Vertex sono verificati separatamente per la disponibilità UE. Nebius Token Factory è di proprietà europea, ma i suoi modelli pubblici nebius/... non hanno alcuna garanzia di regione: contano come GLOBAL e richiedono un’autorizzazione GLOBAL esplicita. Solo nebius-eu, gli endpoint dedicati dell’operatore in una regione UE, conta come UE.

tok/s è il throughput di output, misurato su richieste reali tramite Sluis negli ultimi 7 giorni, non su un benchmark sintetico. Un numero senza segno esclude l'attesa del primo token; un ‡ la include ancora; un † indica una cifra pubblicata dal fornitore del modello tramite Artificial Analysis, che non abbiamo misurato noi. n/a significa che non abbiamo ancora traffico per questo modello e il fornitore non pubblica nulla.

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