在 AI 服务上线前的常规检查中，/healthz 返回 200 常被视为服务已经可用。但 Dev.to AI 的一篇工程笔记记录了一次相反经历：健康检查在几毫秒内通过，批处理发出的首批真实请求仍然失败。作者花两天时间排查后发现，问题并不在模型本身，而在于“就绪”被定义得太浅：HTTP 探针只确认 Web 层可以响应，没有确认模型路径已经能够处理即将到来的请求。
健康检查通过后，批处理仍撞上冷模型服务器
这项任务本身并不复杂：整理一批应用日志文件，按失败签名分组，再让语言模型为每组写一段简短摘要。作者将批处理脚本接到一个 OpenAI 兼容端点，并使用 MonkeyCode 的免费模型访问，在免费服务器选项的非高峰时段运行。脚本完成了几件基础工作：读取文件、构造提示词、调用端点、写入 JSON。
但它也做错了一件不显眼的事：把成功的 HTTP 探针返回，理解成模型已经可以服务。当容器报告健康后，任务执行器立即向共享端点发送请求，结果首批请求失败，同一时刻的重试也以同样方式失败。作者将这种现象概括为“冷启动缺口”：一个已经接受流量的冷工作进程，可能比直接关闭端口更容易误导调用方，因为健康检查持续返回调用方希望看到的结果。
“服务在线”至少有三层含义
这篇笔记把“up”拆成三个不同判断：
- 套接字能接受连接，只说明进程存在。
- HTTP 处理器返回 200，只说明 Web 框架已被调度。
- 模型能针对即将发送的请求形状产生 token，才是批处理真正依赖的条件。
作者的探针只验证了第二层，批处理却按第三层行动。这种错位不是细节疏忽，而是类别错误。/models 接口也不能替代验证，因为模型目录可能已经可访问，但对应模型是否可生成仍未被确认。作者给出的做法是：在批处理启动前，用与真实任务相同或接近的请求形状做一次最小化探测。
示例脚本会向 /chat/completions 发送请求，参数包括 model、messages、max_tokens 为 1、temperature 为 0，并在 120.0 秒内循环等待；每次请求超时时间为 10 秒，失败后等待 1.5 秒再试。只有当返回状态码为 200，且 choices 中出现 message 时，才认为模型真正就绪。
重试要回答“还有没有时间”，而不是“试了几次”
第二个教训来自重试策略。作者最初按次数重试，但很快发现计次会掩盖真实时间消耗：固定次数叠加指数退避，可能持续数分钟或数小时，取决于计数器从哪里开始。于是脚本改为截止时间制，并加入 full jitter，避免多个工作者在同一时刻重新发起请求，形成新的请求风暴。
示例中的重试函数以 90.0 秒为截止时间，单次请求超时为 30 秒；对 408、429、500、502、503、504 进行重试，对不可通过重试修复的 4xx 错误不再重试。退避上限由公式 cap = min(30.0, 0.5 * (2 ** min(attempt, 6))) 计算，实际等待时间在 0 与 cap 之间随机，并不超过剩余时间。
作者强调，重试安全的前提是重复执行不会产生额外副作用。对于日志摘要这类任务，可以通过幂等输出解决：用稳定输入的哈希作为文件名，使重复请求覆盖同一结果，而不是追加。示例脚本将文件内容、提示词和模型 ID 一起传入 SHA-256，取十六进制摘要的前 16 位作为键，并先写临时文件再重命名，避免中途失败留下半截结果。
对 AI 服务生产化排查的提醒
这篇笔记的意义在于，把“可用”从一个模糊状态拆成可验证的工程条件。对 AI 批处理来说，健康检查不能只服务负载均衡器或容器探针，也要服务真实业务路径。模型服务器是否冷、请求形状是否匹配、输出是否可覆盖，都会影响首批请求的成败。
作者还提到，免费模型访问与免费服务器选项并不是付费生产部署的缩小版，把它们按生产环境假设使用，会产生上述混乱。素材在涉及客户数据时给出的提醒是“先停止”，但后续内容未完整展示。
对正在把 LLM 接入内部工具的团队而言，这次排查提供了一组可复用的检查点：就绪探针要能触发真实模型路径，重试策略要围绕截止时间设计，输出要原子且幂等。/healthz 返回 200 只能说明服务在应答，不能说明模型已经准备好接住下一批请求。
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/healthz-fan-hui-200-bu-dai-biao-mo-xing-ke-yong-yi-ci-ai-pi
