想象一下，就像咱們家里的水管，正常來講水應(yīng)該嘩嘩地流，可要是這管子太窄了，水就只能滴滴答答，讓人干著急！

當(dāng)下咱們面臨的大模型服務(wù)吞吐率太小，不就類似于這窄窄的水管嗎？當(dāng)面試官問你有沒有辦法把大模型服務(wù)吞吐這個(gè)“管子”拓寬，讓數(shù)據(jù)像奔騰的江河一樣順暢流淌，你準(zhǔn)備怎么解決？

1.面試官心理分析

當(dāng)面試官問你這個(gè)問題的時(shí)候，其實(shí)面試官主要是想考驗(yàn)?zāi)闳缦?3 個(gè)方面：

• 第一，在實(shí)際業(yè)務(wù)中，你有沒有做過大模型服務(wù)性能的調(diào)優(yōu)？
• 第二，你是否了解大模型服務(wù)吞吐率跟哪些因素有關(guān)？
• 第三，展開你實(shí)戰(zhàn)用過的優(yōu)化技術(shù)，說明是怎么解決這個(gè)問題的？

2.面試題剖析

首先我們看一下吞吐率是怎么計(jì)算的：吞吐率 = 處理的請(qǐng)求N / 延時(shí)

也就是：在一定時(shí)間內(nèi)，服務(wù)處理的請(qǐng)求數(shù)除以消耗的時(shí)間。那我們看一下分母，模型處理的延時(shí)跟什么有關(guān)，是不是模型的 forward 的時(shí)間。我們當(dāng)然希望模型 forward 實(shí)際計(jì)算的時(shí)間盡可能的小。

再看一下分子，怎么能讓分子變大？

處理的請(qǐng)求 N 跟 2 個(gè)因素有關(guān)：一是模型一次能處理的條數(shù)，也就是 batch size。二是服務(wù)的實(shí)例數(shù)量，也就是部署了多少個(gè)節(jié)點(diǎn)。一個(gè)節(jié)點(diǎn)能處理 N，那 k 個(gè)節(jié)點(diǎn)理論上能看*N。這兩個(gè)因素都直接增大了分子。

分析到這里，我們首先回答出面試官心里預(yù)期之一：大模型服務(wù)的吞吐率跟 2 個(gè)因素有關(guān)，一是模型單次推理的延遲，二是模型一次能處理的請(qǐng)求數(shù)量。

因此讓吞吐率提高的方法是盡量降低模型的推理延遲，同時(shí)增大模型的并行處理請(qǐng)求的能力。

到這里只是回答到了第一層，最基本的概念。

繼續(xù)分析，大模型的單次推理延遲，有幾個(gè)方向：

首先是可以減少計(jì)算量，可以采用權(quán)重+激活量化來解決。

如果 profile 到服務(wù)的計(jì)算資源還有空余，比如 GPU 的利用率只有 60%，也可以用投機(jī)采樣方法來做，即用一個(gè)小模型來猜測(cè)+大模型驗(yàn)證的方式。

另一個(gè)方向是提高訪存的利用率，這要結(jié)合所使用模型計(jì)算量來分析，如果模型不是計(jì)算密集型的，即計(jì)算速度比訪問內(nèi)存速度快得多，這時(shí)候主要就是受到內(nèi)存(HBM)訪問的瓶頸。

在 self-attention 中，大部分都是屬于這種情況。因此減少訪問內(nèi)存次數(shù)，可以極大提升單次推理速度，flash attention 就是這個(gè)思想。

大模型的并行處理能力，有兩個(gè)優(yōu)化方向：

一是在顯存運(yùn)行的情況下，增大模型一次處理的 batchsize。

這里就有多種方法，靜態(tài)的 batching，動(dòng)態(tài) batching，以及連續(xù)的 batching 等等，差別就是合并 batch 的方式不同而已。

二是在業(yè)務(wù)條件允許下，水平擴(kuò)展，增加節(jié)點(diǎn)數(shù)。這里就要考慮都 scaling 的問題，即增加節(jié)點(diǎn)數(shù)后，要盡可能最大化利用每個(gè)節(jié)點(diǎn)的計(jì)算能力，這就需要考慮到負(fù)載均衡的問題。比如用 K8S+GPU 利用率監(jiān)測(cè)+QLB 負(fù)載均衡來調(diào)優(yōu)。

回答到這里，就算回答到了第二層，即從概念到具體解決方法。

最后進(jìn)階一下，用業(yè)務(wù)中實(shí)際用過且行之有效的技術(shù)來讓面試官信服。這里要注意一點(diǎn)，就是一定要注意重點(diǎn)，選最重要，適合落地的方法來講，這也是考驗(yàn)?zāi)慵夹g(shù)選型的能力，切忌主次不分。

回到問題，如果是優(yōu)化吞吐率，影響最大的因素肯定是模型處理的并行度，單次推理延時(shí)影響的是單個(gè)用戶的體驗(yàn)，而并行度是高并發(fā)情況下的多個(gè)用戶的體驗(yàn)。

另外，從實(shí)際工程經(jīng)驗(yàn)來看，如果增大 batch size，會(huì)以 10～30% 的單次時(shí)延增加，換來數(shù)倍甚至數(shù)十倍的吞吐率加速。

最后一層回答就以現(xiàn)目前最流行，加速最明顯的 continuous batching 技術(shù)，來詳細(xì)講解是如何和實(shí)際業(yè)務(wù)模型結(jié)合的，至于它的前身，static batching，dynamic batching 就可以一筆帶過了。

為什么有這個(gè)方法，原因是大模型服務(wù)不能假定固定長(zhǎng)度的輸入序列，也不能假定固定長(zhǎng)度的輸出序列。

因此對(duì)于 static batching 或者 dynamic batching 來說，生成輸出的變化可能會(huì)導(dǎo)致 GPU 嚴(yán)重未充分利用。

因此在 OSDI 2022 上發(fā)表的 Orca 是第一篇解決這個(gè)問題的論文。它采用了迭代級(jí)調(diào)度，一旦批中的一個(gè)序列完成生成，就可以在其位置插入一個(gè)新的序列，從而實(shí)現(xiàn)比靜態(tài)批處理更高的 GPU 利用率。

如上圖所示，使用連續(xù)批處理完成七條序列。左圖顯示了單個(gè)迭代后的批，右圖顯示了多次迭代后的批。

一旦一個(gè)序列產(chǎn)生結(jié)束序列標(biāo)記，我們?cè)谄湮恢貌迦胄碌男蛄校葱蛄?S5、S6 和 S7）。這實(shí)現(xiàn)了更高的 GPU 利用率，因?yàn)?GPU 不需要等待所有序列完成才開始新的一個(gè)。

實(shí)際在代碼實(shí)現(xiàn)時(shí)，還需要根據(jù)服務(wù)是流式輸出還是一次性輸出做進(jìn)一步優(yōu)化。

如果是流式輸出，則需要利用異步協(xié)程的 async 和 await 來實(shí)現(xiàn)計(jì)算資源的切換，實(shí)現(xiàn)在 token 粒度級(jí)多用戶輸出。

更進(jìn)一步，在這個(gè)過程中，tokenize 和 detokenize 也可以用異步協(xié)程來實(shí)現(xiàn)，進(jìn)一步提高編解碼速度。

在回答過程中，你可以畫圖或者結(jié)合用例給面試官講解出來，體現(xiàn)你對(duì)這個(gè)算法的熟練掌握程度。

到此為止，才可以算得上是一個(gè)優(yōu)秀的面試回答了。

本文轉(zhuǎn)載自 ??丁師兄大模型??，作者： 丁師兄