推理性能问题先要量化，不要凭感觉调参。LingBot-Depth 2.0 如果只在单次请求时慢，和并发场景下整体吞吐低，优化方向完全不同。建议先用 profile 工具记录一次请求的完整耗时分布，再决定是改部署配置还是改调用方式。

建议先记录请求各阶段耗时，用 profiling 工具确认瓶颈在预处理、模型计算还是解码生成，不要直接改模型结构。多数情况下，增大批处理、使用半精度、开启 KV Cache 能带来稳定收益；但需要结合具体环境逐项验证，并做回归对比，防止精度下降或显存溢出。

先把“慢”拆成可测量的段

记录至少 20 个请求的耗时分布：输入解析、预处理、模型前向、解码循环、后处理。注意区分首 token 耗时应和后续 token 平均耗时，前者反映模型前向和请求调度，后者反映解码循环效率。用 nvidia-smi 看 GPU 利用率，用 py-spy 或 top 看 CPU 侧热点。如果是 CPU 推理，还要看线程数和内存带宽。

验证方式：完成 profile 后判断瓶颈是“单次前向慢”还是“整体吞吐上不去”。单次前向慢重点看算子和显存带宽；吞吐上不去重点看批处理和并发调度。

常见瓶颈点排查清单

• 数据预处理：检查 tokenize、resize、归一化是否重复计算；缓存预处理结果后再测一次耗时。
• 模型前向：观察单次推理耗时随输入长度增长的曲线；注意力计算量通常随序列长度二次增长。
• 解码策略：贪心解码和 beam search 差异很大；beam size 加大后耗时会显著增加。
• 显存和内存：确认没有 swap 或显存不足导致的周期性卡顿。
• 推理框架：确认是否开启算子融合、CUDA graph、半精度；不同框架对相同模型的加速效果差异较大。

可落地的优化动作

先切换推理精度

如果当前是 FP32，建议先试 FP16 或 BF16，多数模型在支持半精度的 GPU 上能直接加速，但要以实际验证为准。CPU 环境可以尝试 INT8 量化，但需要准备校准数据，避免精度损失过大。

示例：PyTorch 下切换 FP16
model.half().eval()
input_tensor = input_tensor.half()

调整批处理大小

单请求逐条推理时吞吐很低。考虑把多个请求拼成一个 batch，记录 batch size 为 1、2、4、8 时单条平均耗时和显存峰值。批处理增大后单条耗时通常会下降，但显存占用上升，需要设上限。

开启或检查 KV Cache

自回归生成时，KV Cache 避免重复计算历史 token 的键值。如果框架没有默认开启，逐 token 生成会非常慢。需要查询所用推理框架的文档，确认开关位置，并观察显存占用变化。这一步可以单独验证。

验证与回归

每次只改一个变量，保留改动前的耗时记录。固定测试集和输入序列长度，至少跑三次取中位数。除了耗时要记录显存峰值和生成文本是否一致。如果精度波动超出预期，需要回退。优化完成后应形成一份可复用的环境配置，避免同类问题反复出现。