大模型推理框架升级之路

大模型推理框架升级之路我们将从四个优化专项介绍如何优化大模型推理框架性能量化投机采样TTFT与TPOT的优化通信优化01量化量化作为大模型最重要的性能优化手段，能有效降低显存占用，降低访存量，充分利用计算资源以下是大模型计算流程：Weight-int8+KV_cache_int8最早上线的一个版本，显著降低显存占用，使得模型使用较少卡启动，增大服务承载能力，降低成本50%weight

跟

kv

cache在推理框架占用显存为大头，优先优化能有效降低成本Activation

int8A8是在w8/kv8基础上对gemm相关计算的输入激活进行量化，能有效降低gemm运算耗时，首token耗时下降50%，成本下降15%Weight-int4+kv_cache-int4Int4

主要目标是将显存占用压至更低，能在低端卡型上部署并支持更长的序列，支持更大的batch，成本下降30%使用了类似quorat的技术，并结合marlin算子，针对性做了优化，已在多个业务落地，后续可能会有论文输出Communicationint8通信量化，降低低端卡通信耗时开销，首token耗时下降30%后续会有论文产出AttentionQKV

int8将gemm计算全线转为int8计算Q(int8)*K(int8)->softmax->V(int8)目前处于开发中02投机采样投机采样就是利用decode过程算力冗余使用额外的技术生成多个候选token同时输送给大模型并行验证，充分使用算力且不会增加额外太多的时延1(大模型输出的最后一个token)

+

4(候选token)

->

一次验证通过4个token需要考虑云端大batch下候选token数量限制Clover模型结构设计路线使用transformer

block

前几层信息预测效果不好尝试获取全局的信息而不是仅仅当前预测token的信息通过h<t+1>=concat(token_emb,

h<t>)效果提升有限尝试attention结构qk之争，h表示全局信息，不断吸收token_emb效果不错/abs/2405.00263尝试使用前置候选token信息辅助后续token预测单独建一层可学习的transformer

block收集全局信息提升不错Sample

策略我们的目标是大batch场景下投机有效，要求的候选token仅仅为4，此时sample策略就影响很大了开源的都是固定组合的形式，如

head_0_top1+head_1_top1+head_2_top1，head_0_top2+head_1_top1+head_2_top1动态构建候选token树，较为激进的贪心搜索策略核心策略：单token级别(保证树深度)1.prob先进行top

p丢弃按照top1/4

长尾小概率丢弃token

tree级别(子节点排序依据)1.从根节点的联合概率排序每层token预算数量(保证树最大宽度，防止计算量激增)1.去除所有父节点token数Clover收益命中率上提升50%+，

端到端推理速度提升30%+Clover2模型结构升级/abs/2408.00264loss

优化仅仅根据CrossEntropyLoss预测token偏序关系，训练多轮，过拟合会出现对一些高频token增强概率的情况增加数据蒸馏loss使得clover能更加关注与主模型的一致性上，而不是走捷径主模型预测token信息前置，提前加入transformer

block，帮助更远的预测Clover2模型结构升级3.

Regressive

attention

block

output

projector结构提升后几个head预测能力4.

增加AugmentingBlock层数，增强全局信息提取能力Augmenting

Block

位于第一个head之前只会跑一次，增加层数不会导致跑多次的问题，eagle增加层就会导致每个head都多跑，耗时会暴增这为clover提供更多可能，可以设计更加复杂的Augmenting

Block，我们尝试最简单的加层获取收益Clover2收益clover为rnn为主的架构，但仍然能打败eagle这种以decode

layer为主的模型结构在各个数据集上都超过eagle命中率最大提升7.7%，

端到端推理速度最大提升9.3%03TTFTTPOT优化首token耗时

与

decode每个token间耗时

的平衡驱动来源于用户体验上优化，当一个新的用户请求进入时会导致现有做decode的请求被卡住Chunk

prefillchunk

prefill是将单次prefill计算拆分为多段计算的技术，能有效降低decode间隔时间Chunk

prefillSplit

fused技术将chunk

prefill与decode计算整合有效提升计算利用率Chunk

prefill算子差异明显tensorcore

attention需要读取kv

cache第一个版本访存->反量化->计算

pipeline并不能很好掩盖并且qk会切块计算，每块都需要反量化，反量化次数剧增为解决这个问题，我们还是采用了外部反量化后再计算的策略最终收益decode

token间隔p99下降在各个业务都非常明显PD分离解决TTFT与TPOT的平衡，PD分离是终极方案PD分离较短的输入仍然采用split-fused的混合推理方案，长请求会单独扔给prefill节点完成，长请求来的时间不一定此时需要PD动态调度策略目前还在开发测试中Cache

策略Sessioncache缓存多轮请求kv

cache结果多级动态lru排除老数据对于第二轮的请求首token延迟提升巨大同时也支持sys_prompt

cache功能很早的一个版本就支持了该功能后来出了全局前缀树cache，当时评估收益不大最近的gpt

o1提出后，MCTS相关算法需求强烈最近会上线一个版本04通信优化在4090卡上，通信能力很弱，通信耗时占比很高，导致gpu大部分时间算力浪费计算通信overlap常见方法：gemm

overlap:许多场景通信耗时会长于gemm计算，导致不能很好overlapreqoverlap:需要组批两个请求，还需要两个请求间尽量计算量均衡我们的设计：ISOsequence内的overlap方法/abs/2409.11155计算通信overlap计算通信占比越均衡收益越大，最终收益上限取最小的占比在a800和4090上计算通信占比都比较极端我们针对性的做了优化4090

通信占大头，通信>attention

&&

通信>mlp8bit通信，对通信进行量化A800

计算占大头,

通信<attention&&通信<mlpgemm与comm多stream会导致gemm耗时增加20%采用gemm切块的策略，减少gemm与comm之间的重叠计算通信overlap除了以上两个极端的情况，可能会出现 mlp<通信<attention

的情况，为此我们设计了可能的优化手段attention计算量的不平衡，