长上下文LLM服务中的真实权衡：内存、延迟、成本与准确性

上下文是你在一次请求中发送给模型的所有内容：提示词、文档、代码、对话历史。它使用令牌（token）来衡量，令牌是词元片段，大约每1,000个令牌对应750个单词。128K令牌窗口（大约相当于一部小说的文本量）是当前常见的标准。Llama 3.1 和 GPT-OSS-120B 均配备128K窗口。前沿的闭源模型更进一步。根据 DigitalOcean 的定价页面上的模型列表，Claude Sonnet 4.6、4.5 和 4 最多接受100万输入令牌，大约相当于十部小说。

规格表上的数字告诉你模型能接受什么，但并不能告诉你当许多用户同时向同一基础设施发送如此大的输入时会发生什么。支持是模型的能力，性能是服务的问题，两者在四个具体方面存在差异。本文将逐一说明，并附上数据。

你需要先了解两个背景知识。

预填充（Prefill）与解码（Decode）。 推理分为两个阶段。在预填充阶段，模型在生成任何内容之前，以一次并行通行读取你的整个输入。预填充受计算限制，受限于 GPU 进行数学运算的速度。在解码阶段，模型一次生成一个令牌的回答。解码受内存限制，受限于数据从 GPU 内存移出的速度，而非算术运算。长输入主要对预填充造成压力，长输出主要对解码造成压力。

KV 缓存。 模型每读取一个令牌，就会计算并存储两个向量：一个键和一个值，这样就不必在生成每个新令牌时重新读取整个输入。这个存储就是 KV 缓存。它会在整个请求生命周期内驻留在 GPU 内存中，并且与您发送的内容量成正比增长。

KV 缓存的内存占用遵循一个简单的公式：

延迟就是等待时间：从发送请求到获得响应之间需要多久。对语言模型而言，延迟包含两个用户感受不同的部分。第一部分是任何输出出现之前的停顿，称为首令牌时间（TTFT）。第二部分是开始输出后，其余答案流入的速度。人们对较慢的流式输出远比长时间沉默停顿更能容忍，这使得TTFT成为决定应用是否感觉响应灵敏的关键指标。而长上下文恰恰会抬高TTFT。

原因如下。注意力机制是每个Transformer的核心操作，它会将输入中的每个token与其他所有token进行比较。计算量随输入长度的平方增长。上下文长度翻倍，工作量为原来的四倍。从32K到128K，长度变为4倍，注意力计算量则变为16倍。

所有这些都发生在预填充阶段，即在答案第一个词出现之前。这就是为什么TTFT在短上下文时是毫秒级，在长上下文时则变成整秒级。像FlashAttention这样的优化确实在此有所帮助。它们减少了GPU在快速内存和慢速内存之间来回搬运数据所浪费的时间，加速效果显著。但它们无法改变底层的数学原理。计算量仍然随输入平方增长；只是从更低的起点开始增长。只要标准注意力机制是二次复杂度，每增加一个token，下一个token的成本就会更高。

第二个延迟成本更容易被忽视：你的长请求对其他人造成的影响。一次128K token的预填充会占用GPU数秒，排在它后面的每个请求都要等待。受伤害最深的不是那些发送长请求的人，因为他们预期到要等待。而是那些发送短请求、却不幸排在长请求后面的用户。在仪表盘上，这看起来像是平均延迟健康，而p95和p99则在悄悄恶化，这种模式对智能体和副驾驶等交互式产品的损害最大。

即使计算能力无限，解码也会撞上一堵与算术无关的墙。为了生成每个输出token，GPU必须从高带宽内存（HBM）中读取整个KV缓存。旗舰GPU的数据移动速度大约为3到4 TB/s，而且这个数字是固定的。一旦缓存达到几十GB，每生成一个token就读取一次缓存就成为真正的瓶颈。

二者之间的关系几乎是线性的。上下文长度翻倍，缓存翻倍，每一步解码读取的数据翻倍，每秒生成的token数大约减半。一个集群可能计算资源空闲，却仍然缓慢地服务长上下文，因为瓶颈已经从计算单元转移到了内存总线上。如果你用FLOPS来购买和衡量GPU容量，那么对这个工作负载而言，你衡量的其实是错误的约束。

你可以通过一次除法自己为这个计算设置一个上限。对于单个请求，每次解码步骤都会读取模型权重加上KV缓存，所以最佳可能速度是带宽除以读取的字节数。对于在H100 SXM（3.35 TB/s）上运行的BF16精度Llama 3 70B（141 GB权重）：

有两个注意事项。这是单个未批处理请求的理论上限；没有任何系统能超过它，而且大多数系统远低于这个值。对于单个请求来说，在缓存增长到可比规模之前，权重读取占据主导地位，这就是为什么上限先缓慢下降然后急剧下降。在生产环境中，效果比表格显示的更糟糕，因为批处理在多个请求之间共享一次权重读取，而每个请求都带来自己的缓存流量。一旦缓存读取占据总线主导地位，就会出现上下文长度翻倍、吞吐量减半的行为。这些计算的意义不在于精确性，而在于你可以在三十秒内快速检验任何提供商吞吐量声明的合理性。

成本也随之而来。你可能会认为一个128K token的请求成本大约是1K请求的128倍，与token数量成正比。但一旦将二次方预填充、缩减的批处理、饱和的带宽以及后面阻塞的队列都计算在内，实际成本往往更高。一些定价已经承认了这一点。根据DigitalOcean的模型定价页面（2026年7月查询），Anthropic的Claude Sonnet模型在输入达到200K token之前每百万输入token收费$3.00，超过后每百万收费$6.00，输出价格从$15.00上升到$22.50。提示缓存的存在主要是为了缓解这一问题：你为处理一个长而稳定的上下文支付一次费用（Claude Sonnet写入缓存的费用是每百万token $3.75，缓存生命周期为5分钟），之后每次复用只需支付每百万token $0.30。

理解这含义的最清晰方式是给一次会话定价，而不是给单个token定价。以一次携带稳定128K token上下文的10轮智能体对话为例，比如一个代码库或文档集，每轮增加一个500 token的问题并获得一个500 token的回答，采用上述Claude Sonnet的费率：

携带128K token上下文的10轮智能体会话的累计成本，三种策略对比：每轮重新发送完整上下文达到$3.93，缓存达到$0.95，检索8K切片达到$0.33

该图清晰地展示了每种策略的运行形态。重新发送（Resending）呈陡峭增长且永不停歇。缓存（Caching）的起始位置高于检索（Retrieval），原因在于第一轮对话时需要一次性写入缓存（可以看到它在第一轮到第二轮之间与重新发送的曲线相交），随后逐渐趋于平缓，每轮成本几乎为零。而检索的曲线始终保持在低位且平稳。

在相同的对话和模型条件下，缓存使账单降低了4倍，而检索则降低了12倍。在每天数千次会话的规模下，架构选择的重要性远超单令牌价格。检索也并非零成本，它需要独立的基础设施支持，这就引出了下一部分的内容。

前三个权衡属于基础设施问题。第四个权衡起初源于模型问题，最终却演变为基础设施问题。

模型在回答长输入问题时，其可靠性不如短输入。这一点已有充分的文献记录。RULER研究表明，许多模型的有效上下文长度——即它们仍能保持良好性能的长度——远低于其宣传的最大值。Lost in the Middle研究则显示，当关键信息位于长输入的中部而非开头或结尾时，准确率会急剧下降。

IBM Research与代尔夫特理工大学联合开展的一项2026年测量研究，题为《准确率即速度：面向分布式LLM服务的长上下文感知路由》(Yoshimura, van de Beek 和 Chiba, EuroMLSys '26)，补充了两项发现，对于在生产环境中运行长上下文工作负载的人来说值得关注。

第一个发现是，准确率的退化方式往往打破直觉。作者在4K到64K令牌的上下文长度下，使用英语、日语和中文，对五款模型进行了键值查找任务的测试。模型大小并不能预测长上下文的准确率。Phi3-mini作为测试中规模最小的模型，往往是准确率最高的，甚至超越了更大的Phi3-medium。在32K和64K令牌长度下，一款2B模型的表现优于其8B的同类模型。还有一款模型在16K内表现稳定，但在32K时就骤然崩溃。语言因素同样重要：在英语中表现最佳的模型，未必在日语或中文中也是最好的。各模型间的延迟排名保持稳定，但准确率排名却并非如此。

第二个发现是论文的核心论点：准确性失败会转化为延迟。当模型回答错误时，用户或系统会重试，而时钟一直在走。论文将这种现象命名为“正确回答时间”（Time-to-Correct-Answer，TTCA）：即从首次尝试到首次正确回答的总挂钟时间。一个有一半时间都答错的高速模型，可能比一个首次就能答对的较慢模型体验更差，因为重试会累积时间。正如作者所说，在长上下文服务场景下，准确性即速度。

他们还表明你可以据此采取行动。他们的路由设计LAAR（轻量级准确性感知路由，Lightweight Accuracy-Aware Routing）将每个候选模型的预期延迟除以预期成功概率作为评分，所用特征不过是输入长度和语言，并且不会将对已失败模型的请求重发。在A100 GPU上对五个模型的测试中，与负载感知路由相比，平均TTCA最多降低了31%；与会话亲和路由相比，最多降低了49%。具体数字不如原则重要。如果你在多个模型之间提供长上下文服务，上下文长度应有助于决定哪个模型来处理请求，因为最佳选择会随上下文长度而变化。

问得合理。如果模型能接受一百万个token，为什么还要保留向量数据库，分块流水线和检索步骤呢？为什么不把整个语料库粘贴到提示词中？

因为上述一切都是这种粘贴的代价。把窗口塞满意味着要承担二次方预填充成本、数秒的首token时间，以及每次请求按token分层计费的费用，即使只需要输入中的三段话来回答。这也意味着在模型最不可靠的区域工作。RULER发现，有效上下文长度通常达不到宣传的窗口大小，而“迷失在中间”（Lost in the Middle）发现，模型最弱的时刻恰恰是相关细节埋在上下文中间时，而整个语料库放入时通常都是这种情况。检索以同样的方式绕开了这四种权衡：它保持请求短小。模型只读取关键片段，因此预填充成本低、缓存小、答案响应快，而且模型在它可靠的长度范围内工作。

因此，长上下文并没有让检索过时。它改变了每种方法各自的胜出时机，并且在两个方向上都提出了警告：例如，关于两种方法结合的研究Long-Context LLMs Meet RAG发现，向大窗口中检索更多段落并不总能可靠地改善答案，反而可能随着无关文本的堆积而降低答案质量。更大的窗口并不是允许你粗心检索的许可。

跳过检索的代价

这四种权衡就是可见的代价。放弃检索、押注上下文窗口的团队还会遇到一组直到系统进入生产环境才会显现的成本。其中五项反复出现。

每一种已知的缓解措施都有所收获，也有所牺牲：

这些方法都不能让你以短上下文的代价获得长上下文能力。它们汇总起来就是一份简短的行动手册：

不要发送你不需要的内容。 检索、总结旧轮次和修剪失效上下文，胜过任何GPU端修复，因为最便宜的token就是你从未发送过的那个。

缓存重复的内容。 跨请求共享的稳定长前缀（系统提示、文档、代码库）正是提示缓存的用武之地。一次性支付预填充成本，然后廉价地复用。

将模型与长度匹配。 最近的研究结果表明，在8K下最准确的模型在64K下可能并不是最准确的，而且更大的模型不一定更好。如果你控制路由，请将上下文长度作为输入条件。如果不能，就在你的实际长度下测试模型，而不是相信宣传的窗口。RULER的存在正是因为这两者经常不一致。

关注尾部延迟和上下文混合，而不是平均值。 损害隐藏在p95和p99中，也隐藏在那些统计请求数而非token数的自动扩缩容信号中。十个128K请求和一千个1K请求在请求速率仪表盘上看起来可能完全相同，直到延迟崩溃。

在决定采用某家提供商进行长上下文工作之前，有四个问题值得询问：长上下文吞吐量是如何衡量的，是单独测量还是在并发负载下测量？当长请求到来时，其他租户的延迟会发生什么变化？定价是否随token线性扩展，还是反映了真实的非线性成本？他们能否向你展示prefill与decode的延迟拆分？最后一条是一个不错的成熟度测试。一家已对该拆分进行检测的提供商，会知道自己的时间花在了哪里。

如果你正在评估自己的技术栈在上下文增长时的表现，DigitalOcean的推理引擎提供长上下文模型（包括Claude Sonnet的100万token输入窗口），按模型公布每token定价，同时列出提示缓存费率，并提供专用推理，用于需要与嘈杂邻居隔离的工作负载。请使用真实的上下文长度和真实的并发度进行测试，而不是在演示中只发送单个请求。这是最快的方法，能让你知道上下文窗口是产品可以依赖的功能，还是仅仅在技术上支持而已。

来源

• 精度即速度：面向分布式LLM服务的长期上下文感知路由, Yoshimura, van de Beek, and Chiba, EuroMLSys '26（精度可变性测量、TTCA、LAAR结果）
• 规模化长上下文推理：隐藏的基础设施成本, DigitalOcean, 2026年5月（KV缓存公式及实例、prefill/decode分析、带宽上限、提供商问题）
• 使用PagedAttention的大语言模型服务的高效内存管理, Kwon et al., SOSP 2023（KV缓存核算、分页缓存分配）
• GQA：从多头检查点训练广义多查询Transformer模型, Ainslie et al., 2023（分组查询注意力、缓存公式中的KV头项）
• RULER：你的长上下文语言模型的真实上下文大小是多少？（有效上下文长度与宣称上下文长度）
• 迷失在中间：语言模型如何使用长上下文（位置准确性损失）
• 长上下文LLM与RAG相遇：克服RAG中长输入的挑战（长窗口中的检索质量）
• RAG对比大上下文窗口：AI应用的真实权衡, Redis, 2026年2月（隐藏成本小节中引用的运营成本类别）