昇腾社区首页
中文
注册

明确优化目标

用户通常关注首Token时延、吞吐等性能指标。测试时的并发、输入输出长度对性能影响较大,必要时可以进行引导。

  • 低时延场景:实时交互(如对话系统),关注首Token生成速度(Prefill阶段优化)。
  • 高吞吐场景:离线批量处理(如文档生成),关注Tokens/秒(Decode阶段优化)。

    有时性能目标和实际差异较大,可以根据纯模型性能简单评估性能上限,判断时延或吞吐的极限,从而判断目标是否有可能达成。

服务化性能上限评估

按照估算场景和目标划分,基于纯模型测试结果,对于服务化性能上限的几种(乐观)估计方法如下:

  • 单并发:与纯模型单并发性能接近。
  • 大并发下平均首token时延。
    • prefill阶段推理是算力密集型场景,prefill batchsize增大后会触发算力瓶颈;触发瓶颈后,prefill时延会随batchsize增加接近线性增长。
    • 使用纯模型测试找到达到算力瓶颈的prefill batchsize,以这个prefill batchsize划分服务化的并发请求数,即基于纯模型结果计算首token时延上限;假设纯模型测试找到瓶颈处prefill batchsize为,此时单个prefill batch的纯模型计算时间为,要估计的服务化实际并发为,则服务化此轮并发请求的prefill总时间估计为,在先来先服务(FCFS)调度策略下,平均首token时延约为
  • 大并发下吞吐、非首token时延。
    • decode是带宽瓶颈而非算力瓶颈,理论单个decode的batchsize越大,总吞吐越大,直至达到显存限制。
    • 服务化的输出吞吐和非首token时延,可参考相同并发(即decode batchsize)下的纯模型结果作为理论估计的上限,考虑到服务化推理会有框架侧调度等额外的时间开销,服务化吞吐的乐观估计可折算为纯模型吞吐0.8~0.9倍。
  • 最大并发/maxBatchsize的理论上限:decode阶段maxBatchsize主要受显存限制,可根据KV Cache Block数量和序列长度计算,具体计算方法请参考MindIE Motor开发指南性能调优流程章节中操作步骤的步骤3。