这类问题我又碰上了一次。上线后用户抱怨首字要等两秒，按阶段打点看到 embedding 120 毫秒、向量查询 40 毫秒、重排 900 毫秒、首 token 600 毫秒，重排是最大头。
第一反应是「候选没先截断，长文档让重排推理时间翻倍」，验证下来不成立。
原因不止一个，得分开看。重排模型跑在 CPU 上，50 条配对要接近一秒；检索与重排串在同一条同步链路，耗时直接累加；流式响应在重排结束前被框架整体缓冲住。
动手时先确认重排能否走 GPU
python -c "import torch;print(torch.cuda.is_available(),torch.cuda.device_count())"候选先截到 20 条再送重排
python -c "print(len(list(range(50))),len(list(range(20))))"然后把重排拆成独立服务并行调用
curl -s http://127.0.0.1:8081/rerank -H "Content-Type: application/json" -d '{"query":"退款","documents":["退款规则"],"top_n":1}'压测各阶段耗时看 P95 落点
python -c "import numpy as np;print(round(float(np.percentile([0.9,1.1,0.8],95)),2))"恢复的判定其实很直接。首字延迟 P95 从 1.8 秒降到 700 毫秒以内，重排阶段不超过 200 毫秒，流式首个内容块稳定返回。
补一句。首字延迟里检索占比超过一半时，先砍候选数量和排序开销，换更大的模型通常只会更慢。报错文案容易误导，真正的原因往往在相邻那一层的日志里。