器部署全指南：顯存規(guī)劃、框架選型與生產(chǎn)落地實(shí)踐)
從 2024 年到 2026 年大模型已經(jīng)走過了“能跑通”的階段大量團(tuán)隊(duì)開始認(rèn)真考慮“怎么穩(wěn)定、省錢、高效率地跑生產(chǎn)流量”。我前前后后幫團(tuán)隊(duì)和客戶做過不下十套大模型服務(wù)器部署方案從單卡 4090 原型驗(yàn)證到八卡 A100/H800 集群承載線上 Agent 服務(wù)中間踩過的坑很值得整理出來。這篇指南就圍繞大模型服務(wù)器部署的完整鏈路展開硬件與顯存規(guī)劃、推理和微調(diào)框架選型、云服務(wù)商對比以及一套能直接落地的生產(chǎn)級部署流程適合正在做技術(shù)選型、準(zhǔn)備上線大模型服務(wù)的開發(fā)者和運(yùn)維同學(xué)參考。1. 部署前先定調(diào)這張卡能跑什么模型很多人在選服務(wù)器、買顯卡或者租云實(shí)例之前根本沒算過模型到底要吃多少顯存結(jié)果買回來發(fā)現(xiàn)跑不動或者租了一天八卡 A100 結(jié)果只用到 20% 的算力。這步其實(shí)特別關(guān)鍵可以先不聊框架、不聊服務(wù)先把顯存這筆賬算清楚。1.1 顯存是第一硬指標(biāo)怎么算模型部署時(shí)的顯存占用主要有三塊模型權(quán)重、KV Cache、中間激活值。推理場景下前兩塊占大頭中間激活值通常不用太擔(dān)心如果是微調(diào)場景激活值和優(yōu)化器狀態(tài)會暴增同樣一個模型需要的顯存可能是推理的 3 到 6 倍。模型權(quán)重的計(jì)算很直觀以 7B 參數(shù)模型為例FP16/BF16 精度下每個參數(shù)占 2 字節(jié)權(quán)重約 14GB。INT8 量化后約 7GBINT4 量化后約 3.5GB。13B 模型在 BF16 下就是 26GB 左右70B 模型在 BF16 下約 140GB。也就是說單張 24GB 的顯卡在 BF16 精度下最多放得下 7B-8B 級別的模型權(quán)重再大的模型就要考慮量化、多卡張量并行或者干脆上更大顯存的卡。KV Cache 是很多人容易忽略的部分。它存儲的是推理時(shí)每個 token 對應(yīng)的 Key 和 Value占用大小可以用一個粗略公式估算KV Cache 字節(jié)數(shù)約等于 2K 和 V 兩組乘以層數(shù)乘以 KV 頭維度乘以序列長度乘以并發(fā)數(shù)乘以精度字節(jié)數(shù)。層數(shù)、注意力頭維度都能從模型配置里讀到我用 LLaMA 7B 舉例32 層、KV 頭維度 128、序列長度 2048、并發(fā) 16、BF16 精度算下來大概 2 × 32 × 128 × 2048 × 16 × 2 536MB 左右。這個量級看著不大但注意序列長度翻到 32K、并發(fā)翻到 128KV Cache 就會到幾十個 GB直接決定你能開多少并發(fā)。生產(chǎn)環(huán)境里建議把模型權(quán)重和 KV Cache 合在一起看并預(yù)留 10%-20% 的余量。1.2 推理還是微調(diào)硬件策略完全不同推理場景看重的是顯存容量和吞吐計(jì)算上其實(shí) 4090 這類消費(fèi)卡就能做事瓶頸往往在顯存不夠放長上下文和多人并發(fā)。微調(diào)場景則是另一個維度梯度、優(yōu)化器狀態(tài)都是額外的顯存開銷。以 LoRA 這類參數(shù)高效微調(diào)為例單張 24GB 顯卡能微調(diào) 7B 模型但全參數(shù)微調(diào)就要謹(jǐn)慎很多。全參數(shù)微調(diào) 7B 模型混合精度訓(xùn)練下通常需要 60GB 以上顯存才比較舒服所以要么上 A100/H100 80GB 版本要么做多卡數(shù)據(jù)并行張量并行。做硬件策略時(shí)我的建議是如果你主要做推理優(yōu)先把顯存容量和顯存帶寬放在第一位如果你要頻繁微調(diào)和全參數(shù)訓(xùn)練優(yōu)先考慮多卡互聯(lián)帶寬也就是 NVLink、InfiniBand 這類因?yàn)樘荻韧胶土魉€并行對卡間通信特別敏感。我自己踩過坑曾經(jīng)用普通 PCle 4.0 x16 廣口連接兩張卡做張量并行性能遠(yuǎn)不如帶 NVLink 的雙卡差距能到 30% 以上訓(xùn)練場景下更夸張。1.3 消費(fèi)卡、專業(yè)卡和云上實(shí)例到底怎么選消費(fèi)卡的代表是 4090、5090 這類算力強(qiáng)、顯存 24G 或 32G性價(jià)比極高但有兩個天生問題一是顯存帶寬和專業(yè)卡有差距二是機(jī)架式服務(wù)器里供電散熱不好處理。個人開發(fā)機(jī)和原型驗(yàn)證我非常推薦用消費(fèi)卡但要上生產(chǎn)環(huán)境穩(wěn)定性優(yōu)先專業(yè)卡如 A10、L20、L40S、A100、H100、H20 更合適。專業(yè)卡的優(yōu)勢是顯存 ECC 糾錯、持久化顯存模式、更好的散熱設(shè)計(jì)還有驅(qū)動支持周期長。這里要給個云上的現(xiàn)實(shí)建議如果是 1-2 張卡的推理需求租一臺帶 4090 的云服務(wù)器最省成本如果是 8 卡級別的訓(xùn)練或服務(wù)直接租整機(jī)不要自己買。因?yàn)檎麢C(jī)功耗幾千瓦機(jī)房、電費(fèi)、故障率都是隱性成本而云上的 H800/H20 集群隨時(shí)可擴(kuò)按小時(shí)計(jì)費(fèi)彈性好得多。云服務(wù)這塊我會在第三章詳細(xì)對比。2. 框架選型推理與微調(diào)分開談框架不是越新越好而是要和你的場景匹配。我的實(shí)踐經(jīng)驗(yàn)是推理服務(wù)選 vLLM 系或 SGLang 系不要自己從頭寫調(diào)度微調(diào)用 LLaMA-Factory 這類統(tǒng)一框架不要每個模型都單獨(dú)找倉庫里的 training 腳本。2.1 主流推理框架速覽vLLM、SGLang、LMDeployvLLM 是目前生產(chǎn)環(huán)境里事實(shí)上的標(biāo)準(zhǔn)。它用 PagedAttention 把顯存里的 KV Cache 按頁管理配合 Continuous Batching能把單卡吞吐壓榨到接近理論上限。社區(qū)支持極其龐大幾乎所有開源模型發(fā)布時(shí)都會順手給一個 vLLM 的適配新模型支持補(bǔ)丁也最快。我個人推薦所有剛起步的項(xiàng)目直接上 vLLM文檔全、坑少、社區(qū)問答多踩坑成本最低。SGLang 在 vLLM 基礎(chǔ)上做了 RadixAttention適合多輪對話和 Agent 這類有大量前綴復(fù)用的業(yè)務(wù)。它對結(jié)構(gòu)化輸出、并行采樣、多模態(tài)輸入的支持也比 vLLM 更激進(jìn)。如果你的服務(wù)是高頻多輪對話或者大量用戶共享相同的 system promptSGLang 的前綴緩存命中率優(yōu)勢明顯。不過它的版本迭代快偶發(fā)兼容性問題多一點(diǎn)建議在測試環(huán)境充分壓測后再上生產(chǎn)。LMDeploy 是國內(nèi)團(tuán)隊(duì)維護(hù)的推理框架TurboMind 引擎性能優(yōu)秀。它的量化支持比較完善AWQ 和 KV Cache INT8 量化都能直接用。如果是國產(chǎn)算力環(huán)境比如昇騰、寒武紀(jì)等LMDeploy 的適配度往往比 vLLM 更好。我建議國產(chǎn)卡場景優(yōu)先考慮它NVIDIA 卡場景還是首選 vLLM。簡單總結(jié)一下這張選型表框架核心優(yōu)勢適合場景需要注意的點(diǎn)vLLM生態(tài)最全、吞吐高NVIDIA 卡上的通用推理長 Context 下顯存管理仍需調(diào)參SGLang前綴緩存、結(jié)構(gòu)化輸出Agent、多輪對話、高并發(fā)小請求版本迭代快、需謹(jǐn)慎升級LMDeploy量化完善、國產(chǎn)卡適配好國產(chǎn)算力、需要量化壓縮顯存國際模型適配相對滯后2.2 關(guān)于 TCC 和 WDDM 的誤區(qū)選型群里經(jīng)常能看到有人問“大模型選 TCC 還是 WDDM”這里要先說明TCCTesla Compute Cluster和 WDDMWindows Display Driver Model不是推理框架的選擇而是 NVIDIA 驅(qū)動在不同系統(tǒng)下的兩種運(yùn)行模式。WDDM 是 Windows 圖形驅(qū)動模型驅(qū)動里包含圖形調(diào)度、桌面合成這些邏輯適合游戲、設(shè)計(jì)軟件、桌面 GPU 直連顯示器。TCC 是專門面向計(jì)算卡的模式不加載圖形顯示功能GPU 直接作為純計(jì)算設(shè)備使用CPU 可以直接訪問顯存這在 CUDA 計(jì)算里效率更高也支持 GPU 持久性模式和更穩(wěn)定的大規(guī)模并行。所以如果你在 Windows 上用消費(fèi)卡做實(shí)驗(yàn)驅(qū)動默認(rèn) WDDM沒問題但一旦上服務(wù)器、上 Linux或者用 Tesla/專業(yè)計(jì)算卡就應(yīng)該切到 TCC 模式尤其多卡環(huán)境。一個最簡單的判斷你不需要這塊卡輸出畫面它就應(yīng)該是 TCC 模式。2.3 微調(diào)框架LLaMA-Factory 與 Axolotl 怎么選做微調(diào)的主流工具還有 LLaMA-Factory 和 Axolotl 兩個以及它們背后的生態(tài)。LLaMA-Factory 的全稱是用于大模型微調(diào)的統(tǒng)一 Web UI 和命令行框架對初學(xué)者特別友好支持 LoRA、QLoRA、全參數(shù)微調(diào)內(nèi)置了大量模型架構(gòu)適配。我自己的經(jīng)驗(yàn)是LLaMA-Factory 的 WebUI 適合快速做實(shí)驗(yàn)、看訓(xùn)練 loss、下采樣數(shù)據(jù)團(tuán)隊(duì)內(nèi)部做任務(wù)型微調(diào)時(shí)非常高效。Axolotl 更偏“配置文件驅(qū)動”用 YAML 定義數(shù)據(jù)集、模型、訓(xùn)練參數(shù)可復(fù)現(xiàn)性特別好。它更適合搭建標(biāo)準(zhǔn)化訓(xùn)練流水線比如我需要把微調(diào)任務(wù)固化到 CI/CD 里每次訓(xùn)練用同一份配置改數(shù)據(jù)集重新跑就可以。如果你的團(tuán)隊(duì)有專門的訓(xùn)練工程師追求實(shí)驗(yàn)可復(fù)現(xiàn)和數(shù)據(jù)記錄規(guī)范Axolotl 是更好的選擇。個人或者小團(tuán)隊(duì)做業(yè)務(wù)微調(diào)我建議先從 LLaMA-Factory 上手跑通后如果發(fā)現(xiàn)需要大量自動化實(shí)驗(yàn)再切 Axolotl。3. 云服務(wù)對比從省錢到省心很多人對云 GPU 的認(rèn)知停留在“租個帶顯卡的機(jī)器”但真到了生產(chǎn)要考慮的遠(yuǎn)不止 GPU 型號。網(wǎng)絡(luò)帶寬、磁盤 IO、存儲價(jià)格、數(shù)據(jù)遷移這些環(huán)節(jié)哪一個沒規(guī)劃好后面都要付出真金白銀的代價(jià)。3.1 主流云 GPU 平臺橫向?qū)Ρ任野言品?wù)商分成三類一類是大型綜合云廠商比如阿里云、騰訊云、華為云以及 AWS、Azure、Google Cloud 這些第二類是專門做 GPU 算力租賃的平臺常見的有 AutoDL 這類共享 GPU 服務(wù)、Vast.ai 這類去中心化算力市場第三類是大模型一體機(jī)或私有化交付方案。大模型場景我推薦優(yōu)先看第一類里的 GPU 云主機(jī)或者模型服務(wù)平臺比如阿里云的 ECS GPU 實(shí)例、PAI-EAS騰訊云的 TI 平臺華為云的 ModelArts。綜合云廠商的優(yōu)勢在穩(wěn)定性和周邊生態(tài)。阿里云 ECS 的 GPU 實(shí)例可以搭配 VPC、負(fù)載均衡、云監(jiān)控、KMS 密鑰管理系統(tǒng)生產(chǎn)環(huán)境直接把 API 網(wǎng)關(guān)、數(shù)據(jù)庫、對象存儲都串起來。AWS 的 SageMaker 對 MLOps 的支持更完整從數(shù)據(jù)處理到訓(xùn)練到推理部署都有托管組件。Google Cloud 在 TPU 和 Kubernetes 集成上有優(yōu)勢但國內(nèi)團(tuán)隊(duì)訪問不便我一般不太推薦。AutoDL 這類平臺適合做算法實(shí)驗(yàn)和臨時(shí)跑訓(xùn)練任務(wù)價(jià)格可能比綜合云便宜 30%-50%但不適合承載生產(chǎn)流量因?yàn)閷?shí)例網(wǎng)絡(luò)隔離、SLA 保障、數(shù)據(jù)持久化能力都偏弱真出故障的時(shí)候平臺響應(yīng)速度也不夠。3.2 按場景選原型驗(yàn)證、訓(xùn)練、長期服務(wù)我的建議是分三種場景來選。原型驗(yàn)證追求低成本快速起租 1 張 4090 或者 2 張 3090 足夠平臺選 AutoDL 這類靈活的就行跑通模型、測完效果立刻釋放。長期訓(xùn)練任務(wù)要買整機(jī)或包周期實(shí)例重點(diǎn)看卡間互聯(lián)比如阿里云的 P100/A100 集群盡量選帶 NVLink 或 InfiniBand 的規(guī)格不然 8 卡訓(xùn)練會卡在通信上。推理服務(wù)則要優(yōu)先看服務(wù)可用性和彈性擴(kuò)容能力我建議用云廠商的托管推理平臺比如阿里云 PAI-EAS或者自己在 GPU 云主機(jī)上部署 vLLM配合 SLB 負(fù)載均衡和彈性伸縮這樣流量上來就擴(kuò)容流量下去就縮容。很多團(tuán)隊(duì)忽略跨云遷移和數(shù)據(jù)回流的成本。如果你一開始在共享算力平臺訓(xùn)練數(shù)據(jù)存儲用的是對方平臺的對象存儲后續(xù)要把模型和數(shù)據(jù)遷到正式生產(chǎn)云比如阿里云 OSS下載上傳會產(chǎn)生大量流量費(fèi)用和耗時(shí)。我吃過這個虧訓(xùn)練好的幾十 GB 模型文件遷移加上數(shù)據(jù)集來回折騰了很久費(fèi)用也不低。所以在最開始做原型驗(yàn)證時(shí)就順手把數(shù)據(jù)放在標(biāo)準(zhǔn)格式的對象存儲里后面遷移會順暢很多。3.3 部署時(shí)容易被忽略的周邊配置云服務(wù)器部署大模型服務(wù)時(shí)光配好 GPU 驅(qū)動還不夠。第一個容易忽略的是安全組和防火墻入方向規(guī)則很多人在云控制臺打開端口之后又在服務(wù)器里遇到 iptables/ufw 攔截導(dǎo)致 API 端口外部訪問不通。我的習(xí)慣是統(tǒng)一在云平臺安全組層面管控服務(wù)器內(nèi)部默認(rèn)不開額外防火墻減少一層排查變量。第二個是存儲類型。GPU 實(shí)例的系統(tǒng)盤默認(rèn)是云盤但如果把模型文件放在系統(tǒng)盤加載幾百 GB 模型時(shí)會很慢而且系統(tǒng)盤擴(kuò)容代價(jià)高。建議使用獨(dú)立的云盤或高性能文件存儲比如阿里云 NAS 或文件存儲 CPFS多個 GPU 節(jié)點(diǎn)共享同一個模型目錄省去每臺機(jī)器拷貝一份的時(shí)間。我經(jīng)歷過 4 臺節(jié)點(diǎn)手動同步模型文件先后順序和版本不一致導(dǎo)致線上推理結(jié)果異常后面改成共享存儲才徹底解決。第三個是內(nèi)網(wǎng)訪問策略。生產(chǎn)環(huán)境的模型服務(wù)應(yīng)該只對 VPC 內(nèi)網(wǎng)開放不要直接暴露公網(wǎng)。如果需要從個人電腦調(diào)試訪問可以用安全組臨時(shí)放開白名單 IP或者通過堡壘機(jī)跳轉(zhuǎn)。有個常規(guī)技巧用 frp 之類的工具把云服務(wù)器的內(nèi)網(wǎng)端口映射到本地調(diào)試不能替代生產(chǎn)訪問路徑但確實(shí)能讓開發(fā)調(diào)試舒服很多。不管哪種方式公網(wǎng)接口一定要有鑒權(quán)別裸奔。4. 生產(chǎn)級部署流程從鏡像到監(jiān)控前面的選型和云資源定下來后接下來的部署流程就相對固定了。我以 Ubuntu 22.04 系統(tǒng)、NVIDIA GPU、vLLM 推理服務(wù)為例給出一套我實(shí)際驗(yàn)證過的生產(chǎn)級流程。這套流程的目標(biāo)是可重復(fù)、可回滾、可監(jiān)控而不是跑起來就行。4.1 環(huán)境準(zhǔn)備與驅(qū)動安裝拿到一臺 GPU 云主機(jī)后第一步確認(rèn) GPU 型號和驅(qū)動。執(zhí)行nvidia-smi能看到 GPU 狀態(tài)如果提示找不到命令說明驅(qū)動還沒裝。Ubuntu 下安裝 NVIDIA 驅(qū)動建議通過 apt 安裝比如安裝 550 版本驅(qū)動apt install nvidia-driver-550。裝完重啟再nvidia-smi確認(rèn) GPU 出現(xiàn)在列表里。接下來是 CUDA 和 cuDNN其實(shí)現(xiàn)在很多推理框架自帶 CUDA 運(yùn)行時(shí)環(huán)境尤其是用 Docker 部署的話鏡像里已經(jīng)包含 CUDA。我強(qiáng)烈建議生產(chǎn)環(huán)境直接用 NVIDIA NGC PyTorch 鏡像或 vLLM 官方鏡像不要在自己宿主機(jī)里折騰 CUDA 環(huán)境。有一個經(jīng)驗(yàn)法則宿主機(jī)只裝驅(qū)動CUDA 版本跟隨容器走這樣可以避免框架依賴的 CUDA 版本沖突。Docker 環(huán)境也在這里一并裝好NVIDIA Container Toolkit 是必需組件。安裝后執(zhí)行docker run --gpus all nvidia/cuda:12.4.1-base-ubuntu22.04 nvidia-smi驗(yàn)證容器能訪問 GPU。4.2 模型下載與格式準(zhǔn)備模型文件建議提前下載到共享存儲或多節(jié)點(diǎn)本地磁盤。使用 Hugging Face CLI 或 ModelScope 的 SDK 都可以國內(nèi)環(huán)境用 ModelScope 下載速度會更穩(wěn)。重點(diǎn)是下載后確認(rèn)模型目錄結(jié)構(gòu)完整包含 config.json、tokenizer 相關(guān)文件以及權(quán)重分片文件。如果下載的是源格式vLLM 能直接加載大多數(shù)主流架構(gòu)不過有一些小眾模型或者 GGUF 格式可能需要做轉(zhuǎn)換。GGUF 格式在 llama.cpp 生態(tài)里很常見但 vLLM 不直接加載 GGUF需要通過 llama.cpp 轉(zhuǎn)換回 HF 格式或者直接用支持 GGUF 的工具。這個細(xì)節(jié)經(jīng)常害人白等半天。我用過一個笨辦法在上生產(chǎn)前先跑一個小腳本用transformers庫直接加載一遍模型能加載成功基本就說明權(quán)重沒損壞格式也正確。這個驗(yàn)證步驟很值得做能省掉后續(xù)服務(wù)起不來的排查時(shí)間。4.3 vLLM 服務(wù)化與 GPU 顯存參數(shù)配置vLLM 啟動一條命令就能起服務(wù)但參數(shù)配置直接決定服務(wù)質(zhì)量和并發(fā)上限。基本的 OpenAI 兼容服務(wù)命令大概長這樣python -m vllm.entrypoints.openai.api_server \ --model /data/models/Qwen2.5-7B-Instruct \ --served-model-name qwen2.5-7b-instruct \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.85 \ --max-model-len 32768 \ --host 0.0.0.0 \ --port 8000這里最值得講的是--gpu-memory-utilization參數(shù)它控制 vLLM 最多使用多大比例的 GPU 顯存。我建議設(shè)置在 0.85 到 0.9 之間不要用默認(rèn)的 0.9 甚至更高因?yàn)轱@存管理需要留一部分余量給 Python 運(yùn)行時(shí)、CUDA context 和碎片化開銷。設(shè)到 1.0 很容易在并發(fā)高峰直接 OOM服務(wù)恢復(fù)起來非常痛苦。--tensor-parallel-size是多卡并行參數(shù)。一張卡放不下模型時(shí)比如 70B 模型在 2 張 80GB 卡上可以設(shè)成 2。跨多卡會多一層通信開銷但這是大模型部署必經(jīng)之路。--max-model-len控制最大上下文長度設(shè)太大顯存預(yù)留的 KV Cache 就會很大設(shè)置太小用戶的長文檔輸入會被截?cái)?。合理的策略是先跑一個最長輸入樣例觀察顯存占用和實(shí)際 KV Cache 用量再反向調(diào)這個參數(shù)。我這里給一個實(shí)操過的案例7B 模型、24GB 顯存、max-model-len設(shè)置為 16384、并發(fā) 32 時(shí)需要把gpu-memory-utilization設(shè)置在 0.8 左右才不容易爆顯存。提示vLLM 提供了--enable-prefix-caching參數(shù)多輪對話或者多用戶共享 system prompt 的場景建議開啟它能顯著提升吞吐。開啟后要留意監(jiān)控指標(biāo)的prefix_cache_hit_rate這個數(shù)值越高說明緩存收益越大。4.4 網(wǎng)關(guān)、鑒權(quán)與負(fù)載均衡模型服務(wù)起來了還不能直接暴露給業(yè)務(wù)方。生產(chǎn)環(huán)境至少要做三層Nginx 做反向代理和負(fù)載均衡、API Key 做鑒權(quán)、Prometheus 做監(jiān)控采集。vLLM 本身開放了/metrics端點(diǎn)格式就是 Prometheus 標(biāo)準(zhǔn)格式直接接入即可。Nginx 側(cè)的配置不難把 /v1 路徑代理到 vLLM 端口就行。需要注意的一點(diǎn)是模型輸入輸出都是大 JSON請求體大小限制一定要調(diào)大默認(rèn)的 1MB 根本不夠建議至少client_max_body_size 100m。另外要給 Nginx 和 vLLM 之間配置 keepalive降低 TCP 連接重建開銷。我見過線上服務(wù)每次請求都重新建立 TCP 連接長文本生成的耗時(shí)里可能有 20% 都花在連接建立上。鑒權(quán)建議通過網(wǎng)關(guān)層統(tǒng)一做最簡單的方案是 Nginx 里校驗(yàn)一個自定義 Header當(dāng)然更規(guī)范的做法是用服務(wù)網(wǎng)格或 API 網(wǎng)關(guān)統(tǒng)一下發(fā) Token。關(guān)鍵點(diǎn)是不要在代碼邏輯里到處散落密鑰而是集中到環(huán)境變量或者 Secret 管理服務(wù)里。這個點(diǎn)看似基礎(chǔ)但真實(shí)項(xiàng)目里泄露 API Key 的事故一點(diǎn)都不少見。生產(chǎn)流程里我還會加一個滾動發(fā)布環(huán)節(jié)。新版本模型上線時(shí)先在灰度節(jié)點(diǎn)啟動新服務(wù)用少量流量驗(yàn)證效果和穩(wěn)定性觀察監(jiān)控指標(biāo)沒有異常后再把 Nginx upstream 切到新節(jié)點(diǎn)?；貪L時(shí)同理保留上一個版本的容器鏡像和模型路徑一條命令切回去就行。這樣比直接替換服務(wù)要穩(wěn)妥得多。5. 常見問題與排查實(shí)錄這部分內(nèi)容是我在實(shí)際部署中被折騰最久的經(jīng)驗(yàn)集合。大模型服務(wù)看起來簡單但故障場景非常刁鉆很多問題不會在測試環(huán)境暴露只會在線上流量高峰時(shí)突然出現(xiàn)。5.1 OOM 與顯存碎片OOM 是部署大模型繞不開的坎它的表現(xiàn)有很多種服務(wù)啟動時(shí)直接報(bào)CUDA out of memory運(yùn)行中進(jìn)程崩潰或者推理請求突然超時(shí)。這里的經(jīng)驗(yàn)是不要把 OOM 的原因簡單歸到“顯存不夠”要分情況看。第一種是權(quán)重就放不下。比如 24GB 卡嘗試加載 13B 模型BF16 下權(quán)重 26GB這屬于硬性不足只能量化或者換卡。第二種是運(yùn)行時(shí)顯存被其他進(jìn)程占用特別是多卡機(jī)器上其他任務(wù)沒釋放nvidia-smi里能看到其他進(jìn)程占著顯存查一下進(jìn)程并清理即可。第三種是 vLLM 的預(yù)留給 KV Cache 太少導(dǎo)致高并發(fā)下請求排隊(duì)看似沒有報(bào)錯但延遲飆升。這種情況我一般先看nvidia-smi的顯存使用率曲線如果長期處于 95% 以上可以逐步上調(diào)--gpu-memory-utilization每次加 0.05 觀察穩(wěn)定性。排查 OOM 的最好工具就是nvidia-smi加vllm日志。vLLM 日志里會輸出注冊到模型引擎的并發(fā)數(shù)和顯存情況。如果發(fā)現(xiàn) PagedAttention 觸發(fā)了頻繁的顯存換頁說明 KV Cache 不夠需要調(diào)大顯存利用率或降低并發(fā)上限。5.2 接口響應(yīng)慢接口響應(yīng)慢其實(shí)要區(qū)分為兩種首 token 延遲高和生成吞吐低。首 token 延遲高通常是模型計(jì)算沒有開始就卡在排隊(duì)上或者請求帶了極長的歷史上下文全量預(yù)填充耗時(shí)太久。前者看并發(fā)隊(duì)列長度后者可以優(yōu)化為對超過閾值的舊上下文做截?cái)嗷蛘苊饷看稳孔咭槐椤Ｉ赏掏碌蛣t常是張量并行效率不高需要檢查卡間通信和模型拆分粒度。還有一個被很多人忽略的因素是 CPU Offload 到磁盤的交換。如果max-model-len設(shè)置過大vLLM 可能把部分 KV Cache 換到 CPU 內(nèi)存推理速度斷崖式下降。我在排查時(shí)觀察到nvidia-smi里 GPU 利用率不到 30%但磁盤讀寫很高才知道是換頁導(dǎo)致的。解決辦法就是調(diào)小max-model-len或者減少并發(fā)。5.3 安全組與訪問異常服務(wù)部署完外部訪問不通是最常見的開局問題。排查順序我建議從外到內(nèi)先看云控制臺安全組有沒有放行端口再看服務(wù)器本地防火墻狀態(tài)然后看服務(wù)進(jìn)程監(jiān)聽地址是不是0.0.0.0。vLLM 如果監(jiān)聽默認(rèn)localhost外部訪問自然不通啟動命令里--host 0.0.0.0必須明確寫上。訪問異常還有一個隱蔽原因云服務(wù)器的帶寬或者 QPS 限制。GPU 實(shí)例的規(guī)格不同公網(wǎng)帶寬上限也不同大模型請求響應(yīng)體動輒幾 MB如果帶寬不足客戶端會表現(xiàn)為超時(shí)或下載極慢但服務(wù)端nvidia-smi顯示 GPU 利用率很低。這個坑我見過很多人在生產(chǎn)第二天才暴露出來一查公網(wǎng)帶寬已經(jīng)打滿了。建議如果業(yè)務(wù)流量大盡量走內(nèi)網(wǎng)調(diào)用比如同一個 VPC 下的其他業(yè)務(wù)服務(wù)器直接訪問 GPU 實(shí)例內(nèi)網(wǎng) IP避開公網(wǎng)瓶頸。提示如果在云上做生產(chǎn)推理服務(wù)優(yōu)先把模型服務(wù)放在內(nèi)網(wǎng)讓應(yīng)用服務(wù)和模型服務(wù)同 VPC 互通。大模型響應(yīng)體大走公網(wǎng)既慢又貴內(nèi)網(wǎng)調(diào)用延遲和帶寬都更可控。6. 一些實(shí)踐中的體會最后分享幾個我長期踩坑攢下來的心得。大模型服務(wù)器部署這件事難點(diǎn)從來不是“啟動一個模型”而是讓它穩(wěn)定跑在線上、成本可控、可觀測、可回滾。我個人最深的體會是不要迷信所謂“推薦配置”每臺機(jī)器、每個模型、每類業(yè)務(wù)流量都有自己的脾氣。啟動參數(shù)、顯存利用率、并發(fā)上限這些都要用真實(shí)業(yè)務(wù)流量去壓測后確定。我的習(xí)慣是先把最小可用服務(wù)跑起來再用 JMeter 或者自寫腳本發(fā)送不同并發(fā)和不同上下文長度的請求觀察響應(yīng)時(shí)間、吞吐和顯存曲線把gpu-memory-utilization、max-model-len、并發(fā)上限這幾個參數(shù)調(diào)到相互匹配。另外一個很實(shí)用的技巧是在做容量規(guī)劃時(shí)先估算業(yè)務(wù)高峰期的最高并發(fā)和平均輸入長度再反推需要的顯存和卡數(shù)而不是反過來先買卡再想跑什么模型。比如你的業(yè)務(wù)是客服問答平均輸入 2K tokens、高峰期并發(fā) 50那 7B 級別的模型一張 24GB 卡就夠用如果是代碼生成或者長文檔分析平均輸入 16K tokens那至少需要 40GB 以上的顯存建議直接 80GB 卡。還有一個小 TIP 想分享給正在做微調(diào)的朋友微調(diào)完成后一定要把模型權(quán)重從訓(xùn)練框架里導(dǎo)出為 Hugging Face 格式再放到 vLLM 里驗(yàn)證推理結(jié)果。這一步經(jīng)常被忽略導(dǎo)致模型在訓(xùn)練階段 loss 很好看上線推理卻出現(xiàn)輸出亂碼或不符合預(yù)期。我習(xí)慣在微調(diào)結(jié)束后用一套固定的評測 prompt 做回歸測試對比微調(diào)前后的回答質(zhì)量確認(rèn)沒問題再進(jìn)入部署流程。整個鏈路都走順之后你會發(fā)現(xiàn)大模型服務(wù)器部署沒有那么神秘它無非是顯存計(jì)算、框架匹配、云資源規(guī)劃和工程化流程的組合把這些基礎(chǔ)打牢后面無論換什么模型、什么框架都能快速上手。 大模型服務(wù)器部署全指南：顯存規(guī)劃、框架選型與生產(chǎn)落地實(shí)踐
從 2024 年到 2026 年大模型已經(jīng)走過了“能跑通”的階段大量團(tuán)隊(duì)開始認(rèn)真考慮“怎么穩(wěn)定、省錢、高效率地跑生產(chǎn)流量”。我前前后后幫團(tuán)隊(duì)和客戶做過不下十套大模型服務(wù)器部署方案從單卡 4090 原型驗(yàn)證到八卡 A100/H800 集群承載線上 Agent 服務(wù)中間踩過的坑很值得整理出來。這篇指南就圍繞大模型服務(wù)器部署的完整鏈路展開硬件與顯存規(guī)劃、推理和微調(diào)框架選型、云服務(wù)商對比以及一套能直接落地的生產(chǎn)級部署流程適合正在做技術(shù)選型、準(zhǔn)備上線大模型服務(wù)的開發(fā)者和運(yùn)維同學(xué)參考。1. 部署前先定調(diào)這張卡能跑什么模型很多人在選服務(wù)器、買顯卡或者租云實(shí)例之前根本沒算過模型到底要吃多少顯存結(jié)果買回來發(fā)現(xiàn)跑不動或者租了一天八卡 A100 結(jié)果只用到 20% 的算力。這步其實(shí)特別關(guān)鍵可以先不聊框架、不聊服務(wù)先把顯存這筆賬算清楚。1.1 顯存是第一硬指標(biāo)怎么算模型部署時(shí)的顯存占用主要有三塊模型權(quán)重、KV Cache、中間激活值。推理場景下前兩塊占大頭中間激活值通常不用太擔(dān)心如果是微調(diào)場景激活值和優(yōu)化器狀態(tài)會暴增同樣一個模型需要的顯存可能是推理的 3 到 6 倍。模型權(quán)重的計(jì)算很直觀以 7B 參數(shù)模型為例FP16/BF16 精度下每個參數(shù)占 2 字節(jié)權(quán)重約 14GB。INT8 量化后約 7GBINT4 量化后約 3.5GB。13B 模型在 BF16 下就是 26GB 左右70B 模型在 BF16 下約 140GB。也就是說單張 24GB 的顯卡在 BF16 精度下最多放得下 7B-8B 級別的模型權(quán)重再大的模型就要考慮量化、多卡張量并行或者干脆上更大顯存的卡。KV Cache 是很多人容易忽略的部分。它存儲的是推理時(shí)每個 token 對應(yīng)的 Key 和 Value占用大小可以用一個粗略公式估算KV Cache 字節(jié)數(shù)約等于 2K 和 V 兩組乘以層數(shù)乘以 KV 頭維度乘以序列長度乘以并發(fā)數(shù)乘以精度字節(jié)數(shù)。層數(shù)、注意力頭維度都能從模型配置里讀到我用 LLaMA 7B 舉例32 層、KV 頭維度 128、序列長度 2048、并發(fā) 16、BF16 精度算下來大概 2 × 32 × 128 × 2048 × 16 × 2 536MB 左右。這個量級看著不大但注意序列長度翻到 32K、并發(fā)翻到 128KV Cache 就會到幾十個 GB直接決定你能開多少并發(fā)。生產(chǎn)環(huán)境里建議把模型權(quán)重和 KV Cache 合在一起看并預(yù)留 10%-20% 的余量。1.2 推理還是微調(diào)硬件策略完全不同推理場景看重的是顯存容量和吞吐計(jì)算上其實(shí) 4090 這類消費(fèi)卡就能做事瓶頸往往在顯存不夠放長上下文和多人并發(fā)。微調(diào)場景則是另一個維度梯度、優(yōu)化器狀態(tài)都是額外的顯存開銷。以 LoRA 這類參數(shù)高效微調(diào)為例單張 24GB 顯卡能微調(diào) 7B 模型但全參數(shù)微調(diào)就要謹(jǐn)慎很多。全參數(shù)微調(diào) 7B 模型混合精度訓(xùn)練下通常需要 60GB 以上顯存才比較舒服所以要么上 A100/H100 80GB 版本要么做多卡數(shù)據(jù)并行張量并行。做硬件策略時(shí)我的建議是如果你主要做推理優(yōu)先把顯存容量和顯存帶寬放在第一位如果你要頻繁微調(diào)和全參數(shù)訓(xùn)練優(yōu)先考慮多卡互聯(lián)帶寬也就是 NVLink、InfiniBand 這類因?yàn)樘荻韧胶土魉€并行對卡間通信特別敏感。我自己踩過坑曾經(jīng)用普通 PCle 4.0 x16 廣口連接兩張卡做張量并行性能遠(yuǎn)不如帶 NVLink 的雙卡差距能到 30% 以上訓(xùn)練場景下更夸張。1.3 消費(fèi)卡、專業(yè)卡和云上實(shí)例到底怎么選消費(fèi)卡的代表是 4090、5090 這類算力強(qiáng)、顯存 24G 或 32G性價(jià)比極高但有兩個天生問題一是顯存帶寬和專業(yè)卡有差距二是機(jī)架式服務(wù)器里供電散熱不好處理。個人開發(fā)機(jī)和原型驗(yàn)證我非常推薦用消費(fèi)卡但要上生產(chǎn)環(huán)境穩(wěn)定性優(yōu)先專業(yè)卡如 A10、L20、L40S、A100、H100、H20 更合適。專業(yè)卡的優(yōu)勢是顯存 ECC 糾錯、持久化顯存模式、更好的散熱設(shè)計(jì)還有驅(qū)動支持周期長。這里要給個云上的現(xiàn)實(shí)建議如果是 1-2 張卡的推理需求租一臺帶 4090 的云服務(wù)器最省成本如果是 8 卡級別的訓(xùn)練或服務(wù)直接租整機(jī)不要自己買。因?yàn)檎麢C(jī)功耗幾千瓦機(jī)房、電費(fèi)、故障率都是隱性成本而云上的 H800/H20 集群隨時(shí)可擴(kuò)按小時(shí)計(jì)費(fèi)彈性好得多。云服務(wù)這塊我會在第三章詳細(xì)對比。2. 框架選型推理與微調(diào)分開談框架不是越新越好而是要和你的場景匹配。我的實(shí)踐經(jīng)驗(yàn)是推理服務(wù)選 vLLM 系或 SGLang 系不要自己從頭寫調(diào)度微調(diào)用 LLaMA-Factory 這類統(tǒng)一框架不要每個模型都單獨(dú)找倉庫里的 training 腳本。2.1 主流推理框架速覽vLLM、SGLang、LMDeployvLLM 是目前生產(chǎn)環(huán)境里事實(shí)上的標(biāo)準(zhǔn)。它用 PagedAttention 把顯存里的 KV Cache 按頁管理配合 Continuous Batching能把單卡吞吐壓榨到接近理論上限。社區(qū)支持極其龐大幾乎所有開源模型發(fā)布時(shí)都會順手給一個 vLLM 的適配新模型支持補(bǔ)丁也最快。我個人推薦所有剛起步的項(xiàng)目直接上 vLLM文檔全、坑少、社區(qū)問答多踩坑成本最低。SGLang 在 vLLM 基礎(chǔ)上做了 RadixAttention適合多輪對話和 Agent 這類有大量前綴復(fù)用的業(yè)務(wù)。它對結(jié)構(gòu)化輸出、并行采樣、多模態(tài)輸入的支持也比 vLLM 更激進(jìn)。如果你的服務(wù)是高頻多輪對話或者大量用戶共享相同的 system promptSGLang 的前綴緩存命中率優(yōu)勢明顯。不過它的版本迭代快偶發(fā)兼容性問題多一點(diǎn)建議在測試環(huán)境充分壓測后再上生產(chǎn)。LMDeploy 是國內(nèi)團(tuán)隊(duì)維護(hù)的推理框架TurboMind 引擎性能優(yōu)秀。它的量化支持比較完善AWQ 和 KV Cache INT8 量化都能直接用。如果是國產(chǎn)算力環(huán)境比如昇騰、寒武紀(jì)等LMDeploy 的適配度往往比 vLLM 更好。我建議國產(chǎn)卡場景優(yōu)先考慮它NVIDIA 卡場景還是首選 vLLM。簡單總結(jié)一下這張選型表框架核心優(yōu)勢適合場景需要注意的點(diǎn)vLLM生態(tài)最全、吞吐高NVIDIA 卡上的通用推理長 Context 下顯存管理仍需調(diào)參SGLang前綴緩存、結(jié)構(gòu)化輸出Agent、多輪對話、高并發(fā)小請求版本迭代快、需謹(jǐn)慎升級LMDeploy量化完善、國產(chǎn)卡適配好國產(chǎn)算力、需要量化壓縮顯存國際模型適配相對滯后2.2 關(guān)于 TCC 和 WDDM 的誤區(qū)選型群里經(jīng)常能看到有人問“大模型選 TCC 還是 WDDM”這里要先說明TCCTesla Compute Cluster和 WDDMWindows Display Driver Model不是推理框架的選擇而是 NVIDIA 驅(qū)動在不同系統(tǒng)下的兩種運(yùn)行模式。WDDM 是 Windows 圖形驅(qū)動模型驅(qū)動里包含圖形調(diào)度、桌面合成這些邏輯適合游戲、設(shè)計(jì)軟件、桌面 GPU 直連顯示器。TCC 是專門面向計(jì)算卡的模式不加載圖形顯示功能GPU 直接作為純計(jì)算設(shè)備使用CPU 可以直接訪問顯存這在 CUDA 計(jì)算里效率更高也支持 GPU 持久性模式和更穩(wěn)定的大規(guī)模并行。所以如果你在 Windows 上用消費(fèi)卡做實(shí)驗(yàn)驅(qū)動默認(rèn) WDDM沒問題但一旦上服務(wù)器、上 Linux或者用 Tesla/專業(yè)計(jì)算卡就應(yīng)該切到 TCC 模式尤其多卡環(huán)境。一個最簡單的判斷你不需要這塊卡輸出畫面它就應(yīng)該是 TCC 模式。2.3 微調(diào)框架LLaMA-Factory 與 Axolotl 怎么選做微調(diào)的主流工具還有 LLaMA-Factory 和 Axolotl 兩個以及它們背后的生態(tài)。LLaMA-Factory 的全稱是用于大模型微調(diào)的統(tǒng)一 Web UI 和命令行框架對初學(xué)者特別友好支持 LoRA、QLoRA、全參數(shù)微調(diào)內(nèi)置了大量模型架構(gòu)適配。我自己的經(jīng)驗(yàn)是LLaMA-Factory 的 WebUI 適合快速做實(shí)驗(yàn)、看訓(xùn)練 loss、下采樣數(shù)據(jù)團(tuán)隊(duì)內(nèi)部做任務(wù)型微調(diào)時(shí)非常高效。Axolotl 更偏“配置文件驅(qū)動”用 YAML 定義數(shù)據(jù)集、模型、訓(xùn)練參數(shù)可復(fù)現(xiàn)性特別好。它更適合搭建標(biāo)準(zhǔn)化訓(xùn)練流水線比如我需要把微調(diào)任務(wù)固化到 CI/CD 里每次訓(xùn)練用同一份配置改數(shù)據(jù)集重新跑就可以。如果你的團(tuán)隊(duì)有專門的訓(xùn)練工程師追求實(shí)驗(yàn)可復(fù)現(xiàn)和數(shù)據(jù)記錄規(guī)范Axolotl 是更好的選擇。個人或者小團(tuán)隊(duì)做業(yè)務(wù)微調(diào)我建議先從 LLaMA-Factory 上手跑通后如果發(fā)現(xiàn)需要大量自動化實(shí)驗(yàn)再切 Axolotl。3. 云服務(wù)對比從省錢到省心很多人對云 GPU 的認(rèn)知停留在“租個帶顯卡的機(jī)器”但真到了生產(chǎn)要考慮的遠(yuǎn)不止 GPU 型號。網(wǎng)絡(luò)帶寬、磁盤 IO、存儲價(jià)格、數(shù)據(jù)遷移這些環(huán)節(jié)哪一個沒規(guī)劃好后面都要付出真金白銀的代價(jià)。3.1 主流云 GPU 平臺橫向?qū)Ρ任野言品?wù)商分成三類一類是大型綜合云廠商比如阿里云、騰訊云、華為云以及 AWS、Azure、Google Cloud 這些第二類是專門做 GPU 算力租賃的平臺常見的有 AutoDL 這類共享 GPU 服務(wù)、Vast.ai 這類去中心化算力市場第三類是大模型一體機(jī)或私有化交付方案。大模型場景我推薦優(yōu)先看第一類里的 GPU 云主機(jī)或者模型服務(wù)平臺比如阿里云的 ECS GPU 實(shí)例、PAI-EAS騰訊云的 TI 平臺華為云的 ModelArts。綜合云廠商的優(yōu)勢在穩(wěn)定性和周邊生態(tài)。阿里云 ECS 的 GPU 實(shí)例可以搭配 VPC、負(fù)載均衡、云監(jiān)控、KMS 密鑰管理系統(tǒng)生產(chǎn)環(huán)境直接把 API 網(wǎng)關(guān)、數(shù)據(jù)庫、對象存儲都串起來。AWS 的 SageMaker 對 MLOps 的支持更完整從數(shù)據(jù)處理到訓(xùn)練到推理部署都有托管組件。Google Cloud 在 TPU 和 Kubernetes 集成上有優(yōu)勢但國內(nèi)團(tuán)隊(duì)訪問不便我一般不太推薦。AutoDL 這類平臺適合做算法實(shí)驗(yàn)和臨時(shí)跑訓(xùn)練任務(wù)價(jià)格可能比綜合云便宜 30%-50%但不適合承載生產(chǎn)流量因?yàn)閷?shí)例網(wǎng)絡(luò)隔離、SLA 保障、數(shù)據(jù)持久化能力都偏弱真出故障的時(shí)候平臺響應(yīng)速度也不夠。3.2 按場景選原型驗(yàn)證、訓(xùn)練、長期服務(wù)我的建議是分三種場景來選。原型驗(yàn)證追求低成本快速起租 1 張 4090 或者 2 張 3090 足夠平臺選 AutoDL 這類靈活的就行跑通模型、測完效果立刻釋放。長期訓(xùn)練任務(wù)要買整機(jī)或包周期實(shí)例重點(diǎn)看卡間互聯(lián)比如阿里云的 P100/A100 集群盡量選帶 NVLink 或 InfiniBand 的規(guī)格不然 8 卡訓(xùn)練會卡在通信上。推理服務(wù)則要優(yōu)先看服務(wù)可用性和彈性擴(kuò)容能力我建議用云廠商的托管推理平臺比如阿里云 PAI-EAS或者自己在 GPU 云主機(jī)上部署 vLLM配合 SLB 負(fù)載均衡和彈性伸縮這樣流量上來就擴(kuò)容流量下去就縮容。很多團(tuán)隊(duì)忽略跨云遷移和數(shù)據(jù)回流的成本。如果你一開始在共享算力平臺訓(xùn)練數(shù)據(jù)存儲用的是對方平臺的對象存儲后續(xù)要把模型和數(shù)據(jù)遷到正式生產(chǎn)云比如阿里云 OSS下載上傳會產(chǎn)生大量流量費(fèi)用和耗時(shí)。我吃過這個虧訓(xùn)練好的幾十 GB 模型文件遷移加上數(shù)據(jù)集來回折騰了很久費(fèi)用也不低。所以在最開始做原型驗(yàn)證時(shí)就順手把數(shù)據(jù)放在標(biāo)準(zhǔn)格式的對象存儲里后面遷移會順暢很多。3.3 部署時(shí)容易被忽略的周邊配置云服務(wù)器部署大模型服務(wù)時(shí)光配好 GPU 驅(qū)動還不夠。第一個容易忽略的是安全組和防火墻入方向規(guī)則很多人在云控制臺打開端口之后又在服務(wù)器里遇到 iptables/ufw 攔截導(dǎo)致 API 端口外部訪問不通。我的習(xí)慣是統(tǒng)一在云平臺安全組層面管控服務(wù)器內(nèi)部默認(rèn)不開額外防火墻減少一層排查變量。第二個是存儲類型。GPU 實(shí)例的系統(tǒng)盤默認(rèn)是云盤但如果把模型文件放在系統(tǒng)盤加載幾百 GB 模型時(shí)會很慢而且系統(tǒng)盤擴(kuò)容代價(jià)高。建議使用獨(dú)立的云盤或高性能文件存儲比如阿里云 NAS 或文件存儲 CPFS多個 GPU 節(jié)點(diǎn)共享同一個模型目錄省去每臺機(jī)器拷貝一份的時(shí)間。我經(jīng)歷過 4 臺節(jié)點(diǎn)手動同步模型文件先后順序和版本不一致導(dǎo)致線上推理結(jié)果異常后面改成共享存儲才徹底解決。第三個是內(nèi)網(wǎng)訪問策略。生產(chǎn)環(huán)境的模型服務(wù)應(yīng)該只對 VPC 內(nèi)網(wǎng)開放不要直接暴露公網(wǎng)。如果需要從個人電腦調(diào)試訪問可以用安全組臨時(shí)放開白名單 IP或者通過堡壘機(jī)跳轉(zhuǎn)。有個常規(guī)技巧用 frp 之類的工具把云服務(wù)器的內(nèi)網(wǎng)端口映射到本地調(diào)試不能替代生產(chǎn)訪問路徑但確實(shí)能讓開發(fā)調(diào)試舒服很多。不管哪種方式公網(wǎng)接口一定要有鑒權(quán)別裸奔。4. 生產(chǎn)級部署流程從鏡像到監(jiān)控前面的選型和云資源定下來后接下來的部署流程就相對固定了。我以 Ubuntu 22.04 系統(tǒng)、NVIDIA GPU、vLLM 推理服務(wù)為例給出一套我實(shí)際驗(yàn)證過的生產(chǎn)級流程。這套流程的目標(biāo)是可重復(fù)、可回滾、可監(jiān)控而不是跑起來就行。4.1 環(huán)境準(zhǔn)備與驅(qū)動安裝拿到一臺 GPU 云主機(jī)后第一步確認(rèn) GPU 型號和驅(qū)動。執(zhí)行nvidia-smi能看到 GPU 狀態(tài)如果提示找不到命令說明驅(qū)動還沒裝。Ubuntu 下安裝 NVIDIA 驅(qū)動建議通過 apt 安裝比如安裝 550 版本驅(qū)動apt install nvidia-driver-550。裝完重啟再nvidia-smi確認(rèn) GPU 出現(xiàn)在列表里。接下來是 CUDA 和 cuDNN其實(shí)現(xiàn)在很多推理框架自帶 CUDA 運(yùn)行時(shí)環(huán)境尤其是用 Docker 部署的話鏡像里已經(jīng)包含 CUDA。我強(qiáng)烈建議生產(chǎn)環(huán)境直接用 NVIDIA NGC PyTorch 鏡像或 vLLM 官方鏡像不要在自己宿主機(jī)里折騰 CUDA 環(huán)境。有一個經(jīng)驗(yàn)法則宿主機(jī)只裝驅(qū)動CUDA 版本跟隨容器走這樣可以避免框架依賴的 CUDA 版本沖突。Docker 環(huán)境也在這里一并裝好NVIDIA Container Toolkit 是必需組件。安裝后執(zhí)行docker run --gpus all nvidia/cuda:12.4.1-base-ubuntu22.04 nvidia-smi驗(yàn)證容器能訪問 GPU。4.2 模型下載與格式準(zhǔn)備模型文件建議提前下載到共享存儲或多節(jié)點(diǎn)本地磁盤。使用 Hugging Face CLI 或 ModelScope 的 SDK 都可以國內(nèi)環(huán)境用 ModelScope 下載速度會更穩(wěn)。重點(diǎn)是下載后確認(rèn)模型目錄結(jié)構(gòu)完整包含 config.json、tokenizer 相關(guān)文件以及權(quán)重分片文件。如果下載的是源格式vLLM 能直接加載大多數(shù)主流架構(gòu)不過有一些小眾模型或者 GGUF 格式可能需要做轉(zhuǎn)換。GGUF 格式在 llama.cpp 生態(tài)里很常見但 vLLM 不直接加載 GGUF需要通過 llama.cpp 轉(zhuǎn)換回 HF 格式或者直接用支持 GGUF 的工具。這個細(xì)節(jié)經(jīng)常害人白等半天。我用過一個笨辦法在上生產(chǎn)前先跑一個小腳本用transformers庫直接加載一遍模型能加載成功基本就說明權(quán)重沒損壞格式也正確。這個驗(yàn)證步驟很值得做能省掉后續(xù)服務(wù)起不來的排查時(shí)間。4.3 vLLM 服務(wù)化與 GPU 顯存參數(shù)配置vLLM 啟動一條命令就能起服務(wù)但參數(shù)配置直接決定服務(wù)質(zhì)量和并發(fā)上限。基本的 OpenAI 兼容服務(wù)命令大概長這樣python -m vllm.entrypoints.openai.api_server \ --model /data/models/Qwen2.5-7B-Instruct \ --served-model-name qwen2.5-7b-instruct \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.85 \ --max-model-len 32768 \ --host 0.0.0.0 \ --port 8000這里最值得講的是--gpu-memory-utilization參數(shù)它控制 vLLM 最多使用多大比例的 GPU 顯存。我建議設(shè)置在 0.85 到 0.9 之間不要用默認(rèn)的 0.9 甚至更高因?yàn)轱@存管理需要留一部分余量給 Python 運(yùn)行時(shí)、CUDA context 和碎片化開銷。設(shè)到 1.0 很容易在并發(fā)高峰直接 OOM服務(wù)恢復(fù)起來非常痛苦。--tensor-parallel-size是多卡并行參數(shù)。一張卡放不下模型時(shí)比如 70B 模型在 2 張 80GB 卡上可以設(shè)成 2。跨多卡會多一層通信開銷但這是大模型部署必經(jīng)之路。--max-model-len控制最大上下文長度設(shè)太大顯存預(yù)留的 KV Cache 就會很大設(shè)置太小用戶的長文檔輸入會被截?cái)?。合理的策略是先跑一個最長輸入樣例觀察顯存占用和實(shí)際 KV Cache 用量再反向調(diào)這個參數(shù)。我這里給一個實(shí)操過的案例7B 模型、24GB 顯存、max-model-len設(shè)置為 16384、并發(fā) 32 時(shí)需要把gpu-memory-utilization設(shè)置在 0.8 左右才不容易爆顯存。提示vLLM 提供了--enable-prefix-caching參數(shù)多輪對話或者多用戶共享 system prompt 的場景建議開啟它能顯著提升吞吐。開啟后要留意監(jiān)控指標(biāo)的prefix_cache_hit_rate這個數(shù)值越高說明緩存收益越大。4.4 網(wǎng)關(guān)、鑒權(quán)與負(fù)載均衡模型服務(wù)起來了還不能直接暴露給業(yè)務(wù)方。生產(chǎn)環(huán)境至少要做三層Nginx 做反向代理和負(fù)載均衡、API Key 做鑒權(quán)、Prometheus 做監(jiān)控采集。vLLM 本身開放了/metrics端點(diǎn)格式就是 Prometheus 標(biāo)準(zhǔn)格式直接接入即可。Nginx 側(cè)的配置不難把 /v1 路徑代理到 vLLM 端口就行。需要注意的一點(diǎn)是模型輸入輸出都是大 JSON請求體大小限制一定要調(diào)大默認(rèn)的 1MB 根本不夠建議至少client_max_body_size 100m。另外要給 Nginx 和 vLLM 之間配置 keepalive降低 TCP 連接重建開銷。我見過線上服務(wù)每次請求都重新建立 TCP 連接長文本生成的耗時(shí)里可能有 20% 都花在連接建立上。鑒權(quán)建議通過網(wǎng)關(guān)層統(tǒng)一做最簡單的方案是 Nginx 里校驗(yàn)一個自定義 Header當(dāng)然更規(guī)范的做法是用服務(wù)網(wǎng)格或 API 網(wǎng)關(guān)統(tǒng)一下發(fā) Token。關(guān)鍵點(diǎn)是不要在代碼邏輯里到處散落密鑰而是集中到環(huán)境變量或者 Secret 管理服務(wù)里。這個點(diǎn)看似基礎(chǔ)但真實(shí)項(xiàng)目里泄露 API Key 的事故一點(diǎn)都不少見。生產(chǎn)流程里我還會加一個滾動發(fā)布環(huán)節(jié)。新版本模型上線時(shí)先在灰度節(jié)點(diǎn)啟動新服務(wù)用少量流量驗(yàn)證效果和穩(wěn)定性觀察監(jiān)控指標(biāo)沒有異常后再把 Nginx upstream 切到新節(jié)點(diǎn)?；貪L時(shí)同理保留上一個版本的容器鏡像和模型路徑一條命令切回去就行。這樣比直接替換服務(wù)要穩(wěn)妥得多。5. 常見問題與排查實(shí)錄這部分內(nèi)容是我在實(shí)際部署中被折騰最久的經(jīng)驗(yàn)集合。大模型服務(wù)看起來簡單但故障場景非常刁鉆很多問題不會在測試環(huán)境暴露只會在線上流量高峰時(shí)突然出現(xiàn)。5.1 OOM 與顯存碎片OOM 是部署大模型繞不開的坎它的表現(xiàn)有很多種服務(wù)啟動時(shí)直接報(bào)CUDA out of memory運(yùn)行中進(jìn)程崩潰或者推理請求突然超時(shí)。這里的經(jīng)驗(yàn)是不要把 OOM 的原因簡單歸到“顯存不夠”要分情況看。第一種是權(quán)重就放不下。比如 24GB 卡嘗試加載 13B 模型BF16 下權(quán)重 26GB這屬于硬性不足只能量化或者換卡。第二種是運(yùn)行時(shí)顯存被其他進(jìn)程占用特別是多卡機(jī)器上其他任務(wù)沒釋放nvidia-smi里能看到其他進(jìn)程占著顯存查一下進(jìn)程并清理即可。第三種是 vLLM 的預(yù)留給 KV Cache 太少導(dǎo)致高并發(fā)下請求排隊(duì)看似沒有報(bào)錯但延遲飆升。這種情況我一般先看nvidia-smi的顯存使用率曲線如果長期處于 95% 以上可以逐步上調(diào)--gpu-memory-utilization每次加 0.05 觀察穩(wěn)定性。排查 OOM 的最好工具就是nvidia-smi加vllm日志。vLLM 日志里會輸出注冊到模型引擎的并發(fā)數(shù)和顯存情況。如果發(fā)現(xiàn) PagedAttention 觸發(fā)了頻繁的顯存換頁說明 KV Cache 不夠需要調(diào)大顯存利用率或降低并發(fā)上限。5.2 接口響應(yīng)慢接口響應(yīng)慢其實(shí)要區(qū)分為兩種首 token 延遲高和生成吞吐低。首 token 延遲高通常是模型計(jì)算沒有開始就卡在排隊(duì)上或者請求帶了極長的歷史上下文全量預(yù)填充耗時(shí)太久。前者看并發(fā)隊(duì)列長度后者可以優(yōu)化為對超過閾值的舊上下文做截?cái)嗷蛘苊饷看稳孔咭槐椤Ｉ赏掏碌蛣t常是張量并行效率不高需要檢查卡間通信和模型拆分粒度。還有一個被很多人忽略的因素是 CPU Offload 到磁盤的交換。如果max-model-len設(shè)置過大vLLM 可能把部分 KV Cache 換到 CPU 內(nèi)存推理速度斷崖式下降。我在排查時(shí)觀察到nvidia-smi里 GPU 利用率不到 30%但磁盤讀寫很高才知道是換頁導(dǎo)致的。解決辦法就是調(diào)小max-model-len或者減少并發(fā)。5.3 安全組與訪問異常服務(wù)部署完外部訪問不通是最常見的開局問題。排查順序我建議從外到內(nèi)先看云控制臺安全組有沒有放行端口再看服務(wù)器本地防火墻狀態(tài)然后看服務(wù)進(jìn)程監(jiān)聽地址是不是0.0.0.0。vLLM 如果監(jiān)聽默認(rèn)localhost外部訪問自然不通啟動命令里--host 0.0.0.0必須明確寫上。訪問異常還有一個隱蔽原因云服務(wù)器的帶寬或者 QPS 限制。GPU 實(shí)例的規(guī)格不同公網(wǎng)帶寬上限也不同大模型請求響應(yīng)體動輒幾 MB如果帶寬不足客戶端會表現(xiàn)為超時(shí)或下載極慢但服務(wù)端nvidia-smi顯示 GPU 利用率很低。這個坑我見過很多人在生產(chǎn)第二天才暴露出來一查公網(wǎng)帶寬已經(jīng)打滿了。建議如果業(yè)務(wù)流量大盡量走內(nèi)網(wǎng)調(diào)用比如同一個 VPC 下的其他業(yè)務(wù)服務(wù)器直接訪問 GPU 實(shí)例內(nèi)網(wǎng) IP避開公網(wǎng)瓶頸。提示如果在云上做生產(chǎn)推理服務(wù)優(yōu)先把模型服務(wù)放在內(nèi)網(wǎng)讓應(yīng)用服務(wù)和模型服務(wù)同 VPC 互通。大模型響應(yīng)體大走公網(wǎng)既慢又貴內(nèi)網(wǎng)調(diào)用延遲和帶寬都更可控。6. 一些實(shí)踐中的體會最后分享幾個我長期踩坑攢下來的心得。大模型服務(wù)器部署這件事難點(diǎn)從來不是“啟動一個模型”而是讓它穩(wěn)定跑在線上、成本可控、可觀測、可回滾。我個人最深的體會是不要迷信所謂“推薦配置”每臺機(jī)器、每個模型、每類業(yè)務(wù)流量都有自己的脾氣。啟動參數(shù)、顯存利用率、并發(fā)上限這些都要用真實(shí)業(yè)務(wù)流量去壓測后確定。我的習(xí)慣是先把最小可用服務(wù)跑起來再用 JMeter 或者自寫腳本發(fā)送不同并發(fā)和不同上下文長度的請求觀察響應(yīng)時(shí)間、吞吐和顯存曲線把gpu-memory-utilization、max-model-len、并發(fā)上限這幾個參數(shù)調(diào)到相互匹配。另外一個很實(shí)用的技巧是在做容量規(guī)劃時(shí)先估算業(yè)務(wù)高峰期的最高并發(fā)和平均輸入長度再反推需要的顯存和卡數(shù)而不是反過來先買卡再想跑什么模型。比如你的業(yè)務(wù)是客服問答平均輸入 2K tokens、高峰期并發(fā) 50那 7B 級別的模型一張 24GB 卡就夠用如果是代碼生成或者長文檔分析平均輸入 16K tokens那至少需要 40GB 以上的顯存建議直接 80GB 卡。還有一個小 TIP 想分享給正在做微調(diào)的朋友微調(diào)完成后一定要把模型權(quán)重從訓(xùn)練框架里導(dǎo)出為 Hugging Face 格式再放到 vLLM 里驗(yàn)證推理結(jié)果。這一步經(jīng)常被忽略導(dǎo)致模型在訓(xùn)練階段 loss 很好看上線推理卻出現(xiàn)輸出亂碼或不符合預(yù)期。我習(xí)慣在微調(diào)結(jié)束后用一套固定的評測 prompt 做回歸測試對比微調(diào)前后的回答質(zhì)量確認(rèn)沒問題再進(jìn)入部署流程。整個鏈路都走順之后你會發(fā)現(xiàn)大模型服務(wù)器部署沒有那么神秘它無非是顯存計(jì)算、框架匹配、云資源規(guī)劃和工程化流程的組合把這些基礎(chǔ)打牢后面無論換什么模型、什么框架都能快速上手。