Standpunt: LLM-inferentie moet worden geëvalueerd als energie-naar-tokenproductie.
Position: LLM Inference Should Be Evaluated as Energy-to-Token Production
May 12, 2026
Auteurs: Xiang Liu, Shimiao Yuan, Zhenheng Tang, Peijie Dong, Kaiyong Zhao, Qiang Wang, Bo Li, Xiaowen Chu
cs.AI
Samenvatting
LLM-inferentie wordt nog steeds voornamelijk geëvalueerd als een model- of softwareprobleem: nauwkeurigheid, latentie, doorvoer en hardwarebenutting. Dit is onvolledig. Op implementatieschaal is de relevante output een kwaliteitsafhankelijke token die wordt geproduceerd onder gezamenlijke beperkingen van effectieve rekenkracht, geleverd datacentervermogen, koelcapaciteit, PUE en benutting.
Wij stellen dat de ML-gemeenschap inferentie moet beschouwen als energie-naar-token-productie. We formaliseren deze visie met een dimensioneel consistente Tokenproductiefunctie waarin de tokensnelheid wordt begrensd door zowel een rekenkracht-per-token- als een energie-per-token-plafond. Vermelde API-prijzen variëren met meer dan een grootteorde tussen aanbieders, maar we gebruiken prijsspreiding slechts als richtinggevende motivatie, niet als causaal bewijs van marginale kosten. De kernvraag is in plaats daarvan fysisch van aard: onder vaste kwaliteits- en servicedoelen, wanneer verschuift de bindende beperking van theoretische piekrekenkracht naar geleverd vermogen, koeling en operationele efficiëntie?
In dit kader zijn systeemoptimalisaties – latente KV-cachecompressie, sparse of zwaar gecomprimeerde aandacht, kwantisatie, routering en moeilijkheidsadaptieve redenering – niet louter lokale technische trucs. Het zijn hefbomen voor energie-naar-token omdat ze FLOPs/token, joules/token, geheugenverkeer of benuttingsverliezen verminderen onder vaste (q*, s*). Daarom pleiten we ervoor dat inferentiepapers en benchmarks Joules/token, actieve bindende beperking, PUE-gecorrigeerd geleverd vermogen en benuttingsgecorrigeerde tokenoutput rapporteren naast nauwkeurigheid en latentie.
English
LLM inference is still evaluated mainly as a model or software problem: accuracy, latency, throughput, and hardware utilization. This is incomplete. At deployment scale, the relevant output is a quality-conditioned token produced under joint constraints from effective compute, delivered data-center power, cooling capacity, PUE, and utilization.
We argue that the ML community should treat inference as energy-to-token production. We formalize this view with a dimensionally consistent Token Production Function in which token rate is bounded by both compute-per-token and energy-per-token ceilings. Listed API prices vary by over an order of magnitude across providers, but we use price dispersion only as directional motivation, not as causal evidence of marginal cost. The core physical question is instead: under fixed quality and service targets, when does the binding constraint move from theoretical peak compute toward delivered power, cooling, and operational efficiency?
Under this framing, system optimizations -- latent KV-cache compression, sparse or heavily compressed attention, quantization, routing, and difficulty-adaptive reasoning -- are not merely local engineering tricks. They are energy-to-token levers because they reduce FLOPs/token, joules/token, memory traffic, or utilization losses under fixed (q^{*},s^{*}). We therefore call for inference papers and benchmarks to report Joules/token, active binding constraint, PUE-adjusted delivered power, and utilization-adjusted token output alongside accuracy and latency.