AI 推理性能调优与大模型推理加速实践开发短记：先拆开首包和续写
一次模型演示里，开发者往往只看见“回答出来了”。上线前真正要拆开的，是首个 token 出现前的等待时间，以及后续 token 的生成节奏。把两者混成一个平均耗时，定位会变得很困难：前者可能受排队、提示词处理或权重加载影响，后者才更接近解码与 KV Cache 的压力。
我会先固定一个请求集合：短问答、长上下文、带工具说明的请求各保留几条，再记录模型版本、推理后端、量化格式、GPU、并发数和预热轮次。每条记录至少有排队时间、TTFT、TPOT、输出 token 数、显存峰值和被取消的请求数。没有这些字段，报表上的“变快”无法解释。
排查顺序也不要从参数表开始。若 TTFT 随并发增长而跳变，先看批处理等待窗口和请求队列；若 TTFT 稳定但 TPOT 拉长，再检查解码批次、显存碎片及 PCIe 传输。长提示词变慢时，单独观察预填充阶段，不要把它归到生成速度。
改动一次只动一个变量。例如先把最大批次从 8 调到 16，保留同一批输入并比较分位数；再单独试用另一种量化格式。若超时、拒绝率或显存告警变多，即使吞吐更高也不应继续扩大配置。最终交付的是一份可重跑的命令、原始样本和回退参数，而不是一个孤立的毫秒数字。
交接时，再标明这组数据对应的上下文上限和服务端限流规则。后续有人更换模型、驱动或 tokenizer，应从这份基线重新采样，而不是把旧曲线当成新版本的结论。
样本中还应保留被截断、超时和取消的请求。它们常被平均值排除，却直接影响调用方的重试和用户体验。
同一轮结果用同一时钟来源记录。
报告中注明队列等待是否计入端到端延迟，避免调用方和服务端使用不同口径。
