Wie können mehrere Teams oder Mandanten sich teure GPU-Infrastruktur sicher teilen?

Mehrere Teams oder Mandanten können sich teure GPU-Infrastruktur sicher teilen, wenn sie Identität, Berechtigungen, Ressourcenanspruch, Workload-Platzierung, Service-Zugriff, Metering und Audit voneinander trennen. Das Design der Quelle behandelt Multi-Tenancy als Problem von Personen und von Compute zugleich: Mandanten haben Mitglieder und Berechtigungen, aber auch Projekte, Kontingente, Aufgaben, Modelldienste, Token-Nutzung und Kostengrenzen.

Die teure Infrastruktur soll geteilt werden, ohne dass daraus ein unbeschränkter Ressourcenpool wird. Ein Nutzer sollte die Kapazität erhalten, die sein Projekt nutzen darf, nur die Objekte sehen, für die er autorisiert ist, und bei jeder Übermittlung, Änderung oder Nutzung eines Dienstes einen nachvollziehbaren Datensatz hinterlassen.

Was muss gemeinsam genutztes Multi-Tenant-GPU-Sharing isolieren?

Das Modell der Quelle beschreibt Mandantenisolation über mehrere operative Ebenen hinweg.

Personen:

Mandantenmitglieder
Projektmitglieder
Rollen
Berechtigungen

Compute:

Ressourcenkontingente
Aufgabeneigentümerschaft
Ressourcenpools
Scheduling

Modelldienste:

Modelle
Wissensdatenbanken
Anwendungen
Zugriffsschlüssel

Verbrauch:

Beschleunigerkarten-Stunden
Token-Nutzung
Kosten

Compute-Isolation allein reicht nämlich nicht. Zwei Teams können getrennte GPU-Kontingente haben und trotzdem ein Data-Governance-Problem, wenn eines das Modell, den Arbeitsauftrag oder die Wissensdatenbank des anderen einsehen kann. Die Mandantengrenze muss sich daher durch die gesamte Betriebskette ziehen.

Warum sollten Mandanten und Projekte beide existieren?

Ein Mandant ist eine breitere Grenze für Eigentum und Isolation, ein Projekt eine spezifischere Arbeits- und Abrechnungseinheit innerhalb dieses Mandanten.

Das Q&A der Quelle beschreibt Multi-Tenancy als Thema, das Personen und Compute betrifft, einschließlich:

Mitglieder
Berechtigungen
Projekte
Kontingente
Aufgaben
Modelldienste
Token-Nutzung
Kostenisolation

So kann eine Organisation mehrere Projekte unter einem Mandanten gruppieren und Verbrauch und Verantwortung trotzdem auf Projektebene verfolgen. Ein Mandant „Forschungsabteilung" könnte zum Beispiel Projekt A für das Fine-Tuning eines Foundation-Modells und Projekt B für Vision-Inferenz enthalten. Der Mandant zieht dann die organisatorische Grenze, das Projekt die Grenze für Workload und Kosten.

Wie sollten Rollenberechtigungen funktionieren?

Nach dem Prinzip der geringsten Rechte (Least Privilege). Das Governance-Modell der Quelle umfasst organisatorische Hierarchie, Rollenberechtigungsmatrizen, Mandantenmitgliedschaft, Projektmitgliedschaft und eine separate Autorisierung für sensible Operationen. Ein Nutzer erhält also nur die Berechtigungen, die seine Rolle erfordert.

Ein Mandantenadministrator verwaltet etwa Mitglieder und einige Projekteinstellungen innerhalb des Mandanten, während ein Projektnutzer Workloads innerhalb des Projektkontingents übermittelt. Ein Betriebsingenieur kümmert sich um den Infrastrukturzustand, ein Sicherheitsadministrator um sensible Richtlinien. Ein Anbieterkonto darf nur für einen begrenzten Zeitraum auf genehmigte Geräte oder Arbeitsaufträge zugreifen.

Das Q&A der Quelle sagt ausdrücklich, dass ein Mandantenadministrator Mitglieder, Projekte und einige Berechtigungen innerhalb der vom Plattformadministrator autorisierten Grenze verwalten kann, aber nicht in andere Mandanten oder globale Ressourcen vordringen darf. So sieht korrektes Multi-Tenancy aus.

Wie sollten GPU-Kontingente Fairness durchsetzen?

Kontingente sollten geprüft werden, bevor ein Workload in den normalen Wettbewerb um Scheduling eintritt. Der Scheduler der Quelle behandelt Mandantenkontingente als harte Beschränkung. So kann kein Mandant den gesamten Pool verbrauchen, nur weil er viel Arbeit übermittelt und seine Aufgaben länger gewartet haben.

Laut dem Q&A der Quelle können Kontingente auf mehreren Dimensionen basieren:

GPU-Anzahl
Beschleunigerspeicher
CPU und Speicher
Gleichzeitige Jobs
Monatliche Kartenstunden

Die Organisation wählt die Dimensionen, die zu ihrem Betriebsmodell passen. Ein hartes Kapazitätskontingent schützt die Infrastruktur, ein Nutzungskontingent hilft zusätzlich bei der Budgetkontrolle.

Wie sollten Prioritäten mandantenübergreifend funktionieren?

Priorität sollte einer Richtlinie folgen und nicht davon abhängen, wer zuerst übermittelt. Der Scheduler der Quelle unterstützt Warteschlangenpriorität und Preemption, sodass ein Unternehmen unterscheiden kann zwischen:

Produktion und Entwicklung
Kritischem Kundendienst und Hintergrund-Batch
Dringender Incident-Arbeit und flexibler Forschung

Priorität braucht allerdings Governance. Wenn jeder Mandant jeden Job als "höchste Priorität" markieren kann, ist die Kontrolle wertlos.

Eine detaillierte Richtlinie zur Verwaltung von Prioritäten schreibt die Quelle nicht vor. Ein praktisches Design, das sich an ihr orientiert, bindet hohe Prioritätsstufen an Rollen, Projektklassen oder genehmigte Workload-Typen und hält die Entscheidung in der Audit-Historie fest.

Sollten Teams ganze GPUs oder GPU-Slices teilen?

Das Scheduling-Design der Quelle unterstützt sowohl ganze Karten als auch aufgeteilte Ressourcen. Was man verwendet, hängt vom Workload und von der unterstützten Hardware ab.

Ganze Karten sind angemessen, wenn die Aufgabe exklusive Beschleunigerressourcen, vorhersehbare Leistung oder ein vollständiges Gerät benötigt. Aufgeteilte Ressourcen können leichtere Workloads effizienter machen, sofern die Hardware das unterstützt und das nötige Isolationsverhalten akzeptabel ist.

Die Quelle nennt außerdem die Isolation mehrerer Container auf einer Karte und Interferenzen bei gemeinsam genutzten Karten als technische Herausforderungen. Geteilte GPU-Nutzung ist also nicht automatisch gleichwertig mit dedizierter Zuweisung. Überwachen Sie das Verhalten geteilter Workloads, halten Sie die Ressourcenform sichtbar und nutzen Sie standardisierte Ressourcenspezifikationen, damit Nutzer verstehen, was sie anfordern.

Wie sollten heterogene GPUs geteilt werden?

Normalisieren Sie sie in standardisierte Ressourcenspezifikationen und behalten Sie darunter das tatsächliche Modell und den Zustand bei.

Die Plattform der Quelle unterstützt heterogenes Pooling über mehrere Beschleuniger-Anbieter und -Modelle hinweg. Nutzer fordern eine Standard-Ressourcenklasse an, statt einzelne physische Karten von Hand auszuwählen. Das erleichtert das Teilen, weil die Plattform verwalten kann:

Kartentyp
Kartenanzahl
CPU
Speicher
Ganze oder aufgeteilte Form

Laut Quelle ist Multi-Vendor-Scheduling technisch schwierig, weil sich Treiber, Runtimes und Geräte-Plugins unterscheiden. Die standardisierte Ressourcenschicht darf also nicht so tun, als sei jede Karte identisch. Sie sollte die Anfrage vereinfachen und die Kompatibilitätsregeln trotzdem einhalten.

Wie sollte Kartenzustand Mandanten schützen?

Der Zustand sollte vor der Zuweisung geprüft werden. Das Scheduling-Design der Quelle isoliert degradierte Beschleunigerkarten ausdrücklich, bevor Aufgaben zugewiesen werden, und in einer geteilten Umgebung ist das besonders wichtig.

Eine Karte, die technisch sichtbar und gerade frei ist, sollte ein Mandant deshalb nicht automatisch bekommen. Ist sie degradiert, nimmt die Plattform sie aus dem normalen Scheduling oder wendet die genehmigte Zustandsrichtlinie an. Kein Mandant wird so zum unglücklichen Empfänger bekannt schlechter Kapazität. Auch die Fairness profitiert, weil nutzbare Kapazität an gesunden Ressourcen gemessen wird und nicht am installierten Inventar.

Wie sollten Workload-Bindungen verfolgt werden?

Das Container-und-GPU-Modell der Quelle speichert Zuordnungen zwischen Beschleunigerkarten und Containern in beide Richtungen und führt für Audit-Zwecke eine Zeitlinie der Bindungen. Die Plattform kann damit beantworten, welcher Workload eine bestimmte GPU nutzt, welche GPU ein Container nutzt, welchem Mandanten der Workload gehört und wann die Bindung begann und endete.

Für geteilte Infrastruktur sind diese Beziehungen unverzichtbar. Sie unterstützen:

Incident-Impact
Kostenzuordnung
Sicherheitsüberprüfung
Ressourcenrückgewinnung
Historischen Audit

Tritt ein Hardwarefehler auf, kann der Betrieb genau den betroffenen Mandanten und die betroffene Aufgabe identifizieren, ohne Daten unbeteiligter Mandanten offenzulegen.

Wie sollte der Zugriff auf Modelldienste isoliert werden?

Die Modelldienst-Ebene der Quelle trennt Modelle, Wissensdatenbanken, Anwendungen, Schlüssel, Kontingente und Nutzung nach Mandant und Projekt. API-Keys sind an Projekt-Tags gebunden, damit der Token-Verbrauch korrekt zugeordnet werden kann.

Damit hat die Service-Ebene ihre eigene Zugriffsgrenze. Ein Mandant sollte weder den privaten Modelldienst eines anderen aufrufen noch dessen Wissensdatenbank abfragen können, nur weil beide auf demselben GPU-Cluster laufen. Der Compute-Pool darf geteilt werden, die Eigentümerschaft an Services und Daten bleibt isoliert.

Wie sollten Wissensdatenbanken isoliert werden?

Das RAG-Design der Quelle sagt ausdrücklich, dass Berechtigungen für Wissensdatenbanken pro Mandant isoliert sind, und das ist eine kritische Sicherheitskontrolle.

Zwei Mandanten können dasselbe genehmigte Modell nutzen und dabei auf unterschiedliches Unternehmenswissen zugreifen. Das Modell ist geteilte Infrastruktur, die Wissensdatenbank bleibt mandantenspezifisch. Diese Trennung ist einer der Vorteile, wenn man die Lebenszyklen von Modell und Wissen entkoppelt.

Dasselbe Prinzip sollte für operative Dokumente und Arbeitsaufträge gelten: Nutzer rufen nur das Wissen ab, das ihre Rolle und ihr Mandant erlauben.

Wie sollte Nutzung gemessen werden?

Das Metering-Modell der Quelle ordnet Verbrauch zu nach:

Mandant
Projekt
Modell
Beschleunigertyp

Zusätzlich verfolgt es Beschleunigerkarten-Stunden und Token-Nutzung. Damit hat die Organisation eine klare Antwort auf die Frage, wer was genutzt hat.

Ohne Metering werden geteilte GPUs schnell zum Politikum, weil jedes Team glaubt, ein anderes verbrauche die teure Kapazität. Mit Metering wird aus der Diskussion eine Frage der Daten.

Für das detaillierte Zuordnungsmodell erklärt wie Unternehmen die Kosten von KI-Infrastruktur nach GPU-Stunde, Token, Projekt, Mandant oder Modell messen können, wie Eigentümerschaft und Nutzungsdimensionen zusammenhängen.

Wie sollte Kostentransparenz funktionieren?

Jeder Mandant und jedes Projekt sollte den eigenen Verbrauch innerhalb des autorisierten Bereichs einsehen können. Das Betriebsmodell der Quelle unterstützt Kostenberichte für Projekte und Mandanten.

Das heißt nicht, dass jede Organisation Teams intern etwas verrechnen muss. Manche Unternehmen nutzen die Zahlen nur zum Showback, andere zum Chargeback.

Entscheidend für die Sicherheit ist, dass die detaillierten Kosten- und Workload-Daten eines Mandanten nicht ohne Autorisierung für andere Mandanten sichtbar werden. Aggregiertes Management-Reporting kann es auf Plattformebene für Administratoren trotzdem geben.

Wie sollte Audit mandantenübergreifend funktionieren?

Das Governance-Modell der Quelle verlangt Nachvollziehbarkeit nach Person, Zeit, Zielobjekt und Aktion. Bei geteilten GPU-Operationen gehören zu den relevanten auditierten Aktionen:

Ressourcenanfrage
Kontingentänderung
Prioritätsänderung
Workload-Übermittlung
Preemption
Manuelle Ressourcenfreigabe
Veröffentlichung eines Modelldienstes
API-Key-Verwaltung
Berechtigungsänderung
Sensible Operation

Der Audit-Datensatz sollte die Identität des handelnden Nutzers oder Service festhalten. Bei Mandantenadministratoren ist das besonders wichtig: Sie können innerhalb des Mandanten viel steuern, dürfen aber keine globalen Ressourcenrichtlinien ändern, und die Audit-Historie zeigt, ob diese Grenze eingehalten wurde.

Zur Scheduling-Richtlinie für geteilte Kapazität erklärt was GPU-Kontingente, Reservierungen, Prioritäten und Preemption bedeuten und wann jedes davon verwendet werden sollte, warum Anspruch und Dringlichkeit getrennte Kontrollen bleiben sollten.

Wie sollte Anbieter- und Support-Zugriff gehandhabt werden?

Das Q&A der Quelle empfiehlt eingeschränkte Anbieterkonten, deren Umfang auf bestimmte Arbeitsaufträge begrenzt ist und deren Berechtigungen zeitlich ablaufen. Für geteilte Infrastruktur ist das ein nützliches Muster.

Ein Hardware-Anbieter braucht vielleicht Zugriff auf einen ausgefallenen GPU-Node. Automatisch Zugriff auf Folgendes sollte er deshalb aber nicht erhalten:

Workloads anderer Mandanten
Modelldienste
Wissensdatenbanken
Projektnutzung
Globale Administration

Temporärer, eingegrenzter Zugriff senkt die unnötige Exposition, und jede Anmeldung und Operation bleibt auditierbar.

Wie sollte verhindert werden, dass der Ausfall eines Mandanten andere beeinträchtigt?

Dafür sorgen Ressourcengrenzen, Zustandsisolation, Topologiebewusstsein und kontrolliertes Scheduling.

Eine degradierte Karte wird vor jeder neuen Zuweisung isoliert. Erzeugt ein Job abnormale Konkurrenz auf einer geteilten Karte, sollte die Plattform die Interferenz erkennen und die unterstützte Ressourcenrichtlinie anwenden. Fällt ein Node aus, werden die betroffenen Workloads identifiziert und nur dort neu eingeplant, wo die genehmigte Recovery-Richtlinie es erlaubt.

Weil das Design der Quelle außerdem die Beziehungen von der GPU über den Container bis zur Anwendung verfolgt, lässt sich ein Incident auf den betroffenen Mandanten oder Dienst eingrenzen.

Was sollte eine mandantenseitige Ansicht zeigen?

Eine Mandanten- oder Projektansicht kann zeigen:

Autorisiertes Ressourcenkontingent
Aktuelle Zuweisung
Verfügbares Kontingent
Laufende Aufgaben
Wartende Aufgaben
Warteschlangengründe
Modelldienste
Token-Verbrauch
Kartenstunden
Kosten
Aktuelle Alarme, die eigene Ressourcen betreffen

Infrastruktur- oder Mandantendaten außerhalb der autorisierten Grenze gehören nicht hinein.

Ein Plattformbeispiel, das Mandantenkontingente, Projektisolation, Ressourcen-Scheduling, Token-Zuordnung und Least-Privilege-Zugriff kombiniert, ist Sensaka.

Würde ich sicheres GPU-Sharing entwerfen, stünde ein Prinzip im Mittelpunkt: Den physischen Beschleuniger-Pool dürfen sich alle teilen, aber Eigentümerschaft, Berechtigungen, Workload-Identität, Service-Zugriff, Nutzungsdaten und Audit müssen auf jeder Ebene explizit bleiben. Erst dadurch wird aus einem geteilten Cluster eine Multi-Tenant-Plattform und kein gemeinsamer Maschinenraum.