加速大语言模型推理:NVIDIATensorRT-LLM更新
内容介绍
一、大模型推理挑战与解决方案
二、大模型推理优化与性能提升策略
三、KVCash在用户请求处理中的应用
四、大模型优化与应用探索
本次分享的主题是加速大语言模型推理:NVIDIATensorRT-LLM更新,由NVIDIA开发与技术部门亚太区资深总监李曦鹏分享。
今天分享的是对大语言模型推理加速的思考,并且讲解大语言模型的推理的难点,以及该如何解决这些难点。
一、KVCash在用户请求处理中的应用
首先大语言模型场景是高度分化的。业务有大量服务是应用于内部的,有时推荐系统的pipeline很长,但是最后用户看到的界面是很简单的。所以他可以把大量的延迟或者复杂性隐蔽掉。但是大模型是直接面对我们的最终用户,所以它的使用场景和其他的类型不同,在chat时,也有可能是让大模型解决一些数学问题,所以他对inputsequencelength、outputsequencelength以及batchsize和firsttokenlatency。
如果是chat,便希望能尽快生成内容;如果是要写code,便希望内容能直接生成整体,而不是一个一个字的生成。另外对模型的能力要求很大,这就会使得这个模型至少是需要一个非常大的size。这样的巨大的模型第一次需要使用多卡,甚至是多机器进行推理。
再举个gpt4的例子,基本模型需要八台nvidiagpu的服务器做推理。以前的推理是使用单卡,甚至是一张卡上跑多个任务,其中的内容十分不同,所以推理场景未来也可能会变成一个算力,消耗非常大,这是高性能计算的一个问题。在GPT发布了OE模型中,发布者证明了learning也可以做scalinglaw,如果加上meta他们的证明过程将会取得进一步成果。
所以相信scalinglaw是一个普遍存在的规律,但做reinforcementlearning的scalinglaw会用到大量的推理过程,所以推理不但是在用户使用过程中变得越来越重要,调教模型能力的时候也变得越来越重要,而且推理的量级更大。在线部署对时延的要求是希望及时响应,程序员对于自动代码生成不太适应的原因是它生成的速度不够快,习惯了原来代码补全的那个速度,所以它对时延是有很多要求的。因为模型大,推理慢,所以导致它的成本高,而且目标很多。
一方面要提高每一个GPU上的生成token的数量,与此同时还要去提高每个user。而每秒生成token的数量也就是latency,所以这两个目标其实是有一些矛盾的。其中推理和调度是仅耦合的,原本都是单独的推理引擎,再加上一个调度系统,因为模型都是在单个GPU上运行的,所以作为一个单独的调度系统就完成了。
但是现在不但要做模型的推理,调度的时候因为Contextface和generativeface两个的一些表现属性很不一样,因为context可以看到所有的token,所以它其实是计算密集型,但generativeface其实是memoryband密集型,所以现在有很多创新,一类是说inferbatching,把在线的去打batch。
还可以做这个PD分离,这都是不断涌现的一些创新。另外模型比较多,这个数据比较过时,现在应该是超过一万个模型了,modelscope模型的精度多,还有量化算法多。在原来量化也很流行,但是没有到大模型的时代,这个不可或缺。
二、KVCash在用户请求处理中的应用
NVIDIA对于一直致力于开源生态应对上述的挑战,答案是TensorRT开源的解决方案就是推理引擎,也是内部天字第一号NVIDIA的项目,我们都相信大模型推理优化是大模型落实的重中之重,它提供了非常多简单的API,可以通过python或者C++的API。
另外最关键的NVIDIA,常年来其实就做两件事情,一个事情叫性能,如何能把硬件的性能完全榨干,开发一个产品或者是一个东西时,就有一个概念叫做speedoflight。与这个硬件的物理极限去做对比,一般来说达到是70%、80%甚至90%,如果是单纯的矩阵层的话,都是95%以上的performance才合格。所以一定会去保证sata的性能,充分的利用了像TensorRT本身的编译能力,原来fasttransformer的kernel还有cutopenatriton的kernel,另外也和TensorRT的engine进行了联动。
NVIDIA一直致力于Deliver性能,另外一个事情就是我们要降低这个使用的难度,不管从最早做cuda还是在cuda上面的各种library,还是TensorRT-LLM包括triton,它都是为了降低用户的使用难度,而和triton的结合,其实就达到了一个一加一大于二的地步。调度和Inference是仅耦合的关系。TRTM的一些架构,我们可以看到,首先它有基于TCRT的runtime,同时还有python或者C++的一些runtime来做一些辅助的工作。
在上层它有一个模型build的一个过程。builder提供了像TensorRT的一些言语,可以在TensorRT-LLM里边用一些更简单的方法去构建一个TensorRT-LLM支持的算子。另外我们从FT里边继承了非常多的kernel,像Fmentionkernel,肯定也是业界最快的关于attention的可能。另外涉及到多卡,多机的通讯,有nico的communication的kernel,上层是有各种各样构建的层和一些预编译的模型,是TRTOM的重要特性做一些介绍,第一个是windowattention或者是更多一点的slidingwindowattention,是我们现在的一个需求方面,我们希望去增加文本的长度,同时我们又想去降低这个KVCache的一些使用。
其实去年的时候提过一些数学上等价或者数学上的一些优化方法,可能在今年上半年的时候基本上都已经做完了,更多的其实需要去做一些performance和速度的一些渠道,windowattention就是其中一例,attention是全局的,只是去做跟我相应邻居的一个,可以很容易想到在精度上肯定是有些损失的,所以这是一个tradeoff,streamlm是另外一个概念。
一般来说,一个请求开头的token是比较重要的。另外现在要生成相邻token是比较重要的,把两个东西都利用起来,然后保证一个KVCache是一个固定值,这样的一些优化在CSRT里也都是支持的。另外关于KVCache的优化,比如说我们支持了page的KVCache,也就是知道pageattention利用一些技术手段解决显存碎片化的问题,像以前windows硬盘。
所以要做磁盘清理,是有点类似于这个方式,它可以减少这个性能,减少这个利用。同时我们去做了KVCache的一个量化,将KVCache从原来的16位的浮点数降到int8或者FP8,当然也可以想象fp8的量化效果肯定是更好的,损失是更小的。hopper这样的机器上,我们其实直接去使用fp8的KVCache肯定是最好的。
三、KVCash在用户请求处理中的应用
KVCache也是一个非常有意思的feature,我与一些做大模型提供服务的公司同学交流,他们给我一个数据,80%的用户请求其实是可以被Cache住的。用户的请求千奇百怪,为什么会出现这样的情况?如果大家打开一些app。它会有一些预检项。比如今天的天气怎么样?今天的什么?就跟搜索的预选项一样,其实是用户比较懒而导致的。他会去预点这些已经设置好的,这一些prompt甚至它生成的context的prompt,都是可以被提前Cache住的,所以可以去做一个加载。
像回合制的对话,过一段时间后,与他聊完后,过一段时间先把他叫回,再跟他聊,这时你要去支持KVCacheReusage,和做PD分离,就是把preview和decodingface分开。还有一个用处是systemprompt,最近anthropic对它开源,它开放了crowd的systemprompt,它模型就是这个,通过去调整systemprompt呈现不同表现形式,这些都是可以预先计算出来,然后把它给缓存下来。InflightBatching是一个非常有用的技术,大模型推理规律时,存在请求长度不固定,所以preview和decodingface的计算行为也不太一样,所以InflightBatching其实是一个非常好去解决的一个方法。
四、大模型优化与应用探索
刚才的细节,是告诉各位其实主流的、能看到的是优化策略,在TRTLM里面其实都有支持,并且TRTLM还在飞速的进化。最近8月31号发布的这个v0.12版本,包括了对象MOE模型的laura。对于ADAMGPU上的fp8,optimization的支持,还有包括一些投机采样,进一步的优化,也支持了像LLaMA3.1,Mamba2,Qwen2。对于这些模型,相信下一个版本Qwen2.5都会支持。另外很多做实际业务的同事,确实是非常着急,一些新的feature,我们也提供了每周weeklyupdate开发的branch可以使用。NVIDIA,也录制了开源社区的合作,而魔搭是现在国内最领先的这个大模型的开源社区。魔搭社区已经发布超过一万个模型。
与此同时,TensorRT-LLM和魔搭社区的合作首批,其实已经支持了包括Qwen2在内超过50个主流不同的可以加速,其中会提供一键部署,使用范例,可以基于魔搭社区和快速构建一个推理服务和大模型。
对Qwen2-72B模型的优化,通过优化过后,在相同的精度下,比如都是bfloat16的情况下,相比他和face原始的视线框架去做推理,整体的吞吐性能达到七位以上。同时TensorRT-LLM支持很多的量化策略,比如像灰类的量化,比如像GPTQ的量化,使用这些量化策略可以进一步的减少尺寸,减少内存带宽计算功耗的需求。
因为特别是fp8的量化,相当于INT8,INT4,可以保持更高的一个精度,是可以获得一个更好的一个性能,可能有人认为自己去转这个TensorRT-LLM格式太麻烦,于是魔搭近期实验也加入了TensorRT-LLM的记录账号,已经有大量转换好的TensorRT-LLM,可以下载一键部署,现在可以在魔搭社区去尝试一下。除魔搭社区以外,目前在阿里云平台上已经全面集成了NVIDIA的大语言模型软件栈,包括基于Megatron-Core的MoE大规模训练。可以在在P平台上面可以找到map,在其中找到nemo的训练框架,也有预装好的TensorRT-LLM的倾向。
同时可以让你在阿里云上快速享受训练和推理的加速。
这么多挑战解决方法,其本质就是合作,大模型发展真的是才刚刚起步,现在还处于AGI非常初期的一个时态,这条很长的路,起步就像三米就破百的加速,非常强的推背感,过去8个月新出现的帮助推理的技术比过去5、6年新技术都要多,也是非常希望使用TensorRT,是魔搭社区一起帮大家降低LM使用的难度和推理的成本,虽然已经做了很多,但还有很多事情等着我们,道阻且长。
本次分享到此结束。