做部署這塊這幾年我最大的感觸是跑通一個(gè)大模型 demo 只是把門(mén)推開(kāi)一條縫真正讓人掉頭發(fā)的是從一個(gè)人在筆記本上玩變成一群用戶在線上用。2026 年了推理框架、云 GPU 方案多得眼花繚亂可我依然看到很多團(tuán)隊(duì)卡在同一個(gè)路口——模型下載下來(lái)確實(shí)能出結(jié)果一接生產(chǎn)流量就崩或者月底一看賬單直接懷疑人生。這篇指南我想把這幾年實(shí)際趟過(guò)的路一次性說(shuō)明白從框架選型、云服務(wù)對(duì)比到一套真正能扛住線上流量的大模型服務(wù)器部署流程全部按我親手驗(yàn)證過(guò)的方式寫(xiě)不是拿官方文檔拼湊的那種。適合看這篇的人很明確準(zhǔn)備把開(kāi)源大模型接到自己業(yè)務(wù)里的后端工程師、算法工程師以及替公司做技術(shù)選型但預(yù)算和運(yùn)維人手都有限的技術(shù)負(fù)責(zé)人。文章不會(huì)堆一堆無(wú)腦命令而是把每個(gè)選擇背后的原因講透讓你看完能自己決策而不是只會(huì)復(fù)制粘貼。1. 部署前先想清楚你的大模型到底為誰(shuí)服務(wù)1.1 三種典型部署形態(tài)決定后面所有選擇很多人一上來(lái)就問(wèn)“用什么框架部署”這個(gè)順序其實(shí)反了。先問(wèn)一個(gè)問(wèn)題這個(gè)模型部署好之后服務(wù)對(duì)象和流量形態(tài)是什么樣第一種是在線交互服務(wù)。典型場(chǎng)景是智能客服、AI 助手、Copilot 這類(lèi)需要用戶實(shí)時(shí)等待回答的產(chǎn)品。這種形態(tài)最在意兩件事首字延遲用戶問(wèn)完問(wèn)題到看見(jiàn)第一個(gè)字的時(shí)間和并發(fā)能力同時(shí)能扛住多少個(gè)會(huì)話。它對(duì)顯存、推理引擎的要求最高也是本文討論的核心形態(tài)。第二種是批量離線推理。典型場(chǎng)景是歷史數(shù)據(jù)清洗、文檔批量理解、定時(shí)跑一批日?qǐng)?bào)總結(jié)。這種任務(wù)不要求秒級(jí)響應(yīng)跑幾十分鐘甚至幾小時(shí)都行。對(duì)用量的優(yōu)先級(jí)是吞吐量每秒生成多少 token和算力成本可以容忍排隊(duì)甚至可以晚上再用便宜算力跑。第三種是企業(yè)私有化交付。典型場(chǎng)景是銀行、醫(yī)療、政企項(xiàng)目核心訴求是數(shù)據(jù)和模型權(quán)重不出環(huán)境交付物通常是一套包含模型文件、推理服務(wù)、管理界面的完整系統(tǒng)。這種形態(tài)要把精力花在離線部署包制作、權(quán)限隔離、一鍵升級(jí)這些交付細(xì)節(jié)上而不是單純追求單機(jī)性能。這三種形態(tài)對(duì)框架、云資源、流程的要求完全不同。在線服務(wù)要把 vLLM、SGLang 這類(lèi)高性能推理引擎聊透批量離線可能只需要簡(jiǎn)單的批量腳本加定時(shí)任務(wù)私有化交付則要額外做好模型加密、離線安裝包、版本管理。想清楚自己是哪種再看下面的內(nèi)容才不會(huì)跑偏。1.2 從需求倒推硬件預(yù)算顯存怎么算很多團(tuán)隊(duì)栽的第一個(gè)跟頭是買(mǎi)完卡發(fā)現(xiàn)顯存不夠跑想要的模型。顯存需求有一個(gè)大致的估算公式顯存 ≈ 模型參數(shù)占用量 KV Cache 占用量 推理過(guò)程臨時(shí)開(kāi)銷(xiāo)模型參數(shù)占用量很好算權(quán)重文件多大加載進(jìn)顯存基本就要多大。一個(gè) 7B 模型fp16 精度下大約 14GB用 4bit 量化后 4GB 左右就能跑70B 模型 fp16 要 140GB4bit 量化也需要 35-40GB。KV Cache 是推理過(guò)程中緩存歷史 token 的中間結(jié)果通常要額外留出 30% 左右余量。舉個(gè)真實(shí)例子。我?guī)鸵粋€(gè)團(tuán)隊(duì)規(guī)劃過(guò) 32B 模型的服務(wù)打算用 4bit 量化那參數(shù)本身約占 18GB再加 8k 上下文長(zhǎng)度的 KV Cache單卡至少要有 24GB 顯存才跑得動(dòng)推理如果還要并發(fā)高一點(diǎn)直接建議上雙卡。很多人在 24GB 卡上跑 32B 模型遭遇 OOM多半就是沒(méi)算 KV Cache 的余量。提示模型推理的顯存計(jì)算有個(gè)經(jīng)驗(yàn)法則——先看量化后的權(quán)重大小再乘以 1.3 到 1.5 作為運(yùn)行期總需求。7B 4bit 模型用這個(gè)法則算出來(lái)約 6-8GB正好低配個(gè)人電腦的顯存預(yù)算。1.3 部署資源從哪來(lái)自購(gòu)、云 GPU 還是 API 托管硬件來(lái)源決定你的試錯(cuò)成本。自購(gòu)服務(wù)器聽(tīng)起來(lái)資產(chǎn)化很誘人但從下單到上架用上到機(jī)器折舊、散熱、故障維修全都要自己扛。對(duì)于絕大多數(shù)沒(méi)有專屬機(jī)房運(yùn)維團(tuán)隊(duì)的團(tuán)隊(duì)我強(qiáng)烈建議從云 GPU 起步。云資源里又分兩種一種是租裸的 GPU 云主機(jī)自己在里面裝驅(qū)動(dòng)、部署推理框架靈活度最高也是本文主要講的路徑另一種是直接用云廠商的托管推理服務(wù)把模型傳上去平臺(tái)幫你拉起來(lái)省事很多但要接受平臺(tái)限定框架和一定的黑盒。對(duì)需要快速驗(yàn)證業(yè)務(wù)的團(tuán)隊(duì)托管服務(wù)是個(gè)好起點(diǎn)對(duì)已經(jīng)有工程能力的團(tuán)隊(duì)自己掌控整套部署鏈路能獲得更大的優(yōu)化空間。還有一種常被忽略的形態(tài)是 Serverless 方式發(fā)布推理服務(wù)類(lèi)似把模型封裝成一個(gè)函數(shù)按調(diào)用次數(shù)收費(fèi)零流量時(shí)不花顯卡錢(qián)。實(shí)測(cè)下來(lái)這個(gè)形態(tài)很適合 demo 和原型驗(yàn)證初期參數(shù)調(diào)優(yōu)階段非常劃算但流量穩(wěn)定之后單價(jià)往往比長(zhǎng)期租卡高生產(chǎn)主力還是別指望它。2. 推理框架選型2026 年主流方案橫向?qū)Ρ?.1 第一梯隊(duì)vLLM、SGLang、TensorRT-LLM2026 年這個(gè)時(shí)間點(diǎn)生產(chǎn)環(huán)境在線推理的三巨頭基本還是這三家但各自的定位差異很大。vLLM 是大多數(shù)團(tuán)隊(duì)?wèi)?yīng)該默認(rèn)選的框架。它有兩個(gè)核心創(chuàng)新Paged Attention 把顯存管理做得像操作系統(tǒng)內(nèi)存分頁(yè)一樣高效Continuous Batching 讓不同請(qǐng)求的動(dòng)態(tài)生成過(guò)程拼車(chē)處理。這兩個(gè)技術(shù)組合起來(lái)的效果是GPU 利用率相比樸素的逐個(gè)推理提升了數(shù)倍。我從 vLLM 0.6 版本用到現(xiàn)在的 0.8、0.9穩(wěn)定性一年比一年好社區(qū)生態(tài)也最成熟新模型出來(lái)后通常最早就是它適配。SGLang 更適合復(fù)雜推理場(chǎng)景。它的 RadixAttention 會(huì)自動(dòng)復(fù)用請(qǐng)求之間相同的前綴部分。比如做多輪對(duì)話用戶前面說(shuō)過(guò)的話不用重新算一遍做思維鏈或復(fù)雜 Agent 場(chǎng)景多個(gè)請(qǐng)求共享大段 system prompt 時(shí)這套機(jī)制帶來(lái)的提速非常明顯。另外它對(duì)結(jié)構(gòu)化輸出、多模態(tài)輸入的支持做得很細(xì)致。如果你的業(yè)務(wù)有大量長(zhǎng)文檔問(wèn)答、復(fù)雜工具調(diào)用SGLang 值得認(rèn)真評(píng)估。TensorRT-LLM 是為極致性能而生的。這是英偉達(dá)自家生態(tài)里的框架通過(guò) TensorRT 引擎把模型編譯成高度優(yōu)化的推理圖同硬件下延遲和吞吐往往能壓得更低。但它把易用性犧牲得比較多模型編譯時(shí)間長(zhǎng)PyTorch 生態(tài)里的新特性支持滯后調(diào)試問(wèn)題也更痛苦。除非你的硬件規(guī)模大、團(tuán)隊(duì)有專門(mén)的推理優(yōu)化工程師或者業(yè)務(wù)對(duì) P99 延遲極其苛刻否則不建議第一步就選它。2.2 輕量場(chǎng)景別殺雞用牛刀Ollama 和 llama.cppOllama 這兩年的流行程度有點(diǎn)被過(guò)度抬高了。它最大的價(jià)值是開(kāi)箱即用——一條命令下載模型、一條命令起一個(gè)兼容 OpenAI 的 HTTP 接口開(kāi)發(fā)調(diào)試體驗(yàn)極好個(gè)人電腦上玩大模型基本首選。我自己的開(kāi)發(fā)環(huán)境就常駐一個(gè) Ollama用來(lái)快速驗(yàn)證提示詞效果。但它的瓶頸在于并發(fā)能力弱、缺少精細(xì)的調(diào)度控制、量化管理也比較黑盒線上多用戶并發(fā)一上來(lái)就明顯吃力。llama.cpp 則主打一個(gè)奇純 CPU 也能跑ARM 設(shè)備也能跑內(nèi)存占用極低。邊緣設(shè)備、樹(shù)莓派、內(nèi)網(wǎng)小工具這類(lèi)場(chǎng)景它幾乎是唯一解。但同樣它不適合作為高并發(fā)服務(wù)的底座。這里得給個(gè)明確建議開(kāi)發(fā)調(diào)試用 Ollama 沒(méi)問(wèn)題線上在線服務(wù)至少要從 vLLM 或 SGLang 開(kāi)始考慮。有一個(gè)常見(jiàn)誤區(qū)是“用 Ollama 部署好了就直接當(dāng)生產(chǎn)”。一次我問(wèn)一個(gè)團(tuán)隊(duì)線上服務(wù)用什么他說(shuō) Ollama再問(wèn)壓測(cè)結(jié)果發(fā)現(xiàn) 5 個(gè)并發(fā)就把響應(yīng)時(shí)間拖到了十幾秒。所以輕量框架可以作為生產(chǎn)的前置驗(yàn)證工具但真要面對(duì)真實(shí)用戶把這個(gè)環(huán)節(jié)替換成高性能框架幾乎是必經(jīng)之路。2.3 多模型規(guī)?；芾鞹riton 與統(tǒng)一網(wǎng)關(guān)當(dāng)你的業(yè)務(wù)不是只有一個(gè)模型而是同時(shí)有 Embedding 模型、對(duì)話模型、小分類(lèi)模型、大生成模型每個(gè)框架各起一套服務(wù)后相互之間的管理就很混亂。NVIDIA Triton Inference Server 的價(jià)值就在于此它可以作為統(tǒng)一的模型托管入口同時(shí)掛載多個(gè)后端不同的模型用不同框架加載統(tǒng)一對(duì)外暴露一個(gè)服務(wù)端口。配合 Triton 的模型版本管理可以實(shí)現(xiàn)新模型和舊模型并行運(yùn)行灰度流量切到新版本發(fā)現(xiàn)問(wèn)題立即回滾。如果你面向企業(yè)客戶做交付Triton 這種“一個(gè)入口管所有模型”的方式也更容易講清楚架構(gòu)。但 Triton 的使用門(mén)檻并不低它的配置體系復(fù)雜很多團(tuán)隊(duì)部署完 vLLM 就已經(jīng)能滿足需求不一定非要再疊一層 Triton。我一般建議單模型單場(chǎng)景直接上 vLLM多模型多租戶場(chǎng)景再加 Triton 或自建網(wǎng)關(guān)。工具沒(méi)有絕對(duì)的好壞匹配復(fù)雜度才是關(guān)鍵。2.4 選型決策速查表部署場(chǎng)景推薦方案核心理由在線單模型聊天/客服vLLM生態(tài)成熟、并發(fā)吞吐出色、上手成本低復(fù)雜推理鏈/多輪長(zhǎng)對(duì)話SGLang前綴復(fù)用、結(jié)構(gòu)化能力更強(qiáng)極致性能/超低延遲需求TensorRT-LLM引擎優(yōu)化最深適合投入工程師調(diào)優(yōu)個(gè)人開(kāi)發(fā)/本地驗(yàn)證Ollama一條命令起服務(wù)模型管理最省心邊緣設(shè)備/純 CPU 環(huán)境llama.cpp資源占用少不受顯卡限制多模型統(tǒng)一托管Triton 網(wǎng)關(guān)統(tǒng)一入口、模型版本管理、灰度方便另外要說(shuō)明的是微調(diào)鏈路LLaMA-Factory 是目前微調(diào)實(shí)操最順手的工具之一微調(diào)完導(dǎo)出權(quán)重之后同樣可以喂給 vLLM 起生產(chǎn)服務(wù)。很多人誤以為微調(diào)和推理是兩套分裂的系統(tǒng)實(shí)際上它們是同一個(gè)鏈路的兩頭。3. 云服務(wù)對(duì)比GPU 從哪來(lái)錢(qián)怎么花3.1 主流云廠商 GPU 機(jī)型與計(jì)費(fèi)方式對(duì)比2026 年的云 GPU 市場(chǎng)選擇非常豐富。國(guó)內(nèi)主流的阿里云、騰訊云、華為云都有成熟的 GPU 云主機(jī)產(chǎn)品線機(jī)型覆蓋從入門(mén)級(jí)到頂配互聯(lián)集群另外還有一些以 GPU 資源為核心業(yè)務(wù)的云服務(wù)商性價(jià)比往往突出適合算法開(kāi)發(fā)和中小業(yè)務(wù)。計(jì)費(fèi)方式大體分三種按量付費(fèi)、包年包月、競(jìng)價(jià)實(shí)例。按量付費(fèi)靈活但單價(jià)高適合短時(shí)測(cè)試包年包月能獲得較大折扣適合長(zhǎng)期在線服務(wù)競(jìng)價(jià)實(shí)例是拿未被占用的閑置資源價(jià)格可能降到按量的兩三折但隨時(shí)可能被回收只能用于可中斷的批量任務(wù)千萬(wàn)別把在線服務(wù)壓在競(jìng)價(jià)實(shí)例上。以 2026 年初的大致行情來(lái)說(shuō)一張 24GB 顯存的 A10 或 L20按量大概每小時(shí) 8-15 元80GB 顯存的 A100 或 H20每小時(shí) 20-35 元區(qū)間浮動(dòng)。這些價(jià)格可能隨市場(chǎng)波動(dòng)實(shí)際以控制臺(tái)報(bào)價(jià)為準(zhǔn)。下面用這些數(shù)字做成本推導(dǎo)。3.2 成本測(cè)算實(shí)例一個(gè) 70B 模型跑滿一個(gè)月要用多少錢(qián)我們來(lái)算一筆具體賬。部署一個(gè) 70B 模型做在線服務(wù)fp16 精度要 140GB 顯存至少 4 張 80GB 卡如果做 4bit 量化兩張 80GB 卡也能跑但并發(fā)和上下文長(zhǎng)度會(huì)受限。支撐一個(gè)真實(shí)業(yè)務(wù)我按 4 張 A100 規(guī)格估算單卡按量約 25 元/時(shí)4 卡就是 100 元/時(shí)。如果全天跑滿 30 天按量總價(jià)是 100 × 24 × 30 72000 元實(shí)際業(yè)務(wù)負(fù)載很少全天滿載打五折也要 3 萬(wàn)多。如果選包年包月單卡月租一般在 1.3-1.8 萬(wàn)元4 卡一個(gè)月的成本在 5-7 萬(wàn)元區(qū)間但這是敞開(kāi)了用的額度。把這筆賬換算一下如果按月成本 5 萬(wàn)而這個(gè)服務(wù)每月只能帶來(lái)幾萬(wàn)元收入那這個(gè)項(xiàng)目就該重新思考模型規(guī)模或部署方式了。我見(jiàn)過(guò)不少團(tuán)隊(duì)在 70B 模型上大動(dòng)干戈最后發(fā)現(xiàn)用戶真實(shí)場(chǎng)景用 32B 甚至 14B 就夠月成本直接降了個(gè)量級(jí)。成本測(cè)算應(yīng)該反過(guò)來(lái)驅(qū)動(dòng)模型選型而不是先選模型再硬扛成本。3.3 云上部署的資源購(gòu)買(mǎi)經(jīng)驗(yàn)細(xì)節(jié)買(mǎi)完實(shí)例不是直接就能用幾個(gè)細(xì)節(jié)很容易埋坑。地域選擇上實(shí)例要和你的用戶體驗(yàn)?zāi)繕?biāo)匹配。業(yè)務(wù)用戶主要在哪個(gè)區(qū)域服務(wù)器就盡量選離得近可用區(qū)首字延遲能差出幾十毫秒。跨地域調(diào)用雖然請(qǐng)求也能通但每次都要走公網(wǎng)延遲和故障概率都上來(lái)了。存儲(chǔ)方面模型文件體積動(dòng)輒幾十 GB 到上百 GB數(shù)據(jù)盤(pán)一定要選高性能云盤(pán)并且閉店注意 IOPS。啟動(dòng)推理服務(wù)時(shí)加載模型需要大量讀盤(pán)磁盤(pán)吞吐不夠會(huì)直接拖慢冷啟動(dòng)。我見(jiàn)過(guò)有人把模型放在默認(rèn)的 40GB 系統(tǒng)盤(pán)上結(jié)果磁盤(pán)寫(xiě)滿了不說(shuō)加載模型都要半小時(shí)。另外鏡像和快照是防呆關(guān)鍵。在完成一套環(huán)境配置后立刻做一個(gè)自定義鏡像或數(shù)據(jù)盤(pán)快照。這樣即使實(shí)例被誤刪、被回收也能快速還原。用競(jìng)價(jià)實(shí)例跑批量任務(wù)時(shí)快照更是保命工具——實(shí)例隨時(shí)可能消失但數(shù)據(jù)和環(huán)境都在快照里。3.4 云上托管推理服務(wù)與自建怎么取舍各云廠商現(xiàn)在都在推托管模型推理平臺(tái)把模型文件傳上去平臺(tái)負(fù)責(zé)拉框架、分配顯存、暴露 API。這確實(shí)省心適合以下情況團(tuán)隊(duì)沒(méi)有運(yùn)維能力、流量波動(dòng)劇烈需要自動(dòng)擴(kuò)縮容、上線的模型是常見(jiàn)開(kāi)源型號(hào)無(wú)需深度定制。但托管的代價(jià)也是實(shí)打?qū)嵉亩▋r(jià)通常比自己租卡部署貴一截框架更新依賴平臺(tái)想要調(diào)量化參數(shù)、做特殊的并發(fā)優(yōu)化往往受限。我的經(jīng)驗(yàn)是原型和 MVP 階段可以用托管服務(wù)快速跑通用戶量和調(diào)用量增長(zhǎng)到一定程度后遷到自己掌控的 GPU 云主機(jī)上成本會(huì)明顯下降。這個(gè)遷移動(dòng)作本身不復(fù)雜因?yàn)椴渴鹆鞒叹褪潜疚倪@套流程。4. 生產(chǎn)級(jí)部署全流程從一臺(tái)空機(jī)器到穩(wěn)定服務(wù)4.1 環(huán)境準(zhǔn)備驅(qū)動(dòng)、CUDA 與容器化拿到一臺(tái) GPU 云主機(jī)第一步先確認(rèn)顯卡驅(qū)動(dòng)能正常識(shí)別。執(zhí)行nvidia-smi能看到顯卡型號(hào)、驅(qū)動(dòng)版本和顯存信息說(shuō)明驅(qū)動(dòng)層面沒(méi)問(wèn)題。接下來(lái)的關(guān)鍵決策是用容器承載一切。推理服務(wù)依賴的 CUDA、Python、框架版本多且相互約束直接在宿主機(jī)上搞一個(gè)月后大概率遇到環(huán)境地獄。容器化后環(huán)境可以鏡像化分發(fā)和回滾生產(chǎn)環(huán)境的可復(fù)現(xiàn)性會(huì)好很多。# 安裝 nvidia-container-toolkit讓 Docker 能調(diào)用 GPU sudo apt-get update sudo apt-get install -y nvidia-container-toolkit sudo systemctl restart docker # 驗(yàn)證容器內(nèi)能否看到 GPU docker run --rm --gpus all nvidia/cuda:12.4.0-base-ubuntu22.04 nvidia-smi注意容器啟動(dòng)推理服務(wù)時(shí)建議加上--shm-size16g或更大的共享內(nèi)存設(shè)置否則高并發(fā)下數(shù)據(jù)交換容易卡死。這個(gè)參數(shù)不加單機(jī)并發(fā)稍高就可能出問(wèn)題。4.2 模型下載與本地驗(yàn)證模型從哪來(lái)常見(jiàn)的開(kāi)源模型托管平臺(tái)有 Hugging Face 和國(guó)內(nèi)的 ModelScope?？紤]到國(guó)內(nèi)網(wǎng)絡(luò)環(huán)境ModelScope 下載速度通常有明顯優(yōu)勢(shì)而且很多主流模型都在上面同步了權(quán)重。我一般用 ModelScope 官方命令行工具或 Python SDK 下載。下載后模型文件會(huì)是一個(gè)目錄里面包含權(quán)重文件、配置文件、tokenizer 文件。先別急著上生產(chǎn)在本地或開(kāi)發(fā)機(jī)用一段小腳本加載模型試跑一次確認(rèn)權(quán)重復(fù)現(xiàn)正常、回復(fù)質(zhì)量達(dá)標(biāo)再往服務(wù)器上放。這個(gè)驗(yàn)證步驟能省去很多部署后的排障時(shí)間——模型本身的問(wèn)題就別帶到服務(wù)層去排查。4.3 用 vLLM 啟動(dòng)一個(gè)生產(chǎn)級(jí)推理服務(wù)下面是一條經(jīng)過(guò)生產(chǎn)驗(yàn)證的 vLLM 啟動(dòng)命令我以 72B 模型 4 卡部署為例子docker run -d \ --gpus all \ --shm-size16g \ -p 8000:8000 \ -v /data/models:/models \ -v /data/cache:/root/.cache \ vllm/vllm-openai:latest \ --model /models/Qwen2.5-72B-Instruct \ --tensor-parallel-size 4 \ --max-model-len 32768 \ --gpu-memory-utilization 0.9 \ --served-model-name demo-chat \ --api-key sk-demo-xxxx逐個(gè)解釋關(guān)鍵參數(shù)這些參數(shù)背后都是真實(shí)教訓(xùn)--tensor-parallel-size指定張量并行度。4 卡設(shè)成 4讓單層權(quán)重切到 4 張卡上并行計(jì)算。如果設(shè)置與卡數(shù)不匹配要么顯存不夠要么性能浪費(fèi)就是個(gè)必須對(duì)齊的參數(shù)。--max-model-len是模型支持的最大上下文長(zhǎng)度。設(shè)太大會(huì)讓 KV Cache 預(yù)留空間過(guò)大顯存壓力陡增設(shè)太小會(huì)導(dǎo)致長(zhǎng)文本對(duì)話截?cái)鄨?bào)錯(cuò)。一般按業(yè)務(wù)真實(shí)需求設(shè)不是越大越好。--gpu-memory-utilization控制推理進(jìn)程最多吃多少顯存0.9 表示預(yù)留 10% 顯存給臨時(shí)開(kāi)銷(xiāo)和模型加載過(guò)程。不要設(shè) 1.0實(shí)測(cè)定滿容易觸發(fā)不可預(yù)期的 OOM。--served-model-name是對(duì)外暴露的模型名。這個(gè)設(shè)計(jì)挺實(shí)用相當(dāng)于給內(nèi)部模型起一個(gè)對(duì)外別名后續(xù)換模型版本只要改內(nèi)部映射不必讓調(diào)用方感知。啟動(dòng)后先用 curl 驗(yàn)證一下服務(wù)是否正常返回curl http://localhost:8000/v1/chat/completions \ -H Authorization: Bearer sk-demo-xxxx \ -H Content-Type: application/json \ -d {model:demo-chat,messages:[{role:user,content:你好}],max_tokens:100}如果返回結(jié)構(gòu)里的choices字段正常輸出內(nèi)容說(shuō)明服務(wù)已經(jīng)跑起來(lái)了。4.4 統(tǒng)一 API 網(wǎng)關(guān)鑒權(quán)、限流與路由vLLM 自帶一個(gè) OpenAI 兼容的 API 端口但它本身不解決鑒權(quán)、限流、多服務(wù)路由這些問(wèn)題。對(duì)外提供服務(wù)前建議在前面加一層統(tǒng)一網(wǎng)關(guān)。網(wǎng)關(guān)層主要做三件事第一API Key 鑒權(quán)防止服務(wù)被裸奔調(diào)用尤其在大模型按 token 計(jì)費(fèi)的業(yè)務(wù)里沒(méi)有鑒權(quán)的服務(wù)等于在給別人免費(fèi)燒錢(qián)第二限流按用戶維度限制每分鐘請(qǐng)求數(shù)防止個(gè)別調(diào)用方打滿顯卡第三路由把/v1/chat/completions的請(qǐng)求路由到 vLLM把向量查詢路由到 Embedding 服務(wù)把圖像生成路由到另外的模型實(shí)現(xiàn)統(tǒng)一入口。Nginx 足夠應(yīng)對(duì)大多數(shù)場(chǎng)景更復(fù)雜的流量治理可以上 APISIX 這類(lèi)專業(yè)網(wǎng)關(guān)。這個(gè)過(guò)程我踩過(guò)的坑是網(wǎng)關(guān)層一定要配上請(qǐng)求體和響應(yīng)體的超時(shí)時(shí)間大模型生成長(zhǎng)文本可能耗時(shí)幾十秒到幾分鐘默認(rèn)的 60 秒超時(shí)會(huì)把正常的長(zhǎng)輸出也干掉。4.5 監(jiān)控與日志沒(méi)有可觀測(cè)性就別談生產(chǎn)部署完成后最重要的一件事不是功能測(cè)試而是把監(jiān)控體系搭起來(lái)。推理服務(wù)不比普通 Web 服務(wù)瞬時(shí) GPU 狀態(tài)變化對(duì)服務(wù)質(zhì)量影響極大。必須監(jiān)控的指標(biāo)有這么幾類(lèi)延遲分位數(shù)重點(diǎn)關(guān)注首字延遲 P50/P95/P99還有單 token 生成速度。P99 飆升通常意味著資源存在瓶頸或請(qǐng)求排隊(duì)加劇。GPU 利用率與顯存水位利用率長(zhǎng)期低于 20% 說(shuō)明并發(fā)配置不足或請(qǐng)求量不夠顯存長(zhǎng)期高于 95% 則有 OOM 風(fēng)險(xiǎn)。排隊(duì)長(zhǎng)度與拒絕數(shù)并發(fā)請(qǐng)求超出框架處理能力時(shí)請(qǐng)求會(huì)排隊(duì)甚至超時(shí)這兩個(gè)指標(biāo)直接反映容量是否夠用。錯(cuò)誤碼分布5xx、429、上下文超長(zhǎng)報(bào)錯(cuò)分類(lèi)統(tǒng)計(jì)能快速定位問(wèn)題方向。實(shí)現(xiàn)上vLLM 原生暴露 Prometheus 指標(biāo)端口配合 nvidia-exporter 采集 GPU 指標(biāo)用 Prometheus 存儲(chǔ)、Grafana 畫(huà)盤(pán)。日志方面每個(gè)請(qǐng)求至少要記錄模型、輸入 token 數(shù)、輸出 token 數(shù)、耗時(shí)這些數(shù)據(jù)既是排障依據(jù)也是月底算成本的憑據(jù)。4.6 高可用與交付擴(kuò)展多副本、升級(jí)、私有化單實(shí)例部署永遠(yuǎn)存在單點(diǎn)風(fēng)險(xiǎn)。生產(chǎn)環(huán)境要有最基本的冗余至少兩個(gè)實(shí)例副本前面加負(fù)載均衡。一個(gè)實(shí)例故障時(shí)流量可以切到另一個(gè)業(yè)務(wù)不受影響。vLLM 官方也支持多實(shí)例部署配合 k8s 的擴(kuò)縮容但復(fù)雜度高團(tuán)隊(duì)規(guī)模不大時(shí)建議先用兩臺(tái)云主機(jī)加簡(jiǎn)單負(fù)載均衡的方式跑起來(lái)。版本升級(jí)同樣要注意平滑。模型更新或框架升級(jí)時(shí)先在新實(shí)例啟動(dòng)最新版本并驗(yàn)證通過(guò)再切換流量切換后保留舊實(shí)例一段時(shí)間觀察。不要直接在生產(chǎn)實(shí)例上原地升級(jí)一旦失敗現(xiàn)場(chǎng)完全沒(méi)有回滾余地。私有化交付場(chǎng)景模型權(quán)重文件通常要拷到隔離環(huán)境內(nèi)部。做法一般是準(zhǔn)備好離線模型文件、推理服務(wù)鏡像、一鍵部署腳本組成交付包配合離線安裝和校驗(yàn)流程讓客戶環(huán)境內(nèi)獨(dú)立完成部署。整個(gè)過(guò)程不依賴外部網(wǎng)絡(luò)這也是私有化部署的核心合規(guī)要求。5. 生產(chǎn)環(huán)境高頻問(wèn)題排查實(shí)錄5.1 GPU 利用率低響應(yīng)卻還是慢一個(gè)很常見(jiàn)又矛盾的場(chǎng)景看監(jiān)控 GPU 利用率只有 10%但用戶反饋?lái)憫?yīng)慢。出現(xiàn)這種情況先別急著加卡大概率是并發(fā)配置有問(wèn)題。vLLM 的max_num_seqs參數(shù)控制每個(gè) batch 能同時(shí)處理的序列數(shù)量默認(rèn)值往往偏低。在顯存允許的情況下適當(dāng)調(diào)大把并發(fā)請(qǐng)求真正拼進(jìn)同一個(gè) batchGPU 利用率才能拉起來(lái)。另一個(gè)容易被忽略的原因是請(qǐng)求生成很短。大模型推理是增量式的如果業(yè)務(wù)大量請(qǐng)求只問(wèn) 7 個(gè)字要 50 個(gè)字的回答GPU 每次只算一小段就結(jié)束算力自然用不滿。這種情況要優(yōu)化的是業(yè)務(wù)側(cè)的 prompt 設(shè)計(jì)和響應(yīng)長(zhǎng)度設(shè)定而不是硬件。5.2 顯存 OOM 與 KV Cache 的博弈OOM 排查時(shí)優(yōu)先確認(rèn)兩件事gpu-memory-utilization是否設(shè)得過(guò)高max-model-len是否虛大。這兩個(gè)參數(shù)決定顯存分配上限。如果實(shí)際業(yè)務(wù)平均上下文只有 4k卻把max-model-len設(shè)成 128kKV Cache 的預(yù)留空間會(huì)白白吃掉大量顯存。vLLM 也有顯存交換swap 到 CPU 內(nèi)存的能力理論上能緩解 OOM但代價(jià)是速度驟降。生產(chǎn)環(huán)境盡量不要依賴 swap寧可把模型量化級(jí)別調(diào)高一點(diǎn)或者減少并發(fā)數(shù)保持服務(wù)響應(yīng)質(zhì)量。5.3 推理結(jié)果質(zhì)量不穩(wěn)定不是服務(wù)故障有段時(shí)間團(tuán)隊(duì)反饋線上回答“時(shí)好時(shí)壞”我們排查了網(wǎng)關(guān)、網(wǎng)絡(luò)、超時(shí)最后發(fā)現(xiàn)是采樣參數(shù)導(dǎo)致的。模型的 temperature、top_p 設(shè)置直接影響輸出的隨機(jī)性默認(rèn)值在創(chuàng)意對(duì)話場(chǎng)景或許合適但在客服、知識(shí)問(wèn)答場(chǎng)景會(huì)讓答案飄忽不定。把 temperature 調(diào)到 0 到 0.3 區(qū)間top_p 調(diào)低一些回答的一致性和可預(yù)測(cè)性會(huì)好很多。這里要區(qū)分一個(gè)概念推理服務(wù)故障和模型效果問(wèn)題是兩個(gè)層面。服務(wù)故障表現(xiàn)為超時(shí)、報(bào)錯(cuò)、崩潰模型效果問(wèn)題表現(xiàn)為有輸出但內(nèi)容不對(duì)。排查思路完全不同前者查框架和基礎(chǔ)設(shè)施后者要回到數(shù)據(jù)、微調(diào)、提示詞優(yōu)化。我在很多團(tuán)隊(duì)身上看到它們被混為一談浪費(fèi)了大量時(shí)間。5.4 微調(diào)與部署的銜接從訓(xùn)練權(quán)重到新服務(wù)用 LLaMA-Factory 微調(diào)完模型后導(dǎo)出的是合并好的權(quán)重。要把它推向生產(chǎn)流程是推送到模型倉(cāng)庫(kù)或直接傳到 GPU 服務(wù)器的模型目錄 → 用新目錄啟動(dòng)一個(gè)新的推理實(shí)例并驗(yàn)證效果 → 確認(rèn)沒(méi)問(wèn)題后切換網(wǎng)關(guān)路由 → 保留舊實(shí)例作為回滾。整個(gè)過(guò)程在同一天內(nèi)可以完成。如果只是微調(diào)版本迭代不需要?jiǎng)踊A(chǔ)設(shè)施改模型路徑和重啟服務(wù)就行。如果換了模型架構(gòu)或 tokenizer注意前端傳參的上下文對(duì)齊方式可能變化需要重新驗(yàn)證提示詞格式。寫(xiě)在最后的一點(diǎn)個(gè)人體會(huì)部署這塊做得越久我越覺(jué)得上線前的充分驗(yàn)證比什么都重要。如果只讓我給一條最樸素的建議那就是先用小模型把整套流程跑通再換大模型。7B 模型都跑不穩(wěn)的服務(wù)直接換 70B 只會(huì)把問(wèn)題放大十倍。另外多說(shuō)一個(gè)小技巧部署完成后拿一個(gè)包含超長(zhǎng)上下文、多輪對(duì)話、并發(fā)請(qǐng)求的測(cè)試集每天定時(shí)跑一遍做健康檢查看起來(lái)笨但效果比花里胡哨的告警規(guī)則都實(shí)在。大模型服務(wù)器部署不是一個(gè)一次性的體力活而是一個(gè)需要持續(xù)維護(hù)的長(zhǎng)期系統(tǒng)把基礎(chǔ)打牢后面才有余力去優(yōu)化體驗(yàn)和成本。