一、背景

Deepseek-r1模型的爆火標志著本地部署大模型的需求日益增長。本文主要探討如何優化本地部署大模型的性能，并結合我們的實踐進行評測分析，文章最后我們將分享如何在本地高效部署滿血版Deepseek-r1大模型。

在生產環境中，我們已部署專用的大模型推理集群，并對其性能進行了全面優化。對于大模型推理來說，性能優化主要聚焦于兩個關鍵指標：吞吐量與響應時間(RT)。

1. 吞吐量
   傳統上，我們用每秒請求數（QPS）來衡量吞吐量，即系統每秒能夠處理多少請求。但對于大模型而言，還有一個重要指標——每秒Token數（token/s），它反映了系統每秒能處理的輸入或輸出Token數量。
2. 響應時間（RT）
   這是指系統處理每個請求所需的時間。對于支持流式輸出的大模型，還需要關注另外一個指標——首個Token到達時間（TTFT: Time To First Token），即從開始處理請求到輸出第一個Token所需的時間

接下來文章將介紹部署高性能大模型推理服務的方法與思路，這些方法主要圍繞提升吞吐量與響應時間這兩個關鍵指標展開。

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

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

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

性能足夠高——CPU與GPU分離設計

對于一款以Python為主的大模型GPU推理引擎，要實現較高的性能，關鍵在于CPU與GPU的分離設計。至少需要將系統拆分為兩個進程：CPU進程和GPU進程。CPU進程主要負責與CPU相關的邏輯，例如序列化、調度、分發和Resize等；而GPU進程則專注于GPU推理邏輯，其底層通過直接調用CUDA等庫來進行GPU運算。

目前，主流的大模型推理框架，如vllm與sglang，已經實現或正在實施CPU與GPU分離架構。

那么，CPU與GPU分離究竟解決了什么問題呢？

一直以來，Python 在運行時采用全局解釋器鎖（GIL）機制，這意味著在任意時刻只有一個線程能夠執行 Python 字節碼。也就是說，即使在多線程程序中，各線程也無法在 Python 層面實現真正的并行執行。這個設計主要是為了簡化內存管理和對象引用計數，從而保證線程安全，但也帶來了一些限制，特別是在以GPU計算為主的推理服務中更為明顯。

在單一的 Python 進程中，如果同時存在多個 CPU 密集型任務（比如網絡請求處理、數據預處理、請求驗證等）和 GPU 任務，它們都必須在同一個 GIL 下運行。這樣，CPU密集型任務就會與GPU任務競爭 GIL，導致 GPU kernel 啟動調度不足，從而形成性能瓶頸。這種瓶頸表現為GPU利用率不高，在高并發場景下，GIL 的競爭會極大地影響系統的響應速度和吞吐量。

下表為我們曾經針對Python GIL鎖做過的專項對比測試，在做了CPU與GPU分離設計后，GPU利用率大幅提高，QPS提升了7倍，RT縮減了50%。

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

可擴展性足夠好——各模塊高內聚低耦合

為了實現高效且易于擴展的設計，我們應將系統按照功能拆分為多個模塊，每個模塊只負責其特定功能，確保模塊內部的高內聚和模塊間的低耦合。一個完整的大模型推理框架至少需要包含以下四個模塊：

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

大模型推理框架設計

綜合上述內容，我們可以設計出一個高性能、可擴展的大模型推理框架。框架圖如下：

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

該架構也是當前vllm 1.0與sglang等經典推理框架的基礎架構。感興趣的同學可以通過查看相關代碼，你會發現它們的設計思路大致與上面相同。比如下面的sglang推理引擎的代碼，參考：[2]sglang 代碼

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

在 Linux 等操作系統上運行的應用程序通常不會出現內存碎片問題，這是因為 Linux 內核擁有強大的內存管理機制，專門用于解決內存碎片問題。然而，這一優勢僅適用于系統內存；如果在 GPU 上頻繁申請和釋放不規則大小的顯存，就可能導致顯存碎片的產生。

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

為了解決這一問題，vllm 提出了 Paged Attention 的概念[3]，其設計思路正是借鑒了操作系統的內存管理機制，對 kvcache 的顯存進行統一管理。

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

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

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

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

Paged Attention評測效果

圖片來自[4] vLLM: Easy, Fast, and Cheap LLM Serving with PagedAttention

通過高效的內存管理，Paged Attention減少了內存浪費，提高了 GPU 的利用率，使模型的推理吞吐量比傳統方法提升了數倍。例如，與 HuggingFace Transformers 相比，吞吐量可提升至 24 倍；與 HuggingFace TGI 相比，提升可達 3.5 倍。此外，它還降低了內存開銷，支持更復雜的采樣方法，使 LLM 服務變得更快、更經濟。

目前VLLM與SGLang等推理引擎默認支持Paged Attention開啟，所以你使用這些推理引擎部署大模型，系統會自動支持。

四、緩存之前請求的計算結果，減少重復計算—Radix Attention

雖然 Paged Attention 成功解決了顯存碎片問題，并顯著提升了系統吞吐量，但在大模型推理中，還有一個常見場景具備較大性能優化空間。

實際應用中，我們往往需要多次給大模型發送請求，而這些請求的Prompt中有很大一部分的內容是完全相同的。如下所示：

圖片來自[5] Fast and Expressive LLM Inference with RadixAttention and SGLang

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

上圖中可共享部分場景包括少量示例學習、自我一致性中的問題、多輪對話中的聊天歷史，以及思維樹中的搜索歷史。在這些場景中，每次請求都會重復計算這些Prompt中可共享的部分，這些會造成大量的計算資源浪費。

那么，有沒有辦法將這些重復部分的計算結果(KV Cache)緩存起來，下次請求時直接使用呢？為此，SGLang 提出了一種優秀的算法—— Radix Attention。

RadixAttention 是一種新技術，用于在大語言模型的推理過程中優化 KV 緩存的重用。其核心在于利用基數樹（Radix Tree）來高效管理和重用不同請求之間共享的前綴，從而減少重復計算和內存占用。也就是說，當多個請求共享相同的前綴（例如系統提示 "You are a helpful assistant"）時，RadixAttention 可以重用該前綴對應的 KV 緩存，避免重復計算。

下圖中的例子展示了 RadixAttention 在九個時間點上的基數樹動態演變過程，以下是具體步驟的解釋：

圖片來自[5] Fast and Expressive LLM Inference with RadixAttention and SGLang

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

那Radix Attention帶來的性能提升如何呢？我們針對SGLang推出的Radix Attention與VLLM (v0.5.0)進行了對比評測。同時由于Radix Attention可以復用不同請求的上下文，這與我們的日常業務使用比較吻合，取得了不錯的評測結果，Radix Attention充分利用不同請求之間的共享前綴，其耗時比VLLM(v0.5.0)快30%，吞吐是VLLM(v0.5.0)的1.5倍。

下面為SGLang給出的Radix Attention性能對比效果，與當前系統相比，SGLang吞吐提升了5倍以上。

圖片來自[5] Fast and Expressive LLM Inference with RadixAttention and SGLang

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

五、請求分塊處理，避免單個請求卡頓 —— Chunked Prefill

在將大模型應用于生產環境時，我們有時會遇到一種奇怪的現象：某個請求的響應時間（RT）異常長，甚至出現卡頓，而系統的平均響應時間卻依然正常。這是什么原因導致的呢？又如何解決呢？

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

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

在實際應用中，多個請求往往會同時進行推理，因此可能出現不同請求的階段交叉運行。例如，如果請求 req3 的 prefill 階段處理了一個非常長的 prompt，那么它就會占用大量的 GPU 資源；而如果此時 req13的 prefill 階段與請求 req1的 decode 階段并行運行，就會導致 req1的 decode 階段響應速度明顯變慢，甚至出現卡頓現象。

圖片來自 Taming Throughput-Latency Tradeoff in LLM Inference with Sarathi-Serve vLLM @ Fourth Meetup (Public) ，較大的prompt請求與decode階段請求并行調度，算力資源爭搶，會顯著影響decode階段。

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

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

如下圖所示，vllm 通過啟用 chunked prefill 功能，顯著降低了系統的最大響應時間（max RT）。

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

在 vllm 的最新版本中，chunked prefill 已默認開啟。

六、縮短輸出長度，顯著提升性能

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

因此，如果我們能夠在 decode 階段盡量減少生成的 token 總長度，就能顯著提高整體的響應時間（RT）。具體來說，如果每生成一個 token 耗時 5 毫秒，減少 5 個 token 的輸出，就能減少 25 毫秒的總響應時間。對于非流式調用的大模型來說，這種改進會帶來顯著效果。例如，如果大模型只需進行簡單的分類或識別任務，那么僅需輸出結果即可，其他無關信息完全不需要生成。

那么如何縮短大模型的輸出長度呢？

a.限制最大輸出長度

首先，可以通過設置系統參數來限制大模型的最大輸出長度。如果你通過 OpenAI 接口調用大模型，在輸入參數中有一個叫做 max tokens 的設置項。你可以調整該參數，限制大模型的最大輸出長度。這樣一來，可以避免大模型產生過長的輸出，甚至防止無限循環的情況。一個示例代碼如下：

b.通過 Prompt 限制輸出

另外，可以通過優化 prompt 來引導大模型產生更短的輸出。例如，在 prompt 中加上類似“請直接輸出結果”或“請盡可能簡短輸出結果”的提示語，可以有效減少無關內容的輸出。

c.微調大模型

如果條件允許，微調大模型也是一種有效的方法。通過微調，可以讓大模型在滿足需求的前提下盡量縮短輸出。微調的過程中，首先可以通過 prompt 調整輸出長度，制造大量數據后，再對大模型進行訓練。這樣一來，不僅輸入的內容被優化，輸出的長度也能有效縮短，達到更好的效果。

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

在某些場景下，出于模型效果考慮無法對大模型進行量化，但對響應時間（RT）有非常高的要求。這時，嘗試 多卡推理 可以帶來立竿見影的效果，通常能夠將 RT 縮短至原來的 1/3 或 1/2。

   以下是我們針對 單卡 與 雙卡 推理性能的對比測試結果：

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

那為什么多卡可以提升大模型的推理速度呢？主要原因多卡推理的優化是通過 tensor parallelism（張量并行）實現的。

假設你將 tensor parallel 設置為 2，意味著使用兩張 GPU 來加速推理。在模型加載時，推理引擎會將大模型的 attention 參數的數量分為兩組，分別加載到每張 GPU 上。然后，在推理過程中，兩個 GPU 會并行計算注意力，最后再將結果聚合合并。

想象一下，你有一本非常厚的書，你想一次性復印整本書，但是你的復印機一次只能復印幾頁。這時，你可以把這本書分成幾個部分，每個部分分別復印，最后再把所有復印好的部分按順序拼接起來，這樣就完成了整本書的復印。

在張量并行中，我們要處理的大模型就像是那本厚書，而GPU則像是復印機。因為單個GPU無法一次處理整個大模型，我們就需要把模型（在這個例子中是權重張量）分成幾個部分，讓不同的GPU分別處理（相當于復印書的不同部分）。在處理輸入數據時，就像是把書的每一頁分別復印，然后再把復印好的各個部分拼接起來，形成完整的輸出結果。

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

1.vllm配置多卡推理

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

圖片來自[6] vllm Documentation

2.SGLang配置多卡推理

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

八、小模型推理+大模型驗證 —— 預測解碼 (Speculative Decoding)

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

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

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

以下為我們針對70b模型所做的實驗效果。

可見預測解碼在一定的場景下可以提升大模型的推理速度。

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

關于預測解碼，想深入了解的同學可以參考vllm的這篇文檔。[8] How Speculative Decoding Boosts vLLM Performance by up to 2.8x

下面我們介紹下如何在vllm中配置預測解碼。

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

b.使用n-gram的方式

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

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

a.如何下載Deepseek-r1

這次Deepseek發布了一系列模型，如下：

原始模型包括Deepseek-r1-zero與Deepseek-r1，其中Deepseek-r1是官方推薦的經過多階段訓練的最優模型。但是Deepseek-r1有671B大小的參數，部署起來至少需要2*8H20GPU，比較耗費資源。所以deepseek團隊又基于Deepseek-r1蒸餾出了一系列小的模型，其中效果不錯比如DeepSeek-R1-Distill-Qwen-32B，單卡H20可以運行啟動。

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

b.準備部署環境

我們嘗試使用SGLang這個大模型推理引擎部署Deepseek-r1。以下為我們的部署軟硬件環境準備。

部署Deepseek-r1

準備好SGLang鏡像，deepseek-r1模型，GPU后，可以按照如下命令啟動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

這里使用的是多機多卡部署，部署后使用Openai格式請求發送到node1上即可。

十、總結

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

后續我們將會持續關注大模型推理性能提升方面的最新技術，驗證并及時分享給大家。

參考文獻

[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

本文轉載自得物技術，作者：menglinggong