Residency & Modelle

Die Offenlegungs-Header, verwaltete Aliasse und der Live-Modellkatalog mit Hinweisen zu Verfügbarkeit und Fallback.

Antwort-Header

Aufrufe eines sluis/*-Alias legen die aufgelöste Route über die x-sluis-*-Antwort-Header offen, und jeder Aufruf mit einem eingebetteten Dokument legt offen, wie dieses das Modell erreicht hat. Ein einfacher provider/model-Aufruf ohne Dokument trägt keines von beiden. Residency selbst ist Organisations-Policy, beim Versand durchgesetzt, nie ein Request-Header.

Verwaltete Aliasse

Verwaltete Aliasse sind reservierte sluis/... Modellnamen. sluis/auto wählt pro Anfrage unter den Routen, die Ihre Policy erlaubt: Ein Klassifikator innerhalb des Sluis-Deployments kann die Reasoning-Route wählen, ohne dass Text das Deployment verlässt; andernfalls liest ein gehosteter Klassifikator nach dem Datenschutz drei kurze Auszüge des Prompts, und zwar nur auf einem Modell eines EU-eigenen Anbieters mit Verarbeitung in der EU. Die Use-Case-Aliasse wählen aus täglichen Artificial Analysis Benchmark-Snapshots, die Sluis kuratiert. Artificial AnalysisJeder Alias wird zuerst innerhalb der Residency-Policy des Tenants aufgelöst, deshalb schlägt die Souveränitätsregel den Benchmark-Rang.

Rufen Sie einen Alias überall dort auf, wo Sie sonst eine provider/model-ID übergeben. Die Response-Header zeigen die angefragte Route und das konkrete Modell, das lief.

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 ist der verwaltete oder Tenant-Alias, der die Anfrage aufgelöst hat. x-sluis-model ist das konkrete provider/model-Ziel nach Residency-Policy, Shadowing und Routing. Lehnt der Anbieter das Credential für das Modell einer verwalteten Route ab, wechselt der Aufruf zum nächsten konformen Modell der Route; ein konkretes provider/model oder ein Tenant-Alias wird nie ersetzt.

Unterstützte Modelle

Sluis stellt integrierte Anbieter über verwaltete Keys bereit, wenn ein Plattform-Credential konfiguriert ist; verbinden Sie Ihren eigenen Key (BYOK) oder fügen Sie in der Console einen eigenen OpenAI-kompatiblen Anbieter hinzu, um den Katalog zu überschreiben oder zu erweitern. Jede aufrufbare Modell-ID trägt das Provider-Präfix: übergeben Sie provider/model (z. B. mistral/mistral-large-latest), und Sluis routet sie gemäß Ihrer Residency-Policy. Der Katalog berücksichtigt Credentials und Policy, nutzt verfügbare Live-Kataloge der Anbieter und kann bei einem Ausfall des Upstream-Katalogs auf deklarierte Modelle zurückfallen. Vertex-Kandidaten werden separat auf EU-Verfügbarkeit geprüft. Nebius Token Factory ist EU-eigen, aber seine öffentlichen nebius/...-Modelle haben keine Regionsgarantie: Sie zählen als GLOBAL und benötigen eine ausdrückliche GLOBAL-Freigabe. Nur nebius-eu, die dedizierten Endpunkte des Betreibers in einer EU-Region, zählt als EU.

tok/s ist der Ausgabedurchsatz, gemessen an echten Anfragen über Sluis in den letzten 7 Tagen — nicht an einem synthetischen Benchmark. Eine Zahl ohne Markierung schließt die Wartezeit auf das erste Token aus; ein ‡ enthält sie noch; ein † kennzeichnet eine vom Modellanbieter über Artificial Analysis veröffentlichte Zahl, die wir nicht gemessen haben. n/a bedeutet, dass wir für dieses Modell noch keinen Verkehr haben und der Anbieter nichts veröffentlicht.

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