Tokenomics: Quantifizierung, wofür Tokens im agentischen Software Engineering verwendet werden
(arxiv.org)- Studie, die Ausführungsspuren eines LLM-basierten Multi-Agenten-Systems zur Softwareentwicklung auf SDLC-Phasen abbildet und misst, dass sich der Tokenverbrauch nicht auf die anfängliche Generierung, sondern auf Code-Review und Verifikation konzentriert
- Bei 30 Softwareentwicklungsaufgaben, die von ChatDev ausgeführt wurden, verbrauchte die Code-Review-Phase im Mittel 59,4 % der Tokens und erwies sich damit als größter Verbrauchsabschnitt
- Die durchschnittliche Token-Zusammensetzung über alle Aufgaben hinweg lag bei 53,9 % Input, 24,4 % Output und 21,6 % Reasoning; die wiederholte Weitergabe von Kontext zwischen Agenten erzeugt dabei eine erhebliche communication tax
- Während die Coding-Phase mit 58,0 % einen hohen Anteil an Output-Tokens aufweist, zeigt die Dokumentationsphase mit 80,2 % einen hohen Anteil an Input-Tokens, wodurch sich je nach Entwicklungsphase klar unterschiedliche Token-Nutzungsmuster ergeben
- Schlussfolgerung, dass für Kostenprognosen und Workflow-Optimierung tokeneffizientere Kollaborationsprotokolle für Agenten und standardisierte Evaluierungs-Frameworks erforderlich sind
Abstract
- LLM-basierte Multi-Agenten-Systeme (LLM-MA) werden zunehmend eingesetzt, um komplexe Software-Engineering-Aufgaben wie Requirements Engineering, Codegenerierung und Tests zu automatisieren
- Da Betriebseffizienz und Ressourcenverbrauch nicht ausreichend verstanden sind, behindern schwer vorhersehbare Kosten und Umweltauswirkungen den praktischen Einsatz
- Die Studie analysiert Ausführungsspuren von 30 Softwareentwicklungsaufgaben, die das ChatDev-Framework mit dem GPT-5 reasoning model ausgeführt hat, und ordnet interne Schritte den Phasen Design, Coding, Code Completion, Code Review, Testen und Dokumentation zu
- Vorläufige Ergebnisse zeigen, dass die iterative Code-Review-Phase mit durchschnittlich 59,4 % den größten Anteil am Tokenverbrauch hat
- Input-Tokens stellen mit durchschnittlich 53,9 % durchgängig den größten Anteil und liefern empirische Evidenz für erhebliche Ineffizienzen in der Agentenkollaboration
- Die Hauptkosten im agentischen Software Engineering konzentrieren sich nicht auf die anfängliche Codegenerierung, sondern auf automatisierte Verbesserungs- und Verifikationsprozesse
- Die Methodik kann für Kostenprognosen, Workflow-Optimierung und die Forschung an tokeneffizienteren Protokollen für die Agentenkollaboration genutzt werden
Einleitung
- Im großskaligen Software Engineering werden LLM-basierte Multi-Agenten-Systeme untersucht, um komplexe Aufgaben über den gesamten SDLC hinweg zu automatisieren
- LLM-MA-Frameworks simulieren menschliche Teamrollen wie Produktmanager, Architekten, Entwickler und Tester mit spezialisierten LLM-Agenten, die Design-, Coding- und Verifikationsaufgaben kollaborativ ausführen
- LLM-MA-Systeme können Aufgaben grundsätzlich auf mehrere Agenten verteilen und so Autonomie und Robustheit erhöhen
- Frühere Arbeiten zeigen, dass LLM-MA-Systeme divergentes Denken fördern, Reasoning und Faktentreue stärken und auf Probleme ausgeweitet werden können, die über die Fähigkeiten eines einzelnen Agenten hinausgehen
- Im Software Engineering besteht das Potenzial, End-to-End-Workflows von den Anforderungen bis zum Testen integriert zu automatisieren
- Das AGENTTAXO-Framework bietet eine Taxonomie zur Analyse der Tokenverteilung in allgemeinen LLM-MA-Systemen und führt das Konzept der „communication tax“ zur Beschreibung des Overheads in der Interaktion zwischen Agenten ein
- Die MAST-Fehlerklassifikation zeigt, dass viele Probleme in LLM-MA-Systemen eher aus Systemdesign- und Koordinationsfragen wie Phasenwiederholungen oder unvollständiger Verifikation entstehen als aus den Grenzen einzelner LLMs
- Bestehende Forschung analysiert Agentenverhalten in allgemeinen Kontexten, doch beim Ressourcenverbrauch von Systemen in mehrstufigen Software-Engineering-Workflows besteht weiterhin eine Wissenslücke
- Die für die praktische Einführung zentrale Frage „Wohin gehen die Tokens?“ ist im Software-Engineering-Bereich noch unzureichend beantwortet
- Tokenomics bezeichnet hier die Untersuchung von Betriebseffizienz und Ressourcenverbrauch in LLM-MA-Systemen
- Die Analyse untersucht die Verteilung des Tokenverbrauchs, indem interne Schritte von ChatDev auf Entwicklungsphasen abgebildet werden
- ChatDev simuliert ein virtuelles Softwareunternehmen, in dem mehrere Agentenrollen wie Programmierer und Tester den SDLC über mehrturnige Dialoge hinweg abschließen
- Bereitgestellt werden ein kuratierter Datensatz mit 30 Ausführungsspuren und ein vollständiges Reproduktionspaket
Studiendesign
-
Ziel und Analysegegenstand
- Ziel ist es, empirisch zu untersuchen, wie sich der Tokenverbrauch verteilt, wenn ein LLM-MA-System End-to-End-Aufgaben der Softwareentwicklung ausführt
- Der erste Analysegegenstand ist ChatDev
- Die „chat chain“-Architektur von ChatDev bildet ein klares sequentielles Wasserfallmodell aus Design → Coding → Testen ab und eignet sich wegen der deutlich getrennten Phasen gut für die Zuordnung zu Softwareentwicklungsphasen
- ChatDev ist eines der populären und häufig zitierten Open-Source-Frameworks
-
Kuratierung des Datensatzes
- ChatDev wurde auf 30 unterschiedlichen Softwareentwicklungsaufgaben ausgeführt
- Die Prompts stammen aus dem ProgramDev Dataset, das in der MAST-Studie verwendet wurde
- Die ausgewählten Prompts reichen von einfachen Algorithmen wie der Erzeugung von Fibonacci-Zahlen bis zu komplexeren Anwendungen wie einem Schachspiel
- Die Vielfalt wurde auf Basis jüngerer Forschung überprüft, nach der die Zahl der Reasoning-Tokens als Proxy für die Aufgabenkomplexität dienen kann
- Der Verbrauch an Reasoning-Tokens über die 30 Aufgaben hinweg reicht von 17.280 bis 40.000, was auf eine für die Studie ausreichende Vielfalt an Aufgabenkomplexität hindeutet
-
Modellauswahl
- Das Basismodell aller Agenten ist das GPT-5 reasoning model
- Auswahlkriterien waren die Popularität und Aktualität des Modells, seine Eignung für agentische Use Cases und seine starke Reasoning-Fähigkeit im Einklang mit den Erwartungen an autonome Agenten
- Die in den Experimenten verwendete Modellversion ist
gpt-5-2025-08-07 - Der Parameter
temperaturewird von diesem Modell nicht unterstützt, daher wurde der Standardwert1.0verwendet - Das Kontextfenster beträgt 400.000 Tokens, die maximale Zahl an Output-Tokens 128.000 Tokens
- Der Knowledge Cutoff liegt beim 30. September 2024
-
Analyse-Pipeline
- In der Phase der Tracesammlung wurde ChatDev instrumentiert, um die vollständigen Ausführungsspuren aller 30 Aufgaben als Logs aufzuzeichnen
- Erfasst wurden Prompt, Antwort sowie die Zahl der Input-, Output- und Reasoning-Tokens für jeden LLM-Aufruf
- Die Phasenzuordnung ist die zentrale Methodik, bei der interne Framework-Schritte von ChatDev in allgemeine Entwicklungsphasen übersetzt werden
- Diese Abstraktion ermöglicht eine verallgemeinerbare Analyse und lässt sich auf andere LLM-MA-Frameworks für Software Engineering ausweiten
- Die Tokenaggregation wurde mit Python-Skripten durchgeführt
- Die gesammelten Traces wurden geparst und die Tokenzahlen über alle 30 Ausführungen hinweg nach Entwicklungsphase aufsummiert
- Die Auswertung wurde nach Input-, Output- und Reasoning-Tokens aufgeschlüsselt
-
Zuordnung interner ChatDev-Schritte zu Entwicklungsphasen
- Die Designphase entspricht
DemandAnalysisundLanguageChooseund fokussiert das Verständnis der Anforderungen sowie technische Entscheidungen auf hoher Ebene - Die Coding-Phase entspricht
Codingund ist direkt an der Erstellung des initialen Source Codes beteiligt - Die Code-Completion-Phase entspricht
CodeCompleteund vervollständigt Platzhalter oder unvollständige Code-Dateien, die in der Coding-Phase zurückgeblieben sind - Die Code-Review-Phase entspricht
CodeReviewund umfasst die iterative Unterhaltung zwischen Programmierer-Agent und Code-Reviewer-Agent zur Prüfung, Korrektur und Verbesserung des Codes - Die Testphase entspricht
Testund konzentriert sich auf dynamische Systemtests, um ausführbarkeitsbezogene Bugs zu finden und zu beheben - Die Dokumentationsphase entspricht
EnvironmentDoc,ReflectionundManualund erzeugt Benutzerdokumentation sowie notwendige Umgebungs- und Abhängigkeitsdokumentation
- Die Designphase entspricht
Studienergebnisse und Diskussion
-
Forschungsfrage
- Die zentrale Frage betrifft die Muster des Tokenverbrauchs von LLM-MA-Systemen bei Softwareentwicklungsaufgaben
- Das Verständnis der Tokenomics agentischer Software-Engineering-Systeme ist wichtig für eine praktikable und nachhaltige Einführung
- Hoher Tokenverbrauch steht in direktem Zusammenhang mit höheren finanziellen Kosten, höherem Energieverbrauch und größeren Umweltauswirkungen
- Wenn identifiziert wird, wo im SDLC Tokens verbraucht werden, lässt sich eine „Kostenlandkarte“ erstellen, die für Kostenprognosen und Workflow-Optimierung nutzbar ist
- Die Analyse erfolgt entlang zweier Achsen
- der Verteilung der Gesamttokens auf die zugeordneten Entwicklungsphasen wie Design und Coding
- der Anteile von Input-, Output- und Reasoning-Tokens innerhalb jeder Phase
-
Befund 1: Die Code-Review-Phase dominiert den Tokenverbrauch
- Der Tokenverbrauch über den gesamten Entwicklungsprozess hinweg ist sehr ungleich verteilt
- Die Code-Review-Phase verbraucht im Durchschnitt über alle 30 Aufgaben 59,4 % der Tokens und ist damit der größte Verbrauchsabschnitt
- Die Code-Completion-Phase trat bei 6 von 30 Aufgaben auf und verbrauchte in diesen Ausführungen im Mittel 26,8 % der Tokens
- Die Dokumentationsphase verbraucht im Mittel 20,1 %, die Testphase 10,3 % der Tokens
- Die Testphase trat bei 12 von 30 Aufgaben auf
- Das anfängliche Coding liegt mit durchschnittlich 8,6 %, das Design mit 2,4 % auf vergleichsweise niedrigem Kostenniveau
- Die Hauptkosten des agentischen Software Engineerings konzentrieren sich eher auf iterative, dialogische Verbesserungs- und Verifikationsprozesse als auf die anfängliche Codegenerierung
- Der
n-Wert in der Abbildung bezeichnet die Zahl der Aufgaben unter den 30, bei denen die jeweilige Phase ausgeführt wurde - Nicht alle Phasen werden immer ausgeführt; Agenten im Multi-Agenten-System entscheiden autonom, welche Phasen sie ausführen
- Fehlerbalken entsprechen ±1 Standardabweichung und zeigen die Variabilität des Tokenverbrauchs je Phase
-
Befund 2: Der Tokenverbrauch ist inputzentriert
- In allen Phasen außer der Coding-Phase übersteigen Input-Tokens Output- und Reasoning-Tokens deutlich
- Die durchschnittliche Gesamtzusammensetzung des Tokenverbrauchs pro Aufgabe liegt bei 53,9 % Input, 24,4 % Output und 21,6 % Reasoning
- Das ungefähr 2:1-Verhältnis von Input- zu Output-Tokens liefert starke empirische Evidenz für die in früheren Arbeiten beschriebene „communication tax“
- Agenten verbrauchen Tokens, indem sie in kollaborativen Dialogen wiederholt große Kontexte weitergeben
- In heutigen Protokollen der Agentenkollaboration besteht Ineffizienz, weil mehr Tokens für Kontextweitergabe als für die Erzeugung neuer Outputs aufgewendet werden
- Die communication tax könnte eine inhärente Eigenschaft dialogischer Multi-Agenten-Architekturen sein und ist ein Thema für weitere Forschung
-
Befund 3: Unterschiedliche tokenomic profiles je Entwicklungsphase
- Die Tokenanteile pro Phase bilden je nach Software-Engineering-Aktivität eigene Muster
- Die Coding-Phase ist eine outputzentrierte Ausnahme mit 58,0 % Output und 6,9 % Input
- Diese outputzentrierte Struktur der Coding-Phase entspricht der Natur der Aufgabe, aus kompakten Design-Spezifikationen umfangreichen Source Code zu erzeugen
- Verifikations- und Dokumentationsphasen wie Code Review und Dokumentation sind inputzentriert
- Der Input-Anteil im Code Review beträgt 51,4 %
- Der Input-Anteil in der Dokumentation beträgt 80,2 %
- Diese Phasen konsumieren bestehenden Code als großen Kontext und erzeugen kleinere analytische Outputs
- Die phasenspezifischen Tokenprofile können als Kostenlandkarte für unterschiedliche Engineering-Aktivitäten dienen
- Praktiker können damit Kosten besser prognostizieren und Optimierungspotenziale im Prozess identifizieren
-
Tokenanteile nach Phase
- Die durchschnittlichen Anteile in der Designphase liegen bei 60,4 % Input, 3,6 % Output und 36,0 % Reasoning
- Die durchschnittlichen Anteile in der Coding-Phase liegen bei 6,9 % Input, 58,0 % Output und 35,1 % Reasoning
- Die durchschnittlichen Anteile in der Code-Completion-Phase liegen bei 47,7 % Input, 41,7 % Output und 10,5 % Reasoning
- Die durchschnittlichen Anteile in der Code-Review-Phase liegen bei 51,4 % Input, 24,7 % Output und 23,9 % Reasoning
- Die durchschnittlichen Anteile in der Testphase liegen bei 60,8 % Input, 20,7 % Output und 18,4 % Reasoning
- Die durchschnittlichen Anteile in der Dokumentationsphase liegen bei 80,2 % Input, 8,3 % Output und 11,5 % Reasoning
- Die durchschnittlichen Gesamtanteile pro Aufgabe liegen bei 53,9 % Input, 24,4 % Output und 21,6 % Reasoning
-
Diskussion
- Die vorläufigen Ergebnisse liefern eine erste Kostenlandkarte für agentische Softwareentwicklung
- Die hohen Tokenkosten der Code-Review-Phase lassen sich als „Gesprächskosten“ interpretieren
- Diese Kosten entstehen direkt aus der dialogischen Architektur von LLM-MA-Systemen, in der Agenten wiederholt den vollständigen Code-Kontext austauschen, um den Code zu verbessern
- Aktuelle Kollaborationsprotokolle für Verifikation sind sehr ineffizient, da sie selbst für Aufgaben mit kleinen Änderungen enorme Ressourcen verbrauchen können
- Dies steht im Einklang mit den Befunden der MAST-Klassifikation zu Verifikationsfehlern und Phasenwiederholungen
- Hoher Tokenverbrauch könnte ein Symptom dafür sein, dass Agentensysteme inhärente Koordinationsprobleme durch erzwungene Dialoge zu überwinden versuchen
- Praktiker können die Kosten agentenbasierter Projekte je nach erforderlichem Aufgabentyp abschätzen
- Greenfield-Projekte mit hohem Anteil anfänglichen Codings und Projekte, die sich auf Refactoring und Debugging bestehenden Codes konzentrieren, haben unterschiedliche Kostenstrukturen
- Bei Projekten mit Fokus auf Refactoring und Debugging bestehenden Codes dominieren teure und inputzentrierte Code-Review-Zyklen die Kosten
- Die Integration eines „human-in-the-loop“-Checkpoints vor der Code-Review-Phase kann als Designentscheidung dienen, um kostspielige iterative Schleifen zu vermeiden und die wirtschaftliche wie rechnerische Effizienz zu erhöhen
- Eine Forschungsaufgabe ist die Entwicklung tokeneffizienterer Kollaborationsprotokolle für Verifikation und Verbesserung
- Erforderlich sind Ansätze, die über die bloße Weitergabe des gesamten Kontexts hinausgehen
- Zudem wird ein standardisiertes und umfassendes Evaluierungs-Framework benötigt
- Dieses Framework kann als gemeinsame Grundlage dienen, um die Effizienz unterschiedlicher LLM-MA-Architekturen wie den hierarchischen dialogischen Workflow von ChatDev und die SOP-basierte Assembly-Line von MetaGPT zu benchmarken und zu vergleichen
- Es kann als „Rosetta Stone“ fungieren, der frameworkspezifisches Verhalten in allgemeine Software-Engineering-Aktivitäten übersetzt
Bedrohungen der Validität und künftige Aufgaben
-
Bedrohungen der Validität
- Die Analyse basiert auf einem einzelnen LLM-MA-System, ChatDev, und einem einzelnen LLM, dem GPT-5 Reasoning Model
- Die beobachteten Muster des Tokenverbrauchs können bei anderen LLM-MA-Architekturen oder LLMs mit anderer Tokeneffizienz abweichen
- Die 30 Softwareentwicklungsaufgaben sind vielfältig, repräsentieren aber möglicherweise nicht alle denkbaren Softwareentwicklungsszenarien und Komplexitätsgrade
- Der Umfang des kuratierten Datensatzes ergibt sich direkt aus dem Mangel an öffentlich verfügbaren großskaligen Benchmarks für Traces spezialisierter Software-Engineering-Agenten
- Die Kuratierung der Daten ist zeit- und kostenintensiv
- Einige Entwicklungsphasen wurden nur in einer kleinen Teilmenge der 30 Aufgaben ausgeführt
- Code Completion wurde mit
n=6, Testen mitn=12nur selten ausgelöst - Schlussfolgerungen zu den tokenomic profiles dieser spezifischen Phasen beruhen daher auf kleinen Stichproben, könnten wenig repräsentativ sein und nur eingeschränkt verallgemeinert werden
- Die Zuordnung interner ChatDev-Schritte zu Softwareentwicklungsphasen ist eine Abstraktion
- Sie ist eine logische und nützliche Zuordnung für den Aufbau eines standardisierten Evaluierungs-Frameworks, aber nur eine von mehreren möglichen Arten, Agentenaktivitäten abzubilden
-
Fazit und künftige Aufgaben
- Im agentischen Software Engineering sind die Tokenkosten nicht gleichmäßig verteilt, sondern stark auf die iterative und dialogische Code-Review-Phase konzentriert
- Input-Tokens, die die „communication tax“ ausmachen, stellen den größten Teil des gesamten Tokenverbrauchs und sind damit ein zentrales Feld für künftige Optimierung
- Eine erste Aufgabe künftiger Arbeiten ist die Erweiterung des Datensatzes um mehr Aufgaben, um die Generalisierbarkeit zu verbessern
- Eine zweite Aufgabe ist die Ausweitung der Analyse auf andere LLMs, um modellspezifische Effekte zu verstehen
- Eine dritte Aufgabe ist die Ausweitung der Analyse auf andere LLM-MA-Systeme, um zu vergleichen, wie sich architektonische Unterschiede auf die Tokenomics auswirken
- Eine vierte Aufgabe ist die Untersuchung des Zusammenhangs zwischen Mustern des Tokenverbrauchs und Fehlermodi
- Eine fünfte Aufgabe ist die weitere Entwicklung und Validierung eines robusten und universellen Frameworks zur Zuordnung von Entwicklungsphasen für das Effizienz-Benchmarking von Software-Engineering-Agenten
1 Kommentare
Hacker-News-Kommentare
Ich habe mir für den privaten Gebrauch ein Multi-Agenten-System gebaut und nutze es regelmäßig.
Wenn ich ein Problem eingebe, stellt zunächst ein schnelles und günstiges Modell Fragen und verfeinert auf Basis der Antworten den Eingabe-Prompt.
Danach wird das Problem in Abschnitte aufgeteilt, und ich wähle eine Strategie, bei der entweder ein finaler Schiedsrichter die Schlussfolgerung zieht oder mehrere Agenten diskutieren und der Schiedsrichter anschließend zusammenfasst.
Die beste Methode ist für mich das, was ich all angles nenne: mehrere Strategien parallel laufen lassen und ein abschließender Meta-Schiedsrichter fasst die Antworten zusammen.
Der nützlichste Teil unter den jüngsten Ergänzungen ist eine Ansicht, in der man die Abweichungen zwischen den einzelnen Strategien sehen kann.
Ich nutze es für Alltagsthemen wie Wohnungssuche, Schule und Familienfragen.
Ich würde auch gern wissen, welche Strategien du verwendest und wie sich die Kosten je nach Strategie unterscheiden.
Eher im Sinne der Kybernetik: Ich erweitere fortlaufend eine Bibliothek aus deterministischen Prüfungen und automatischen Korrekturen, um die Stabilität der Prompt-Ausgaben zu erhalten.
„Probleme“, die diese Bibliothek nicht abdecken kann, werden für die Person sichtbar, die den Prozess steuert.
Einen Monat lang habe ich GitHub Copilot ohne Unterbrechung intensiv genutzt, aber nach der Preisänderung waren meine Token im darauffolgenden Monat schon nach zwei Tagen aufgebraucht.
So eine abrupte Veränderung wirkt für mich wie ein Zeichen dafür, dass die Token-Preise willkürlich sind und dem AI-Geschäft schnell das Geld ausgeht.
Es gibt sogar Gerüchte über eine Marge von über 70 % bei Inferenz.
Bei SpaceX zum Beispiel sind in den letzten sechs Monaten die Preise für Verbraucherprodukte insgesamt gestiegen, aber Alphabet und Anthropic zahlen zusammen monatlich über 2 Milliarden Dollar, also fehlt es nicht an Geld.
Microsoft/GitHub hat hier eher verloren, weil sie in der Position waren, das Produkt eines anderen nur neu zu verpacken.
Im Allgemeinen werden Preise auf Basis verschiedener zugrunde liegender Faktoren festgelegt; das bedeutet nicht, dass sie per se willkürlich wären.
Wenn GitHub-Manager die Token-Preise mit einem Zufallszahlengenerator festgelegt hätten, dann wäre das willkürliche Preisgestaltung.
Dort steht, „Eingabetoken machen mit durchschnittlich 53,9 % den größten Anteil am Verbrauch aus“, aber bei meiner Nutzung liegt das Verhältnis eher bei ungefähr 10:1.
Der überwältigende Großteil der verbrauchten Token entfällt auf die Eingabeseite, und es kommt oft vor, dass ein Agent eine Million Token liest, um eine einzige Zeile Code zu ändern.
Wenn es eher bei 1:1 liegt oder die Ausgabeseite größer ist, würde ich vermuten, dass mit dem Agenten etwas nicht stimmt oder dass die Codebasis neu oder leer ist.
Eine Million nicht gecachte Token wirkt ziemlich viel.
Man könnte das Modell einen einmaligen „Komprimierungs“-Schritt ausführen lassen, bei dem die relevanten Teile des Codes ausgegeben werden, und dieses Ergebnis dann als gecachtes Präfix für viele nachgelagerte Agentenaufrufe verwenden.
Wenn man Agenten fürs Programmieren einsetzt, wollen sie offenbar Unit-Tests zu Tausenden schreiben, haben aber wenig Neigung, dynamisch zu testen.
Statische Tests sind Dinge wie Linting oder Typprüfungen.
Wenn du neben Unit-Tests andere Arten dynamischer Tests willst, würde mich interessieren, ob du das bereits in der Planungs- oder PRD-Phase als Anforderung festgelegt hast.
Deren Interessen stimmen nicht immer mit deinen überein.
In diesem Fall wollen sie dich dazu bringen, unnötig Geld für nutzlose Arbeit auszugeben.
Mit diesem Euphemismus „Token“ sollte man vielleicht auch langsam aufhören.
Ich glaube, ein Grund dafür, dass dynamische Tests etwas gemieden werden, ist, dass sie langsamer machen und die Software an unerwarteten Stellen stoppen können.
Das erinnerte mich an eine Arbeit vom letzten Jahr, die Budget-Hinweise bereitgestellt hat, um die Effizienz der Tokennutzung zu optimieren.
[1] https://scholar.google.com/scholar?hl=en&as_sdt=0%2C5&q=Stee...
Das ist ähnlich wie Vielfliegermeilen von Fluggesellschaften und hat aus Unternehmenssicht keinen Vorteil gegenüber dem Mieten von Bare-Metal-GPU-Zeit.
Sobald sich der Großteil der AI-Nachfrage mit On-Premises- oder On-Device-Hardware und -Modellen decken lässt, frage ich mich, wofür diese riesigen Rechenfarmen und Modelle mit ihren Betriebskosten dann noch gut sein sollen.
Wahrscheinlich bleiben nur große Regierungen als Kunden übrig, und am Ende werden die Steuerzahler für die zig Milliarden Dollar aufkommen, die das AI-Kartell investiert hat.
Ich habe im Dezember einen Substack-Beitrag zu diesem Thema geschrieben: https://open.substack.com/pub/zacharywhitley/p/the-coming-ag...
Früher haben Firmen wie Google Ingenieure danach eingestellt, wie gut sie Infrastruktur optimieren konnten.
Vielleicht schauen Unternehmen bald darauf, wie gut Ingenieure die Effizienz von AI-Token optimieren können.
Ich bin nicht sicher, ob Entwickler genauso schnell neue Einsatzmöglichkeiten für mehr Token finden, wie die Preise sinken.
Man behandelt Token wie Nebenkosten fürs Internet und lässt die Ingenieure sie einfach selbst bezahlen.
Als interessante Randnotiz: Ich war in einer Besprechung zur Prüfung eines neuen Produktkandidaten. Alles lief gut, bis ein Bildschirm auftauchte, der zeigte, dass dem Produkt AI hinzugefügt worden war.
Natürlich hatte es AI, und es wirkte sehr offensichtlich hineingezwungen.
Ein Hinweis darauf war eine Spalte, die zeigte, wie viele Token jede Anfrage gekostet hatte.
Ich fragte, wer die Token-Kosten bezahlt, und man sagte mir, sie seien in der Lizenz enthalten. Dann fragte ich, ob es eine Budgetgrenze gebe oder ob es unbegrenzt sei, und man sagte, das sei eine gute Frage und man werde nachsehen.
Ich hatte gefragt, weil gerade eine einzige einfache gerätebezogene Anfrage, die man uns gezeigt hatte, 250.000 Token verbrannt hatte.
In dem Moment hörte man einen der Führungskräfte auf der Gegenseite laut sagen: „Warum zeigen wir den Kunden das eigentlich?“
Wir mussten ziemlich lachen.
Meine Lehre daraus ist, dass die Kosten dafür, AI überall einzubauen, nicht sauber kalkuliert werden und die tatsächlichen Kosten des AI-Betriebs erst recht nicht.
Alles, dem AI hinzugefügt wird, wird teurer werden, ob man es will oder nicht.
Tokenomics ist doch bereits ein Begriff zur Beschreibung der Ökonomie von Kryptowährungen; ich verstehe nicht, warum man ihn unbedingt für Token in der AI neu definieren will, auch wenn es sich um eine andere Art von Token handelt.
Vergiss die alten Trends, auch dieser wird bald veraltet sein, also sollte man aufspringen, bevor es zu spät ist.
„Web 3.0“ existierte ebenfalls schon, bevor Krypto-Leute Web3 krypto-zentriert gemacht haben.
Daher verstehe ich nicht, wo das Problem sein soll.
Begriffe werden in unterschiedlichen Kontexten ständig wiederverwendet.
Außerdem sind die meisten ohnehin schon von Krypto weitergezogen, also ist das Potenzial für Verwirrung wohl nicht besonders groß.