上个月，一位做法律AI的朋友给我看了他的OpenAI账单：一次合同审查任务，上下文塞了三十页判决书和法规条文，单次调用烧了超过十二万token，折合人民币接近两块钱。他问我：“这玩意儿吃的不是算力，是金子吧？”
两块钱听起来不多。但放大到每天十万次调用，这笔账就变成了一个绕不开的工程命题。我们习惯于把大模型当作一个"聪明的对话者"，却很少追问一个更底层的问题：为什么这些对话如此昂贵？token到底烧在了哪里？
要回答这个问题，不能停留在"模型很大所以很贵"这种模糊认知上。我们需要拆开Transformer的引擎盖，看看那些token在计算图里究竟经历了什么。
Token不是"字"，而是模型认知的原子
很多开发者对token的第一个误解，是把它等同于字符或单词。真相更微妙。以GPT-4使用的Byte-Pair Encoding（BPE）为例，token是介于字符和单词之间的子词单元。“unbelievable"可能被切成un+believ+able；一个汉字如"智”，在UTF-8层面是三字节，经过BPE后可能独立成token，也可能和相邻字合并。
这带来一个关键洞察：token是模型理解世界的最小语义单元，也是计量成本的硬通货。推理的每一次前向传播、每一次注意力计算，都是以token为粒度展开的。理解了这一点，我们才能明白为什么"烧token"不是简单的流量计费，而是深嵌在架构层面的结构性开销。
第一座大山：注意力机制的平方诅咒
Transformer的核心机制是自注意力（Self-Attention）。它的优雅之处在于让每个token都能"看到"序列中的其他所有token，从而捕捉长距离依赖。但这种全连接的视野是有代价的。
具体来说，注意力矩阵的计算复杂度是O(n²)，其中n是序列长度。这意味着如果你把上下文从4000 token翻倍到8000，计算量不是翻倍，而是大致变为四倍。内存消耗同样遵循这个规律，因为需要存储一个n×n的注意力分数矩阵。
ByteByteGo在一篇关于上下文工程的文章中做过一个精妙的概括：将上下文窗口中的token数量翻倍，所需的计算量大约会翻两番（quadruple）。更长上下文带来的不是线性增长，而是指数级的沉重。$TRAE_REF
这就是为什么2022年底ChatGPT刚发布时上下文只有8192 token——不是OpenAI吝啬，而是在当时的工程约束下，这是算力与效果之间的甜点。而今天那些宣称支持百万token上下文的模型，背后无一不是用架构创新（如稀疏注意力、滑动窗口、Ring Attention）在规避这个平方诅咒，而非正面硬刚。
第二座大山：KV Cache的内存黑洞
如果说注意力计算是算力消耗，那KV Cache就是内存消耗。这是许多工程师容易忽略的部分。
在Transformer的推理过程中，模型会为每一个token生成一对Key和Value向量，缓存起来供后续token使用。这个KV Cache的大小与序列长度成正比。以Llama 3 8B为例，处理一百万token的序列时，KV Cache的显存 footprint 可以达到128GB——这已经超过大多数单卡GPU的容量。$TRAE_REF
这些研究的密集涌现本身就说明了一个问题：KV Cache已成为长上下文推理的首要瓶颈。你每多塞一个token进上下文，不仅是在消耗计算，更是在占用宝贵的GPU显存。而当显存不足时，系统不得不将KV Cache卸载到CPU内存甚至SSD，延迟就会雪崩式上升。
第三座大山：Tokenization的"语言歧视"
如果说前两个问题对所有语言一视同仁，那tokenization则存在明显的"语言歧视"。这是非英语使用者最直观的痛感来源。
英文受益于BPE的合并逻辑：常见词如"the"、"and"通常被编码为单个token，一个token平均覆盖约0.75个单词。但中文、日文、韩文（CJK）的处境截然不同。由于训练语料中CJK文本占比低，且这些语言没有空格分词，BPE难以形成高效的子词合并。结果是一个汉字常被拆成2到3个byte-level token来处理。$TRAE_REF
这造成了一个尴尬的等式：表达同样的语义，中文需要比英文多2到3倍的token。一篇一千字的中文文章，在API计费时可能等效于三千词的英文内容。OpenAI和Anthropic按token收费，这意味着中文用户实际上在补贴英文用户的成本结构。
SentencePiece等后续方案试图缓解这个问题，将输入视为原始字节流而非预分词文本，但根本性的语料偏斜依然存在。最近有研究甚至挑战了"中文prompt一定更贵"的刻板印象，指出不同模型表现各异——GPT-4o-mini上中英文token成本接近1:1，而MiniMax上中文仍是1.28倍。$TRAE_REF 但无论比例如何波动，非英语语言在token效率上的劣势是系统性的。
第四座大山：Lost in the Middle——花了钱还记不住
最讽刺的是，你燃烧的token，模型未必真正"看见"。
2023年，斯坦福大学、UC Berkeley和Samaya AI的研究者联合发表了一项影响深远的研究：他们把关键信息（“针”）藏在长文档（“草堆”）的不同位置，测试大模型能否准确提取。结果发现，当文档足够长时，模型对中间位置信息的检索准确率显著下降——而对开头和结尾的注意力保持得较好。
这就是著名的"Lost in the Middle"现象。它的含义令人沮丧：你付费塞进上下文中间的那些token，模型其实没怎么认真看。ArsTechnica在一篇报道中形象地描述了这一问题：即使今天的LLM能处理百万token上下文，它们仍然会在长文本中"窒息"，不是忘记了开头，就是对中间内容一知半解。$TRAE_REF
注意力的分布本质上是偏态的。人类读长文时会前后翻阅，但Transformer的注意力权重天然倾向于序列的两端。这意味着长上下文不仅烧更多token、更多算力、更多显存，还可能因为信息检索的不均衡而降低输出质量。你付了头等舱的票价，模型却只在经济舱的视野里工作。
出路：RAG、压缩与架构革新
面对这四座大山，业界并没有坐以待毙。工程上的应对大致分为三条战线。
第一条战线是RAG（检索增强生成）。与其把整本书塞进上下文，不如先让检索系统找到最相关的几页，只把这几页喂给模型。Elastic的一项基准测试显示，RAG查询的平均成本比纯长上下文方案低1250倍，同时精度更稳定。$TRAE_REF 这不是说长上下文没用——对于需要全局理解的文学分析或代码仓库理解，全量上下文仍有不可替代的价值——但在大多数企业场景下，RAG是更务实的选择。
第二条战线是KV Cache压缩与卸载。从FP16到FP8再到NVFP4，量化精度不断下探；从静态压缩到动态筛选（如KVCompose、MorphKV），压缩策略越来越智能。NVIDIA Dynamo甚至支持将KV Cache从GPU显存实时卸载到CPU内存或SSD，用带宽换容量。$TRAE_REF 这些技术正在把"百万token上下文"从论文里的数字变成生产环境的可选项。
第三条战线是注意力机制的重新设计。稀疏注意力、线性注意力、状态空间模型（如Mamba）试图从根本上绕过O(n²)的复杂度。它们不再让每一个token关注所有其他token，而是通过局部窗口、层次化聚合或隐状态传递来近似全局依赖。这些架构是否能在通用能力上追平Transformer仍是开放问题，但它们代表了一个清晰的方向：未来的高效模型，大概率不会是纯Transformer。
回到本质：我们在为什么付费
说到底，token之所以昂贵，是因为它同时承载着三重功能：语义单元、计算单元、记忆单元。每一个token都要参与注意力计算，都要占用KV Cache的存储，都要经过神经网络的层层变换。这种三位一体的设计赋予了Transformer强大的表达能力，也锁死了它的成本结构。
我们正处于一个微妙的过渡期。上下文窗口从8K膨胀到1M，靠的是工程上的精雕细琢——量化、压缩、并行、卸载——而非底层复杂度的根本突破。真正的拐点，或许要等到下一代架构（无论是状态空间模型、神经图灵机，还是某种尚未被发明的机制）来重新定义"模型如何处理长序列"这个问题。
在此之前，每一次调用API时的token计数，都是一次对Transformer架构本质的提醒：智能不是免费的，每一个被点亮的注意力权重，都有它的电价。
