大模型推理优化入门：三个量互相牵制

推理优化，指的是在并发、首字延迟与单位成本之间做取舍。它不是把三个指标同时调到最好 —— 在固定硬件上这三者互相牵制，优化的实质是明确当前业务最不能让步的是哪一项

先测，再优化

没有基线的优化等于凭感觉调参。上优化手段之前，至少要把下面三项测出来，并且是在真实负载形态下测，而不是单条请求跑一遍。

• 并发：单位时间内同时处理的请求数，以及队列开始堆积的临界点。
• 首字延迟：从请求发出到第一个字返回的时间，它直接决定使用者觉得「快不快」。
• 单位成本：每千次调用或每百万字的实际支出，含算力、电费与运维人力的分摊。

三项要一起测、一起记录。只报首字延迟而不报当时的并发，等于没有信息 —— 延迟数字离开了负载条件就没有可比性。

常见手段各自动了哪一项

• 批处理：把多个请求合并计算，提升吞吐、降低单位成本，代价是首字延迟上升。
• 缓存：命中相似请求时直接复用结果或中间状态，同时改善延迟与成本，代价是命中率不稳定且需要处理失效。
• 量化与显存优化：降低单次推理的资源占用，让同一设备承载更多并发，代价是可能需要重新验证精度。
• 上下文裁剪：缩短送入模型的资料长度，直接降低延迟与成本，代价是可能丢信息、提高漏答率。
• 推测式解码一类的加速手段：在特定负载下降低延迟，在高并发时收益可能反转。

把手段和它动的量对上号，讨论就不会失焦。如果目标是把首字延迟压下来，批处理就不是首选；如果目标是摊薄成本，那么先看缓存命中率通常比调模型参数更划算。

还有一项常被忽略的变量是输出长度。同一个问题，让模型先写一大段推理过程再给结论，延迟与成本都会成倍上升；而多数内部场景只需要结论与依据。控制输出形态，往往是最省力的一次优化。

把优化放进流程

优化不是一次性动作。模型换代、知识库扩容或业务量变化都会让原有的基线失效，所以更需要的是机制，而不是某一次调参的结果

• 记录基线：每次变更前后各留一组并发、延迟与成本数据。
• 指定责任人：谁看这些指标、多久看一次、异常找谁。
• 设置复核触发点：负载接近瓶颈、模型换代或成本结构变化时重新评估。

什么时候不值得优化

• 负载远未接近瓶颈：余量充足时，优化的收益会被运维复杂度抵消。
• 瓶颈不在推理侧：真正慢的是检索、外部接口或人工复核，压推理延迟没有意义。
• 需求还没稳定：场景与调用量都在变，此时优化等于给一个会变的数字做精调。
• 优化会削弱可追溯性：为提速而关掉日志或引用，省下的是延迟，赔上的是信任与合规。

判断是否值得优化，有个简单的标准：优化之后能不能说清「哪一类请求变快了、代价是什么」。说不清，说明优化的目标还没定下来。