stephen147的博客

通过融合前两个计算步骤，降低执行Reduce_max和Reduce_sum等操作的通信开销。利用共享内存来存储临时数据，以减少对全局内存的访问成本。

默认情况下，LMDeploy 会根据算法 repo 提供的对话模版将表示图片的特殊 token 插入到 user prompt 中，但在一些模型中，图片 token 的位置并没有限制，如 deepseek-vl，或者用户需要自定义图片 token 插入的位置。因为复用VLMs上游库关于图像的预处理和视觉模型的推理，且不同的VLM依赖各不相同，出于维护性方面的考虑，LMDeploy 没有把 VLMs 的依赖，比如 timm，flash-attn，放在自己的依赖列表里。（后续考虑移除，相信用户）

图中左侧是用户使用界面，罗列了上述所说的两种调用方式（注意，如前文所说，做demo用的api server官方已经不再维护了，openai_api_server才是官方推荐的使用方式，user custom server目前还没有实现）。右侧则是开发者界面，不难发现LLMEngine是vLLM的核心逻辑。我们来看开发者界面下的几个函数，先来看**LLMEngine。

模型量化是指以较低的推理精度损失将连续取值（通常为float32或者大量可能的离散值）的浮点型权重近似为有限多个离散值（通常为int8）的过程。通过以更少的位数表示浮点数据，模型量化可以减少模型尺寸，进而减少在推理时的内存消耗，并且在一些低精度运算较快的处理器上可以增加推理速度。具体如下图所示，[-T, T]是量化前的数据范围，[-127, 127]是量化后的数据范围。

肯定很多人想知道triton干啥的，学习这个有啥用？triton可以充当服务框架去部署你的深度学习模型，其他用户可以通过http或者grpc去请求，相当于你用flask搭了个服务供别人请求，当然相比flask的性能高很多了triton也可以摘出C-API充当多线程推理服务框架，去除http和grpc部分，适合本地部署多模型，比如你有很多模型要部署，然后分时段调用，或者有pipeline，有了triton就省去你处理显存、内存和线程的麻烦注意，还有一个同名的triton。

本篇介绍以Triton作为推理服务器，TensorRT作为推理后端，部署句嵌入向量模型m3e-base的工程方案和实现，句嵌入模型本质上是Bert结构，本案例可以推广到更一般的深度学习模型部署场景。推理服务器和推理后端介绍TensorRT+Triton环境搭建Bert模型转化为ONNX中间表示ONNX中间表示编译为TensorRT模型文件Triton服务端参数配置Triton服务端代码实现Triton服务端启动HTTP客户端请求TensorRT前后压测结果对比。

由于量化前的激活值变化范围较大，即使对于同一 token，不同channel数值差异较大，对每个 token 的量化也会造成精度损失，但是不难看出较大值一般出现在同一 channel，因此作者也分析了采用 per-channel 的量化方式，这种量化方式能很好的避免精度损失，但是硬件不能高效执行，增加了计算时间，因此大多数量化仍采用 per-token 及 per-tensor 的量化方式。最后，我们再计算与 A 和 B 的最大绝对值向量的外积，并将此与 C 求哈达玛积来反量化回 FP16。

浮点数精度：双精度（FP64）、单精度（FP32、TF32）、半精度（FP16、BF16）、8位精度（FP8）、4位精度（FP4、NF4）量化精度：INT8、INT4 （也有INT3/INT5/INT6的）另外，实际使用场景中，还有多精度和混合精度的概念假设你每秒钟赚到的钱是1块钱，那一个月的收入是160602430=216000，如果每秒钟赚到1块1呢，那一个月的收入是237600，就一个1毛钱的小数点，让你月收入少了1万多，这就是精度不同导致的差异。

大家都知道大模型是通过语言序列预测下一个词的概率。假定x1​x2​x3​...xn−1​为已知序列，其中x1​x2​x3​, …,xn−1​均为维度是dmodel​的向量，qn​kn​vn​同为向量。当输入xn​时，需要预测xn1​的概率分布。

提示词总结的核心思想是在保持相似的语义信息的前提下，将原有提示词浓缩为更短的总结。这些技术还可以作为提示词的在线压缩方法。与前面提到的保留未裁剪标记的提示词裁剪技术不同，这一行方法将整个提示符转换为总结。RECOMP[34]引入了一个抽象压缩器（AbstractiveCompressor），其将输入问题和检索到的文档作为输入，生成一个简洁的摘要。具体来说，它从大规模的大模型中提取轻量级压缩器来进行总结工作。SemanticCompression提出了一种语义压缩方法。它首先将文本分解成句子。

推理是 LLM 应用的重要一环，在部署服务环节影响重大，本文将讨论主流的 LLM 的推理优化技术。

1.1 GPU 硬件特点由于 FlashAttention 计算 self-attention 的主要关键是有效的硬件使用，所以了解GPU内存和各种操作的性能特征是很有必要的。以 A100 (40GB HBM) 为例，下面显示其内存层次结构的粗略图。SRAM内存分布在108个流式多处理器(SMs)上，每个处理器192KB。片上SRAM比HBM快得多，但比HBM小得多，在计算方面，使用Tensor Core的BFLOAT16 的理论峰值吞吐量为 312 TFLOPS。GPU 的典型操作方式是使用大量的线程

LLM推理优化我认为总共可以分为以下几个方面：

大模型推理加速的目标是高吞吐量、低延迟。吞吐量为一个系统可以并行处理的任务量。延时，指一个系统串行处理一个任务时所花费的时间。调研了一些大模型推理的框架。

现代大型语言模型（LLMs）基于Transformer架构，该架构利用注意力机制和多层感知器（MLP）来处理输入。基于流行的Transformer模型，例如GPT [10] 和 LLaMA [11]，采用的是仅解码器结构。每个推理请求在逻辑上被划分为两个阶段：预填充阶段和解码阶段。在预填充阶段，所有输入token并行处理。此阶段生成第一个输出token，同时存储计算出的中间结果，这些中间结果被称为KVCache。

🤗 Optimum 提供了一个名为 BetterTransformer 的 API，这是标准 PyTorch Transformer API 的快速路径，能够通过稀疏性和融合内核（如 Flash Attention）在 CPU 和 GPU 上实现有趣的加速。目前，BetterTransformer 支持来自原生 nn.TransformerEncoderLayer的快速路径，以及 torch.nn.functional.scaled_dot_product_attention。

但从使用体验上看，vllm，lmdeploy使用方便，直接从model hub下载模型即可，而tensorrt-llm需要转换和编译模型，并且创建合适的引擎环境也有一定的成本，需要tensorrt-llm，triton server以及tensorrt-llm backend，格步骤参数有一定关联性，极易出错，总体使用成本对比会高不少。在prefill阶段后返回的第一个token的时间，在stream输出模式下，对体验影响大，越小用户等待返回第一个token时间越小，体验越好。每秒处理完成的请求数。