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, indem sie Identität, Berechtigungen, Ressourcenanspruch, Workload-Platzierung, Service-Zugriff, Metering und Audit voneinander trennen. Das Design der Quelle behandelt Multi-Tenancy sowohl als Personen- als auch als Compute-Problem: Mandanten haben Mitglieder und Berechtigungen, aber auch Projekte, Kontingente, Aufgaben, Modelldienste, Token-Nutzung und Kostengrenzen.

Das Ziel ist es, die teure Infrastruktur zu teilen, ohne die Umgebung in einen unbeschränkten Ressourcenpool zu verwandeln. 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 identifiziert 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

Das ist wichtig, weil Compute-Isolation allein nicht ausreicht.

Zwei Teams können getrennte GPU-Kontingente haben und trotzdem ein Data-Governance-Problem haben, 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 Eigentums- und Isolationsgrenze.

Ein Projekt ist eine spezifischere Arbeits- und Abrechnungseinheit innerhalb dieses Mandanten.

Das Q&A der Quelle beschreibt Multi-Tenancy als sowohl Personen als auch Compute betreffend, einschließlich:

Mitglieder
Berechtigungen
Projekte
Kontingente
Aufgaben
Modelldienste
Token-Nutzung
Kostenisolation

Das erlaubt einer Organisation, mehrere Projekte unter einem Mandanten zu gruppieren und dabei Verbrauch und Verantwortung trotzdem auf Projektebene zu verfolgen.

Zum Beispiel:

Mandant: Forschungsabteilung

Projekt A: Fine-Tuning eines Foundation-Modells

Projekt B: Vision-Inferenz

Der Mandant liefert die organisatorische Grenze.

Das Projekt liefert die Workload- und Kostengrenze.

Wie sollten Rollenberechtigungen funktionieren?

Least Privilege anwenden.

Das Governance-Modell der Quelle umfasst organisatorische Hierarchie, Rollenberechtigungsmatrizen, Mandantenmitgliedschaft, Projektmitgliedschaft und separate Autorisierung für sensible Operationen.

Das bedeutet, ein Nutzer sollte nur die für seine Rolle erforderlichen Berechtigungen erhalten.

Beispiele:

Ein Mandantenadministrator kann Mitglieder und einige Projekteinstellungen innerhalb des Mandanten verwalten.

Ein Projektnutzer kann Workloads innerhalb des Projektkontingents übermitteln.

Ein Betriebsingenieur kann den Infrastrukturzustand verwalten.

Ein Sicherheitsadministrator kann sensible Richtlinien verwalten.

Ein Anbieterkonto kann nur auf genehmigte Geräte oder Arbeitsaufträge für einen begrenzten Zeitraum 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 kann.

Das ist das korrekte Multi-Tenant-Prinzip.

Wie sollten GPU-Kontingente Fairness durchsetzen?

Kontingente sollten geprüft werden, bevor der Workload in den normalen Scheduling-Wettbewerb eintritt.

Der Scheduler der Quelle behandelt Mandantenkontingente als harte Beschränkung.

Das verhindert, dass ein Mandant genug Arbeit übermittelt, um den gesamten Pool zu verbrauchen, nur weil seine Aufgaben länger gewartet haben.

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

GPU-Anzahl
Beschleunigerspeicher
CPU und Speicher
Gleichzeitige Jobs
Monatliche Kartenstunden

Die Organisation kann die Dimensionen wählen, die zu ihrem Betriebsmodell passen.

Ein hartes Kapazitätskontingent schützt die Infrastruktur.

Ein Nutzungskontingent kann außerdem die Budgetkontrolle unterstützen.

Wie sollten Prioritäten mandantenübergreifend funktionieren?

Priorität sollte richtliniengesteuert sein, statt davon abzuhängen, welcher Nutzer zuerst übermittelt.

Der Scheduler der Quelle unterstützt Warteschlangenpriorität und Preemption.

Ein Unternehmen kann daher unterscheiden zwischen:

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

Priorität braucht jedoch Governance.

Wenn jeder Mandant jeden Job als "höchste Priorität" markieren kann, hat die Kontrolle keinen Wert.

Die Quelle schreibt keine detaillierte Prioritäts-Verwaltungsrichtlinie vor.

Ein praktisches, an der Quelle orientiertes Design bindet hohe Prioritätsstufen an Rollen, Projektklassen oder genehmigte Workload-Typen und bewahrt die Entscheidung in der Audit-Historie.

Sollten Teams ganze GPUs oder GPU-Slices teilen?

Das Scheduling-Design der Quelle unterstützt sowohl ganze Karten als auch aufgeteilte Ressourcen.

Was verwendet wird, hängt vom Workload und der unterstützten Hardware ab.

Die Zuweisung ganzer Karten ist angemessen, wenn die Aufgabe exklusive Beschleunigerressourcen, vorhersehbare Leistung oder ein vollständiges Gerät benötigt.

Aufgeteilte Ressourcen können die Effizienz für leichtere Workloads verbessern, sofern unterstützt und sofern das erforderliche Isolationsverhalten akzeptabel ist.

Die Quelle identifiziert außerdem Isolation mehrerer Container auf einer Karte und Interferenzen bei gemeinsam genutzten Karten als technische Herausforderungen.

Das bedeutet, gemeinsam genutzte GPU-Nutzung sollte nicht automatisch als gleichwertig mit dedizierter Zuweisung behandelt werden.

Das Verhalten des gemeinsam genutzten Workloads überwachen.

Die Ressourcenform sichtbar halten.

Standardisierte Ressourcenspezifikationen nutzen, damit Nutzer verstehen, was sie anfordern.

Wie sollten heterogene GPUs geteilt werden?

Sie in standardisierte Ressourcenspezifikationen normalisieren, während das tatsächliche Modell und der Zustand darunter erhalten bleiben.

Die Plattform der Quelle unterstützt heterogenes Pooling über mehrere Beschleuniger-Anbieter und -Modelle hinweg.

Nutzer können eine Standard-Ressourcenklasse anfordern, statt manuell einzelne physische Karten auszuwählen.

Das erleichtert das Teilen, weil die Plattform verwalten kann:

Kartentyp
Kartenanzahl
CPU
Speicher
Ganze oder aufgeteilte Form

Die Quelle stellt außerdem fest, dass Multi-Vendor-Scheduling technisch schwierig ist, weil sich Treiber, Runtimes und Geräte-Plugins unterscheiden.

Die standardisierte Ressourcenschicht sollte also nicht so tun, als sei jede Karte identisch.

Sie sollte die Anfrage vereinfachen und dabei Kompatibilitätsregeln beibehalten.

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.

Das ist in einer gemeinsam genutzten Umgebung besonders wichtig.

Ein Mandant sollte eine Karte nicht nur deshalb erhalten, weil sie technisch sichtbar und aktuell frei ist.

Ist die Karte degradiert, sollte die Plattform sie aus dem normalen Scheduling entfernen oder die genehmigte Zustandsrichtlinie anwenden.

Das verhindert, dass ein Mandant zum unglücklichen Empfänger bekannt schlechter Kapazität wird.

Es verbessert außerdem die Fairness, weil nutzbare Kapazität aus gesunden Ressourcen gemessen wird, nicht aus installiertem Inventar.

Wie sollten Workload-Bindungen verfolgt werden?

Das Container-und-GPU-Modell der Quelle bewahrt bidirektionale Zuordnungen zwischen Beschleunigerkarten und Containern und erhält eine Bindungs-Zeitlinie für Audit-Zwecke.

Das bedeutet, die Plattform kann beantworten:

Welcher Workload nutzt diese GPU?

Welche GPU nutzt dieser Container?

Welcher Mandant besitzt den Workload?

Wann begann die Bindung?

Wann endete sie?

Diese Beziehungen sind für gemeinsam genutzte Infrastruktur essenziell.

Sie unterstützen:

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

Tritt ein Hardwarefehler auf, kann der Betrieb den genauen betroffenen Mandanten und die betroffene Aufgabe identifizieren, ohne unbeteiligte Mandantendaten 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, sodass der Token-Verbrauch korrekt zugeordnet werden kann.

Das gibt der Service-Ebene ihre eigene Zugriffsgrenze.

Ein Mandant sollte nicht den privaten Modelldienst eines anderen Mandanten aufrufen oder dessen Wissensdatenbank abrufen können, nur weil beide dasselbe zugrunde liegende GPU-Cluster nutzen.

Der Compute-Pool kann geteilt werden.

Die Service- und Dateneigentümerschaft bleiben isoliert.

Wie sollten Wissensdatenbanken isoliert werden?

Das RAG-Design der Quelle sagt ausdrücklich, dass Berechtigungen für Wissensdatenbanken mandantenspezifisch isoliert sind.

Das ist eine kritische Sicherheitskontrolle.

Zwei Mandanten können dasselbe genehmigte Modell nutzen und dabei aus unterschiedlichem Unternehmenswissen abrufen.

Das Modell ist gemeinsam genutzte Infrastruktur.

Die Wissensdatenbank bleibt mandantenspezifisch.

Diese Trennung ist einer der Vorteile der Entkopplung von Modell- und Wissenslebenszyklus.

Dasselbe Prinzip sollte für operative Dokumente und Arbeitsaufträge gelten.

Nutzer sollten nur das Wissen abrufen, 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

Es verfolgt außerdem Beschleunigerkarten-Stunden und Token-Nutzung.

Das gibt der Organisation eine klare Antwort auf die Frage der gemeinsam genutzten Infrastruktur:

Wer hat was genutzt?

Ohne Metering können gemeinsam genutzte GPUs politisch schwer zu verwalten werden, weil jedes Team glaubt, ein anderes Team verbrauche die teure Kapazität.

Metering macht die Diskussion zu 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 oder jedes Projekt sollte seinen eigenen Verbrauch innerhalb des autorisierten Bereichs einsehen können.

Das Betriebsmodell der Quelle unterstützt Projekt- und Mandanten-Kostenberichte.

Das bedeutet nicht automatisch, dass jede Organisation Teams intern verrechnen muss.

Manche Unternehmen nutzen die Zahlen nur zum Showback.

Andere nutzen sie zum Chargeback.

Die zentrale Sicherheitsanforderung ist, dass die detaillierten Kosten- und Workload-Daten eines Mandanten einem anderen Mandanten nicht ohne Autorisierung offengelegt werden sollten.

Aggregiertes Management-Reporting kann auf Plattformebene für Administratoren existieren.

Wie sollte Audit mandantenübergreifend funktionieren?

Das Governance-Modell der Quelle verlangt Nachvollziehbarkeit nach Person, Zeit, Zielobjekt und Aktion.

Für gemeinsam genutzte 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 handelnde Nutzer- oder Service-Identität bewahren.

Das ist besonders wichtig für Mandantenadministratoren.

Ein Mandantenadmin kann innerhalb des Mandanten erhebliche Kontrolle haben, während er trotzdem nicht in der Lage ist, globale Ressourcenrichtlinien zu ändern.

Die Audit-Historie zeigt, ob diese Grenze respektiert wurde.

Für die Scheduling-Richtlinienseite gemeinsam genutzter Kapazität erklärt was GPU-Kontingente, Reservierungen, Prioritäten und Preemption bedeuten und wann jedes davon verwendet werden sollte, wie Anspruch und Dringlichkeit getrennte Kontrollen bleiben sollten.

Wie sollte Anbieter- und Support-Zugriff gehandhabt werden?

Das Q&A der Quelle empfiehlt eingeschränkte Anbieterkonten mit begrenztem Arbeitsauftrags-Umfang und zeitbasierten Berechtigungen.

Das ist auch für gemeinsam genutzte Infrastruktur ein nützliches Muster.

Ein Hardware-Anbieter benötigt möglicherweise Zugriff auf einen ausgefallenen GPU-Node.

Er sollte nicht automatisch Zugriff erhalten auf:

Workloads anderer Mandanten
Modelldienste
Wissensdatenbanken
Projektnutzung
Globale Administration

Temporärer, eingegrenzter Zugriff reduziert unnötige Exposition.

Jede Anmeldung und jede Operation sollte auditierbar bleiben.

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

Ressourcengrenzen, Zustandsisolation, Topologiebewusstsein und kontrolliertes Scheduling nutzen.

Wird eine Karte degradiert, sie vor neuer Zuweisung isolieren.

Erzeugt ein Job abnormale Konkurrenz auf einer gemeinsam genutzten Karte, sollte die Plattform die Interferenz erkennen und die unterstützte Ressourcenrichtlinie anwenden.

Fällt ein Node aus, die betroffenen Workloads identifizieren und nur dort neu einplanen, wo die genehmigte Recovery-Richtlinie es erlaubt.

Das Design der Quelle verfolgt außerdem Beziehungen von GPU über Container bis zur Anwendung, was hilft, den Incident auf den betroffenen Mandanten oder Dienst einzugrenzen.

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

Sie sollte keine Infrastruktur- oder Mandantendaten außerhalb der autorisierten Grenze anzeigen.

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

Würde ich sicheres GPU-Sharing entwerfen, würde ich ein Prinzip in den Mittelpunkt stellen: Der physische Beschleuniger-Pool kann geteilt werden, aber Eigentümerschaft, Berechtigungen, Workload-Identität, Service-Zugriff, Nutzungsdaten und Audit müssen auf jeder Ebene explizit bleiben. Das ist es, was aus einem gemeinsam genutzten Cluster eine Multi-Tenant-Plattform macht statt eines gemeinsamen Maschinenraums.