Wie können Unternehmen standardisierte Service-Kataloge für Infrastruktur- und KI-Dienste erstellen?

Unternehmen können standardisierte Service-Kataloge erstellen, indem sie wiederholbare Infrastruktur- und KI-Fähigkeiten in genehmigte Servicedefinitionen mit bekannten Parametern, Eigentümerschaft, Kontingent, Freigabe, Liefer-Workflow, Metering und Lifecycle überführen. Das Ausgangsmaterial definiert keine einzelne formale Seite namens Service-Katalog, liefert aber die Bausteine, die zur Erstellung eines solchen nötig sind.

Der stärkste, quellengestützte Ansatz besteht darin, das zu katalogisieren, was Nutzer bereits anfordern dürfen: Standard-Compute-Spezifikationen, Bare-Metal-Bereitstellung, Storage- und Konnektivitätsdienste, Model-Deployment-Templates, Inferenzdienste, API-Zugriff, Kontingentänderungen und andere wiederholbare Workflows.

Was ist ein Service-Katalog in diesem Kontext?

Ein Service-Katalog ist eine kontrollierte Liste von Diensten, die Nutzer anfordern oder konsumieren können.

Für Infrastruktur kann ein Katalogeintrag Folgendes darstellen:

Compute-Ressource
Bare-Metal-Server
Storage-Zuweisung
Dedizierter Netzwerkdienst
Kontingentänderung

Für KI-Dienste kann er Folgendes darstellen:

Genehmigtes Model-Deployment
Inferenz-Instanz
Model-API
Knowledge-Base-Dienst
Agenten-Dienst

Der Katalogeintrag verbirgt unnötige Implementierungsdetails.

Der Nutzer wählt den Dienst und die genehmigten Parameter.

Die Plattform wendet Governance- und Lieferlogik an.

Die Quelle unterstützt dieses Muster durch standardisierte Ressourcenspezifikationen, Templates, Workflows, Service-Veröffentlichung und Metering.

Warum Infrastrukturanfragen standardisieren?

Standardisierung reduziert manuelle Einzelfallarbeit.

Ohne Service-Katalog fordern Nutzer Infrastruktur oft als Freitext an.

„Bitte gib mir einen leistungsstarken GPU-Server.“

Das erzeugt mehrere Rückfragen.

Welcher Beschleuniger?

Wie viele?

Wie viel Speicher?

Für wie lange?

Welches Projekt?

Welches Kontingent?

Welches Betriebssystem?

Welches Netzwerk?

Ein standardisierter Katalogeintrag verwandelt dieses Gespräch in definierte Felder.

Das zugrunde liegende Scheduling-Modell nutzt bereits Standard-Ressourcenspezifikationen für heterogene GPU- und NPU-Kapazität.

Das ist die richtige Grundlage.

Was sollte ein Compute-Katalogeintrag enthalten?

Ein Compute-Eintrag kann die Ressourcenfähigkeit definieren statt eine einzelne physische Maschine.

Von der Quelle unterstützte Parameter umfassen:

Beschleunigertyp
Beschleunigeranzahl
CPU
Speicher
Ganze Karte oder gesliceste Form
Mandant
Projekt
Kontingent
Priorität

Die Quelle definiert kein universelles Katalogschema.

Ein praxistauglicher Katalogeintrag sollte außerdem festlegen:

Service-Eigentümer
Freigaberichtlinie
Nutzungs-Metering-Regel
Rückgabe- oder Ablaufverhalten

Der Nutzer sollte verstehen, was er erhält und wie es gesteuert wird.

Das Infrastrukturteam sollte verstehen, wie die Anfrage auf den Ressourcenpool abgebildet wird.

Wie sollten heterogene Beschleuniger im Katalog erscheinen?

Genehmigte Ressourcenspezifikationen präsentieren, während die tatsächliche Hersteller- und Modellkompatibilität darunter erhalten bleibt.

Die zugrunde liegende Plattform unterstützt heterogenes Beschleuniger-Pooling.

Das bedeutet, der Katalog kann vermeiden, jeden Nutzer zu zwingen, jeden Hardwarehersteller zu verstehen.

Gleichzeitig sollte er keine Fähigkeitsunterschiede verbergen, die für den Workload relevant sind.

Ein Standarddienst kann festlegen:

Ressourcenklasse
Speicherstufe
Ganze oder gesliceste Ressource
Unterstützter Workload-Typ

Der Scheduler kann die Anfrage dann auf kompatible, funktionsfähige Hardware abbilden.

Für das zugrunde liegende Ressourcenmanagement erläutert wie Unternehmen GPUs und NPUs mehrerer Hersteller in einer Plattform verwalten können, warum Standardisierung und Hardware-Detail koexistieren müssen.

Was sollte ein Bare-Metal-Katalogeintrag enthalten?

Der zugrunde liegende Bare-Metal-Lieferworkflow bietet einen klaren standardisierten Dienst.

Ein Katalogeintrag kann festlegen:

Genehmigte Hardwareklasse
Betriebssystem
Treibersatz
Monitoring-Agent
Cluster-Rolle
Netzwerkprofil

Die Anfrage tritt in den Workflow ein.

Die Plattform validiert den physischen Server.

Die Bereitstellung läuft.

Der Zustand nach der Installation wird geprüft.

Das Ergebnis wird zurückgeschrieben.

Das verwandelt „bau mir einen Server“ in einen wiederholbaren Lieferdienst.

Für die Lieferdetails erklärt, wie automatisierte Bare-Metal-Bereitstellung für physische Server, Betriebssysteme, GPU-Treiber und Monitoring-Agenten funktioniert, den vollständigen Ablauf.

Wie sollte Storage im Katalog erscheinen?

Storage-Dienste lassen sich anhand der Parameter standardisieren, die die Plattform steuern kann.

Das Ausgangsmaterial umfasst Storage-Management, Kapazität, Performance, Kontingente und Nutzung.

Ein Storage-Katalogeintrag könnte daher festlegen:

Storage-Dienst
Kapazität
Mandant oder Projekt
Kontingent
Performance-Anforderung, sofern unterstützt
Lifecycle

Die Quelle spezifiziert keine einzelne formale Storage-Katalog-Schnittstelle.

Das quellengestützte Prinzip ist, wiederholbare Zuweisungsregeln in standardisierte Servicedefinitionen zu überführen.

Dasselbe gilt für andere Infrastrukturressourcen.

Wie sollten Netzwerkdienste erscheinen?

Die zugrunde liegende Plattform verwaltet dedizierte Leitungen und Netzwerktopologie.

Ein Netzwerkkatalog kann Anfragen standardisieren wie:

Private Standortverbindung
Bandbreitenänderung
Netzwerkzugriff
Genehmigtes Konnektivitätsprofil

Der genaue Dienst hängt vom Netzwerkbetriebsmodell des Unternehmens ab.

Der Katalog sollte die Anfrage verknüpfen mit:

Eigentümer
Leitungs- oder Netzwerkobjekt
Freigabe
Kosten
Liefer-Workflow
Monitoring

Das hält den kaufmännischen und operativen Datensatz in Einklang.

Wie sollte Model-Deployment im Katalog erscheinen?

Die zugrunde liegende MaaS-Schicht nutzt bereits Deployment-Templates.

Das macht Model-Deployment zu einem starken Katalogkandidaten.

Ein Katalogeintrag kann umfassen:

Genehmigtes Modell
Genehmigte Modellversion
Deployment-Template
Ressourcenspezifikation
Projekt
Replika- oder Skalierungsrichtlinie
Service-Tier

Der Nutzer wählt die genehmigte Kombination.

Die Plattform erstellt Inferenz-Instanzen.

Das Service-Gateway veröffentlicht den Endpunkt.

Das ist ein Katalog-artiger Dienst, auch wenn die Quelle ihn nicht Service-Katalog nennt.

Wie sollten Model-APIs erscheinen?

Das API-Gateway bietet eine stabile Servicegrenze.

Ein Katalogeintrag für eine Model-API kann festlegen:

Model-Service
Mandantenberechtigung
Projekt
API-Key-Richtlinie
Kontingent
Rate-Limit
Fallback-Richtlinie
Metering-Definition

Die zugrunde liegende Model-Service-Schicht umfasst Key-Management, Rate-Limits, Kontingente, Routing, Fallback und Token-Metering.

Das sind die Betriebskontrollen, die einen API-Service-Katalog nützlich machen.

Der Katalogeintrag sollte den gesteuerten Dienst beschreiben, nicht die interne Inferenz-Topologie offenlegen.

Wie sollten KI-Agenten-Dienste erscheinen?

Die zugrunde liegende Agenten-Orchestrierungsschicht erlaubt es, eine Orchestrierung als Dienst zu veröffentlichen.

Das bedeutet, ein genehmigter Agent kann ebenfalls zum Katalogeintrag werden.

Ein Nutzer kann Folgendes entdecken:

Zweck des Agenten
Version
Geschäftsbereich
Zugriffsumfang
Servicestatus

Die Quelle erfasst außerdem Anrufvolumen, Latenz, Erfolgsrate und fehlgeschlagene Stichproben.

Diese operativen Kennzahlen helfen zu bestimmen, ob der Katalogeintrag noch funktionsfähig und es wert ist, veröffentlicht zu bleiben.

Wie sollten Kontingente an Katalogeinträge geknüpft werden?

Kontingent sollte Teil der Berechtigungsrichtlinie sein.

Die zugrunde liegende Plattform unterstützt Kontingente auf Mandanten- und Projektebene.

Bei einem Compute-Eintrag kann das Kontingent begrenzen, wie viel Ressource das Projekt anfordern kann.

Bei einem Model-Service-Eintrag kann das Kontingent die Servicenutzung gemäß der unterstützten Gateway-Richtlinie begrenzen.

Ein Katalog sollte daher beantworten:

Wer ist berechtigt?

Wie viel dürfen sie konsumieren?

Was passiert, wenn das Limit erreicht ist?

Der Nutzer sollte das Kontingent nicht erst kennenlernen müssen, nachdem die Anfrage gescheitert ist.

Wie sollten Freigaben angeknüpft werden?

Die Freigabe sollte von Kosten, Risiko und Eigentümerschaft abhängen.

Die zugrunde liegende Workflow-Engine unterstützt dynamische und mehrstufige Freigaben.

Das bedeutet, unterschiedliche Katalogeinträge können unterschiedliche Richtlinien haben.

Beispiele:

Eine routinemäßige, kleine Compute-Anfrage innerhalb des Kontingents kann einem leichtgewichtigen Pfad folgen.

Eine große Kapazitätserweiterung erfordert die Freigabe durch die Führungskraft.

Sensibler Zugriff erfordert eine Sicherheitsfreigabe.

Eine Änderung an der Produktionsinfrastruktur erfordert eine Betriebsfreigabe.

Die Quelle schreibt diese genauen Richtlinien nicht vor.

Sie liefert den Workflow-Mechanismus.

Das Unternehmen sollte die Freigabelogik für jeden Serviceeintrag definieren.

Wie sollte Preis- oder Kostenkontext einbezogen werden?

Die zugrunde liegende Plattform erfasst Kartenstunden, Token-Nutzung, Energie, Projektkosten und Mandantenkosten.

Ein Katalogeintrag kann daher mit einer genehmigten Metering-Definition verknüpft werden.

Die Quelle legt nicht fest, dass jede Anfrage einen vorab sichtbaren Preis zeigen muss.

Was sie unterstützt, ist nachvollziehbarer Verbrauch nach der Lieferung.

Für gereifte interne Dienste kann auch der historische Stückkostenwert Eigentümern helfen, die Auswirkung zu verstehen, sich für eine Ressourcenspezifikation statt eine andere zu entscheiden.

Entscheidend ist, dieselbe Kostendefinition wie auf den formalen Betriebs- und Abrechnungsseiten zu verwenden.

Wie sollte die Service-Eigentümerschaft definiert werden?

Jeder Katalogeintrag sollte einen operativen Eigentümer haben.

Mögliche Eigentümer sind:

Infrastrukturteam
Netzwerkteam
Storage-Team
KI-Plattformteam
Model-Service-Eigentümer
Sicherheitsteam

Das zugrunde liegende Datenfundament umfasst Personen, Dienste, Assets und Aktivitäten in einem gemeinsamen Beziehungsmodell.

Das erlaubt es, den Katalogeintrag mit dem Team zu verknüpfen, das für Lieferung und Support verantwortlich ist.

Fällt der Dienst aus, sollte der Incident den verantwortlichen Eigentümer bereits kennen.

Wie sollte der Lifecycle eines Katalogeintrags funktionieren?

Eine Servicedefinition sollte ihren eigenen Lifecycle haben.

Entwurf.

Genehmigt.

Veröffentlicht.

Aktualisiert.

Veraltet.

Ausgemustert.

Die Quelle definiert diese genauen Katalogzustände nicht.

Sie unterstützt jedoch Modellversionen, Deployment-Templates, Workflow-Versionen, Asset-Lifecycle und Service-Veröffentlichung.

Die quellengestützte Schlussfolgerung ist, dass standardisierte Dienste kontrollierte Versionierung und Ausmusterung brauchen, damit alte Definitionen nicht unbegrenzt verfügbar bleiben.

Alle Lifecycle-Zustände sollten gemäß dem Unternehmensprozess umgesetzt werden.

Wie sollten Katalogeinträge mit Automatisierung verknüpft werden?

Der Katalogeintrag sollte auf den genehmigten Workflow oder das Template verweisen, das ihn liefert.

Hier wird der Katalog zu mehr als Dokumentation.

Die zugrunde liegende Workflow-Engine kann auslösen:

Ressourcen-Scheduling
Automatisierungsskripte
Bare-Metal-Lieferung
Kontingentänderungen

Die MaaS-Schicht kann Model-Deployment und Service-Veröffentlichung auslösen.

Der Katalogeintrag wird zur Eingangstür.

Der Workflow wird zur Lieferengine.

Scheduler und Automatisierungssysteme bleiben die Ausführungsschicht.

Wie sollte der Katalog mit Metering verbunden werden?

Jeder gelieferte Dienst sollte dieselben Nutzungsdatensätze erzeugen, die die Betriebsplattform verwendet.

Beispiele:

Der Compute-Dienst erzeugt Kartenstunden-Nutzung.

Die Model-API erzeugt Token-Nutzung.

Der Storage-Dienst erzeugt Storage-Nutzung.

Die dedizierte Leitung erzeugt Service- und Kostendatensätze.

Das bedeutet, der Katalog erzeugt kein neues Abrechnungsvokabular.

Er nutzt dasselbe Projekt- und Mandanten-Eigentümerschaftsmodell wieder, das bereits vom Metering verwendet wird.

Für Eigentümerschaft und Kosten-Rollup erklärt, wie Unternehmen Infrastrukturkosten bis auf Abteilungen, Projekte, Anwendungen oder Kunden zurückverfolgen können, wie diese Beziehungen erhalten bleiben sollten.

Was sollte der erste Katalog enthalten?

Beginnen Sie mit wiederholbaren, häufig genutzten, gut gesteuerten Diensten.

Ein quellengestützter erster Katalog könnte umfassen:

Standard-GPU-Ressourcenanfrage
Bare-Metal-KI-Knoten-Lieferung
Storage-Zuweisung
Projektkontingentänderung
Genehmigtes Model-Deployment
Inferenz-API-Dienst
Agenten-Dienst

Das reicht aus, um das Modell zu belegen.

Beginnen Sie nicht damit, jede Infrastrukturaktion zu katalogisieren.

Ein Plattformbeispiel, das die Spezifikationen, Templates, Workflows, MaaS-Dienste, Kontingente und das Metering liefert, die für den Aufbau eines solchen Katalogs nötig sind, ist Sensaka.

Wenn ich den ersten Service-Katalog erstellen würde, würde ich die Anfragen auswählen, die bereits wiederholt über Tickets eingehen, und diese zuerst standardisieren. Jeder Eintrag sollte genehmigte Parameter, einen Eigentümer, eine Freigaberegel, einen Ausführungs-Workflow und eine Metering-Definition haben. Fehlt eines davon, ist der Eintrag noch Dokumentation statt ein echter Dienst.