同一句话中文贵两倍：词表里藏的语言税

你大概知道"换便宜模型能省钱"，知道"前缀缓存能省钱"，甚至知道"输出token比输入贵三倍"。但有一笔账，所有成本攻略都绕开了它——你的中文，本身就在被AI按"语言税"计价。同一句话、同一个意思，中文在主流英文优化词表里要花掉1.5到2.5倍的token，意味着你的API账单、embedding索引成本、上下文窗口占用，统统在为一个你不自知的因素多付钱。今天这一篇，把这笔税拆给你看，再给你三把刀把它砍掉。

一、什么是"语言税"，它凭什么藏在账单里

要理解语言税，先理解一个最基础却被99%用户忽略的事实：模型不是按"字"收费，是按"token"收费，而token和字之间不是一一对应。

token是大模型词表（vocabulary）里的一个基本单位。主流闭源模型（GPT系列、Claude、Gemini）的词表，本质上是字节对编码（BPE）训练出来的，而训练语料以英文为主。结果是：英文单词、英文词根被大量完整收录进词表，一个常见英文词往往就是1个token；而中文，因为训练时见得少，被拆得更碎，一个中文字经常要拆成1到3个token才能表示。

这就产生了"语言税"：同样表达一个意思，中文比英文消耗更多token，而计费是按token走的。 你以为你在为"内容"付费，其实你在为"词表对你语言的友好程度"付费。

举一个最直观的例子（你可以立刻去 platform.openai.com/tokenizer 验证）：

短短六个字，中文比英文多了快一倍的token。把这种差异放大到一篇10万字的文档、一个5000万字的知识库、一年的客服对话日志——你多付的不是几分钱，是成倍的账单。

二、实测：六个词表对同一批中文的"税单"

我把一段约1000字的中文技术文档，分别在几款主流词表上跑了一遍（数字为典型实测区间，你可自行在 tokenizer.gg 或各家tokenizer playground复核），换算成"每百字消耗token"这个统一标尺：

这张表就是信息差的核心。看清楚三件事：

第一，GPT-4o 的 o200k 词表是OpenAI专门为非英文做过的优化。 2024年GPT-4o发布时，OpenAI官方明确说过新词表对100多种非英文语言压缩率显著提升，中文token消耗相比cl100k直接砍掉近一半。所以至今还在用 GPT-4（cl100k）跑中文长文本的人，等于主动放弃了一半的token折扣。 很多人为了"质量"死守GPT-4，却没意识到光token密度这一项，GPT-4o就帮你省了约45%。

第二，国产模型的中文密度是真·物理碾压。 GLM、Qwen、DeepSeek的词表是为中文优化的，中文字基本能做到1字≈1token，密度和英文持平甚至更好。这意味着同样一份中文语料，喂给GLM的token数，只有喂给GPT-4的一半左右。

第三，Claude的中文密度介于两者之间，没有GPT-4那么离谱，但也不如国产模型友好。如果你重度用Claude处理中文，同样在默默交税。

三、三把刀：把语言税从账单上剔掉

理解了机制，下面是可立刻执行的三把刀。

刀一：中文任务，优先路由到中文原生模型

这是收益最大、改动最小的一刀。逻辑链是这样的：

中文输入 → 走英文优化词表 → token虚高 → 单价×虚高token = 双重多付
中文输入 → 走中文原生词表 → token压扁 → 更低单价×更少token = 双重省钱

国产模型不光单价更低（GLM/Qwen/DeepSeek的API价格普遍是Claude/GPT同档的几分之一到十分之一），词表还更省token，两个优势复乘，账单能差出5到10倍。

具体怎么操作：

1. 纯中文场景（中文写作、中文总结、中文客服、中文RAG问答）——直接把默认模型换成GLM-4.6/GLM-5系列或Qwen。这类任务国产模型质量完全够用，而token单价和密度双优。
2. 中英混合或强代码场景——可以保留前沿模型做"难题"，但用一层路由（router）把简单中文请求分流给国产模型。注意，这一刀和"别让顶配跑杂活"是不同的维度：那一刀讲的是任务难度路由，这一刀讲的是语言密度路由。一个简单的中文意图识别，不管多简单，丢给GPT-4都比丢给GLM贵，纯粹是因为词表在多收钱。
3. 长文档处理——这点最容易被忽略。10万字中文文档，GPT-4要吃掉约15–20万token，光输入就可能撑爆单次上下文，逼你切片、多次调用、重复付费。换GLM，同样文档约7–9万token，调用次数直接减半。

刀二：embedding也在交语言税，换BGE-M3或GLM embedding

这把刀隐藏得最深，因为大家盯着聊天token，却忘了向量数据库里的每一份文档，都是先过embedding再付费，而embedding同样按token计价，同样吃语言税。

算一笔真实的RAG索引账。假设你要给一个 5000万字 的中文知识库建向量索引：

看出来了吗？索引成本能从约12美元干到接近0美元，差出一个数量级。 这还只是一次性索引。如果你的知识库每周增量更新、每次检索还要re-rank、还有用户query的embedding开销——语言税会按月、按查询量持续复利。

更关键的是：BGE-M3是开源的、支持中文长文本、自带多语言和多粒度（dense+sparse+colbert）能力，自部署零token成本；走第三方API也极便宜。把embedding这一层从"OpenAI税"里挪出来，是RAG成本优化的最大单项杠杆。

注意一个常见误区：很多人为了省embedding钱，把中文文档先翻译成英文再embedding。这是反向操作——翻译本身要花生成token钱（且往往用更贵的模型），还损失语义精度。正确做法是直接用中文友好的embedding模型，省掉翻译这一步的双重开销。

刀三：别按"字数"切分，按"token"切分

第三把刀藏在工程实现里。几乎所有RAG教程都教你"按500字一段切分文档"——但500字中文和500字英文的token数差了一倍多。

如果你按字数切分，会出现两种隐性浪费：

• 超限浪费：500中文字在GPT-4词表里可能是800–1000token，叠加上下文prompt后轻松超限，触发截断或报错，被迫重切重算。
• 不均浪费：中文段落token密度高，同样的"500字"窗口，中文装的信息token更多，检索粒度变粗，召回质量下降，逼你做更多次检索、更多次重排——又是token在烧。

正确做法：

1. 切分单位从"字符数"改成"token数"，用各家的tokenizer库（OpenAI的tiktoken、智谱的tokenizer SDK）预先计数，每段控制在模型友好区间（如256/512token）。
2. 切分时考虑词表边界——不要把一个完整的中文词组从token中间切断，否则语义被拆碎，embedding质量下降，又要靠更多次检索弥补。
3. 不同模型用不同切片策略：同一个知识库，喂GLM的切片和喂GPT-4o的切片，token数应该一致但字符数不同。如果你用一套"500字"切片通吃所有模型，等于在国产模型上白白浪费了它词表密度的优势——你用同样的字符数，本可以塞进更多内容。

这把刀单独看不显眼，但它决定了刀一和刀二的收益能不能真正落袋：词表省下来的token，如果被粗糙的字数切分又浪费回去，整条优化链就断在这里。

flowchart TD
    A["中文任务请求"] --> B{"选哪条省钱路径?"}
    B -->|"中文原生模型<br/>GLM/Qwen/DeepSeek"| C["词表密度~1.0<br/>token直接压扁"]
    B -->|"英文优化词表<br/>GPT-4/Claude旧版"| D["词表密度~1.5-2.5<br/>token虚高交税"]

    C --> E["embedding选中文友好<br/>BGE-M3 自部署≈0成本"]
    D --> F["embedding走OpenAI<br/>语言税叠加$0.13/M"]

    E --> G["按token切分<br/>而非按字数切分"]
    F --> H["按字数切分<br/>超限/不均双重浪费"]

    G --> I["✅ 账单砍到1/5–1/10"]
    H --> J["❅ 复利持续烧钱"]

    style C fill:#d4f4dd
    style E fill:#d4f4dd
    style G fill:#d4f4dd
    style I fill:#a8e6b8
    style D fill:#f9d0c4
    style F fill:#f9d0c4
    style H fill:#f9d0c4
    style J fill:#f5b7b1

四、信息差总结：你不知道的，和别人已经省下的

五、行动指南：今天就能做的四步

第一步：体检（10分钟）。 把你最近一周的中文prompt/文档，丢到 platform.openai.com/tokenizer 或 tokenizer.gg，分别用cl100k、o200k看token数对比。再算一下你每周的中文token总量×当前模型单价——这个数字会吓到你。

第二步：路由（半天）。 在你的调用层加一个语言/难度路由：纯中文简单任务 → GLM/Qwen；中英混合或强推理 → 前沿模型。优先把中文意图识别、中文总结、中文摘要这类"语言税重灾区"迁走。

第三步：换embedding（1天）。 新建RAG或向量检索项目，直接用BGE-M3（自部署或第三方便宜API）替代OpenAI embedding-3。已有项目可灰度迁移。算一下索引成本差异，作为汇报材料。

第四步：改切分（半天）。 把"按字符数切分"统一改成"按token数切分"，并按目标模型的词表密度调整窗口。这是让前三刀收益落地的关键一环。

预算分级推荐： - 个人/小项目：GLM系列API + BGE-M3第三方API，月成本可压到几十元。 - 中型团队：GLM/Qwen API + 自部署BGE-M3，按token切分，月成本砍到原1/5。 - 大规模RAG：自部署embedding + 国产模型为主力 + 前沿模型仅做难题兜底，整体账单可压到原1/10。

语言税这笔账之所以长期没人讲，是因为它藏在计费的最底层——比模型单价更深，比缓存策略更隐蔽。但它对中国用户的杀伤力恰恰最大，因为我们每天都在用中文。你省下的每一分钱，不一定来自换更便宜的模型，更可能来自让你的中文，不再为别人的英文词表买单。

本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生（微信ID: gprshome201101）维护。 聚焦5G/6G核心网、3GPP标准、AI工具实战。知识星球「51学通信」提供深度技术答疑和行业洞察。

[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。