上个月一位做法律AI的朋友给我看了他的OpenAI账单一次合同审查任务上下文塞了三十页判决书和法规条文单次调用烧了超过十二万token折合人民币接近两块钱。他问我“这玩意儿吃的不是算力是金子吧”两块钱听起来不多。但放大到每天十万次调用这笔账就变成了一个绕不开的工程命题。我们习惯于把大模型当作一个聪明的对话者却很少追问一个更底层的问题为什么这些对话如此昂贵token到底烧在了哪里要回答这个问题不能停留在模型很大所以很贵这种模糊认知上。我们需要拆开Transformer的引擎盖看看那些token在计算图里究竟经历了什么。Token不是字而是模型认知的原子很多开发者对token的第一个误解是把它等同于字符或单词。真相更微妙。以GPT-4使用的Byte-Pair EncodingBPE为例token是介于字符和单词之间的子词单元。“unbelievable可能被切成unbelievable一个汉字如智”在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_REFNVIDIA在2025年发布的技术博客中讨论了用NVFP4量化来压缩KV Cache能将内存占用降低50%从而实现上下文长度或批处理大小的翻倍。T R A E R E F ] ( h t t p s : / / d e v e l o p e r . n v i d i a . c o m / b l o g / o p t i m i z i n g − i n f e r e n c e − f o r − l o n g − c o n t e x t − a n d − l a r g e − b a t c h − s i z e s − w i t h − n v f p 4 − k v − c a c h e / ) 更有研究者提出 M o r p h K V 试图在保持恒定 K V C a c h e 大小的同时不损失精度通过注意力模式动态筛选和更新缓存内容。 [ TRAE_REF](https://developer.nvidia.com/blog/optimizing-inference-for-long-context-and-large-batch-sizes-with-nvfp4-kv-cache/) 更有研究者提出MorphKV试图在保持恒定KV Cache大小的同时不损失精度通过注意力模式动态筛选和更新缓存内容。[TRAER​EF](https://developer.nvidia.com/blog/optimizing−inference−for−long−context−and−large−batch−sizes−with−nvfp4−kv−cache/)更有研究者提出MorphKV试图在保持恒定KVCache大小的同时不损失精度通过注意力模式动态筛选和更新缓存内容。[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架构本质的提醒智能不是免费的每一个被点亮的注意力权重都有它的电价。