LLM推理：GPU资源和推理框架选择
作者： 吃果冻不吐果冻皮 来源： 吃果冻不吐果冻皮
原文：https://zhuanlan.zhihu.com/p/678763741
一、引言
ChatGPT引爆了各行各业对生成式AI（Generative AI, GenAI）的广泛关注，甚至可以说是狂热追捧。经过2023年的蓄力，如资本涌入、人才储备、算力囤积、模型训练、应用场景探索等等，2024年将迎来GenAI规模化商业应用。大语言模型（Large Language Model, LLM）推理服务是很多GenAI应用系统的基础功能组件，LLM推理服务的成本会在很大程度上影响GenAI应用的收益与成本的平衡。本篇介绍LLM推理服务所需要的GPU资源和LLM推理框架的选择，希望能为大家构建LLM推理服务提供参考。
二、LLM推理GPU资源选择
LLM推理需要选用什么样的GPU，取决于LLM的参数规模。常见的LLM参数规模有7B、13B、34B、72B、130B、176B、260B等等（其中，1B = 10亿，1T = 1万亿）。
常见LLM参数规模举例（1B = 10亿，1T = 1万亿）
到目前为止，我们了解到在2024年可以批量供给的GPU卡包括** Nvidia H20、L20、A10，以及国产AI芯片（如昇腾910、邃思2.0、昆仑芯XPU 2代等等）** 。当然，还有存量的（囤积的）Nvidia A800、H800、L40S、A30等GPU卡可用于LLM推理服务。
GPU/AI芯片Dense DFP16算力（TFLOPS）Dense FP8算力
（TFLOPS）Dense INT8算力
（TOPS）显存容量（GB）显存带宽（GB/s）芯片互联
（GB/s）功耗（W）
H800
（8卡高速互联）
989
1979
1979
80
～3350
NVLink：400;
PCIe Gen5: 128
700
A800
（8卡高速互联）
312
624
80
2039
NVLink：400;
PCIe Gen4: 64
400
H20
（8卡高速互联）
148
296
296
96
～4000
NVLink：900;
PCIe Gen5: 128
400
L20 119.5 239 239 48 864 PCIe Gen4: 64 275
A10 125
250 24 600 PCIe Gen4: 64 150
A30
（2卡高速互联）
165
330
24
933
NVLink：200;
PCIe Gen4: 64
165
V100
（4卡高速互联）
125
–
32
900
NVLink：300;
PCIe Gen4: 64
300
910B
（模组，8个芯片高速互联）
376
752
64
～1600
HCCS: 392;
PCIe Gen5: 128
400
邃思2.0
（模组，4个芯片高速互联）
160
320
64
～1800
LARE: 300;
PCIe Gen4: 64
400
XPU2.0
（模组，4个芯片高速互联）
128
256
32
512
高速互联: 200;
PCIe Gen4: 64
150
LLM推理服务一般是在线服务，需要实时响应，要求响应时延满足用户要求，例如，首token时延（time to first token）要求在2秒以内 [1]。这样的实时在线LLM推理服务一般都是显存IO速度受限的服务（Memory-Bound）[1, 2]。换句话说，对于实时在线服务，优化LLM推理的吞吐（throughput，如tokens per second）不是首要目标。除了首token时延，LLM在线服务也可能会把尾token时延（即完成response的时延）作为优化目标，例如，当LLM推理服务作为中间环节时，就会希望response的尾token时延越小越好。
在Memory-Bound场景里，为了提升GPU利用率，一般会采用张量并行（Tensor Parallelism, TP），将LLM模型参数进行切分，从而减少从显存中读取模型参数的耗时。
举例而言，对于13B的模型，如果使用FP16精度进行模型推理，那么模型参数所占的显存空间约为 ～24.21 GB （132/(1.024**3) ~= 24.21）。如果是使用单张L20卡进行推理，那么从显存中读取模型参数的耗时约为 ~0.02802秒（～28.02毫秒，24.21/864 ~= 0.02802）。如果是使用两张L20卡进行推理，并选择TP=2，那么从显存中读取模型参数的耗时约为 ~0.01401秒（～14.01毫秒，24.21/(8642) ~= 0.01401）。关于LLM推理的数学原理和性能优化方法，我们将在另外一篇文章里详细讨论。
当然，因为使用多卡进行模型推理，一般需要采用TP策略，而TP策略会带领额外通信开销，所以也不是越多卡越好，需要根据模型参数规模来选择折中方案，并通过实际测试来看哪个方案时延最优。进一步的，当单机8个GPU卡（或8个AI芯片）总的显存都放不下模型参数时，就需要使用流水线并行技术（Pipeline Parallelism, PP）[13, 14]，以便将模型参数切分到不同的服务器上，或者是采用ZeRO-Inference大模型推理技术，将模型参数切分以及将模型参数offload到CPU内存 [15]。
针对不同参数规模的LLM，其推理所使用的GPU资源选择也不一样，主要考虑的因素就是模型参数所占的显存空间以及推理服务的性价比。使用FP8精度或者INT8精度进行LLM推理，可以显著降低显存空间开销，也可以有效降低计算开销。一般情况下，使用FP8精度推理比使用INT8精度推理可以获得更好的模型效果（或者说，相对于FP16计算，FP8计算带来的模型效果损失更小）。
考虑优化在线LLM推理服务时延（如batch size = 1），我们推荐以下LLM推理资源配置。
模型参数规模推荐单个推理实例配置GPU卡/AI芯片及数量 - FP16计算推荐单个推理实例配置GPU卡/芯片及数量 - FP8/INT8计算备注
6B ～ 20B 2 x（L20，L40S，A10，A30，V100，邃思2.0，XPU2.0） 2 x（L20，L40S，A10，A30，邃思2.0，XPU2.0）
33B，34B
2 x（L20，L40S，邃思2.0）；
4 x（V100，XPU2.0）
2 x（L20，L40S，A10，A30，邃思2.0，XPU2.0）
45B ～ 53B
2 x 邃思2.0；
4 x（L20，L40S，V100，XPU2.0）
2 x（L20，L40S，邃思2.0，XPU2.0）；
4 x（A10，A30）
65B ～ 72B
4 x（L20，L40S，邃思2.0，910B）
2 x（L20，L40S，邃思2.0，910B）；
4 x（A10，A30，XPU2.0）
102B 4 x（910B，邃思2.0，H20，A800，H800） 2 x（910B，邃思2.0，H20，A800，H800） 要求4个芯片之间有高速互联
130B ～ 200B 8 x（910B，H20，A800，H800） 4 x（910B，邃思2.0，H20，A800，H800） 要求8个芯片（或4个芯片）之间有高速互联
260B
8 x（H20，A800，H800）；
16 x 910B（TP & PP）
4 x （H20，A800，H800）；
8 x 910B
要求8个芯片（或4个芯片）之间有高速互联
530B ~ 540B
16 x（H20，A800，H800）；
32 x 910B
8 x （H20，A800，H800）；
16 x 910B
要求8个芯片之间有高速互联 （TP & PP）
三、LLM推理框架选择
当前比较流行的开源可免费商用的LLM推理框架有TensorRT-LLM [3]和vLLM [4]这两个，这两个开源项目的License都是Apache License 2.0。
TensorRT-LLM是Nvidia开源的LLM推理引擎，由开源项目FastTransformer演进而来，TensorRT-LLM需要结合Triton Inference Server才能构建完整的LLM推理服务。如果需要支持基于RESTFul API的流式输出（例如，类似OpenAI的LLM推理API接口），还需要进一步配合FastAPI才能支持流式输出，这是因为目前Triton不支持基于RESTFul API的流式输出。TensorRT-LLM目前还不是完全开源的，例如，Batch Manager 目前是不开源的[10]。
vLLM是由UC Berkeley主动开源的LLM推理框架，基于vLLM可以搭建完整的LLM推理服务，且默认可以支持OpenAI API协议。vLLM的关键优势之一是支持PagedAttention [9]，将每个序列的KV cache划分为块，允许在非连续的显存空间中存储KV cache ，可以高效管理KV cache在显存的存储并减少IO时间。 关于KV cache [2, 12]，我们将在另外一篇文章里详细介绍。
TensorRT-LLM [3]vLLM [4] 是否可免费商用 是（Apache License 2.0） 是（Apache License 2.0）
是否可搭建完整LLM推理服务 只有推理引擎，需结合Triton（和FastAPI）构建完整推理服务 可直接构建完整推理服务
易用性 需要编译模型文件（build engine） 可直接挂载模型文件
首token处理方式 Context Phase（生成首token）与Generation Phase（生成其他token）混合，会互相影响 –> 可获得较好的首token时延和尾token时延的平衡 优先处理首token，Context Phase与Generation Phase交替执行，Context Phase会导致Generation Phase暂停 –> 优化首token时延，尾token时延变差
FP8推理 支持（在降低推理GPU资源开销的同时获得较好的模型效果） 目前不支持
INT8推理 W8A8（SmoothQuant），W8A16（Weight-only） W4A16，W4A8，W4A4
Prefix Sharing (System Prompt Caching) 支持System Prompt Caching，避免重复计算System Prompt，可显著降低GPU资源开销（提升推理服务性能） 目前不支持
是否需要padding 可不需要padding（支持Packed Tensors [5]） 需要padding
Dynamic SplitFuse [7] v0.8版本将支持 [6] 目前不支持
是否支持FlashAttention [8] 是 是
是否支持PagedAttention [9] 是 是
是否支持Continuous Batching（iteration-level batching）[11] 是（in-flight batching） 是
####历史文章： 2024年2月大模型文章集锦
更多AI工具，参考Github-AiBard123，国内AiBard123
