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