Wie können Unternehmen Infrastrukturkosten auf Abteilungen, Projekte, Anwendungen oder Kunden zurückführen?

Unternehmen können Infrastrukturkosten auf Abteilungen, Projekte, Anwendungen oder Kunden zurückführen, indem sie Ressourcenzuweisungen und Serviceverbrauch mit stabilen Eigentümer-Identitäten versehen und die Datensätze dann über CMDB- und Geschäftsbeziehungen auf die gewünschte Geschäftsebene hochrechnen. Das Quellmaterial unterstützt direkt die Zuordnung nach Projekt, Tenant, Modell und Beschleunigertyp. Beschleuniger-Kartenstunden, Token-Nutzung, Energie, Storage-Nutzung und andere Verbrauchsdatensätze fließen dort in Projekt- und Tenant-Kostenberichte ein.

Für Abteilungen, Anwendungen oder Kunden definiert die Quelle keine eigene kommerzielle Abrechnungs-Engine. Der unterstützte Weg ist, diese Geschäftsobjekte im Beziehungsmodell mit Projekten, Tenants oder Services zu verbinden und dieselbe Nutzung dann entsprechend zu aggregieren.

Warum scheitert Infrastruktur-Kostenallokation?

Kostenallokation scheitert, wenn es Nutzung ohne Eigentümer gibt. Das Infrastrukturteam weiß vielleicht, wie viele GPU-Stunden, wie viel Storage und wie viel Strom verbraucht und wie viele Tokens generiert wurden. Tragen diese Datensätze aber keine Projekt-, Tenant-, Service- oder Eigentümeridentität, kann die Organisation nicht verlässlich sagen, wer die Kosten verursacht hat.

Das Quellmodell löst das, indem es Personen, Assets, Aktivitäten, Compute und Geschäftsobjekte über die CMDB und das Event-Datenmodell verbindet. Die Metering-Schicht verwendet dieselben Eigentumsdimensionen für die Kostenzuordnung, und auf dieser Verbindung baut alles Weitere auf.

Welche Nutzungsdatensätze sollten Eigentum tragen?

Jeder Nutzungsdatensatz, aus dem nennenswerte Kosten werden können, sollte eine Eigentumsdimension tragen, sofern das Quellsystem das unterstützt. Das KI-Betriebsmodell der Quelle umfasst:

• Beschleuniger-Kartenstunden
• Beschleuniger-Speichernutzung
• Token-Nutzung
• Energie
• Storage-Nutzung
• Modell
• Projekt
• Tenant
• Beschleunigertyp

Im Projekt-Kosten-Szenario heißt es ausdrücklich, dass die Plattform Kartenstunden, Beschleuniger-Speicherbelegung und Token-Aufrufe nach Projekt aggregieren, Energie- und Ressourcenbelegungskosten zuordnen und Projekt- und Tenant-Kostenberichte erstellen kann. Das sind direkt unterstützte Fähigkeiten der Quelle. Dasselbe Prinzip lässt sich auf andere Infrastrukturservices übertragen, sofern Nutzung und Eigentum bekannt sind.

Warum sollte Projektidentität früh erforderlich sein?

Nachdem ein Workload abgeschlossen ist, lässt sich das Eigentum viel schwerer rekonstruieren. Das Quellmodell verlangt deshalb, dass API-Schlüssel an ein Projekt-Tag gebunden sind, damit die Token-Nutzung korrekt zugeordnet werden kann. Es sagt auch ausdrücklich, dass Nutzung über einen Schlüssel ohne Projekt-Tag keinem Projekt zugeordnet werden kann.

Für Compute-Jobs gilt dieselbe Logik. Ein Trainingstask sollte beim Einreichen einem Projekt gehören, ein Modell-Service bei der Veröffentlichung einem Projekt oder Tenant, und eine Ressourcenreservierung sollte bei der Genehmigung ihren Eigentümer tragen. Warten Sie nicht bis zum Monatsende und lassen dann die Finanzabteilung raten, welches Team die Nutzung verursacht hat.

Wie können Beschleuniger-Kartenstunden zugeordnet werden?

Kartenstunden lassen sich ganz natürlich zuordnen, wenn der Scheduler weiß, welchem Projekt der Task gehört. Ein einfacher Datensatz enthält Ressourcenidentität, Start- und Endzeit, zugewiesene Kartenanzahl, Kartentyp, Task, Projekt und Tenant. Das Kostenmodell der Quelle aggregiert diese Datensätze nach Projekt, Tenant, Modell und Beschleunigertyp.

Nutzt ein Workload acht Karten für zehn Stunden, ergibt das nach der einfachen Allokationsdefinition 80 Kartenstunden. Die Organisation sollte festhalten, ob sie zugewiesene Zeit, aktive Zeit oder beides berichtet. Die Quelle unterstützt Kartenstunden-Metering, schreibt aber keine universelle kommerzielle Formel vor, und die gewählte Definition muss in allen Berichten gleich bleiben.

Wie kann Token-Nutzung zugeordnet werden?

Die Modell-Service-Schicht der Quelle erfasst die Token-Nutzung über das API-Gateway nach Tenant, Modell und Projekt. Weil API-Schlüssel an Projekt-Labels gebunden sind, erbt jeder Aufruf das Eigentum. Das System kann dann Eingabe- und Ausgabenutzung gemäß Servicedefinition, Anzahl der Anfragen, Token-Anzahl, Modell, Projekt, Tenant und Zeitraum aggregieren.

So entsteht ein direkter Datensatz über den Serviceverbrauch. In einer MaaS-Umgebung ist der Token-Datensatz oft der sauberste Weg, die Nutzung eines Inferenz-Services einem Geschäftseigentümer zuzuordnen.

Wie können Energiekosten zugeordnet werden?

Das Projekt-Kosten-Szenario der Quelle verknüpft Energie mit der Ressourcenbelegung, und das detaillierte Energiemodell unterstützt zusätzlich GPU-Energie und Energie pro Token. Eine universelle Methode, jede Facility-Kostenposition auf jedes Projekt zu verteilen, gibt die Quelle nicht vor.

Ein Ansatz im Sinne der Quelle ist, gemessene oder zuordenbare Ressourcenenergie zu nutzen, wo es sie gibt, und dann die genehmigte Allokationsregel der Organisation anzuwenden. Ein Beispiel: Die GPU-Leistung wird während eines Jobs gemessen, der Job gehört zu Projekt A, und die Beschleunigerenergie wird dem Nutzungsdatensatz von Projekt A zugeordnet.

Rechnet die Organisation Facility-Overhead wie PUE dazu, sollte das eine dokumentierte zusätzliche Allokationsregel sein und nicht unbemerkt in die rohe GPU-Energie einfließen.

Für die Formeln erklärt wie ein Rechenzentrum PUE, WUE, GPU-Energieverbrauch und Energiekosten pro Token berechnen kann die Messseite.

Wie können Storage-Kosten zugeordnet werden?

Im Projekt-Kosten-Szenario der Quelle ist Storage-Nutzung eine der Verbrauchsdimensionen. Für die Zuordnung braucht es eine erkennbare Storage-Beziehung, etwa wenn ein Trainingstask Dataset-Storage nutzt, eine Anwendung ein Volume verwendet, ein Modell-Service Modelldateien aus einem Storage-Pfad lädt oder ein Projekt einen Storage-Pool reserviert.

Die Organisation kann dann entscheiden, welches Storage-Maß die Kosten treibt, ob Kapazität, Durchsatz, IOPS oder eine feste Servicegebühr. Eine universelle Storage-Preisformel definiert die Quelle nicht, und diese Grenze sollte klar bleiben. Belegt ist, dass Storage mit dem Projekt verbunden und in die Kostenansicht einbezogen werden kann.

Wie fügen sich Abteilungen in das Modell ein?

Das Quellmodell unterstützt Organisationshierarchie, Personen, Tenants, Projekte und Geschäftsbeziehungen direkt. Eine eigene „Abteilungs-Kostenallokationsformel" definiert es nicht. Ein Rollup auf Abteilungen ist trotzdem möglich, wenn die Abteilung verbindlich über dem Projekt oder Tenant steht.

Nehmen Sie als Beispiel eine Abteilung KI-Forschung mit Projekt A, Projekt B und Projekt C. Wird die Nutzung jedes Projekts einheitlich gemessen, ist die Abteilungssumme die Summe der Projekte, die der Abteilung im Berichtszeitraum zugeordnet sind. Das folgt aus dem Beziehungsmodell und ist keine eigens beschriebene Funktion der Quelle.

Voraussetzung ist eine stabile organisatorische Zuordnung. Wechseln Projekte die Abteilung, sollte das Berichtssystem den Gültigkeitszeitraum speichern, damit historische Kosten nicht unbemerkt umgebucht werden.

Wie fügen sich Anwendungen in das Kostenmodell ein?

Anwendungen können zur Berichtsdimension werden, wenn die Geschäftstopologie Services mit den Ressourcen und Verbrauchsdatensätzen verbindet, die sie tragen. Das CMDB- und Geschäftstopologie-Modell der Quelle verknüpft Geschäftssystem, Anwendung, Modell-Service, Container, Compute-Ressource, Storage, Netzwerk und Eigentümer. Wo die Beziehung eindeutig ist, lässt sich Infrastrukturnutzung damit einer Anwendung zuordnen.

Ein Beispiel: Inference Service IS1 unterstützt Anwendung A, produziert 20 Millionen Tokens und verbraucht eine bestimmte Menge Beschleunigerzeit. Diese Datensätze können auf Anwendung A hochgerechnet werden.

Die Quelle behauptet nicht, dass sich jede gemeinsam genutzte Infrastrukturkostenposition immer präzise einer Anwendung zuordnen lässt. Für gemeinsame Netzwerk- und Facility-Kosten braucht es womöglich weiterhin eine vereinbarte Allokationsmethode.

Wie fügen sich Kunden in das Modell ein?

Das Quellmaterial unterstützt Tenants und Projekte direkt, ein universelles Abrechnungsmodell für externe Kunden hat es nicht. Ein Rollup auf Kunden hängt deshalb davon ab, wie das Unternehmen Kunden abbildet. Hat jeder Kunde einen eigenen Tenant, kann das Metering auf Tenant-Ebene als Kostengrenze pro Kunde dienen. Bedient ein Tenant mehrere Kunden, braucht die Service- oder Projektbeziehung eine zusätzliche Kundenkennung.

Die sicherste Regel im Betrieb: Leiten Sie Kundeneigentum nicht nachträglich aus der Nutzung ab. Erfassen oder ordnen Sie die Kundenidentität auf Service-, Projekt-, Schlüssel- oder Tenant-Ebene zu, bevor die Nutzung entsteht. Dann lässt sich das Kundenreporting nachvollziehen.

Warum sind CMDB-Beziehungsdaten für die Kosten wichtig?

Für die Kostenzuordnung reicht direktes Metering oft nicht aus. Ein GPU-Stunden-Datensatz nennt vielleicht das Projekt, während das Unternehmen die Abteilung sehen will. Ein Modell-Service-Datensatz nennt das Projekt, und die Finanzabteilung fragt nach Anwendung oder Kunde. Den Weg für das Rollup liefert der Beziehungsgraph.

Das Datenfundament der Quelle behandelt die CMDB ausdrücklich als gemeinsame Basis für Monitoring, Scheduling, Metering und Fehleranalyse. Die Kostenrechnung sollte also dieselben Objektbeziehungen nutzen und keine eigene Tabelle mit Eigentümern pflegen.

Für das Beziehungsmodell erklärt wie eine CMDB Server, GPUs, Container, Anwendungen, Geschäftsservices und Eigentümer verbinden kann, wie diese Objekte verknüpft sind.

Wie sollten gemeinsame Kosten zugeordnet werden?

Gemeinsame Kosten brauchen eine ausdrückliche Regel. Die Quelle misst Projekt- und Tenant-Nutzung für mehrere Ressourcentypen direkt, aber manche Infrastruktur teilen sich viele Verbraucher, etwa die Netzwerk-Fabric, gemeinsamer Storage, Facility-Stromoverhead, Betriebsarbeit und Rack-Kosten. Eine universelle Allokationsmethode für diese Posten definiert die Quelle nicht.

Ein Unternehmen kann einen vereinbarten Treiber wählen, zum Beispiel Kartenstunden, Token-Volumen, reservierte Kapazität, Storage-Kapazität, Projektanteil oder eine feste Allokation. Wichtig ist Transparenz: Eine Verteilung gemeinsamer Kosten sollte als Allokationsregel gekennzeichnet sein und nicht als direktes Metering erscheinen.

Wie sollten Kostenberichte abgeglichen werden?

Verwenden Sie dieselben Eigentums- und Kennzahlendefinitionen für detaillierte Nutzung, Projektberichte, Tenant-Berichte und jede Abrechnung. Das Quellmodell legt immer wieder Wert auf einheitliche Datendefinitionen. Token-Nutzung sollte also nicht im Gateway über ein Projekt-Label und in der Finanzabteilung über einen anderen Projektnamen zugeordnet werden, und Kartenstunden sollten nicht in einem Bericht zugewiesene und im anderen aktive Zeit messen, ohne dass das gekennzeichnet ist.

Der Abgleich sollte prüfen:

• gesamte Rohnutzung
• zugeordnete Nutzung
• nicht zugeordnete Nutzung
• Projektsummen
• Tenant-Summen
• Modellsummen
• Konsistenz des Zeitraums

Nicht zugeordnete Nutzung muss sichtbar sein. Sie ist ein Datenqualitätsproblem und gehört nicht versteckt unter „Sonstiges".

Wie sollten Showback und Chargeback dieselben Daten nutzen?

Beide können auf demselben Metering- und Eigentumsmodell aufsetzen. Sie unterscheiden sich darin, was das Unternehmen mit dem Ergebnis macht: Showback berichtet die Kosten dem Eigentümer, damit er sie sieht, Chargeback verbucht sie tatsächlich als interne oder externe finanzielle Belastung.

Die Quellmaterialien unterstützen Projekt- und Tenant-Kostenberichte sowie „Abrechnungsoutput", verwenden die Begriffe Showback und Chargeback aber nicht ausdrücklich.

Für die Unterscheidung erklärt was Showback versus Chargeback im IT- und KI-Infrastruktur-Kostenmanagement ist, wie sich die beiden Betriebsmodelle auf dasselbe Metering-Fundament beziehen.

Was sollte ein Kostenzuordnungs-Dashboard zeigen?

Ein nützliches Dashboard kann zeigen:

• gesamte Infrastrukturkosten
• Beschleuniger-Kartenstunden
• Token-Nutzung
• Energie
• Storage-Nutzung
• Idle-Kosten
• Projektkosten
• Tenant-Kosten
• Modellkosten
• Kosten nach Beschleunigertyp
• nicht zugeordnete Nutzung
• Geschäfts-Rollup, wo zugeordnet

Von jeder Summe aus sollte ein Drill-down bis zu den Nutzungsdatensätzen möglich sein, aus denen sie entstanden ist.

Ein Plattformbeispiel, das Projekt, Tenant, Modell, Beschleunigertyp, Kartenstunden, Token-Nutzung und Kosten verbindet, ist Sensaka.

Würde ich eine Kostenzuordnung aufbauen, stünde am Anfang eine Anforderung: Jeder nennenswerte Nutzungsdatensatz trägt schon bei seiner Erstellung eine stabile Projekt- oder Tenant-Identität. Abteilungen, Anwendungen und Kunden lassen sich dann über das Geschäftsbeziehungsmodell hochrechnen. Fehlt das Eigentum schon bei der Rohnutzung, wird die Allokation am Monatsende zum Ratespiel.