一、背景

Deepseek-r1模型的爆火標(biāo)志著本地部署大模型的需求日益增長(zhǎng)。本文主要探討如何優(yōu)化本地部署大模型的性能，并結(jié)合我們的實(shí)踐進(jìn)行評(píng)測(cè)分析，文章最后我們將分享如何在本地高效部署滿血版Deepseek-r1大模型。

在生產(chǎn)環(huán)境中，我們已部署專用的大模型推理集群，并對(duì)其性能進(jìn)行了全面優(yōu)化。對(duì)于大模型推理來(lái)說(shuō)，性能優(yōu)化主要聚焦于兩個(gè)關(guān)鍵指標(biāo)：吞吐量與響應(yīng)時(shí)間(RT)。

1. 吞吐量
   傳統(tǒng)上，我們用每秒請(qǐng)求數(shù)（QPS）來(lái)衡量吞吐量，即系統(tǒng)每秒能夠處理多少請(qǐng)求。但對(duì)于大模型而言，還有一個(gè)重要指標(biāo)——每秒Token數(shù)（token/s），它反映了系統(tǒng)每秒能處理的輸入或輸出Token數(shù)量。
2. 響應(yīng)時(shí)間（RT）
   這是指系統(tǒng)處理每個(gè)請(qǐng)求所需的時(shí)間。對(duì)于支持流式輸出的大模型，還需要關(guān)注另外一個(gè)指標(biāo)——首個(gè)Token到達(dá)時(shí)間（TTFT: Time To First Token），即從開始處理請(qǐng)求到輸出第一個(gè)Token所需的時(shí)間

接下來(lái)文章將介紹部署高性能大模型推理服務(wù)的方法與思路，這些方法主要圍繞提升吞吐量與響應(yīng)時(shí)間這兩個(gè)關(guān)鍵指標(biāo)展開。

二、高性能、易擴(kuò)展的大模型推理框架是什么樣的

盡管業(yè)界已有許多經(jīng)典的大模型推理框架，但在深入了解這些框架之前，我們不妨先思考一下，如何設(shè)計(jì)一個(gè)既高性能又易于擴(kuò)展的大模型推理框架。

大模型推理框架需要滿足的基本條件

性能足夠高——CPU與GPU分離設(shè)計(jì)

對(duì)于一款以Python為主的大模型GPU推理引擎，要實(shí)現(xiàn)較高的性能，關(guān)鍵在于CPU與GPU的分離設(shè)計(jì)。至少需要將系統(tǒng)拆分為兩個(gè)進(jìn)程：CPU進(jìn)程和GPU進(jìn)程。CPU進(jìn)程主要負(fù)責(zé)與CPU相關(guān)的邏輯，例如序列化、調(diào)度、分發(fā)和Resize等；而GPU進(jìn)程則專注于GPU推理邏輯，其底層通過(guò)直接調(diào)用CUDA等庫(kù)來(lái)進(jìn)行GPU運(yùn)算。

目前，主流的大模型推理框架，如vllm與sglang，已經(jīng)實(shí)現(xiàn)或正在實(shí)施CPU與GPU分離架構(gòu)。

那么，CPU與GPU分離究竟解決了什么問(wèn)題呢？

一直以來(lái)，Python 在運(yùn)行時(shí)采用全局解釋器鎖（GIL）機(jī)制，這意味著在任意時(shí)刻只有一個(gè)線程能夠執(zhí)行 Python 字節(jié)碼。也就是說(shuō)，即使在多線程程序中，各線程也無(wú)法在 Python 層面實(shí)現(xiàn)真正的并行執(zhí)行。這個(gè)設(shè)計(jì)主要是為了簡(jiǎn)化內(nèi)存管理和對(duì)象引用計(jì)數(shù)，從而保證線程安全，但也帶來(lái)了一些限制，特別是在以GPU計(jì)算為主的推理服務(wù)中更為明顯。

在單一的 Python 進(jìn)程中，如果同時(shí)存在多個(gè) CPU 密集型任務(wù)（比如網(wǎng)絡(luò)請(qǐng)求處理、數(shù)據(jù)預(yù)處理、請(qǐng)求驗(yàn)證等）和 GPU 任務(wù)，它們都必須在同一個(gè) GIL 下運(yùn)行。這樣，CPU密集型任務(wù)就會(huì)與GPU任務(wù)競(jìng)爭(zhēng) GIL，導(dǎo)致 GPU kernel 啟動(dòng)調(diào)度不足，從而形成性能瓶頸。這種瓶頸表現(xiàn)為GPU利用率不高，在高并發(fā)場(chǎng)景下，GIL 的競(jìng)爭(zhēng)會(huì)極大地影響系統(tǒng)的響應(yīng)速度和吞吐量。

下表為我們?cè)?jīng)針對(duì)Python GIL鎖做過(guò)的專項(xiàng)對(duì)比測(cè)試，在做了CPU與GPU分離設(shè)計(jì)后，GPU利用率大幅提高，QPS提升了7倍，RT縮減了50%。

下面是VLLM在0.6版本做的最大變更，即做CPU與GPU進(jìn)程分離設(shè)計(jì)，帶來(lái)了性能的大幅提升，吞吐提升了2.7倍。具體可以參考文章[1]vLLM v0.6.0: 2.7x Throughput Improvement and 5x Latency Reduction。

可擴(kuò)展性足夠好——各模塊高內(nèi)聚低耦合

為了實(shí)現(xiàn)高效且易于擴(kuò)展的設(shè)計(jì)，我們應(yīng)將系統(tǒng)按照功能拆分為多個(gè)模塊，每個(gè)模塊只負(fù)責(zé)其特定功能，確保模塊內(nèi)部的高內(nèi)聚和模塊間的低耦合。一個(gè)完整的大模型推理框架至少需要包含以下四個(gè)模塊：

• 接入層：接入層負(fù)責(zé)處理各種請(qǐng)求。比如當(dāng)收到OpenAI格式的請(qǐng)求時(shí)，接入層將其轉(zhuǎn)化為內(nèi)部可識(shí)別的原始請(qǐng)求（raw request），以便后續(xù)其他模塊繼續(xù)處理。
• 調(diào)度器：調(diào)度器負(fù)責(zé)管理和調(diào)度各個(gè)請(qǐng)求（Request）。當(dāng)有多個(gè)并發(fā)請(qǐng)求時(shí)，調(diào)度器動(dòng)態(tài)調(diào)整模型的輸入和輸出，以確保計(jì)算資源得到高效利用，同時(shí)滿足調(diào)度限制，如GPU緩存、最大請(qǐng)求數(shù)和最大處理長(zhǎng)度等。調(diào)度器通過(guò)管理請(qǐng)求的狀態(tài)、緩存、優(yōu)先級(jí)和資源使用，確保推理過(guò)程流暢進(jìn)行。
• 模型推理：在接收到請(qǐng)求后，模型推理層調(diào)用相應(yīng)模型的forward方法進(jìn)行推理計(jì)算。其底層實(shí)際上調(diào)用CUDA等進(jìn)行GPU推理。
• 顯存管理：操作系統(tǒng)有物理內(nèi)存管理機(jī)制，避免了頻繁申請(qǐng)和釋放內(nèi)存帶來(lái)的碎片問(wèn)題。然而，CUDA計(jì)算中并沒(méi)有顯存管理機(jī)制，頻繁的顯存申請(qǐng)與釋放同樣會(huì)導(dǎo)致顯存碎片問(wèn)題。因此，顯存管理成為推理引擎中不可或缺的模塊，用于解決顯存碎片問(wèn)題。

大模型推理框架設(shè)計(jì)

綜合上述內(nèi)容，我們可以設(shè)計(jì)出一個(gè)高性能、可擴(kuò)展的大模型推理框架?？蚣軋D如下：

從框架圖中可以看出，系統(tǒng)首先被拆分為多個(gè)進(jìn)程(多個(gè)CPU進(jìn)程與GPU進(jìn)程)，進(jìn)程間可通過(guò)管道等方式進(jìn)行通信。此外，系統(tǒng)在邏輯上又被拆分為多個(gè)模塊，其中接入層、調(diào)度器、模型推理和顯存管理四個(gè)模塊是必不可少的。

該架構(gòu)也是當(dāng)前vllm 1.0與sglang等經(jīng)典推理框架的基礎(chǔ)架構(gòu)。感興趣的同學(xué)可以通過(guò)查看相關(guān)代碼，你會(huì)發(fā)現(xiàn)它們的設(shè)計(jì)思路大致與上面相同。比如下面的sglang推理引擎的代碼，參考：[2]sglang 代碼

三、解決顯存碎片問(wèn)題，大幅提升吞吐—Paged Attention

在 Linux 等操作系統(tǒng)上運(yùn)行的應(yīng)用程序通常不會(huì)出現(xiàn)內(nèi)存碎片問(wèn)題，這是因?yàn)?Linux 內(nèi)核擁有強(qiáng)大的內(nèi)存管理機(jī)制，專門用于解決內(nèi)存碎片問(wèn)題。然而，這一優(yōu)勢(shì)僅適用于系統(tǒng)內(nèi)存；如果在 GPU 上頻繁申請(qǐng)和釋放不規(guī)則大小的顯存，就可能導(dǎo)致顯存碎片的產(chǎn)生。

在大模型推理場(chǎng)景中，顯存碎片問(wèn)題尤為嚴(yán)重。大部分推理過(guò)程都涉及注意力計(jì)算（Attention），而每次計(jì)算都需要申請(qǐng)并使用一個(gè)名為 kvcache 的緩存。隨著請(qǐng)求的不斷增加，kvcache 的大小與數(shù)量會(huì)逐步上升，通常占據(jù)總總顯存的約三分之一，而且它會(huì)被頻繁地被申請(qǐng)和釋放。如果不對(duì) kvcache 使用的 GPU 顯存進(jìn)行有效管理，顯存碎片將大量累積，最終可能導(dǎo)致系統(tǒng)性能下降甚至崩潰。

為了解決這一問(wèn)題，vllm 提出了 Paged Attention 的概念[3]，其設(shè)計(jì)思路正是借鑒了操作系統(tǒng)的內(nèi)存管理機(jī)制，對(duì) kvcache 的顯存進(jìn)行統(tǒng)一管理。

首先，我們回顧一下操作系統(tǒng)是如何避免內(nèi)存碎片的。操作系統(tǒng)通常將物理內(nèi)存劃分為若干固定大小的塊，并利用頁(yè)表將應(yīng)用程序的虛擬地址映射到相應(yīng)的物理內(nèi)存塊。當(dāng)應(yīng)用程序申請(qǐng)內(nèi)存時(shí)，系統(tǒng)先分配虛擬地址，然后在實(shí)際使用時(shí)，從固定大小的物理內(nèi)存塊中分配空間，并建立虛擬地址與物理地址之間的映射。這樣，就能有效避免內(nèi)存碎片問(wèn)題。

Paged Attention 正是基于這一原理而提出的——“Paged”體現(xiàn)了類似頁(yè)表的映射方式，而“Attention”則表示這種映射機(jī)制被應(yīng)用在大模型注意力計(jì)算中。

PagedAttention 工作原理，圖片來(lái)自[3] Efficient Memory Management for Large Language Model Serving with PagedAttention。

vllm 的 Paged Attention 是一種受操作系統(tǒng)虛擬內(nèi)存和分頁(yè)機(jī)制啟發(fā)的注意力算法。它將大型語(yǔ)言模型中的 KV Cache 緩存劃分為固定大小的塊，這些塊可以在內(nèi)存中非連續(xù)存儲(chǔ)。然后通過(guò)Block table(類似Linux頁(yè)表)把每個(gè)請(qǐng)求的邏輯KV 塊(類似Linux虛擬地址)映射到物理KV 塊(類似物理內(nèi)存)中。通過(guò)這種方法，PagedAttention 能有效管理內(nèi)存，減少碎片和浪費(fèi)，大幅提升系統(tǒng)的吞吐量。

Paged Attention評(píng)測(cè)效果

圖片來(lái)自[4] vLLM: Easy, Fast, and Cheap LLM Serving with PagedAttention

通過(guò)高效的內(nèi)存管理，Paged Attention減少了內(nèi)存浪費(fèi)，提高了 GPU 的利用率，使模型的推理吞吐量比傳統(tǒng)方法提升了數(shù)倍。例如，與 HuggingFace Transformers 相比，吞吐量可提升至 24 倍；與 HuggingFace TGI 相比，提升可達(dá) 3.5 倍。此外，它還降低了內(nèi)存開銷，支持更復(fù)雜的采樣方法，使 LLM 服務(wù)變得更快、更經(jīng)濟(jì)。

目前VLLM與SGLang等推理引擎默認(rèn)支持Paged Attention開啟，所以你使用這些推理引擎部署大模型，系統(tǒng)會(huì)自動(dòng)支持。

四、緩存之前請(qǐng)求的計(jì)算結(jié)果，減少重復(fù)計(jì)算—Radix Attention

雖然 Paged Attention 成功解決了顯存碎片問(wèn)題，并顯著提升了系統(tǒng)吞吐量，但在大模型推理中，還有一個(gè)常見(jiàn)場(chǎng)景具備較大性能優(yōu)化空間。

實(shí)際應(yīng)用中，我們往往需要多次給大模型發(fā)送請(qǐng)求，而這些請(qǐng)求的Prompt中有很大一部分的內(nèi)容是完全相同的。如下所示：

圖片來(lái)自[5] Fast and Expressive LLM Inference with RadixAttention and SGLang

上圖中藍(lán)色框表示可共享的Prompt部分，綠色框表示不可共享的Prompt部分，黃色框表示模型的輸出。

上圖中可共享部分場(chǎng)景包括少量示例學(xué)習(xí)、自我一致性中的問(wèn)題、多輪對(duì)話中的聊天歷史，以及思維樹中的搜索歷史。在這些場(chǎng)景中，每次請(qǐng)求都會(huì)重復(fù)計(jì)算這些Prompt中可共享的部分，這些會(huì)造成大量的計(jì)算資源浪費(fèi)。

那么，有沒(méi)有辦法將這些重復(fù)部分的計(jì)算結(jié)果(KV Cache)緩存起來(lái)，下次請(qǐng)求時(shí)直接使用呢？為此，SGLang 提出了一種優(yōu)秀的算法—— Radix Attention。

RadixAttention 是一種新技術(shù)，用于在大語(yǔ)言模型的推理過(guò)程中優(yōu)化 KV 緩存的重用。其核心在于利用基數(shù)樹（Radix Tree）來(lái)高效管理和重用不同請(qǐng)求之間共享的前綴，從而減少重復(fù)計(jì)算和內(nèi)存占用。也就是說(shuō)，當(dāng)多個(gè)請(qǐng)求共享相同的前綴（例如系統(tǒng)提示 "You are a helpful assistant"）時(shí)，RadixAttention 可以重用該前綴對(duì)應(yīng)的 KV 緩存，避免重復(fù)計(jì)算。

下圖中的例子展示了 RadixAttention 在九個(gè)時(shí)間點(diǎn)上的基數(shù)樹動(dòng)態(tài)演變過(guò)程，以下是具體步驟的解釋：

圖片來(lái)自[5] Fast and Expressive LLM Inference with RadixAttention and SGLang

1. 初始狀態(tài)：基數(shù)樹最初為空。
2. 第一場(chǎng)聊天開始：用戶發(fā)送“你好！”，助手回復(fù)“你好！”，系統(tǒng)提示、用戶消息和助手回復(fù)被合并為基數(shù)樹中的一條邊，連接到新節(jié)點(diǎn)。
3. 第一場(chǎng)聊天繼續(xù)：同一會(huì)話中收到新消息，服務(wù)器在基數(shù)樹中找到已有前綴并重用其KV緩存，新消息作為新節(jié)點(diǎn)附加到樹上。
4. 第二場(chǎng)聊天開始：另一個(gè)用戶開始新的聊天會(huì)話，服務(wù)器分割現(xiàn)有節(jié)點(diǎn)，使兩個(gè)會(huì)話共享公共前綴和KV緩存。
5. 第二場(chǎng)聊天繼續(xù)并進(jìn)行淘汰：第二場(chǎng)聊天繼續(xù)，因內(nèi)存限制，第一場(chǎng)聊天中最少近期使用的節(jié)點(diǎn)被淘汰釋放空間，新消息在共享節(jié)點(diǎn)后添加到樹上。
6. 處理少樣本學(xué)習(xí)查詢：服務(wù)器收到不與現(xiàn)有節(jié)點(diǎn)共享前綴的少樣本學(xué)習(xí)請(qǐng)求，根節(jié)點(diǎn)被分割以容納新序列，請(qǐng)求作為單獨(dú)分支插入樹中。
7. 處理一批少樣本學(xué)習(xí)查詢：收到一批共享相同少樣本示例的查詢，分割第六步的節(jié)點(diǎn)以在這些查詢間實(shí)現(xiàn)KV緩存共享，最大化重用并減少冗余計(jì)算。
8. 第一場(chǎng)聊天繼續(xù)并進(jìn)行淘汰：第一場(chǎng)聊天繼續(xù)，基于最近最少使用（LRU）策略，淘汰第二場(chǎng)聊天的節(jié)點(diǎn)以高效管理內(nèi)存。
9. 自一致性采樣并進(jìn)行淘汰：服務(wù)器收到生成多個(gè)答案的請(qǐng)求，為自一致性目的，按照LRU策略淘汰較不重要的節(jié)點(diǎn)以為新請(qǐng)求分配內(nèi)存。 

那Radix Attention帶來(lái)的性能提升如何呢？我們針對(duì)SGLang推出的Radix Attention與VLLM (v0.5.0)進(jìn)行了對(duì)比評(píng)測(cè)。同時(shí)由于Radix Attention可以復(fù)用不同請(qǐng)求的上下文，這與我們的日常業(yè)務(wù)使用比較吻合，取得了不錯(cuò)的評(píng)測(cè)結(jié)果，Radix Attention充分利用不同請(qǐng)求之間的共享前綴，其耗時(shí)比VLLM(v0.5.0)快30%，吞吐是VLLM(v0.5.0)的1.5倍。

下面為SGLang給出的Radix Attention性能對(duì)比效果，與當(dāng)前系統(tǒng)相比，SGLang吞吐提升了5倍以上。

圖片來(lái)自[5] Fast and Expressive LLM Inference with RadixAttention and SGLang

如果你也想嘗試下Radix Attention，可以直接使用SGLang的推理引擎去啟動(dòng)大模型嘗試下。

五、請(qǐng)求分塊處理，避免單個(gè)請(qǐng)求卡頓 —— Chunked Prefill

在將大模型應(yīng)用于生產(chǎn)環(huán)境時(shí)，我們有時(shí)會(huì)遇到一種奇怪的現(xiàn)象：某個(gè)請(qǐng)求的響應(yīng)時(shí)間（RT）異常長(zhǎng)，甚至出現(xiàn)卡頓，而系統(tǒng)的平均響應(yīng)時(shí)間卻依然正常。這是什么原因?qū)е碌哪?？又如何解決呢？

大模型的推理過(guò)程實(shí)際上可以分為兩個(gè)階段：prefill 階段和 decode 階段。舉個(gè)例子：假設(shè)我們輸入了一個(gè)包含 1000 個(gè) token 的 prompt，并希望模型生成 100 個(gè) token 的響應(yīng)。

1. Prefill 階段：系統(tǒng)首先對(duì)這 1000 個(gè) token 進(jìn)行并行推理，這一步驟可以充分利用 GPU 的并行計(jì)算能力。
2. Decode 階段：隨后，系統(tǒng)會(huì)逐個(gè)生成后續(xù)的 100 個(gè) token。由于每個(gè)新生成的 token 都依賴于之前的輸出，因此這一階段必須按順序逐個(gè)生成。

在實(shí)際應(yīng)用中，多個(gè)請(qǐng)求往往會(huì)同時(shí)進(jìn)行推理，因此可能出現(xiàn)不同請(qǐng)求的階段交叉運(yùn)行。例如，如果請(qǐng)求 req3 的 prefill 階段處理了一個(gè)非常長(zhǎng)的 prompt，那么它就會(huì)占用大量的 GPU 資源；而如果此時(shí) req13的 prefill 階段與請(qǐng)求 req1的 decode 階段并行運(yùn)行，就會(huì)導(dǎo)致 req1的 decode 階段響應(yīng)速度明顯變慢，甚至出現(xiàn)卡頓現(xiàn)象。

圖片來(lái)自 Taming Throughput-Latency Tradeoff in LLM Inference with Sarathi-Serve vLLM @ Fourth Meetup (Public) ，較大的prompt請(qǐng)求與decode階段請(qǐng)求并行調(diào)度，算力資源爭(zhēng)搶，會(huì)顯著影響decode階段。

問(wèn)題原因明確了，解決方法也十分簡(jiǎn)單：縮短每次提交給 GPU 并行計(jì)算的 prompt 長(zhǎng)度。具體來(lái)說(shuō)，我們可以將整個(gè) prompt 按照固定長(zhǎng)度（例如 512 個(gè) token）進(jìn)行分塊，每次在 prefill 階段只處理一塊。這樣一來(lái)，每次并行計(jì)算的內(nèi)容就變得更短，不僅能減輕單個(gè)請(qǐng)求對(duì) GPU 資源的占用，還能避免對(duì)同時(shí)運(yùn)行的 decode 請(qǐng)求產(chǎn)生影響。這個(gè)方法便被稱為 chunked prefill。

圖片來(lái)自 Taming Throughput-Latency Tradeoff in LLM Inference with Sarathi-Serve vLLM @ Fourth Meetup (Public) 開啟chunked prefill后，prefill與decode并行互不影響。

如下圖所示，vllm 通過(guò)啟用 chunked prefill 功能，顯著降低了系統(tǒng)的最大響應(yīng)時(shí)間（max RT）。

圖片來(lái)自 Taming Throughput-Latency Tradeoff in LLM Inference with Sarathi-Serve vLLM @ Fourth Meetup (Public)，開啟chunked prefill后，在高并發(fā)QPS下，平均RT提升了2倍。

在 vllm 的最新版本中，chunked prefill 已默認(rèn)開啟。

六、縮短輸出長(zhǎng)度，顯著提升性能

在前文中，我們提到過(guò)大模型的推理過(guò)程分為 prefill 階段和 decode 階段。Prefill 階段主要對(duì) prompt 進(jìn)行注意力計(jì)算，并可以并行進(jìn)行；而 decode 階段則用于生成新輸出的 token，這一階段必須按順序逐個(gè)生成，無(wú)法并行。

因此，如果我們能夠在 decode 階段盡量減少生成的 token 總長(zhǎng)度，就能顯著提高整體的響應(yīng)時(shí)間（RT）。具體來(lái)說(shuō)，如果每生成一個(gè) token 耗時(shí) 5 毫秒，減少 5 個(gè) token 的輸出，就能減少 25 毫秒的總響應(yīng)時(shí)間。對(duì)于非流式調(diào)用的大模型來(lái)說(shuō)，這種改進(jìn)會(huì)帶來(lái)顯著效果。例如，如果大模型只需進(jìn)行簡(jiǎn)單的分類或識(shí)別任務(wù)，那么僅需輸出結(jié)果即可，其他無(wú)關(guān)信息完全不需要生成。

那么如何縮短大模型的輸出長(zhǎng)度呢？

a.限制最大輸出長(zhǎng)度

首先，可以通過(guò)設(shè)置系統(tǒng)參數(shù)來(lái)限制大模型的最大輸出長(zhǎng)度。如果你通過(guò) OpenAI 接口調(diào)用大模型，在輸入?yún)?shù)中有一個(gè)叫做 max tokens 的設(shè)置項(xiàng)。你可以調(diào)整該參數(shù)，限制大模型的最大輸出長(zhǎng)度。這樣一來(lái)，可以避免大模型產(chǎn)生過(guò)長(zhǎng)的輸出，甚至防止無(wú)限循環(huán)的情況。一個(gè)示例代碼如下：

b.通過(guò) Prompt 限制輸出

另外，可以通過(guò)優(yōu)化 prompt 來(lái)引導(dǎo)大模型產(chǎn)生更短的輸出。例如，在 prompt 中加上類似“請(qǐng)直接輸出結(jié)果”或“請(qǐng)盡可能簡(jiǎn)短輸出結(jié)果”的提示語(yǔ)，可以有效減少無(wú)關(guān)內(nèi)容的輸出。

c.微調(diào)大模型

如果條件允許，微調(diào)大模型也是一種有效的方法。通過(guò)微調(diào)，可以讓大模型在滿足需求的前提下盡量縮短輸出。微調(diào)的過(guò)程中，首先可以通過(guò) prompt 調(diào)整輸出長(zhǎng)度，制造大量數(shù)據(jù)后，再對(duì)大模型進(jìn)行訓(xùn)練。這樣一來(lái)，不僅輸入的內(nèi)容被優(yōu)化，輸出的長(zhǎng)度也能有效縮短，達(dá)到更好的效果。

七、使用多卡推理，推理速度翻倍

在某些場(chǎng)景下，出于模型效果考慮無(wú)法對(duì)大模型進(jìn)行量化，但對(duì)響應(yīng)時(shí)間（RT）有非常高的要求。這時(shí)，嘗試 多卡推理 可以帶來(lái)立竿見(jiàn)影的效果，通常能夠?qū)?RT 縮短至原來(lái)的 1/3 或 1/2。

   以下是我們針對(duì) 單卡 與 雙卡 推理性能的對(duì)比測(cè)試結(jié)果：

可見(jiàn)推理中單卡變雙卡可以顯著提升大模型推理速度與QPS。

那為什么多卡可以提升大模型的推理速度呢？主要原因多卡推理的優(yōu)化是通過(guò) tensor parallelism（張量并行）實(shí)現(xiàn)的。

假設(shè)你將 tensor parallel 設(shè)置為 2，意味著使用兩張 GPU 來(lái)加速推理。在模型加載時(shí)，推理引擎會(huì)將大模型的 attention 參數(shù)的數(shù)量分為兩組，分別加載到每張 GPU 上。然后，在推理過(guò)程中，兩個(gè) GPU 會(huì)并行計(jì)算注意力，最后再將結(jié)果聚合合并。

想象一下，你有一本非常厚的書，你想一次性復(fù)印整本書，但是你的復(fù)印機(jī)一次只能復(fù)印幾頁(yè)。這時(shí)，你可以把這本書分成幾個(gè)部分，每個(gè)部分分別復(fù)印，最后再把所有復(fù)印好的部分按順序拼接起來(lái)，這樣就完成了整本書的復(fù)印。

在張量并行中，我們要處理的大模型就像是那本厚書，而GPU則像是復(fù)印機(jī)。因?yàn)閱蝹€(gè)GPU無(wú)法一次處理整個(gè)大模型，我們就需要把模型（在這個(gè)例子中是權(quán)重張量）分成幾個(gè)部分，讓不同的GPU分別處理（相當(dāng)于復(fù)印書的不同部分）。在處理輸入數(shù)據(jù)時(shí)，就像是把書的每一頁(yè)分別復(fù)印，然后再把復(fù)印好的各個(gè)部分拼接起來(lái)，形成完整的輸出結(jié)果。

如何配置tensor parell并行呢？下面我們分別給出vllm 與sglang兩款大模型的配置方式。

1.vllm配置多卡推理

以下命令為vllm如何配置多卡推理的方式。

圖片來(lái)自[6] vllm Documentation

2.SGLang配置多卡推理

以為命令為SGLang推理服務(wù)如何配置多卡推理。

八、小模型推理+大模型驗(yàn)證 —— 預(yù)測(cè)解碼 (Speculative Decoding)

最近，一種名為預(yù)測(cè)解碼的加速技術(shù)備受關(guān)注，它能夠在特定條件下顯著提升大型模型（如72B大模型）的推理速度。

預(yù)測(cè)解碼工作原理比較簡(jiǎn)單，假如你想加速一個(gè)70b大模型。你可以訓(xùn)練一個(gè)同類型的7b小模型，然后開啟預(yù)測(cè)解碼。系統(tǒng)同時(shí)加載7b小模型與70b大模型，在推理的時(shí)候先讓7b小模型做輸出，比如輸出5個(gè)token。然后再把這5個(gè)token交給70b大模型去做驗(yàn)證，并保留驗(yàn)證正確的前N個(gè)token做為輸出，以此類推。

由于驗(yàn)證是可以批量進(jìn)行的，而小模型的推理速度又比較快。這樣就可以大大提升70b大模型的推理速度，同時(shí)保障70b大模型的效果。

以下為我們針對(duì)70b模型所做的實(shí)驗(yàn)效果。

可見(jiàn)預(yù)測(cè)解碼在一定的場(chǎng)景下可以提升大模型的推理速度。

此外還有一種更簡(jiǎn)單的方式，如果你不想訓(xùn)練7b的小模型，而你的輸出中大部分都與輸入promt相似，比如你只是讓大模型幫你修改下文章中錯(cuò)別字。那么你可以直接使用n-gram匹配prompt的方法替代小模型，即直接從輸入prompt中選取預(yù)測(cè)的token，讓大模型直接去驗(yàn)證。這樣輸出速度更快，更簡(jiǎn)單。

關(guān)于預(yù)測(cè)解碼，想深入了解的同學(xué)可以參考vllm的這篇文檔。[8] How Speculative Decoding Boosts vLLM Performance by up to 2.8x

下面我們介紹下如何在vllm中配置預(yù)測(cè)解碼。

a.使用大模型+小模型的方式

b.使用n-gram的方式

九、高效部署Deepseek-R1模型的方法

前面我們介紹了業(yè)界大模型性能優(yōu)化的很多方法，接下來(lái)我們將用SGLang這個(gè)推理引擎來(lái)部署下最近爆火Deepseek-R1滿血版大模型。下面分享下詳細(xì)的部署步驟。

a.如何下載Deepseek-r1

這次Deepseek發(fā)布了一系列模型，如下：

原始模型包括Deepseek-r1-zero與Deepseek-r1，其中Deepseek-r1是官方推薦的經(jīng)過(guò)多階段訓(xùn)練的最優(yōu)模型。但是Deepseek-r1有671B大小的參數(shù)，部署起來(lái)至少需要2*8H20GPU，比較耗費(fèi)資源。所以deepseek團(tuán)隊(duì)又基于Deepseek-r1蒸餾出了一系列小的模型，其中效果不錯(cuò)比如DeepSeek-R1-Distill-Qwen-32B，單卡H20可以運(yùn)行啟動(dòng)。

我們這里只介紹滿血版Deepseek-r1的部署方法。

b.準(zhǔn)備部署環(huán)境

我們嘗試使用SGLang這個(gè)大模型推理引擎部署Deepseek-r1。以下為我們的部署軟硬件環(huán)境準(zhǔn)備。

部署Deepseek-r1

準(zhǔn)備好SGLang鏡像，deepseek-r1模型，GPU后，可以按照如下命令啟動(dòng)deepseek-r1

 node 1：

  python -m sglang.launch_server --model-path deepseek-ai/DeepSeek-V3 --tp 16 --dist-init-addr 10.0.0.1:5000 --nnodes 2 --node-rank 0 --trust-remote-code

 node 2：

  python -m sglang.launch_server --model-path deepseek-ai/DeepSeek-V3 --tp 16 --dist-init-addr 10.0.0.1:5000 --nnodes 2 --node-rank 1 --trust-remote-code

這里使用的是多機(jī)多卡部署，部署后使用Openai格式請(qǐng)求發(fā)送到node1上即可。

十、總結(jié)

文章依次總結(jié)了部署高性能大模型推理服務(wù)的技巧與實(shí)踐，先后介紹了Paged Attention，Radix Attention，chunked prefill，多卡并行等大模型推理加速方法，并給出驗(yàn)證結(jié)果與操作方法。文章最后還給出最近爆火的deepseek-r1的高效部署方法，歡迎大家去嘗試優(yōu)化。

后續(xù)我們將會(huì)持續(xù)關(guān)注大模型推理性能提升方面的最新技術(shù)，驗(yàn)證并及時(shí)分享給大家。

參考文獻(xiàn)

[1] vLLM v0.6.0: 2.7x Throughput Improvement and 5x Latency Reduction https://blog.vllm.ai/2024/09/05/perf-update.html

[2] sglang 代碼 https://github.com/sgl-project/sglang/tree/main/python/sglang/srt/managers

[3] Efficient Memory Management for Large Language Model Serving with PagedAttention(https://arxiv.org/abs/2309.06180)

[4] vLLM: Easy, Fast, and Cheap LLM Serving with PagedAttention https://blog.vllm.ai/2023/06/20/vllm.html

[5] Fast and Expressive LLM Inference with RadixAttention and SGLang https://lmsys.org/blog/2024-01-17-sglang/

[6] vllm Documentation https://docs.vllm.ai/en/latest/

[7] SGLang Documentation https://docs.sglang.ai/backend/server_arguments.html

[8] How Speculative Decoding Boosts vLLM Performance by up to 2.8x https://blog.vllm.ai/2024/10/17/spec-decode.html