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?
