首Token迟迟不出现，换更快的加速卡未必能解决问题。理解LLM服务首Token时延与硬件路径优化，要先拆清请求从文本进入服务，到生成首个输出Token之间经过了哪些环节：分词、排队、预填充、内存传输和模型计算。以下六个误区，常让优化方向跑偏。
先把测量口径弄对
首Token时延通常从请求到达服务端计时，直到首个输出Token返回；但有些监控从请求进入模型执行阶段才开始。两种口径不能直接比较。长提示词还会增加预填充计算，因此同一硬件在不同输入长度下，结果可能明显不同。
误区一：只看平均值
平均值会掩盖少量很慢的请求。应同时记录中位数和较高分位数，并按提示词长度、并发数分组。若高分位时延升高、低负载时却正常，优先检查排队和批处理，不要立刻认定计算设备变慢。
误区二：把分词时间算进模型计算
分词可能运行在主机处理器上，也可能与模型推理并行。分别记录请求接收、分词完成、进入预填充、首Token生成和返回时间，才能判断瓶颈是在文本处理、调度还是加速设备。测试客户端与服务端时钟不同步时，优先用服务端同一时钟的事件时间戳。
沿着硬件路径查六类错位
误区三：只盯加速卡利用率
利用率低不等于设备闲置故障。小请求可能受启动、调度或数据搬运影响，计算很快结束；较长提示词则可能主要受预填充计算限制。结合设备执行时间、队列长度和每批请求规模判断，避免仅凭一个利用率数字换设备。
误区四：认为显存够用就不会搬数据
模型权重能放入显存，不代表请求路径没有传输开销。输入张量、临时缓冲区和缓存数据仍可能在主机内存与设备显存之间移动。检查推理框架是否反复分配缓冲区、输入是否连续，以及数据是否在每次请求中重复复制；稳定复用缓冲区通常比盲目扩大批次更容易验证。
误区五：把更大的批次当作首Token加速器
合批能提高吞吐，但请求等待凑批也会增加排队时延。低并发、交互式请求通常更看重迅速启动；高并发、提示词较长的场景则可以测试小批次合并。记录批次等待时间与首Token时延，按负载调整等待窗口，而不是只比较每秒生成量。
误区六：用不匹配的测试代表线上
仅用固定短提示词、单个请求测出的结果，不能代表长上下文或并发流量。测试应覆盖实际常见的提示词长度、并发水平和输出方式，并保持模型、精度、框架版本与设备配置一致。若使用 AWS Inferentia2 等特定加速器，也要把对应运行时和编译配置记入记录，避免把软件路径差异误判为硬件差异。
按步骤定位，而不是一次改完
- 固定模型、输入样本、并发量和输出设置，记录版本与硬件配置。
- 为请求各阶段打点，分别统计分词、排队、预填充、首Token生成和返回耗时。
- 按提示词长度与负载分组，比较中位数及高分位数，找出时延集中出现的阶段。
- 一次只改一个变量，例如批处理等待窗口或缓冲区复用；重复同一测试，再比较结果。
这套顺序让LLM服务首Token时延与硬件路径优化从“换硬件试试”变成可验证的排查：先确认时间花在哪里，再针对对应路径调整。
常见问题
首Token时延越低，吞吐一定越高吗？
不一定。缩短合批等待可能改善首Token响应，却降低设备合并处理请求的机会；两项指标应分别观察。
提示词长度为什么影响首Token？
模型需要先处理输入上下文，再开始生成。提示词越长，预填充通常越重，具体影响取决于模型、实现和硬件。
什么时候该考虑换加速设备？
先确认时间主要消耗在设备计算，而非排队、分词或数据传输；再用相同模型与负载做可比测试，才有判断依据。
