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

像DeepSpeed、PyTorch和其他幾個框架可以在LLM訓練期間實現良好的硬件利用率，但它們在與用戶互動及處理開放式文本生成等任務時，受限于這些操作的計算密集度相對較低，現有系統往往在推理吞吐量上遇到瓶頸。

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

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

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

DeepSpeed-FastGen

當系統將「提示處理」和「生成」視為不同的階段時，生成階段將被提示處理所搶占，可能會破壞服務級別協議（SLAs）。

通過采用動態SplitFuse技術，DeepSpeed-FastGen框架能夠提供比vLLM等先進系統高出多達2.3倍的有效吞吐量。

DeepSpeed-FastGen是DeepSpeed-MII和DeepSpeed-Inference的結合，提供了一個易于使用的服務系統。

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

pip install deepspeed-mii

要使用簡單的非持久性管道部署并生成文本，請運行以下代碼。

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)

現有LLM服務技術

單個序列的文本生成工作負載包含兩個階段：

1. 提示處理，此階段系統處理用戶輸入的文本，將其轉換成一系列token并構建用于注意力機制的鍵值（KV）緩存；

2. 生成token，即向緩存中添加單個token并產生新的token。

在生成文本序列的過程中，系統將對模型進行多次前向調用以生成完整的文本序列，現有文獻和系統中已經提出了兩種主要技術，解決了這些階段中可能出現的各種限制和瓶頸。

分塊KV緩存

vLLM識別出大型單體KV緩存導致的內存碎片化顯著降低了大型語言模型服務系統的并發性，并提出了「分頁注意力」（Paged Attention）機制來實現非連續KV緩存，并增加整個系統的總吞吐量。

此技術采用分頁緩存機制，從而提升了系統的整體吞吐量。不同于之前分配各個不同大小的連續內存塊的做法，分塊KV緩存中的底層存儲是固定大小的塊（也稱為頁面）。

分塊KV緩存通過消除KV緩存引起的內存碎片化，增加了潛在的序列并發量，從而增加了系統吞吐量。非連續KV緩存也被HuggingFace TGI和NVIDIA TensorRT-LLM等框架所實現。

連續批處理

過去，動態批處理（服務器等待多個請求以同步處理）被用來提高GPU利用率。然而，這種方法有缺點，因為它通常需要將輸入填充到相同長度或使系統等待以構建更大的批次（batch）。

近期大型語言模型（LLM）推理和服務的優化一直專注于細粒度調度和優化內存效率。例如，Orca提出了迭代級調度（也稱為連續批處理），它在模型的每次前向傳遞時作出獨特的調度決策。

這允許請求根據需要加入/離開批次，從而消除了填充請求的需要，提高了總體吞吐量。除了Orca，NVIDIA TRT-LLM、HuggingFace TGI和vLLM也實現了連續批處理。

在當前系統中，有兩種主要方法來實現連續批處理。

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

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

為了解決這些缺點，我們提出了一種新穎的提示和生成組合策略，動態 SplitFuse。

動態SplitFuse：一種新穎的提示和生成組合策略

類似于現有的框架如TRT-LLM、TGI和vLLM，DeepSpeed-FastGen的目標是利用連續批處理和非連續KV緩存技術，以提升數據中心服務大型語言模型（LLM）的硬件利用率和響應速度。

為了實現更高的性能，DeepSpeed-FastGen提出了SplitFuse技術，它利用動態提示和生成分解，統一來進一步改善連續批處理和系統吞吐量。

A. 三個性能見解

在描述動態SplitFuse之前，我們回答三個關鍵的性能問題，這些問題解釋了SplitFuse背后的邏輯。

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

為了有效地調度，我們必須首先了解調度過程中應考慮的獨立變量有哪些。

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

這意味著我們可以圍繞單一變量——即前向傳遞中的token數量——構建一個高效的調度器。

2. 模型的吞吐量與前向傳遞中token數量的關系如何？

一個LLM有兩個關鍵的運行區間，并且過渡相對陡峭。

當token數量較少時，GPU的瓶頸是從內存中讀取模型，因此吞吐量會隨著token數量的增加而上升，而當token數量很多時，模型的吞吐量受GPU計算能力限制，吞吐量近乎恒定。

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

3. 如何在多個前向傳遞中調度一組token？

我們在上圖中觀察到，對于對齊良好的輸入，token吞吐量曲線是凹的，這意味著第二導數必定小于或等于0。

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

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

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

B. 動態分割融合（Dynamic SplitFuse）

動態分割融合是一種用于提示處理和token生成的新型token組成策略。

DeepSpeed-FastGen利用動態分割融合策略，通過從提示中取出部分token并與生成過程相結合，使得模型可以保持一致的前向傳遞大小（forward size）。

具體來說，動態分割融合執行兩個關鍵行為：

將長提示分解成更小的塊，并在多個前向傳遞（迭代）中進行調度，只有在最后一個傳遞中才執行生成。短提示將被組合以精確填滿目標token預算。

即使是短提示也可能被分解，以確保預算被精確滿足，前向大小（forward sizes）保持良好對齊。

動態分割融合（Dynamic SplitFuse）提升了以下性能指標：

- 更好的響應性：

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

- 更高的效率：

短提示的融合到更大的token預算使模型能夠持續運行在高吞吐量狀態。

- 更低的波動和更好的一致性：

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

生成頻率也是如此，因為DeepSpeed-FastGen不需要像其他先前的系統那樣搶占或長時間運行提示，因此延遲會更低。

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

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

性能評估

DeepSpeed-FastGen利用分塊KV緩存和動態分割融合連續批處理，提供了最先進的LLM服務性能。

我們以下述的基準測試方法對DeepSpeed-FastGen和vLLM在一系列模型和硬件配置上進行評估。

A. 基準測試方法論

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

吞吐量-延遲曲線：生產環境的兩個關鍵指標是吞吐量（以每秒請求計）和延遲（每個請求的響應性）。

為了衡量這一點，我們模擬了多個客戶端（數量從1到32不等）同時向服務器發送請求（總計512個）的情況。每個請求的結果延遲在端點測量，吞吐量通過完成實驗的端到端時間來測量。

有效吞吐量：諸如聊天應用程序之類的交互式應用程序可能有比上述指標（如端到端延遲）更嚴格和復雜的要求。

以越來越受歡迎的聊天應用為例：

用戶通過發送提示（輸入）來開始對話。系統處理提示并返回第一個token。隨著生成的進行，后續token被流式傳輸給用戶。

在這個過程的每個階段，系統都有可能提供不利的用戶體驗；例如，第一個token到達得太慢；或生成似乎停止了一段時間。

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

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

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

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

我們通過在NVIDIA A100、H100和A6000上運行Llama-2 7B、Llama-2 13B和Llama-2 70B對vLLM和DeepSpeed-FastGen進行了評估。

B. 吞吐量-延遲分析

在這個實驗中，DeepSpeed-FastGen在吞吐量和延遲方面都優于vLLM，在相同的延遲下DeepSpeed-FastGen的吞吐量更大；在相同的吞吐量下DeepSpeed-FastGen的響應延遲更小。

如圖2所示，在Llama-2 70B運行于4個A100-80GB的情況下，DeepSpeed-FastGen展示了高達2倍的吞吐量（1.36 rps對比0.67 rps）在相同的延遲（9 秒）下；或高達50%的延遲減少（7秒對比14秒）同時實現相同的吞吐量（1.2 rps）。

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

評估Llama-2 13B時DeepSpeed-FastGen也呈現了這些趨勢，如圖3所示。

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

C. 有效吞吐量分析

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

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

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

當我們擴大客戶端數量時，我們最初觀察到有效吞吐量的增加。然而，當客戶端數量接近系統容量時，延遲也顯著增加，導致許多請求未能滿足SLA。

因此，有效吞吐量將在某個點上飽和或減少。從可用性角度來看，達到最大有效吞吐量所需的客戶端數量并不特別重要；線條的最高點是最優的服務點。

當vLLM搶占正在進行的先前請求的生成時，生成延遲會明顯增加。這導致vLLM的有效吞吐量看起來低于其直接測量的吞吐量。

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

D. token級時間分析

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

這種差異是由于vLLM在搶占正在進行的生成以處理新提示時，生成延遲出現顯著增加所導致的。

相比之下，DeepSpeed-FastGen通常會同時處理之前請求的提示和生成，導致生成延遲更加一致。

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

E. 使用負載均衡的可擴展性

DeepSpeed-FastGen提供了副本級負載均衡，可以將請求均勻分布在多個服務器上，讓您輕松擴展應用程序。

圖6展示了DeepSpeed-FastGen在使用負載均衡器和最多16個副本時的可擴展性。請注意，我們使用了4個A100 GPU來計算每個Llama 2 70B模型。

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

結果展示了DeepSpeed-FastGen幾乎完美的可擴展性。

單個副本時DeepSpeed-FastGen的吞吐量為1.46查詢/秒，而16個副本的吞吐量達到了23.7查詢/秒，與單個副本相比標志著線性的16倍增長。

F. 其他硬件平臺

除了對A100的深入分析，我們還提供了H100和A6000的基準測試結果。在A6000和H100上觀察到的性能趨勢與A100相同。

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

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

軟件實現與使用指南

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

兩個軟件包共同提供了系統的各個組成部分，包括前端API、用于使用動態SplitFuse調度批次的主機和設備基礎設施、優化的內核實現，以及構建新模型實現的工具。

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

A. 支持的模型

在DeepSpeed-FastGen的當前alpha版本中，我們目前支持以下模型架構：LLaMA和LLaMA-2MistralOPT

所有當前模型都利用了后端的HuggingFace API來提供模型權重和模型對應的分詞器。

我們計劃在最初發布后的幾周和幾個月內添加更多模型。如果您希望支持特定的模型架構，請提交問題來讓我們知道。

B. 部署選項

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

非持久管道

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

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)

持久部署

持久部署非常適合用于長時間運行和生產的應用。持久部署使用了輕量級的GRPC服務器，可以使用以下兩行代碼創建：

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

上述服務器可以同時被多個客戶端查詢，這要歸功于DeepSpeed-MII內置的負載平衡器。創建客戶端也只需要兩行代碼：

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

持久部署可以在不再需要時終止：

client.terminate_server()

C. 高級安裝方式

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

我們發現這個庫在環境中非常便攜，只要這些環境具有NVIDIA GPU計算能力 8.0+（Ampere+）、CUDA 11.6+和Ubuntu 20+。

在大多數情況下，您甚至不需要知道這個庫的存在，因為它是DeepSpeed-MII的依賴項，并將自動與之一起安裝。然而，如果您因任何原因需要手動編譯我們的內核，請參閱我們的高級安裝文檔。

轉載自微軟DeepSpeed組官方知乎賬號：zhihu.com/people/deepspeed