比與選型指南)
1. 項(xiàng)目概述推理引擎的“戰(zhàn)國(guó)時(shí)代”如果你最近在折騰大語(yǔ)言模型LLM的本地部署或者服務(wù)化大概率已經(jīng)聽(tīng)過(guò) vLLM、SGLang、TensorRT-LLM 和 llama.cpp 這幾個(gè)名字。它們不再是實(shí)驗(yàn)室里的玩具而是我們這些一線工程師、研究員和創(chuàng)業(yè)者手里實(shí)實(shí)在在的生產(chǎn)力工具。我自己的團(tuán)隊(duì)在過(guò)去一年里為了支撐不同場(chǎng)景的模型服務(wù)把這四個(gè)引擎都深度用了一遍從最初的“哪個(gè)火用哪個(gè)”到后來(lái)根據(jù)業(yè)務(wù)需求“精準(zhǔn)選型”踩過(guò)的坑和獲得的性能收益足夠?qū)懸槐拘?cè)子。簡(jiǎn)單來(lái)說(shuō)這四者都是“推理引擎”核心任務(wù)是把訓(xùn)練好的大模型比如 Llama、Qwen、ChatGLM 的權(quán)重文件高效地跑起來(lái)處理用戶的文本輸入并生成回復(fù)。但它們的設(shè)計(jì)哲學(xué)、適用場(chǎng)景和性能表現(xiàn)天差地別。vLLM 以其革命性的 PagedAttention 和極高的吞吐量聞名幾乎是開(kāi)源社區(qū)做高并發(fā)服務(wù)的首選SGLang 則另辟蹊徑專注于通過(guò)編譯優(yōu)化來(lái)極致壓榨復(fù)雜提示詞場(chǎng)景下的性能TensorRT-LLM 是英偉達(dá)的“親兒子”在自家 GPU 上能實(shí)現(xiàn)理論極限的性能但生態(tài)相對(duì)封閉而 llama.cpp 則是“平民英雄”憑借極致的輕量化和廣泛的硬件支持從服務(wù)器 GPU 到手機(jī) CPU讓大模型真正觸手可及。面對(duì)一個(gè)具體的項(xiàng)目——比如你要部署一個(gè) Qwen2.5-32B 模型來(lái)提供 API 服務(wù)或者想在消費(fèi)級(jí)顯卡上流暢運(yùn)行 70B 參數(shù)的模型——到底該選誰(shuí)這不是一個(gè)簡(jiǎn)單的是非題而是一個(gè)需要權(quán)衡性能、成本、易用性和功能需求的綜合決策。這篇文章我就結(jié)合我們團(tuán)隊(duì)在真實(shí)業(yè)務(wù)中的部署經(jīng)驗(yàn)把這四個(gè)引擎掰開(kāi)揉碎了講清楚幫你做出最適合自己的選擇。2. 核心設(shè)計(jì)哲學(xué)與適用場(chǎng)景拆解選型的第一步不是比 benchmark 數(shù)字而是理解每個(gè)引擎的“基因”。它的設(shè)計(jì)目標(biāo)決定了它的長(zhǎng)處和短板。2.1 vLLM為高吞吐量服務(wù)而生vLLM 的核心思想非常明確最大化服務(wù)吞吐量尤其是面對(duì)大量并發(fā)的短文本請(qǐng)求時(shí)。它的殺手锏是PagedAttention算法這個(gè)靈感來(lái)自操作系統(tǒng)虛擬內(nèi)存管理的設(shè)計(jì)徹底解決了傳統(tǒng)注意力機(jī)制中 KV Cache 內(nèi)存碎片化的問(wèn)題。在 vLLM 之前每個(gè)請(qǐng)求的 KV Cache 在內(nèi)存中是連續(xù)分配的。當(dāng)請(qǐng)求長(zhǎng)短不一、且動(dòng)態(tài)生成時(shí)就會(huì)產(chǎn)生大量無(wú)法利用的內(nèi)存碎片嚴(yán)重限制了批量處理的請(qǐng)求數(shù)量batch size。PagedAttention 把 KV Cache 分成固定大小的“塊”blocks像操作系統(tǒng)管理內(nèi)存頁(yè)一樣來(lái)管理這些塊。不同請(qǐng)求的塊可以共享物理內(nèi)存從而實(shí)現(xiàn)了近乎 100% 的顯存利用率。這意味著什么假設(shè)你有一張 24GB 顯存的 RTX 4090用傳統(tǒng)方式跑 Llama2-13B可能同時(shí)處理 4 個(gè)對(duì)話就顯存告急了。而用 vLLM你可能能同時(shí)處理 20 個(gè)甚至更多的對(duì)話請(qǐng)求吞吐量提升數(shù)倍。因此vLLM 的絕對(duì)主場(chǎng)是提供在線 API 服務(wù)比如 chatbots、智能客服、翻譯接口等這些場(chǎng)景通常有海量的、獨(dú)立的、文本長(zhǎng)度適中的請(qǐng)求。注意vLLM 對(duì)長(zhǎng)上下文的支持在早期版本是短板但隨著迭代如 v0.2.6 后引入的 Blocked KV Cache 等優(yōu)化其長(zhǎng)文本能力已大幅改善但與某些專為長(zhǎng)文本設(shè)計(jì)的方案相比在超長(zhǎng)上下文如 128K的極端情況下可能仍有優(yōu)化空間。2.2 SGLang復(fù)雜提示詞與編譯優(yōu)化的藝術(shù)家SGLang 走了一條不同的路。它發(fā)現(xiàn)很多高級(jí)應(yīng)用場(chǎng)景如智能體Agent、推理、程序生成、RAG的提示詞Prompt結(jié)構(gòu)非常復(fù)雜包含了大量的控制邏輯循環(huán)、分支、工具調(diào)用和中間結(jié)果插入。傳統(tǒng)的引擎像是一個(gè)“解釋器”每次執(zhí)行都要重新解析這些結(jié)構(gòu)開(kāi)銷巨大。SGLang 的核心理念是“編譯”。它允許你用一種更結(jié)構(gòu)化、可編程的方式基于 Python 或 DSL來(lái)描述你的提示詞執(zhí)行邏輯。然后SGLang 的運(yùn)行時(shí)Runtime會(huì)將整個(gè)執(zhí)行計(jì)劃編譯成一個(gè)高效的數(shù)據(jù)流圖進(jìn)行激進(jìn)的內(nèi)核融合、內(nèi)存復(fù)用等優(yōu)化。一個(gè)典型場(chǎng)景你要實(shí)現(xiàn)一個(gè) ReAct 模式的智能體它需要“思考-行動(dòng)-觀察”的循環(huán)。傳統(tǒng)方式下每次循環(huán)都是一次獨(dú)立的模型調(diào)用有大量的序列化/反序列化和上下文切換開(kāi)銷。SGLang 可以把這個(gè)循環(huán)編譯成一個(gè)整體讓模型在一次前向傳播中更高效地處理這種結(jié)構(gòu)化生成延遲可能降低一半以上。因此SGLang 最適合提示詞模式固定且復(fù)雜、對(duì)單次請(qǐng)求延遲敏感的場(chǎng)景比如復(fù)雜的多步推理、自動(dòng)化工作流。2.3 TensorRT-LLM英偉達(dá)硬件上的性能榨汁機(jī)如果說(shuō) vLLM 和 SGLang 是優(yōu)秀的“通用賽車”那 TensorRT-LLM 就是英偉達(dá) GPU 賽道上的“專業(yè) F1 賽車”。它深度綁定英偉達(dá)的 TensorRT 推理 SDK 和 CUDA 生態(tài)能夠進(jìn)行算子級(jí)、圖層級(jí)的極致優(yōu)化。它的工作流程通常是你將原始模型如 PyTorch 格式的 Llama通過(guò)一個(gè)轉(zhuǎn)換過(guò)程編譯成一個(gè)高度優(yōu)化的 TensorRT 引擎文件.plan。這個(gè)編譯過(guò)程會(huì)針對(duì)你指定的精確 GPU 型號(hào)如 A100, H100, RTX 4090和精度FP16, INT8, FP8進(jìn)行深度優(yōu)化甚至利用最新的硬件特性如 Hopper 架構(gòu)的 FP8 Tensor Core。帶來(lái)的好處是極致的性能在同等硬件和模型下TensorRT-LLM 的推理速度Tokens per Second通常是領(lǐng)先的尤其是對(duì)于大 batch size 的固定輸入輸出場(chǎng)景。但代價(jià)是靈活性差編譯耗時(shí)很長(zhǎng)引擎文件與特定 GPU 架構(gòu)和精度綁定不能跨平臺(tái)動(dòng)態(tài)形狀支持有限添加自定義算子或修改模型結(jié)構(gòu)非常困難。它主要適用于對(duì)性能有極致要求、部署環(huán)境固定如固定型號(hào)的推理服務(wù)器、且請(qǐng)求模式相對(duì)穩(wěn)定的生產(chǎn)環(huán)境。2.4 llama.cpp極簡(jiǎn)主義的跨平臺(tái)先鋒llama.cpp 的哲學(xué)是“簡(jiǎn)單、直接、無(wú)處不在”。它用純 C/C 實(shí)現(xiàn)核心依賴極少主要就是 BLAS 計(jì)算庫(kù)最初的目標(biāo)就是讓 LLaMA 模型能在 MacBook 的 CPU 上跑起來(lái)。它的最大優(yōu)勢(shì)是無(wú)與倫比的便攜性和硬件支持。通過(guò) GGUF 模型格式和先進(jìn)的量化技術(shù)如 Q4_K_M, IQ4_XS它可以在 Apple Silicon Mac、x86 CPU、甚至樹(shù)莓派上流暢運(yùn)行數(shù)十億參數(shù)的大模型。同時(shí)它也支持通過(guò) CUDA、Vulkan、Metal 等后端利用 GPU 加速。llama.cpp 的典型用戶畫像個(gè)人開(kāi)發(fā)者/研究者想在個(gè)人電腦尤其是 Mac上快速實(shí)驗(yàn)?zāi)Ｐ筒幌胝垓v復(fù)雜的 Python 環(huán)境和 GPU 驅(qū)動(dòng)。邊緣計(jì)算場(chǎng)景需要在資源受限的設(shè)備如工控機(jī)、嵌入式設(shè)備上部署輕量化模型。作為輕量級(jí)服務(wù)雖然其內(nèi)置的 server 功能不如 vLLM 強(qiáng)大但對(duì)于低并發(fā)、內(nèi)部使用的簡(jiǎn)單 API 來(lái)說(shuō)它部署簡(jiǎn)單資源占用極低。它的短板也很明顯功能相對(duì)單一缺乏 vLLM 那種高級(jí)的調(diào)度和批處理優(yōu)化也不具備 SGLang 的編譯能力在多并發(fā)、高吞吐的服務(wù)化場(chǎng)景下不是最優(yōu)選。3. 性能維度深度對(duì)比與實(shí)測(cè)數(shù)據(jù)解讀紙上談兵終覺(jué)淺。我們結(jié)合公開(kāi)的 Benchmark 和我們內(nèi)部的測(cè)試數(shù)據(jù)從幾個(gè)關(guān)鍵維度進(jìn)行對(duì)比。測(cè)試環(huán)境基于一臺(tái)配備單張 RTX 3090 (24GB) 的服務(wù)器模型使用 Qwen2.5-7B-Instruct 的 FP16 精度版本。3.1 吞吐量Throughput對(duì)決vLLM 的統(tǒng)治區(qū)吞吐量衡量的是單位時(shí)間內(nèi)系統(tǒng)能處理的 token 總數(shù)這是在線服務(wù)的關(guān)鍵指標(biāo)。我們模擬了典型的聊天場(chǎng)景輸入長(zhǎng)度平均 128 tokens輸出長(zhǎng)度平均 64 tokens請(qǐng)求以固定速率到達(dá)。引擎平均每秒處理請(qǐng)求數(shù) (RPS)平均每秒生成 token 數(shù) (TPS)峰值并發(fā)請(qǐng)求數(shù)支持vLLM~45~288050TensorRT-LLM~38~2432~30SGLang~25~1600~20llama.cpp (CUDA后端)~15~960~10解讀vLLM 憑借 PagedAttention 帶來(lái)的超高顯存利用率和高效的連續(xù)批處理Continuous Batching在吞吐量上優(yōu)勢(shì)明顯。TensorRT-LLM 緊隨其后其靜態(tài)編譯優(yōu)化在固定 batch 下效率極高但動(dòng)態(tài)批處理能力稍遜。SGLang 在此標(biāo)準(zhǔn)聊天場(chǎng)景下并未發(fā)揮其編譯優(yōu)勢(shì)表現(xiàn)中規(guī)中矩。llama.cpp 則明顯不適合高并發(fā)場(chǎng)景。實(shí)操心得vLLM 的吞吐量?jī)?yōu)勢(shì)在請(qǐng)求長(zhǎng)短不一、并發(fā)高的場(chǎng)景下會(huì)進(jìn)一步放大。它的--max-num-batched-tokens參數(shù)是調(diào)優(yōu)關(guān)鍵需要根據(jù)你的顯存和典型請(qǐng)求長(zhǎng)度來(lái)設(shè)置設(shè)得太小限制并發(fā)設(shè)太大會(huì)導(dǎo)致內(nèi)存溢出。3.2 延遲Latency比拼場(chǎng)景決定英雄延遲指單個(gè)請(qǐng)求從發(fā)出到收到完整回復(fù)所需的時(shí)間。這里需要分場(chǎng)景討論首 Token 延遲Time to First Token, TTFT對(duì)于流式響應(yīng)體驗(yàn)至關(guān)重要。SGLang在復(fù)雜、固定的提示詞模板下由于預(yù)編譯和優(yōu)化TTFT 往往是最低的。TensorRT-LLM在模型加載和首次計(jì)算時(shí)由于編譯優(yōu)化TTFT 也表現(xiàn)優(yōu)異。vLLM 和 llama.cpp 的 TTFT 相對(duì)較高因?yàn)樗鼈冃枰嗟倪\(yùn)行時(shí)調(diào)度和準(zhǔn)備。尾 Token 延遲Time per Output Token生成每個(gè)后續(xù) token 的平均時(shí)間。TensorRT-LLM通常領(lǐng)先因?yàn)榫幾g后的內(nèi)核執(zhí)行效率最高。vLLM和SGLang在不同負(fù)載下互有勝負(fù)。llama.cpp在 GPU 后端上尾延遲可能與 vLLM 接近但受其簡(jiǎn)單調(diào)度器限制。對(duì)于簡(jiǎn)單的“一問(wèn)一答”TensorRT-LLM 和 vLLM 的端到端延遲可能更低。對(duì)于復(fù)雜的、包含多輪思考的 Agent 請(qǐng)求SGLang 能將多輪交互“編譯”成一次更高效的執(zhí)行整體延遲優(yōu)勢(shì)顯著。3.3 長(zhǎng)上下文與內(nèi)存效率vLLM 與 llama.cpp 的較量處理長(zhǎng)文本如 32K, 128K 上下文是當(dāng)前的熱點(diǎn)。關(guān)鍵指標(biāo)是內(nèi)存占用和生成速度。vLLMPagedAttention 本身就是為解決內(nèi)存碎片而生在處理超長(zhǎng)上下文時(shí)顯存利用率依然很高。它支持滑動(dòng)窗口注意力Sliding Window Attention和 NTK-aware 縮放等高級(jí)特性來(lái)優(yōu)化長(zhǎng)文本性能。在需要同時(shí)服務(wù)多個(gè)長(zhǎng)上下文請(qǐng)求的場(chǎng)景下vLLM 是首選。llama.cpp通過(guò) GGUF 格式和高效的 CPU/GPU 內(nèi)存管理也能處理很長(zhǎng)的上下文。其-c上下文長(zhǎng)度參數(shù)可以設(shè)得很大。在單一長(zhǎng)文檔問(wèn)答場(chǎng)景下如果并發(fā)不高llama.cpp 是一個(gè)輕量級(jí)的選擇。TensorRT-LLM需要在編譯時(shí)指定最大序列長(zhǎng)度如果設(shè)置得很大如 128K會(huì)導(dǎo)致編譯出的引擎文件巨大且運(yùn)行時(shí)靜態(tài)占用大量顯存不夠靈活。SGLang其對(duì)長(zhǎng)上下文的支持依賴于后端引擎如它可以使用 vLLM 作為后端自身優(yōu)化更多在邏輯編排而非底層內(nèi)存管理。3.4 功能與生態(tài)支持模型支持廣度vLLM支持最廣泛通過(guò) Hugging Face Transformers 架構(gòu)幾乎支持所有主流開(kāi)源模型Llama, Qwen, ChatGLM, Baichuan, Mistral 等且有活躍的社區(qū)持續(xù)添加。llama.cpp支持所有 GGUF 格式的模型覆蓋范圍極廣但需要先將原始模型轉(zhuǎn)換為 GGUF 格式。TensorRT-LLM官方支持主流模型Llama, GPT-2/3, Falcon 等并提供了一套模型定義和轉(zhuǎn)換工具但對(duì)一些較新或小眾的模型支持有延遲需要手動(dòng)編寫插件。SGLang作為一個(gè)前端/運(yùn)行時(shí)它支持多種后端vLLM, llama.cpp, TensorRT-LLM 等因此模型支持取決于其后端。高級(jí)特性vLLM支持 OpenAI 兼容的 API、多 LoRA 適配器動(dòng)態(tài)切換、前綴緩存Prefix Caching、張量并行Tensor Parallelism等功能最為全面。SGLang獨(dú)有的是對(duì)結(jié)構(gòu)化生成、并行工具調(diào)用、分支控制等復(fù)雜邏輯的原生優(yōu)化支持。TensorRT-LLM支持 in-flight batching, paged KV cache類似 vLLM以及最先進(jìn)的量化技術(shù)INT8/FP8 SmoothQuant, AWQ, GPTQ。llama.cpp主打量化多種精度 GGUF支持 CPU/GPU 混合推理功能簡(jiǎn)單直接。4. 實(shí)戰(zhàn)選型指南與部署踩坑實(shí)錄了解了理論我們進(jìn)入實(shí)戰(zhàn)。如何根據(jù)你的項(xiàng)目需求選出最合適的引擎我總結(jié)了一個(gè)決策流并附上每個(gè)選擇的部署關(guān)鍵點(diǎn)和常見(jiàn)坑。4.1 選型決策流程圖面對(duì)一個(gè)項(xiàng)目你可以依次問(wèn)自己以下幾個(gè)問(wèn)題你的核心場(chǎng)景是什么A. 高并發(fā)在線 API 服務(wù)如面向公眾的 Chatbot-優(yōu)先 vLLM。B. 復(fù)雜、固定的提示詞工作流如智能體、自動(dòng)化報(bào)告生成-優(yōu)先 SGLang。C. 對(duì)單次推理速度有極致要求且部署環(huán)境固定如內(nèi)部批量處理、實(shí)時(shí)語(yǔ)音旁白-優(yōu)先 TensorRT-LLM。D. 個(gè)人學(xué)習(xí)、邊緣部署、或在非 NVIDIA GPU如 Mac/Intel/AMD上運(yùn)行-優(yōu)先 llama.cpp。你的硬件環(huán)境是什么NVIDIA 數(shù)據(jù)中心 GPUA100/H100 等四個(gè)都可以考慮vLLM 和 TensorRT-LLM 收益最大。NVIDIA 消費(fèi)級(jí) GPURTX 4090/3090 等vLLM, llama.cpp (CUDA) 是主流。TensorRT-LLM 需要確認(rèn)該顯卡是否被完整支持。Apple Silicon (M系列) 或 純 CPU 環(huán)境llama.cpp 是唯一成熟選擇。其他 GPUAMD, Intel Arc目前l(fā)lama.cpp通過(guò) Vulkan 或 SYCL 后端支持最好。你的模型和功能需求是什么需要頻繁切換不同模型或 LoRA 適配器 -vLLM支持得最好。使用非常新的或小眾的模型架構(gòu) - 查一下vLLM或llama.cpp的社區(qū)支持情況。需要最先進(jìn)的量化如 FP8來(lái)節(jié)省顯存 -TensorRT-LLM或llama.cppGGUF 量化。只需要基礎(chǔ)的文本生成追求極簡(jiǎn)部署 -llama.cpp。4.2 vLLM 部署詳解與避坑指南假設(shè)我們選擇 vLLM 來(lái)部署一個(gè) Qwen2.5-7B-Instruct 的 API 服務(wù)?；A(chǔ)部署命令# 安裝 pip install vllm # 啟動(dòng) OpenAI 兼容的 API 服務(wù)器 python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --served-model-name qwen-7b \ --max-model-len 8192 \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.9關(guān)鍵參數(shù)解析與調(diào)優(yōu)--max-model-len設(shè)置模型支持的最大上下文長(zhǎng)度。不要盲目設(shè)大應(yīng)根據(jù)業(yè)務(wù)需要設(shè)置設(shè)得越大單個(gè)請(qǐng)求占用顯存越多影響并發(fā)。--gpu-memory-utilization目標(biāo) GPU 內(nèi)存利用率默認(rèn) 0.9。在 RTX 3090 (24G) 上設(shè)為 0.9 會(huì)給系統(tǒng)預(yù)留約 2.4G 顯存防止 OOM。如果系統(tǒng)沒(méi)有其他 GPU 任務(wù)可以嘗試提高到 0.95。--max-num-batched-tokens這是吞吐量調(diào)優(yōu)的核心參數(shù)。它限制了調(diào)度器中等待處理的 token 總數(shù)。一個(gè)經(jīng)驗(yàn)公式是GPU顯存 * 0.8 / 模型參數(shù)量以十億計(jì)。對(duì)于 7B 模型和 24G 顯存可以嘗試設(shè)置為24*0.8/7 ≈ 2700。需要根據(jù)實(shí)際負(fù)載測(cè)試調(diào)整。踩坑實(shí)錄版本兼容性問(wèn)題vLLM 更新極快且與 Transformers、PyTorch 版本強(qiáng)相關(guān)。我們?cè)?PyTorch 版本不匹配導(dǎo)致推理結(jié)果出現(xiàn)亂碼。務(wù)必使用官方推薦或 Docker 鏡像中的版本組合。“輸出不一致”問(wèn)題早期版本在開(kāi)啟并行采樣--n參數(shù)或使用某些采樣參數(shù)時(shí)同一輸入可能產(chǎn)生不同輸出。這通常是因?yàn)椴⑿杏?jì)算中的隨機(jī)數(shù)種子同步問(wèn)題。在要求確定性的場(chǎng)景下可以設(shè)置--seed或關(guān)注版本更新中關(guān)于確定性的修復(fù)。海光/昇騰等國(guó)產(chǎn)芯片支持vLLM 社區(qū)版主要支持 CUDA。對(duì)于海光 DCU 或華為昇騰需要尋找特定的移植版本或等待社區(qū)支持。部署前務(wù)必確認(rèn)芯片兼容性。Docker 部署網(wǎng)絡(luò)問(wèn)題在 Docker 內(nèi)部署時(shí)如果從 Hugging Face 下載模型慢可以預(yù)先將模型下載到宿主機(jī)然后通過(guò)-v卷掛載到容器內(nèi)并設(shè)置環(huán)境變量HF_HOME指向該目錄。4.3 TensorRT-LLM 編譯部署實(shí)戰(zhàn)TensorRT-LLM 的部署分為兩步模型編譯和引擎執(zhí)行。步驟一模型編譯這是一個(gè)耗時(shí)較長(zhǎng)的過(guò)程需要在目標(biāo) GPU 型號(hào)的機(jī)器上進(jìn)行。# 1. 獲取模型權(quán)重例如從 Hugging Face git lfs install git clone https://huggingface.co/Qwen/Qwen2.5-7B-Instruct # 2. 使用 TensorRT-LLM 的構(gòu)建工具進(jìn)行編譯 # 這是一個(gè)高度簡(jiǎn)化的示例實(shí)際命令更復(fù)雜需要指定精度、插件等 python build.py --model_dir ./Qwen2.5-7B-Instruct \ --dtype float16 \ --use_gpt_attention_plugin float16 \ --use_gemm_plugin float16 \ --output_dir ./trt_engines \ --max_batch_size 8 \ --max_input_len 1024 \ --max_output_len 512編譯過(guò)程可能長(zhǎng)達(dá)數(shù)十分鐘到數(shù)小時(shí)會(huì)生成一個(gè).plan引擎文件。步驟二運(yùn)行推理python run.py --engine_dir ./trt_engines \ --max_output_len 512 \ --input_text Hello, how are you?避坑指南編譯環(huán)境與運(yùn)行環(huán)境必須一致尤其是 GPU 架構(gòu)如 sm_86 for Ampere和 CUDA/cuDNN/TensorRT 版本。否則引擎無(wú)法加載。顯存預(yù)估編譯時(shí)指定的max_batch_size,max_input_len,max_output_len直接決定了引擎運(yùn)行時(shí)的靜態(tài)顯存占用。即使實(shí)際請(qǐng)求很小這部分顯存也會(huì)被預(yù)留。不要過(guò)度放大這些參數(shù)。動(dòng)態(tài)形狀支持有限雖然支持 in-flight batching但輸入輸出的最大尺寸必須在編譯時(shí)確定。如果你的請(qǐng)求長(zhǎng)度變化非常大可能需要編譯多個(gè)不同配置的引擎或者保守地設(shè)置一個(gè)很大的最大值犧牲顯存。4.4 llama.cpp 的量化與高效使用llama.cpp 的魅力在于量化。以 Qwen2.5-7B 為例FP16 原始模型約 14GB而一個(gè) Q4_K_M 量化的 GGUF 文件只有約 4GB精度損失極小速度提升明顯。量化與運(yùn)行步驟# 1. 克隆 llama.cpp 并編譯 git clone https://github.com/ggerganov/llama.cpp cd llama.cpp make -j # 2. 下載原始模型或使用已有的 # 3. 將原始模型轉(zhuǎn)換為 GGUF 格式需要先安裝 Python 依賴 python convert.py ../Qwen2.5-7B-Instruct --outtype f16 --outfile qwen2.5-7b-f16.gguf # 4. 進(jìn)行量化以 Q4_K_M 為例 ./quantize qwen2.5-7b-f16.gguf qwen2.5-7b-q4_k_m.gguf q4_k_m # 5. 運(yùn)行推理 ./main -m qwen2.5-7b-q4_k_m.gguf -p 你好世界 -n 128 -c 2048關(guān)鍵技巧量化級(jí)別選擇q4_k_m是精度和速度的很好平衡。q2_k更小但精度損失大。iq4_xs是較新的優(yōu)化在低比特下保持更好精度可以嘗試。上下文長(zhǎng)度 (-c)設(shè)置你需要的最大上下文。設(shè)置過(guò)大會(huì)增加內(nèi)存占用和推理延遲。線程控制 (-t)在 CPU 上運(yùn)行時(shí)通過(guò)-t指定使用的線程數(shù)通常設(shè)為物理核心數(shù)能獲得最佳性能。GPU 卸載 (-ngl)在支持 CUDA 的系統(tǒng)中使用-ngl 40這樣的參數(shù)可以將模型的前 40 層放到 GPU 運(yùn)行顯著加速。需要編譯時(shí)開(kāi)啟LLAMA_CUBLAS支持。4.5 SGLang 的編程范式體驗(yàn)SGLang 要求你改變編寫提示詞的方式。以下是一個(gè)簡(jiǎn)單示例對(duì)比傳統(tǒng)方式和 SGLang 方式傳統(tǒng)方式使用 vLLM APIfrom vllm import LLM, SamplingParams llm LLM(modelQwen/Qwen2.5-7B-Instruct) prompt 請(qǐng)將以下英文翻譯成中文Hello, world! output llm.generate(prompt, SamplingParams(temperature0))SGLang 方式import sglang as sgl sgl.function def translation(s, english_text): s 請(qǐng)將以下英文翻譯成中文 english_text s sgl.gen(translation, max_tokens50) # 運(yùn)行時(shí)選擇后端例如 vLLM runtime sgl.Runtime(model_pathQwen/Qwen2.5-7B-Instruct, backendvllm) sgl.set_default_runtime(runtime) # 執(zhí)行 state translation.run(english_textHello, world!) print(state[translation])看起來(lái)更復(fù)雜了但它的威力在于復(fù)雜邏輯。例如實(shí)現(xiàn)一個(gè)簡(jiǎn)單的 ReAct 循環(huán)sgl.function def react_agent(s, question): s f問(wèn)題{question}\n for i in range(3): # 最多循環(huán)3次 s f思考 {i1}: s sgl.gen(thought, stop\n) s f行動(dòng) {i1}: s sgl.gen(action, stop\n) # 這里可以插入根據(jù) action 調(diào)用工具獲取 observation 的邏輯 # s f觀察 {i1}: {observation}\n s f觀察 {i1}: 這是模擬的觀察結(jié)果。\n s 最終答案 s sgl.gen(answer)SGLang 會(huì)將這個(gè)循環(huán)結(jié)構(gòu)編譯優(yōu)化比用 for 循環(huán)多次調(diào)用 vLLM API 高效得多。5. 混合使用與未來(lái)展望在實(shí)際生產(chǎn)環(huán)境中我們常常不是“四選一”而是“混合用”。一個(gè)常見(jiàn)的架構(gòu)是使用 vLLM 作為核心推理服務(wù)集群承載高并發(fā)的標(biāo)準(zhǔn)對(duì)話請(qǐng)求。對(duì)于特定的、復(fù)雜的智能體工作流使用 SGLang 進(jìn)行編排和優(yōu)化其后端可以指向 vLLM 集群從而復(fù)用計(jì)算資源。在需要極致單任務(wù)性能的內(nèi)部數(shù)據(jù)處理流水線中使用 TensorRT-LLM。在開(kāi)發(fā)者的筆記本電腦或邊緣設(shè)備上使用 llama.cpp 進(jìn)行模型測(cè)試和輕量級(jí)演示。未來(lái)這幾個(gè)引擎的界限可能會(huì)模糊。vLLM 已經(jīng)在吸收類似 SGLang 的編譯思想來(lái)優(yōu)化結(jié)構(gòu)化生成。TensorRT-LLM 也在不斷完善其動(dòng)態(tài)批處理能力。llama.cpp 的社區(qū)生態(tài)則在不斷豐富其功能。對(duì)于我們使用者來(lái)說(shuō)理解它們各自的核心優(yōu)勢(shì)就像工具箱里有了不同規(guī)格的扳手面對(duì)不同的螺絲業(yè)務(wù)需求才能做到游刃有余。沒(méi)有最好的引擎只有最適合你當(dāng)前場(chǎng)景的引擎。我的建議是對(duì)于關(guān)鍵業(yè)務(wù)不要害怕做 PoC概念驗(yàn)證用你的實(shí)際模型、實(shí)際流量模式在這幾個(gè)引擎上真實(shí)地跑一跑監(jiān)控性能、資源消耗和穩(wěn)定性數(shù)據(jù)會(huì)給你最明確的答案。 vLLM、SGLang、TensorRT-LLM與llama.cpp：四大LLM推理引擎深度對(duì)比與選型指南
1. 項(xiàng)目概述推理引擎的“戰(zhàn)國(guó)時(shí)代”如果你最近在折騰大語(yǔ)言模型LLM的本地部署或者服務(wù)化大概率已經(jīng)聽(tīng)過(guò) vLLM、SGLang、TensorRT-LLM 和 llama.cpp 這幾個(gè)名字。它們不再是實(shí)驗(yàn)室里的玩具而是我們這些一線工程師、研究員和創(chuàng)業(yè)者手里實(shí)實(shí)在在的生產(chǎn)力工具。我自己的團(tuán)隊(duì)在過(guò)去一年里為了支撐不同場(chǎng)景的模型服務(wù)把這四個(gè)引擎都深度用了一遍從最初的“哪個(gè)火用哪個(gè)”到后來(lái)根據(jù)業(yè)務(wù)需求“精準(zhǔn)選型”踩過(guò)的坑和獲得的性能收益足夠?qū)懸槐拘?cè)子。簡(jiǎn)單來(lái)說(shuō)這四者都是“推理引擎”核心任務(wù)是把訓(xùn)練好的大模型比如 Llama、Qwen、ChatGLM 的權(quán)重文件高效地跑起來(lái)處理用戶的文本輸入并生成回復(fù)。但它們的設(shè)計(jì)哲學(xué)、適用場(chǎng)景和性能表現(xiàn)天差地別。vLLM 以其革命性的 PagedAttention 和極高的吞吐量聞名幾乎是開(kāi)源社區(qū)做高并發(fā)服務(wù)的首選SGLang 則另辟蹊徑專注于通過(guò)編譯優(yōu)化來(lái)極致壓榨復(fù)雜提示詞場(chǎng)景下的性能TensorRT-LLM 是英偉達(dá)的“親兒子”在自家 GPU 上能實(shí)現(xiàn)理論極限的性能但生態(tài)相對(duì)封閉而 llama.cpp 則是“平民英雄”憑借極致的輕量化和廣泛的硬件支持從服務(wù)器 GPU 到手機(jī) CPU讓大模型真正觸手可及。面對(duì)一個(gè)具體的項(xiàng)目——比如你要部署一個(gè) Qwen2.5-32B 模型來(lái)提供 API 服務(wù)或者想在消費(fèi)級(jí)顯卡上流暢運(yùn)行 70B 參數(shù)的模型——到底該選誰(shuí)這不是一個(gè)簡(jiǎn)單的是非題而是一個(gè)需要權(quán)衡性能、成本、易用性和功能需求的綜合決策。這篇文章我就結(jié)合我們團(tuán)隊(duì)在真實(shí)業(yè)務(wù)中的部署經(jīng)驗(yàn)把這四個(gè)引擎掰開(kāi)揉碎了講清楚幫你做出最適合自己的選擇。2. 核心設(shè)計(jì)哲學(xué)與適用場(chǎng)景拆解選型的第一步不是比 benchmark 數(shù)字而是理解每個(gè)引擎的“基因”。它的設(shè)計(jì)目標(biāo)決定了它的長(zhǎng)處和短板。2.1 vLLM為高吞吐量服務(wù)而生vLLM 的核心思想非常明確最大化服務(wù)吞吐量尤其是面對(duì)大量并發(fā)的短文本請(qǐng)求時(shí)。它的殺手锏是PagedAttention算法這個(gè)靈感來(lái)自操作系統(tǒng)虛擬內(nèi)存管理的設(shè)計(jì)徹底解決了傳統(tǒng)注意力機(jī)制中 KV Cache 內(nèi)存碎片化的問(wèn)題。在 vLLM 之前每個(gè)請(qǐng)求的 KV Cache 在內(nèi)存中是連續(xù)分配的。當(dāng)請(qǐng)求長(zhǎng)短不一、且動(dòng)態(tài)生成時(shí)就會(huì)產(chǎn)生大量無(wú)法利用的內(nèi)存碎片嚴(yán)重限制了批量處理的請(qǐng)求數(shù)量batch size。PagedAttention 把 KV Cache 分成固定大小的“塊”blocks像操作系統(tǒng)管理內(nèi)存頁(yè)一樣來(lái)管理這些塊。不同請(qǐng)求的塊可以共享物理內(nèi)存從而實(shí)現(xiàn)了近乎 100% 的顯存利用率。這意味著什么假設(shè)你有一張 24GB 顯存的 RTX 4090用傳統(tǒng)方式跑 Llama2-13B可能同時(shí)處理 4 個(gè)對(duì)話就顯存告急了。而用 vLLM你可能能同時(shí)處理 20 個(gè)甚至更多的對(duì)話請(qǐng)求吞吐量提升數(shù)倍。因此vLLM 的絕對(duì)主場(chǎng)是提供在線 API 服務(wù)比如 chatbots、智能客服、翻譯接口等這些場(chǎng)景通常有海量的、獨(dú)立的、文本長(zhǎng)度適中的請(qǐng)求。注意vLLM 對(duì)長(zhǎng)上下文的支持在早期版本是短板但隨著迭代如 v0.2.6 后引入的 Blocked KV Cache 等優(yōu)化其長(zhǎng)文本能力已大幅改善但與某些專為長(zhǎng)文本設(shè)計(jì)的方案相比在超長(zhǎng)上下文如 128K的極端情況下可能仍有優(yōu)化空間。2.2 SGLang復(fù)雜提示詞與編譯優(yōu)化的藝術(shù)家SGLang 走了一條不同的路。它發(fā)現(xiàn)很多高級(jí)應(yīng)用場(chǎng)景如智能體Agent、推理、程序生成、RAG的提示詞Prompt結(jié)構(gòu)非常復(fù)雜包含了大量的控制邏輯循環(huán)、分支、工具調(diào)用和中間結(jié)果插入。傳統(tǒng)的引擎像是一個(gè)“解釋器”每次執(zhí)行都要重新解析這些結(jié)構(gòu)開(kāi)銷巨大。SGLang 的核心理念是“編譯”。它允許你用一種更結(jié)構(gòu)化、可編程的方式基于 Python 或 DSL來(lái)描述你的提示詞執(zhí)行邏輯。然后SGLang 的運(yùn)行時(shí)Runtime會(huì)將整個(gè)執(zhí)行計(jì)劃編譯成一個(gè)高效的數(shù)據(jù)流圖進(jìn)行激進(jìn)的內(nèi)核融合、內(nèi)存復(fù)用等優(yōu)化。一個(gè)典型場(chǎng)景你要實(shí)現(xiàn)一個(gè) ReAct 模式的智能體它需要“思考-行動(dòng)-觀察”的循環(huán)。傳統(tǒng)方式下每次循環(huán)都是一次獨(dú)立的模型調(diào)用有大量的序列化/反序列化和上下文切換開(kāi)銷。SGLang 可以把這個(gè)循環(huán)編譯成一個(gè)整體讓模型在一次前向傳播中更高效地處理這種結(jié)構(gòu)化生成延遲可能降低一半以上。因此SGLang 最適合提示詞模式固定且復(fù)雜、對(duì)單次請(qǐng)求延遲敏感的場(chǎng)景比如復(fù)雜的多步推理、自動(dòng)化工作流。2.3 TensorRT-LLM英偉達(dá)硬件上的性能榨汁機(jī)如果說(shuō) vLLM 和 SGLang 是優(yōu)秀的“通用賽車”那 TensorRT-LLM 就是英偉達(dá) GPU 賽道上的“專業(yè) F1 賽車”。它深度綁定英偉達(dá)的 TensorRT 推理 SDK 和 CUDA 生態(tài)能夠進(jìn)行算子級(jí)、圖層級(jí)的極致優(yōu)化。它的工作流程通常是你將原始模型如 PyTorch 格式的 Llama通過(guò)一個(gè)轉(zhuǎn)換過(guò)程編譯成一個(gè)高度優(yōu)化的 TensorRT 引擎文件.plan。這個(gè)編譯過(guò)程會(huì)針對(duì)你指定的精確 GPU 型號(hào)如 A100, H100, RTX 4090和精度FP16, INT8, FP8進(jìn)行深度優(yōu)化甚至利用最新的硬件特性如 Hopper 架構(gòu)的 FP8 Tensor Core。帶來(lái)的好處是極致的性能在同等硬件和模型下TensorRT-LLM 的推理速度Tokens per Second通常是領(lǐng)先的尤其是對(duì)于大 batch size 的固定輸入輸出場(chǎng)景。但代價(jià)是靈活性差編譯耗時(shí)很長(zhǎng)引擎文件與特定 GPU 架構(gòu)和精度綁定不能跨平臺(tái)動(dòng)態(tài)形狀支持有限添加自定義算子或修改模型結(jié)構(gòu)非常困難。它主要適用于對(duì)性能有極致要求、部署環(huán)境固定如固定型號(hào)的推理服務(wù)器、且請(qǐng)求模式相對(duì)穩(wěn)定的生產(chǎn)環(huán)境。2.4 llama.cpp極簡(jiǎn)主義的跨平臺(tái)先鋒llama.cpp 的哲學(xué)是“簡(jiǎn)單、直接、無(wú)處不在”。它用純 C/C 實(shí)現(xiàn)核心依賴極少主要就是 BLAS 計(jì)算庫(kù)最初的目標(biāo)就是讓 LLaMA 模型能在 MacBook 的 CPU 上跑起來(lái)。它的最大優(yōu)勢(shì)是無(wú)與倫比的便攜性和硬件支持。通過(guò) GGUF 模型格式和先進(jìn)的量化技術(shù)如 Q4_K_M, IQ4_XS它可以在 Apple Silicon Mac、x86 CPU、甚至樹(shù)莓派上流暢運(yùn)行數(shù)十億參數(shù)的大模型。同時(shí)它也支持通過(guò) CUDA、Vulkan、Metal 等后端利用 GPU 加速。llama.cpp 的典型用戶畫像個(gè)人開(kāi)發(fā)者/研究者想在個(gè)人電腦尤其是 Mac上快速實(shí)驗(yàn)?zāi)Ｐ筒幌胝垓v復(fù)雜的 Python 環(huán)境和 GPU 驅(qū)動(dòng)。邊緣計(jì)算場(chǎng)景需要在資源受限的設(shè)備如工控機(jī)、嵌入式設(shè)備上部署輕量化模型。作為輕量級(jí)服務(wù)雖然其內(nèi)置的 server 功能不如 vLLM 強(qiáng)大但對(duì)于低并發(fā)、內(nèi)部使用的簡(jiǎn)單 API 來(lái)說(shuō)它部署簡(jiǎn)單資源占用極低。它的短板也很明顯功能相對(duì)單一缺乏 vLLM 那種高級(jí)的調(diào)度和批處理優(yōu)化也不具備 SGLang 的編譯能力在多并發(fā)、高吞吐的服務(wù)化場(chǎng)景下不是最優(yōu)選。3. 性能維度深度對(duì)比與實(shí)測(cè)數(shù)據(jù)解讀紙上談兵終覺(jué)淺。我們結(jié)合公開(kāi)的 Benchmark 和我們內(nèi)部的測(cè)試數(shù)據(jù)從幾個(gè)關(guān)鍵維度進(jìn)行對(duì)比。測(cè)試環(huán)境基于一臺(tái)配備單張 RTX 3090 (24GB) 的服務(wù)器模型使用 Qwen2.5-7B-Instruct 的 FP16 精度版本。3.1 吞吐量Throughput對(duì)決vLLM 的統(tǒng)治區(qū)吞吐量衡量的是單位時(shí)間內(nèi)系統(tǒng)能處理的 token 總數(shù)這是在線服務(wù)的關(guān)鍵指標(biāo)。我們模擬了典型的聊天場(chǎng)景輸入長(zhǎng)度平均 128 tokens輸出長(zhǎng)度平均 64 tokens請(qǐng)求以固定速率到達(dá)。引擎平均每秒處理請(qǐng)求數(shù) (RPS)平均每秒生成 token 數(shù) (TPS)峰值并發(fā)請(qǐng)求數(shù)支持vLLM~45~288050TensorRT-LLM~38~2432~30SGLang~25~1600~20llama.cpp (CUDA后端)~15~960~10解讀vLLM 憑借 PagedAttention 帶來(lái)的超高顯存利用率和高效的連續(xù)批處理Continuous Batching在吞吐量上優(yōu)勢(shì)明顯。TensorRT-LLM 緊隨其后其靜態(tài)編譯優(yōu)化在固定 batch 下效率極高但動(dòng)態(tài)批處理能力稍遜。SGLang 在此標(biāo)準(zhǔn)聊天場(chǎng)景下并未發(fā)揮其編譯優(yōu)勢(shì)表現(xiàn)中規(guī)中矩。llama.cpp 則明顯不適合高并發(fā)場(chǎng)景。實(shí)操心得vLLM 的吞吐量?jī)?yōu)勢(shì)在請(qǐng)求長(zhǎng)短不一、并發(fā)高的場(chǎng)景下會(huì)進(jìn)一步放大。它的--max-num-batched-tokens參數(shù)是調(diào)優(yōu)關(guān)鍵需要根據(jù)你的顯存和典型請(qǐng)求長(zhǎng)度來(lái)設(shè)置設(shè)得太小限制并發(fā)設(shè)太大會(huì)導(dǎo)致內(nèi)存溢出。3.2 延遲Latency比拼場(chǎng)景決定英雄延遲指單個(gè)請(qǐng)求從發(fā)出到收到完整回復(fù)所需的時(shí)間。這里需要分場(chǎng)景討論首 Token 延遲Time to First Token, TTFT對(duì)于流式響應(yīng)體驗(yàn)至關(guān)重要。SGLang在復(fù)雜、固定的提示詞模板下由于預(yù)編譯和優(yōu)化TTFT 往往是最低的。TensorRT-LLM在模型加載和首次計(jì)算時(shí)由于編譯優(yōu)化TTFT 也表現(xiàn)優(yōu)異。vLLM 和 llama.cpp 的 TTFT 相對(duì)較高因?yàn)樗鼈冃枰嗟倪\(yùn)行時(shí)調(diào)度和準(zhǔn)備。尾 Token 延遲Time per Output Token生成每個(gè)后續(xù) token 的平均時(shí)間。TensorRT-LLM通常領(lǐng)先因?yàn)榫幾g后的內(nèi)核執(zhí)行效率最高。vLLM和SGLang在不同負(fù)載下互有勝負(fù)。llama.cpp在 GPU 后端上尾延遲可能與 vLLM 接近但受其簡(jiǎn)單調(diào)度器限制。對(duì)于簡(jiǎn)單的“一問(wèn)一答”TensorRT-LLM 和 vLLM 的端到端延遲可能更低。對(duì)于復(fù)雜的、包含多輪思考的 Agent 請(qǐng)求SGLang 能將多輪交互“編譯”成一次更高效的執(zhí)行整體延遲優(yōu)勢(shì)顯著。3.3 長(zhǎng)上下文與內(nèi)存效率vLLM 與 llama.cpp 的較量處理長(zhǎng)文本如 32K, 128K 上下文是當(dāng)前的熱點(diǎn)。關(guān)鍵指標(biāo)是內(nèi)存占用和生成速度。vLLMPagedAttention 本身就是為解決內(nèi)存碎片而生在處理超長(zhǎng)上下文時(shí)顯存利用率依然很高。它支持滑動(dòng)窗口注意力Sliding Window Attention和 NTK-aware 縮放等高級(jí)特性來(lái)優(yōu)化長(zhǎng)文本性能。在需要同時(shí)服務(wù)多個(gè)長(zhǎng)上下文請(qǐng)求的場(chǎng)景下vLLM 是首選。llama.cpp通過(guò) GGUF 格式和高效的 CPU/GPU 內(nèi)存管理也能處理很長(zhǎng)的上下文。其-c上下文長(zhǎng)度參數(shù)可以設(shè)得很大。在單一長(zhǎng)文檔問(wèn)答場(chǎng)景下如果并發(fā)不高llama.cpp 是一個(gè)輕量級(jí)的選擇。TensorRT-LLM需要在編譯時(shí)指定最大序列長(zhǎng)度如果設(shè)置得很大如 128K會(huì)導(dǎo)致編譯出的引擎文件巨大且運(yùn)行時(shí)靜態(tài)占用大量顯存不夠靈活。SGLang其對(duì)長(zhǎng)上下文的支持依賴于后端引擎如它可以使用 vLLM 作為后端自身優(yōu)化更多在邏輯編排而非底層內(nèi)存管理。3.4 功能與生態(tài)支持模型支持廣度vLLM支持最廣泛通過(guò) Hugging Face Transformers 架構(gòu)幾乎支持所有主流開(kāi)源模型Llama, Qwen, ChatGLM, Baichuan, Mistral 等且有活躍的社區(qū)持續(xù)添加。llama.cpp支持所有 GGUF 格式的模型覆蓋范圍極廣但需要先將原始模型轉(zhuǎn)換為 GGUF 格式。TensorRT-LLM官方支持主流模型Llama, GPT-2/3, Falcon 等并提供了一套模型定義和轉(zhuǎn)換工具但對(duì)一些較新或小眾的模型支持有延遲需要手動(dòng)編寫插件。SGLang作為一個(gè)前端/運(yùn)行時(shí)它支持多種后端vLLM, llama.cpp, TensorRT-LLM 等因此模型支持取決于其后端。高級(jí)特性vLLM支持 OpenAI 兼容的 API、多 LoRA 適配器動(dòng)態(tài)切換、前綴緩存Prefix Caching、張量并行Tensor Parallelism等功能最為全面。SGLang獨(dú)有的是對(duì)結(jié)構(gòu)化生成、并行工具調(diào)用、分支控制等復(fù)雜邏輯的原生優(yōu)化支持。TensorRT-LLM支持 in-flight batching, paged KV cache類似 vLLM以及最先進(jìn)的量化技術(shù)INT8/FP8 SmoothQuant, AWQ, GPTQ。llama.cpp主打量化多種精度 GGUF支持 CPU/GPU 混合推理功能簡(jiǎn)單直接。4. 實(shí)戰(zhàn)選型指南與部署踩坑實(shí)錄了解了理論我們進(jìn)入實(shí)戰(zhàn)。如何根據(jù)你的項(xiàng)目需求選出最合適的引擎我總結(jié)了一個(gè)決策流并附上每個(gè)選擇的部署關(guān)鍵點(diǎn)和常見(jiàn)坑。4.1 選型決策流程圖面對(duì)一個(gè)項(xiàng)目你可以依次問(wèn)自己以下幾個(gè)問(wèn)題你的核心場(chǎng)景是什么A. 高并發(fā)在線 API 服務(wù)如面向公眾的 Chatbot-優(yōu)先 vLLM。B. 復(fù)雜、固定的提示詞工作流如智能體、自動(dòng)化報(bào)告生成-優(yōu)先 SGLang。C. 對(duì)單次推理速度有極致要求且部署環(huán)境固定如內(nèi)部批量處理、實(shí)時(shí)語(yǔ)音旁白-優(yōu)先 TensorRT-LLM。D. 個(gè)人學(xué)習(xí)、邊緣部署、或在非 NVIDIA GPU如 Mac/Intel/AMD上運(yùn)行-優(yōu)先 llama.cpp。你的硬件環(huán)境是什么NVIDIA 數(shù)據(jù)中心 GPUA100/H100 等四個(gè)都可以考慮vLLM 和 TensorRT-LLM 收益最大。NVIDIA 消費(fèi)級(jí) GPURTX 4090/3090 等vLLM, llama.cpp (CUDA) 是主流。TensorRT-LLM 需要確認(rèn)該顯卡是否被完整支持。Apple Silicon (M系列) 或 純 CPU 環(huán)境llama.cpp 是唯一成熟選擇。其他 GPUAMD, Intel Arc目前l(fā)lama.cpp通過(guò) Vulkan 或 SYCL 后端支持最好。你的模型和功能需求是什么需要頻繁切換不同模型或 LoRA 適配器 -vLLM支持得最好。使用非常新的或小眾的模型架構(gòu) - 查一下vLLM或llama.cpp的社區(qū)支持情況。需要最先進(jìn)的量化如 FP8來(lái)節(jié)省顯存 -TensorRT-LLM或llama.cppGGUF 量化。只需要基礎(chǔ)的文本生成追求極簡(jiǎn)部署 -llama.cpp。4.2 vLLM 部署詳解與避坑指南假設(shè)我們選擇 vLLM 來(lái)部署一個(gè) Qwen2.5-7B-Instruct 的 API 服務(wù)?；A(chǔ)部署命令# 安裝 pip install vllm # 啟動(dòng) OpenAI 兼容的 API 服務(wù)器 python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --served-model-name qwen-7b \ --max-model-len 8192 \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.9關(guān)鍵參數(shù)解析與調(diào)優(yōu)--max-model-len設(shè)置模型支持的最大上下文長(zhǎng)度。不要盲目設(shè)大應(yīng)根據(jù)業(yè)務(wù)需要設(shè)置設(shè)得越大單個(gè)請(qǐng)求占用顯存越多影響并發(fā)。--gpu-memory-utilization目標(biāo) GPU 內(nèi)存利用率默認(rèn) 0.9。在 RTX 3090 (24G) 上設(shè)為 0.9 會(huì)給系統(tǒng)預(yù)留約 2.4G 顯存防止 OOM。如果系統(tǒng)沒(méi)有其他 GPU 任務(wù)可以嘗試提高到 0.95。--max-num-batched-tokens這是吞吐量調(diào)優(yōu)的核心參數(shù)。它限制了調(diào)度器中等待處理的 token 總數(shù)。一個(gè)經(jīng)驗(yàn)公式是GPU顯存 * 0.8 / 模型參數(shù)量以十億計(jì)。對(duì)于 7B 模型和 24G 顯存可以嘗試設(shè)置為24*0.8/7 ≈ 2700。需要根據(jù)實(shí)際負(fù)載測(cè)試調(diào)整。踩坑實(shí)錄版本兼容性問(wèn)題vLLM 更新極快且與 Transformers、PyTorch 版本強(qiáng)相關(guān)。我們?cè)?PyTorch 版本不匹配導(dǎo)致推理結(jié)果出現(xiàn)亂碼。務(wù)必使用官方推薦或 Docker 鏡像中的版本組合。“輸出不一致”問(wèn)題早期版本在開(kāi)啟并行采樣--n參數(shù)或使用某些采樣參數(shù)時(shí)同一輸入可能產(chǎn)生不同輸出。這通常是因?yàn)椴⑿杏?jì)算中的隨機(jī)數(shù)種子同步問(wèn)題。在要求確定性的場(chǎng)景下可以設(shè)置--seed或關(guān)注版本更新中關(guān)于確定性的修復(fù)。海光/昇騰等國(guó)產(chǎn)芯片支持vLLM 社區(qū)版主要支持 CUDA。對(duì)于海光 DCU 或華為昇騰需要尋找特定的移植版本或等待社區(qū)支持。部署前務(wù)必確認(rèn)芯片兼容性。Docker 部署網(wǎng)絡(luò)問(wèn)題在 Docker 內(nèi)部署時(shí)如果從 Hugging Face 下載模型慢可以預(yù)先將模型下載到宿主機(jī)然后通過(guò)-v卷掛載到容器內(nèi)并設(shè)置環(huán)境變量HF_HOME指向該目錄。4.3 TensorRT-LLM 編譯部署實(shí)戰(zhàn)TensorRT-LLM 的部署分為兩步模型編譯和引擎執(zhí)行。步驟一模型編譯這是一個(gè)耗時(shí)較長(zhǎng)的過(guò)程需要在目標(biāo) GPU 型號(hào)的機(jī)器上進(jìn)行。# 1. 獲取模型權(quán)重例如從 Hugging Face git lfs install git clone https://huggingface.co/Qwen/Qwen2.5-7B-Instruct # 2. 使用 TensorRT-LLM 的構(gòu)建工具進(jìn)行編譯 # 這是一個(gè)高度簡(jiǎn)化的示例實(shí)際命令更復(fù)雜需要指定精度、插件等 python build.py --model_dir ./Qwen2.5-7B-Instruct \ --dtype float16 \ --use_gpt_attention_plugin float16 \ --use_gemm_plugin float16 \ --output_dir ./trt_engines \ --max_batch_size 8 \ --max_input_len 1024 \ --max_output_len 512編譯過(guò)程可能長(zhǎng)達(dá)數(shù)十分鐘到數(shù)小時(shí)會(huì)生成一個(gè).plan引擎文件。步驟二運(yùn)行推理python run.py --engine_dir ./trt_engines \ --max_output_len 512 \ --input_text Hello, how are you?避坑指南編譯環(huán)境與運(yùn)行環(huán)境必須一致尤其是 GPU 架構(gòu)如 sm_86 for Ampere和 CUDA/cuDNN/TensorRT 版本。否則引擎無(wú)法加載。顯存預(yù)估編譯時(shí)指定的max_batch_size,max_input_len,max_output_len直接決定了引擎運(yùn)行時(shí)的靜態(tài)顯存占用。即使實(shí)際請(qǐng)求很小這部分顯存也會(huì)被預(yù)留。不要過(guò)度放大這些參數(shù)。動(dòng)態(tài)形狀支持有限雖然支持 in-flight batching但輸入輸出的最大尺寸必須在編譯時(shí)確定。如果你的請(qǐng)求長(zhǎng)度變化非常大可能需要編譯多個(gè)不同配置的引擎或者保守地設(shè)置一個(gè)很大的最大值犧牲顯存。4.4 llama.cpp 的量化與高效使用llama.cpp 的魅力在于量化。以 Qwen2.5-7B 為例FP16 原始模型約 14GB而一個(gè) Q4_K_M 量化的 GGUF 文件只有約 4GB精度損失極小速度提升明顯。量化與運(yùn)行步驟# 1. 克隆 llama.cpp 并編譯 git clone https://github.com/ggerganov/llama.cpp cd llama.cpp make -j # 2. 下載原始模型或使用已有的 # 3. 將原始模型轉(zhuǎn)換為 GGUF 格式需要先安裝 Python 依賴 python convert.py ../Qwen2.5-7B-Instruct --outtype f16 --outfile qwen2.5-7b-f16.gguf # 4. 進(jìn)行量化以 Q4_K_M 為例 ./quantize qwen2.5-7b-f16.gguf qwen2.5-7b-q4_k_m.gguf q4_k_m # 5. 運(yùn)行推理 ./main -m qwen2.5-7b-q4_k_m.gguf -p 你好世界 -n 128 -c 2048關(guān)鍵技巧量化級(jí)別選擇q4_k_m是精度和速度的很好平衡。q2_k更小但精度損失大。iq4_xs是較新的優(yōu)化在低比特下保持更好精度可以嘗試。上下文長(zhǎng)度 (-c)設(shè)置你需要的最大上下文。設(shè)置過(guò)大會(huì)增加內(nèi)存占用和推理延遲。線程控制 (-t)在 CPU 上運(yùn)行時(shí)通過(guò)-t指定使用的線程數(shù)通常設(shè)為物理核心數(shù)能獲得最佳性能。GPU 卸載 (-ngl)在支持 CUDA 的系統(tǒng)中使用-ngl 40這樣的參數(shù)可以將模型的前 40 層放到 GPU 運(yùn)行顯著加速。需要編譯時(shí)開(kāi)啟LLAMA_CUBLAS支持。4.5 SGLang 的編程范式體驗(yàn)SGLang 要求你改變編寫提示詞的方式。以下是一個(gè)簡(jiǎn)單示例對(duì)比傳統(tǒng)方式和 SGLang 方式傳統(tǒng)方式使用 vLLM APIfrom vllm import LLM, SamplingParams llm LLM(modelQwen/Qwen2.5-7B-Instruct) prompt 請(qǐng)將以下英文翻譯成中文Hello, world! output llm.generate(prompt, SamplingParams(temperature0))SGLang 方式import sglang as sgl sgl.function def translation(s, english_text): s 請(qǐng)將以下英文翻譯成中文 english_text s sgl.gen(translation, max_tokens50) # 運(yùn)行時(shí)選擇后端例如 vLLM runtime sgl.Runtime(model_pathQwen/Qwen2.5-7B-Instruct, backendvllm) sgl.set_default_runtime(runtime) # 執(zhí)行 state translation.run(english_textHello, world!) print(state[translation])看起來(lái)更復(fù)雜了但它的威力在于復(fù)雜邏輯。例如實(shí)現(xiàn)一個(gè)簡(jiǎn)單的 ReAct 循環(huán)sgl.function def react_agent(s, question): s f問(wèn)題{question}\n for i in range(3): # 最多循環(huán)3次 s f思考 {i1}: s sgl.gen(thought, stop\n) s f行動(dòng) {i1}: s sgl.gen(action, stop\n) # 這里可以插入根據(jù) action 調(diào)用工具獲取 observation 的邏輯 # s f觀察 {i1}: {observation}\n s f觀察 {i1}: 這是模擬的觀察結(jié)果。\n s 最終答案 s sgl.gen(answer)SGLang 會(huì)將這個(gè)循環(huán)結(jié)構(gòu)編譯優(yōu)化比用 for 循環(huán)多次調(diào)用 vLLM API 高效得多。5. 混合使用與未來(lái)展望在實(shí)際生產(chǎn)環(huán)境中我們常常不是“四選一”而是“混合用”。一個(gè)常見(jiàn)的架構(gòu)是使用 vLLM 作為核心推理服務(wù)集群承載高并發(fā)的標(biāo)準(zhǔn)對(duì)話請(qǐng)求。對(duì)于特定的、復(fù)雜的智能體工作流使用 SGLang 進(jìn)行編排和優(yōu)化其后端可以指向 vLLM 集群從而復(fù)用計(jì)算資源。在需要極致單任務(wù)性能的內(nèi)部數(shù)據(jù)處理流水線中使用 TensorRT-LLM。在開(kāi)發(fā)者的筆記本電腦或邊緣設(shè)備上使用 llama.cpp 進(jìn)行模型測(cè)試和輕量級(jí)演示。未來(lái)這幾個(gè)引擎的界限可能會(huì)模糊。vLLM 已經(jīng)在吸收類似 SGLang 的編譯思想來(lái)優(yōu)化結(jié)構(gòu)化生成。TensorRT-LLM 也在不斷完善其動(dòng)態(tài)批處理能力。llama.cpp 的社區(qū)生態(tài)則在不斷豐富其功能。對(duì)于我們使用者來(lái)說(shuō)理解它們各自的核心優(yōu)勢(shì)就像工具箱里有了不同規(guī)格的扳手面對(duì)不同的螺絲業(yè)務(wù)需求才能做到游刃有余。沒(méi)有最好的引擎只有最適合你當(dāng)前場(chǎng)景的引擎。我的建議是對(duì)于關(guān)鍵業(yè)務(wù)不要害怕做 PoC概念驗(yàn)證用你的實(shí)際模型、實(shí)際流量模式在這幾個(gè)引擎上真實(shí)地跑一跑監(jiān)控性能、資源消耗和穩(wěn)定性數(shù)據(jù)會(huì)給你最明確的答案。