首Token变慢未必是显卡不足：排队与预处理排查

模型生成首个 token 之前，请求可能已经花时间等候、套用聊天模板、完成分词并处理提示词。因而，LLM服务首Token时延与硬件路径优化不能只看显卡型号或利用率：先找出时间花在哪一段，再决定是否需要更换或调整硬件。

首个 token 前，延迟经过哪些环节

从请求进入服务到首个 token 返回，常见路径包括接入与排队、输入校验和模板处理、分词、任务调度、提示词预填充，以及结果传回客户端。模型加载、网络连接或进程启动也可能影响冷启动请求，但通常不该与稳定运行时的延迟混为一谈。

队列等待发生在请求真正执行之前；分词把文本转换为模型输入；提示词预填充则让模型处理已有上下文。长提示词可能使预填充耗时增加，即使生成阶段速度正常，首 token 仍会较晚到达。LLM服务首Token时延与硬件路径优化的第一步，是把这些阶段分开计时，而非单看整条请求的总时长。

记录分段时间。在服务入口、分词前后、任务进入执行器和首 token 发出的位置记时间戳，同时记录请求是否排队、输入 token 数及模型是否已加载。使用同一时钟源，避免各进程时间戳难以对齐。
比较短、长提示词。在相同模型和相近并发下，分别发送短输入与长输入。若延迟随输入长度明显上升，优先检查模板、分词和预填充；若两者都慢，再看排队、调度或启动开销。
比较空闲与有负载状态。空闲时快、并发时慢，常提示排队或调度竞争；空闲时也慢，则检查单请求路径和模型冷启动。分别观察中位数与高分位延迟，避免少数慢请求被平均值掩盖。
核对硬件是否在等数据。查看加速器执行活动、显存占用及主机到设备的数据传输。如果设备长期空闲而请求耗时偏高，瓶颈可能在前处理或调度；若预填充期间设备持续繁忙，才更有理由评估计算能力或模型配置。

先检查服务并发上限、执行器线程和请求调度策略，确认请求是否卡在入口或等待可用执行槽位。以受控并发逐步增加请求，观察队列时间和首 token 延迟何时开始明显上升；不要只为提高吞吐而无限增加并发，否则排队可能让交互延迟更差。

固定聊天模板，减少不必要的重复格式化；检查分词器是否在每次请求中被重复初始化。若业务允许，控制过长的输入上下文，并把输入 token 数纳入延迟分析。对使用 vLLM 或 llama.cpp 的服务，应结合具体版本和后端核对调度、模型加载及加速器支持情况，不要假设不同运行时具有相同的数据路径。

确认模型权重是否在服务启动时一次性加载，避免请求期间发生意外的重新加载；检查输入张量是否经过多余的主机与设备转换。Google Cloud TPU 服务也需要区分主机侧预处理与 TPU 执行时间；采用 TPU 并不意味着分词、排队或数据准备自动消失。每次只调整一个环节，并用相同请求和负载复测。

不能据此判断。设备可能在等待分词结果、调度或数据传入；先对齐各阶段时间，再看执行期间的设备活动。

如果主要耗时在排队、冷启动或预处理，换卡未必有效。先确认加速器计算是否占据主要时间，再比较硬件方案。

两者都看。平均值反映整体水平，高分位数能暴露少数排队或冷启动请求造成的长尾；比较时要保持模型、输入长度和并发条件一致。

归根结底，LLM服务首Token时延与硬件路径优化应从可观测的分段数据开始：先分清队列等待、分词、预填充和设备执行，再有针对性地调整。只有硬件执行本身确实占主导时，升级加速器才是有依据的选择。