Wie können Unternehmen die Kosten der KI-Infrastruktur nach GPU-Stunde, Token, Projekt, Tenant oder Modell messen?

Unternehmen können die Kosten der KI-Infrastruktur messen, indem sie Ressourcen-Metering und Service-Metering unter demselben Ownership-Modell zusammenführen. Beschleuniger-Stunden messen, wie lange teures Compute zugewiesen ist, Token-Metering misst den Modell-Service-Verbrauch, und Projekt-, Tenant- und Modell-Kennungen erklären, wer die Ressourcen genutzt und was die Kosten verursacht hat.

Der schwierige Teil ist die Zuordnung, nicht die Arithmetik. Wenn Scheduler, API-Gateway, Energiesystem und Abrechnungssystem unterschiedliche Projektnamen oder Zeitfenster nutzen, kann derselbe Workload mehrere widersprüchliche Kostenzahlen erzeugen. Die Kostenrechnung braucht deshalb eine gemeinsame Definition von Ressource, Owner, Nutzungszeitraum und Einheit.

Was ist eine GPU-Stunde?

Eine GPU-Stunde ist eine Beschleuniger-Karte, die gemäß der Metering-Richtlinie für eine Stunde zugewiesen oder verbraucht wird.

Eine einfache Berechnung lautet:

GPU hours = Number of GPUs × Allocation time in hours

Wenn ein Trainingsjob 8 GPUs für 3 Stunden nutzt:

8 × 3 = 24 GPU hours

Diese Metrik misst Ressourcenzeit.

Sie misst nicht automatisch nützliche Arbeit.

Ein Job kann 24 GPU-Stunden verbrauchen, während die durchschnittliche Auslastung nur 40 Prozent beträgt.

Diese Unterscheidung ist wichtig, weil zugewiesene Kapazität wirtschaftlichen Wert behält, selbst wenn der Workload ineffizient ist.

Das Kostensystem sollte GPU-Stunden und Auslastung deshalb als getrennte Metriken führen.

GPU-Stunden beantworten: „Wie viel Beschleuniger-Kapazität hat dieser Workload belegt?"

Auslastung beantwortet: „Wie beschäftigt war der Beschleuniger, während er belegt war?"

Die Kombination beider macht Leerlaufkosten sichtbar.

Sollten GPU-Stunden zugewiesene Zeit oder aktive Zeit nutzen?

Nutzen Sie die Definition, die zu Ihrer geschäftlichen Fragestellung passt, und kennzeichnen Sie sie klar.

Zugewiesene GPU-Stunden zählen den vollständigen Zeitraum, in dem eine Karte für den Workload reserviert ist.

Aktive GPU-Stunden zählen nur Zeiträume, die eine definierte Aktivitätsregel erfüllen.

Für die interne Kapazitätsplanung sind zugewiesene Stunden oft nützlicher, weil der Scheduler dieselbe Karte während dieses Zeitraums keinem anderen Tenant geben konnte.

Für die Performance-Analyse kann aktive Zeit zeigen, wie viel der Reservierung tatsächlich nützliche Arbeit ausgeführt hat.

Bei der Abrechnung entscheidet das kommerzielle Modell.

Wenn ein Tenant eine dedizierte GPU für zehn Stunden reserviert, spiegelt eine Abrechnung nur für Momente über einem Auslastungs-Schwellenwert womöglich nicht die für diesen Tenant vorgehaltene Kapazität wider.

Ein nützliches Reporting-Modell kann beides zeigen:

Zugewiesene GPU-Stunden
Geschätzte aktive GPU-Stunden
Leerlaufrate
Durchschnittliche Auslastung

Das trennt Kapazitätsverbrauch von Effizienz.

Wie berechnet man die Kosten pro GPU-Stunde?

Kosten pro GPU-Stunde sind die der Beschleuniger-Kapazität zugewiesenen Kosten geteilt durch die GPU-Stunden im selben Zeitraum.

Eine einfache Formel lautet:

Cost per GPU hour = Allocated accelerator-related cost / GPU hours

Der Zähler kann eng oder breit gefasst sein.

Ein enges Modell umfasst womöglich nur Hardware-Abschreibung und Strom.

Ein breiteres Modell kann umfassen:

Beschleuniger-Abschreibung
Server-Gehäusekosten
Power
Kühlungs-Overhead
Rack- oder Colocation-Kosten
Netzwerk
Storage
Software
Operations-Personal
Wartung

Es gibt keinen universell richtigen Zähler.

Die Anforderung ist Konsistenz.

Wenn Sie das Ergebnis „vollständig belastete Kosten pro GPU-Stunde" nennen, definieren Sie jede enthaltene Kostenkategorie.

Wenn Sie es „Energiekosten pro GPU-Stunde" nennen, nehmen Sie nur Energiekosten auf.

Vergleichen Sie keine zwei Stückkosten, die unterschiedliche Grenzen nutzen.

Wie fügt sich Token-Metering in die Infrastrukturkosten ein?

Token-Metering verbindet Modell-Service-Output mit der Infrastruktur, die ihn erzeugt hat.

Eine Model-Serving-Plattform kann Input- und Output-Tokens nach Projekt, Tenant, API-Key, Modell und Zeitraum erfassen.

Die Infrastruktur-Ebene kann Beschleuniger-Stunden, Energie und andere Ressourcenkosten während desselben Zeitraums erfassen.

Dann kann das System berechnen:

Kosten pro 1.000 Tokens
Kosten pro 1 Million Tokens
Energiekosten pro Token
Infrastrukturkosten pro Token
Kosten nach Modell
Kosten nach Projekt
Kosten nach Tenant

Das macht aus KI-Kosten statt einer Geräte-Zahl eine Service-Einheiten-Zahl.

Die vollständige Kette erklärt für die Service-Architektur hinter diesen Datensätzen was MaaS ist und wie Modell-Repositories, Inferenz-Instanzen, API-Gateways und Token-Metering zusammenwirken.

Wie berechnet man die Kosten pro Token?

Kosten pro Token sind die einem Modell-Service zugeordneten Kosten geteilt durch das Token-Volumen, das demselben Service und Zeitraum zugeordnet ist.

Zum Beispiel:

Einem Modell-Service werden an einem Tag 600 $ Infrastrukturkosten zugewiesen.

Er verarbeitet 300 Millionen abrechenbare Tokens.

$600 / 300,000,000 = $0.000002 per Token

Das lässt sich auch angeben als:

$2 per 1 million Tokens

Dieses Beispiel dient der Veranschaulichung. Ihr Ergebnis hängt vollständig von der Kostengrenze und der Token-Definition ab.

Ein Produktionssystem sollte definieren:

Behandlung von Input- vs. Output-Tokens
Fehlgeschlagene Requests
Retries
Gecachte Ergebnisse
Shared-Instance-Zuordnung
Zeitzone
Abrechnungszeitraum
Modellversion
Projekt- und Tenant-Ownership

Die Zahl ist nur nützlich, wenn die Definition stabil ist.

Sollten Input- und Output-Tokens getrennt bepreist werden?

Das können sie, besonders wenn sich die Output-Generierung im Compute-Verhalten wesentlich von der Input-Verarbeitung unterscheidet.

Aber getrennte Bepreisung ist eine geschäftliche Entscheidung, keine Anforderung für den Infrastrukturbetrieb.

Erfassen Sie mindestens Input- und Output-Tokens getrennt, wo das Serving-System sie offenlegt.

Sie können sie später immer noch zusammenführen.

Sie können sie nicht nachträglich trennen, wenn Sie die Unterscheidung nie erfasst haben.

Beide zu bewahren hilft außerdem, Kostenänderungen zu erklären.

Angenommen, die Anzahl der Requests bleibt konstant, aber die durchschnittliche Output-Länge verdoppelt sich.

Das gesamte Token-Volumen steigt, obwohl sich die Anzahl der Aufrufe nicht ändert.

Das kann Inferenz-Compute und -Kosten erhöhen.

Ein Dashboard, das nur Requests zeigt, würde die Ursache verbergen.

Wie ordnet man Kosten einem Projekt zu?

Ordnen Sie Kosten einem Projekt zu, indem Sie jede Ressourcenreservierung und jeden Service-Aufruf mit einer stabilen Projekt-Kennung verknüpfen.

Für Training sollte der Scheduler oder der Job-Submission-Prozess die Projekt-Identität verlangen.

Für Inferenz sollten API-Key, Service-Route, Tenant oder Anwendungs-Identität auf ein Projekt abgebildet werden.

Bei dedizierten Ressourcen ist die Zuordnung unkompliziert.

Nutzen Sie bei gemeinsam genutzten Ressourcen eine dokumentierte Zuordnungsregel.

Beispiele umfassen:

GPU-Reservierungszeit
Tatsächliche Ausführungszeit
Token-Volumen
Request-Volumen
Anteil an reservierter Kapazität
Anteil an gemessener Auslastung

Wählen Sie die Regel, die am besten widerspiegelt, wie die gemeinsam genutzte Ressource verbraucht wird.

Halten Sie sie dann über Zeiträume hinweg konsistent.

Die Plattform sollte außerdem die rohen Nutzungsdatensätze bewahren, damit Finance oder Operations das Ergebnis erklären können.

Wie ordnet man Kosten einem Tenant zu?

Die Tenant-Zuordnung funktioniert genauso, aber der Tenant wird zur primären Ownership-Dimension.

Ein Tenant kann mehrere Projekte enthalten.

Das bedeutet, das Datenmodell sollte Hierarchie unterstützen.

Zum Beispiel:

Tenant A
Projekt A1
Projekt A2
Modell-Service A
Trainingsjob A3

Kosten lassen sich dann auf jeder Ebene ausweisen, ohne die Nutzung zu duplizieren.

Wenn Projekt A1 100 GPU-Stunden verbraucht und Projekt A2 50, beträgt die Tenant-Summe 150.

Dasselbe Modell funktioniert für die Token-Nutzung.

Deshalb ist ein gemeinsames Ownership-Modell essenziell.

Lassen Sie nicht zu, dass der Scheduler Abteilungsnamen nutzt, während das Gateway Account-IDs nutzt und Finance einen anderen Projektcode verwendet, ohne dass es eine Zuordnung zwischen ihnen gibt.

Wie ordnet man Kosten einem Modell zu?

Kosten auf Modellebene erfordern eine Beziehung zwischen der Modellversion, ihren Inferenz-Instanzen und dem Compute, das sie verbrauchen.

Bei dedizierten Modell-Instanzen ist das unkompliziert.

Wenn Modell X vier GPUs für zehn Stunden belegt, lassen sich diese 40 GPU-Stunden direkt zuordnen.

Shared Serving ist schwieriger.

Wenn sich mehrere Modelle einen Beschleuniger teilen, braucht die Plattform eine Zuordnungsregel, die auf Ausführungszeit, Token-Volumen, reserviertem Anteil oder einem anderen messbaren Treiber basiert.

Kosten auf Modellebene sollten auch den Kontext der Servicequalität einbeziehen.

Ein günstigeres Modell ist nicht automatisch besser, wenn es das erforderliche SLO verfehlt oder inakzeptable Output-Qualität liefert.

Kosten sind eine operative Dimension.

Servicequalität ist eine andere.

Der nützliche Vergleich sind die Kosten auf dem erforderlichen Qualitätsniveau.

Wie sollte Energie einbezogen werden?

Energie sollte, wo verfügbar, anhand gemessener Beschleuniger- oder Server-Leistung einbezogen werden, mit einer klaren Regel für Facility-Overhead.

Integrieren Sie auf Beschleuniger-Ebene die Leistung über die Zeit, um kWh zu berechnen.

Nutzen Sie auf Server-Ebene, wo verfügbar, Server-Metering.

Wenn Sie facility-zugeordnete Energie schätzen möchten, können Sie einen dokumentierten Facility-Overhead-Faktor wie eine relevante PUE-Messung anwenden, sollten das aber als Zuordnungsmethode kennzeichnen.

Wenden Sie dann den Stromtarif für den passenden Zeitraum an.

Das ist wichtig, wenn sich die Strompreise nach Tageszeit ändern.

Ein flexibler Trainingsjob, der außerhalb der Spitzenzeiten läuft, hat womöglich niedrigere Energiekosten, selbst wenn er dieselbe Anzahl GPU-Stunden nutzt.

Die detaillierte Methode liefert für die Formeln wie ein Rechenzentrum PUE, WUE, GPU-Energieverbrauch und Energiekosten pro Token berechnen kann.

Wie misst man Leerlaufkosten?

Leerlaufkosten sind die Kosten zugewiesener oder eigener Kapazität, die gemäß der Definition der Organisation nicht die vorgesehene Menge nützlicher Arbeit erzeugt.

Definieren Sie zuerst Leerlauf.

Eine vollständig nicht zugewiesene Karte ist ein Typ.

Eine Karte, die einem Job mit 5 Prozent Auslastung zugewiesen ist, ist ein anderer.

Eine Karte, die auf Storage wartet, ist ein weiterer.

Ein fragmentierter Pool mit freien Karten, die keinen wartenden Job bedienen können, ist noch ein weiterer.

Diese Ursachen sollten nicht zu einer Zahl zusammengefasst und den Nutzern angelastet werden.

Klassifizieren Sie den Leerlaufgrund, wo möglich.

Beispiele:

Keine Nachfrage
Quota-Einschränkung
Fragmentierung
Netzwerk-Engpass
Storage-Engpass
Daten-Laden
Degradierte Hardware
Überdimensionierte Ressourcenanfrage

Berechnen Sie dann die Beschleuniger-Stunden und Energie, die mit jeder Ursache verbunden sind.

Das macht aus einem Leerlaufraten-KPI ein Optimierungs-Backlog.

Wie sollten gemeinsam genutzte Infrastrukturkosten zugeordnet werden?

Geteilte Kosten sollten einen stabilen Zuordnungstreiber nutzen, der verständlich und schwer zu manipulieren ist.

Netzwerk und Storage sind häufige Beispiele.

Mögliche Zuordnungstreiber sind verbrauchte Bandbreite, reservierte Storage-Kapazität, I/O-Volumen, GPU-Stunden, Projektanteil oder eine feste Grundgebühr plus variable Nutzung.

Es gibt keine einzelne beste Methode.

Die Frage ist, ob die Zuordnung entscheidungsnützlich ist.

Wenn die Storage-Kosten im Vergleich zu den GPU-Kosten winzig sind, erzeugt eine überkomplexe IOPS-basierte Zuordnung womöglich mehr Verwaltungsaufwand als Nutzen.

Wenn Storage ein bedeutender Kostenfaktor ist und bestimmte Projekte unverhältnismäßig viel Bandbreite verbrauchen, ist eine detailliertere Regel womöglich gerechtfertigt.

Fangen Sie einfach an.

Erhöhen Sie die Präzision nur, wenn das Ergebnis eine echte Entscheidung verändert.

Wie sollten Kostendaten mit Quotas verbunden sein?

Kosten- und Quota-Definitionen sollten sich dasselbe Ressourcenmodell teilen.

Wenn ein Tenant eine Quota für acht High-Memory-GPUs hat, sollte das Metering-System genau diese Ressourcen konsistent identifizieren.

Wenn das Quota-System eine partitionierte GPU als eine Ressource behandelt, während die Abrechnung sie als Bruchteil behandelt, dokumentieren Sie die Umrechnung.

Nicht aufeinander abgestimmte Definitionen erzeugen Streitfälle.

Das Betriebsmodell der Quelle spricht das direkt an: Beschleuniger-Stunden, Energieverbrauch und Token-Metering brauchen abgestimmte Zuordnungsdefinitionen, damit unterschiedliche Module keine widersprüchlichen Zahlen erzeugen.

Das ist ebenso sehr ein Data-Governance-Thema wie ein Abrechnungs-Thema.

Was sollte ein KI-Kosten-Dashboard zeigen?

Ein nützliches Kosten-Dashboard sollte Kosten, Nutzung, Effizienz und Ownership gemeinsam zeigen.

Mindestens:

Gesamte Beschleuniger-Stunden
Verfügbare vs. zugewiesene Kapazität
Leerlaufrate
Kosten pro GPU-Stunde
Token-Volumen
Kosten pro Token
Energieverbrauch
Projekt-Ranking
Tenant-Ranking
Modell-Ranking
Ressourcentyp oder Beschleunigermodell
Trend über die Zeit

Jede zusammengefasste Zahl sollte Drill-down zu den Nutzungsdatensätzen unterstützen, die sie erzeugt haben.

Ein Plattform-Beispiel mit einem gemeinsamen Metering-Modell über Projekte, Tenants, Modelle und Beschleuniger-Ressourcen hinweg ist Sensaka.

Wenn ich KI-Kostenrechnung aufbauen würde, würde ich mit einer Regel beginnen: Jede GPU-Stunde und jeder Token muss einen Owner und ein Zeitintervall tragen. Sobald das gilt, wird Projekt-, Tenant- und Modell-Reporting zu einem Gruppierungsproblem. Ohne das ist selbst ein wunderschönes Kosten-Dashboard größtenteils eine Schätzung.