KI selbst hosten: wann sich private KI technisch und wirtschaftlich lohnt

Selbst gehostete KI bedeutet, dass Ihr Unternehmen die Infrastruktur für die Modellausführung selbst betreibt statt die eines Anbieters zu nutzen. Das kann ein Modell mit offenen Gewichten auf einem GPU-Server in einem Schweizer Rechenzentrum sein oder eine Inferenzplattform auf Kubernetes in einer eigenen Private Cloud.

Bei sensiblen Daten liegt der Gedanke nahe, das Modell selbst zu betreiben. Ob dafür eigene GPUs nötig sind oder ein verwalteter regionaler Dienst genügt, lässt sich daraus aber noch nicht ableiten. Entscheidend sind die benötigte Kontrolle, die Qualität für Ihren Anwendungsfall und der Betrieb, den Ihr Team zuverlässig leisten kann.

Was Selbsthosting tatsächlich bedeutet

Private KI kann sehr unterschiedliche Betriebsmodelle bezeichnen. Klären Sie vor der Architekturwahl und Beschaffung, wer das Modell ausführt, wo die Daten verarbeitet werden und welche Aufgaben bei Ihrem Team bleiben.

Die Kategorien überschneiden sich. Ein Modell mit offenen Gewichten auf gemieteten Cloud-GPUs in der eigenen VPC ist gleichzeitig Cloud-KI und selbst gehostete KI. Entscheidend sind vier getrennte Fragen: wohin die Daten fliessen, wer die Inferenz betreibt, wer für die Sicherheit verantwortlich ist und welche rechtlichen Pflichten für den Anwendungsfall gelten.

Ein privater Endpunkt ist kein privates Hosting

Diese Unterscheidung geht am häufigsten verloren, und sie spät zu korrigieren wird teuer.

AWS beschreibt PrivateLink als Zugang zu Amazon Bedrock aus einer VPC ohne Internet-Gateway, sodass der Dienst wirkt, als läge er in der VPC (AWS-Dokumentation). Der Verkehr ist privat. Bedrock bleibt ein von AWS verwalteter Dienst, und das Modell läuft weiterhin bei AWS. Die VPC Service Controls von Google bilden ebenso einen Sicherheitsperimeter um die verwalteten KI-Dienste, um Datenabfluss zu begrenzen (Google Cloud). Das ist eine Kontrolle um einen verwalteten Dienst herum, kein Beleg dafür, dass das Modell auf Ihrer Hardware läuft.

Der Verarbeitungsort ist eine dritte, eigenständige Frage. Microsoft unterscheidet in der Foundry-Dokumentation zwischen dem Speicherort der Daten und dem Ort der Verarbeitung: Global-Deployments können eine Anfrage in jeder Azure-Region verarbeiten, Data-Zone-Deployments halten die Verarbeitung in einer festgelegten Zone, und geografiegebundene Deployments bleiben in der gewählten Azure-Geografie (Microsoft Learn).

Ein privater Netzwerkpfad bedeutet also keine Verarbeitung ausschliesslich in der Schweiz, und eine Verarbeitung in der Schweiz bedeutet nicht, dass Sie das Modell betreiben. Wer in der Beschaffung nur fragt, wo der Endpunkt liegt, erhält eine beruhigende Antwort, die nichts klärt. Die bessere Frage lautet, wo Anfragen, abgerufene Dokumente, Embeddings, Protokolle, Sicherungen und die Inferenz jeweils verarbeitet werden, durch welche Stellen, und unter welchen Regelungen zu Aufbewahrung und Supportzugriff.

Was Sie gewinnen und was Sie übernehmen

Selbsthosting gibt Ihnen direkte Kontrolle über die Modellausführung und die Datenflüsse. Ob sich damit die Vertraulichkeit verbessert, hängt von den umgesetzten Massnahmen ab.

Mit dem Modellserver unter eigener Kontrolle entscheiden Sie, welche Gewichte laufen und wann Versionen wechseln, welches Quantisierungsformat verwendet wird, was protokolliert wird, ob es überhaupt ausgehenden Internetverkehr gibt, welche Datenquellen erreichbar sind, wie lange Anfragen bestehen bleiben und ob die Inferenz weiterläuft, wenn das externe Netz ausfällt. Auch tiefere Anpassungen werden einfacher: Laufzeitumgebungen wie vLLM unterstützen mehrere Quantisierungsverfahren sowie verteilte Tensor- und Pipeline-Parallelität, sodass ein Modell über mehrere GPUs verteilt werden kann, wenn ein Beschleuniger zu wenig Speicher hat (vLLM-Dokumentation).

Diese Kontrolle bringt laufende Aufgaben mit sich. Ihr Team oder ein Betriebspartner muss Aktualisierungen, Kapazitätsplanung, Überwachung und Störungsbehebung übernehmen.

Die Plattform ist grösser als das Modell

Ein produktives System für private KI ist nicht eine GPU mit einem Modell darauf. Der Pfad führt von der Nutzerin über Single Sign-on und Identität in die Anwendung, durch ein Gateway, das Richtlinien durchsetzt, weiter zu Suche und Werkzeugen und erst dann zum Modellserver und seinen GPUs. Darum herum liegen Vektorspeicher, Dokumentenablage, Secrets-Verwaltung, Schlüssel, Audit-Logs, Überwachung, Prüfpipelines und Deployment-Automatisierung.

Auf Kubernetes kommt die GPU-Ebene hinzu. Kubernetes stellt Beschleuniger über Device-Plugins der Hersteller bereit, die Ressourcen wie nvidia.com/gpu bekannt machen (Kubernetes-Dokumentation), und der GPU Operator von NVIDIA verwaltet Treiber, Device-Plugin, Container-Toolkit, Node-Labels und GPU-Monitoring, damit diese Knoten nutzbar sind (NVIDIA). Das sind etablierte Werkzeuge. Trotzdem braucht es jemanden, der sie wartet und bei Störungen eingreift.

«Wir können das Modell herunterladen» ist kein Nachweis der Produktionsreife.

GPUs nach Last dimensionieren, nicht nach Parameterzahl

Die Modellgrösse ist eine erste Näherung. Sie ist keine Kapazitätsplanung.

Googles veröffentlichte Zahlen zu Gemma 3 zeigen, wie stark sich das Zahlenformat auf den Speicherbedarf auswirkt, noch bevor Parallelität ins Spiel kommt. Das Modell mit 27 Milliarden Parametern braucht rund 54 GB für BF16-Gewichte gegenüber 14.1 GB bei Quantisierung auf INT4; das 12B-Modell fällt von etwa 24 GB auf 6.6 GB und das 4B-Modell von 8 GB auf 2.6 GB (Google Developers). Das sind nur die Gewichte. Google Compute Engine führt NVIDIA H100 derzeit mit 80 GB GPU-Speicher je Beschleuniger und H200 mit 141 GB (Google Cloud).

Daraus folgt nicht, dass ein Modell mit 79 GB Gewichten auf eine 80-GB-Karte passt. Zur Laufzeit benötigen ausserdem der Key-Value-Cache (KV-Cache) für den Attention-Mechanismus, Aktivierungen, die Laufzeitumgebung und das Batching Speicher; lange Kontexte bei hoher Parallelität treiben das deutlich über die Grösse der Gewichtsdatei hinaus. Passt ein Modell nicht auf einen Beschleuniger, unterstützt vLLM Tensor-Parallelität über GPUs und Pipeline-Parallelität über Knoten, wenn es nicht in einen Server passt (vLLM).

Für die Beschaffung folgt daraus: dimensionieren Sie nach der gemessenen Höchstzahl gleichzeitiger Anfragen, Länge der Eingaben und Ausgaben sowie Latenzzielen. Quantisierung senkt den Speicherbedarf tatsächlich, wie Googles eigene Zahlen zeigen, muss aber gegen Ihre Qualitätsanforderungen geprüft werden statt als kostenlose Kompression zu gelten.

Kleine Modelle eröffnen weitere Möglichkeiten

Nicht jede private Arbeitslast braucht eine H100. Gemma 3 wurde mit Modellen mit 1, 4, 12 und 27 Milliarden Parametern vorgestellt (Google Developers), und Google hat die Variante mit einer Milliarde Parametern ausdrücklich für den Einsatz auf Endgeräten entworfen (Google Developers).

Damit kommt der Betrieb auf Endgeräten für klar begrenzte Aufgaben infrage: Klassifikation, Feldextraktion, eine lokale Gerätebedienung, das Zusammenfassen von Material, das die Maschine nicht verlassen soll. Der Fehler liegt in der Übertragung auf allgemeine geschäftliche Schlussfolgerungen. Wählen Sie ein kleines lokales Modell, weil Ihre Tests zeigen, dass es für die definierte Aufgabe genügt, und nicht, weil privat als besser gilt.

Was gehostete KI-APIs kosten

Das wirtschaftliche Argument für private KI kommt meist bereits vereinfacht an: APIs sind teuer, eigene GPUs sind günstiger. Ab einer bestimmten Grösse kann das stimmen. Als allgemeine Aussage stimmt es nicht.

Beginnen Sie bei den tatsächlichen Kosten gehosteter Inferenz. OpenAI nennt am 13. September 2026 als Standard-Listenpreise für kurze Kontexte 10 Dollar pro Million Eingabe-Token und 50 pro Million Ausgabe-Token für GPT-6 Astra, 2 und 12 für GPT-5.6 Terra sowie 0.20 und 1.20 für GPT-5.6 Luna, mit einem Aufschlag von 10 % auf regionale Endpunkte mit Datenstandortgarantie für Modelle ab dem 5. März 2026 (OpenAI). Anthropic führt 2 Dollar pro Million Eingabe- und 10 pro Million Ausgabe-Token für Claude Sonnet 5 sowie 1 und 5 für Haiku 4.5, wobei die Verarbeitung ausschliesslich in den USA für Claude-Modelle ab Version 4.6 einen Aufschlag von 10 % kostet; Partnerplattformen haben eigene regionale Preise (Anthropic).

Die Beispiele zeigen, wie stark die API-Kosten je nach Modell variieren. Sie sagen nicht aus, dass ein selbst betriebenes Modell dieselbe Qualität erreicht. Alle Beträge sind in US-Dollar angegeben.

Mischpreise berechnet aus den oben verlinkten Listenpreisen, ohne Caching, Batch-Tarife, Werkzeugkosten, regionale Aufschläge und verhandelte Konditionen. Der Referenzknoten wird unten erläutert.

In diesen Beispielen verschiebt die Wahl des API-Modells den Punkt gleicher Ausgaben um den Faktor 45. Benennen Sie das zu ersetzende Modell und prüfen Sie die Alternative an denselben Aufgaben, bevor Sie die Kosten bewerten.

Was ein GPU-Knoten tatsächlich kostet

Öffentliche GPU-Preise schwanken nach Region, Reservierungsart und Bezugsmodell. Google führt die Konfiguration a3-highgpu-8g mit acht H100 mit rund 88.49 Dollar pro Stunde bei bedarfsgerechter Abrechnung und 38.86 Dollar bei einer Ressourcenbindung über drei Jahre (Google Cloud). Bei durchgehendem Betrieb und 730 Stunden als Monatsreferenz sind das etwa 28'400 bis 64'600 Dollar Rechenleistung pro Monat, bevor Anwendungsentwicklung, Speicher, Netzwerk und Personal hinzukommen. Google beschreibt A3 High in der grössten Ausbaustufe mit acht H100 und 640 GB GPU-Speicher (Google Cloud); ein kleineres Modell kann mit deutlich weniger auskommen. Der niedrigere Preis setzt eine Bindung über drei Jahre voraus. Die Werte dienen als Referenz und sind kein Angebot für eine Schweizer Region. Prüfen Sie Standort, Kapazität und Vertragsbedingungen vor der Budgetplanung.

Bei einer nach Token abgerechneten API sinken die Inferenzkosten, wenn weniger Anfragen eingehen. Ein reservierter Cluster kostet bei 10 % Auslastung fast dasselbe wie bei 90 %, und Google hält ausdrücklich fest, dass laufende Instanzen auch im Leerlauf Gebühren verursachen und die Gebühren für zugesicherte Ressourcen unabhängig von der Nutzung anfallen (Google Cloud).

Selbsthosting lässt sich umso leichter begründen, je höher und je planbarer die Nachfrage ist. Eines von beiden genügt nicht.

Gleiche Ausgaben bedeuten noch keine Wirtschaftlichkeit

Die letzte Tabellenspalte setzt API-Ausgaben mit reinen Knotenkosten gleich, belegt damit aber noch keine Wirtschaftlichkeit. Ein belastbarer Vergleich muss beantworten, ob das offene Modell die erforderliche Qualität erreicht, ob diese Hardware den erforderlichen Durchsatz bei der geforderten Latenz erreicht, welche Auslastung real erreicht wird, wie viele Replikate die Verfügbarkeit verlangt und was Entwicklung, Sicherheit, Speicher, Netzwerk, Sicherung, Beobachtbarkeit und Support zusätzlich kosten.

Die gehostete Seite verdient dieselbe Sorgfalt. Prompt-Caching, asynchrone Batch-Tarife, Mengenrabatte und das Routing einfacher Aufgaben auf günstigere Modelle verschieben die Zahl. Microsofts Foundry-Batch-Deployments nennen 50 % Ersparnis gegenüber Global Standard im Tausch gegen asynchrone Verarbeitung mit einer Zielzeit von bis zu 24 Stunden (Microsoft Learn), und die Batch-API von Anthropic gewährt dieselben 50 % auf Eingabe- und Ausgabe-Token (Anthropic). Wenn Ihre Aufgaben eine Verarbeitung im Batch erlauben, gehören diese reduzierten Tarife in den Vergleich.

Vergleichen Sie die Kosten je erfolgreich erledigter Aufgabe bei der geforderten Qualität und Verfügbarkeit.

In der Praxis lässt sich Selbsthosting nur schwer rechtfertigen für gelegentlich genutzte interne Assistenten, Pilotprojekte mit ungewisser Nutzung, Aufgaben, die auf die neuesten Spitzenmodelle angewiesen sind, oder ein Unternehmen, das für eine einzige Anwendung ein Team für den GPU-Betrieb aufbauen müsste. Plausibel wird es bei stabilen, grossen Mengen an Extraktion, Klassifikation, Zusammenfassung oder Suche, wenn ein kleineres offenes Modell Ihre Prüfungen bereits bestanden hat und die Hardware ausgelastet bleibt.

Selbst hosten macht ein System nicht sicher

Ein Modellserver im eigenen Rechenzentrum mit Standardpasswort, weiten Netzrechten, ungepatchten Container-Images und einem unbeschränkten Dokumentenzugriff ist unsicherer als eine sauber konfigurierte verwaltete Plattform. Der Standort allein gewährleistet keine Sicherheit.

Sicherheit ist eine Eigenschaft des Systems, nicht des Gebäudes, in dem die GPUs stehen.

AWS formuliert das Prinzip für Bedrock: AWS schützt die Infrastruktur, und das nutzende Unternehmen bleibt für seine Inhalte und die Konfiguration des Dienstes verantwortlich, einschliesslich Identitäts- und Zugriffskontrollen (AWS). Beim Selbsthosting übernimmt Ihr Team zusätzlich den Schutz der Modellserver und ihrer Infrastruktur.

Generative KI bringt zudem Risiken mit, die ein Netzwerkperimeter nicht abdeckt. Das Generative AI Profile von NIST erweitert das AI Risk Management Framework auf diese Systemklasse (NIST), und OWASP behandelt Prompt Injection als eigenständiges Problem der Anwendungssicherheit (OWASP). Für einen internen Wissensassistenten heisst das: Berechtigungsprüfung vor dem Abruf, damit der Assistent kein Dokument zeigt, das die Person nicht ohnehin öffnen dürfte, Umgang mit Prompt Injection in nicht vertrauenswürdigen Dokumenten und Webinhalten, Lieferkette für Modelle und Container, Secrets und Werkzeugrechte, Aufbewahrung und Schwärzung von Protokollen, ausgehender Verkehr, Schlüsselverwaltung, Herkunft der Modellversionen und menschliche Freigabe bei folgenreichen Aktionen.

Schweizer und EU-Recht richten sich nach dem Anwendungsfall

Ein Modell in Zürich zu betreiben belegt keine Rechtskonformität. Der Eidgenössische Datenschutz- und Öffentlichkeitsbeauftragte hält fest, dass das Datenschutzgesetz unmittelbar für KI-gestützte Bearbeitungen von Personendaten gilt (EDÖB), und das DSG selbst regelt Datenschutz durch Technik und datenschutzfreundliche Voreinstellungen sowie Auftragsbearbeitung, Sicherheit und Bekanntgabe ins Ausland (Fedlex). Sie müssen weiterhin wissen, welche Personendaten in Anfragen und Suchindizes gelangen, zu welchem Zweck, wer darauf zugreifen kann, was protokolliert wird, welche Auftragsbearbeiter beteiligt sind und ob die Massnahmen angemessen sind.

Das DSG verlangt auch nicht pauschal, dass Schweizer Personendaten physisch in der Schweiz bleiben. Es regelt die Bekanntgabe ins Ausland unter definierten Garantien, statt sie zu verbieten (Fedlex). Eine Architektur ausschliesslich in der Schweiz ist dann richtig, wenn die rechtliche Prüfung, eine vertragliche Zusage, eine Branchenvorgabe oder eine Kundenanforderung sie verlangt, und sie ersetzt diese Prüfung nicht.

Auch die DSGVO stellt Bedingungen an internationale Datenübermittlungen. Kapitel V legt Bedingungen fest, die das Schutzniveau erhalten sollen, wenn Personendaten den EWR verlassen; der Europäische Datenschutzausschuss beschreibt das so, dass der Schutz die Daten begleitet (EDSA). Ein privates Modell kann die Zahl externer Auftragsbearbeiter und internationaler Übermittlungen verringern. Es hebt Pflichten zu Auftragsbearbeitung, Sicherheit und Folgenabschätzung nicht auf.

Beim KI-Gesetz der EU hat sich der Kalender 2026 verschoben. Die Verordnung (EU) 2026/1744 bestätigt den 2. August 2026 als allgemeines Anwendungsdatum, verschiebt aber die Abschnitte 1 bis 3 von Kapitel III mit Ausnahme von Artikel 6 Absatz 5 für die grossen Hochrisiko-Kategorien auf den 2. Dezember 2027 für Systeme nach Anhang III und Artikel 6 Absatz 2 sowie auf den 2. August 2028 für Systeme nach Anhang I und Artikel 6 Absatz 1 (EUR-Lex). Für die Architekturentscheidung bleibt entscheidend: Die Einstufung richtet sich danach, was das System tut und welche Rolle Ihr Unternehmen einnimmt, nicht danach, wo die Gewichte liegen. Ein lokal betriebenes Modell in einem regulierten Hochrisiko-Einsatz wird nicht risikoarm, weil kein Anbieter die Anfragen sieht, und ein gewöhnlicher interner Assistent wird nicht hochriskant, weil er eine verwaltete API aufruft.

Drei Architekturen, die funktionieren

Ein kleines Unternehmen mit einem internen Wissensassistenten. Mitarbeitende stellen Fragen zu Richtlinien, Verträgen und interner Dokumentation. Der Pfad führt von der Person über Single Sign-on in die Webanwendung, durch eine Berechtigungs- und Richtlinienschicht, zur Suche über einen freigegebenen Dokumentenbestand und Vektorindex und dann über ein Modell-Gateway zu einem verwalteten regionalen Modell. Dazu kommen Verschlüsselung, berechtigungsgeprüfte Suche, Audit-Logs der Anwendung, Datensparsamkeit in den Anfragen und ein Prüfdatensatz. Das Gateway ist der entscheidende Teil: damit lässt sich später ein privates Modell einführen, ohne die Anwendung neu zu bauen. Prüfen Sie verwaltete regionale Verarbeitung oder private Anbindung, bevor Sie GPUs kaufen, denn oft erfüllen sie die tatsächliche Vertraulichkeitsanforderung zu einem Bruchteil des Betriebsaufwands.

Ein mittleres Unternehmen mit mehreren KI-Anwendungen. Nutzende und Anwendungen erreichen ein zentrales KI-Gateway, das Richtlinien und Datenklassifikation anwendet und dann routet. Wenig sensible Arbeit und alles, was Spitzenqualität braucht, geht an verwaltete Modelle. Sensible, häufig anfallende und planbare Aufgaben geht an eine private Inferenzebene auf Kubernetes mit vLLM über einem GPU-Pool. Beide Wege nutzen dieselbe Identitäts- und Secrets-Verwaltung sowie gemeinsame Werkzeuge für Überwachung, Qualitätstests und Kostenkontrolle. Der kommerzielle Vorteil: keine vorschnelle Festlegung auf einen Anbieter oder ein Modell.

Eine regulierte Organisation. Verwaltete Endgeräte und Unternehmensidentität führen in eine kontrollierte Anwendungszone, dann durch ein Gateway für Richtlinien und Datenabflussschutz, dann zur berechtigten Suche und schliesslich zu einem privaten Inferenzcluster ohne standardmässigen ausgehenden Internetverkehr, mit freigabepflichtigem Import von Modellartefakten, privater Container-Registry, Schlüsseln in HSM oder KMS, unveränderlichem Audit-Trail, eingeschränkter Administrationsebene, kontrollierter Aktualisierungskette und getrennter Wiederanlaufumgebung. Folgenreiche Aktionen bleiben hinter deterministischer Prüfung oder menschlicher Freigabe statt autonom ausgeführt zu werden. Die Architektur verbessert die Kontrolle über Datenflüsse; sie ersetzt weder dokumentierte Governance noch Risikoabschätzungen, Lieferantenkontrollen, Modellprüfung, Sicherheitstests, Incident-Management oder die Rollenanalyse nach dem KI-Gesetz.

Sollten Sie selbst hosten?

Prüfen Sie mit diesen Fragen Ihren Anwendungsfall und Ihre betrieblichen Möglichkeiten.

Hosten Sie selbst, wenn Kontrolle, Verarbeitungsort, netzunabhängiger Betrieb, Latenz oder dauerhafte Auslastung einen Nutzen erzeugen, der die Qualitätslücke und den Betriebsaufwand übersteigt. Andernfalls kaufen Sie verwaltete Inferenz zu, oder betreiben Sie beides hinter einem Gateway.

Wo KI das falsche Mittel ist

Selbsthosting rettet keinen schlechten Anwendungsfall. Ein Sprachmodell ist meist das falsche Kernstück, wenn feste Regeln das Problem zuverlässiger lösen, wenn jede Antwort exakt sein muss und nichts sie unabhängig prüft, wenn zu wenig belastbare Daten für die Entscheidung vorliegen, oder wenn eine autonome Aktion unverhältnismässigen finanziellen, sicherheitsrelevanten oder rechtlichen Schaden anrichten kann und keine wirksame Kontrolle davorsteht. In diesen Fällen kann KI weiterhin bei Recherche, Entwürfen oder Vorsortierung helfen, während der folgenreiche Schritt deterministisch oder in menschlicher Hand bleibt. Diese Grenze behandelt unser Leitfaden zum Finden lohnender KI-Anwendungsfälle.

Wo Sie anfangen sollten

Beginnen Sie bei der Arbeitslast, nicht bei der Hardware. Halten Sie fest, was sie leistet, wie viel davon anfällt, wie planbar die Menge ist und welche Latenz gefordert wird. Klassifizieren Sie die Daten, die in Anfragen und Suche gelangen, und klären Sie die tatsächlich geltenden rechtlichen Anforderungen. Prüfen Sie, ob ein verfügbares offenes Modell Ihre Qualitätsanforderung an Ihren eigenen Beispielen erreicht, und vergleichen Sie dann einen verwalteten, einen privaten und einen hybriden Entwurf an denselben Anforderungen, mit Auslastung und Entwicklungsaufwand in der Rechnung.

Bauen Sie die kleinste Architektur, die die Anforderungen erfüllt, und setzen Sie ein Gateway davor, damit die Modellentscheidung umkehrbar bleibt.

Bei Alpine Edge führen wir in einer technischen Analyse Lastprofil, Datenklassifikation, die mit Ihrem Rechtsteam geklärten Anforderungen und Qualitätstests zu einer Empfehlung mit Kostenschätzung zusammen. Anschliessend setzen wir die gewählte Lösung mit unseren Leistungen für KI-Integration und private KI um und betreiben sie auf einer passenden Cloud- und DevOps-Infrastruktur.

Quellen und Preisannahmen

• OpenAI API-Preise. Listenpreise für kurzen Kontext und der Aufschlag für regionale Verarbeitung, abgerufen am 13. September 2026.
• Anthropic Claude-Preise. Listenpreise, Batch-Rabatt und Aufschläge für regionale Endpunkte, abgerufen am 13. September 2026.
• Google Cloud, Preise für beschleunigungsoptimierte VMs. Bedarfstarife und Preise bei dreijähriger Ressourcenbindung für a3-highgpu-8g, geprüft am 13. September 2026.
• Google Cloud, Compute-Engine-Preise. Gebühren für laufende Instanzen im Leerlauf und Gebühren für zugesicherte Ressourcen.
• Google Cloud, GPU-Maschinentypen. Speicher je H100 und H200 sowie die Ausbaustufen von A3 High.
• Gemma 3, Zahlen zur Quantisierung. BF16 gegenüber INT4 bei 27B, 12B und 4B.
• Gemma 3 im Überblick und Gemma 3 auf Mobilgeräten und im Web. Modellgrössen und die Variante für Endgeräte.
• vLLM-Dokumentation und Parallelität und Skalierung. Quantisierung, Tensor- und Pipeline-Parallelität.
• Kubernetes, GPU-Scheduling und NVIDIA GPU Operator. Device-Plugins und Lebenszyklus der GPU-Knoten.
• Microsoft Foundry, Deployment-Typen. Global, Data Zone und Geografie sowie Batch-Preise.
• Amazon Bedrock, VPC-Endpunkte und Datenschutz. PrivateLink und geteilte Verantwortung.
• Google Cloud, VPC Service Controls für KI. Sicherheitsperimeter um verwaltete KI.
• EDÖB zu KI und Datenschutz. Anwendbarkeit des DSG auf KI-gestützte Bearbeitungen.
• Datenschutzgesetz. Pflichten zu Technikgestaltung, Auftragsbearbeitung und Bekanntgabe ins Ausland.
• EDSA zu internationalen Datenübermittlungen. Bedingungen nach Kapitel V der DSGVO.
• Verordnung (EU) 2026/1744. Neue Anwendungsdaten des KI-Gesetzes für Hochrisikosysteme.
• NIST AI Risk Management Framework. Generative AI Profile.
• OWASP zu Prompt Injection. Risiken auf Anwendungsebene.