。结构裁剪面对超大参数量模型，不做裁剪直接部署，那是真不现实。常用的一招是剪掉影响不大的层，列如中间冗余的attention block，或者MLP里维度特别高的部分。 也可以用结构重参数化的思路，把训练阶段复杂结构，推理阶段合并掉。 列如RepVGG这种思路，在部署端的确 省了不少资源，速度一下就起来了。 别怕精度掉，许多时候影响不大float32是真的吃资源，大部分模型实则用不到这么高的精度。许多时候量化成int8或者混合精度fp16，性能提升是肉眼可见的。尤其是目前推理框架基本都支持量化感知训练和后训练量化，只要校准做得稳，效果基本能hold住。 我们线上用过一版int8部署，推理时间几乎砍了一半，精度也就掉0.3左右，完全能接受。 框架不改，算子先动起来许多人忽略了这一步，实则你模型结构不变，只是把默认的PyTorch算子换成TensorRT、ONNX优化版本，也能提升一大截。列如conv+bn融合、GELU近似替换、Flash Attention替换标准注意这些，都能拉高速度。尤其一些复杂模型里的自定义作，提议重写成CUDA kernel，自己对齐精度，最终部署才好用。 别让每条输入都单独过一遍模型推理如果每次都是单条输入走一遍，全流程重复太多，完全不划算。 要搞推理服务，第一步就是支持batch推理，按需动态填充、batch合并，加上continuous batching机制，GPU能吃满，吞吐量起飞。 我们实测一个视觉检测模型，从单张推理到批量32张，速度直接提升了4倍还多。 KV缓存优化对于生成式模型，KV缓存是性能瓶颈。目前主流做法是PagedAttention这种内存分页管理，避免显存碎片化。还有就是KV缓存压缩，保留关键token的缓存，其他的动态计算，既省显存又不影响效果。 经验分享之前在做一个文本生成服务的推理优化，前期只用了fp16和TensorRT，感觉还挺快的，结果上线后发现延迟波动特别大。后来加了动态batch和prefill缓存机制，才把尾延迟压下来。还有一点要提醒大家，千万别忽视tokenizer的耗时，有时候tokenize比模型本身还慢，必定要一起优化，不然速度提不上去。
© 版权声明
文章版权归作者所有，未经允许请勿转载。
相关文章
大模型推理优化的几个常见技术。结构裁剪面对超大参数量模型，不做裁剪直接部署，那是真不现实。常用的一招是剪掉影响不大的层，比如中间冗余的attention block，或者MLP里维度特别高的部分。 也可以用结构重参数化的思路，把训练阶段复杂结构，推理阶段合并掉。 比如RepVGG这种思路，在部署端确实省了不少资源，速度一下就起来了。 别怕精度掉，很多时候影响不大float32是真的吃资源，大部分模型其实用不到这么高的精度。很多时候量化成int8或者混合精度fp16，性能提升是肉眼可见的。尤其是现在推理框架基本都量化感知训练和后训练量化，只要校准做得稳，效果基本能hold住。 我们线上用过一版int8部署，推理时间几乎砍了一半，精度也就掉0.3左右，完全能接受。 框架不改，算子先动起来很多人忽略了这一步，其实你模型结构不变，只是把默认的PyTorch算子换成TensorRT、ONNX优化版本，也能提升一大截。比如conv+bn融合、GELU近似替换、Flash Attention替换标准注意这些，都能拉高速度。尤其一些复杂模型里的自定义作，建议重写成CUDA kernel，自己对齐精度，最终部署才好用。 别让每条输入都单独过一遍模型推理如果每次都是单条输入走一遍，全流程重复太多，完全不划算。 要搞推理服务，第一步就是batch推理，按需动态填充、batch合并，加上continuous batching机制，GPU能吃满，吞吐量起飞。 我们实测一个视觉检测模型，从单张推理到批量32张，速度直接提升了4倍还多。 KV缓存优化对于生成式模型，KV缓存是性能瓶颈。现在主流做法是PagedAttention这种内存分页管理，避免显存碎片化。还有就是KV缓存压缩，保留关键token的缓存，其他的动态计算，既省显存又不影响效果。 经验分享之前在做一个文本生成服务的推理优化，前期只用了fp16和TensorRT，感觉还挺快的，结果上线后发现延迟波动特别大。后来加了动态batch和prefill缓存机制，才把尾延迟压下来。还有一点要提醒大家，千万别忽视tokenizer的耗时，有时候tokenize比模型本身还慢，一定要一起优化，不然速度提不上去。#深度学习#大模型#python#论文辅导#算法改进