2026年再回頭看大模型服務(wù)器部署這件事已經(jīng)從“能不能跑起來”徹底變成了“能不能穩(wěn)定跑下去”。開源模型的能力一年比一年強(qiáng)生態(tài)和文檔也比兩年前成熟得多但真到自己給團(tuán)隊(duì)搭生產(chǎn)環(huán)境、選框架、對比云服務(wù)的時(shí)候框架選型、云服務(wù)對比、生產(chǎn)級流程這三個(gè)詞還是會(huì)卡住不少人。尤其當(dāng)你面對的是72B級模型、多卡并行、內(nèi)網(wǎng)私有化這些現(xiàn)實(shí)需求時(shí)光靠照抄啟動(dòng)命令是遠(yuǎn)遠(yuǎn)不夠的。這篇內(nèi)容是我過去一年實(shí)際部署多套大模型服務(wù)之后的落地記錄覆蓋了推理框架怎么選、云GPU機(jī)器怎么買才不虧、從一臺(tái)裸機(jī)到穩(wěn)定對外服務(wù)要走的完整流程以及微調(diào)產(chǎn)物怎么安全接到生產(chǎn)環(huán)境。適合剛拿到GPU預(yù)算的算法工程師、要自己動(dòng)手搭私有化部署的運(yùn)維同學(xué)還有正在做技術(shù)選型的技術(shù)負(fù)責(zé)人參考。1. 動(dòng)手之前先把部署目標(biāo)想清楚1.1 2026年的部署難題模型好選工程難做我接觸過不少團(tuán)隊(duì)上來第一句話就是“我要部署一個(gè)大模型”然后開始糾結(jié)用哪個(gè)框架。但實(shí)際聊下去就會(huì)發(fā)現(xiàn)真正的問題往往不是模型而是環(huán)境。2026年這個(gè)時(shí)間點(diǎn)開源模型的選擇已經(jīng)非常豐富輕量級的7B、14B到能力接近閉源一線的72B甚至更大規(guī)模通用對話、代碼、多模態(tài)各有各的好手。API調(diào)用也很便宜很多場景完全沒必要自己部署。那為什么還有這么多人堅(jiān)持自建服務(wù)器我總結(jié)下來無非三個(gè)原因數(shù)據(jù)不能出域、長期成本想可控、需要深度定制。數(shù)據(jù)不能出域是大多數(shù)企業(yè)私有化部署的硬理由。金融、醫(yī)療、政務(wù)、企業(yè)內(nèi)部知識(shí)庫這些場景的數(shù)據(jù)級別決定了你根本不能把文本丟給外部API只能在自己的機(jī)房或云主機(jī)上跑。長期成本方面如果業(yè)務(wù)量穩(wěn)定在每天幾十萬token自建GPU服務(wù)器的邊際成本會(huì)明顯低于按量調(diào)用外部API。深度定制則更直接微調(diào)、LoRA、領(lǐng)域知識(shí)注入這些都需要你有模型權(quán)重和推理環(huán)境的完整掌控權(quán)。但問題也隨之而來——部署這件事不再是“git clone pip install 跑起來”就完事。你需要面對多卡并行怎么切、量化精度損失多少、并發(fā)上來以后KV Cache會(huì)不會(huì)爆、模型文件怎么在內(nèi)網(wǎng)分發(fā)、服務(wù)掛了怎么恢復(fù)。這一整套問題就是標(biāo)題里說的“生產(chǎn)級流程”的分量所在。1.2 場景決定一切在線推理、離線批處理、微調(diào)訓(xùn)練是三條不同的路我在幫團(tuán)隊(duì)做架構(gòu)方案時(shí)第一件事永遠(yuǎn)是逼他們把場景說清楚。因?yàn)椴煌瑘鼍皩λ懔Α⒖蚣?、服?wù)器的要求差異大到可以讓你前面的所有選型全部作廢。在線推理服務(wù)是大家最熟悉的場景客服機(jī)器人、知識(shí)庫問答、寫代碼助手、內(nèi)容生成。這類服務(wù)7×24小時(shí)跑著核心指標(biāo)是首Token延遲、單Token生成速度、并發(fā)吞吐和穩(wěn)定性。此時(shí)你需要的是高性能推理引擎比如vLLM、SGLang配合合理的并發(fā)控制。它關(guān)注的是怎么讓顯存被高效利用、怎么讓多個(gè)請求交錯(cuò)不排隊(duì)。離線批量處理則完全不同批量文檔解析、知識(shí)抽取、數(shù)據(jù)標(biāo)注、報(bào)表生成。這類任務(wù)可以排隊(duì)、可以跑幾個(gè)小時(shí)但對單位時(shí)間的吞吐量有要求。此時(shí)你不一定需要最頂尖的推理引擎Ollama、LMDeploy甚至直接用批量腳本都能勝任關(guān)鍵是做好任務(wù)隊(duì)列和失敗重試。比如之前熱詞里提到的知識(shí)抽取框架OneKE本質(zhì)上就是這類離線任務(wù)對吞吐的要求遠(yuǎn)高于對單請求延遲的要求。微調(diào)訓(xùn)練又是一條獨(dú)立的路。它吃顯存、吃算力、吃多卡通信帶寬用的是LLaMA-Factory、MS Swift這類訓(xùn)練框架和推理框架完全是兩套體系。很多人混淆了“部署一個(gè)微調(diào)環(huán)境”和“部署一個(gè)推理服務(wù)”結(jié)果買了一堆推理卡去跑訓(xùn)練效率慘不忍睹。另外還有一類就是多模態(tài)部署涉及圖像、語音、視頻編碼器對特定的算子庫和依賴版本有要求不再是單單一個(gè)transformers就能搞定的。訊飛實(shí)時(shí)語音轉(zhuǎn)寫這類場景前端適配、流式處理、推理引擎的流式接口都要單獨(dú)設(shè)計(jì)。所以第一步一定是定義場景而不是問用什么框架。1.3 預(yù)算、團(tuán)隊(duì)能力和合規(guī)約束比框架更先定調(diào)很多技術(shù)選型最后死掉不是死在框架不夠強(qiáng)而是死在預(yù)算和運(yùn)維能力上。先說預(yù)算。GPU服務(wù)器的成本大頭在顯卡。一張A100/H100級別的卡按量計(jì)費(fèi)每小時(shí)就是幾十元甚至上百元的量級一個(gè)月跑下來輕松超過一臺(tái)中配燃油車的月供。包年會(huì)有明顯折扣但需要你一次性投入競價(jià)實(shí)例便宜但實(shí)例隨時(shí)可能被回收只適合離線任務(wù)。這些計(jì)費(fèi)模式直接決定你的架構(gòu)是按量臨時(shí)跑還是包年撐長期服務(wù)還是競價(jià)實(shí)例扛批處理。再說團(tuán)隊(duì)能力。如果團(tuán)隊(duì)里只有一位同時(shí)懂算法和Linux的工程師我強(qiáng)烈建議不要一上來就上Kubernetes——那是給自己找罪受。單機(jī)Docker加systemd再加一個(gè)簡單的監(jiān)控就能覆蓋大多數(shù)中小團(tuán)隊(duì)的90%需求。反過來說如果有專職運(yùn)維多節(jié)點(diǎn)高可用、自動(dòng)擴(kuò)縮容才有意義。還有合規(guī)約束。有些業(yè)務(wù)明確要求數(shù)據(jù)必須留在內(nèi)網(wǎng)這時(shí)候你連公有云的GPU機(jī)器都不能直連外網(wǎng)拉模型必須走完整的內(nèi)網(wǎng)分發(fā)流程模型文件先下載到安全區(qū)再拷貝到機(jī)房或VPC內(nèi)。這個(gè)流程本身也是一大塊工作。Dify接入本地大模型這類需求之所以火正是因?yàn)槠髽I(yè)既要本地模型的能力又要通過Dify這種平臺(tái)去管知識(shí)庫和Agent鏈條一下子就長了。2. 推理框架選型2026年該用什么2.1 主流框架橫向?qū)Ρ葀LLM、SGLang、Ollama、TensorRT-LLM框架選型是所有部署工作的第一道分水嶺。我2026年的結(jié)論是生產(chǎn)環(huán)境基本被vLLM和SGLang統(tǒng)治Ollama留在開發(fā)和個(gè)人場景TensorRT-LLM偏極致優(yōu)化LMDeploy是國產(chǎn)方案里的穩(wěn)妥選擇。vLLM是當(dāng)前生態(tài)最廣、社區(qū)最活躍的推理框架。它的核心優(yōu)勢是PagedAttention顯存分頁管理和Continuous Batching連續(xù)批處理前者大幅提升了顯存利用率后者讓多個(gè)請求可以動(dòng)態(tài)拼批而不是傻等一個(gè)batch跑完。它對OpenAI接口的兼容做得最全幾乎所有上層應(yīng)用都能直接對接。生產(chǎn)環(huán)境如果不知道選什么選vLLM是大概率不會(huì)錯(cuò)的決定。SGLang用RadixAttention做前綴緩存對RAG這類長前綴重復(fù)場景收益非常明顯調(diào)度器做得更細(xì)對長上下文和復(fù)雜推理任務(wù)的控制更強(qiáng)。前兩年DeepSeek推理服務(wù)的走紅也讓SGLang的關(guān)注度上了一個(gè)臺(tái)階。如果你的場景是大量文檔問答、Agent多輪調(diào)用、上下文動(dòng)不動(dòng)幾萬tokenSGLang的吞吐優(yōu)勢會(huì)讓你覺得換得值。Ollama的強(qiáng)項(xiàng)是“零門檻”三個(gè)字。下載安裝拉模型一條命令起服務(wù)底層甚至也能切到vLLM這類高性能后端。但默認(rèn)情況下它的并發(fā)和吞吐能力遠(yuǎn)不如vLLM而且精細(xì)參數(shù)控制能力弱。適合個(gè)人電腦、十幾人小團(tuán)隊(duì)內(nèi)部試用或者作為模型管理工具存在。一旦業(yè)務(wù)開始有穩(wěn)定并發(fā)就要考慮遷到vLLM。TensorRT-LLM是NVIDIA自家的優(yōu)化方案能做到最低延遲、最高吞吐代價(jià)是模型需要編譯優(yōu)化裝環(huán)境、排依賴的工程量大得多而且基本綁死在N卡生態(tài)。除非你的延遲要求極其苛刻、且有人力長期維護(hù)否則不建議作為第一選擇。LMDeploy是國產(chǎn)框架里做得比較扎實(shí)的上手簡單推理性能也不錯(cuò)對很多國產(chǎn)芯片和中文文檔環(huán)境的適配更好。如果團(tuán)隊(duì)有國產(chǎn)化要求或者想要一個(gè)中文資料更友好的框架它可以和vLLM并列放進(jìn)候選名單。框架核心優(yōu)勢典型場景上手難度生產(chǎn)推薦度vLLM生態(tài)最廣、PagedAttention、OpenAI兼容絕大多數(shù)在線推理中等首選SGLang前綴緩存、長上下文調(diào)度強(qiáng)RAG、Agent、長文檔問答中等強(qiáng)力候選Ollama一鍵部署、模型管理簡單個(gè)人開發(fā)、小團(tuán)隊(duì)試用很低僅限輕量場景TensorRT-LLMNVIDIA極致優(yōu)化、低延遲苛刻延遲要求的N卡環(huán)境高評估后選用LMDeploy國產(chǎn)化、易用、文檔友好國產(chǎn)芯片/內(nèi)部環(huán)境低合規(guī)備選2.2 我的選型組合與決策邏輯我不太喜歡把架構(gòu)搞得很復(fù)雜所以給團(tuán)隊(duì)做方案時(shí)用的是這樣一套決策邏輯。第一檔個(gè)人開發(fā)、內(nèi)部demo、并發(fā)個(gè)位數(shù)直接用Ollama跑省心。模型用Qwen系列或者Llama系列的量化版本一張消費(fèi)級顯卡就能帶起來。這一檔不追求吞吐追求的是快速驗(yàn)證。第二檔正式的在線服務(wù)、預(yù)計(jì)并發(fā)幾十到幾百用vLLM模型選擇量化后單卡或雙卡能扛住的規(guī)模比如Qwen2.5-14B或72B的AWQ量化版。vLLM的OpenAI接口可以直接對接業(yè)務(wù)代碼也可以接Dify這類應(yīng)用平臺(tái)。這是我最推薦的“默認(rèn)組合”。第三檔大量RAG、Agent、長上下文場景換SGLang。它在前綴緩存上省出來的算力可能直接讓你的響應(yīng)速度快一倍尤其多輪對話里每輪都在反復(fù)處理相同知識(shí)庫上下文的時(shí)候差距明顯。第四檔極致性能、純N卡、團(tuán)隊(duì)有工程人力TensorRT-LLM。我自己只在第三方評測環(huán)境里用過做產(chǎn)品我不太愿意碰它因?yàn)槊看螕Q模型都等于重新走一遍編譯和調(diào)優(yōu)ROI不高。還有一個(gè)原則不要雙線并行?？吹揭粋€(gè)新框架火了就馬上切換會(huì)讓團(tuán)隊(duì)把大量時(shí)間花在遷移上。vLLM打底、SGLang作為長上下文特型方案、Ollama做開發(fā)調(diào)試這個(gè)組合我自己用了一年多基本覆蓋了所有業(yè)務(wù)場景。2.3 容易被忽略但決定成敗的部署參數(shù)很多人部署vLLM只知道填個(gè)模型路徑但真正影響服務(wù)穩(wěn)定性的是一些不起眼的小參數(shù)。量化精度是一切的起點(diǎn)。FP16的70B模型需要約140GB顯存兩張80G卡剛好放下但KV Cache就沒多少空間了換成AWQ 4bit量化權(quán)重降到約35GB單張80G卡就富余很多。代價(jià)是量化后模型會(huì)有一定的質(zhì)量損失通常不明顯但如果你做的是代碼生成、數(shù)學(xué)推理這類任務(wù)最好拿評測集實(shí)測對比一下。max-model-len是顯存規(guī)劃的關(guān)鍵。它決定模型最大支持的上下文長度而這個(gè)長度直接決定了KV Cache能占多大。上下文長度設(shè)得越大能同時(shí)服務(wù)的并發(fā)數(shù)就越少。很多OOM問題不是模型太大而是這個(gè)值設(shè)得太狠。gpu-memory-utilization建議不要設(shè)滿。我一般設(shè)0.85到0.93之間留出一點(diǎn)顯存給CUDA上下文、臨時(shí)張量和偶發(fā)峰值否則稍有波動(dòng)就可能OOM。max-num-seqs控制的是并發(fā)batch上限。設(shè)小了吞吐上不去設(shè)大了顯存扛不住。要根據(jù)壓測結(jié)果慢慢調(diào)而不是拍腦袋。prefix caching在vLLM和SGLang里都建議開啟。RAG場景下用戶問題不同但知識(shí)上下文相同緩存能省掉大量重復(fù)計(jì)算。實(shí)測某些問答場景開啟后吞吐能提升30%以上。speculative decoding投機(jī)解碼也是一項(xiàng)有價(jià)值的優(yōu)化用一個(gè)小模型先草擬多個(gè)token大模型一次驗(yàn)證從而加速生成。前提是你有額外顯存來放草稿模型且場景以批量或高并發(fā)為主。3. 云服務(wù)器怎么選從GPU型號(hào)到成本測算3.1 選云GPU主機(jī)的五個(gè)關(guān)鍵指標(biāo)云GPU主機(jī)的選型不少人只看“多少G顯存”但實(shí)際部署后你會(huì)發(fā)現(xiàn)還有四個(gè)指標(biāo)同樣決定體驗(yàn)。第一是GPU型號(hào)與顯存。模型能跑起來靠的是顯存容量跑得快不快靠的是算力。以2026年常見的幾款為例A100/A800 80G適合大模型推理和中等規(guī)模微調(diào)H20是不少云廠商主推的合規(guī)選擇算力不弱、顯存大L40S 48G是視頻生成和推理的常見選擇A10 24G適合輕量模型和開發(fā)調(diào)試消費(fèi)級的4090 24G在小團(tuán)隊(duì)和個(gè)人項(xiàng)目里也很常見但大規(guī)模生產(chǎn)要謹(jǐn)慎。還有昇騰系列這些國產(chǎn)芯片生態(tài)越來越成熟vLLM等主流框架已有官方適配。第二是卡間互聯(lián)帶寬。當(dāng)你需要多卡跑一個(gè)70B以上模型Tensor Parallel并行策略會(huì)讓顯卡之間高頻通信。A100/A800之間的NVLink帶寬接近600GB/s而PCIe只能到幾十GB/s差了一個(gè)數(shù)量級。我見過有人用四張PCIe互聯(lián)的卡跑72B模型推理速度比兩張NVLink互聯(lián)的卡還慢。所以預(yù)算里卡間互聯(lián)的優(yōu)先級僅次于顯存本身。第三是內(nèi)網(wǎng)帶寬。模型文件動(dòng)輒幾十GB從對象存儲(chǔ)拉到GPU機(jī)器如果內(nèi)網(wǎng)帶寬小光下載模型就要一小時(shí)。分布式推理時(shí)不同機(jī)器之間還要同步中間結(jié)果網(wǎng)絡(luò)一慢就是災(zāi)難。第四是云盤IOPS。很多人忽略這一點(diǎn)。模型加載、KV Cache寫入刷盤、日志落盤全都依賴云盤性能。模型放高IOPS的SSD上加載時(shí)間能從10分鐘降到2分鐘放普通HDD上光啟動(dòng)就能讓人崩潰。第五才是計(jì)費(fèi)模式按量、包年、競價(jià)實(shí)例的取舍直接關(guān)系你每個(gè)月的成本我下面詳細(xì)算一筆賬。3.2 主流云服務(wù)對比與真實(shí)成本測算云廠商的選擇維度不只是價(jià)格。我評估過阿里云、騰訊云、華為云、AWS、Azure這幾家主流平臺(tái)給團(tuán)隊(duì)的參考維度是這么幾條GPU型號(hào)覆蓋度A100/H100/L40S/昇騰這些算力卡是否齊全能不能支撐后續(xù)擴(kuò)容國產(chǎn)芯片選項(xiàng)有國產(chǎn)化合規(guī)需求時(shí)昇騰這類方案是否成熟主流框架適配度如何計(jì)費(fèi)靈活性按量、包年、競價(jià)實(shí)例的搭配是否方便能不能自動(dòng)釋放運(yùn)維生態(tài)監(jiān)控、安全組、容器服務(wù)、對象存儲(chǔ)這些周邊是否好用出海場景如果你的業(yè)務(wù)部署在海外AWS和Azure的全球覆蓋優(yōu)勢明顯。具體到成本測算我用一個(gè)真實(shí)的70B模型部署來算。模型選用Qwen2.5-72B的AWQ量化版權(quán)重約35GB推理時(shí)KV Cache預(yù)留20GB到30GB總計(jì)約65GB所以一張80G顯卡就夠。按當(dāng)前公開市場的量級估算方案規(guī)格計(jì)費(fèi)模式月成本量級適用場景方案A1×A100/A800 80G按量數(shù)萬元量級短期測試、彈性突發(fā)方案B1×A100/A800 80G包年/預(yù)留數(shù)千到上萬元量級長期在線服務(wù)方案C4×A10 24G包年與方案B接近多模型共存、開發(fā)環(huán)境方案D競價(jià)實(shí)例按量約為按量兩三成離線批處理、評測這個(gè)表格只是量級參考具體價(jià)格各平臺(tái)會(huì)有差異。核心結(jié)論是在線服務(wù)長期跑一定要轉(zhuǎn)包年或預(yù)留實(shí)例離線任務(wù)能接受中斷就上競價(jià)實(shí)例不確定業(yè)務(wù)量的時(shí)候按量先測一個(gè)月再?zèng)Q定。另外再推薦一個(gè)算賬思路用“單token成本”來評估你的部署值不值。拿月總成本除以月輸出token數(shù)得到每個(gè)token的部署成本再去和外部API價(jià)格對比。如果明顯更低自建的意義就成立了。3.3 網(wǎng)絡(luò)、存儲(chǔ)、安全組與遠(yuǎn)程運(yùn)維細(xì)節(jié)選好機(jī)器之后網(wǎng)絡(luò)和安全組配置是很多人踩坑的地方。安全組原則是最小開放。GPU機(jī)器上只開放必需的端口比如推理服務(wù)的8000端口只允許反向代理IP訪問SSH端口只允許公司IP訪問數(shù)據(jù)庫端口一律不對外。API服務(wù)不要直接暴露公網(wǎng)。前端業(yè)務(wù)通過Nginx或其他網(wǎng)關(guān)轉(zhuǎn)發(fā)到內(nèi)網(wǎng)的vLLM服務(wù)這樣既安全又方便做限流和審計(jì)。模型文件一定要放在高性能云盤或SSD數(shù)據(jù)盤。大模型加載時(shí)要把幾百GB權(quán)重讀進(jìn)顯存磁盤IOPS低的話加載耗時(shí)能讓人懷疑服務(wù)器是不是壞了。有條件的話把模型放在NVMe SSD上加載時(shí)間會(huì)明顯縮短。遠(yuǎn)程運(yùn)維方面我個(gè)人的習(xí)慣是不依賴公網(wǎng)IP暴露。比如你在家里想連回辦公室或IDC機(jī)房的GPU機(jī)器查看訓(xùn)練日志可以用frp這類內(nèi)網(wǎng)穿透工具把SSH端口或可視化面板端口透傳出來。這種做法不是把服務(wù)暴露到公網(wǎng)而是給自己留一條管理通道配好訪問認(rèn)證之后遠(yuǎn)程維護(hù)會(huì)方便很多——尤其是半夜接到告警又沒法立刻到機(jī)房的時(shí)候這條通道能救急。國內(nèi)也有不少云廠商提供成熟的運(yùn)維堡壘機(jī)方案團(tuán)隊(duì)有條件可以優(yōu)先用堡壘機(jī)。容器鏡像和模型倉庫也建議實(shí)現(xiàn)內(nèi)網(wǎng)化。生產(chǎn)環(huán)境里鏡像從內(nèi)網(wǎng)registry拉取模型文件從內(nèi)網(wǎng)對象存儲(chǔ)或NAS加載依賴包從內(nèi)網(wǎng)pip源安裝。這樣既避免公網(wǎng)流量費(fèi)用也符合數(shù)據(jù)合規(guī)的硬性要求。我看到很多團(tuán)隊(duì)部署失敗最后查明原因居然是下載模型超時(shí)——換成內(nèi)網(wǎng)分發(fā)之后這個(gè)問題直接消失。4. 生產(chǎn)級部署流程從裸機(jī)到可用服務(wù)4.1 環(huán)境初始化驅(qū)動(dòng)、容器運(yùn)行時(shí)與模型分發(fā)拿到一臺(tái)全新的GPU云主機(jī)我是按這個(gè)順序初始化的第一步檢查GPU驅(qū)動(dòng)。跑一句nvidia-smi看能不能正常輸出顯卡信息確認(rèn)驅(qū)動(dòng)版本和CUDA版本。如果是全新系統(tǒng)大概率需要先安裝NVIDIA驅(qū)動(dòng)和CUDA toolkit。這里有個(gè)經(jīng)驗(yàn)GPU機(jī)器上盡量用Docker跑大模型而不是直接在宿主機(jī)的Python環(huán)境里裝。因?yàn)橥评砜蚣軐UDA、PyTorch、Transformer的版本組合非常敏感直接裝在宿主機(jī)上升級一次驅(qū)動(dòng)可能就把環(huán)境搞壞。Docker鏡像把整個(gè)依賴鏈固化下來部署和遷移都干凈很多。第二步裝NVIDIA Container Toolkit讓Docker能訪問GPU# Ubuntu/Debian系安裝nvidia-container-toolkit distribution$(. /etc/os-release;echo $ID$VERSION_ID) curl -s -L https://nvidia.github.io/libnvidia-container/gpgkey | sudo apt-key add - curl -s -L https://nvidia.github.io/libnvidia-container/$distribution/libnvidia-container.list | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list sudo apt-get update sudo apt-get install -y nvidia-container-toolkit sudo systemctl restart docker第三步配置Docker默認(rèn)使用NVIDIA運(yùn)行時(shí)sudo nvidia-ctk runtime configure --runtimedocker sudo systemctl restart docker # 驗(yàn)證 docker run --rm --gpus all nvidia/cuda:12.3.1-base-ubuntu22.04 nvidia-smi第四步準(zhǔn)備模型文件。生產(chǎn)環(huán)境下載模型我推薦優(yōu)先用ModelScope魔搭而不是直接從Hugging Face拉。一是國內(nèi)網(wǎng)絡(luò)穩(wěn)定二是支持命令行工具方便做腳本化和內(nèi)網(wǎng)分發(fā)pip install modelscope modelscope download --model Qwen/Qwen2.5-72B-Instruct-AWQ --local_dir /data/models/Qwen2.5-72B-Instruct-AWQ下載完成后模型目錄結(jié)構(gòu)就是標(biāo)準(zhǔn)的Hugging Face格式包含config.json、權(quán)重文件、tokenizer等。如果公司有內(nèi)網(wǎng)對象存儲(chǔ)把這整個(gè)目錄傳到內(nèi)網(wǎng)其他機(jī)器直接內(nèi)網(wǎng)拉取速度比公網(wǎng)快得多。4.2 用vLLM拉起推理服務(wù)Docker命令逐參數(shù)解讀環(huán)境就緒后我用vLLM的官方Docker鏡像啟動(dòng)推理服務(wù)。下面這條命令是我在2×A100 80G機(jī)器上跑Qwen2.5-72B-Instruct-AWQ時(shí)的完整寫法docker run --runtime nvidia --gpus all \ -v /data/models:/models \ -p 8000:8000 \ vllm/vllm-openai:latest \ --model /models/Qwen2.5-72B-Instruct-AWQ \ --served-model-name qwen72b \ --tensor-parallel-size 2 \ --max-model-len 32768 \ --gpu-memory-utilization 0.9 \ --max-num-seqs 64 \ --enable-prefix-caching \ --api-key sk-token-xxx逐參數(shù)解釋一下關(guān)鍵點(diǎn)--tensor-parallel-size 22張卡做張量并行單卡放不下模型權(quán)重和KV Cache時(shí)必須用。粗粒度并行度不是越高越好通信開銷會(huì)吃掉收益。--max-model-len 32768最大上下文長度。顯存緊張就調(diào)低到16384空間立刻釋放出來。--gpu-memory-utilization 0.9給顯存留10%余量別設(shè)1.0。--enable-prefix-caching開啟前綴緩存。RAG和Agent場景強(qiáng)烈建議開。--api-keyvLLM自帶接口鑒權(quán)生產(chǎn)環(huán)境必須加。啟動(dòng)后先用curl驗(yàn)證服務(wù)是否正常curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer sk-token-xxx \ -d { model: qwen72b, messages: [{role: user, content: 你好介紹一下你自己}], max_tokens: 256 }返回正常的OpenAI格式結(jié)果就說明服務(wù)通了。為了生產(chǎn)級穩(wěn)定性我還會(huì)把容器納入 systemd 管理設(shè)置開機(jī)自啟和異常自動(dòng)拉起或者用 docker compose 管理環(huán)境變量和啟動(dòng)參數(shù)方便以后升級時(shí)只改一行鏡像版本。4.3 壓測與容量規(guī)劃用數(shù)據(jù)決定并發(fā)上限服務(wù)跑起來只是開始我得知道它到底能扛多少并發(fā)、輸出速度多少才能決定線上給業(yè)務(wù)分配多少流量。壓測是這步的關(guān)鍵。我用的是oha這個(gè)開壓測工具簡單、輸出清晰oha -z 60s -c 32 -m POST \ -H Content-Type: application/json \ -H Authorization: Bearer sk-token-xxx \ -d {model:qwen72b,messages:[{role:user,content:寫一段產(chǎn)品介紹}],max_tokens:128} \ http://localhost:8000/v1/chat/completions-z 60s表示持續(xù)壓測60秒-c 32表示32個(gè)并發(fā)連接。壓測后重點(diǎn)看幾個(gè)指標(biāo)吞吐每秒生成多少tokenTPOT單Token生成時(shí)間每個(gè)token平均生成耗時(shí)錯(cuò)誤率請求失敗比例P99延遲最慢的那批請求耗時(shí)。我記錄了一份典型數(shù)據(jù)2×A80G跑72B AWQmax-model-len32768并發(fā)數(shù)吞吐(tokens/s)P99 TPOT(ms)錯(cuò)誤率8約1200900%16約18001300%32約24001800.2%64約29002601.8%從這個(gè)結(jié)果看32并發(fā)以內(nèi)是比較舒適的工作區(qū)間64并發(fā)開始錯(cuò)誤率上升說明已經(jīng)接近上限。容量規(guī)劃的經(jīng)驗(yàn)公式是預(yù)估線上峰值QPS乘以單請求平均生成token數(shù)得到需要的吞吐能力再除以0.7留30%余量。比如線上預(yù)測峰值5 QPS、平均每個(gè)請求生成200 token需要1000 tokens/s的吞吐那么這個(gè)服務(wù)至少得按能跑1400 tokens/s來規(guī)劃也就是并發(fā)控制在16以內(nèi)比較安全。4.4 監(jiān)控告警與服務(wù)高可用生產(chǎn)服務(wù)不能“跑起來就不管”。vLLM內(nèi)置了Prometheus指標(biāo)接口默認(rèn)通過/metrics暴露。我配合Prometheus加Grafana搭了一套基礎(chǔ)監(jiān)控。監(jiān)控里我重點(diǎn)盯這幾個(gè)指標(biāo)gpu_utilization和顯存占用確認(rèn)GPU沒有被閑置或打滿kv_cache_usage_percKV Cache使用率超過80%意味著快OOM了request_success成功率掉到99%以下要警覺request_queue排隊(duì)請求數(shù)持續(xù)增高說明后端處理不過來了。告警規(guī)則我用表格整理一下方便直接抄告警項(xiàng)觸發(fā)條件處理動(dòng)作KV Cache使用率連續(xù)1分鐘80%降低并發(fā)、縮短max-model-len、擴(kuò)容請求錯(cuò)誤率連續(xù)5分鐘1%查看后端日志、檢查GPU狀態(tài)、重啟容器GPU顯存不足出現(xiàn)OOM事件降低max-num-seqs、換量化模型、加卡機(jī)器溫度過高連續(xù)10分鐘85°C檢查風(fēng)扇/散熱、降低負(fù)載高可用層面如果預(yù)算允許我會(huì)用兩臺(tái)GPU機(jī)器前面放一個(gè)負(fù)載均衡器Nginx做輪詢或最少連接后端分別指到兩臺(tái)機(jī)器的vLLM服務(wù)。這樣單臺(tái)故障時(shí)流量自動(dòng)切到另一臺(tái)業(yè)務(wù)無感。兩臺(tái)機(jī)器之間用健康檢查接口持續(xù)探測比如每10秒請求一次/health。至于Kubernetes我的判斷是不到多模型、多團(tuán)隊(duì)、需要按流量自動(dòng)擴(kuò)縮容的程度不要主動(dòng)上。單機(jī)加負(fù)載均衡就足夠支撐絕大多數(shù)中小團(tuán)隊(duì)。K8s帶來的運(yùn)維復(fù)雜度不是所有人都能消化得起的。5. 微調(diào)之后的模型怎么安全接到生產(chǎn)5.1 主流微調(diào)工具選型與產(chǎn)物格式說明部署不只是把開源原版模型跑起來很多業(yè)務(wù)最終要走到微調(diào)這一步。工具選型直接影響后面部署的順暢程度。當(dāng)前主流微調(diào)工具里L(fēng)LaMA-Factory是我最常用也最推薦的一款。它把LoRA、QLoRA、全參微調(diào)、DPO這些常見方案都封裝好了命令行和WebUI都有中文資料豐富新手也能快速上手。MS Swift是魔搭生態(tài)里的微調(diào)工具和ModelScope的數(shù)據(jù)集、模型庫結(jié)合很緊密國產(chǎn)化環(huán)境下用起來很順手。Axolotl更偏研究型配置靈活度高但上手門檻也高。Unsloth的優(yōu)勢是速度和顯存優(yōu)化都做得很好適合在意訓(xùn)練耗時(shí)的場景。微調(diào)完的產(chǎn)物格式需要提前想清楚。常用的幾種HF格式全量權(quán)重微調(diào)后直接導(dǎo)出整個(gè)模型目錄可以加載到vLLM里跑LoRA Adapter只保存增量權(quán)重部署時(shí)合并到基座GGUF格式給llama.cpp和Ollama用的量化格式適合單機(jī)CPU/混合推理AWQ/GPTQ量化格式推理性能好適合vLLM、SGLang生產(chǎn)部署。如果訓(xùn)練時(shí)只保存了LoRA adapter部署前必須先合并成完整權(quán)重否則沒法直接喂給vLLM。5.2 LoRA合并、量化轉(zhuǎn)換與權(quán)重驗(yàn)證用LLaMA-Factory導(dǎo)出合并后的模型命令大致是CUDA_VISIBLE_DEVICES0 python -m llamafactory.cli export \ --model_name_or_path /data/models/Qwen2.5-7B \ --adapter_name_or_path /data/train/output_lora \ --template qwen \ --finetuning_type lora \ --export_dir /data/models/Qwen2.5-7B-finetuned \ --export_size 4 \ --export_legacy_format false這條命令的作用是把基座模型和LoRA adapter合并成一個(gè)完整的HF格式模型目錄。合并之后再用vLLM加載驗(yàn)證一遍跑幾個(gè)訓(xùn)練集里的問題看輸出是否符合預(yù)期同時(shí)確認(rèn)--max-model-len、量化配置等參數(shù)正常。如果生產(chǎn)環(huán)境顯存緊張合并后的模型再做AWQ量化。我用的是autoawqpip install autoawq python -m awq.entry \ --model_path /data/models/Qwen2.5-7B-finetuned \ --quant_path /data/models/Qwen2.5-7B-finetuned-AWQ \ --quant_method awq \ --bits 4量化完成后用vLLM加載AWQ模型再跑一輪評測確認(rèn)質(zhì)量損失在可接受范圍。GGUF轉(zhuǎn)換則用llama.cpp倉庫里的convert.py腳本轉(zhuǎn)換完喂給Ollama即可。這里有一個(gè)核心經(jīng)驗(yàn)每次轉(zhuǎn)換都重新做一次質(zhì)量評測不要假設(shè)轉(zhuǎn)換是無損的。5.3 上線前評測、灰度與回滾策略微調(diào)模型上線前我堅(jiān)持要做一套標(biāo)準(zhǔn)化的評測流程。評測集從業(yè)務(wù)真實(shí)問題里抽100到200條覆蓋主要場景和邊界情況比如長文本、多輪追問、模糊提問、敏感話題等。打分方式可以是人工評分也可以用LLM judge但評判標(biāo)準(zhǔn)必須固定否則沒法在不同模型版本之間對比。上線策略上我沿用這套流程新舊模型對比評測微調(diào)版和原版在評測集上跑一遍記錄準(zhǔn)確率、拒答率、字?jǐn)?shù)控制等指標(biāo)灰度發(fā)布在負(fù)載均衡層把5%到10%的流量切到新模型跑一兩天觀察業(yè)務(wù)反饋和錯(cuò)誤率全量發(fā)布灰度沒問題再逐步放大流量回滾預(yù)案模型目錄帶版本號(hào)比如/data/models/qwen7b-finetuned-v3容器鏡像tag也對應(yīng)版本。一旦發(fā)現(xiàn)異常改一行配置把流量切回舊模型目錄重啟容器即可。版本化是這一節(jié)里最容易被忽略的細(xì)節(jié)。沒有版本號(hào)的模型目錄上線一個(gè)月后你根本分不清線上跑的是哪個(gè)權(quán)重回滾也無從談起。6. 生產(chǎn)環(huán)境常見問題排查實(shí)錄6.1 顯存OOM與KV Cache溢出OOMOut of Memory是GPU部署里最常見的故障沒有之一。癥狀是vLLM日志直接報(bào)CUDA out of memory或者容器被操作系統(tǒng)殺掉服務(wù)靜默掛掉。我排查OOM的順序是固定的看nvidia-smi確認(rèn)當(dāng)前顯存占用情況看vLLM啟動(dòng)日志確認(rèn)KV Cache預(yù)留了多少顯存看最近一次請求的上下文長度是不是有個(gè)別超長請求把顯存吃爆了看max-num-seqs是不是并發(fā)batch過大。根據(jù)原因?qū)ΠY下藥常見原因解決辦法max-model-len設(shè)得過大調(diào)小到實(shí)際業(yè)務(wù)需要比如16384或8192并發(fā)請求數(shù)過高降低max-num-seqs限制同時(shí)處理的請求數(shù)gpu-memory-utilization設(shè)滿降到0.85到0.9留出峰值余量模型太大換AWQ/GPTQ量化版或多卡tensor-parallel并行KV Cache使用率持續(xù)高位開啟prefix caching、限制單請求長度6.2 首Token延遲高與吞吐上不去另一個(gè)高頻問題是服務(wù)響應(yīng)慢或者并發(fā)一上來吞吐就卡死。首Token延遲高我先看幾個(gè)點(diǎn)是不是CUDA graph沒有預(yù)熱vLLM第一次請求會(huì)觸發(fā)kernel編譯之后才快。解決辦法是啟動(dòng)后發(fā)一條短請求預(yù)熱模型文件是不是放在HDD上權(quán)重加載慢會(huì)拖慢冷啟動(dòng)且服務(wù)啟動(dòng)后首次推理要等權(quán)重全進(jìn)顯存。模型挪到SSD上能明顯改善是不是沒開prefix cachingRAG場景下前綴重復(fù)計(jì)算會(huì)拖慢每個(gè)請求。開啟后立竿見影最大上下文長度過大導(dǎo)致KV Cache碎片化調(diào)小max-model-len能減少碎片。吞吐上不去則優(yōu)先檢查并發(fā)和調(diào)度設(shè)置。max-num-seqs太小會(huì)導(dǎo)致GPU利用率不足調(diào)度不了足夠多請求TP設(shè)置不合理則通信開銷吃掉算力另外確認(rèn)一下是不是沒有開啟Continuous Batching——vLLM默認(rèn)開啟但如果用了舊版本或某些參數(shù)配置可能退化成靜態(tài)批處理。6.3 接口安全、限流與穩(wěn)定性加固最后說安全。很多人部署完大模型第一件事是把接口地址發(fā)給前端開發(fā)這其實(shí)特別危險(xiǎn)。沒有鑒權(quán)的OpenAI兼容接口等于把服務(wù)裸奔在公網(wǎng)上誰都能來白嫖你的算力甚至可能被惡意灌垃圾請求打爆。我的加固方案是這樣vLLM啟動(dòng)時(shí)加--api-key所有請求帶Authorization: Bearer頭外側(cè)再加一層Nginx反向代理做IP白名單和請求體大小限制Nginx層限流比如每個(gè)IP每分鐘最多60次請求防止突發(fā)流量打掛后端健康檢查走獨(dú)立路徑/health放行/v1/chat/completions必須帶鑒權(quán)日志里做脫敏處理不要把完整prompt打到日志里尤其注意用戶上傳的文檔內(nèi)容可能包含敏感信息。穩(wěn)定性方面我建議業(yè)務(wù)側(cè)配置合理的接口超時(shí)和重試機(jī)制。大模型生成本來就慢超時(shí)設(shè)太短容易誤判失敗設(shè)太長又會(huì)讓請求堆積。我一般把超時(shí)設(shè)為生成時(shí)間上限10秒重試次數(shù)限制在1到2次避免雪崩。另外如果vLLM容器在運(yùn)行中無故退出先看Docker日志再看系統(tǒng)日志journalctl -u docker多數(shù)情況下是OOM kill或者顯卡驅(qū)動(dòng)異常。這類問題排查時(shí)要有耐心別一看到報(bào)錯(cuò)就重啟——很多故障重啟后不復(fù)現(xiàn)反而更難定位。我個(gè)人這一年多帶項(xiàng)目最大的體會(huì)是不要一開始就把架構(gòu)搞得很復(fù)雜。GPU機(jī)器先單機(jī)、vLLM容器、掛上監(jiān)控跑通一兩個(gè)真實(shí)業(yè)務(wù)再談擴(kuò)容和微調(diào)上線。另一個(gè)小技巧是把所有的啟動(dòng)參數(shù)和環(huán)境變量收進(jìn)一個(gè).env文件用docker compose管理服務(wù)升級換版本只改一行鏡像tag或一個(gè)環(huán)境變量省心很多。部署這件事穩(wěn)定壓倒一切先把這套工序跑熟再往深了做也不遲。