问题出现得很突然，日志倒是留得挺全。用 Triton 24.08 部署 ONNX 的 embedding 模型，dynamic_batching 的 max_queue_delay_microseconds 设成 100000，实测排队从 100ms 涨到 2 秒，客户端开始大量超时。
刚开始盯着「客户端只有 4 并发，凑不满批只能等超时」，折腾了半个多小时，排掉了。
把日志和配置对完，能解释这个现象的基本就这几处。队列延迟按微秒计，这个值叠加首轮预热后实际更久。少数情况下是preferred_batch_size 没设，调度器一直等更大的批。
少数情况下是实例数只有 1，队列与执行串在一起。
第一件事是检查当前的调度配置
curl http://127.0.0.1:8000/v2/models/embed/config再往下把延迟降到 5ms 并给出首选批大小
curl -X POST http://127.0.0.1:8000/v2/repository/models/embed/config -d @config.pbtxt增加实例数分担队列
sed -i 's/count: 1/count: 2/' config.pbtxt末了用 8 并发压一轮看 P99
python bench.py --url http://127.0.0.1:8000 --concurrency 8别只看报错消失，验证要多做一步。排队时间回到 10ms 以内，P99 低于 300ms，吞吐没有因为批变小而下降。
动态批处理在低并发下就是纯等待，先把并发压上去再调延迟参数，顺序反了会越调越慢。报错文案容易误导，真正的原因往往在相邻那一层的日志里。