861 篇博文 含有标签「insider」

将你的 GPU 推理自动缩放至零（Autoscaling to zero）看起来是显而易见的成本控制策略。GPU 是账单中最昂贵的项目，流量具有突发性，而空闲时间纯粹是浪费。所以你开启了缩放至零（scale-to-zero），看着云端账单下降，并以此自得。

然而，在一段沉寂之后，一位用户出现了，他们的第一次请求需要 60 秒才能返回一个 token。运行 Serverless LLM 推理的生产部署经常报告冷启动超过 40 秒才出现第一个 token —— 相比之下，模型预热后的每个 token 延迟大约仅为 30 毫秒。这是冷路径和热路径之间千倍的延迟差距，而这完全取决于你的流量空闲情况。

这是没有人会写在 PPT 上的权衡。缩放至零并没有消除成本；它将稳定的金钱成本转化为了突发性的延迟成本，然后将这种延迟成本隐藏在仪表盘很少关注的 p99 尾部。

每个智能体 (Agent) 架构图中都有一个标记为“上报给人类 (escalate to human)”的方框。它用一条整洁的箭头画出，既能让评审人员满意，又能让系统显得安全。然而，架构图从未展示过箭头另一端的人——他们是否存在、是否醒着，以及是否能在智能体耗尽耐心之前给出答复。

人机回环 (Human-in-the-loop) 被当作一种设计模式来推销。但在生产环境中，它的表现更像是一个人员配置问题。这种模式假设有人在随时待命；而人员配置的现实是，上报请求并不会在人类刚好有空时出现——它们有自己的“时间表”。比如凌晨 2 点，当夜间批处理任务触发护栏 (guardrail) 时出现的爆发式请求。或者是午餐时间，当一半评审员都不在座位上时产生的长尾延迟。又或者是细水长流般的请求量，在不知不觉中超出了那支在演示阶段看起来绰绰有余的双人团队——毕竟在演示阶段，智能体每天只处理 10 个请求，而不是 1 万个。

“我们有上报路径”与“上报得到响应”之间的鸿沟，正是智能体系统发生故障且评估 (eval) 无法捕捉的地方。评估衡量的是智能体是否正确地发起了上报，而从未衡量过是否真的有人在那里。

值班轮换制度是建立在一个承诺之上的：故障是可以复现的。警报触发，你重新运行请求，观察 Bug 发生，找到错误的提交 (commit)，然后回滚部署。这个循环的每一个环节都假设了确定性 (determinism)。同样的输入产生同样的输出，而输出要么是对的，要么是错的，其方式一目了然。

Agent 集群悄无声息地打破了这条链条上的每一个环节。故障发生了一次，其采样温度 (sampling temperature) 你无法重现，所处的上下文窗口 (context window) 也早已被垃圾回收。这里没有“错误的提交”，因为代码从未改变 —— 改变的是模型，或者是检索到的文档，再或者是用户措辞的方式超出了所有人的预料。你回滚了部署，但部署从来都不是问题所在。

于是警报发出了，一名工程师接手了。他们发现了在生产环境中运行 Agent 最令人不安的事实：他们拿到手的是一个无法单步执行 (single-step) 的系统，而摆在他们眼前的运行手册 (runbook) 却是为另一种完全不同的机器编写的。

在每个 AI 功能的演进过程中，审阅者总会提出一个听起来很合理的问题：“我们能不能让模型告诉我们它的置信度（confidence），这样我们就可以把低置信度的回答路由给人工或备选方案？”这听起来像是一份免费保险。你在输出 schema 中添加一个 confidence 字段，模型尽职尽责地填好它，现在你就有了一个可以调节的旋钮。发布吧。

那个旋钮并不是免费的，更糟糕的是，它通常没有连接到任何实际逻辑上。置信度数字只是模型乐于生成的一个 token 序列，模型并没有义务让它具有实际意义。团队支付真实的 token 和延迟来获取它，却从不检查它是否与正确性相关，然后根据它路由生产环境的流量，就好像 “0.9” 真的代表 90% 的可靠性评估一样。它就像一个用螺栓固定在仪表盘上的压力表，但玻璃后面其实什么也没连。

这篇文章讨论了两个没人定价的成本：生成置信度字段本身的单次请求税，以及信任一个未校准的数字来做路由决策所带来的更巨大的成本。

每个评测套件（eval suite）最终都会被精简。有人注意到套件运行需要 9 分钟，每次运行成本 40 美元，而且里面充满了没人记得为什么要写的用例。他们提交了一个名为 “清理陈旧评测用例” 的 PR，删除了 40 条 “看起来不再相关” 的条目，CI 运行时间降到了 4 分钟。PR 获得了点赞。没人反对，因为删除测试看起来就像是在做维护。

这不是维护。每一个评测用例都是团队对自己做出的承诺：这种失败模式不会再静默地发生。 删除用例就意味着撤销了这项保证。通过率没有变化，仪表板依然是绿色的，唯一消失的是团队对这项保证曾经存在过的记忆。六个月后，一次模型迁移重新引入了被删除用例所防范的回归，复盘（postmortem）重新发现了团队已经支付过代价的教训，然后有人写道 “我们应该为此添加一个测试” —— 而这个测试正是之前在清理 PR 中被删除的那个。

你构建过的每个分布式系统都依赖于一个隐形的假设：超时后的重试是安全的。操作是幂等的，因此如果客户端放弃等待并重新发送，最坏的情况也只是重复工作，并最终收敛到相同的状态。两个 PUT 请求落地同一行。两个 DELETE 请求留下同样的空缺。重试只是伪装成第二次尝试的“无操作”（no-op）。

LLM 调用打破了这一假设，而且是悄无声息地打破。重试并不会重新获取相同的答案 —— 它会采样一个新的答案。当客户端因为响应在传输中丢失而在网络层超时，但提供商实际上已经完成了生成时，重试会产生第二个、不同的答案。现在，对于一个逻辑请求，存在两个不同的输出，而你的技术栈中没有任何部分知道哪一个是权威的。

这并非罕见的极端情况。在模型背后运行超时机制的从业者报告称，即使底层调用最终成功，仍有 5–10% 的请求会触发完整的超时加重试循环。其中的每一次重试都是一次抛硬币，而你的系统从未被设计成去裁定这种结果。

一个工程师花了一个下午钻研一个问题：智能体 (agent) 能否根据合同条款核对客户的发票？他们编写了一个简单的提示词，在五份真实发票上运行，结果三份是正确的。另外两份的错误方式他们还没完全搞清楚——于是他们关上电脑，继续做别的事。在第二天早上的站会上，他们说：“是的，发票核对基本上能用了。”房间里的 PM 记下了这一点。两周后，它成了 Q3 路线图上的一个项目。一个月后，一位销售代表在续约电话中向一家大客户承诺了这项功能。

没有人撒谎。没有人孤立地做出错误决定。但团队现在已经在合同上承诺了一种行为，而这种行为的评估集 (eval set) 并不存在，其失败模式从未被记录，其可靠性预算是由一位看了演示并将其解读为正式合同的总监设定的。这是 AI 功能获取范围 (scope) 最常见的方式：不是通过规划会议，而是通过一个从未被明确提升地位的能力探索 (capability probe)。

行业对这种下游症状有一个称呼——“POC 炼狱” (POC purgatory)，即 70% 到 80% 的 AI 项目在可运行的沙盒和可交付的产品之间停滞不前的状态。但“炼狱”是一个错误的比喻，因为它暗示项目被困住了。它们并没有被困住。它们在移动——在有人检查它们是否准备好之前，它们就被承诺了，现在团队正试图将可靠性强行填补到一个承诺中。

当你第一次尝试像调试服务那样调试 Agent 时，你会发现以往的肌肉记忆完全派不上用场。你设置了一个假设的断点——虽然 IDE 中没有面板可以放置它，但你在脑海中想象了一个——就在 planner 选错工具的那一步。你使用相同的输入重新运行。这一次，planner 选择了正确的工具。你再次运行。它又选了一个你从未见过的第三种工具。Bug 是真实存在的，你的同事今天早上复现了两次，而你用了十五年的调试器突然间变成了博物馆里的陈列品。

这里失效的心智模型并不是“使用调试器”，而是背后更深层的假设：即一个程序在给定相同输入的情况下，会产生相同的执行过程。现代调试器中的每一项功能——断点、单步跳过 (step-over)、观测表达式 (watch expressions)、条件断点、热重载——都是建立在这种确定性之上的。你暂停执行是因为暂停是有意义的。你向前单步执行是因为下一步是可预知的。你检查一个变量是因为它的值是一个事实，而不是从某种分布中随机抽取的结果。

你正在对接的采购团队最终会提出一个重置你架构的问题：“我们可以自带模型 API 密钥吗？”回答“可以”能赢得订单。但回答“可以”同时也意味着你的信任边界、成本边界和运营边界发生了转移 —— 而大多数产品团队只有在合同签署、第一个月的使用产生了一个没人知道如何回答的服务工单后，才会发现这一点。

BYOK 在公司内部推销时被视为一个开关。客户粘贴一个密钥，你的代码从保险库（Vault）读取它而不是从你自己的账户读取，然后推理流程照常进行。但这并不是一个开关。这是一场由销售驱动的架构重构，它会波及成本分摊、安全事件响应、可观测性、速率限制、模型版本锁定以及值班问责。那些在没有意识到这一点的情况下就交付产品的团队，最终会在一年后为了修复这些问题而重构整个平台层，而付费企业客户则在焦急等待。

团队最开始有 5 个工具和一个在生产流量中命中率达 95% 的规划器（planner）。18 个月后，他们有了 51 个工具，而规划器的命中率降到了 26%，原本那 5 个工具能干净利落处理的简单案例——预订会议、查询客户、提交工单——现在有时会路由到错误的工具，因为目录中有三个听起来很像的“替代品”。没有人故意让规划器变差。每一次工具的增加在当时看来都是合理的。这种累积的代价就是“可组合性税”（composability tax），每一个在工具目录增长过程中缺乏淘汰机制的产品都在支付这笔费用。

这笔“税”是一条曲线，而不是悬崖。Berkeley Function Calling Leaderboard 直接测量了这一点：在日历调度任务中，当跨多个领域的工具从 4 个增加到 51 个时，准确率从 43% 下降到了 2%。在客户支持类任务中，GPT-4o 从 58%（单一领域，9 个工具）下降到 26%（7 个领域，51 个工具）。Llama-3.3-70B 在同样的扩张下从 21% 降到了 0%。这种趋势在不同模型和任务类型中不断重复：每增加一个工具，规划器就会在曲线上进一步下滑，而且随着目录变大，边际损害会变得更严重，因为新加入的条目与现有的条目越来越难以区分。

你的状态页是一片绿色。你的错误率为零。你的运行时间仪表盘连续第七个月显示为 100%。然而，在周二上午 9:14，你的客户团队给你转来了一条来自一家财富 500 强客户的消息，上面写着：“我们的团队注意到这周助手的表现变差了。你能告诉我们发生了什么变化吗？”午饭前，你又收到了 12 条类似的反馈。现有的事故沟通手册（incident-comms playbook）无法回答其中任何一个问题，因为那套手册是为停机事故准备的，而现在没有任何东西崩溃。

这就是面向客户的 AI 复盘难题，也是我在将 LLM 功能交付给企业合约的团队中看到的最普遍的差距。可靠性的维度已经从“系统是否在线”转向了“系统是否和上周一样好”，而几乎没有任何沟通基础设施跟上了这一变化。状态页上没有相应的展示块。严重性等级标准（Severity rubrics）没有对其进行评分。支持服务的回复模版默认为“我们发现了一个问题并已解决”，这取决于客户当天的情绪，听起来要么是敷衍，要么是危言耸听。

新员工打开入职文档。文档指向了十一个月前的一个服务架构图、一个最后更新于十月的名为 “我们的 LLM 技术栈” 的 Confluence 页面，以及一个 “我们使用的模型供应商” Notion 表格。这些文档都没有告诉他们哪个提示词是针对哪种失败模式优化的，哪些评估案例是在哪次事故后添加的，当模型从 4.5 升级到 4.6 时哪个评判模型被重新校准了，或者为什么支持代理的系统提示词有一段谁都不敢动的奇怪的三行前导内容。入职两周后，他们提交了一个 “小的提示词清理” PR，删除了这段前导内容。评估套件通过了。不到一天，生产环境的准确率下降了四个百分点。

标准的新员工入职指南 —— 阅读架构文档、配置电脑、在第二周前完成第一个 PR —— 是为加入服务端的工程师设计的。AI 工程师加入的是一种不同的制品。他们要编辑的不是某个主任工程师写的 5000 行 Go 服务；而是一个经历了 11 次事故和 17 次评估驱动重写的 30 行提示词，而这 30 行代码的意义只存在于团队中两个人的脑子里。你的入职文档无法捕捉到这些，而尝试写一份更长的文档是错误的修复方案。