服务器中断后，模型调用如何对账

应用进程挂了，已经发出的模型请求却可能继续执行：费用照常发生，结果却没能保存。dev.to 的文章《Tokens Outlive the Free Server》讨论了这个可靠性盲区，提出在调用前记录意图、调用后记录结果，并把账本放在独立于应用实例的持久存储中，让重启后的对账有据可查。

目前能确认什么

应用服务器和模型服务属于两个故障域（failure domain），各自可能独立失败。应用退出，不能证明远端请求已经取消；没有收到响应，也不能直接判定调用失败。

作者给出的流程是：先写调用意图，再请求模型，最后写调用结果。即使客户端已经断开，只要应用还能拿到结果，就应继续保存。启动时扫描只有意图、没有结果的记录，将它们列为待对账项，不能静默重试。

账本能标记不确定的调用，不能凭空找回响应。

节选中的示例记录了请求 ID、时间、提示词哈希和完成状态，没有保存回答正文。它依赖 LEDGER_PATH 指向的存储能独立于实例存活；fsync 用于同步文件写入，不能让临时磁盘跨实例保留。

我的判断

对接模型 API 时，重试策略需要区分「明确失败」和「结果未知」。后者直接重试，可能再次消耗额度。如果产品需要用户断线后回来取结果，就需要持久任务记录和结果查询，只有调用日志不够。

还有两点不能照搬。孤立记录增加可能来自进程被杀或结果落账失败，不能仅凭数量认定超时设置过短。能否查询远端状态、找回回答或通过幂等机制避免重复执行，节选没有给出，需要对应模型服务的官方文档确认。

这套方案首先解决的是可追踪性，完整的费用对账还缺远端凭据。