GPT-4和LLaMA這樣的大型語言模型（LLMs）已在各個(gè)層次上成為了集成AI 的主流服務(wù)應(yīng)用。從常規(guī)聊天模型到文檔摘要，從自動(dòng)駕駛到各個(gè)軟件中的Copilot功能，這些模型的部署和服務(wù)需求正在迅速增加。

像DeepSpeed、PyTorch和其他幾個(gè)框架可以在LLM訓(xùn)練期間實(shí)現(xiàn)良好的硬件利用率，但它們?cè)谂c用戶互動(dòng)及處理開放式文本生成等任務(wù)時(shí)，受限于這些操作的計(jì)算密集度相對(duì)較低，現(xiàn)有系統(tǒng)往往在推理吞吐量上遇到瓶頸。

為了解決這一問題，使用類似vLLM這樣由PagedAttention驅(qū)動(dòng)的框架或是Orca系統(tǒng)可以顯著提高LLM推理的性能。

然而，這些系統(tǒng)在面對(duì)長提示的工作負(fù)載時(shí)，依舊難以提供良好的服務(wù)質(zhì)量。隨著越來越多的模型（例如MPT-StoryWriter）和系統(tǒng)（例如DeepSpeed Ulysses）支持延伸到數(shù)萬個(gè)token的上下文窗口，這些長提示工作負(fù)載變得越來越重要。

為了更好地理解問題，微軟DeepSpeed的研究人員最近發(fā)表了一篇博文，詳細(xì)介紹了LLM的文本生成，以及DeepSpeed-FastGen框架是如何在「提示處理」和「生成」的這兩個(gè)階段中運(yùn)行的。

DeepSpeed-FastGen

當(dāng)系統(tǒng)將「提示處理」和「生成」視為不同的階段時(shí)，生成階段將被提示處理所搶占，可能會(huì)破壞服務(wù)級(jí)別協(xié)議（SLAs）。

通過采用動(dòng)態(tài)SplitFuse技術(shù)，DeepSpeed-FastGen框架能夠提供比vLLM等先進(jìn)系統(tǒng)高出多達(dá)2.3倍的有效吞吐量。

DeepSpeed-FastGen是DeepSpeed-MII和DeepSpeed-Inference的結(jié)合，提供了一個(gè)易于使用的服務(wù)系統(tǒng)。

快速開始：要使用DeepSpeed-FastGen只需安裝最新的DeepSpeed-MII發(fā)行版：

pip install deepspeed-mii

要使用簡(jiǎn)單的非持久性管道部署并生成文本，請(qǐng)運(yùn)行以下代碼。

from mii import pipeline
pipe = pipeline("mistralai/Mistral-7B-v0.1")
output = pipe(["Hello, my name is", "DeepSpeed is"], max_new_tokens=128)
print(output)

現(xiàn)有LLM服務(wù)技術(shù)

單個(gè)序列的文本生成工作負(fù)載包含兩個(gè)階段：

1. 提示處理，此階段系統(tǒng)處理用戶輸入的文本，將其轉(zhuǎn)換成一系列token并構(gòu)建用于注意力機(jī)制的鍵值（KV）緩存；

2. 生成token，即向緩存中添加單個(gè)token并產(chǎn)生新的token。

在生成文本序列的過程中，系統(tǒng)將對(duì)模型進(jìn)行多次前向調(diào)用以生成完整的文本序列，現(xiàn)有文獻(xiàn)和系統(tǒng)中已經(jīng)提出了兩種主要技術(shù)，解決了這些階段中可能出現(xiàn)的各種限制和瓶頸。

分塊KV緩存

vLLM識(shí)別出大型單體KV緩存導(dǎo)致的內(nèi)存碎片化顯著降低了大型語言模型服務(wù)系統(tǒng)的并發(fā)性，并提出了「分頁注意力」（Paged Attention）機(jī)制來實(shí)現(xiàn)非連續(xù)KV緩存，并增加整個(gè)系統(tǒng)的總吞吐量。

此技術(shù)采用分頁緩存機(jī)制，從而提升了系統(tǒng)的整體吞吐量。不同于之前分配各個(gè)不同大小的連續(xù)內(nèi)存塊的做法，分塊KV緩存中的底層存儲(chǔ)是固定大小的塊（也稱為頁面）。

分塊KV緩存通過消除KV緩存引起的內(nèi)存碎片化，增加了潛在的序列并發(fā)量，從而增加了系統(tǒng)吞吐量。非連續(xù)KV緩存也被HuggingFace TGI和NVIDIA TensorRT-LLM等框架所實(shí)現(xiàn)。

連續(xù)批處理

過去，動(dòng)態(tài)批處理（服務(wù)器等待多個(gè)請(qǐng)求以同步處理）被用來提高GPU利用率。然而，這種方法有缺點(diǎn)，因?yàn)樗ǔＰ枰獙⑤斎胩畛涞较嗤L度或使系統(tǒng)等待以構(gòu)建更大的批次（batch）。

近期大型語言模型（LLM）推理和服務(wù)的優(yōu)化一直專注于細(xì)粒度調(diào)度和優(yōu)化內(nèi)存效率。例如，Orca提出了迭代級(jí)調(diào)度（也稱為連續(xù)批處理），它在模型的每次前向傳遞時(shí)作出獨(dú)特的調(diào)度決策。

這允許請(qǐng)求根據(jù)需要加入/離開批次，從而消除了填充請(qǐng)求的需要，提高了總體吞吐量。除了Orca，NVIDIA TRT-LLM、HuggingFace TGI和vLLM也實(shí)現(xiàn)了連續(xù)批處理。

在當(dāng)前系統(tǒng)中，有兩種主要方法來實(shí)現(xiàn)連續(xù)批處理。

- 在TGI和vLLM中，生成階段被搶占以執(zhí)行提示處理（在TGI中稱為填充）然后繼續(xù)生成。

- 在Orca中，這些階段不被區(qū)分；相反，只要總序列數(shù)沒有達(dá)到固定限制，Orca就會(huì)將提示加入正在運(yùn)行的批次中。這兩種方法都在不同程度上需要暫停生成以處理長提示。

為了解決這些缺點(diǎn)，我們提出了一種新穎的提示和生成組合策略，動(dòng)態(tài) SplitFuse。

動(dòng)態(tài)SplitFuse：一種新穎的提示和生成組合策略

類似于現(xiàn)有的框架如TRT-LLM、TGI和vLLM，DeepSpeed-FastGen的目標(biāo)是利用連續(xù)批處理和非連續(xù)KV緩存技術(shù)，以提升數(shù)據(jù)中心服務(wù)大型語言模型（LLM）的硬件利用率和響應(yīng)速度。

為了實(shí)現(xiàn)更高的性能，DeepSpeed-FastGen提出了SplitFuse技術(shù)，它利用動(dòng)態(tài)提示和生成分解，統(tǒng)一來進(jìn)一步改善連續(xù)批處理和系統(tǒng)吞吐量。

A. 三個(gè)性能見解

在描述動(dòng)態(tài)SplitFuse之前，我們回答三個(gè)關(guān)鍵的性能問題，這些問題解釋了SplitFuse背后的邏輯。

1. 哪些因素影響單個(gè)LLM的前向傳遞？

為了有效地調(diào)度，我們必須首先了解調(diào)度過程中應(yīng)考慮的獨(dú)立變量有哪些。

我們觀察到，在前向傳遞中序列的組成（序列中的批次大小）對(duì)性能的影響可以忽略不計(jì)。

這意味著我們可以圍繞單一變量——即前向傳遞中的token數(shù)量——構(gòu)建一個(gè)高效的調(diào)度器。

2. 模型的吞吐量與前向傳遞中token數(shù)量的關(guān)系如何？

一個(gè)LLM有兩個(gè)關(guān)鍵的運(yùn)行區(qū)間，并且過渡相對(duì)陡峭。

當(dāng)token數(shù)量較少時(shí)，GPU的瓶頸是從內(nèi)存中讀取模型，因此吞吐量會(huì)隨著token數(shù)量的增加而上升，而當(dāng)token數(shù)量很多時(shí)，模型的吞吐量受GPU計(jì)算能力限制，吞吐量近乎恒定。

因此如果我們能將所有前向傳遞都保持在吞吐量飽和區(qū)間，則模型運(yùn)行效率最高。

3. 如何在多個(gè)前向傳遞中調(diào)度一組token？

我們?cè)谏蠄D中觀察到，對(duì)于對(duì)齊良好的輸入，token吞吐量曲線是凹的，這意味著第二導(dǎo)數(shù)必定小于或等于0。

設(shè)f(x)為給定模型的延遲至吞吐量的凹函數(shù)。則對(duì)于凹函數(shù)f(x)，以下關(guān)系成立：

這表明，對(duì)于給定的2x個(gè)總token來說，最大化吞吐量的方式是將它們均勻分割到兩個(gè)批次之間。

更一般地說，在一個(gè)系統(tǒng)中，如果要在F個(gè)前向傳遞中處理P個(gè)token，最理想的分區(qū)方案是均勻分配它們。

B. 動(dòng)態(tài)分割融合（Dynamic SplitFuse）

動(dòng)態(tài)分割融合是一種用于提示處理和token生成的新型token組成策略。

DeepSpeed-FastGen利用動(dòng)態(tài)分割融合策略，通過從提示中取出部分token并與生成過程相結(jié)合，使得模型可以保持一致的前向傳遞大?。╢orward size）。

具體來說，動(dòng)態(tài)分割融合執(zhí)行兩個(gè)關(guān)鍵行為：

將長提示分解成更小的塊，并在多個(gè)前向傳遞（迭代）中進(jìn)行調(diào)度，只有在最后一個(gè)傳遞中才執(zhí)行生成。短提示將被組合以精確填滿目標(biāo)token預(yù)算。

即使是短提示也可能被分解，以確保預(yù)算被精確滿足，前向大?。╢orward sizes）保持良好對(duì)齊。

動(dòng)態(tài)分割融合（Dynamic SplitFuse）提升了以下性能指標(biāo)：

- 更好的響應(yīng)性：

由于長提示不再需要極長的前向傳遞來處理，模型將提供更低的客戶端延遲。在同一時(shí)間窗口內(nèi)執(zhí)行的前向傳遞更多。

- 更高的效率：

短提示的融合到更大的token預(yù)算使模型能夠持續(xù)運(yùn)行在高吞吐量狀態(tài)。

- 更低的波動(dòng)和更好的一致性：

由于前向傳遞的大小一致，且前向傳遞大小是性能的主要決定因素，每個(gè)前向傳遞的延遲比其他系統(tǒng)更加一致。

生成頻率也是如此，因?yàn)镈eepSpeed-FastGen不需要像其他先前的系統(tǒng)那樣搶占或長時(shí)間運(yùn)行提示，因此延遲會(huì)更低。

因此，與現(xiàn)有最先進(jìn)的服務(wù)系統(tǒng)相比，DeepSpeed-FastGen將以允許快速、持續(xù)生成的速率消耗來自提示的token，同時(shí)向系統(tǒng)添加token，提高系統(tǒng)利用率，提供更低的延遲和更高的吞吐量流式生成給所有客戶端。

圖 1：連續(xù)批處理策略的示意圖。每個(gè)塊顯示一個(gè)前向傳遞的執(zhí)行。箭頭表示前向傳遞有一或多個(gè)token生成。vLLM在一個(gè)前向傳遞中要么生成token要么處理提示；token生成搶占提示處理。Orca在生成過程中以完整長度處理提示。DeepSpeed-FastGen動(dòng)態(tài)分割融合則執(zhí)行固定大小批次的動(dòng)態(tài)組合，包括生成和提示token

性能評(píng)估

DeepSpeed-FastGen利用分塊KV緩存和動(dòng)態(tài)分割融合連續(xù)批處理，提供了最先進(jìn)的LLM服務(wù)性能。

我們以下述的基準(zhǔn)測(cè)試方法對(duì)DeepSpeed-FastGen和vLLM在一系列模型和硬件配置上進(jìn)行評(píng)估。

A. 基準(zhǔn)測(cè)試方法論

我們采用兩種主要的定量方法來衡量性能。

吞吐量-延遲曲線：生產(chǎn)環(huán)境的兩個(gè)關(guān)鍵指標(biāo)是吞吐量（以每秒請(qǐng)求計(jì)）和延遲（每個(gè)請(qǐng)求的響應(yīng)性）。

為了衡量這一點(diǎn)，我們模擬了多個(gè)客戶端（數(shù)量從1到32不等）同時(shí)向服務(wù)器發(fā)送請(qǐng)求（總計(jì)512個(gè)）的情況。每個(gè)請(qǐng)求的結(jié)果延遲在端點(diǎn)測(cè)量，吞吐量通過完成實(shí)驗(yàn)的端到端時(shí)間來測(cè)量。

有效吞吐量：諸如聊天應(yīng)用程序之類的交互式應(yīng)用程序可能有比上述指標(biāo)（如端到端延遲）更嚴(yán)格和復(fù)雜的要求。

以越來越受歡迎的聊天應(yīng)用為例：

用戶通過發(fā)送提示（輸入）來開始對(duì)話。系統(tǒng)處理提示并返回第一個(gè)token。隨著生成的進(jìn)行，后續(xù)token被流式傳輸給用戶。

在這個(gè)過程的每個(gè)階段，系統(tǒng)都有可能提供不利的用戶體驗(yàn)；例如，第一個(gè)token到達(dá)得太慢；或生成似乎停止了一段時(shí)間。

我們提出了一個(gè)考慮這兩個(gè)維度的SLA框架。

由于提示和生成文本的長度差異很大，影響計(jì)算成本，因此設(shè)定同一個(gè)SLA值對(duì)于吞吐量和延遲是不切實(shí)際的。

因此，我們將提示延遲的SLA定義為「|提示中的token|/512」秒（=512 token/秒）。

此外，考慮到人類的閱讀速度，我們將生成延遲的SLA設(shè)置在指數(shù)移動(dòng)平均（EMA）上為2、4或6 token/秒。能夠達(dá)到這些SLA的請(qǐng)求被認(rèn)為是成功的，這些成功請(qǐng)求的吞吐量被稱為有效吞吐量。

我們通過在NVIDIA A100、H100和A6000上運(yùn)行Llama-2 7B、Llama-2 13B和Llama-2 70B對(duì)vLLM和DeepSpeed-FastGen進(jìn)行了評(píng)估。

B. 吞吐量-延遲分析

在這個(gè)實(shí)驗(yàn)中，DeepSpeed-FastGen在吞吐量和延遲方面都優(yōu)于vLLM，在相同的延遲下DeepSpeed-FastGen的吞吐量更大；在相同的吞吐量下DeepSpeed-FastGen的響應(yīng)延遲更小。

如圖2所示，在Llama-2 70B運(yùn)行于4個(gè)A100-80GB的情況下，DeepSpeed-FastGen展示了高達(dá)2倍的吞吐量（1.36 rps對(duì)比0.67 rps）在相同的延遲（9 秒）下；或高達(dá)50%的延遲減少（7秒對(duì)比14秒）同時(shí)實(shí)現(xiàn)相同的吞吐量（1.2 rps）。

圖 2：使用Llama 2 70B進(jìn)行文本生成的吞吐量和延遲（使用4個(gè)A100-80GB GPU的張量并行）。提示和生成長度遵循正態(tài)分布，平均值分別為1200/2600和128/60，方差為30%

評(píng)估Llama-2 13B時(shí)DeepSpeed-FastGen也呈現(xiàn)了這些趨勢(shì)，如圖3所示。

圖 3：使用Llama 2 13B進(jìn)行文本生成的吞吐量和延遲（A100-80GB GPU，無張量并行）。提示和生成長度遵循正態(tài)分布，平均值分別為1200/2600和60/128，并且有30%的方差

C. 有效吞吐量分析

在考慮了首個(gè)token的延遲和生成速率的有效吞吐量分析下，DeepSpeed-FastGen提供的吞吐量比vLLM高出多達(dá)2.3倍。

圖4展示了DeepSpeed-FastGen和vLLM的有效吞吐量的比較分析。每個(gè)繪制的點(diǎn)表示從特定數(shù)量的客戶端得出的有效吞吐量。

圖 4：DeepSpeed-FastGen和vLLM的有效吞吐量（Llama 2 70B/A100-80GB使用張量并行在4個(gè)A100-80GB GPU上。提示和生成長度遵循正態(tài)分布，平均值分別為2600和60，并且有30%的方差)

當(dāng)我們擴(kuò)大客戶端數(shù)量時(shí)，我們最初觀察到有效吞吐量的增加。然而，當(dāng)客戶端數(shù)量接近系統(tǒng)容量時(shí)，延遲也顯著增加，導(dǎo)致許多請(qǐng)求未能滿足SLA。

因此，有效吞吐量將在某個(gè)點(diǎn)上飽和或減少。從可用性角度來看，達(dá)到最大有效吞吐量所需的客戶端數(shù)量并不特別重要；線條的最高點(diǎn)是最優(yōu)的服務(wù)點(diǎn)。

當(dāng)vLLM搶占正在進(jìn)行的先前請(qǐng)求的生成時(shí)，生成延遲會(huì)明顯增加。這導(dǎo)致vLLM的有效吞吐量看起來低于其直接測(cè)量的吞吐量。

在vLLM的峰值時(shí)，有效吞吐量為0.63查詢/秒，大約28%的請(qǐng)求未能滿足4 token/秒的SLA。在相同的SLA下，DeepSpeed-FastGen達(dá)到了1.42查詢/秒（不到1%的請(qǐng)求未能滿足SLA），這是vLLM的2.3倍。

D. token級(jí)時(shí)間分析

圖5顯示了生成過程的P50、P90和P95延遲。vLLM和DeepSpeed-FastGen展示了類似的P50延遲，但vLLM的P90和P95延遲顯著更高。

這種差異是由于vLLM在搶占正在進(jìn)行的生成以處理新提示時(shí)，生成延遲出現(xiàn)顯著增加所導(dǎo)致的。

相比之下，DeepSpeed-FastGen通常會(huì)同時(shí)處理之前請(qǐng)求的提示和生成，導(dǎo)致生成延遲更加一致。

圖 5：使用張量并行在4個(gè)A100-80GB GPU上的Llama 2 70B/A100-80GB的每token生成延遲，16客戶端。提示和生成長度遵循正態(tài)分布，平均值分別為2600和128，并且有30%的方差。

E. 使用負(fù)載均衡的可擴(kuò)展性

DeepSpeed-FastGen提供了副本級(jí)負(fù)載均衡，可以將請(qǐng)求均勻分布在多個(gè)服務(wù)器上，讓您輕松擴(kuò)展應(yīng)用程序。

圖6展示了DeepSpeed-FastGen在使用負(fù)載均衡器和最多16個(gè)副本時(shí)的可擴(kuò)展性。請(qǐng)注意，我們使用了4個(gè)A100 GPU來計(jì)算每個(gè)Llama 2 70B模型。

圖 6：使用負(fù)載均衡功能的可擴(kuò)展性。提示和生成長度遵循正態(tài)分布，平均值分別為2600和60，并且有30%的方差

結(jié)果展示了DeepSpeed-FastGen幾乎完美的可擴(kuò)展性。

單個(gè)副本時(shí)DeepSpeed-FastGen的吞吐量為1.46查詢/秒，而16個(gè)副本的吞吐量達(dá)到了23.7查詢/秒，與單個(gè)副本相比標(biāo)志著線性的16倍增長。

F. 其他硬件平臺(tái)

除了對(duì)A100的深入分析，我們還提供了H100和A6000的基準(zhǔn)測(cè)試結(jié)果。在A6000和H100上觀察到的性能趨勢(shì)與A100相同。

圖 7：使用8個(gè)H100 GPU的Llama 2 70B的吞吐量-延遲曲線和有效吞吐量。提示和生成長度遵循正態(tài)分布，平均值分別為2600和60，并且有30%的方差

圖 8：使用A6000的Llama 2 7B的吞吐量-延遲曲線和有效吞吐量。提示和生成長度遵循正態(tài)分布，平均值分別為2600和60，并且有30%的方差

軟件實(shí)現(xiàn)與使用指南

DeepSpeed-FastGen是DeepSpeed-MII和DeepSpeed-Inference的協(xié)同組合，如下圖所示。

兩個(gè)軟件包共同提供了系統(tǒng)的各個(gè)組成部分，包括前端API、用于使用動(dòng)態(tài)SplitFuse調(diào)度批次的主機(jī)和設(shè)備基礎(chǔ)設(shè)施、優(yōu)化的內(nèi)核實(shí)現(xiàn)，以及構(gòu)建新模型實(shí)現(xiàn)的工具。

alpha版DeepSpeed-FastGen最快的入門方式是：pip install deepspeed-mii

A. 支持的模型

在DeepSpeed-FastGen的當(dāng)前alpha版本中，我們目前支持以下模型架構(gòu)：LLaMA和LLaMA-2MistralOPT

所有當(dāng)前模型都利用了后端的HuggingFace API來提供模型權(quán)重和模型對(duì)應(yīng)的分詞器。

我們計(jì)劃在最初發(fā)布后的幾周和幾個(gè)月內(nèi)添加更多模型。如果您希望支持特定的模型架構(gòu)，請(qǐng)?zhí)峤粏栴}來讓我們知道。

B. 部署選項(xiàng)

以下所有示例均可在DeepSpeedExamples中運(yùn)行。安裝后，您有兩種部署方式：交互式非持久管道或持久化服務(wù)部署：

非持久管道

非持久管道部署是快速入門的好方法，只需幾行代碼即可完成。非持久模型只在您運(yùn)行的python腳本期間存在，適用于臨時(shí)交互式會(huì)話。

from mii import pipeline
pipe = pipeline("mistralai/Mistral-7B-v0.1")
output = pipe(["Hello, my name is", "DeepSpeed is"], max_new_tokens=128)
print(output)

持久部署

持久部署非常適合用于長時(shí)間運(yùn)行和生產(chǎn)的應(yīng)用。持久部署使用了輕量級(jí)的GRPC服務(wù)器，可以使用以下兩行代碼創(chuàng)建：

import mii
mii.serve("mistralai/Mistral-7B-v0.1")

上述服務(wù)器可以同時(shí)被多個(gè)客戶端查詢，這要?dú)w功于DeepSpeed-MII內(nèi)置的負(fù)載平衡器。創(chuàng)建客戶端也只需要兩行代碼：

client = mii.client("mistralai/Mistral-7B-v0.1")
output = client.generate("Deepspeed is", max_new_tokens=128)
print(output)

持久部署可以在不再需要時(shí)終止：

client.terminate_server()

C. 高級(jí)安裝方式

為了使用方便并顯著減少許多其他框架所需的冗長編譯時(shí)間，我們通過名為DeepSpeed-Kernels的新庫分發(fā)了覆蓋我們大部分自定義內(nèi)核的預(yù)編譯 Python wheel。

我們發(fā)現(xiàn)這個(gè)庫在環(huán)境中非常便攜，只要這些環(huán)境具有NVIDIA GPU計(jì)算能力 8.0+（Ampere+）、CUDA 11.6+和Ubuntu 20+。

在大多數(shù)情況下，您甚至不需要知道這個(gè)庫的存在，因?yàn)樗荄eepSpeed-MII的依賴項(xiàng)，并將自動(dòng)與之一起安裝。然而，如果您因任何原因需要手動(dòng)編譯我們的內(nèi)核，請(qǐng)參閱我們的高級(jí)安裝文檔。

轉(zhuǎn)載自微軟DeepSpeed組官方知乎賬號(hào)：zhihu.com/people/deepspeed