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

Unternehmen erstellen standardisierte Service-Kataloge, indem sie wiederholbare Infrastruktur- und KI-Fähigkeiten in genehmigte Servicedefinitionen überführen, jeweils mit bekannten Parametern, Eigentümerschaft, Kontingent, Freigabe, Liefer-Workflow, Metering und Lifecycle. Eine formale Seite namens Service-Katalog definiert das Ausgangsmaterial nicht, es liefert aber die Bausteine, die man dafür braucht.

Am besten gestützt ist der Ansatz, zuerst das zu katalogisieren, was Nutzer ohnehin schon 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. Bei Infrastruktur steht ein Katalogeintrag etwa für eine Compute-Ressource, einen Bare-Metal-Server, eine Storage-Zuweisung, einen dedizierten Netzwerkdienst oder eine Kontingentänderung. Bei KI-Diensten kann er ein genehmigtes Model-Deployment, eine Inferenz-Instanz, eine Model-API, einen Knowledge-Base-Dienst oder einen Agenten-Dienst darstellen.

Der Katalogeintrag blendet unnötige Implementierungsdetails aus. Der Nutzer wählt den Dienst und die genehmigten Parameter, und die Plattform kümmert sich um Governance und Lieferung. Die Quelle stützt dieses Muster mit standardisierten Ressourcenspezifikationen, Templates, Workflows, Service-Veröffentlichung und Metering.

Warum Infrastrukturanfragen standardisieren?

Standardisierung spart manuelle Einzelfallarbeit. Ohne Service-Katalog fordern Nutzer Infrastruktur oft per Freitext an, etwa mit „Bitte gib mir einen leistungsstarken GPU-Server.“ Darauf folgen Rückfragen: Welcher Beschleuniger, wie viele, wie viel Speicher und für wie lange? Für welches Projekt, mit welchem Kontingent, welchem Betriebssystem und welchem Netzwerk?

Ein standardisierter Katalogeintrag macht aus diesem Gespräch definierte Felder. Das zugrunde liegende Scheduling-Modell arbeitet bereits mit Standard-Ressourcenspezifikationen für heterogene GPU- und NPU-Kapazität, und das ist die richtige Grundlage dafür.

Was sollte ein Compute-Katalogeintrag enthalten?

Ein Compute-Eintrag definiert eine Ressourcenfähigkeit und nicht eine einzelne physische Maschine. Von der Quelle gestützte Parameter sind:

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

Ein universelles Katalogschema definiert die Quelle nicht. Ein praxistauglicher Eintrag sollte zusätzlich Service-Eigentümer, Freigaberichtlinie, Metering-Regel für die Nutzung und das Verhalten bei Rückgabe oder Ablauf festlegen. Der Nutzer soll verstehen, was er bekommt und wie es gesteuert wird, und das Infrastrukturteam, wie die Anfrage auf den Ressourcenpool abgebildet wird.

Wie sollten heterogene Beschleuniger im Katalog erscheinen?

Der Katalog präsentiert genehmigte Ressourcenspezifikationen, während die tatsächliche Kompatibilität von Hersteller und Modell darunter erhalten bleibt. Die zugrunde liegende Plattform unterstützt heterogenes Beschleuniger-Pooling, sodass nicht jeder Nutzer jeden Hardwarehersteller verstehen muss. Fähigkeitsunterschiede, die für den Workload relevant sind, sollte der Katalog trotzdem nicht verstecken.

Ein Standarddienst kann Ressourcenklasse, Speicherstufe, ganze oder gesliceste Ressource und den unterstützten Workload-Typ festlegen. Der Scheduler bildet die Anfrage dann auf kompatible, funktionsfähige Hardware ab.

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 ergibt einen klar standardisierbaren Dienst. Ein Katalogeintrag kann genehmigte Hardwareklasse, Betriebssystem, Treibersatz, Monitoring-Agent, Cluster-Rolle und Netzwerkprofil festlegen.

Die Anfrage läuft dann in den Workflow: Die Plattform validiert den physischen Server, die Bereitstellung läuft, der Zustand nach der Installation wird geprüft und das Ergebnis zurückgeschrieben. So wird aus „bau mir einen Server“ ein wiederholbarer 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 über die Parameter standardisieren, die die Plattform steuern kann. Das Ausgangsmaterial umfasst Storage-Management, Kapazität, Performance, Kontingente und Nutzung. Ein Storage-Katalogeintrag könnte also Storage-Dienst, Kapazität, Mandant oder Projekt, Kontingent, Performance-Anforderung (sofern unterstützt) und Lifecycle festlegen.

Eine formale Storage-Katalog-Schnittstelle spezifiziert die Quelle nicht. Das Prinzip, das sie stützt, lautet, wiederholbare Zuweisungsregeln in standardisierte Servicedefinitionen zu überführen, und das gilt genauso für andere Infrastrukturressourcen.

Wie sollten Netzwerkdienste erscheinen?

Die zugrunde liegende Plattform verwaltet dedizierte Leitungen und Netzwerktopologie. Ein Netzwerkkatalog kann Anfragen wie eine private Standortverbindung, eine Bandbreitenänderung, Netzwerkzugriff oder ein genehmigtes Konnektivitätsprofil standardisieren. Wie der Dienst genau aussieht, hängt vom Netzwerkbetriebsmodell des Unternehmens ab.

Der Katalog sollte die Anfrage mit Eigentümer, Leitungs- oder Netzwerkobjekt, Freigabe, Kosten, Liefer-Workflow und Monitoring verknüpfen. So passen kaufmännischer und operativer Datensatz zusammen.

Wie sollte Model-Deployment im Katalog erscheinen?

Die zugrunde liegende MaaS-Schicht arbeitet bereits mit Deployment-Templates, weshalb sich Model-Deployment gut für den Katalog eignet. Ein Eintrag kann genehmigtes Modell und Modellversion, Deployment-Template, Ressourcenspezifikation, Projekt, Replika- oder Skalierungsrichtlinie und Service-Tier umfassen.

Der Nutzer wählt die genehmigte Kombination, die Plattform erstellt Inferenz-Instanzen, und das Service-Gateway veröffentlicht den Endpunkt. Auch wenn die Quelle es nicht so nennt, ist das ein Dienst im Stil eines Service-Katalogs.

Wie sollten Model-APIs erscheinen?

Das API-Gateway bildet eine stabile Servicegrenze. Ein Katalogeintrag für eine Model-API kann Model-Service, Mandantenberechtigung, Projekt, API-Key-Richtlinie, Kontingent, Rate-Limit, Fallback-Richtlinie und Metering-Definition festlegen.

Die zugrunde liegende Model-Service-Schicht bietet Key-Management, Rate-Limits, Kontingente, Routing, Fallback und Token-Metering, also genau die Betriebskontrollen, die einen API-Katalog nützlich machen. Der Eintrag beschreibt den gesteuerten Dienst und legt die interne Inferenz-Topologie nicht offen.

Wie sollten KI-Agenten-Dienste erscheinen?

Mit der zugrunde liegenden Orchestrierungsschicht lässt sich eine Agenten-Orchestrierung als Dienst veröffentlichen, sodass auch ein genehmigter Agent zum Katalogeintrag werden kann. Nutzer sehen dann Zweck, Version, Geschäftsbereich, Zugriffsumfang und Servicestatus des Agenten.

Die Quelle erfasst außerdem Anrufvolumen, Latenz, Erfolgsrate und fehlgeschlagene Stichproben. An diesen Kennzahlen lässt sich ablesen, ob der Eintrag noch funktioniert und weiter veröffentlicht bleiben sollte.

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

Das Kontingent gehört zur Berechtigungsrichtlinie. Die zugrunde liegende Plattform unterstützt Kontingente auf Mandanten- und Projektebene. Bei einem Compute-Eintrag begrenzt das Kontingent, wie viel Ressource das Projekt anfordern kann, bei einem Model-Service-Eintrag die Nutzung des Dienstes gemäß der Gateway-Richtlinie.

Ein Katalog sollte deshalb beantworten, wer berechtigt ist, wie viel diese Nutzer konsumieren dürfen und was beim Erreichen des Limits passiert. Vom Kontingent sollte niemand erst erfahren, wenn die Anfrage schon gescheitert ist.

Wie sollten Freigaben angeknüpft werden?

Die Freigabe richtet sich nach Kosten, Risiko und Eigentümerschaft. Die zugrunde liegende Workflow-Engine unterstützt dynamische und mehrstufige Freigaben, sodass verschiedene Katalogeinträge verschiedene Richtlinien haben können.

Eine routinemäßige kleine Compute-Anfrage innerhalb des Kontingents kann einen leichtgewichtigen Pfad nehmen. Eine große Kapazitätserweiterung braucht die Freigabe der Führungskraft, sensibler Zugriff eine Sicherheitsfreigabe und eine Änderung an der Produktionsinfrastruktur eine Betriebsfreigabe. Diese konkreten Richtlinien schreibt die Quelle nicht vor, sie liefert den Workflow-Mechanismus, und die Freigabelogik für jeden Eintrag legt das Unternehmen fest.

Wie sollte Preis- oder Kostenkontext einbezogen werden?

Die zugrunde liegende Plattform erfasst Kartenstunden, Token-Nutzung, Energie, Projektkosten und Mandantenkosten. Ein Katalogeintrag lässt sich daher mit einer genehmigten Metering-Definition verknüpfen.

Dass jede Anfrage vorab einen Preis anzeigen muss, legt die Quelle nicht fest. Sie stützt einen nachvollziehbaren Verbrauch nach der Lieferung. Bei ausgereiften internen Diensten können historische Stückkosten Eigentümern zeigen, was die Wahl einer Ressourcenspezifikation gegenüber einer anderen bedeutet. Wichtig ist, dieselbe Kostendefinition zu verwenden wie auf den formalen Betriebs- und Abrechnungsseiten.

Wie sollte die Service-Eigentümerschaft definiert werden?

Jeder Katalogeintrag braucht einen operativen Eigentümer, etwa das Infrastruktur-, Netzwerk-, Storage- oder KI-Plattformteam, den Eigentümer eines Model-Service oder das Sicherheitsteam.

Das zugrunde liegende Datenfundament bildet Personen, Dienste, Assets und Aktivitäten in einem gemeinsamen Beziehungsmodell ab. Damit lässt sich der Katalogeintrag mit dem Team verknüpfen, das für Lieferung und Support verantwortlich ist, und fällt der Dienst aus, kennt der Incident den Eigentümer bereits.

Wie sollte der Lifecycle eines Katalogeintrags funktionieren?

Eine Servicedefinition braucht ihren eigenen Lifecycle, etwa von Entwurf über genehmigt, veröffentlicht und aktualisiert bis zu veraltet und ausgemustert. Diese konkreten Katalogzustände definiert die Quelle nicht, sie unterstützt aber Modellversionen, Deployment-Templates, Workflow-Versionen, Asset-Lifecycle und Service-Veröffentlichung.

Daraus folgt, dass standardisierte Dienste kontrollierte Versionierung und Ausmusterung brauchen, damit alte Definitionen nicht unbegrenzt verfügbar bleiben. Die Lifecycle-Zustände sollten gemäß dem Unternehmensprozess umgesetzt werden.

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

Der Katalogeintrag verweist auf den genehmigten Workflow oder das Template, das ihn liefert, und wird dadurch mehr als Dokumentation. Die zugrunde liegende Workflow-Engine kann Ressourcen-Scheduling, Automatisierungsskripte, Bare-Metal-Lieferung und Kontingentänderungen auslösen, die MaaS-Schicht Model-Deployment und Service-Veröffentlichung.

Der Katalogeintrag ist die Eingangstür, der Workflow die Lieferengine, und Scheduler und Automatisierungssysteme bleiben die Ausführungsschicht.

Wie sollte der Katalog mit Metering verbunden werden?

Jeder gelieferte Dienst sollte dieselben Nutzungsdatensätze erzeugen, mit denen die Betriebsplattform arbeitet. Der Compute-Dienst erzeugt Kartenstunden, die Model-API Token-Nutzung, der Storage-Dienst Storage-Nutzung und die dedizierte Leitung Service- und Kostendatensätze.

Der Katalog braucht also kein neues Abrechnungsvokabular. Er nutzt dasselbe Modell für Projekt- und Mandanten-Eigentümerschaft, das das Metering schon verwendet.

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?

Den Anfang machen wiederholbare, häufig genutzte und gut gesteuerte Dienste. Ein erster Katalog auf Basis der Quelle 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, um das Modell zu erproben. Jede Infrastrukturaktion gleich zu Beginn zu katalogisieren, wäre zu viel.

Ein Plattformbeispiel, das Spezifikationen, Templates, Workflows, MaaS-Dienste, Kontingente und Metering für einen solchen Katalog liefert, ist Sensaka.

Wenn ich den ersten Service-Katalog erstellen würde, würde ich die Anfragen nehmen, die schon jetzt immer wieder als Tickets hereinkommen, und diese zuerst standardisieren. Jeder Eintrag braucht genehmigte Parameter, einen Eigentümer, eine Freigaberegel, einen Ausführungs-Workflow und eine Metering-Definition. Fehlt eines davon, ist der Eintrag noch Dokumentation und kein echter Dienst.