2 篇博文 含有标签「llm-infra」

你的微调变体在平稳的工作日每分钟处理几百个请求，p99 延迟仪表盘基本保持平稳。然后，在周二当地时间 03:14，某个请求的 p99 延迟从 800 毫秒飙升至 4.6 秒，随后恢复正常。第二天晚上，同样的情况再次发生，模式基本一致，时间也大致相同。你向供应商提交了一个工单询问这次飙升。得到的回复准确但毫无用处：他们的仪表盘显示其侧没有任何异常，没有速率限制，没有故障，在飙升时刻你的 token 使用量也很寻常。4.6 秒确实发生了。但账单上没有体现。

这种差距——用户明显感受到的延迟事件与未记录任何异常的账单之间——就是“微调冷启动税”的体现。这并不是你代码中的 bug，也不是供应商侧的性能回退。它是两种计费模式交汇的缝隙：供应商向你收取适配器上的活跃推理时间费用，而将适配器“加载”到服务槽位的成本隐藏在了供应商的基础设施层，在那里，它表现为你的延迟，却是他们的成本。如果你的流量模式低于供应商的预热阈值，那么每次流量回升时，你都要为 p99 延迟中的这段往返时间买单。

一个模型提供商发布了 99.9% 的可用性 SLA。采购团队将其理解为“三个九，每年四个小时的停机时间，对于非 0 级（非核心）工作负载是可以接受的”。六个月后，智能体（Agent）功能上线，值班仪表板显示用户感知的任务成功率约为 98% —— 这个数字没有写进任何合同，在提供商的状态页面上也找不到，而且没有人为此负责。提供商满足了他们的 SLA，而产品却没达到其 SLO。两者同时成立，而这种差距并不是一个 bug —— 这是一个算术问题。

大多数团队都忽略了算术这部分。提供商的 99.9% 是针对同步请求工作负载进行衡量的 —— 一个用户，一个提示词，一个响应，一个计费事件。而智能体并不会产生这种工作负载。一个用户感知的任务会扇出（fan out）为 8 到 20 次推理调用，它会对瞬时错误进行重试，对慢速调用进行对冲（hedge），并聚合部分输出。每一次调用都是对提供商故障分布的一次独立抽样，如果任何关键调用失败，任务就会失败。SLA 覆盖的边界和用户感受到的边界并不是同一个边界。