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