用户发出请求后，首个回答迟迟不出现，问题未必在模型本身。排查LLM服务首Token时延与硬件路径优化，应先把一次请求拆成可观测的阶段，再确认时间究竟消耗在网络、排队、预填充还是GPU执行上。以下步骤适用于自建推理服务，也适用于调用托管模型时的客户端侧诊断。
先把请求链路拆开计时
首Token时延是请求到达与首个输出Token返回之间的时间。它不同于生成完整回答所需的总时间：长回答可能首Token很快，但整体耗时仍长。至少记录客户端发送、服务端接收、进入调度队列、开始模型计算、首Token生成、首字节返回等时间点。
可用 OpenTelemetry 为入口、网关和推理服务传递同一请求标识；客户端同时记录单调时钟下的发送与首字节时间。若服务端只暴露总耗时，先补充阶段日志或指标，否则难以区分网络等待和模型计算。对照同一请求的客户端与服务端时间，也能发现代理转发、连接建立或响应缓冲造成的额外延迟。
按顺序定位耗时阶段
- 排除请求入口问题。用固定长度的提示词，在同一网络环境下分别测试复用连接与新建连接。若新连接明显更慢，检查 DNS、TLS 握手和代理；若服务端已快速返回而客户端首字节迟到，重点看网关缓冲与传输链路。
- 测量排队时延。记录请求进入队列和被调度的时间，并按并发量分组比较。负载升高时队列等待快速增加，通常意味着可用执行槽不足或批处理策略过于保守。不要只看平均值，同时观察高分位数，避免少量长等待被均值掩盖。
- 检查分词与输入长度。记录输入Token数，而不只记录字符数；中英文、代码和特殊符号的分词结果可能不同。保持提示词长度不变，再逐步缩短输入。如果首Token时间随输入Token数明显增加，耗时可能主要落在模型预填充（prefill），而不是输出阶段。
- 观察GPU是否真正忙于计算。检查设备利用率、显存占用、功耗和时钟是否持续变化；NVIDIA 环境可先用 nvidia-smi 查看状态，再用 Nsight Systems 查看主机到设备的执行时间线。利用率低但请求在等候，回查队列、CPU侧调度和数据准备；利用率持续很高且预填充时间增长，则需检查并发、输入长度与批次配置。
- 做单变量对照。固定模型、提示词、输出上限和硬件，只改变并发或最大批次；每轮分别记录冷启动与预热后的结果。这样能区分模型加载、编译或缓存初始化与稳定运行期的时延，避免把一次启动开销误判为日常问题。
沿硬件路径优化，而不是盲目换卡
先处理队列与批处理
连续批处理（continuous batching）可以在请求到达时动态组织执行，提高设备利用率，但批次等待过久也会推迟首Token。对交互式负载，应比较不同最大等待时间和批次上限下的首Token分位数与吞吐量；低并发场景可减少人为凑批等待，高并发场景则要避免批次过大导致显存紧张或排队加重。
再核对数据与计算路径
检查模型权重是否已驻留显存，主机内存到设备的数据传输是否频繁，以及设备是否因功耗、温度或显存压力降频。若时间线显示大量小型内核启动或主机等待，优化执行调度可能比增加算力更直接；若预填充计算本身占主导，再评估模型精度、输入长度和适配的推理内核。不同GPU架构、驱动与软件版本的结果并不相同，变更后必须用同一组请求复测。
用可复现结果确认改动
每轮测试至少保留输入Token数、并发数、模型与软件版本、GPU状态、排队时间和首Token时间。先测预热后的稳定请求，再单独记录冷启动；报告中注明测试时长和负载方式，不把单次最快值当作服务表现。LLM服务首Token时延与硬件路径优化的关键，是找到主耗时段后只改一项，再验证时延与吞吐是否同时符合目标。
常见问题
首Token慢，是否一定是GPU算力不足？
不是。请求可能卡在网络、队列、分词、模型加载或预填充。先用分阶段时间戳定位，再判断硬件是否是瓶颈。
为什么短提示词很快，长提示词明显变慢？
长输入需要处理更多Token，预填充计算通常随输入规模增加。比较不同输入长度下的预填充耗时，可确认这一因素的影响。
该优先降低批次等待还是提高吞吐？
交互请求通常更关注首Token分位数，可尝试缩短等待；吞吐优先的批处理任务则可接受适度等待。应按实际负载对照测试，而非只看设备利用率。
优化后该看哪个指标？
同时看首Token时延的中位数与高分位数、队列等待和吞吐量，并固定测试条件。单一平均值不足以判断用户体验是否改善。
