用户看到页面迟迟没有输出，业务团队往往直接判断“模型太慢”，平台团队则可能先增加GPU或扩大副本。若请求实际上堵在网关、队列、冷启动、模型加载或Prefill阶段，这些动作既可能无效，也会让成本上升。

排查范围：以首Token到达前的请求时间线为主线，依次核对入口等待、调度排队、实例就绪、模型加载、Prefill和传输；不把平均总耗时当作根因。

首Token慢不是一个单层问题

首Token时间应拆成入口、排队、调度、就绪、Prefill和传输几个阶段。先建立同一请求ID下的时间线，再决定加资源、调参数还是改入口策略。

先确认慢发生在哪些请求

按模型版本、输入长度、并发、调用方和时间窗口分组，区分全部请求变慢还是长输入、冷启动或某个入口异常。平均值不能代替长尾和分组证据。

先用同一请求标识拼出首Token之前的分段时间，再按最大耗时段排查：

只有总耗时而没有分段时间时，任何“增加GPU”或“更换框架”的动作都缺少根因依据。排查报告应标出最大耗时段、证据缺口和下一次只改哪个变量。

入口与队列先排除等待

检查网关鉴权、限流、重试、连接和队列等待。若请求尚未进入模型服务，加GPU不会解决入口拥塞；重试还可能放大峰值。

实例与模型就绪要分开

容器运行不等于模型就绪。查看实例创建、镜像与模型加载、健康检查、显存和调度事件，确认是否存在冷启动、资源等待或反复重启。

Prefill与输入长度决定计算压力

输入上下文、批处理和模型配置会改变Prefill时间。用固定模型和资源按长度分组复测，避免把长输入问题误判为框架整体性能。

灰度验证和回滚要成对

每次只改一个变量，在少量流量下观察首Token、错误、吞吐和资源变化；若改善不可复现或错误上升，恢复上一配置并保留实验记录。

用对照压测定位延迟来源

排查不能只截取故障时的一条慢请求。先从真实流量中选取短、中、长输入和不同预期输出，固定模型、版本、资源、入口与客户端，建立低并发稳定基线；再逐级提高并发，比较排队、首Token、错误和资源何时发生拐点。若只在长输入变慢，优先检查Prefill与输入治理；若所有请求在峰值同时变慢，入口、队列和容量更可疑。

冷启动需要单独测试。分别记录镜像或实例启动、模型加载、健康检查顺利获得和首个成功请求的时间，区分已缓存与未缓存条件。实例数量增加但新实例尚未就绪时，入口如果过早分流，会把扩容变成新的超时来源。压测结果必须保留时间线，而不是只看扩容后的稳定窗口。

每次优化只改一个主要变量，例如入口重试、队列等待、批处理窗口、实例预热或输入上限。使用相同样本复测首Token、完整响应、吞吐、错误与资源，避免改善首Token却增加失败或拖慢长输出。工具端连接、网络和客户端读取也要排除，否则平台会为客户端瓶颈背负错误结论。

采购平台要看能否给予分层证据

平台选型时，应要求候选方案展示请求ID如何穿过网关、服务、模型实例与资源层，能否按模型版本、调用方、输入长度和状态分组。只给予总响应时间和GPU利用率的面板，无法支持首Token故障定位，也难以把改进写入验收。

证据清单至少包括入口接收与转发时间、服务排队、实例就绪、模型版本、输入输出规模、错误或取消状态、资源与事件。具体字段可随平台变化，但必须能回答慢在哪一段、受哪些请求影响、谁有权限调整以及调整后如何复验。监控需要额外开发或日志关联时，也要计入实施成本。

采购还要核对告警、变更和支持边界。首Token越界由业务、平台还是SRE接单，供应商能查看哪些日志，敏感请求如何脱敏，夜间异常是否有升级路径，都比一张演示曲线更接近生产责任。

优化必须有质量护栏和故障恢复

缩短输入、调整批处理、减少排队或提前拒绝可能降低首Token，但也可能改变回答完整性、吞吐和业务成功率。业务方应给予一组代表性样本与不可接受结果，技术团队同时设置错误、取消、完整响应和资源护栏。任何一项越界，都不能仅凭首Token改善放行。

灰度期间要预设停止条件：错误持续上升、请求无法取消、队列不回落、新实例反复重启或监控失去关联时，立即撤回改动。恢复后确认入口配置、实例版本、队列、告警和样本结果均回到已知基线。若恢复只能依赖原调优人员，运行手册和权限交接仍未完成。

退出无效优化，保留可复用证据

不是每个首Token问题都值得顺利获得增加复杂组件解决。若优化收益只在特殊样本创建、维护成本超过业务价值，或需要长期保留难以升级的专用配置，应正式停止该路径并恢复基线。停止不是测试失败，而是避免把不可维护实验带入生产。

保留样本分组、时间线、参数变更、压测脚本、结果和回退记录，下一次更换模型、运行时或平台时可直接复用。低延迟治理的交付物应是一条能重复定位、验证和恢复的证据链，而不是一组无法解释来源的调优参数。

排查结论要指向具体耗时段和单一动作

故障记录应保存慢请求标识、每段时间戳、输入长度、实例与模型版本、队列和资源事件。分析结论明确主要耗时落在入口、调度、就绪还是Prefill；执行结论只安排对应层的一项改动，并写明首Token、错误和吞吐的护栏。

入口队列占比最高时，优先处理限流、重试或多层排队；实例就绪占比最高时，检查冷启动和流量接入；Prefill随输入长度增长时，再评估长度策略、批次或计算配置。未拿到分段证据前，不应以增加GPU或替换框架作为默认方案。

下一步建议

选一条可复现的慢请求，用同一请求标识打通客户端、网关、服务、实例和模型阶段的时间戳。按短、中、长输入各复测一次，再只修改最大耗时段的一个变量，并保留上一配置。需要补齐请求到资源的观测链路，可参照 AI模型可观测性怎么看？指标、链路和日志怎么定位问题。

常见问题

首Token慢，为什么加GPU可能没有效果？

请求可能在鉴权、限流、网关队列、服务队列或实例调度阶段等待，此时尚未进入GPU执行。增加设备不会缩短这些等待，甚至可能因新增冷实例和模型加载扩大短期长尾。

先比较入口接收、开始排队、分配实例、模型就绪、Prefill开始和首Token发送的时间戳。只有等待主要发生在计算资源不足且GPU证据一致时，扩容才是合理候选动作。

扩容前还要确认资源池确有可用容量、新实例冷启动能赶上业务等待预算，并设置错误和长尾停止线。若入口重试或队列才是根因，应先治理流量，避免新增GPU只扩大无效请求。

扩容成本也需绑定有效请求增量。

怎样区分冷启动慢与Prefill慢？

冷启动慢通常与实例创建、镜像或模型加载、健康检查和首次接流量相关，同一实例稳定后会明显改善；Prefill慢则常随输入长度、并发、批次和模型配置变化，即使实例已就绪仍会出现。

测试时分别记录冷实例首个请求和热实例同样请求，并按输入长度分组。若健康检查顺利获得后仍长时间没有首Token，再从调度与Prefill事件继续缩小范围。

还应在未缓存节点重做一次冷启动，记录镜像、模型加载、就绪和接流量时点。恢复后用同一请求复验；若只有预热环境表现正常，采购报告必须注明缓存和预置资源条件。

预热资源的持续费用不能遗漏。

平均首Token正常，为什么用户仍会投诉很慢？

平均值会被大量短请求和低峰时段稀释。少量长输入、特定调用方、冷实例或高峰队列可能形成很差的长尾，而总体平均仍看起来稳定。

平台应展示分位、样本数和请求分组，并允许从慢请求回查原始时间线。告警也应围绕业务关键分组和长尾设置，避免只监控全局平均。

选型验收时可让业务给予一组投诉样本，检查能否按调用方、模型版本、输入长度和时段定位。若必须人工拼接多套日志，应估算观测接入和长期排障成本，不能把面板存在视为顺利获得。

敏感样本还要脱敏、限权并设置留存期限。

一次参数优化后首Token下降，可以直接全量发布吗？

不能。先确认改善在相同模型、样本、资源和负载下可复现，并同时观察完整响应、吞吐、错误、取消和模型质量。某些优化会把等待转移到后续生成或扩大资源压力。

应以少量流量灰度，每次只改一个变量，触发错误或长尾护栏时恢复上一配置。结果记录要包含变更前后时间线和回退是否恢复基线。

全量前由值班人员按手册完成一次回退，并核对队列、实例版本、告警和业务样本。无法稳定复现的优化应退出，保留失败证据与配置差异，避免形成只能由原调优者维护的生产负担。

退出后还要清理临时路由、测试凭证与闲置资源。