昂贵的二次方：LLM代理成本曲线（读书笔记）

2026-02-03 Philip Zeyliger

快速测验：在编码代理的上下文长度的哪个点上，缓存读取消耗了你下一个API调用的一半成本？到50,000个令牌时，你的对话成本可能主要由缓存读取主导。

让我们退后一步。我们之前写过关于编码代理如何工作的文章：它们将迄今为止的对话发布到LLM，并在LLM请求工具调用时继续这样做。当没有更多工具要运行时，循环等待用户输入，整个周期重新开始。视觉上：

代理循环

或者，以代码形式：

def loop(llm):
    msg = user_input()
    while True:
        output, tool_calls = llm(msg)
        print("Agent: ", output)
        if tool_calls:
            msg = [handle_tool_call(tc)
                   for tc in tool_calls]
        else:
            msg = user_input()

LLM提供商对输入令牌、缓存写入、输出令牌和缓存读取收费。这有点棘手：你在提示中指示缓存到某个点（通常是末尾），然后你被收取"缓存写入"而不是输入的费用。前一回合的输出成为下一回合的缓存写入。视觉上：

跨LLM调用的令牌成本

在这里，颜色和数字表示构成第n次LLM调用的成本。每次后续调用都从缓存中读取迄今为止的故事，将前一次调用的输出写入缓存（以及任何新输入），并获得一个输出。区域代表成本，尽管在这个图中，它并没有完全按比例绘制。把所有矩形加起来，那就是总成本。

那个为缓存读取出现的三角形？那就是可怕的二次方！

这个二次方有多可怕？相当平方！我相当平淡地实现了一个功能，并像上面的图表一样可视化它。区域对应成本：每个矩形的宽度是令牌数量，高度是每个令牌的成本。随着对话的进行，越来越多的成本是底部对应缓存读取的细长线条。

[显示成本分布的可视化]

整个对话花费了大约12.93美元。你可以看到，随着对话的继续，缓存读取占主导地位。在对话结束时，缓存读取占总成本的87%。在27,500个令牌时，它们占了一半的成本！

这个对话只是一个例子。这是否普遍发生？exe.dev的LLM网关跟踪我们正在产生的成本。我们不存储过去的消息本身，但我们确实跟踪令牌数量。下图显示了"累积成本"可视化，适用于许多Shelley对话，而不仅仅是我自己的。我从数据中随机抽样了250个对话。

x轴是上下文长度，y轴是到该点的累积成本。左图是所有成本，右图只是缓存读取。你可以将鼠标悬停以在两个图表上找到给定的对话。下面的箱线图显示了输入令牌和输出令牌的分布。

[显示跨对话累积成本和缓存读取的图表]

成本曲线都不同，因为每个对话都不同。一些对话编写大量代码，因此在昂贵的输出令牌上花费更多钱。一些对话读取大量代码库，因此在工具调用输出上花费金钱，这些看起来像缓存写入。一些对话在缓存过期时等待用户，因此必须重新将数据写入缓存。在我们的数据中，中位数输入大约是285个令牌，中位数输出大约是100个，但分布相当广泛。

让我们看看一些对话如何达到100,000个令牌。我们从同一数据集中抽样，但排除了20次调用以下的短对话，也排除了没有达到100,000个令牌的对话。对话中的LLM调用数量相当重要。缓存读取成本并不是令牌数量的平方；它是令牌数量乘以调用次数，不同的对话有非常不同的LLM调用次数！

[显示达到100,000个令牌的对话的可视化]

回到我们最初的问题，我们可以构建一个小型模拟器。Anthropic的费率是x用于输入，1.25x用于缓存写入，5x用于输出，x/10用于缓存读取，其中x = Opus 4.5每百万令牌5美元。在模拟器的默认设置中，只需要20,000个令牌就能达到缓存读取占主导地位的程度。

作为编码代理开发者和代理循环用户，这种成本结构给了我很多思考！

一个关于这个的隐喻是"航位推算"。如果我们让代理在没有反馈（以工具调用和大量来回的形式）的情况下导航一个长期任务，它会更便宜，但另一方面，我们知道是反馈让代理找到正确的目的地。在所有条件相等的情况下，更少的LLM调用更便宜，但代理的内部指南针是否偏离了，它是否朝错误的方向前进？

一些编码代理（包括Shelley！）在某个阈值后拒绝将大型工具输出返回给代理。这是一个错误：它将读取整个文件，不如在一次调用中完成，而不是五次。

子代理和调用LLM的工具是在主上下文窗口之外进行迭代的一种方式。例如，Shelley使用"关键词搜索"工具作为LLM辅助的grep。

重新开始对话可能感觉失去了太多上下文，但重新建立上下文所花费的令牌很可能比继续对话所花费的令牌更便宜，而且效果往往相同。开始新对话总是感觉浪费，但然后我记住我在开始新任务时总是从我的git仓库开始新对话；为什么继续现有任务有什么不同？

成本管理、上下文管理和代理编排是否真的都是同一个问题？Recursive Language Models这样的工作是否是正确的方法？

这些问题在我们开发exe.dev和Shelley时非常困扰着我们。让我们知道你的想法！

---

#标签 #LLM #成本优化 #AI代理 #令牌管理 #缓存 #性能优化 #Shelley #exe.dev