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