北京
传统软件里，一个写坏的循环顶多让CPU飙一下。有人被叫起来处理，曲线回落，代价是一个卡顿的下午。
到了AI系统里，同样的错误变成了一张账单。每一次迭代都是一次付费的API调用，而计费器不在乎这次调用有没有用。一个跑了十分钟才被发现的循环，花掉的钱可能比这个功能一个月赚的还多。
教程版的LLM功能只有一次调用、一个响应，结束。生产版里有重试、有自我纠错步骤、有智能体调用工具、工具再调用模型，还有成千上万的用户同时在做这些事。每一个乘数，都是成本失控的入口。
三种最常见的失控方式
第一种，永远不收敛的自我纠错循环。
设想这样一个场景：智能体生成JSON，做校验，校验失败就把错误发回给模型让它修。这个模式本身很合理。然后一次schema变更上线，某个字段变得无法满足。模型不停地"修"，校验器不停地拒，循环就一直转下去。
没有任何东西崩溃。没有异常进入错误追踪系统。唯一的信号是那张发票。
修法是：每一个重试和纠错循环都要有硬上限，限制尝试次数，也限制token总量，撞到上限要记录为失败，而不是静默降级。
代码里可以这样写：设置最大尝试次数为3，总token上限为20000，每次调用累加用量，超出预算就抛出异常，尝试次数用尽也抛出异常。同样的逻辑适用于智能体：限制每个任务的工具调用次数和模型调用次数，而不只是限制每个请求。
第二种，流量线性增长，成本不是。
普通接口遇到流量高峰，多花一些算力。一个每次请求要扇出好几次模型调用、每次调用还带着长上下文窗口的接口遇到流量高峰，花掉的是好几倍。
如果一个用户操作触发了一次摘要调用、一次分类调用和一次嵌入调用，那么每次请求的成本就是三个计费API的总和。用户翻倍，这三个成本全都翻倍，还没算重试。
修法是：像了解每次请求的延迟一样，了解每次请求的成本。给功能设一个预算，提前决定预算撞线时降级什么——换更便宜的模型、缩短上下文、返回缓存答案，或者干脆不输出AI结果。
第三种，没有按用户设限。
全局速率限制保护的是你的供应商配额，它保护不了你不被某一个用户（或者某一个脚本，或者你自己前端里每渲染一次就重发一次请求的bug）吃掉不成比例的份额。
设想这样一个场景：一个聊天功能没有按用户设上限。一个集成测试被误指向生产环境，整个周末以紧密循环发送请求。全局限制从未被触及，所以什么告警都不会响。
修法是：按用户、按API密钥、按租户分别设置速率限制和token配额。像对待鉴权一样对待它们：不是可选项，而且在边缘执行，不是深埋在某个处理函数里。
监控现在是个财务问题
可用性仪表盘告诉你系统有没有在跑，它不会告诉你过去一小时维持运行花了多少钱。对AI功能来说，两样都需要。
- 按功能、按用户、按租户统计的token和支出，接近实时
- 对支出速率告警，而不只是对错误率告警
- 一个开关，在功能越过阈值时把它关掉，不需要重新部署
换个角度看：一次LLM调用不是一次函数调用，它是一笔采购。你的架构应该把每一个循环、每一次重试、每一次扇出，都当成一次附带限额的支出决策。
如果生产环境里没有硬性的成本控制，你跑的不是一个功能，你跑的是一张敞开的账单。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
