先說個(gè)很多人都會踩的坑本地能跑通一個(gè)模型和能把它穩(wěn)定地扛住線上流量是兩碼事。大模型服務(wù)器部署這事兒在2026年已經(jīng)不該停留在“裝個(gè)環(huán)境、pip install 一下、跑個(gè)demo”的階段了?？蚣苓x型、云服務(wù)采購、生產(chǎn)級流程這三個(gè)詞背后是一整套關(guān)于顯存預(yù)算、推理吞吐、延遲SLA、成本控制和安全風(fēng)控的工程決策。這篇文章是我結(jié)合過去一年多在多個(gè)項(xiàng)目里部署大模型推理服務(wù)的實(shí)際經(jīng)驗(yàn)寫的目標(biāo)讀者是那些要把開源大模型真正落到業(yè)務(wù)里的工程師和技術(shù)負(fù)責(zé)人。只要你關(guān)心的是“怎么讓Qwen、DeepSeek這類開源模型在GPU服務(wù)器上穩(wěn)定服務(wù)”或者“怎么從零搭一套不翻車的大模型推理環(huán)境”那就值得往下看。我會把框架選型邏輯、云服務(wù)的省錢路徑、以及從鏡像構(gòu)建到監(jiān)控告警的完整流程都拆開講清楚。1. 部署前的全局決策先想清楚“為什么部署”和“部署給誰用”很多人一上來就問“用什么框架”“上什么卡”這是本末倒置。部署方案的形態(tài)完全由業(yè)務(wù)需求決定不是由顯卡決定。我在多個(gè)項(xiàng)目里見過同一種翻車模式花了大量精力把70B模型跑起來了結(jié)果發(fā)現(xiàn)業(yè)務(wù)方只需要一個(gè)簡單的文本分類接口延遲要求500毫秒內(nèi)返回并發(fā)也就十幾路。這種情況用一個(gè)小模型加一個(gè)輕量框架就能搞定非得上大模型純屬給自己找罪受。1.1 私有化部署與技術(shù)棧的取舍邏輯先問三個(gè)問題數(shù)據(jù)能不能出內(nèi)網(wǎng)響應(yīng)延遲要求多高并發(fā)峰值是多大數(shù)據(jù)敏感這個(gè)點(diǎn)決定了你要不要做私有化部署。金融、醫(yī)療、政企類的客戶數(shù)據(jù)根本不能往外傳那云廠商的托管API直接pass掉必須自己拉GPU服務(wù)器這就是私有化部署的核心驅(qū)動力。如果數(shù)據(jù)無所謂業(yè)務(wù)方只是想低成本試水直接用云的托管推理服務(wù)更省心。第二個(gè)問題是延遲。大模型的推理延遲分兩個(gè)指標(biāo)首token延遲TTFT和生成吞吐Token/s。聊天機(jī)器人這類交互式場景TTFT要求在1-2秒以內(nèi)而批量離線處理場景比如大量文檔總結(jié)TTFT慢一點(diǎn)沒關(guān)系重要的是整體吞吐要高。這兩個(gè)指標(biāo)會直接影響到你要不要用連續(xù)批處理、要不要開投機(jī)解碼、要不要上量化。第三個(gè)問題是并發(fā)。并發(fā)決定顯存預(yù)算顯存預(yù)算決定機(jī)器選型。后面會展開講量化估算的方法這里先記住一個(gè)結(jié)論并發(fā)需求越高KV Cache占用就越大GPU顯存就越緊張。1.2 從場景倒推硬件顯存、算力與并發(fā)需求估算我有個(gè)習(xí)慣任何部署項(xiàng)目開工前先做一張“顯存賬本”。公式并不復(fù)雜模型權(quán)重顯存 參數(shù)量 × 每參數(shù)字節(jié)數(shù)另外加上推理時(shí)的KV Cache、激活值、推理引擎自身的運(yùn)行時(shí)開銷。舉個(gè)例子一個(gè)7B模型用BF162字節(jié)加載權(quán)重部分大約14GB。假設(shè)要支持32路并發(fā)上下文長度4096KV Cache大概會再吃掉4-6GB。加在一起一張24GB的RTX 4090或L20就能跑但余量不大。如果是70B模型BF16權(quán)重要140GB這就要2張80GB的A100/H100或者4張48GB的L40S。如果上INT4量化比如AWQ或GPTQ格式70B模型權(quán)重能壓到40GB左右單張80G卡就能跑但代價(jià)是生成質(zhì)量會有一點(diǎn)下降精密度要求高的場景要謹(jǐn)慎。所以我在選機(jī)器時(shí)通常會這樣推導(dǎo)先確定模型規(guī)模和并發(fā)上限算出顯存下限再根據(jù)預(yù)算選定機(jī)型。如果預(yù)算只夠買一張卡那就認(rèn)命要么用小模型要么上量化要么砍并發(fā)。別指望一張24G卡能流暢服務(wù)70B模型的多人并發(fā)這不符合物理規(guī)律。順著這個(gè)邏輯下面就可以進(jìn)入框架選型了。2. 2026年主流推理框架橫評vLLM、SGLang、TensorRT-LLM怎么選推理框架是整個(gè)部署鏈路中最核心的一層。2026年這個(gè)時(shí)間點(diǎn)開源大模型推理框架已經(jīng)不是“百花齊放”了而是形成了幾個(gè)明確的主力vLLM、SGLang、TensorRT-LLM再加上LMDeploy、llama.cpp這些特定場景的選手。選錯(cuò)了框架后面調(diào)優(yōu)階段會非常痛苦所以這塊值得花多點(diǎn)篇幅說清楚。2.1 三足鼎立的推理引擎格局vLLM應(yīng)該是目前生態(tài)最成熟、社區(qū)最活躍的選擇沒有之一。它的核心優(yōu)勢是PagedAttention和Continuous Batching。你可以把PagedAttention理解成操作系統(tǒng)的虛擬內(nèi)存分頁機(jī)制KV Cache不再需要連續(xù)的大塊顯存而是像內(nèi)存分頁一樣按需分配這樣顯存碎片化問題被極大緩解同一個(gè)GPU上能塞下的并發(fā)請求數(shù)量就上去了。Continuous Batching則讓推理引擎可以動態(tài)地把新請求插入正在執(zhí)行的批次里而不是傻傻地等當(dāng)前批次全部完成。這兩個(gè)機(jī)制加在一起vLLM的實(shí)際GPU利用率可以做到非常高。SGLang的優(yōu)勢在RadixAttention它會自動緩存并復(fù)用提示詞的前綴公共部分。典型的應(yīng)用場景是帶大量few-shot示例或系統(tǒng)提示詞的對話場景。比如你每次請求里都帶著一大段相同的系統(tǒng)提示詞SGLang會把這段前綴的計(jì)算結(jié)果緩存下來下次直接復(fù)用省下的prefill計(jì)算量相當(dāng)可觀。另外SGLang在多模態(tài)模型支持上做得更激進(jìn)如果你的業(yè)務(wù)要頻繁處理圖片輸入SGLang值得關(guān)注。TensorRT-LLM則是NVIDIA自家的方案底層圖優(yōu)化做得最狠特別在FP8量化配合H100/H200這類Hopper架構(gòu)卡上單卡性能可以壓榨到極限。但它的代價(jià)是使用門檻偏高模型需要先轉(zhuǎn)換并構(gòu)建成TensorRT引擎部署流程明顯更重。我能想到的合適場景是你有一批固定的模型跑在NVIDIA主流卡上追求極致吞吐而且有專門的工程人力來維護(hù)這套轉(zhuǎn)換流程。2.2 框架選型的四個(gè)關(guān)鍵維度具體怎么判斷我總結(jié)出四個(gè)維度生態(tài)成熟度、顯存效率、延遲差異、運(yùn)維復(fù)雜度。維度vLLMSGLangTensorRT-LLMLMDeploy生態(tài)成熟度最高OpenAI兼容API開箱即用較高API也兼容OpenAINVIDIA官方維護(hù)但配置繁瑣國產(chǎn)框架中文社區(qū)活躍顯存效率PagedAttention動態(tài)分配RadixAttention前綴復(fù)用省顯存圖優(yōu)化FP8極致壓縮量化支持好TurboMind引擎輕量延遲表現(xiàn)總體優(yōu)秀TTFT穩(wěn)定前綴命中場景TTFT顯著降低單卡極限性能最強(qiáng)中等勝在易用運(yùn)維復(fù)雜度低Docker一鍵起中等參數(shù)項(xiàng)更多高需要模型轉(zhuǎn)換構(gòu)建低適合快速上線如果項(xiàng)目只有一個(gè)框架可選我默認(rèn)推薦vLLM。理由很簡單它踩坑的人最多生產(chǎn)環(huán)境暴露過的問題也最多所以迭代速度快用起來最穩(wěn)。SGLang適合那些提示詞前綴高度復(fù)用的業(yè)務(wù)省下來的成本肉眼可見。TensorRT-LLM則是給“追求單卡吞吐極限”的人準(zhǔn)備的。有一個(gè)容易忽略的細(xì)節(jié)是框架對量化格式的支持差異。vLLM對AWQ和GPTQ支持得最成熟SGLang也對多種量化格式做了適配但TensorRT-LLM對FP8的支持最原生。你如果看中FP8但GPU是A系列或L系列那TensorRT-LLM的優(yōu)勢就會被削弱因?yàn)镕P8主要是在H100及更新架構(gòu)上才有明顯收益。2.3 輕量場景下的備選方案還有兩類場景我會用不同的框架。第一類是資源受限的個(gè)人或邊緣場景比如只有一張消費(fèi)級顯卡甚至沒有GPU只想本地跑跑效果那llama.cpp GGUF格式是最合適的選擇。GGUF量化格式配合llama.cppCPU也能跑7B模型量化后內(nèi)存占用壓在6GB以內(nèi)體驗(yàn)雖然談不上飛快但勝在輕巧和零依賴。第二類是微調(diào)產(chǎn)物的快速驗(yàn)證場景。如果你自己用LoRA微調(diào)了一個(gè)小模型想快速起一個(gè)服務(wù)驗(yàn)證效果那LMDeploy值得試試。它對量化支持很友好部署步驟比vLLM更簡化一條命令就能啟動特別適合算法團(tuán)隊(duì)自測。說到底框架選型就是一個(gè)需求翻譯成匹配關(guān)系的過程理清了場景選擇自然就出來了。3. 云服務(wù)采購對比裸金屬、GPU云主機(jī)與容器平臺的賬本框架定了接下來是“跑在哪里”的問題。2026年的云服務(wù)選擇比前兩年豐富得多GPU云主機(jī)、裸金屬、容器服務(wù)、Serverless推理都有成熟產(chǎn)品。這塊的核心不是比較參數(shù)表而是算賬和評估運(yùn)維成本。3.1 主流云平臺的GPU實(shí)例形態(tài)對比現(xiàn)在主流的云平臺比如阿里云、騰訊云、AWS、Azure等都提供多種形式的大模型部署載體。我按使用場景拆開講。第一類是GPU云主機(jī)這是最通用的選擇。典型規(guī)格有24GB顯存的單卡實(shí)例L20、RTX 4090、48GB顯存單卡L40S、A10以及80GB顯存高端卡A100、H100、H800等。云主機(jī)的好處是你可以完全掌控環(huán)境任意裝驅(qū)動、框架、依賴壞處是環(huán)境一旦混亂排查問題的成本都落在自己頭上。第二類是容器服務(wù)Kubernetes適合團(tuán)隊(duì)里有一定運(yùn)維基礎(chǔ)、需要頻繁擴(kuò)縮容的場景。容器服務(wù)的好處在于環(huán)境一致性鏡像即環(huán)境發(fā)布和回滾都方便配合GPU節(jié)點(diǎn)池的自動伸縮能做到按需擴(kuò)容。代價(jià)是K8s本身的學(xué)習(xí)成本不低網(wǎng)絡(luò)、存儲、調(diào)度這些組件都要有人懂。第三類是Serverless推理比如各大云廠商的模型服務(wù)平臺提供的托管推理API。你只需要傳入模型ID和參數(shù)平臺負(fù)責(zé)調(diào)度GPU、處理并發(fā)和故障轉(zhuǎn)移。這類服務(wù)的最大優(yōu)勢是把運(yùn)維負(fù)擔(dān)降到零但最大劣勢是數(shù)據(jù)要經(jīng)過平臺方且單價(jià)通常比自建貴適合快速原型驗(yàn)證和對數(shù)據(jù)合規(guī)要求不嚴(yán)的場景。3.2 成本模型按量、包年包月、競價(jià)實(shí)例怎么配合我見過的不少團(tuán)隊(duì)買GPU實(shí)例時(shí)喜歡直接包月圖省心但浪費(fèi)的錢還真不少。以一張80GB顯存的A100/H100為例各平臺的官方按量價(jià)格差異很大地域和活動期也不同通常每小時(shí)幾十塊人民幣。包年包月大約相當(dāng)于按量的五到七折如果業(yè)務(wù)確實(shí)是7×24小時(shí)穩(wěn)定運(yùn)行包月才劃算。但很多業(yè)務(wù)有明顯的波峰波谷白天忙晚上閑這種情況下最好的策略是混合調(diào)度核心穩(wěn)定的流量池用包月實(shí)例兜底。突發(fā)流量用按量實(shí)例彈性擴(kuò)容。對時(shí)延不敏感、可中斷的離線批量任務(wù)用競價(jià)實(shí)例搶占式實(shí)例成本和按量相比有時(shí)能省50%以上。但這里有兩個(gè)血淚教訓(xùn)一是競價(jià)實(shí)例隨時(shí)可能被回收任務(wù)必須有斷點(diǎn)續(xù)跑機(jī)制二是部分云平臺的競價(jià)實(shí)例在高峰期根本搶不到所以千萬別把核心在線服務(wù)全部押在競價(jià)實(shí)例上。3.3 網(wǎng)絡(luò)與存儲對部署體驗(yàn)的影響這一點(diǎn)很多人忽略但它實(shí)實(shí)在在影響部署體驗(yàn)。大模型文件動輒幾十GB甚至上百GB如果云主機(jī)拉取模型走公網(wǎng)可能一兩個(gè)小時(shí)都下不完。正確做法是先把模型文件傳到與GPU實(shí)例同地域的對象存儲OSS/S3再走內(nèi)網(wǎng)拷貝帶寬高且無公網(wǎng)費(fèi)用。如果你沒有專門的對象存儲也可以把模型文件上傳到云盤掛載到實(shí)例上讀取速度同樣比公網(wǎng)下載快得多。網(wǎng)絡(luò)層面還要考慮出口帶寬。推理服務(wù)調(diào)用的流量不算大token輸出量遠(yuǎn)小于視頻流量但如果是長文本生成單次請求也可能產(chǎn)生幾KB到幾十KB的響應(yīng)和傳統(tǒng)API服務(wù)相比不算負(fù)擔(dān)。真正的瓶頸是首token延遲里包含的網(wǎng)絡(luò)RTT和GPU實(shí)例所在地域與調(diào)用方的距離直接相關(guān)。跨地域調(diào)用的RTT動輒幾十毫秒放到TTFT指標(biāo)上可能就是明顯的劣化。所以人在哪里服務(wù)就部署在哪里這是云上部署的第一原則。這些采購層面的決策做完后接下來就可以真正動手做生產(chǎn)級流程了。4. 生產(chǎn)級部署流程全實(shí)錄核心環(huán)節(jié)逐一拆解我見過的很多部署翻車現(xiàn)場不是模型跑不起來而是整個(gè)流程沒有按生產(chǎn)標(biāo)準(zhǔn)來沒有校驗(yàn)?zāi)Ｐ臀募暾?、沒有固定依賴版本、沒有配監(jiān)控、沒有備回滾方案。生產(chǎn)級流程的意義就是把這些“萬一出問題”的環(huán)節(jié)前置解決掉。4.1 環(huán)境初始化與驅(qū)動、容器層配置生產(chǎn)環(huán)境我強(qiáng)烈建議用Docker而不是直接把框架裝在宿主機(jī)上。Docker鏡像能鎖定環(huán)境避免“在我機(jī)器上是好的”這類問題?；A(chǔ)環(huán)境建議這樣搭操作系統(tǒng)用Ubuntu 22.04 LTS內(nèi)核和生態(tài)都比較穩(wěn)。NVIDIA驅(qū)動版本至少535以上具體以顯卡型號和官方兼容表為準(zhǔn)。裝了驅(qū)動后再裝NVIDIA Container Toolkit這步非常關(guān)鍵否則Docker容器里是調(diào)不到GPU的。驗(yàn)證方法是在宿主機(jī)跑nvidia-smi在容器里同樣跑nvidia-smi能顯示GPU信息才算打通。鏡像方面vLLM官方提供了可直接用的Docker鏡像比如vllm/vllm-openai里面已經(jīng)把CUDA、PyTorch這些依賴都配好了。我不建議自己從零構(gòu)建耗時(shí)又容易出問題。直接拉官方鏡像只做少量定制比如把時(shí)區(qū)改成Asia/Shanghai、加一些調(diào)試工具就夠了。4.2 模型下載、格式轉(zhuǎn)換與量化取舍模型的來源和完整性校驗(yàn)是很多新手會忽略的環(huán)節(jié)。開源模型的下載源主要有HuggingFace和ModelScope國內(nèi)環(huán)境建議優(yōu)先ModelScope速度和穩(wěn)定性都好很多。下載時(shí)用官方工具h(yuǎn)f download或modelscope download而不是手動一個(gè)一個(gè)點(diǎn)。核心模型文件和分詞器、配置文件是一個(gè)整體任何一塊缺失都會導(dǎo)致加載失敗。下載完成后記得校驗(yàn)?zāi)Ｐ臀募腟HA256哈希官方頁面上會給別嫌麻煩。這一步能防止下到損壞的文件更重要的是防止下到被投毒的模型?，F(xiàn)在的攻擊手法越來越高有人會在模型權(quán)重里埋后門直接用未經(jīng)驗(yàn)證的第三方模型風(fēng)險(xiǎn)非常高。我的建議是生產(chǎn)環(huán)境只從模型官方賬號或可信鏡像站下載絕不在網(wǎng)盤或不明鏈接下載模型。量化格式的選擇在部署階段就該定好。如果你對顯存有壓力可以選GPTQ或AWQ這些INT4格式加載快顯存占用低。如果追求生成質(zhì)量用BF16或FP16原格式。GGUF格式通常留給llama.cpp場景在vLLM里也可加載但不是我首選的在線服務(wù)格式。4.3 通過vLLM啟動推理服務(wù)關(guān)鍵參數(shù)調(diào)優(yōu)實(shí)解這里直接給一個(gè)可以“抄作業(yè)”的啟動命令并逐個(gè)解釋關(guān)鍵參數(shù)。假設(shè)我們部署的是Qwen2.5-72B-Instruct模型跑在4張80GB的H800上docker run --runtime nvidia \ --gpus all \ --ipchost \ -v /data/models:/models \ -v /data/cache:/cache \ -p 8000:8000 \ --name qwen-72b-vllm \ vllm/vllm-openai:latest \ --model /models/Qwen2.5-72B-Instruct \ --tensor-parallel-size 4 \ --max-model-len 32768 \ --gpu-memory-utilization 0.92 \ --served-model-name qwen-72b \ --port 8000 \ --trust-remote-code \ --enforce-eager幾個(gè)關(guān)鍵參數(shù)分別說明一下--tensor-parallel-size 4表示模型權(quán)重切分到4張GPU上并行推理。這里要特別注意假設(shè)你的GPU顯存粒度是80GB模型權(quán)重是140GB那你可能覺得4張卡就夠了。但實(shí)際還要留出KV Cache和激活值的空間所以有時(shí)需要5-6張卡才舒服。最穩(wěn)妥的辦法是先按理論值給足再觀察顯存利用率逐步下調(diào)整。--max-model-len控制模型支持的最大上下文長度。雖然Qwen2.5-72B原版支持128K上下文但實(shí)際設(shè)得越長KV Cache占用的顯存越大能支持的并發(fā)就越低。如果不是真的有長文本需求我建議初始設(shè)置為16K或32K性價(jià)比最高。--gpu-memory-utilization 0.92告訴vLLM最多可用92%的顯存留出一點(diǎn)余量給CUDA上下文和框架自身。不要直接設(shè)成0.99容易OOM。啟動日志里會輸出模型加載耗時(shí)、顯存分布、KV Cache可用空間。加載完成后用curl做一次冒煙測試curl http://127.0.0.1:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen-72b, messages: [{role: user, content: 你好}], max_tokens: 128, temperature: 0.2 }能正常返回結(jié)果說明模型基本通了。但請注意這只是“能跑”離“生產(chǎn)級”還有一段距離。vLLM還支持--api-key設(shè)置服務(wù)端鑒權(quán)生產(chǎn)環(huán)境務(wù)必開啟別裸奔在公網(wǎng)上。4.4 網(wǎng)關(guān)層與并發(fā)策略讓OpenAI兼容接口真正可用vLLM啟動后默認(rèn)暴露的是OpenAI兼容接口這意味著你現(xiàn)有的OpenAI SDK可以直接換掉base_url業(yè)務(wù)代碼改動量很小。這一步本身就省了不少對接成本。但生產(chǎn)環(huán)境不能直接把vLLM的8000端口暴露給公網(wǎng)。推薦在前面加一層Nginx或云負(fù)載均衡做TLS終止、API key校驗(yàn)、限流。vLLM本身也支持服務(wù)端API key校驗(yàn)但更細(xì)粒度的用戶維度限速、審計(jì)還是要靠網(wǎng)關(guān)層。用一個(gè)簡單的Nginx反代配置就能解決upstream vllm_backend { server 127.0.0.1:8000; keepalive 32; } server { listen 443 ssl; server_name llm.example.com; location /v1/ { proxy_pass http://vllm_backend; proxy_http_version 1.1; proxy_set_header Connection ; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }這里有個(gè)關(guān)鍵點(diǎn)proxy_set_header Connection 配合keepalive 32是為了啟用HTTP長連接。本地的HTTP keep-alive可以讓vLLM接收請求時(shí)減少TCP握手開銷實(shí)測并發(fā)請求的吞吐能提升一截。經(jīng)常有人在壓測時(shí)發(fā)現(xiàn)P99延遲偏高排查到最后就是Nginx默認(rèn)用的是短連接重建連接的壓力全打在了vLLM上。Kubernetes環(huán)境下可以用Nginx Ingress或者直掛ServiceLoadBalancer來做同樣的網(wǎng)關(guān)邏輯。此外建議給vLLM配置--max-parallel-loading-workers和--max-num-seqs來控制并發(fā)上限避免突發(fā)流量把顯存沖爆。vLLM在并發(fā)超限時(shí)會返回429這是合理的行為客戶端應(yīng)當(dāng)實(shí)現(xiàn)指數(shù)退避重試而不是無腦重試。5. 穩(wěn)定性建設(shè)與排查實(shí)錄服務(wù)能跑通只是第一步真正的考驗(yàn)是能不能長時(shí)間穩(wěn)定跑、出問題時(shí)能不能快速定位。這一節(jié)我把自己實(shí)際踩過的坑和解決方案整理出來應(yīng)該能幫你少走不少彎路。5.1 顯存管理與OOM問題排查線上最常見的報(bào)錯(cuò)就是CUDA OOM。很多人第一反應(yīng)是加大顯存但先別急99%的顯存問題都不是“卡不夠”而是“配置不合理”。排查思路是先看nvidia-smi里顯存是吃滿了還是只有一部分占用。如果完全吃滿可能是并發(fā)需求過高或者上下文長度設(shè)置過長。如果是vLLM啟動時(shí)報(bào)CUDA OOM基本可以判斷是權(quán)重加KV Cache初始分配超過了顯存上限。解決辦法依次嘗試降低--gpu-memory-utilization、縮短--max-model-len、限制--max-num-seqs、切換量化格式。還有一個(gè)很容易忽略的點(diǎn)千萬注意CUDA 12與vLLM鏡像版本的兼容性。vLLM對CUDA版本很敏感如果你自己改了鏡像底層的CUDA版本很可能在跑長上下文時(shí)出現(xiàn)隨機(jī)性故障。原則上用官方鏡像鎖定的版本不要自行升級CUDA。5.2 延遲抖動與吞吐瓶頸如果你發(fā)現(xiàn)服務(wù)的P50延遲和P99延遲差距特別大問題大概率不是模型本身而是排隊(duì)。vLLM的連續(xù)批處理有一個(gè)必知邏輯當(dāng)請求正在進(jìn)行時(shí)新請求要等待引擎走到空閑槽位才被調(diào)度。如果并發(fā)超過--max-num-seqs新請求就會排隊(duì)。排隊(duì)的積累會讓P99飆升到P50的幾倍。應(yīng)對辦法有兩種一是提升引擎的并發(fā)處理能力比如增加GPU數(shù)量或提升gpu-memory-utilization二是從業(yè)務(wù)層面削峰填谷給客戶端加請求隊(duì)列和超時(shí)機(jī)制。另外如果單條請求的max_tokens設(shè)置得過大可能會導(dǎo)致生成長度超長的請求霸占推理槽位建議在網(wǎng)關(guān)層強(qiáng)制限制max_tokens的上限。5.3 模型安全與多租戶隔離模型部署完成不代表安全收工?，F(xiàn)在針對大模型推理服務(wù)的攻擊手法越來越多提示詞注入、惡意長上下文打滿KV Cache都是真實(shí)威脅。生產(chǎn)環(huán)境一定要在網(wǎng)關(guān)層做好API鑒權(quán)、限流、審計(jì)日志文件上傳類接口還要做內(nèi)容過濾。多租戶場景下最穩(wěn)妥的方案是一個(gè)租戶一個(gè)獨(dú)立推理服務(wù)實(shí)例用K8s做隔離。如果成本壓力大至少也要在同一個(gè)vLLM實(shí)例上通過多個(gè)served-model-name做邏輯隔離并嚴(yán)格控制每個(gè)租戶的并發(fā)上限。你不想某天一個(gè)租戶的流量把自己整個(gè)推理服務(wù)打掛。5.4 常見問題排查速查表把日常遇到的典型問題和對應(yīng)排查手段整理成一張速查表方便直接定位?，F(xiàn)象可能原因快速排查手段服務(wù)啟動時(shí)報(bào)CUDA OOM權(quán)重KV Cache超顯存降低gpu-memory-utilization減短max-model-len換量化格式請求偶爾超時(shí)或報(bào)429并發(fā)隊(duì)列打滿查vLLM日志和指標(biāo)中的pending_requests數(shù)調(diào)大并發(fā)上限模型回復(fù)質(zhì)量變差量化損失或Temperature過高檢查推理參數(shù)必要時(shí)切換BF16首token延遲異常高長前綴未命中緩存用SGLang或優(yōu)化系統(tǒng)提示詞長度GPU利用率忽高忽低短連接請求過多Nginx開啟keepalive復(fù)用連接多卡NCCL通信報(bào)錯(cuò)網(wǎng)卡驅(qū)動或互聯(lián)帶寬不足檢查多卡型號和NCCL版本確認(rèn)P2P通信正常下載模型總是中斷公網(wǎng)傳輸不穩(wěn)定先傳對象存儲再內(nèi)網(wǎng)拷貝或用ModelScope加速5.5 監(jiān)控與告警配置最后說監(jiān)控。vLLM原生暴露Prometheus指標(biāo)接口這是生產(chǎn)部署必須配置的一層。最重要的指標(biāo)是request_successful/request_failed成功率監(jiān)控。avg_generation_throughput平均生成吞吐觀察每張卡的產(chǎn)出。e2e_request_latency端到端延遲分布這是用戶真實(shí)體感的直接體現(xiàn)。pending_requests當(dāng)前排隊(duì)請求數(shù)暴增說明后端處理不過來。GPU硬件層面的指標(biāo)建議用NVIDIA DCGM Exporter采集包括顯存使用率、GPU溫度、功耗、PCIe帶寬。告警規(guī)則至少要覆蓋三類顯存使用率超過95%、GPU溫度超過80度、服務(wù)成功率掉到99%以下。別等到用戶投訴了才發(fā)現(xiàn)服務(wù)掛了機(jī)器上的nvidia-smi頂多是排查工具真正的守護(hù)者是監(jiān)控和告警。寫在最后部署大模型這件事真正難的不是那些炫酷的技術(shù)名詞而是一步步把工程細(xì)節(jié)摳到位。我在實(shí)際項(xiàng)目中體會最深的一點(diǎn)是框架選型、模型格式、顯存規(guī)劃這些東西一定會在部署完成后持續(xù)影響你的穩(wěn)定性。前期多花一小時(shí)做方案后期能省下十幾個(gè)小時(shí)的排查時(shí)間。最后分享一個(gè)小技巧無論你最終選擇了什么框架先在小規(guī)模、低并發(fā)的環(huán)境里把整套鏈路跑通包括模型下載、鏡像構(gòu)建、API測試、監(jiān)控采集然后再逐步加壓到生產(chǎn)負(fù)載。千萬不要在業(yè)務(wù)上線前一天才開始做壓測那基本等于把穩(wěn)定性交給運(yùn)氣。把這個(gè)流程固化為團(tuán)隊(duì)的標(biāo)準(zhǔn)操作文檔后面每次部署新模型都能少踩很多坑。