7 篇博文 含有标签「cost」

当工程师推介AI功能时，成本讨论几乎总是围绕推理API展开。每个token多少钱？按预期调用量估算每月费用是多少？能否争取到批量折扣？这是一个错误的对话——或者至少是不完整的。

在实践中，推理账单大约占运行一个成熟AI功能实际成本的20-30%。其余成本分散在一系列不会出现在LLM提供商发票上的支出中：检索管道依赖的向量数据库、填充它的嵌入任务、捕捉静默失败的可观测性平台、验证模型输出的人工审核员，以及花费数周调整提示让一切正常运转的工程师。团队通常在上线六个月后才发现这一点——当他们试图解释一个比预测高出3-5倍的成本中心时。

一个用户在周二下午 3 点打开了你的 AI 功能。他们已经轻度使用了三周。这次请求卡住了 8 秒钟，然后返回了一个红色的横幅：“出错了。请稍后再试。”他们又试了一次。还是同样的横幅。他们关闭了标签页，回去做之前在做的事情 —— 并在第二天早上的站会上告诉队友，“那个 AI 功能坏了。”

实际发生的情况是：他们触碰到了一个隐形的单用户配额，这是你的成本团队在六个月前为了防止单个重度用户刷爆 GPU 预算而设置的。配额起作用了。支出保持平稳。仪表盘显示绿色。按照你的工程组织追踪的每一个指标来看，这项功能都是健康的。但它也已经名存实亡了，因为看到那个横幅的用户再也不会回来了，而且他们在站会上告知的那三个队友也永远不会去尝试它。

这就是你的成本仪表盘看不见的鸿沟。单用户 AI 配额是一个产品界面（product surface）。那些将其隐藏在 HTTP 429 错误代码中的团队，正任由其成本控制系统默默地塑造用户对产品的认知，而且直到流失率在季度回顾中显现出来且没有明显原因时，他们才会发现这一点。

这里的数学逻辑很简单，但没人去算。在 AI 时代之前，单个用户操作（例如“总结这张工单”或“发送这封邮件”）只会产生一行应用程序日志。而在 AI 时代之后，同样的操作会产生一条请求日志、一个 LLM 调用追踪、代理调用的每个工具的工具调用 span、它读取的每个数据块的检索 span、一条响应日志，如果你采样进行离线评分，还会产生一条评估日志。一次用户点击的扇出（fan-out）现在会在你的可观测性流水线中产生 30 到 50 条记录，这还是在重试、子代理以及会让一切翻倍的规划器-执行器（planner-executor）拆分出现之前。

你在第一季度发布了一个 AI 功能。到了第二季度，你的安全总监拿着一份比上一个周期高出 4 倍的 Splunk 续订合同走进预算审查会议。AI 团队的人都不在现场。接下来的对话——关于谁来承担这笔费用、为什么威胁检测规则失效了，以及是否真的必须对每次对话进行法律保留（legal hold）——是你在设计阶段就应该进行但没有进行的对话，因为这笔成本没有出现在 LLM 的发票上。它出现在下游，出现在一个 AI 团队从未登录过的工具中。

我认识的一个团队花了三周时间追踪一个“上下文截断”的 Bug，这个 Bug 只在针对日本客户的生产环境中触发。他们的 CI 测试用例是英文的。他们的 tiktoken 计数显示 Prompt 符合 8K 的限制，且留有 600 个 Token 的余量。但供应商的账单显示，该请求因超过限制而被拒绝。这两个数字相差 11%，而安全余量正好落在在那 11% 之内，而且从未有人衡量过中日韩 (CJK) 文本上的这种差异。修复方案不是换一个新模型——而是不再将本地计数器作为事实标准。

这就是 Tokenizer 漂移那种隐蔽且昂贵的形式：不是一个简单的错误数字，而是一类在被你忽略的测试边界处累积的小型系统性误差。你 IDE 中的本地计数器、网关中的预算计算器、重试中间件中的速率限制评估器，以及供应商据以收费的权威计数——这些都不一致，而且差距恰恰在你用户所在的领域扩大。

Temperature 之争是 AI 工程中最具宗教色彩的争论，也是最没效率的争论之一。每个团队都会形成两个阵营：决定论者希望将所有地方的 Temperature 都固定为 0，因为他们无法调试不稳定的系统；而创意论者则希望调高它，因为这样输出结果感觉更“有灵性”。两者都错了，因为他们都在错误的层面上回答这个问题。Temperature 不是一个全局设置。它是一项预算——就像任何预算一样，它应该被分配，而不是被宣告。

高效的框架很简单：系统中每个模型调用都有其目的，随机性要么在那个层面（surface）发挥作用，要么就不该存在。决定下一个调用哪个工具的规划器（planner）无法从变化中获益；选错一个工具就是调试噩梦，而且没有任何创意上的好处。如果一万个用户看到的摘要措辞都一模一样，那么为他们总结搜索结果的响应合成层很快就会显得呆板——SEO 团队最终会标记这些样板内容。一个让模型提出备选方案供人类选择的头脑风暴层，在 Temperature 为 0 时表现反而 更糟；多样性本身就是其核心功能。

如果你无法清晰地说明随机性在特定调用位置的作用，你就不应该为此付费。

大多数构建 LLM 的工程师最终都会学到一个粗略的换算比例：1 个 Token 大约等于 0.75 个英文单词，因此 4,000 个 Token 的上下文窗口大约可以容纳 3,000 个单词。当你的输入是日常英文文本时，这个数字用于粗略估算还可以。但在其他任何地方，它都是悄无声息地错误——而事实证明，“其他任何地方”涵盖了大多数有趣的生产环境负载。

Token 计算错误不会大声报错。它们表现为与任何账单项目都不匹配的成本超支、上下文窗口悄悄截断了文档的最后几段，或者是多语言流水线在英文测试中表现良好，但在遇到真实流量的第一周就超出了 4 倍预算。当你追溯到 Tokenizer 分词问题时，损失已经造成。

一家金融科技团队基于 GPT-4o 构建了他们的 AI 聊天机器人。第一个月：1.5 万美元。第二个月：3.5 万美元。第三个月：6 万美元。预计年支出将达到 70 万美元，他们慌了，并决定转向自托管。六个月后，在耗尽了一名工程师的精力后，他们每月在基础设施、一名兼职 DevOps 工程师以及三次导致生产环境宕机的 CUDA 事故上花费 8.5 万美元。他们最终将开支降到了每月 8000 美元 —— 但并不是通过全盘自托管实现的，而是通过智能路由。

这两个决定都是错误的。真正的失败在于他们从未进行过实际的成本核算。