本节课将从业务方的角度，讨论如何部署大模型推理业务以及如何提升资源利用率的问题。本次课程内容分为四部分，首先，介绍当前大模型及gpu发展的趋势；然后重点介绍如何部署高效的大模型业务系统，强调其中应注意的问题；接下来，了解如何提升资源利用率；最后介绍如何提升大模型的性价比。

 

一、模型与GPU发展趋势

1、大模型的发展趋势

通过2024年以来更新的大模型情况数据分析当前大模型发展的趋势。

第一，模型开源的趋势十分明显。较为出名的大模型基本上都实现了开源，如千问发布的2.5、Llama3.1模型、DeepSeek、Mistral模型等。当然，也有闭源的专业模型比较流行。很多时候，大家都会使用开源模型进行优化，开发适合自己的业务形态。

第二，模型大小的爆炸式增长。2024年更新的模型多是70B以上的模型结构，还有更大的Llama稠密模型，其达到了405B。

第三，随着模型的增长，其能力也在增加，很少有模型只能处理对话系统，或只能处理问答，多模态是模型增长后的必备能力，几乎所有的模型都能处理文本、图片及视频理解等方面的内容。

第四，MOE模型和稠密模型两种模型的结构是目前大模型的两个发展方向，两者各有千秋。基于基模开发的公司或团队都在向这两个方向发展。通义兼具两种模型。

第五，另外一项突出的能力是长文本处理。从前的大模型只能处理32k的长文本，而现在基本所有的模型至少可以处理128K的文本。最近，也进行了相应的评估，如是否真正具备128k的模型长文本处理能力，在某个时间点或某个长度的点处理时，推理效果或性能是否急剧下降。

2、GPU卡的架构演进

随着模型越来越大，GPU卡从几年的a10 24G的显存到48G、96G。现在，若是既适于训练又适于推理的单模型推理，至少是192G的显存。另外，对于显存的带宽，模型推理方面对其要求较高，新的模型多是4TB的带宽。算子也从以前的BF16发展至FB8、FB6，后面的GPU卡甚至会发展至INT4或FB4。随着卡芯片本身的架构演进，出现了Scale up和Scale out。尤其是在NV link跨机互联逐步流行的过程中Rock level的设计出现，两者的边界较为模糊。就传统意义而言，机器单机8卡、单机16卡，OS管理卡的能力逐渐增加，即Scale up。一般而言，通过NV link网络互联、通过网络包的通讯库互联增加执行规模就是Scale out。现在模型训练基本上都已达到万卡级别，大模型训练的架构由HPN6.1升级到7.0，网络结构更加扁平化。

 

二、部署高效的大模型推理业务

1、考虑的两个方向

高效部署大模型要注意两个方面。第一是业务方向的判断，第二是架构方向的选择。

（1）业务方向

首先，需要明确大模型业务部署的场景，如对话场景、代码补全、长文本处理、阅读理解、会议总结等等。只有确定了目标场景，才能确定SLO（service level objective），即模型业务的服务等级。其中包括两个核心要点，即Sotoken的延时和吞吐量，具体业务指标如何选择后面会展开说明。有了明确的业务场景和业务指标后，还需要选择合适的评估数据集帮助评估GPU的选型、架构的选型是否满足了SLO。

（2）架构方向

当前的卡，尤其是推理方向卡的选择非常多，有A10系列的小模型，甚至有些模型可以在端侧手机上运行，相对较大的可以用L系列或H系列的gpu使用。对于框架的选择，每个大厂可能都自有一套推理引擎，现在开源上流行的包括vLLM、TRT-LLM推理引擎，可以选择基于Pass的Blade或基于ACE的ECS推理引擎。部署业务形态后还要管理gpu资源，我们需要了解每个GPU的运行状态，因为所有的业务形态都有可能运行在容器中，如何进行控制也是一个问题。

2、大模型推理的基础结构

模型推理由两个关键点，第一个基本结构是Prefill阶段，第二个是Decoding阶段。

前面在介绍模型的服务化SLO标准时，其核心点是Sotoken的延时，其对应的是Prefill过程。模型吞吐的token吞吐量对应的是Decoding的过程。对GPU卡来说，这两个过程的区别在于它们对算力和显存的需求不同，主要区别在于KV cache（显存的缓存逻辑）的处理上，前者产生KV cache，后者使用KV cache。KV cache是非常消耗显存的一个过程，Prefill包含大量的计算，它把计算缓存在KV cache中，Decoding会读取这些计算缓存。因此，Prefill对算力要求很高，Decoding是token的吞吐阶段，需要将计算的结果重新读取，因此对显存的带宽要求很高。另外，TTFT是Sotoken的时间，TPOT/TPS是token的吞吐量，Req/s是每秒钟的并发的request，这些都是非常重要的服务指标。

3、部署的步骤

（1）明确业务的目标场景与服务化指标

首先，明确服务场景，可能是对话场景、代码补全、文本序列、会议系统的总结等等，包括sotoken延时跟token的吞吐量。对于一般的对话系统，sotoken延时最多为三秒钟，token的吞吐量最多为200~300毫秒。接下来，选用数据集。每种场景都有各自的数据集，对话场景使用ShareGPT方式评估系统。图中列出了各个数据集的情况，数据集之间除了内容不同，input sequence lens和output sequence lens也存在区别。对于对话系统，input sequence lens和output sequence lens均为512足够；对于代码补全，input sequence lens为512，output sequence lens约为2k；对于阅读理解，要支持128k的长文本处理，加上数字可能需要200k，则会影响后面KV cache及显存的用量。

图中展出了一组数据，包括TTFT、TPOT，理解其对业务系统选择的影响。如千问的1.5-72B的模型。在部署该对话系统模型时，有几种GPU卡的方式可供选择。首先，确定TTFT。保证 sotoken的延时不超过三秒，据此查看sotoken延时的信息，如果是L系列的GPU，并发不能超过5；如果使用Hopper，并发可以达到10。同样，确定token的吞吐量。若保证吞吐量不超过300毫秒，则无论是4卡或是8卡，Hopper GPU基本不会有问题，如果是L系列的GPU，4卡规模的并发数不能超过3。

（2）选择合适的ECS GPU实例并规划显存分配

在部署业务系统时，核心的要点是如何规划显存。在确定了场景、SLO标准之后，就要规划的显存用量，即选择卡。对于显存包括两部分，一个是模型本身，如要部署70B的模型，模型本身就占据了140GB的显存，另一部分是KV cache的用量。以200k长文本处理的方式，进入和输出总和为200k,Llama 7B中每个request会用到100GB KV cache的用量，Llama 13B会用到156GB KV cache的用量，Llama 3 KV cache的用量会下降到62GB，Llama 3 KV cache用量下降的原因在于其模型结构发生了改变，它使用了group query attention的方式，即使如此对于显存的节约也非常有限。如果是三并发服务，显存用量仅为模型本身的140GB，再加KV cache的190GB，此时必须使用48G显存的8卡才能服务。

此外，还需确定TP的策略，选择并行的卡的数量，它影响响应时间和性价比。对于7B模型，如果使用1张卡，单个Req大约需要消耗10秒钟；如果使用2张卡，大约需要消耗8秒钟；如果使用4张卡，大约需要消耗4秒。这些都与SLO的服务指标有关。

4、大模型推理框架与优化

确定了场景、评估数据集之后，选择合适的推理框架和优化策略也很重要。优化程度的优劣可能会产生50%以上的性能差。大模型的优化核心在处理KV cache和Attention逻辑，优化策略有很多,如Page Attention，它可以显著提升显存利用率，再如Flush Attention专门针对卡的spind特点优化性能。

全球风暴架构中使用不同的颜色标出了在各个阶段每个算子的开销，可以发现无论是Prefill还是Decoding阶段，self-attention的计算都是耗时非常大，在Prefill阶段约占78%，Decoding阶段约占59%。即便是59%中还有很多算力消耗在显存的读取上。

总之，对算力拆分有很多优化措施，它们会针对KV cache、算力、模型结构做优化。如Page Attention可以提升显存利用率；Continuous batch功能集成到各种模型框架中，可以显著提升每秒的并发数量；模型的量化（端侧一般量化到int 4，业务上部署的大模型多量化到int8等）可以显著降低显存用量，提高推理的性价比；算子优化的技术要求较高，很多优秀的推理框架已经实现了该项优化，如soft max跟前后做融合，linux算子与激活函数做融合等；系统级的优化，如Prefill-Decoding进行架构分离，部署在两台服务器上，这也是前段时间业内讨论较多的一种方式。

 

三、DeepCPU-LLM提升推理效率

前面从场景选择、SLO选择、性能调优等方面介绍了部署大模型业务。这一部分介绍DeepGPU推理框架。

1、DeepCPU-LLM提升推理效率

它是基于Iaas层ECS实例的推理框架，支持免费试。它的优点在于其完全兼容HUGGINGFACE的接口，如果使用HUGGINGFACE，就可以用DeepGPU的方式进行推理，而无需额外的适配工作；此外，其性能也优于VLLM，对比VLLM的0.5.3版本，其性能的优势约为10%以上，对于Llama70B，其优势更明显。

2、DeepCPU-NCLL提升通讯库效率

优化工具是的NCCL版本，把对于通讯库的优化给剥离出来。今天的各种模型优化多是多机多卡的方式，其中通讯库的优化与模型适配非常关键。之所以将其剥离，是因为很多客户在业务系统集成时不希望变动框架，把通讯库优化剥离出来避免了适配成本。使用DeepNCCL的方式与NCCL完全相同，但可以大大提升其性能。

以72B的8卡L系列的GPU为例，对比仅使用了标准NCCL而不启用DeepNCCL，以及使用优化过的DeepNCCL采集性能，后者的吞吐量提升了14%，sotoken的时延降低了15%，仅通过简单的适配就得到了性价比的提升。

 

四、GPU容器的细粒度资源控制提升效率

在业务全部部署在系统上后，如何管理系统也非常重要。当今，绝大部分的业务运行都以容器化的形式，一个GPU的pod服务各种各样的业务，这是在K8S层的调度层面。事实上，对于GPU的管理还需要细粒度的GPU的管理工具，它可以显示pod中的GPU的当前的状态，包括显存的用量、算力，确定是否有资源浪费，显存的使用是否合理，调度系统如何使用，KuberGPU可以实现该功能。

1、KuberGPU是什么

KuberGPU是技术解决方案，而非产品，在用户创建ACS或ACK时背后就会使用到该技术站。它提供了以下几项能力：

（1）GPU虚拟化

第一，虚拟化是指似的GPU可以提供0.25、0.5算力或0.75算力，通过这种虚拟化的方式，在容器层使用使用高阶功能时无需再关心其底层的实现方式。第二，它支持GPU workload的抢占及显存的高阶管理。

（2）GPU弹性管理

它可以支持一定程度的业务迁移和GPU POD迁移的能力。

（3）GPU管理

它自带GPU监控、故障诊断以及GPU异常预测等，数据采集等工作都在底层完成，再通过某种途径把信息汇报到K8S层。

（4）GPU池化

在业务方需要pod时，它可以指定一定算力的GPU容器，还可以动态调整分配给pod的算力大小甚至显存大小，使其在某种程度上可以进行各种业务的混合，调度更加灵活。

这些功能都会与ACS和ACK两个容器实例相结合。其使用方式较为简单，是通过yaml文件的配置实现的，而无需感知其底层的配置方式。

2、推理业务的容器化与资源精细管理

KuberGPU会对K8S的Phrigin以及Exporter标准组件做扩展，并将其数据上报给K8S层。

以KuberGPU用于离在线混合部署为例，其数据来源于几年前小模型运行的数据。可以看到，在实际业务中，集群的GPU利用率较低，仅有4%，但在业务高峰期或是接受业务请求时，则需要占到80%左右GPU的算力。如果在收到业务请求后再创建实例、部署业务系统是远远来不及的。

其GPU利用率低与其波峰波谷的措施有直接关系，业务自身多种任务的特点也会对齐造成影响，此外，也与如今卡的显存、容量、算力越来越大有关。除70B的模型之外，还有很多13B、7B的模型，它们使用2G显存即可完成部署。此外，还有很多传统的模型，其使用的GPU值较低，会导致资源粒度太大不利于管理，也就无法提升资源利用率。KuberGPU可以在波峰波谷的周期内穿插的各种任务，也可以根据业务的实际算力需求分配容器，甚至可以实时控制容器中算力的大小。

业务运行时的响应时间（QPS）大约为21毫秒，如果不开启离在线混部，其GPU利用率相对较低，但利用KuberGPU做离在线混部可以显著提升利用率，甚至达到近80%，极大降低了推理的成本。