运行 AI 智能体的真实成本

服务器价格只是智能体预算中的一行，通常远不是全部。合理的估算应沿着任务的完整路径展开：从用户请求，到模型调用、工具执行、结果保存，再到最终删除。同时也要计算没有人使用时，为保持系统随时可用而付出的费用。

本文提供的是规划方法，不是实时报价，也不是经过测试的省钱承诺。我们没有完成端到端部署或测量生产账单。购买前，请查看当前产品控制台和供应商价目表。促销额度应视为暂时抵扣，而不是服务长期运行成本的一部分。

从一个完成的任务算起

先定义你真正关心的产出：一份通过审核的报告、一份完成分类的文档，或者一个得到解决的客服请求。列出产生该结果所需的每一步。智能体可能多次调用模型、重复失败的工具操作、检索资料，甚至先总结已有上下文，最后才交付有用结果。

保留两个指标：每次任务尝试的成本，以及每个合格结果的成本。单次请求很便宜，如果经常需要人工修复，实际可能并不便宜。单独记录中途放弃、被拒绝或被限制器停止的任务。把这些任务排除在外，只会让预算显得漂亮，却隐藏实际支出。

试运行时，记录任务标识、模型、各类计费 token、工具费用、重试次数、耗时和最终状态。不要仅仅为了算账就保存完整提示。用量元数据通常已经能回答预算问题，同时减少客户内容的暴露。

对每一种计费 token，使用对应费率分别计算，再加上单独计费的工具和服务。供应商可能区分未缓存输入、缓存输入、缓存写入和输出，也可能按模型或处理模式采用不同价格。以实际请求返回的计费分类，以及当前 OpenAI API 价格说明或相应供应商价目表为准。

不要先用一个费率乘以全部输入 token，再额外加一次缓存输入费用。也不要假设每次重复请求都能享受缓存折扣。初期应保守估计，观察实际缓存使用情况后再调整。即使用户的新问题很短，较长的对话历史和大量检索段落，也可能增加后续轮次需要处理的内容。

准备三种场景：

故障场景不是用量预测，而是检验控制措施能否让糟糕的一天仍然负担得起。

分别列出应用计算资源、推理计算资源（如有）、数据库、块存储、对象存储、快照、自动备份、网络传输、域名和监控。如果升级或恢复演练需要临时第二台服务器，也要计入。

每一项都记录计费单位、预计数量、保留期限、负责人和移除步骤。区分预配容量与实际使用量。磁盘即使大部分为空，也可能按照已分配容量收费，具体取决于产品计费方式。估算实际扣款时，把税费和货币兑换单独列出。

Vultr 文档说明，自动备份需要额外付费，已保存快照也会产生费用。如果两者都用，就两项都计入。恢复副本的价值恰恰在于它能比原服务器保存得更久，而这也让被遗忘的副本成为持续支出。

规划网络费用时，要包括生成的文件、报告下载、浏览器流量，以及传往外部备份位置的数据。Vultr 的带宽计量说明将出站互联网传输列为计量对象，入站传输不计量。但仍应核对具体产品和网络配置的额度及超额规则，不要假设每一种网络路径都免费。

在 Vultr，停止的实例仍占用已分配资源，会继续计费。销毁实例会结束该实例的资源分配，但也会永久删除其数据。请查看官方的停止实例计费政策。

不要把销毁当成随手使用的预算控制捷径。先确认哪些状态需要保留，制作合适的导出文件或备份，并验证能够恢复。然后检查快照、存储订阅等独立资源。删除服务器，并不能证明整个项目已经不再产生费用。

告警只是通知某个人支出情况，不自动等于硬性停机。确认供应商实际执行哪些限制，并在应用中为工具步骤、模型输出、执行时间、并发任务和重试设置上限。决定达到上限后用户看到什么，以及如何恢复已经完成的部分工作。

上线前，指定谁接收账单告警、谁能够处理。收到第一张账单时，应逐项与资源明细核对，而不是只看总金额。调查无法解释的条目，并用合格结果的实际成本修订预算。可持续的预算还应包括人的时间：升级、恢复数据、审核异常操作，以及自动化失败时帮助用户。

目标不是得到最低的宣传月费，而是拥有一个能够解释的成本区间、一套可以验证的控制措施，以及不再需要服务时能够明确停止付费的方法。