首Token时延（TTFT）是请求发出到模型返回第一个输出Token的时间。想改善LLM服务首Token时延与硬件路径优化，别先盲目换卡：排队、提示词长度、模型计算和数据传输都会影响结果，优化错环节可能花了成本却看不到变化。
先固定模型版本、提示词长度和并发量，再分别记录请求等待时间与首Token时间。对比单请求和多人同时请求的结果，最好同时看中位数与较慢请求的分位数；服务端日志和推理框架指标可以帮助判断时间耗在排队、预填充还是设备执行。冷启动与持续运行也要分开测。
五项路径，按瓶颈选择
1. 先选合适的加速器与显存配置
模型权重、提示词缓存和运行时空间都要放得下。NVIDIA L4、H100、AMD Instinct MI300X 和 Intel Gaudi 2 是不同定位的加速器实例，不能只按型号或峰值算力直接比较；框架支持、显存容量、内存带宽和机器互连同样重要。模型若放不进显存，分片或跨设备传输可能增加延迟。单卡能完整承载时，通常更容易减少通信环节；需要多卡时，应验证设备间通信是否成为瓶颈。
2. 减少主机与设备间的数据搬运
检查模型权重是否在每个请求中重复加载，以及输入、输出张量是否频繁在主机内存和加速器之间往返。能常驻设备的数据尽量常驻；确有传输需求时，检查复制是否与计算重叠、内存是否按框架要求固定。PCIe 与专用高速互连的带宽和拓扑不同，跨设备路径越多，越值得单独测量传输耗时。
3. 针对提示词计算优化注意力内核
输入提示词需要先经过预填充（prefill），提示词越长，这部分工作通常越多。FlashAttention-2 等优化注意力计算与显存访问的实现，可能改善长提示词场景，但收益取决于模型结构、序列长度、加速器和软件版本。先用短、长两组真实提示词测试；若短输入快、长输入明显变慢，再优先检查预填充内核，而不是先调整输出阶段。
4. 评估低精度计算
BF16、FP8 或 INT8 等低精度格式可能减少计算或显存压力，但是否可用、是否提速，取决于设备、模型和推理软件支持。逐级尝试受支持的格式，固定同一批输入，对比首Token时延、输出质量和显存占用；如果质量不符合业务要求，或实际延迟没有改善，就不应只为低精度而切换。
5. 降低执行启动开销，谨慎控制批处理
CUDA Graphs 可在适用条件下减少重复的内核启动开销，但通常要求输入形状等条件满足框架限制，捕获和内存占用也需实测。连续批处理（continuous batching）有助于提高并发处理效率，却可能让新请求等待已有批次。若目标是低首Token时延，设置较小批次或限制排队可能比追求最高吞吐更合适；两种目标需要分别测。
用这套步骤决定先改哪项
- 选取固定提示词样本，覆盖实际常见长度，并记录输入长度、并发量和模型版本。
- 先测设备空闲、单请求和目标并发三种情况，分开观察冷启动与稳定运行数据。
- 若时间主要耗在排队，先检查并发和批处理策略；若长提示词拖慢首Token，优先测预填充与注意力内核。
- 若日志显示传输或跨设备通信占比较高，再调整设备放置和数据搬运路径。
- 每次只改一项，重复相同测试并比较延迟分位数、吞吐和显存；保留质量与稳定性都达标的方案。
因此，LLM服务首Token时延与硬件路径优化没有适合所有模型的固定排序：小并发短提示词，先排查启动和排队；长提示词，重点测预填充；多卡或高并发服务，则要把互连和批处理等待纳入判断。
常见问题
首Token时延和生成速度是一回事吗？
不是。首Token时延看第一个Token何时到达；后续Token速度看持续生成阶段。前者低，不代表整段回答一定生成得快。
只换更强的加速器一定有效吗？
不一定。若瓶颈是排队、CPU侧处理、数据传输或软件不匹配，换卡未必解决问题。应先用日志和对照测试定位瓶颈。
批处理越大，首Token越快吗？
不一定。更大的批次可能提高吞吐，也可能增加新请求等待时间。应按目标并发实测首Token分位数，而不只看总吞吐。
低精度会不会影响输出？
可能影响模型输出，应使用代表性输入对比质量与时延，并确认硬件和推理框架支持目标精度后再部署。
