大模型推理框架升級之路

大模型推理框架升級之路我們將從四個優(yōu)化專項介紹如何優(yōu)化大模型推理框架性能量化投機采樣TTFT與TPOT的優(yōu)化通信優(yōu)化01量化量化作為大模型最重要的性能優(yōu)化手段，能有效降低顯存占用，降低訪存量，充分利用計算資源以下是大模型計算流程：Weight-int8+KV_cache_int8最早上線的一個版本，顯著降低顯存占用，使得模型使用較少卡啟動，增大服務(wù)承載能力，降低成本50%weight

跟

kv

cache在推理框架占用顯存為大頭，優(yōu)先優(yōu)化能有效降低成本Activation

int8A8是在w8/kv8基礎(chǔ)上對gemm相關(guān)計算的輸入激活進行量化，能有效降低gemm運算耗時，首token耗時下降50%，成本下降15%Weight-int4+kv_cache-int4Int4

主要目標是將顯存占用壓至更低，能在低端卡型上部署并支持更長的序列，支持更大的batch，成本下降30%使用了類似quorat的技術(shù)，并結(jié)合marlin算子，針對性做了優(yōu)化，已在多個業(yè)務(wù)落地，后續(xù)可能會有論文輸出Communicationint8通信量化，降低低端卡通信耗時開銷，首token耗時下降30%后續(xù)會有論文產(chǎn)出AttentionQKV

int8將gemm計算全線轉(zhuǎn)為int8計算Q(int8)*K(int8)->softmax->V(int8)目前處于開發(fā)中02投機采樣投機采樣就是利用decode過程算力冗余使用額外的技術(shù)生成多個候選token同時輸送給大模型并行驗證，充分使用算力且不會增加額外太多的時延1(大模型輸出的最后一個token)

+

4(候選token)

->

一次驗證通過4個token需要考慮云端大batch下候選token數(shù)量限制Clover模型結(jié)構(gòu)設(shè)計路線使用transformer

block

前幾層信息預(yù)測效果不好嘗試獲取全局的信息而不是僅僅當前預(yù)測token的信息通過h<t+1>=concat(token_emb,

h<t>)效果提升有限嘗試attention結(jié)構(gòu)qk之爭，h表示全局信息，不斷吸收token_emb效果不錯/abs/2405.00263嘗試使用前置候選token信息輔助后續(xù)token預(yù)測單獨建一層可學習的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動態(tài)構(gòu)建候選token樹，較為激進的貪心搜索策略核心策略：單token級別(保證樹深度)1.prob先進行top

p丟棄按照top1/4

長尾小概率丟棄token

tree級別(子節(jié)點排序依據(jù))1.從根節(jié)點的聯(lián)合概率排序每層token預(yù)算數(shù)量(保證樹最大寬度，防止計算量激增)1.去除所有父節(jié)點token數(shù)Clover收益命中率上提升50%+，

端到端推理速度提升30%+Clover2模型結(jié)構(gòu)升級/abs/2408.00264loss

優(yōu)化僅僅根據(jù)CrossEntropyLoss預(yù)測token偏序關(guān)系，訓練多輪，過擬合會出現(xiàn)對一些高頻token增強概率的情況增加數(shù)據(jù)蒸餾loss使得clover能更加關(guān)注與主模型的一致性上，而不是走捷徑主模型預(yù)測token信息前置，提前加入transformer

block，幫助更遠的預(yù)測Clover2模型結(jié)構(gòu)升級3.

Regressive

attention

block

output

projector結(jié)構(gòu)提升后幾個head預(yù)測能力4.

增加AugmentingBlock層數(shù)，增強全局信息提取能力Augmenting

Block

位于第一個head之前只會跑一次，增加層數(shù)不會導致跑多次的問題，eagle增加層就會導致每個head都多跑，耗時會暴增這為clover提供更多可能，可以設(shè)計更加復雜的Augmenting

Block，我們嘗試最簡單的加層獲取收益Clover2收益clover為rnn為主的架構(gòu)，但仍然能打敗eagle這種以decode

layer為主的模型結(jié)構(gòu)在各個數(shù)據(jù)集上都超過eagle命中率最大提升7.7%，

端到端推理速度最大提升9.3%03TTFTTPOT優(yōu)化首token耗時

與

decode每個token間耗時

的平衡驅(qū)動來源于用戶體驗上優(yōu)化，當一個新的用戶請求進入時會導致現(xiàn)有做decode的請求被卡住Chunk

prefillchunk

prefill是將單次prefill計算拆分為多段計算的技術(shù)，能有效降低decode間隔時間Chunk

prefillSplit

fused技術(shù)將chunk

prefill與decode計算整合有效提升計算利用率Chunk

prefill算子差異明顯tensorcore

attention需要讀取kv

cache第一個版本訪存->反量化->計算

pipeline并不能很好掩蓋并且qk會切塊計算，每塊都需要反量化，反量化次數(shù)劇增為解決這個問題，我們還是采用了外部反量化后再計算的策略最終收益decode

token間隔p99下降在各個業(yè)務(wù)都非常明顯PD分離解決TTFT與TPOT的平衡，PD分離是終極方案PD分離較短的輸入仍然采用split-fused的混合推理方案，長請求會單獨扔給prefill節(jié)點完成，長請求來的時間不一定此時需要PD動態(tài)調(diào)度策略目前還在開發(fā)測試中Cache

策略Sessioncache緩存多輪請求kv

cache結(jié)果多級動態(tài)lru排除老數(shù)據(jù)對于第二輪的請求首token延遲提升巨大同時也支持sys_prompt

cache功能很早的一個版本就支持了該功能后來出了全局前綴樹cache，當時評估收益不大最近的gpt

o1提出后，MCTS相關(guān)算法需求強烈最近會上線一個版本04通信優(yōu)化在4090卡上，通信能力很弱，通信耗時占比很高，導致gpu大部分時間算力浪費計算通信overlap常見方法：gemm

overlap:許多場景通信耗時會長于gemm計算，導致不能很好overlapreqoverlap:需要組批兩個請求，還需要兩個請求間盡量計算量均衡我們的設(shè)計：ISOsequence內(nèi)的overlap方法/abs/2409.11155計算通信overlap計算通信占比越均衡收益越大，最終收益上限取最小的占比在a800和4090上計算通信占比都比較極端我們針對性的做了優(yōu)化4090

通信占大頭，通信>attention

&&

通信>mlp8bit通信，對通信進行量化A800

計算占大頭,

通信<attention&&通信<mlpgemm與comm多stream會導致gemm耗時增加20%采用gemm切塊的策略，減少gemm與comm之間的重疊計算通信overlap除了以上兩個極端的情況，可能會出現(xiàn) mlp<通信<attention

的情況，為此我們設(shè)計了可能的優(yōu)化手段attention計算量的不平衡，