加速大语言模型推理：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使用的难度和推理的成本，虽然已经做了很多，但还有很多事情等着我们，道阻且长。
本次分享到此结束。
