If you serve an LLM to Indian-language users, your GPU bill has a hidden multiplier. I measured it instead of quoting it.

The measurement

I took the 1,012 FLORES devtest sentences, tokenized each language and its English counterpart with the Qwen3 tokenizer, and compared the median per-sentence token count:

Language Tokens vs the same English sentence
Hindi 4.44x
Malayalam 7.27x

Per word it is starker: Malayalam averages 13.47 tokens per word against 1.27 for English.

More tokens means a bigger KV-cache per user, which means fewer users per GPU. Same model, same hardware, a fraction of the concurrency, for a user who typed one sentence.

It depends heavily on the tokenizer

Same Hindi sentence, different tokenizers:

  • Qwen3 / Qwen2.5: 4.44x
  • Sarvam-M: 1.79x
  • Gemma-3: 1.31x

So "Indic text is expensive" is only half true. Which model you pick can matter more than any serving trick.

Romanizing is not a free fix

The obvious workaround is to write Hindi in Latin script. On Qwen3 that does help: 2.06x against 4.44x. On Gemma-3 it makes things worse: 1.85x against 1.31x. My transliteration scheme (ITRANS) keeps schwas and spells loanwords phonetically, so it is not natural Hinglish. I flag that in the ledger and treat this as a limit, not a result about real chat text.

Checking myself first

Before trusting my own numbers I reproduced the published table from "The Tokenizer Tax" (arXiv 2607.24276): 66 of 66 cells within 0.5%. Mean tax under cl100k_base comes out at 8.03x against the paper's 8.0x, and under o200k_base at 2.14x against 2.1x. I also checked token counts against a second independent implementation of each tokenizer: 44 of 44 model-by-language rows with zero mismatches.

I also found that many FLORES sentences are not Unicode NFC-normalized (609 of 1,012 in Bengali, 573 in Punjabi, 93 in Hindi), which changes token counts if you do not normalize first.

What I have not measured yet

The GPU half: how much FP8 KV-cache wins back on AMD MI300X. That run is pending, so there are no GPU numbers here. The repo keeps a claims ledger in which every number points to a result file and a commit, and a number with no row does not get published.

Repo: https://github.com/Lingikaushikreddy/indic-kv-tax

Which Indian-language workload are you serving, and which tokenizer are you paying for?