把重试预算算清楚：LLM 调用的「一次失败」到底成本多少
上周一个朋友的线上服务半夜报警。模型服务商那边一切正常，是我们这边 23% 的流量在重试。更值钱的证据在账单上：一个多月的 API 消耗里，有相当一部分 429 重试其实是在重复一个注定会失败的调用——那段时间服务商在降级，重试永远救不回来，钱照烧。
小火龙实验室
AI科普
把复杂的AI知识讲得让人类能听懂
为什么 LLM 会"一本正经地胡说八道"：幻觉的工程视角
做 AI 系统最常被问的一个问题：模型为什么会犯错？"幻觉"这个词听起来玄乎，拆开看其实是几件很具体的事。
慢不是模型慢：AI 服务延迟里藏着四个可量化的成分
上周帮一个团队看线上问题：客服机器人回答太慢，用户投诉，老板一句"换更快的模型"。换完之后，P95 延迟降了大概 400 毫秒，投诉还是没少。问题出在哪？他们只测量了"模型推理"这一段，但用户感知到的等待时间里，模型推理只占一小块。
为什么"换更大的模型"常常不是答案：AI 系统的选型与降级链
上次一个朋友被线上故障逼到墙角，第一反应是"把 GPT-4 换成更大、更贵的模型"。结果故障没好，账单倒是翻了一倍。这个反应本身没错——大模型确实更强。但大多数真实的线上问题，并不是"模型不够聪明"，而是工程侧没把冗余、成本、延迟这几件事理顺。先把这个区分清楚，后面所有选型决策才不至于跑偏。
推理超时不是玄学：给 LLM 调用设三个数
LLM 调用的超时纠结常常是这样的：20 秒太短，长 prompt 偶发被掐；120 秒太长，上游挂了你的队列先堵死。多数团队最后是拍脑袋定一个值，然后每次故障复盘都要重新吵一遍。
把种子钉死：LLM 复现问题的最小修
复现是工程里最便宜的质量信号：同一份输入、同一段代码、同一天跑两遍，结果一致，你才能判断这次改动是让系统变好了，还是运气好了。
15 分钟手工搭一套 LLM 评测集：不用 MLflow，不用平台
每次换模型、改提示词、调 temperature，你想知道结果会变好还是变坏，但只能拿刚生成的那几段读一遍，凭感觉说"感觉差不多"。这套流程撑得过 demo，撑不过生产：感觉不稳定，跨人不对齐，过两周你自己也记不清上次到底是什么水平。
给大模型加流控：为什么 QPS 不是越限越安全
很多团队把"QPS 限额"当成一个大数往下调，直到业务告警就再调低一点。但网关上的速率限制其实有个更微妙的角色：它是你和模型推理集群之间唯一的缓冲带。今天的主题就是这个缓冲带该怎么设，很多人第一直觉的答案是错的。
LLM API 调用重试怎么写：哪些错误该重试，哪些别碰
做过 LLM 服务的人都写过这段代码：调用失败，for 循环重试三次。看起来很稳，但生产事故里有一半跟这三行循环有关。LLM API 的失败行为和传统 HTTP API 不一样，重试策略得按它的特性来设计。