“推理接口一直转圈后台其实在排队看起来像假死。”同城朋友做本地验收时找我。推理队列并发上限写成 1请求排队过久像假死。他以为是模型挂了其实是并发与超时没验。这和密钥缓存、健康检查、Docker 时区、返回字段不是一类事这次只盯并发与超时配置验收。身份按同城验收口径走。图Kent Madsen / Wikimedia Commons / CC BY-SA 4.0朋友问“是不是直接加大并发”我说先核对上限与超时再按清单验收。第一并发上限。把队列并发调到业务可承受范围禁止长期钉死在 1。第二超时与排队可见。超时阈值写清排队长度对外可见避免静默假死。图Kent Madsen / Wikimedia Commons / CC BY-SA 4.0第三压测验收。按目标并发压三次延迟与失败率必须落在阈值内故意改回并发 1必须在验收阶段暴露排队。验收调并发后三次压测都稳改回并发 1三次都在超时前堆积。朋友把并发与超时写进验收表换人也能对表。图Robert.Harker / Wikimedia Commons / CC BY-SA 3.0并发上限看起来只是一个数字钉死在 1 就会让人以为服务挂了。调并发再加超时可见比事后重启省事。你们本地推理有没有遇到过并发为 1 导致排队假死最后怎么验收的欢迎评论区聊聊。把检查写成固定步骤比出了事再猜省力换人值班也能按同一套标准走。回头复盘这类问题往往不是某一句提示词写错而是入库、汇总、状态这些前置步骤少做了检查。同事后来把这套步骤写进共享盘说明新人接手也能按同样清单走一遍。我把这次踩坑记进团队备忘下次换环境先过一遍同样的三处改动。验收数字摆在桌面上比口头说好像好了更让人放心。这类细节平时不起眼真出了偏差排查却最费时间。我们约定以后每次改完都留一份对照记录方便下一次复盘。流程写清楚之后值班交接少了很多口头解释。有了清单新人也能按同样标准走完不必每次找人问。下次再碰到类似现象先对清单再动手比凭感觉改快。值班交接时把三处改动念一遍比事后补救省大半天。同一套对照数字留在共享盘下一次排查能直接对齐。把现象、改法和验收数字写在一起比事后回忆清楚得多。少做一次口头确认就多一次可复现的对照记录。换人值班时先对清单比凭记忆口述稳妥。
