为什么要利用物质来提高能源（和代币）效率

作者：Chad Gibson，联合创始人兼首席执行官 主要发现 以不同方式利用缓存。我们发现客户端中有 1.6% 到 11.1% 的输入未缓存。 “缓存”是从提示缓存提供的输入令牌的份额，而不是再次计算。在 92% 缓存时，每 100 个令牌有 8 个未缓存，而在 97% 时有 3 个令牌：大约是预填充工作的 2.7 倍。缓存未命中大约使请求的能量增加一倍。在这里，未命中意味着请求的提示很少或没有被缓存（低于 10%）。在 GLM-5.3 上，大约是 2.5 倍。深度训练会让错过的代价变得昂贵。重新阅读意味着从头开始重新计算提示的该部分。超过 128k 代币，重新读取一半以上提示的一回合所花费的预填充费用相当于该深度下大约 600 个正常回合的预填充费用。其中大部分是可以修复的。我们实验室测试中的每次缓存中断都来自于工具编辑其已发送的内容，迫使从第一个差异开始重新读取。在 Neuralwatt，我们可以看到调用模型的代理线束如何影响其使用的能量。我查看了云上一个月的流量，发现该工具似乎决定了 GPU 工作量的惊人比例。我们通常从模型（有多少活跃参数，其注意力机制）或硬件（H200 vs B200 vs B300）来谈论推理效率。客户值得仔细观察。我们几乎所有的流量都是代理的，输入远多于输出。典型的编码代理轮流发送 100k 令牌或更多会话并返回几百个令牌。大部分输入是上一回合的提示，最后添加了一些。如果较早的文本未更改，则服务器已经拥有其键值 (KV) 缓存，并且只需处理新的部分。这就是即时缓存，我们最大的效率来源。提供缓存的令牌比再次计算它要便宜得多。缓存需要一个精确的前缀。当线束更改其已发送的内容时，就会发生缓存中断。然后我们重新计算从第一个差异开始的所有内容。开头附近的更改，即使是时间戳，也意味着重新计算几乎整个提示。接近尾声时的改变成本很低。线束控制提示的构建方式。相同的型号，相同的价格，不同的缓存率每个请求都会告诉我们哪个客户端发送了它。在2026年9月8日到10月7日的30天内，我们看到了数百个不同的客户端，其中包括OpenCode、Oh My Pi（omp）和Pi等开源编码代理。该组合还包括编辑器集成、OpenAI SDK 和自定义应用程序。仅 OpenCode 就有大约四分之一的客户使用。对于最广泛使用的客户端，以下是我们无法从缓存提供的输入令牌的份额： 图 1. 客户端未缓存的输入。这里的每个客户端都会缓存其大部分输入。这些微小的差异仍然很重要：缓存率为 97% 的客户端向我们发送每百个 3 个未缓存的令牌； 92% 的客户发送了 8 个。这是同一对话的预填充工作量的 2.7 倍。命中率还取决于工作量，而不仅仅是安全带。较长的会话得分较高，因为每个回合的新文本在提示中所占的份额较小，并且 deepseek-harness 的领先优势大约有一半来自运行很长时间会话的用户。衡量线束的一个更清晰的衡量标准是转弯破坏缓存的频率：对于 deepseek-harness，大约每 100 圈就有 1 圈，而对于 OpenCode 和 Pi，大约每 100 圈就有 3 次。我们在流量中同时看到 OpenCode 1.x 和 2.x，因此该栏将它们结合起来。 2.x 单独看起来更好（2.2% 未缓存，3.0%），主要是因为模型混合。在同一模型上，它们的缓存效果大致相同。 2.x 修复了我们在实验室中发现的大部分 1.x 缓存损坏。这种差异在生产中并未显现出来，我们还不知道原因。能源损失是多少 我们根据测量的能源进行计费，因此我们可以直接看到成本。在 2026 年 10 月 1 日至 7 日的一周内，我们比较了具有相同提示大小（约 50k 令牌）和相似输出长度的同一模型上的请求。以下是与完全缓存的请求相比每个请求使用的额外能量： 图 2. 缓存未命中带来的额外能量。大部分未缓存的请求所消耗的能量大约是相同大小的缓存请求的两倍。在 GLM-5.3 上，它接近两倍半。预填充还与相同 GPU 的生成竞争，因此浪费的预填充会减慢该服务器上其他人的响应速度。在 2026 年 10 月 6 日至 13 日这一周内，我们在三个最繁忙的模型上依次跟踪各个会话。我们查看了前一个会话后五分钟内登陆同一服务器的每个会话，其中缓存应该是热的。大多数缓存中断都很小：提示结束时的几千个标记被重新计算。过去 128k 个上下文标记，每 1,000 次重读大约 3 次，从头开始重读一半以上的提示。这几个回合占该深度所有重读令牌的 75%。每个人平均重读约 230k 个令牌。在该深度的正常转弯会增加大约 370 个新令牌的中位数，因此