跳到主要内容

33 篇博文 含有标签「inference」

查看所有标签

你发出的流式中止信号,供应商照样收了费:账单中隐藏的 14% 差额

· 阅读需 11 分钟
Tian Pan
Software Engineer

你的财务团队发起了一项申诉并失败了。该账单项是“输出 token”,它比你交付 token 总数的统计指标高出了 14%。供应商的支持工程师以“流式传输取消下的预期行为”为由关闭了工单,并附上了一份文档链接,上面写着“取消操作将在最后一个交付的 token 处停止计费”。这两句话都是事实,而它们之间的差距,正是你尚未编写的那行代码。

你阅读的合同是一回事,推理调度器的实际操作是另一回事。这种不匹配既不是 bug,也不是计费错误,更不是恶意欺诈——它是一个分层系统,取消信号必须穿越三个边界(浏览器、边缘节点、GPU),而计费表位于第三个边界,但你的“停止生成”按钮却位于第一个边界。缩小这一差距是一个由财务负责人发起的工程项目。

在解码中途缩减至零的自动伸缩器:当推理被视作无状态网络流量时

· 阅读需 13 分钟
Tian Pan
Software Engineer

集群完全按照我们的指令行事。流量在 45 秒内降至零,队列深度指标也归于平寂,KEDA 将副本数从 1 改为 0,90 秒后,节点自动扩缩容工具回收了 H100 Pod。图表看起来很干净。Slack 频道一片寂静。成本看板上的数字跳低了半美分。

一小时十二分钟后,一封客户支持工单送达:一个长时间运行的文档分析任务——一个预算为 28 分钟解码时间的 180k-token 推理任务——消失了。客户端 SDK 没报错。应用程序日志没异常。只有网关访问日志中埋着的一行 499,时间戳大致就在调度器判定 Pod 空闲并将其回收的时候。

你的评估套件设置了确定性种子,但供应商却悄悄忽略了它

· 阅读需 13 分钟
Tian Pan
Software Engineer

你设置了 seed=42。你设置了 temperature=0。你记录了运行情况,发布了仪表板,并在模型更换上签了字。第二天早上,重新运行相同的提示词却返回了不同的数字,你给出的解释——“肯定是采样噪声”——错得离谱:根本没有采样,而且噪声是结构性的。Seed 离开了你的客户端,网关将其丢弃,内核将你的请求与 17 个不相关的请求打包在一起,浮点归约(floating-point reduction)顺序在你眼皮底下发生了变化。你所谓的“可复现”基准测试,距离变成另一个基准测试其实只差一个批次(batch)。

这种失败模式是悄无声息的,因为技术栈中的每一层在技术上都是正确的。SDK 接受了 seed。供应商记录了 seed。模型返回了 system_fingerprint。评估工具记录了这三者。没有 5xx 错误,没有警告,没有抗议。仪表板上的数字只是发生了偏移,而团队将这种偏移合理化为一直存在的某种抖动——因为他们没有工具能告诉他们,他们看到的究竟是随机解码(stochastic decoding),还是导致三周的对比实验全部失效的后端轮换(backend rotation)。

确定性种子:为什么供应商将其视为“提示”而非“契约”

· 阅读需 12 分钟
Tian Pan
Software Engineer

CI 测试只有一个断言:相同的模型、相同的温度、相同的提示词、相同的种子(seed)、相同的输出字符串。它在每个开发者的笔记本电脑上都通过了,在前一百次 CI 运行中也通过了,但在三周内每五十次运行就会出现一次随机失败(flake),直到最后有人承认这种模式是真实存在的。第一个假设是显而易见的——测试工具中某处存在非确定性依赖——三天的调查却一无所获。实际原因隐藏在供应商 API 参考文档的一个脚注中:“seed 提供尽力而为的确定性。”团队读到了参数名称,并将其视为一种契约。而供应商记录的只是一个提示。

这是托管推理的一种特定失败模式,它困扰着那些围绕单一心智模型设计测试基础设施的团队:模型是其输入的纯函数,而 seed 是使函数具有可重现性的关键。在生产环境中,这个模型的这两个部分都是错误的。API 表面与底层物理原理之间的差距如此之大,以至于团队在供应商明确否认的假设之上,构建了整个评估和回归测试栈。

批处理负载挤占了你的实时路径:GPU 预留的惨痛教训

· 阅读需 10 分钟
Tian Pan
Software Engineer

每晚的微调任务在 UTC 时间 02:00 开始。它进入共享 GPU 池,占用它能找到的每一个槽位并持续持有。到 09:30,当工作日的首波推理流量到达时,自动扩缩器(autoscaler)试图声明已被连续占用七个半小时的容量。早晨的前 90 分钟,系统运行在约为基准 p99 延迟四倍的水平上。仪表盘报告了一个“喧闹的早晨尾部(noisy morning tail)”,推理团队将其归因于用户行为,因为实际的资源争用发生在一个推理团队并不拥有的任务队列中。

这是你在容量评审的成本归因幻灯片中无法捕捉到的 GPU 共享失败模式。共享被宣传为利用率的胜利——晚上训练,白天服务,填补低谷。实际交付的却是直到池按延迟类别(而非按团队或按时间)进行分区之前,你都无法摆脱的延迟长尾。

不属于你的那次变慢:对话中途的 KV 缓存逐出

· 阅读需 11 分钟
Tian Pan
Software Engineer

一段对话在同一个 Claude 会话里跑了四十分钟。十一轮回合,每轮平均首字延迟(TTFT)800ms,每轮都很便宜——因为那段 28,000 token 的前缀命中了提示词缓存。第十二轮到来,TTFT 飙到 3.4 秒。对话的形态没变,模型没切换,网络也正常。缓存输入 token 从 27,800 掉到 0。下一轮的 prefill 账单从第一个 token 起就全额计费。

你去追踪里找原因,没有任何一条日志写着"另一个租户的突发流量把你逐出了缓存"。对这次毛刺最诚实的解读是:在同一片 GPU 池的某处,另一个客户的 prompt 让调度器认为,丢掉你这段温热的前缀是代价最小的选择。你无法重放这一轮,无法证明那次逐出。那一刻的缓存状态是陌生人流量的函数,而那些流量不在你的追踪里,因为它们本来就不属于你。

那个悄然演变成延迟敏感型服务的夜间批处理作业

· 阅读需 11 分钟
Tian Pan
Software Engineer

这一切始于一个 cron 作业。每晚凌晨 2 点,一个脚本会被唤醒,拉取当天的记录,通过模型运行,将结果写入表中,然后继续休眠。这是解决该问题的最简单形态,而且在整整一年的时间里,它确实是最合适的形态。没有人去考虑它,因为没有人需要去考虑。

接着有人问结果能否在早上 8 点而不是中午准备好。然后有人问用户是否可以按需触发单条记录的运行。接着一位产品经理问是否可以让应用内的体验“感觉像是即时的”。每个请求都是合理的。每一次改动都很小。而且从始至终,没有人打开过一份名为“重新架构推理流水线”的文档,因为没有任何一次单一的改动让人觉得像是在重写。

18 个月后,你拥有了一个披着批处理作业外壳的延迟敏感型在线服务。它的 p99 无人衡量,队列无人清理,且存在一种失效模式:由于流水线被构建为重试整个批次,一条错误记录就会导致面向用户的请求停滞。这是 AI 系统中最常见的架构失效之一,而且它几乎从未作为一项决策出现,而是作为对一系列合理请求不断说“是”而产生的缓慢累积。

温池与冷真相:Serverless LLM 推理中隐藏的延迟底线

· 阅读需 10 分钟
Tian Pan
Software Engineer

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

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

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

LLM 尾部延迟:为什么在 P50 表现良好时你的 P99 却是一场灾难

· 阅读需 12 分钟
Tian Pan
Software Engineer

你的 LLM API 返回的 P50(中位数)延迟为 800 毫秒。你的仪表板显示为绿色。你的 SLA 规定“两秒以内”。接着,一个用户提交了工单:“它转了 30 秒然后就放弃了。”你检查日志,发现 P99 延迟高达 28 秒。

这种差距——中位数与尾部延迟之间 35 倍的比率——并非偶然。这是 LLM 工作原理的结构性属性,仅仅通过调整超时时间是无法消除的。

生产环境中的扩散模型:演示之后无人讨论的工程栈

· 阅读需 13 分钟
Tian Pan
Software Engineer

你的图像生成功能刚刚走红。每天有 100,000 个请求涌入。API 提供商的速率限制在技术上可以应对。但 p95 延迟爬升到了 12 秒。你的 NSFW 分类器正在误报合法的医学插图。合规性审计显示,加州的《人工智能透明度法案》(AI Transparency Act)要求自 2024 年 9 月起添加水印。支持团队收到了 50 个来自内容被静默拦截的用户的待处理工单。当你意识到需要一套真正的生产级技术栈时,你已经在危机模式中虚耗了两周。

这就是“直接调用 API”失效的时刻——不是因为 API 本身不好,而是因为演示的成功暴露了你对推理延迟、内容策略、审核公平性和监管合规性所做出的每一项假设。教程中从未展示过的工程工作就在这里。

思考预算:扩展推理模型何时真正具备经济意义

· 阅读需 11 分钟
Tian Pan
Software Engineer

令人惊讶的是,许多 AI 团队一旦获得 o3 级别或 Claude 扩展思考模型的访问权限,就会默认对所有查询启用扩展思考。这背后的逻辑看似显而易见:更智能的推理等于更好的输出,何不始终开启?问题在于,这种逻辑没有考虑到测试时计算扩展在实践中如何运作的基本事实。扩展思考能显著提升特定类型任务的性能,在另一些任务上则会降低质量,并可能将全局推理成本推高 5-30 倍。那些从这些模型中获取最大价值的团队,将推理预算作为一个明确的决策来对待——其重要性不亚于模型选择或提示词工程。

本文阐述了任务分类体系、成本结构,以及将战略性使用思考预算的团队与仅仅为质量幻觉溢价买单的团队区分开来的路由决策框架。

预算倒置陷阱:为什么你最重要的AI功能却在用最便宜的推理模型

· 阅读需 9 分钟
Tian Pan
Software Engineer

大多数团队通过将更便宜的查询路由到更便宜的模型来优化AI推理成本。这听起来合理——但实际上是本末倒置的。首先被降级到廉价模型的查询,并不是那些简单的。恰恰相反,它们是复杂的查询,因为这些才是FinOps仪表盘标记出来的昂贵查询。

结果是:你的合同续签工作流——那个负责敲定六位数交易的关键环节——却在一个会产生幻觉、捏造条款引用的模型上运行。而你的客户支持分类——真正低风险的入门级任务——却享受着顶级模型的待遇,仅仅因为还没有人抱怨过它。

这就是预算倒置陷阱。它的产生并非源于疏忽,而是在没有价值背景的情况下单纯施加成本压力所带来的可预见结果。