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. Die einfache Berechnung dazu lautet GPU hours = Number of GPUs × Allocation time in hours, und ein Trainingsjob, der 8 GPUs für 3 Stunden nutzt, landet damit bei 8 × 3 = 24 GPU hours.

Diese Metrik misst Ressourcenzeit und nicht automatisch nützliche Arbeit. Ein Job kann 24 GPU-Stunden verbrauchen, während die durchschnittliche Auslastung nur 40 Prozent beträgt. Die 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?" Erst 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 nur die 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. Reserviert ein Tenant eine dedizierte GPU für zehn Stunden, spiegelt eine Abrechnung nur für Momente über einem Auslastungs-Schwellenwert die für diesen Tenant vorgehaltene Kapazität womöglich nicht wider. Ein nützliches Reporting-Modell kann daher zugewiesene GPU-Stunden, geschätzte aktive GPU-Stunden, Leerlaufrate und durchschnittliche Auslastung nebeneinander und trennt so 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, also 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 nimmt Beschleuniger-Abschreibung, Server-Gehäusekosten, Power, Kühlungs-Overhead, Rack- oder Colocation-Kosten, Netzwerk, Storage, Software, Operations-Personal und Wartung dazu.

Einen universell richtigen Zähler gibt es nicht, die Anforderung heißt 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. Und 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, während die Infrastruktur-Ebene Beschleuniger-Stunden, Energie und andere Ressourcenkosten im selben Zeitraum erfasst.

Daraus lassen sich Kosten pro 1.000 Tokens, Kosten pro 1 Million Tokens, Energiekosten pro Token, Infrastrukturkosten pro Token sowie Kosten nach Modell, nach Projekt und nach Tenant berechnen. Aus einer Geräte-Zahl wird damit 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. Werden einem Modell-Service an einem Tag 600 $ Infrastrukturkosten zugewiesen und verarbeitet er dabei 300 Millionen abrechenbare Tokens, ergibt das $600 / 300,000,000 = $0.000002 per Token, oder anders ausgedrückt $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 deshalb die Behandlung von Input- gegenüber Output-Tokens festlegen, dazu fehlgeschlagene Requests, Retries, gecachte Ergebnisse, Shared-Instance-Zuordnung, Zeitzone, Abrechnungszeitraum, Modellversion sowie Projekt- und Tenant-Ownership. Die Zahl ist nur brauchbar, solange die Definition stabil bleibt.

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. Getrennte Bepreisung bleibt aber eine geschäftliche Entscheidung und ist keine Anforderung für den Infrastrukturbetrieb.

Erfassen Sie Input- und Output-Tokens mindestens getrennt, wo das Serving-System sie offenlegt. Zusammenführen lassen sie sich später jederzeit. Nachträglich trennen lassen sie sich nicht, 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, und das kann Inferenz-Compute und -Kosten erhöhen. Ein Dashboard, das nur Requests zeigt, würde diese 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. Bei gemeinsam genutzten Ressourcen brauchen Sie eine dokumentierte Zuordnungsregel, etwa nach GPU-Reservierungszeit, tatsächlicher Ausführungszeit, Token-Volumen, Request-Volumen, Anteil an reservierter Kapazität oder Anteil an gemessener Auslastung. Wählen Sie die Regel, die am besten widerspiegelt, wie die gemeinsam genutzte Ressource verbraucht wird, und halten Sie sie ü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, nur wird der Tenant zur primären Ownership-Dimension. Ein Tenant kann mehrere Projekte enthalten, das Datenmodell sollte also Hierarchie unterstützen: Tenant A mit Projekt A1, Projekt A2, dem Modell-Service A und dem Trainingsjob A3.

Kosten lassen sich dann auf jeder Ebene ausweisen, ohne die Nutzung zu duplizieren. Verbraucht Projekt A1 100 GPU-Stunden und Projekt A2 50, beträgt die Tenant-Summe 150. Für die Token-Nutzung gilt dasselbe Modell.

Genau deshalb ist ein gemeinsames Ownership-Modell essenziell. Der Scheduler darf nicht mit Abteilungsnamen arbeiten, während das Gateway Account-IDs nutzt und Finance einen dritten Projektcode führt, ohne dass irgendwo eine Zuordnung zwischen ihnen existiert.

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: Belegt Modell X vier GPUs für zehn Stunden, lassen sich diese 40 GPU-Stunden direkt zuordnen. Shared Serving ist schwieriger, denn wenn sich mehrere Modelle einen Beschleuniger teilen, braucht die Plattform eine Zuordnungsregel auf Basis von Ausführungszeit, Token-Volumen, reserviertem Anteil oder einem anderen messbaren Treiber.

Kosten auf Modellebene sollten außerdem 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 eine andere, und 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, und 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 zählt, sobald sich die Strompreise nach Tageszeit ändern: Ein flexibler Trainingsjob, der außerhalb der Spitzenzeiten läuft, hat womöglich niedrigere Energiekosten, selbst bei identischer Anzahl GPU-Stunden. Die Formeln dazu liefert 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 also zuerst, was Leerlauf heißt. Eine vollständig nicht zugewiesene Karte ist ein Typ, eine Karte, die einem Job mit 5 Prozent Auslastung zugewiesen ist, ein zweiter, eine Karte, die auf Storage wartet, ein dritter, und ein fragmentierter Pool mit freien Karten, die keinen wartenden Job bedienen können, ein vierter.

Diese Ursachen sollten nicht zu einer Zahl zusammenlaufen, die dann den Nutzern angelastet wird. Klassifizieren Sie den Leerlaufgrund, wo möglich: keine Nachfrage, Quota-Einschränkung, Fragmentierung, Netzwerk-Engpass, Storage-Engpass, Daten-Laden, degradierte Hardware oder eine überdimensionierte Ressourcenanfrage. Berechnen Sie dann die Beschleuniger-Stunden und die Energie, die zu jeder Ursache gehören. So wird 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 die häufigen Beispiele, und als Treiber kommen verbrauchte Bandbreite, reservierte Storage-Kapazität, I/O-Volumen, GPU-Stunden, Projektanteil oder eine feste Grundgebühr plus variable Nutzung in Frage.

Eine einzelne beste Methode gibt es nicht. Die Frage ist, ob die Zuordnung bei Entscheidungen hilft. Sind die Storage-Kosten im Vergleich zu den GPU-Kosten winzig, erzeugt eine überkomplexe IOPS-basierte Zuordnung womöglich mehr Verwaltungsaufwand als Nutzen. Ist Storage ein bedeutender Kostenfaktor und verbrauchen bestimmte Projekte unverhältnismäßig viel Bandbreite, ist eine detailliertere Regel womöglich gerechtfertigt. Fangen Sie einfach an und 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. Hat ein Tenant eine Quota für acht High-Memory-GPUs, sollte das Metering-System genau diese Ressourcen konsistent identifizieren. Behandelt das Quota-System eine partitionierte GPU als eine Ressource, während die Abrechnung sie als Bruchteil führt, dokumentieren Sie die Umrechnung, denn 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 zeigt Kosten, Nutzung, Effizienz und Ownership gemeinsam. Mindestens gehören dazu die gesamten Beschleuniger-Stunden, verfügbare gegenüber zugewiesener Kapazität, Leerlaufrate, Kosten pro GPU-Stunde, Token-Volumen, Kosten pro Token, Energieverbrauch, ein Ranking nach Projekt, Tenant und Modell, der Ressourcentyp oder das Beschleunigermodell und der Trend über die Zeit.

Jede zusammengefasste Zahl sollte einen Drill-down zu den Nutzungsdatensätzen erlauben, 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, käme ich mit einer Regel an: 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 bleibt selbst ein wunderschönes Kosten-Dashboard größtenteils eine Schätzung.