Souveräne KI-Inferenz in der Schweiz: die Architektur

Souveräne KI-Inferenz ist eine Eigenschaft des gesamten Datenflusses, nicht des Modells. Ein in Zürich gehostetes Apertus-Modell ist nicht souverän, wenn die Traces bei einem US-Monitoring-Dienst landen, die Vektordatenbank in Irland liegt oder der Support aus einem Drittstaat in die Logs schaut. Souverän ist eine Architektur erst, wenn Prompt, Kontext, Gewichte, Logs und Metadaten dieselbe Jurisdiktion nie verlassen.

Über digitale Souveränität ist viel geschrieben worden. ipt etwa führt eine Seite mit dem Title-Tag „Souveräne KI Plattformen auf Kubernetes“ und hat das Thema mit dem ETH AI Center bespielt. Was fehlt, ist die Ebene darunter: welche Anbieter es gibt, was sie kosten, wie der Betrieb aussieht.

Wir rechnen das am Schweizer Markt durch, weil dort Preise und Rechtslage öffentlich prüfbar sind. Die Architektur darunter ist dieselbe, ob die souveräne Cloud in Zürich, Frankfurt oder Paris steht.

Was souveräne KI-Inferenz technisch bedeutet

Souveränität lässt sich an fünf Artefakten prüfen, die bei jeder Inferenz-Anfrage entstehen. Modellgewichte, Prompt, abgerufener Kontext, generierte Antwort und die Telemetrie darüber. Jedes hat einen physischen Speicherort und einen rechtlichen Zugriffsberechtigten, und die beiden sind nicht dasselbe.

Das Schweizer Recht macht daraus eine konkrete Prüfung. Art. 16 revDSG erlaubt die Bekanntgabe von Personendaten ins Ausland nur, wenn der Bundesrat den Zielstaat als angemessen eingestuft hat.

Die Liste steht in Anhang 1 der Datenschutzverordnung (SR 235.11). Die USA stehen seit dem 15. September 2024 darauf, aber nur für Organisationen, die unter dem Swiss-US Data Privacy Framework zertifiziert sind.

Der zweite Prüfpfad läuft über den Anbieter selbst. 18 U.S.C. § 2713, eingeführt mit dem CLOUD Act, verpflichtet US-Anbieter zur Herausgabe gespeicherter Daten „regardless of whether such communication, record, or other information is located within or outside of the United States“.

Ein Rechenzentrum in Zürich ändert daran nichts, wenn die betreibende Gesellschaft US-Konzernrecht untersteht. Welche Architekturentscheidungen daraus folgen, steht in revDSG-konforme KI-Architektur.

Welche Schweizer Cloud-Anbieter souveräne KI-Inferenz anbieten

Vier Anbieter kommen für produktive GPU-Inferenz in der Schweiz realistisch infrage, dazu der Eigenbetrieb. Nur einer davon publiziert vollständige Preise.

Anbieter	GPU-Typen	Abrechnungsmodell	Datenstandort	Kubernetes-Zugang	Öffentliche Preise
Exoscale	RTX Pro 6000 (96 GB), A40, A5000, A30, V100, 3080ti; B300 auf Anfrage	Instanz pro Stunde, Dedicated Inference pro Sekunde	je nach GPU-Typ CH-DK-2 (Schweiz), DE-FRA-1, AT-VIE-2, HR-ZAG-1	ja, SKS	ja, vollständig in CHF
Infomaniak	B300, H200, H100, A100, L40S, L4, A2, T4	GPU-Instanz pro Stunde, AI Services pro Token	Genf und Zürich	ja, Kubernetes-Dienst	teilweise: Token-Preise publiziert, Instanzpreise nur im Konfigurator
Swisscom Swiss AI Platform	NVIDIA SuperPOD	GPU as a Service, dazu Inference-Endpunkte pro Token	Schweiz	nicht dokumentiert	nein
Phoenix Technologies	H100, H200	nicht publiziert	Schweiz	nicht dokumentiert	nein
Eigenbetrieb, Colocation	frei wählbar	CapEx plus Housing	frei wählbar	ja, selbst gebaut	entfällt

Ein Detail, das bei der Souveränitätsprüfung zählt: Exoscales RTX-Pro-6000-Instanzen laufen in DE-FRA-1, HR-ZAG-1 und CH-DK-2, die 3080ti-Instanzen ausschliesslich in AT-VIE-2. Ein Schweizer Anbieter garantiert also nicht automatisch eine Schweizer Zone (abgerufen 18.08.2026).

Apertus 1.5: was das Schweizer Modell heute kann

Apertus 1.5 erschien am 24. Juli 2026 und ist gegenüber der Fassung vom September 2025 ein anderes Modell. Das Kontextfenster liegt bei 262’144 Tokens, eine Vervierfachung. Die Modelle nehmen neu Bilder entgegen, Audio ist als experimentell gekennzeichnet. Lizenz: Apache 2.0.

Für den Betrieb zählt die Tool-Integration mehr als die Multimodalität. Die Modellkarte für Apertus-v1.5-70B dokumentiert einen eigenen Tool-Call-Parser und einen optionalen Thinking-Modus, beides direkt in vLLM ansteuerbar. Damit ist Apertus für Agenten-Architekturen brauchbar, nicht nur für Chat.

Entwickelt haben es EPFL, ETH Zürich und das CSCS auf dem Alps-Supercomputer in Lugano. Wer nicht selbst betreiben will: Infomaniak führt swiss-ai/Apertus-v1.5-70B als API-Modell, aktuell als Beta.

Apertus selbst betreiben: Hugging Face, Ollama oder Apertus Mini

Für den Eigenbetrieb gibt es drei Wege mit sehr unterschiedlichem Produktionsreifegrad.

Hugging Face plus vLLM ist der produktive Pfad. swiss-ai/Apertus-v1.5-70B und die 8B-Variante liegen dort unter Apache 2.0 und laden ohne Konvertierungsschritt.

Ollama ist der schnellste Weg zum Prompt und der langsamste zur Produktion. Es gibt keinen offiziellen Apertus-Build von swiss-ai; die verbreiteten GGUF-Pakete stammen von Community-Packagern und führen die Fassung 2509, also Apertus 1.0. Wer 1.5 lokal will, quantisiert selbst. Für einen Laptop-Test ist das in Ordnung, für einen Dienst mit Parallellast nicht.

Apertus Mini löst oft das eigentliche Problem. Die offizielle Collection enthält Distillate der Reihe v1.1 in 0.5B, 1.5B und 4B, dazu Quantisierungen für MLX und vLLM. Für Klassifikation, Extraktion und Routing reicht ein 4B-Modell meist, und es verschiebt die GPU-Kosten um eine Grössenordnung.

Was Inferenz auf eigener Infrastruktur kostet

Modellrechnung, hergeleitet aus publizierten Preislisten, abgerufen am 18. August 2026. Sie gilt für Apertus-v1.5-70B und vergleicht zwei Bezugswege beim selben Souveränitätsniveau.

Die Modellkarte nennt als Referenzkonfiguration --tensor-parallel-size 4 bei vollen 262’144 Tokens Kontext. Bei 72 Milliarden Parametern in BF16 sind das 144 GB reine Gewichte, dazu der KV-Cache. Vier Karten mit je 96 GB sind damit das Minimum, keine Grosszügigkeit.

Eigenbetrieb, Exoscale Dedicated Inference auf RTX Pro 6000, publizierte Preisliste:

CHF 2.15277778 pro GPU und Stunde, sekundengenau abgerechnet
4 GPUs im Dauerbetrieb: 4 × 2.15277778 × 720 h = CHF 6’200 pro Monat
Modellspeicher 144 GiB zu CHF 0.0000275 pro GiB-Stunde: CHF 2.85 pro Monat

API-Bezug, Infomaniak AI Services, publizierte Preisliste: CHF 0.70 pro Million Input-Tokens, CHF 2.50 pro Million Output-Tokens für dasselbe Modell.

Angenommenes Anfrageprofil: 3’000 Tokens Input (Systemprompt plus RAG-Kontext), 500 Tokens Output. Das ergibt CHF 0.00335 pro Anfrage oder CHF 0.96 pro Million gemischter Tokens.

Der Kipppunkt liegt bei rund 1.85 Millionen Anfragen pro Monat, also etwa 62’000 pro Tag. Darunter ist die API günstiger. Das entspricht 6.5 Milliarden Tokens im Monat oder rund 2’500 Tokens pro Sekunde im Dauerdurchsatz.

Bei 2’500 Tokens pro Sekunde laufen die vier Karten allerdings rund um die Uhr am Anschlag, und kein Betrieb fährt so. Wer Reserve für Lastspitzen und eine zweite Zone für Ausfälle einplant, verdoppelt die GPU-Kosten und damit den Kipppunkt: realistisch drei bis vier Millionen Anfragen pro Monat.

Umgekehrt hilft die Sekundenabrechnung: Wer nur zu Bürozeiten Last hat und auf null skaliert, zahlt bei 220 Stunden im Monat CHF 1’894 statt CHF 6’200, und der Kipppunkt fällt auf rund 566’000 Anfragen. Die geforderte Spitzenlast bleibt dieselbe.

Nicht enthalten: der Cluster darunter (Exoscale SKS Pro CHF 0.054995 pro Stunde, rund CHF 40 im Monat, im Detail in was Kubernetes in der Schweiz wirklich kostet) und eure Zeit.

Rechnet den Kipppunkt für euer Profil nach. Er verschiebt sich stark durch Prompt-Caching, ein kleineres Modell oder einen anderen Input-Output-Schnitt. Wenn ihr euer Anfrageprofil kennt, rechnen wir das gemeinsam durch, mit euren Zahlen statt unseren Annahmen.

GPU-Scheduling auf Kubernetes: DRA statt Device Plugins

Dynamic Resource Allocation ersetzt die Zählweise „gib mir eine GPU“ durch eine Anforderung an Eigenschaften. Der Kern von DRA ist seit Kubernetes v1.34 GA, die API-Gruppe ist resource.k8s.io/v1; die Konzeptseite der Doku führt DRA inzwischen als Kubernetes v1.35 [stable].

Das alte Device Plugin kannte nur nvidia.com/gpu: 4. Welche vier Karten der Scheduler nimmt, war ihm egal. Bei einem 70B-Modell mit Tensor-Parallelismus ist das kein Detail: Vier Karten mit 24 GB sind nicht dasselbe wie vier mit 96 GB, und der Pod stirbt erst beim Laden der Gewichte.

Mit DRA formuliert ihr die Anforderung als CEL-Ausdruck gegen die Attribute, die der Treiber publiziert:

# Vier GPUs mit je mindestens 80 GiB, exklusiv für einen vLLM-Pod.
# Setzt den DRA-Treiber für NVIDIA-GPUs voraus (DeviceClass gpu.nvidia.com).
apiVersion: resource.k8s.io/v1
kind: ResourceClaimTemplate
metadata:
  name: apertus-70b-gpus
  namespace: inference
spec:
  spec:
    devices:
      requests:
        - name: gpu
          exactly:
            deviceClassName: gpu.nvidia.com
            allocationMode: ExactCount
            count: 4
            selectors:
              - cel:
                  expression: |
                    device.capacity['gpu.nvidia.com'].memory.isGreaterThan(quantity('80Gi'))

Der Pod referenziert das Template, statt eine Zahl zu fordern:

spec:
  resourceClaims:
    - name: gpu
      resourceClaimTemplateName: apertus-70b-gpus
  containers:
    - name: vllm
      image: vllm/vllm-openai:v0.27.1
      resources:
        claims:
          - name: gpu

Der Unterschied in der Praxis: Ein falsch dimensionierter Node fällt beim Scheduling durch, nicht nach acht Minuten Modell-Download. Der DRA-Treiber für NVIDIA-GPUs publiziert dafür unter anderem productName, architecture und cudaComputeCapability.

Inference-Serving: was zwischen Modell und Anwendung gehört

vLLM ist der Modellserver, nicht die Plattform. Es macht Continuous Batching, PagedAttention und einen OpenAI-kompatiblen Endpunkt. Was es nicht macht: entscheiden, welche von acht Replicas eine Anfrage bekommt.

Ein Deployment-Ausschnitt für Apertus. Tool-Parser und Chat-Template stammen aus der Modellkarte; das Kontextfenster ist halbiert, weil der KV-Cache sonst den GPU-Speicher füllt:

containers:
  - name: vllm
    image: vllm/vllm-openai:v0.27.1
    args:
      - --model=swiss-ai/Apertus-v1.5-70B
      - --served-model-name=apertus-70b
      - --tensor-parallel-size=4
      - --max-model-len=131072
      - --gpu-memory-utilization=0.90
      - --chat-template-content-format=string
      - --enable-auto-tool-choice
      - --tool-call-parser=apertus
    ports:
      - containerPort: 8000
    readinessProbe:
      httpGet: { path: /health, port: 8000 }

Das Routing gehört eine Ebene höher. Die Gateway API Inference Extension (v1.6.0 vom 17.08.2026) bringt den InferencePool und einen Endpoint Picker, der Warteschlangentiefe und KV-Cache-Auslastung auswertet. Ein Round-Robin-Loadbalancer trifft dagegen ein Replica, dessen Cache den Präfix nicht hat, und zahlt den Prefill zweimal.

apiVersion: inference.networking.k8s.io/v1
kind: InferencePool
metadata:
  name: apertus-70b
spec:
  selector:
    matchLabels: { app: apertus-70b }
  targetPorts:
    - number: 8000
  endpointPickerRef:
    name: apertus-70b-epp
    port: { number: 9002 }
    failureMode: FailOpen

llm-d (v0.9.0 vom 17.08.2026) kombiniert beides zu disaggregiertem Serving, also Prefill und Decode auf getrennten Pods. Für die meisten Installationen dieser Grösse ist das eine Nummer zu gross.

Wo Souveränität real bricht

Das Modell ist selten das Problem. Die Bruchstellen sitzen in der Peripherie, die niemand als KI-Komponente wahrnimmt und deshalb niemand prüft.

flowchart TB
  subgraph CH["Jurisdiktion Schweiz"]
    GW["Inference Gateway"]
    V["vLLM-Pods, Apertus 1.5 70B"]
    OBJ["Objektspeicher, Modellgewichte"]
  end
  subgraph EU["Jurisdiktion EU"]
    VDB["Vektordatenbank, Managed SaaS"]
  end
  subgraph US["Jurisdiktion USA, CLOUD Act"]
    CDN["CDN und WAF"]
    MON["Monitoring-SaaS, Traces mit Prompt-Inhalt"]
    SUP["Support-Zugriff aus Drittstaat"]
  end
  CLIENT["Client"] --> CDN
  CDN --> GW
  GW --> V
  V --> OBJ
  V -->|"Kontext-Abruf, Klartext"| VDB
  V -.->|"Traces, Logs"| MON
  MON -.->|"Einsicht"| SUP

Monitoring-SaaS ist die häufigste Bruchstelle. Ein OpenTelemetry-Trace um einen LLM-Aufruf enthält standardmässig Attribute wie gen_ai.prompt und gen_ai.completion. Wer den Collector auf einen US-Anbieter zeigen lässt, exportiert damit den Prompt-Inhalt, nicht nur Latenzen. Das ist kein Konfigurationsfehler, sondern das Default-Verhalten gängiger Instrumentierungen.

Die Vektordatenbank speichert den Klartext gleich mit. Jede RAG-Implementierung legt den Quelltext-Chunk als Payload neben den Vektor, sonst kann sie ihn nicht in den Prompt setzen. Eine Managed-Vektordatenbank mit Region Irland ist damit eine Kopie eures Dokumentenbestands ausserhalb der Schweiz.

Der Support-Zugriff steht im Vertrag, nicht im Architekturdiagramm. Ob ein Anbieter Second-Level-Support aus einem Drittstaat leistet und ob dieses Team Leseberechtigung auf Produktivsysteme hat, ist eine Frage an den Einkauf. Sie wird selten gestellt.

Das CDN sieht jede Anfrage, bevor sie den Origin erreicht. Wer einen US-CDN vor den Inference-Endpunkt setzt, hat den Prompt im Klartext bei einem Anbieter unter CLOUD-Act-Zugriff.

Dazu die leiseren: der Embedding-Dienst, oft ein anderer Anbieter als der LLM-Dienst, und der Objektspeicher für Modellgewichte, dessen Bucket-Region niemand mehr prüft. Wer diese Punkte auditiert, hat mehr für die Souveränität getan als mit der Wahl des Modells. Dieselbe Disziplin brauchte die verteilte Plattform, die wir für onocoy gebaut haben.

Wann souveräne Inferenz die falsche Antwort ist

Für die Mehrheit der Anwendungsfälle, die wir sehen, ist eigener GPU-Betrieb die teurere und langsamere Lösung. Unterhalb von etwa einer Million Anfragen pro Monat zahlt ihr für Souveränität einen Aufschlag, ohne technischen Gegenwert.

Ein API-Anbieter mit sauberem Auftragsbearbeitungsvertrag, dokumentiertem Datenstandort und einer Zusicherung zum Modelltraining deckt die revDSG-Anforderungen für Geschäftsdaten in aller Regel ab. Infomaniak etwa verarbeitet in Genf und Zürich. Das ist in Tagen produktiv, nicht in Wochen.

Eigenbetrieb lohnt sich, wenn eines davon zutrifft: Das Volumen liegt dauerhaft über dem Kipppunkt. Die Daten fallen unter ein Berufsgeheimnis nach Art. 321 StGB. Oder ihr braucht eine gepinnte Modellversion, weil eine Validierung daran hängt.

Wovon wir abraten: von der Zwischenlösung mit eigenem Cluster, aber Monitoring, Vektordatenbank und CDN beim US-Anbieter. Das kostet den vollen Betriebsaufwand und liefert die Souveränität trotzdem nicht.

Die Entscheidungsmatrix

Kriterium	API-Bezug	Dedizierte GPU in der Schweiz	On-prem oder Colocation
Anfragevolumen	bis rund 1 Mio. pro Monat	ab rund 3 Mio. pro Monat, planbar	dauerhaft hoch, über 3 Jahre gerechnet
Datenklasse	Geschäftsdaten ohne besondere Kategorien	besonders schützenswerte Personendaten (Art. 5 lit. c revDSG)	Berufsgeheimnis (Art. 321 StGB), Daten mit Ausfuhrverbot
Modellkontrolle	Anbieter bestimmt Version und Deprecation	ihr pinnt Version und Quantisierung	zusätzlich Treiber und Kernel
Latenzsteuerung	keine, Batching liegt beim Anbieter	Batchgrösse, KV-Cache, Präfix-Routing	zusätzlich der Netzwerkpfad
Betriebsaufwand	API-Schlüssel und Rechnung	Cluster, DRA-Treiber, vLLM, Gateway, Kapazitätsplanung	zusätzlich Hardware-Lifecycle
Zeit bis produktiv	Stunden	Tage bis Wochen	Monate

Die Zeilen sind nicht gleich gewichtet. Fast immer entscheidet die zweite: Welche Datenklasse fliesst durch den Prompt. Der Rest ist danach eine Kostenfrage.

Häufige Fragen

Welche Schweizer Alternativen zu ChatGPT gibt es?

Apertus ist das offene Schweizer Sprachmodell von EPFL, ETH Zürich und CSCS, in Version 1.5 seit dem 24. Juli 2026 verfügbar. Beziehen lässt es sich über Infomaniak AI Services, die Swisscom Swiss AI Platform, Phoenix Technologies oder von Hugging Face zum Eigenbetrieb. Daneben betreiben Schweizer Anbieter Endpunkte für offene Modelle von Mistral, Qwen und Google.

Was kostet ein selbst gehostetes LLM im Vergleich zur API?

Nach unserer Modellrechnung vom 18. August 2026 kosten vier RTX Pro 6000 bei Exoscale im Dauerbetrieb CHF 6’200 pro Monat. Dieselbe Last über die Infomaniak-API kostet bei 3’000 Input- und 500 Output-Tokens CHF 0.00335 pro Anfrage. Der rechnerische Kipppunkt liegt bei 1.85 Millionen Anfragen im Monat, mit Reserve für Spitzen und Ausfälle eher bei drei bis vier Millionen.

Welche Hardware brauche ich für ein eigenes LLM?

Für Apertus-v1.5-70B nennt die Modellkarte vier GPUs bei vollem Kontextfenster: 72 Milliarden Parameter in BF16 sind 144 GB reine Gewichte, dazu kommt der KV-Cache. Das 8B-Modell läuft auf einer Karte mit 48 GB komfortabel. Quantisierung senkt den Bedarf, kostet aber Qualität und muss für den konkreten Anwendungsfall gemessen werden.

Schützt Schweizer Hosting vor dem US CLOUD Act?

Nur, wenn der Betreiber nicht US-Recht untersteht. 18 U.S.C. § 2713 verpflichtet US-Anbieter zur Herausgabe von Daten unabhängig vom Speicherort. Entscheidend ist also die Gesellschaftsstruktur des Anbieters, nicht die Adresse des Rechenzentrums. Ein Rechenzentrum in Zürich, betrieben von einer Schweizer Tochter eines US-Konzerns, fällt weiterhin unter den Zugriff.

Inferenz-Architektur besprechen. 30 Minuten mit einem unserer Engineers über euren konkreten Fall: welches Modell, welches Volumen, wo die Daten liegen und wo die Peripherie die Jurisdiktion verlässt. Kein Verkaufsgespräch, keine Vorbereitung nötig.

Termin buchen · Kontakt aufnehmen · Mehr zu Künstlicher Intelligenz und Kubernetes und Infrastruktur