关于大模型系统吞吐量计算的方法

基本概念及计算公式

• flops：指完成该任务所需的总和浮点计算次数

  • 对于一个transformer架构的模型而言，使用改一个参数量为m的模型，计算n个token所需的算力flops通常可以近似为\(2 \times m \times n\)。其中常数2由一次乘法和一次加法分别贡献。

  • 具体细节可见下文

• compute to memory bandwidth ratio: 算力访存比 = 峰值算力(FLOP/s) / 内存带宽(Byte/s)

  • 在910B上，算力访存比=320

• prefill throughput：指每秒钟每个模型实例可处理的"输入"token数

  • 理论吞吐量=\(\dfrac{峰值算力}{2 \times 模型参数量}\) 对于在910B上跑32B大小的模型，理论吞吐量=4000token/s

  • 实际吞吐量=\(理论吞吐量 \times MFU\_ encoder\)，910B上约为2800token/s

• MFU_encode：指模型浮点运算利用率（在解析输入token情况下）

  • 对于一般的Dense模型，decode阶段的MFU约为0.7，

  • 由于单一请求的输入token量通常较大，MFU受prefill_batch_size和显存带宽大小的影响较小

• decode single throughput：指对于单个请求而言，每秒钟每个模型实例可输出的token数

  • 理论输出速度=\(\dfrac{峰值显存带宽}{sizeof(fp16/fp8/int4) \times 模型参数量}\)

  • 对于以fp16精度，在910B上运行32B模型，理论输出速度=12.5token/s

  • 实际吞吐量=理论吞吐量*效率系数，一般来说效率系数=0.7，故实际输出速度为8.75token/s

• decode overall throughput：指每秒钟每个模型实例可处理的"输出"token数

  • 计算公式与输入相同

  • 考虑到MFU_decoder较低，故吞吐量会比输入低很多，在910B上的实际吞吐量约为700token/s

• MFU_decoder：指模型浮点运算利用率（在解析输出token情况下）

  • 对于一般的Dense模型，最理想情况下decode阶段的MFU约为prefill阶段的一半

  • 为了达到足够高的decode MFU，需要满足一下的两个条件

    • 同时位于decode阶段的请求足够多，需尽可能接近访存比

    • KV-cache足够大，足够让多个请求一起组为一个大batch进行并行解码

  • 对于算力访存比较高的设备（如华为的910B，H100，4090等），在decode阶段将更容易撞上IO墙，该类设备上MFU越低

  • 综合来看，在910B上的MFU_decoder约为0.2

• single request latency：指单个请求从发起到完成的端到端时间

  • 该部分耗时=prefill耗时+decode耗时

  • 其中prefill耗时=sum(输入token) \(\div​\)prefill_throughput

  • 其中decode耗时=sum(输出token)\(\div\)decode_singhe_throughtput

  • 注意：千万不能用等效计算的方法，直接计算出decode所需的时间

• amortized latency: 在批处理或并发场景下，平均每个请求的等效处理时间

  • 计算公式：amortized_latency = total_processing_time ÷ total_requests

  • 或者：amortized_latency = 1 ÷ overall_throughput（当系统达到稳态时）

  • 该指标反映了系统在高并发场景下的平均响应能力

  • 与single request latency的关系：

    • 在低负载时：amortized_latency ≈ single_request_latency

    • 在高负载时：amortized_latency > single_request_latency（由于排队等待）

flops在不同模型上的计算公式

对于一个transformer架构的模型而言，计算n个token所需的算力flops为：

\[2 \times sum(model\ parameter) \times n \]

其中sum(model_parameter)代表该模型的总参数量。

该算法适用于一切基于transformer的模型，包括但不限于：

• 大语言模型LLM

• 任意的encoder-only模型，如embedding和reranker模型

• 视觉语言模型VLM（该估算方法会导致flops偏高，因为VIT模块仅在prefill阶段进行计算，但考虑到一般VIT模块占整个模型的尺寸不到10%，故该估算方法偏差不会太大）

• 语音识别模型ASR（现在的语音识别模型同样是基于transformer架构的，直接通过傅里叶变换将音频采样信息转化为梅尔频谱图后，通过audio encoder送入一个transformer网络）

假设一个系统中存在有多种模型，需要计算总的flops数，我们可以通过上述的公式进行一系列的折算。

• 当然，此处未考虑不同卡之间的调度，在理想情况下，可以使用类似于wake-up的机制实现内存-显存的动态加载，配合上一套动态k8s，以实现算力平均使用。

一个计算例子

现有一个计算任务，其背景大致如下：

• 每年有70000个大模型任务需要处理，任务特征为:

  • 每日的任务量平均出现，且最大峰值为均值的两倍

  • 仅在工作时间进行实时处理，工作时间假设为8小时

• 对于每一个任务，预计需要1.4M token的计算量（已全部等效折算为了prefill的token数量）

• 我们假设多级流水线的级数为10级，其中涉及到单线程输出的token量为5000个

• 该任务基于某一大小的模型进行计算，此处先按照32B的尺寸进行计算

• 基于910B显卡进行，且910B的fp16算力为256T flops，显存带宽为800GB/s

现在需要计算出下列内容：

• 需要多少张910B才能支撑起上述的服务？

• 对于单个任务，预计的耗时为多长（端到端耗时）

计算卡数量的过程如下：

1. 计算出910B处理prefill的token速度为2800token/s

2. 根据1中所述内容，计算单个任务所需的耗时，为500s（全部按照prefill进行计算），或者说，单张910B每小时可以处理7.2个案件

3. 计算出在工作时间，每小时需要处理的最大案件数量，此时计算出来的数量为70个

4. 计算所需的卡的数量\(=\lceil \dfrac{70}{7.2} \rceil=10\)张，考虑到910B以8卡为单位售卖，且考虑拉高峰值系数，建议为16张

计算耗时的过程如下：

1. prefill的耗时为500s

2. 考虑到额外的处理decode token的耗时，此处不考虑重复计算的问题，额外的耗时=5000/8.75-571s

3. 那么，总共的耗时为1071s，可以大致认为是18分钟