English is the cheapest language to serve and Pashto the most expensive, according to an author-reported preprint that measured LLM inference energy per language: up to 8.3x more energy per output token across languages, and 179x more total energy for a fixed request set. For teams running multilingual products, that spread turns locale mix from a product detail into a capacity-planning and pricing variable.
All quantitative findings in this article come from a single research group and have no independent replication as of 2026-09-16. They are labeled author-reported where they appear.
The measured divide: 8.3x per token, 179x per request set
The paper, “The Language-Energy Divide: Measuring Energy Costs of Multilingual LLM Inference” (arXiv:2606.21869), reports that energy consumption per output token varies by up to 8.3 times across languages. That is the smaller of its two headline numbers, and conflating the two would understate the problem. Total energy for a fixed set of requests varies by up to 179 times, from 17.6 kJ for English to 3,147 kJ for Pashto, per the abstract (both author-reported, single-group measurements).
The gap between 8.3x and 179x is itself the finding. If per-token cost were the whole story, total energy would track per-token energy. It does not. The total figure compounds two effects: some languages pay more per token, and some languages require more tokens to say the same thing. The paper’s phrase “a fixed set of requests” reads as task-equivalent requests, not token-matched ones, which is how a real serving bill behaves. A user asking a question in Pashto and a user asking the same question in English generate the same business value and, in this measurement, wildly different energy draw.
The record behind the numbers is recent. First author Naihao Deng submitted v1 on 2026-06-20, and v2 landed on 2026-09-14 with the arXiv comments field reporting “Accepted to EMNLP 2026 Main,” per the paper’s arXiv page. A bare “arXiv:2606.21869” citation resolves to whichever version is latest, so anyone quoting the kJ figures should cite v2 explicitly; arXiv identifiers encode version numbers and later revisions could change the values.
Why the costs compound
The paper attributes the divide to two factors that multiply rather than add, per the abstract:
- Script-dependent per-token energy. Languages using complex or rare scripts cost more energy per token generated. The mechanism plausibly runs through tokenization and vocabulary coverage: scripts underrepresented in training data tend to fragment into longer token sequences and land on less-optimized regions of the model’s computation, though the abstract itself states the pattern without detailing the internal cause.
- Token inflation for low-resource languages. The model generates more tokens for low-resource languages to complete the same task. This is a well-known tokenizer pathology in a new costume: the same semantic content takes more tokens in a language the tokenizer handles poorly, and every extra token is extra energy.
Multiplication is what makes this operationally uncomfortable. The per-token factor tops out at 8.3x, and only compounding with token inflation reaches the 179x author-reported spread at the request level. Any mitigation that attacks only one factor, say a better tokenizer that cuts token inflation, still leaves the per-token cost of rare scripts untouched.
The double penalty: expensive to serve, worst at the task
The third finding should change how product teams read the first two. The authors report that languages with the highest energy footprints also tend to achieve the lowest task accuracy, per the abstract. They call it a “double cost + performance penalty.”
In serving terms, the locales that cost the most to run are the ones delivering the weakest output. A naive response would be to treat those locales as loss leaders or quietly degrade them. The finding points the other way: if high energy and low accuracy share a root cause, namely weak representation of those languages in training data and tokenizer vocabularies, then the energy line item is a measurable proxy for a quality problem that was already there. An ops team watching per-locale energy draw may be looking at an early-warning dashboard for model quality, not just a cost anomaly.
This coupling also complicates benchmarking practice. A model evaluated only in English reports its cheapest, best-performing configuration. Its P&L and its quality in Dhaka or Kabul can look nothing like the benchmark sheet. Groundy has covered a version of this pattern in Kimi’s published pricing structure, where cache-hit rates and thinking-token counts, not headline benchmark scores, dominated effective serving cost; per-language overhead is the same class of variable that headline evals miss.
Translating ratios into serving decisions
The abstract recommends “deployment-side mitigations” without naming specific ones, per the paper’s arXiv page. What follows is a translation of the measured ratios into decisions serving teams already make; these are inferences from the findings, not recommendations the paper spells out.
| Decision | What the divide changes | First move |
|---|---|---|
| Pricing tiers by locale | A fixed per-token price overcharges cheap locales and undercharges expensive ones relative to energy cost | Model per-locale token inflation on your own traffic before setting tier differentials |
| Caching priorities | High-inflation locales burn more tokens per equivalent request, so prefix and response caching repay faster there | Rank cache investment by locale-level tokens-per-request, not request volume |
| Tokenizer selection | Script-dependent per-token cost is partly a tokenizer artifact | Benchmark candidate tokenizers on your actual locale mix, not English-dominant corpora |
| Model routing | A small model that handles a low-resource language badly may cost more energy than a large model that handles it well | Route by measured energy-per-successful-task per locale, not by request count |
The routing row deserves emphasis because it inverts a common instinct. Teams often route low-volume locales to smaller models to save money. If low-resource languages trigger token inflation and lower accuracy on the small model, the small model can end up more expensive per completed task than the large one. That is a testable hypothesis on any given stack, and the paper’s two-factor mechanism is exactly what such a test should measure: tokens generated per request, and energy per token, broken out by language.
The broader commercial stakes are real even if the exact figures are study-specific. Multilingual markets are not a niche: a Swiss study cited on Wikipedia attributes roughly 10% of Switzerland’s GDP to multilingualism, and the language industry is developing an emerging practice it calls “LangOps” for managing language as a company function, one MultiLingual Computing covers even as it asks whether LangOps is a “pipe dream” or “just a new hashtag.” Energy cost per language is the kind of input that practice has not previously had for LLM serving.
What transfers across stacks, and what stays study-specific
The paper claims the divide “persists across models, hardware, and tasks,” and characterizes it as systemic, per the abstract. If that claim holds, the direction and rough ordering of the gap (English cheap, complex-script and low-resource languages expensive) should reproduce on other serving stacks.
The absolute numbers almost certainly do not transfer. The 17.6 kJ and 3,147 kJ figures come from models and hardware the abstract never names, measured with a framework cited as Chung et al., 2026, whose name is elided in the cleaned abstract text and would need to be confirmed from the PDF. Absolute energy-per-request depends on GPU generation, batch size, serving framework, and datacenter power overhead, none of which are visible here. Even the tested language list is not enumerable from the abstract alone, so “Pashto is the most expensive” describes this study’s language set, not a universal ranking.
The safe way to quote the study, on the evidence available, is the ratios: 8.3x per output token, 179x per fixed request set, English cheapest and Pashto most expensive within the tested set. The unsafe way is to plug 3,147 kJ into a production cost model.
How solid is the evidence, really?
This is where the article owes the reader precision rather than a ritual caveat, because the obvious dismissal (“unreviewed preprint”) is wrong in both directions.
Start with what arXiv hosting means. arXiv’s own about page states that material is not peer-reviewed by arXiv and that submissions are wholly the responsibility of the submitter, presented “as is.” Its submission guidelines describe moderation that “verifies material is appropriate and topical.” Nothing in that pipeline checks whether an energy measurement was done correctly.
But the record does not stop at the preprint. The comments field reports acceptance to EMNLP 2026 Main, which means the paper survived conference peer review. Acceptance is review, not replication: reviewers judge method and plausibility, they do not re-run measurements on independent hardware. The paper’s authors recommend treating energy as a first-class evaluation axis and extending reporting checklists and model cards to include it, per the abstract, which is itself an admission that current practice, including presumably most of the field’s multilingual benchmarks, ignores the variable entirely.
What the evidence cannot settle, as of 2026-09-16:
- Whether the 8.3x and 179x ratios hold on other models, tokenizers, and hardware. The paper claims persistence across all three; no third party has tested that claim.
- Which specific models, languages, and hardware produced the numbers. The abstract does not name them.
- Whether the framework (Chung et al., 2026) measures energy comparably to the tools serving teams actually use.
- Whether the energy-accuracy coupling is causal or correlational, and whether fixing tokenization fixes both.
The fetched record contains no independent coverage or replication of the paper at all, so the competitive and scientific field around these numbers is genuinely unknown rather than merely quiet.
The practical verdict
Treat language mix as a capacity-planning input now, and treat the absolute numbers as provisional. The author-reported findings support three working conclusions: per-output-token energy varies by up to 8.3x across languages, total request-set energy varies by up to 179x because per-token cost and token inflation compound, and the expensive languages tend to be the ones where the model performs worst. For a team serving global traffic, those conclusions justify measuring tokens-per-request and energy-per-token per locale before setting pricing tiers, prioritizing caches, or routing low-resource languages to smaller models.
The limitation is structural: every figure originates with one group, one measurement framework, and unnamed models and hardware. arXiv’s policy guarantees nothing about the measurements, and EMNLP acceptance supplies review rather than replication. Quote the relative divide; build your own measurements before quoting the kilojoules. If the paper’s persistence claim is right, your stack will show its own version of the same gap, and the only way to know your multipliers is to measure them.
Frequently Asked Questions
What are the specific energy costs for English and Pashto in the study?
Total energy for a fixed set of requests varies by up to 179 times, from 17.6 kJ for English to 3,147 kJ for Pashto, per the abstract (both author-reported, single-group measurements).
Why does total energy vary so much more than per-token energy?
The total figure compounds two effects: some languages pay more per token, and some languages require more tokens to say the same thing. The paper’s phrase “a fixed set of requests” reads as task-equivalent requests, not token-matched ones, which is how a real serving bill behaves.
Does the paper name the specific models and hardware used for the measurements?
The 17.6 kJ and 3,147 kJ figures come from models and hardware the abstract never names, measured with a framework cited as Chung et al., 2026, whose name is elided in the cleaned abstract text and would need to be confirmed from the PDF.
