当你自己在服务器上部署好一个模型后,使用场景会有两种。第一种就是你自己去玩,结合自有的数据做RAG等等,这种情况下一般是不会考虑并发的问题。第二种是将部署好的服务给到别人来使用,这时候就必须知道我的服务到底支持多大的访问数量,是否要做分布式部署。本文先不扩展分布式部署,字数有限这部分内容另外些一篇文章。
一、预估模型推理时显存占用的计算公式
模型参数 * 每个参数所占字节 = 权重所需显存
① 已知条件:模型参数数量为70亿(7B)个参数。每个参数使用 16位浮点数 表示,即每个参数占用 2字节(Bytes)。
② 计算过程:
总存储需求 = 参数数量 × 每个参数占用的字节数
=
=
转换为GB()即:
③ 结论为:模型权重的大小约为 14GB。因此,为了加载这个模型,显存容量需要大于14GB,否则会因为显存不足而无法运行。
④ 重要说明:实际应用中,除了模型权重本身,还需要额外的显存来存储以下内容。
- 优化器状态:如果使用优化器(如 Adam),它会存储额外的状态信息(如动量、方差等),通常会使显存需求翻倍或更多。
- 激活值和中间结果:在训练或推理过程中,模型会生成大量的中间数据,这些也需要占用显存。
- 批量数据(重点关注):输入数据和对应的标签也会占用一部分显存。
加载一个7B模型大概需要14G的显存容量,但这仅仅只是加载到显存上而已,都还没开始推理呢。一旦模型开始推理,就会额外占用更多的显存。好在现有的大模型推理框架可以帮助我们优化显存。
二、计算剩余显存量支持的最大并行访问数
vLLM 和 LMDeploy 这样的大模型推理框架时,采用了许多优化技术(具体哪些优化技术我自己也还在学习中,文末附上知乎大佬的文章链接供大家一同学习),有效的减少显存占用和提高推理效率。这意味着对于优化器状态和激活值的显存需求可能已经得到了有效的管理或减轻,使得这些因素在估算显存需求时变得不那么关键。然而,用户输入(例如批量数据、请求数据)依旧是影响最大并行访问数的重要因素。
假设你的服务器还剩余GB的显存,你可以根据每个请求需要的显存量来估算最大并行访问数。这里有一个简化的计算方法:
① 先估算单个请求所需的显存量
包括处理用户输入所需的显存以及运行模型时生成的任何临时数据。如果这个数值不是直接给出的,你可能需要通过实验或查看文档来获得一个近似值。一般在你所下载的模型中有个config文件,里面的max_length就是的了。设这个数值为MB(注意单位转换,因为通常这里的数值会比较小,用MB更直观)。

② 再计算最大并行访问数
将剩余的显存量从GB转换成MB( ),然后除以单个请求所需的显存量
MB:
用千问2.5-7B和24G显存举个例子具体举例(,
):
在给定的条件下,服务器最多可以支持 256个并行访问。
【注】除了显存,还需要考虑 CPU、网络带宽、磁盘 I/O 等其他硬件资源是否能够支持如此高的并发。还有就是请求大小不是一成不变的,单个请求的显存需求 Y 会随输入数据的变化而波动。
公式是理论上的最大值。实际应用中,为了保证系统的稳定性和响应速度,你需要做一些测试,然后做具体调整,比如预留 20% 的显存作为缓冲。不过这种方法,也足够让你可以预估出在当前硬件条件下,你的服务能够同时处理的最大请求数量,从而更好地规划资源和服务能力。
推荐SayHelloCode大佬写的有关vLLM推理优化原理的博客:vLLM(一)PagedAttention 算法