跳到主要内容

2 篇博文 含有标签「cost-management」

查看所有标签

模型迁移的双重账单:被忽视的评测重锚税

· 阅读需 11 分钟
Tian Pan
Software Engineer

每次模型升级都会被当作一种简单的“替换”推销给团队:一行配置更改、在延迟、成本或质量上可衡量的提升,以及几天用于吸收新模型怪癖的提示词微调。采购方案展示了每 token 的差值,工程工单列出了发布阶段,FP&A 团队预记了季度节省。接着,评估分值出炉,却没人认得出来。质量在理应提升的地方毫无波动。曾经达成一致的两个评分员现在分歧达 10 分之多。快照套件显示为红色,但差异看起来只是措辞调整。站会上有人提出了那个本应从迁移计划第一天就该出现的问题:模型到底是在针对什么评分?

这是第二张账单 —— 评估重锚税 (eval re-anchoring tax) —— 且它往往比第一张更昂贵。人工标注的参考分数锚定在旧模型的输出分布上。作为评委的 LLM 评分器针对旧模型的失败模式进行了校准。快照固定装置捕捉的是旧模型的措辞。团队对“优质输出”的直觉是基于旧模型的风格特征训练出来的。在模型替换中,这些都无法完好无损地保留下来。

非工作时间成本曲线:为什么你的 AI 功能在周六和周二的开销不同

· 阅读需 11 分钟
Tian Pan
Software Engineer

每个人都在看的成本仪表盘是一个周滚动平均值,而那个平均值正在对你说谎。并不是说数字本身是错误的——它是计费事件流的忠实算术平均值——而是它隐藏了底层的成本曲线形态。周五晚上到周一早上之间的 token 消耗方式,与周二上午 10 点到周四下午 4 点之间截然不同。周六凌晨 3 点活跃的群体与周二上午 11 点活跃的群体并非同一拨人,这些群体的单用户经济效益(per-user economics)差异巨大,但没人记录这一点,因为仪表盘通过平均值将其抹平了。

大多数团队第一次发现这一点,是在周末自动化脚本烧光预算的时候。一个 LangChain 智能体在周五晚上陷入了无限对话循环,运行了大半周才被人发现,导致产生了一张五位数的账单,周一早上不得不向财务部门解释。事后回顾将其视为一次性事件——糟糕的重试逻辑、缺失的预算上限、没有触发值班报警。但是,那个隐藏了失控循环的仪表盘,同时也隐藏了同一现象的稳态版本:每周都会出现的非工作时间流量基准,其单位经济效益在结构上比工作时间基准更差,而周平均值让这一切变得不可见。