> ## Content Index
> Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# LLM 成本预测
- URL: https://www.hubwiz.com/blog/llm-cost-prediction/
- Published: 2026-09-07T08:45:20.000Z
- Updated: 2026-10-13T16:03:13.000Z
- Description: 深入探讨输出长度预测、智能体预算与 Python 工具
- Author: admin
- Tags: LLM, #Import 2026-10-14 14:41

LLM 成本在执行后很容易衡量。在执行前预测则更为困难。

对于单次 LLM 调用，主要的未知因素是输出长度。对于智能体，不确定性还包括需要多少次模型调用、工具调用、重试或推理步骤。

近期研究表明，其中一些不确定性在执行前就已经可以估计，但这些方法的成熟度在单一提示和完整的智能体轨迹之间存在显著差异。

本文探讨在执行前已经可以估计哪些关于 LLM 和智能体成本的信息，以及哪些方法在当今是实用的。

## 1\. 估算 LLM 调用成本

LLM API 定价通常基于**输入 token**和**输出 token**。Token 是模型使用的文本单元。根据分词器的不同，它可以代表一个完整的词、词的一部分、标点符号或空格。

执行前：

- **输入 token：** 已知，因为提示存在且可以分词。
- **输出 token：** 仍然未知，因为响应尚未生成。

因此，主要的挑战是估计响应会有多长。

### 1.1 仅凭提示能否预测响应长度？

几种方法尝试仅使用提示来估计响应长度，而无需访问服务模型的内部状态。

文献中出现了三种方法：

- **自预测：** 让 LLM 在生成自身响应之前估计其长度。
- **分类：** 训练一个较小的模型（如 DistilBERT），将预期响应长度放入预定义的范围。
- **回归：** 训练一个代理模型（如 BERT）直接预测预期的输出 token 数量。

这些方法在如何制定预测问题上有所不同，但它们共享相同的假设：**提示包含足够的信息来提供对未来响应长度的有用估计。**

仅提示预测的主要优势在于它可以在**请求到达目标模型之前**运行。它不需要访问隐藏状态或内部激活，这使其与 OpenAI、Anthropic 或 Google 等封闭 API 兼容。

#### 让 LLM 估算自身响应长度

2023 年的论文 [Response Length Perception and Sequence Scheduling: An LLM-Empowered LLM Inference Pipeline](https://arxiv.org/abs/2305.13144?utm%5Fsource=chatgpt.com) 探索了最直接的方法：让 LLM 在生成自身响应之前预测其长度。

在论文的实验中，GPT-4 的预测与最终响应平均仅相差 22 个词，80% 在 50 个词以内。然而，模型可以在生成答案之前看到自己的预测。在预测和生成分开的更严格设置中，平均误差增加到约 100 个词，55% 的预测在 100 个词以内。

最重要的是，使这一预测特别有用的是它不仅能支持成本估算。它还能改善 **LLM 服务**。

当许多请求共享相同的 GPU 基础设施时，系统必须决定哪些请求一起处理以及以什么顺序处理。响应长度很重要，因为 2,000 token 的生成占用计算资源的时间远长于 50 token 的生成。如果没有良好的估计，短请求可能最终等待更长的生成，造成**队头阻塞**。

预测的响应长度可以帮助服务系统：

- **优先处理较短的请求**以减少等待时间。
- **更高效地批处理相似长度的请求**。
- **通过减少浪费容量来提高 GPU 利用率**。
- **通过在相同时间内完成更多请求来增加吞吐量**。

作者报告，当使用其长度预测进行调度时，**推理吞吐量增加了 86%**。这意味着服务系统通过使用预测的响应长度来更有效地组织执行，在相同时间内完成了显著更多的请求。

这种方法的主要缺点是预测器本身就是一个 LLM 调用。这在实际请求开始之前引入了额外的延迟和成本。

#### S³：将响应长度视为分类问题

Jin 等人在 [S³: Increasing GPU Utilization during Generative Inference for Higher Throughput](https://arxiv.org/abs/2306.06000?utm%5Fsource=chatgpt.com) 中采用了一种更便宜的方法。S³ 是 **Scheduling Sequences with Speculation** 的缩写，它用一个更小的 DistilBERT 模型取代了额外的 LLM 调用。

预测器从包含提示及其观察到的响应长度的历史示例中训练。

S³ 不是预测确切的 token 数量，而是将响应长度分为**十个桶**。DistilBERT 然后学习将每个新提示分类到这些范围之一。

使结果特别有趣的是，预测准确性如何随工作负载的类型和多样性而变化。

作者在三个不同的数据集上评估了该方法：

- **Alpaca：** 大约 52,000 个指令跟随示例，最初使用 OpenAI 的 `text-davinci-003` 生成。→ 98.61% 准确率
- **Natural Questions：** 超过 300,000 个问答示例，基于真实的 Google 搜索查询和维基百科页面。→ 77.13% 准确率
- **The Pile：** 一个更广泛的语料库，包含来自 22 个来源的约 825 GiB 文本，包括网页、书籍、科学论文和代码 → 65.6% 准确率。

模式很清晰：响应长度对于更同质的任务更容易预测，随着提示和预期输出变得更加多样化而变得更困难。

S³ 最终将其预测用于 GPU 内存分配和调度。论文报告，与基于最大可能输出长度保留内存的基线相比，吞吐量增益高达 **6.49×**。

#### SSJF：将响应长度视为回归问题

Qiu 等人在 [Efficient Interactive LLM Serving with Proxy Model-based Sequence Length Prediction](https://arxiv.org/abs/2404.08509?ref=hubwiz.com) 中扩展了相同的想法。

他们的系统 **Speculative Shortest-Job-First (SSJF)** 使用一个微调的 **BERT-base** 模型从提示预测未来的响应长度。预测器在 [LMSYS-Chat-1](https://huggingface.co/datasets/lmsys/lmsys-chat-1m?ref=hubwiz.com)M 上训练，这是一个包含一百万真实对话的数据集，涉及 25 种不同的 LLM。

作者比较了几种制定预测问题的方法，包括分类、有序分类和回归。他们性能最好的变体将响应长度视为**使用 L1 损失训练的回归问题**。为了比较方法，预测长度随后被映射到五个长度类别。该变体达到 **0.615 准确率和 0.615 F1**，而标准分类为 **0.592 准确率**，使用均方误差训练的回归为 **0.601**，使用均方误差的有序分类为 **0.477**。作为参考，五个平衡类别的随机预测准确率约为 0.20。

然后论文评估这些不完美的预测是否仍然对服务系统有用。SSJF 优先处理预期生成较短响应的请求，减少小作业等待更长生成的时间。跨真实数据集和生产工作负载跟踪，作者报告：

- **平均作业完成时间降低 30.5% 至 39.6%**
- **吞吐量约 2.2× 至 3.6× 高于先到先服务调度**

作者提供了 [公开的 SSJF 实现](https://github.com/James-QiuHaoran/LLM-serving-with-proxy-models?ref=hubwiz.com)，包括数据集预处理、BERT 预测器训练、服务代码和调度器。

### 1.2 访问模型内部是否能改善估计？

仅提示方法从外部观察请求。当服务模型可访问时，另一个信息源变得可用且宝贵：其**隐藏状态**。

当 Transformer 处理提示时，每一层创建编码输入上下文信息的向量表示。在生成过程中，随着新 token 的产生，这些表示继续演变。

这引出了一个不同的假设：**模型的内部表示可能包含从提示本身不可见的关于未来响应长度的信息。**

三种最近的方法说明了这种方法：**TRAIL、EGTP 和 ESTP**。

#### TRAIL：在生成过程中更新估计

Shahout 等人在 [Don't Stop Me Now: Embedding Based Scheduling for LLMs](https://arxiv.org/abs/2410.01035?ref=hubwiz.com) 中介绍了 **TRAIL, Token Response and Embedding Adaptive Inference Layer**，发表于 ICLR 2025。[ICLR 会议页面](https://proceedings.iclr.cc/paper%5Ffiles/paper/2025/hash/9eb8b5ccb0de594a16548f7c058fdadf-Abstract-Conference.html?ref=hubwiz.com) 也提供了论文和补充材料。

TRAIL 从初始长度估计开始，然后在**每个生成的 token 后更新它**。

实验使用 Llama-3–8B-Instruct 与 Alpaca 提示。作者首先通过收集生成过程中不同点的隐藏状态嵌入和真实剩余 token 数来分析模型的 32 个 Transformer 层。

然后训练一个小神经网络来预测剩余响应长度。

预测器：

- **使用小型神经网络：** 两个线性层，中间表示维度为 512。
- **预测剩余长度：** 输出分为十个桶，覆盖最多 512 个 token 的响应。
- **从中间状态学习：** 选择最有用的层后，训练集包含超过 700 万对嵌入和剩余长度。
- **并非平等使用每一层：** 第 10 到 15 层提供最强信号，服务实现使用第 11 层。

一个有趣的结果是，预测并不会随着更多 token 的生成而简单稳定。

TRAIL 在每个解码步骤重新计算剩余长度，连续估计可能差异很大。为了减少这种不稳定性，作者应用贝叶斯平滑，将新预测与先前步骤的信息相结合。

因此，该过程更接近估计-更新-平滑循环，而不是产生一个最终固定的估计。

![None](https://www.hubwiz.com/blog/content/images/2026/09/0-02SJvYBgVOVG3h-R.png)

与仅看到原始提示的 BERT 预测器相比，TRAIL 实现了**平均绝对误差降低 2.66×**。

当与作者的最短剩余处理时间调度器结合使用时，它也改善了服务性能：

- **平均请求延迟：** 改进 1.66× 至 2.01×。
- **首个 token 时间：** 在评估的工作负载上改进 1.76× 至 24.07×。

#### EGTP：在第一个输出 token 之前预测

Xie 等人在 [Predicting LLM Output Length via Entropy-Guided Representations](https://arxiv.org/abs/2602.11812?ref=hubwiz.com) 中将预测提前，发表于 ICLR 2026。作者还发布了 [EGTP 的 GitHub 实现](https://github.com/xiehuanyi/LP%5FBench?ref=hubwiz.com)。

他们的方法 **Entropy-Guided Token Pooling (EGTP)** 在**预填充**期间估计响应长度，在第一个输出 token 生成之前。

预填充是模型处理完整输入提示的阶段。如果提示包含 500 个 token，Transformer 为这 500 个位置中的每一个产生上下文隐藏状态表示。

挑战在于决定如何将数百个 token 表示转换为一个有用的长度预测表示。

一种简单的方法是取平均值。EGTP 则尝试识别哪些提示位置携带更有用的信息。它依赖于**熵**。

在每个提示位置，模型产生下一个 token 的概率分布：

- **低熵：** 概率集中在少数可能的延续周围。
- **高熵：** 概率分布在许多可能的延续中，表示更大的不确定性。

EGTP 测试这些高熵位置是否对预测输出长度也更有信息量。

为了验证这一点，作者将熵与基于梯度的 token 重要性度量进行比较。当对其隐藏状态的小更改对预测误差有大影响时，token 被认为是重要的。

在 LMSYS-Chat-1M 数据集的 10,000 个样本上，他们发现 token 熵与该重要性度量之间存在正相关，**Pearson r = 0.451**。

这激发了池化策略：

- **处理提示：** 目标 LLM 在预填充期间产生隐藏状态和下一个 token 概率。
- **计算熵：** 每个提示位置获得一个熵分数。
- **加权 token：** 较高熵的位置获得更大权重。
- **池化隐藏状态：** 加权表示组合成一个向量。
- **预测输出长度：** 一个小型训练预测头将该表示转换为长度估计。

![None](https://www.hubwiz.com/blog/content/images/2026/09/0-u69O7ce4iGqu8E24.png)

熵计算本身不需要另一个模型。它源自目标 LLM 已经产生的概率。

训练的是一个在池化隐藏状态之上的小型长度预测头。模型将可能的输出长度分为 **20 个桶**。它为每个桶预测一个概率。然后使用每个桶的中心将这些概率转换为连续 token 估计。训练优化桶预测和最终 token 计数误差。

EGTP 论文还引入了 **ForeLen**，一个专门设计用于输出长度预测的基准。[数据集在 Hugging Face 上公开可用](https://huggingface.co/datasets/abinzzz/ForeLen?ref=hubwiz.com)，包含超过 **525,000 个示例**。

与 Alpaca 等更简单的数据集不同，ForeLen 覆盖更多样的工作负载：

- 来自 LongBench 和 ZeroSCROLLS 的**长上下文任务**。
- 具有更复杂指令的**推理任务**。
- 用于强化学习采样的**数学和编码任务**。

最后一个设置特别有趣，因为为同一个提示生成多个响应。这捕捉了一个重要的难点：**同一个提示可能产生不同的输出长度**。

在 Qwen2.5 和 Llama 3.2 模型上，EGTP 实现了约 **100–111 个 token 的平均绝对误差**，优于 TRAIL 和 SSJF 回归。在完整评估中，它将 MAE 降低了 **29.16%（与最强基线相比）** 和 **55.09%（与 SSJF 回归相比）**。

结果表明，预填充期间可用的信息比仅提示提供了更强的输出长度预测信号。

#### ESTP：将不确定性与语义重要性相结合

Ren 等人在 [When Entropy Is Not Enough: Reclaiming Lost Semantics in LLM Output Length Prediction](https://arxiv.org/abs/2608.15592?ref=hubwiz.com) 中挑战了 EGTP 背后的一个假设，于 2026 年 8 月发布。

他们的论点很简单：**不确定性和重要性不是一回事。**

考虑指令：

> 生成包含测试、文档和迁移代码的完整实现。

像测试或完整实现这样的词可能具有相对较低的熵，因为它们可以从周围上下文中预测。然而，它们可以强烈影响最终响应需要多长。相反，一个 token 可能具有高熵，但对预期响应长度贡献不大。

他们的方法 **Entropy-and-Semantic Token Pooling (ESTP)** 基于目标 LLM 的自注意力添加了第二个信号。

对于每个提示 token，ESTP 测量它从其他有效 token 接收到多少注意力。重复接收更多注意力的 token 被视为在上下文中更重要。

因此 ESTP 结合了：

- **熵：** 模型围绕一个 token 的不确定性。
- **注意力：** 该 token 在提示表示中的重要程度。

这些信号用于在长度预测之前加权隐藏状态。

ESTP 在评估的模型中持续改进 EGTP。例如，对于 Qwen2.5–3B，MAE 从 **112.45 降至 96.74**。在更具随机性的强化学习工作负载上，改进更大，MAE 从 **99.78 降至 72.56**。

这些方法的进展很有用：

- **TRAIL：** 内部状态在生成展开时完善预测。
- **EGTP：** 有用的内部信号在预填充期间已经可用。
- **ESTP：** 熵和注意力为预测长度提供互补信息。

## 2\. 更难的问题：评估智能体成本

预测单次 LLM 调用的成本只是问题的一部分。智能体在完成任务之前可以进行多次调用。

在运行期间，智能体可能多次调用 LLM，使用搜索、检索、代码执行或 API 等工具，并将先前的消息或工具结果添加到其上下文中。它还可能重试失败的操作、修改其计划，并继续推理直到达到停止条件。

因此有两个量是不确定的：

- **轨迹长度：** 需要多少步骤和模型调用？
- **每步成本：** 随着上下文累积，后续提示和响应会变得多大？

因此，智能体成本预测不仅是一个输出长度问题。它还需要预测**轨迹本身将如何演变**。

### 2.1 执行前能否知道总智能体成本？

Bai 等人在 [How Do AI Agents Spend Your Money? Analyzing and Predicting Token Consumption in Agentic Coding Tasks](https://arxiv.org/abs/2604.22750?ref=hubwiz.com) 中研究了这个问题。

实验使用 [SWE-bench Verif](https://huggingface.co/datasets/princeton-nlp/SWE-bench%5FVerified?ref=hubwiz.com)ied，这是一个包含 **500 个来自真实 GitHub 仓库的专家验证软件工程问题**的基准。

设置结合了：

- **500 个编码任务**
- **八个前沿 LLM**
- **OpenHands** 作为编码智能体框架
- **四次独立运行**，每个任务和模型配置

结果显示智能体消耗可能有多大的变化。

- **大量 token 使用：** 智能体编码使用的 token 比研究中评估的更简单编码工作负载大约多三个数量级。
- **输入 token 占主导：** 仓库内容、先前消息和工具输出被重复添加到上下文中。
- **运行间变化大：** 同一任务的两次执行在 token 消耗上可能相差多达 **30×**。
- **成本不意味着成功：** 消耗更多 token 不一定产生正确的解决方案。
- **任务难度是弱信号：** 人类评级的难度与 token 消耗的关系有限。

然后作者让模型在**智能体开始工作之前**估计其自身的未来 token 使用量。

预测与实际消耗之间的最强相关性仅约为 **0.39**。模型也倾向于低估最终将使用的 token 数量。

这与单次调用预测有重大差异。即使模型能估计其下一个响应的可能长度，它仍然必须预期**将发生多少未来步骤、重试、工具调用和上下文扩展**。

### 2.2 一旦轨迹开始，估计是否会改善？

[BAGEN: Are LLM Agents Budget-Aware](https://ragen-ai.github.io/bagen/?ref=hubwiz.com) 从不同角度处理成本预测。BAGEN 不是在执行开始前估计任务的全部成本，而是询问模型能否检查**部分完成的轨迹**并估计完成所需的剩余资源。

这实质性地改变了估计问题。一旦轨迹的一部分可见，模型就可以访问诸如：

- **进度：** 任务已经完成了多少。
- **当前状态：** 智能体是否接近解决方案或卡住。
- **到目前为止的消耗：** 已经使用了多少 token 或其他资源。
- **剩余难度：** 观察到的轨迹是否表明仍然需要大量工作。

**评估跨智能体任务的预算意识**

BAGEN 在几种类型的智能体环境中评估了这种能力：

- **Sokoban：** 一个规划环境，智能体在 token 预算下在 8×8 网格中移动箱子。
- **Search-R1：** 需要重复检索和推理的多步骤搜索任务。
- **SWE-bench：** 涉及仓库检查、代码更改、测试和迭代调试的软件工程轨迹。
- **Warehouse：** 一个供应链环境，其中操作消耗**金钱、时间和存储容量**。

**Warehouse** 环境特别重要，因为它将预算概念扩展到 token 之外。现实世界的智能体可能通过 API 调用、计算作业、购买、预订或其他操作消耗外部资源。

因此 BAGEN 专注于智能体能否从迄今为止的轨迹中确定，是否有足够的资源剩余来成功完成任务。

**任务性能和预算意识**

论文最有趣的发现之一是，擅长完成任务并不一定意味着擅长估计其剩余成本。

作者报告任务性能和预算意识性能之间的相关性仅约为 **r = 0.35**。

这表明预算意识是一种独特的能力，而不是更强大任务解决性能的自然副产品。

**训练预算意识**

BAGEN 首先在部分完成的轨迹上直接评估前沿模型。然后作者研究是否可以专门训练一个单独的模型用于预算估计。

一个开放的 Qwen 模型分两个阶段训练：

1. **监督微调（SFT）：** 模型从轨迹前缀与实际剩余预算配对中学习。
2. **强化学习（RL）：** 模型进一步优化以产生包含真实剩余成本而不会变得不必要的宽的区间。

结果揭示了两种预测形式之间的重要区别：

- **可行性预测：** 确定在可用预算内是否仍然可能成功完成。
- **预算估计：** 预测仍然需要的资源的数值范围。

第一个被证明相当容易。

- **可行性预测**在监督微调后从大约 **25.5% 提高到约 90%**。
- **预算区间预测**仍然困难得多，即使在额外训练后也只达到约 **47% 覆盖率**。

换句话说，模型更容易学习："这条轨迹不太可能在剩余预算内成功。"而不是："这条轨迹将需要另外 4,200–5,600 个 token。"

#### 预算意识作为执行时决策工具

这一区别引出了论文最实用的结果之一。

如果一旦估计器确定成功完成不再可行就停止执行，BAGEN 报告：

- **失败的轨迹上 token 减少 28–64%**。
- 总体任务成功率仅**下降 1.6–4.2 个百分点**。

含义很重要：智能体成本预测作为**执行时控制机制**可能比作为执行开始前产生一个精确成本估计的工具更有价值。

因此，更有用的框架是评估，给定迄今为止的轨迹，继续花费资源是否仍然值得。

作者发布了 [BAGEN 代码库](https://github.com/mll-lab-nu/BAGEN?ref=hubwiz.com)（包括评估、监督微调和强化学习管道）以及 [Hugging Face 上的 BAGEN 数据集](https://huggingface.co/datasets/MLL-Lab/BAGEN?ref=hubwiz.com)。

进展与单次调用预测中出现的相似，但在不同层面：

- **执行前：** 总智能体成本难以预测，因为未来轨迹未知。
- **执行期间：** 部分轨迹提供关于进度和剩余成本的有用信息。
- **用于控制：** 预测继续执行是否仍然值得可能比预测最终 token 计数更容易且更有用。

## 3\. 在 Python 中构建实用的估计器

上面讨论的研究集中在执行前无法直接观察的量上，如未来的输出长度、轨迹长度或总智能体成本。

Python 工具在问题的另一部分最强：**测量已知内容并将已知或假定的使用转换为货币成本**。

实际上，当前的 Python 库对三项主要任务有用：

- **Token 计数：** 测量已知模型输入的大小。
- **定价：** 将 token 和资源使用转换为美元。
- **使用规范化：** 处理提供商特定的类别，如缓存、推理 token、多模态输入和分层定价。

它们预测 LLM 或智能体未来消耗的能力要弱得多。

### 3.1 如何将 token 使用转换为成本？

LLM 不是逐词处理文本。分词器首先将文本转换为称为 **token** 的更小单元，这些单元可能代表完整的词、词片段、标点符号、空格或字节序列。

Token 计数是特定于模型的。因此，相同的文本在 OpenAI、Claude、Gemini 甚至同一提供商的不同世代之间可能产生不同的 token 计数。诸如"一个 token 大约等于 0.75 个词"之类的经验法则对于直觉有用，但不适用于计费。

现代 LLM 成本还超出了可见的提示和响应 token。根据提供商，使用可能包括：

- 输入和输出 token；
- 缓存输入和缓存创建 token；
- 内部推理 token；
- 工具定义和模式；
- 工具调用参数和返回的工具结果；
- 图像、音频或视频；
- 长上下文或服务层定价。

工具执行本身通常不是 LLM token 成本，但工具模式消耗输入 token，生成的工具参数消耗输出 token，返回的工具结果在发送回模型时成为额外输入。

因此，现实的成本计算比简单地**可见提示 token + 可见答案 token** 更广泛。

### 3.2 哪些 Python 库支持成本估计？

四个库涵盖了许多常见的 Python 工作流程，用于 token 计账和 LLM 定价。

![None](https://www.hubwiz.com/blog/content/images/2026/09/0-sIrm8ujAM9V2GDNK.png)

关键限制是所有四个库共有的：**它们根据已知或假定的使用计算成本；它们不预测未来使用。**

- [tiktoken](https://github.com/openai/tiktoken?ref=hubwiz.com)：它是 OpenAI 的分词器库，主要用于本地计算 OpenAI 模型编码的 token。它对于估计已知提示大小有用，但不提供多提供商定价或输出长度预测。
- [tokencost](https://github.com/AgentOps-AI/tokencost?ref=hubwiz.com)：由 AgentOps 维护，它将 token 计数与跨多个提供商的提示和完成成本计算相结合。它可以在 token 计数已知后为完成定价，但不预测该完成将有多大。
- [LiteLLM](https://docs.litellm.ai/?ref=hubwiz.com)：它提供广泛的多提供商抽象，具有成本跟踪和对许多 LLM 提供商的支持。它对于规范化异构提供商使用有用，但它仍然是定价和使用层，而不是预测系统。
- [genai-prices](https://github.com/pydantic/genai-prices/tree/main/packages/python?ref=hubwiz.com)：由 Pydantic 维护，它获取结构化使用记录并将其映射到模型和提供商特定的定价规则。它支持历史定价和分层定价等功能，同时将使用测量或预测留给应用程序。

**提供商原生 token 计数器**

提供商原生 token 计数器是模型供应商直接提供的 API 或 SDK 函数，用于在生成之前测量请求中的 token。OpenAI、Anthropic 和 Google Gemini 各自提供自己的机制，它们可以比通用本地分词器更准确地考虑提供商特定的格式、消息结构、工具模式和多模态输入。

例如，Anthropic 的 [Token Counting API](https://docs.anthropic.com/en/docs/build-with-claude/token-counting?ref=hubwiz.com) 可以在调用模型之前计算包含系统提示、对话历史和工具定义的请求的输入 token。

这对于包含聊天历史、工具、文档或图像的复杂请求特别有用。然而，这些计数器只测量**已存在的输入**；它们不预测将生成多少输出、推理或未来智能体步骤 token。

## 4、关键要点

✓ **访问内部模型状态比复杂的提示分析更能改善预测。** 在推理期间检查模型内部表示的方法始终优于仅依赖提示和其他外部信号的方法。

✓ **预测准确性更取决于任务狭窄性而非方法复杂性。** 响应长度对于重复、同质的任务相对容易预测，但随着提示和预期输出变得更加多样化而变得更加困难。

✓ **多步骤执行使不确定性远远超出单次调用预测。** 单个响应主要引入关于输出长度的不确定性。智能体工作流程增加了轨迹长度、重试、工具调用和扩展上下文的不确定性，使总成本更难预测。

✓ **现有工具测量过去的使用而不是预测未来的消耗。** 主要库可以准确地将观察到的 token 使用转换为成本，但它们通常不在执行开始前预测资源消耗。

---

原文链接: [LLM Cost Prediction: From Single Prompts to Agentic Systems](https://medium.com/@linafaik/llm-cost-prediction-from-single-prompts-to-agentic-systems-a4c85a6ae833?source=home%5Ffor%5Fyou---------10-102--------------------5744a141%5F46ba%5F486f%5F90aa%5Ffdeb6912439b-------15---------)

汇智网翻译整理，转载请标明出处

> **这是「AI 基建 / 评测 / 安全」专题的一部分。**完整地图见：[AI 基建 / 评测 / 安全完全指南](https://www.hubwiz.com/blog/ai-infra-stack/)