印度語言的 Token 稅：Sarvam 把 Tokenizer 當產品在做

下次你替中文或其他非英語產品估 API 帳單，先把真實內容丟進 Tokenizer 數一次再報預算，可以少踩一個坑。這份 arXiv 研究把原因攤得很清楚。 研究團隊比了九款公開 Tokenizer，包括 GPT-4、GPT-4o、Qwen2.5、DeepSeek-V3、Mistral-Nemo 和 Sarvam，測試對象是印度 25 種語言。商業 API 按 Token 計費，同一段意思的內容，在某些 Tokenizer 下會被切成更多塊。結果有兩個後果：帳單變高，上下文窗口也被吃掉更多。GPT-4o 對 Santali 這類語言，Token 倍數高到 13.7 倍。換句話說，同樣一段話，用 Santali 寫要付十幾倍的錢，還只能塞進更短的對話。 這像計程車跳表：同樣直線距離，你住的地方路網沒被地圖收錄，就得繞遠路，錢照跳。 這裡最有產品思維價值的是 Sarvam。研究指出它的 Tokenizer 在多語言效率上表現比較均衡，沒有哪個語言特別吃虧。Sarvam 做對的事不是模型多聰明，而是先處理了最底層、最少人看的一環：使用者每天用的語言，到底被切成幾塊。Tokenizer 在多數團隊眼裡是模型附帶的零件，在它那裡成了影響成本、延遲、可用上下文的產品決策。 我們能拿走兩件事。第一，做多語言產品時，成本模型不能拿英文測試集推算。你的使用者寫繁體中文、夾雜日文片語、貼程式碼，就用那種資料實測。第二，選模型時把 Token 效率和單價放在同一張表比，因為每百萬 Token 便宜的模型，不一定讓你的內容整體比較便宜。 研究沒有說所有模型都該換掉 Tokenizer，也沒有給出中文的完整數字，所以不用急著下結論。但這個測法很便宜：挑一百筆真實使用者輸入，分別用幾家的 Tokenizer 數一遍，半天就有答案。 接下來多語言市場的競爭，很可能有一段是在比誰切得更省。