服务超时怎么定界
超时要先定界，再谈调参：客户端读超时、网关代理超时、引擎排队等待、生成本身耗时，是四条不同的路径。用状态码与引擎指标把责任层找出来，再调整对应参数。不同层的表现完全不同，乱调参数只会把失败方式换一个样子，问题本身还在。
基本信息
| 504 | 网关等上游超时：上游还在算或已卡住 |
|---|---|
| 499 | 客户端先断开：多为客户端读超时更早到点 |
| 排队等待 | 并发超过容量：请求在队列里耗掉预算 |
| 生成超时 | 长输出或解码慢：单请求超出预算 |
| 预算设计 | 客户端读超时 > 网关读超时 > 单请求处理时间上限 |
典型使用场景
- 用户反馈「转圈很久最后失败」：先看落在哪一层，再决定动作
- 定位 504 来源：确认上游是仍在计算，还是进程已经卡死
- 流式长回答中途断流：核对网关读超时与中间层的缓冲设置
- 队列造成的失败：并发超过容量，需要在容量侧解决
- 变更前评估：调整超时参数前，先算清业务最长输出要多长时间
定界证据
定界证据
# 网关侧：上游超时记录
tail -n 200 <网关错误日志> | grep 'upstream timed out'
# 客户端先断开：状态码 499
grep ' 499 ' <网关访问日志> | tail -5
# 引擎侧：是否在排队、首 token 延迟是否异常
curl -s http://127.0.0.1:8000/metrics | grep -E 'num_requests_waiting|time_to_first_token'现象与责任层
| 现象 | 责任层 | 对应动作 |
|---|---|---|
| 504 上游超时 | 网关与上游之间 | 确认上游是否卡死，必要时重启或摘流量 |
| 499 客户端断开 | 客户端 | 核对分层预算，客户端超时是否设得太短 |
| 排队等待很长 | 容量 | 扩容或限流，改超时无效 |
| 生成超预算 | 模型与输出长度 | 控制输出长度或提高该层预算 |
队列造成的等待只能在容量侧解决：把超时放大只是让客户端多等一会儿，失败依旧会发生，而且用户更难感知服务异常。
流式场景要保持心跳并关闭中间层缓冲：长时间没有数据流动的空闲连接容易被链路上的设备掐断，表现和超时很像但不是超时。