到LLM推理平臺(tái)：模型部署、vLLM與K8s實(shí)戰(zhàn))
1. 從跑通一個(gè)模型到撐起一個(gè)平臺(tái)的認(rèn)知分水嶺很多人第一次接觸模型部署都是從一行docker run或者一個(gè)python app.py開(kāi)始的。本地把權(quán)重加載進(jìn)去接口能返回結(jié)果截圖發(fā)個(gè)朋友圈這事就算成了。但真正到了正式環(huán)境你會(huì)發(fā)現(xiàn)事情完全不是這個(gè)量級(jí)模型不止一個(gè)請(qǐng)求量忽高忽低GPU 卡就那么幾張業(yè)務(wù)方還要求灰度發(fā)布、A/B 測(cè)試、監(jiān)控告警、故障回滾。這時(shí)候你面對(duì)的已經(jīng)不是怎么把模型跑起來(lái)而是怎么讓一堆模型在有限資源上穩(wěn)定地對(duì)外服務(wù)。這篇內(nèi)容想聊的就是這條演進(jìn)路徑從最樸素的單模型服務(wù)到多模型統(tǒng)一調(diào)度再到面向 LLM 的推理平臺(tái)。關(guān)鍵詞里出現(xiàn)的模型部署、LLM、vLLM、Triton、K8s基本勾勒出了這條路徑上的核心組件。我會(huì)把每個(gè)階段為什么這么選坑在哪里參數(shù)怎么定講清楚而不是丟一堆名詞讓你自己去拼。適合已經(jīng)能把模型跑起來(lái)、但一上生產(chǎn)就手忙腳亂的工程師也適合正在做推理平臺(tái)選型的技術(shù)負(fù)責(zé)人。先說(shuō)一個(gè)反直覺(jué)的結(jié)論單模型服務(wù)和推理平臺(tái)之間最大的差距不是技術(shù)棧而是資源抽象這件事。單模型服務(wù)里模型和進(jìn)程是一一綁定的你腦子里想的是這個(gè)進(jìn)程占幾張卡而平臺(tái)化之后模型變成了一個(gè)可以被調(diào)度、被復(fù)用、被動(dòng)態(tài)加載的資源對(duì)象你腦子里想的應(yīng)該是這批請(qǐng)求該路由到哪個(gè)已加載的模型實(shí)例上。想不通這一層后面堆再多組件都是白搭。2. 單模型服務(wù)階段那些看起來(lái)能用、上量就崩的做法2.1 最樸素的 Flask/FastAPI 包一層為什么撐不住最常見(jiàn)的起步方式寫(xiě)個(gè) FastAPI啟動(dòng)時(shí)把模型 load 進(jìn)顯存暴露一個(gè)/predict接口前面掛個(gè) Nginx。小流量下確實(shí)沒(méi)問(wèn)題我早期做圖像分類(lèi)服務(wù)就是這么干的。但問(wèn)題會(huì)在幾個(gè)地方集中爆發(fā)。第一是并發(fā)模型不匹配。Python 的 GIL 決定了你用多線程跑推理基本沒(méi)意義真正吃滿 GPU 要靠批處理batching。而樸素寫(xiě)法是一個(gè)請(qǐng)求進(jìn)來(lái)就推理一次GPU 利用率可能只有 10%~20%因?yàn)榇蟛糠謺r(shí)間在等數(shù)據(jù)搬運(yùn)和 kernel 啟動(dòng)。第二是顯存常駐。模型一直占著卡哪怕半夜沒(méi)請(qǐng)求也不釋放多模型場(chǎng)景下這就是災(zāi)難。第三是沒(méi)有健康檢查和優(yōu)雅退出進(jìn)程崩了沒(méi)人拉起來(lái)正在處理的請(qǐng)求直接丟。我見(jiàn)過(guò)一個(gè)團(tuán)隊(duì)用這種方式部署 BERT 類(lèi)模型單卡 QPS 卡在 30 上不去后來(lái)?yè)Q成帶動(dòng)態(tài)批處理的方案同樣的卡跑到 200。差距不在模型在服務(wù)框架。2.2 動(dòng)態(tài)批處理單模型服務(wù)第一個(gè)必須補(bǔ)的課動(dòng)態(tài)批處理dynamic batching的核心思想是在極短的時(shí)間窗口內(nèi)比如幾毫秒到幾十毫秒把多個(gè)請(qǐng)求攢成一個(gè) batch一起送進(jìn) GPU。GPU 最擅長(zhǎng)的就是并行矩陣運(yùn)算batch size 從 1 提到 8延遲可能只增加 20%但吞吐直接翻好幾倍。這里有個(gè)關(guān)鍵參數(shù)叫max_batch_size和batch_timeout。設(shè)太小攢不起來(lái)等于沒(méi)批設(shè)太大延遲飆升用戶體驗(yàn)崩。經(jīng)驗(yàn)值是在線交互類(lèi)服務(wù)batch_timeout 控制在 5~10msmax_batch_size 根據(jù)顯存和模型大小定通常 8~32。離線批處理任務(wù)可以放寬到幾百毫秒甚至秒級(jí)。提示動(dòng)態(tài)批處理不是萬(wàn)能的。如果請(qǐng)求的輸入長(zhǎng)度差異極大比如 LLM 場(chǎng)景有的問(wèn)一句話有的貼一整篇文檔簡(jiǎn)單 padding 到統(tǒng)一長(zhǎng)度會(huì)浪費(fèi)大量算力。這時(shí)候需要的是連續(xù)批處理continuous batching這是后面講 vLLM 的重點(diǎn)。2.3 單模型服務(wù)的邊界在哪里判斷你該不該繼續(xù)用單模型服務(wù)看三個(gè)信號(hào)模型數(shù)量超過(guò) 3 個(gè)、GPU 卡需要跨模型共享、業(yè)務(wù)要求不停機(jī)更新模型。只要中了一條就該考慮往平臺(tái)化走了。繼續(xù)硬扛的代價(jià)是運(yùn)維復(fù)雜度指數(shù)上升——每個(gè)模型一套部署腳本、一套監(jiān)控、一套擴(kuò)縮容邏輯改一處要?jiǎng)邮帯?. 多模型服務(wù)框架Triton 到底解決了什么問(wèn)題3.1 Triton 的核心抽象模型倉(cāng)庫(kù) 調(diào)度器NVIDIA Triton Inference Server 是這一層最典型的代表。它把模型抽象成一個(gè)**模型倉(cāng)庫(kù)model repository**里的目錄每個(gè)模型有自己的配置文件config.pbtxt聲明輸入輸出、使用的后端backend、批處理策略、實(shí)例數(shù)量。服務(wù)啟動(dòng)時(shí)掃描倉(cāng)庫(kù)按配置加載。這個(gè)抽象帶來(lái)的直接好處是同一個(gè)進(jìn)程可以同時(shí)服務(wù)多個(gè)模型共享 GPU 資源統(tǒng)一暴露 HTTP/gRPC 接口。你不用再為每個(gè)模型寫(xiě)一套服務(wù)代碼只需要寫(xiě)配置。支持的 backend 覆蓋 TensorRT、ONNX Runtime、PyTorch、TensorFlow甚至 Python 自定義 backend。一個(gè)典型的config.pbtxt長(zhǎng)這樣name: resnet50 platform: onnxruntime_onnx max_batch_size: 16 input [ { name: input data_type: TYPE_FP32 dims: [3, 224, 224] } ] output [ { name: output data_type: TYPE_FP32 dims: [1000] } ] dynamic_batching { preferred_batch_size: [8, 16] max_queue_delay_microseconds: 5000 } instance_group [ { count: 2 kind: KIND_GPU gpus: [0] } ]instance_group里的count: 2表示在 GPU 0 上起兩個(gè)模型實(shí)例配合動(dòng)態(tài)批處理能進(jìn)一步提升吞吐。preferred_batch_size告訴調(diào)度器優(yōu)先湊成 8 或 16 的批。3.2 模型版本管理與熱更新Triton 的模型倉(cāng)庫(kù)支持版本號(hào)目錄比如resnet50/1/、resnet50/2/。默認(rèn)策略是加載最新版本但你可以通過(guò)接口指定用哪個(gè)版本實(shí)現(xiàn)灰度。更實(shí)用的是模型控制 API不重啟服務(wù)的情況下可以 unload 舊版本、load 新版本。這對(duì)生產(chǎn)環(huán)境太重要了——重啟一次服務(wù)所有模型都要重新加載冷啟動(dòng)可能幾分鐘期間服務(wù)不可用。我踩過(guò)的一個(gè)坑Triton 的模型加載是懶加載還是預(yù)加載取決于配置。默認(rèn)啟動(dòng)時(shí)會(huì)嘗試加載所有模型如果某個(gè)模型配置寫(xiě)錯(cuò)整個(gè)服務(wù)可能起不來(lái)。生產(chǎn)環(huán)境建議開(kāi)啟--strict-model-configfalse讓它自動(dòng)推斷配置同時(shí)用--model-control-modeexplicit手動(dòng)控制加載時(shí)機(jī)避免一個(gè)壞模型拖垮全局。3.3 Triton 在 LLM 場(chǎng)景下的局限Triton 很強(qiáng)但它是為傳統(tǒng)深度學(xué)習(xí)模型設(shè)計(jì)的。到了 LLM 時(shí)代它的短板暴露出來(lái)LLM 的推理是自回歸的一個(gè)請(qǐng)求要跑幾十上百步每步生成一個(gè) token。傳統(tǒng)批處理是一個(gè) batch 一起進(jìn)一起出而 LLM 里不同請(qǐng)求的生成長(zhǎng)度不同短請(qǐng)求早就結(jié)束了長(zhǎng)請(qǐng)求還在跑如果按傳統(tǒng)批處理短請(qǐng)求要等長(zhǎng)請(qǐng)求GPU 利用率極低。這就是為什么 LLM 推理需要專(zhuān)門(mén)的框架。Triton 也能通過(guò) TensorRT-LLM backend 跑 LLM但配置復(fù)雜且對(duì)連續(xù)批處理的支持不如 vLLM 這類(lèi)原生方案來(lái)得自然。4. LLM 推理框架選型vLLM 憑什么成為主流4.1 PagedAttention把顯存碎片問(wèn)題摁下去LLM 推理的顯存消耗分兩塊模型權(quán)重和 KV Cache。KV Cache 是注意力機(jī)制里緩存的歷史 key/value隨著生成長(zhǎng)度線性增長(zhǎng)。傳統(tǒng)做法是給每個(gè)請(qǐng)求預(yù)分配一塊連續(xù)顯存按最大可能長(zhǎng)度分配結(jié)果就是大量顯存被浪費(fèi)在預(yù)留但沒(méi)用上的空間里碎片嚴(yán)重能同時(shí)服務(wù)的請(qǐng)求數(shù)上不去。vLLM 的核心創(chuàng)新PagedAttention借鑒了操作系統(tǒng)的虛擬內(nèi)存分頁(yè)思想把 KV Cache 切成固定大小的 block按需分配邏輯上連續(xù)、物理上可以不連續(xù)。這樣一來(lái)顯存利用率能從傳統(tǒng)的 20%~40% 提升到 90% 以上同樣的卡能同時(shí)服務(wù)的請(qǐng)求數(shù)翻好幾倍。這不是玄學(xué)是實(shí)打?qū)嵉耐掏绿嵘?.2 連續(xù)批處理讓 GPU 一刻不停連續(xù)批處理continuous batching也叫 iteration-level scheduling解決的是前面提到的長(zhǎng)短請(qǐng)求互相拖累問(wèn)題。它的做法是以每一步生成一個(gè) token為調(diào)度單位某一步結(jié)束后完成的請(qǐng)求立刻退出 batch新請(qǐng)求立刻補(bǔ)進(jìn)來(lái)。GPU 永遠(yuǎn)在處理一個(gè)滿員的 batch利用率拉滿。實(shí)測(cè)下來(lái)vLLM 相比樸素的 HuggingFacegenerate循環(huán)吞吐提升通常在 10 倍以上具體倍數(shù)取決于請(qǐng)求長(zhǎng)度分布和并發(fā)量。這也是為什么現(xiàn)在一提 LLM 部署vLLM 幾乎是默認(rèn)答案。4.3 vLLM 部署的實(shí)操參數(shù)與坑啟動(dòng)一個(gè) vLLM 的 OpenAI 兼容服務(wù)典型命令python -m vllm.entrypoints.openai.api_server \ --model /models/Qwen2.5-7B-Instruct \ --served-model-name qwen2.5-7b \ --tensor-parallel-size 2 \ --gpu-memory-utilization 0.9 \ --max-model-len 8192 \ --max-num-seqs 256 \ --port 8000幾個(gè)參數(shù)值得展開(kāi)說(shuō)--tensor-parallel-size張量并行度等于用幾張卡跑一個(gè)模型。7B 模型單卡 24G 基本夠70B 就得上 4 卡或 8 卡。注意這個(gè)值必須是 2 的冪次或能被注意力頭數(shù)整除否則起不來(lái)。--gpu-memory-utilizationvLLM 會(huì)按這個(gè)比例預(yù)占顯存用于 KV Cache。設(shè) 0.9 意味著留 10% 給其他開(kāi)銷(xiāo)。設(shè)太高容易 OOM設(shè)太低浪費(fèi)顯存。建議從 0.85 起步觀察穩(wěn)定后再調(diào)。--max-model-len最大上下文長(zhǎng)度。這個(gè)值直接決定 KV Cache 的單請(qǐng)求占用設(shè)太大顯存吃緊設(shè)太小長(zhǎng)文本請(qǐng)求會(huì)被拒。要和模型本身支持的長(zhǎng)度匹配。--max-num-seqs同時(shí)處理的最大請(qǐng)求數(shù)。太小并發(fā)上不去太大顯存扛不住。注意vLLM 啟動(dòng)時(shí)會(huì)做一次顯存 profiling如果gpu-memory-utilization設(shè)得過(guò)高可能在 profiling 階段就報(bào) OOM。遇到這種情況先降這個(gè)值而不是懷疑模型有問(wèn)題。另一個(gè)常見(jiàn)坑是模型格式。vLLM 對(duì) HuggingFace 格式支持最好GGUF 格式雖然也能跑但性能打折ONNX 需要額外轉(zhuǎn)換。如果你手頭是 GGUF 量化模型想要極致性能建議用 llama.cpp 系列想要高并發(fā)服務(wù)還是轉(zhuǎn)成 HF 格式喂給 vLLM。4.4 vLLM、SGLang、TGI、Ollama 的定位差異這幾個(gè)經(jīng)常被放在一起比其實(shí)定位完全不同框架定位適合場(chǎng)景不適合場(chǎng)景vLLM高吞吐生產(chǎn)推理在線服務(wù)、高并發(fā)單機(jī)個(gè)人玩票SGLang高吞吐 復(fù)雜編排需要結(jié)構(gòu)化生成、多輪簡(jiǎn)單問(wèn)答TGIHuggingFace 官方HF 生態(tài)深度用戶非 HF 模型Ollama本地一鍵運(yùn)行個(gè)人開(kāi)發(fā)、桌面端生產(chǎn)高并發(fā)llama.cpp極致輕量邊緣設(shè)備、CPU 推理大規(guī)模并發(fā)Ollama 底層其實(shí)也用了 llama.cpp它的價(jià)值在于把模型下載、量化、運(yùn)行打包成一條命令對(duì)個(gè)人開(kāi)發(fā)者極其友好。但它的調(diào)度能力、并發(fā)能力、顯存管理都遠(yuǎn)不如 vLLM別拿它上生產(chǎn)。我見(jiàn)過(guò)有人用 Ollama 扛線上流量QPS 一過(guò) 5 就開(kāi)始排隊(duì)這就是定位錯(cuò)配。5. K8s 上的推理平臺(tái)把模型當(dāng)成一等公民來(lái)調(diào)度5.1 為什么推理平臺(tái)最終都會(huì)落到 K8s當(dāng)模型數(shù)量、GPU 節(jié)點(diǎn)數(shù)量、團(tuán)隊(duì)人數(shù)都上來(lái)了裸機(jī)部署的運(yùn)維成本會(huì)壓垮你。K8s 提供的價(jià)值在于統(tǒng)一的資源調(diào)度、聲明式的部署管理、自動(dòng)擴(kuò)縮容、服務(wù)發(fā)現(xiàn)、滾動(dòng)更新。這些能力對(duì)推理平臺(tái)來(lái)說(shuō)是剛需。但 K8s 原生不認(rèn)識(shí) GPU。你需要NVIDIA Device Plugin把 GPU 暴露成可調(diào)度資源然后在 Pod 里通過(guò)resources.limits申請(qǐng)resources: limits: nvidia.com/gpu: 2這樣調(diào)度器就知道這個(gè) Pod 要占 2 張卡會(huì)把它調(diào)度到有足夠 GPU 的節(jié)點(diǎn)上。5.2 推理服務(wù)的 K8s 部署形態(tài)Deployment 還是 StatefulSet大多數(shù)推理服務(wù)用Deployment就夠了因?yàn)槟Ｐ蛯?shí)例是無(wú)狀態(tài)的模型權(quán)重從鏡像或 PVC 加載KV Cache 是請(qǐng)求級(jí)的。但有幾個(gè)細(xì)節(jié)要注意模型權(quán)重怎么進(jìn)容器小模型可以打進(jìn)鏡像大模型幾十上百 G必須用 PVC 掛載或者啟動(dòng)時(shí)從對(duì)象存儲(chǔ)拉。打進(jìn)鏡像會(huì)導(dǎo)致鏡像巨大、拉取慢、更新困難。就緒探針readinessProbe要配好模型加載可能要幾分鐘這期間 Pod 不能接流量。探針要指向一個(gè)模型已加載完成的健康接口而不是簡(jiǎn)單的端口探測(cè)。優(yōu)雅退出preStop terminationGracePeriodSecondsLLM 請(qǐng)求可能跑很久直接 kill 會(huì)丟請(qǐng)求。要給足退出時(shí)間讓正在處理的請(qǐng)求跑完。5.3 自動(dòng)擴(kuò)縮容HPA 在推理場(chǎng)景下的尷尬K8s 的 HPA 默認(rèn)按 CPU/內(nèi)存擴(kuò)縮容但推理服務(wù)的瓶頸是GPU 和請(qǐng)求隊(duì)列長(zhǎng)度CPU 可能一直很低。這時(shí)候需要基于自定義指標(biāo)擴(kuò)縮容比如用 Prometheus Adapter 把 vLLM 暴露的num_requests_waiting指標(biāo)接進(jìn)來(lái)隊(duì)列長(zhǎng)了就擴(kuò)容。但 GPU 擴(kuò)容有個(gè)現(xiàn)實(shí)問(wèn)題擴(kuò)容慢。一個(gè)新 Pod 從調(diào)度到模型加載完成可能要好幾分鐘。等它起來(lái)流量高峰可能已經(jīng)過(guò)去了。所以生產(chǎn)上更常見(jiàn)的策略是預(yù)留 buffer平時(shí)保持一定冗余實(shí)例配合較激進(jìn)的擴(kuò)容閾值和較保守的縮容閾值寧可多占一點(diǎn)資源也別讓用戶等。5.4 多模型共享 GPUMIG 與時(shí)間片一張卡怎么給多個(gè)模型用兩條路MIGMulti-Instance GPU把 A100/H100 這類(lèi)卡硬件切分成多個(gè)獨(dú)立實(shí)例每個(gè)實(shí)例有獨(dú)立的顯存和算力隔離性好。缺點(diǎn)是切分粒度固定且不是所有卡都支持。時(shí)間片共享多個(gè)進(jìn)程輪流用 GPU靠 CUDA 的上下文切換。隔離性差一個(gè)進(jìn)程跑滿會(huì)影響其他進(jìn)程但靈活。生產(chǎn)上如果模型對(duì)延遲敏感優(yōu)先 MIG如果是離線批處理混部時(shí)間片也能接受。Triton 的instance_group其實(shí)就是在做進(jìn)程級(jí)的共享配合顯存控制能實(shí)現(xiàn)一定程度的隔離。6. 平臺(tái)化之后的新問(wèn)題網(wǎng)關(guān)、可觀測(cè)性與成本6.1 LLM 網(wǎng)關(guān)別讓業(yè)務(wù)直接懟推理服務(wù)推理平臺(tái)前面通常要加一層網(wǎng)關(guān)職責(zé)包括鑒權(quán)、限流、路由、多模型統(tǒng)一接口、token 計(jì)費(fèi)統(tǒng)計(jì)。關(guān)鍵詞里提到的 llm 網(wǎng)關(guān) 就是這個(gè)東西。它的價(jià)值在于把哪個(gè)模型部署在哪、用什么協(xié)議這些細(xì)節(jié)對(duì)業(yè)務(wù)屏蔽掉業(yè)務(wù)只管調(diào)一個(gè)統(tǒng)一的 OpenAI 兼容接口。路由策略是網(wǎng)關(guān)的核心。常見(jiàn)的有按模型名路由、按成本路由便宜的模型優(yōu)先、按負(fù)載路由哪個(gè)實(shí)例隊(duì)列短去哪個(gè)、按用戶等級(jí)路由VIP 走專(zhuān)用實(shí)例。這些策略組合起來(lái)能在不增加硬件的情況下顯著提升資源利用率。6.2 可觀測(cè)性LLM 服務(wù)的指標(biāo)和傳統(tǒng)服務(wù)不一樣傳統(tǒng)服務(wù)看 QPS、延遲、錯(cuò)誤率就夠了。LLM 服務(wù)還要看首 token 延遲TTFT、每 token 輸出延遲TPOT、輸入輸出 token 數(shù)、KV Cache 使用率、排隊(duì)請(qǐng)求數(shù)。TTFT 決定用戶感覺(jué)快不快TPOT 決定吐字順不順這兩個(gè)指標(biāo)比總延遲更能反映體驗(yàn)。vLLM 原生暴露 Prometheus 指標(biāo)接上 Grafana 就能看。重點(diǎn)盯vllm:num_requests_waiting排隊(duì)數(shù)和vllm:gpu_cache_usage_percKV Cache 使用率前者持續(xù)大于 0 說(shuō)明該擴(kuò)容了后者接近 1 說(shuō)明顯存快滿了。6.3 成本控制推理平臺(tái)最容易被忽視的一環(huán)GPU 是燒錢(qián)的。平臺(tái)化之后如果沒(méi)有成本意識(shí)很容易出現(xiàn)卡都占著但利用率很低的情況。幾個(gè)實(shí)用手段按需加載/卸載模型冷門(mén)模型不常駐請(qǐng)求來(lái)了再加載用完一段時(shí)間后卸載。代價(jià)是首次請(qǐng)求慢。量化INT8/INT4 量化能把顯存占用降一半甚至更多吞吐提升明顯精度損失在可接受范圍內(nèi)。AWQ、GPTQ 是常見(jiàn)的 LLM 量化方案?；觳堪蜒舆t不敏感的離線任務(wù)和在線服務(wù)混在同一批卡上用優(yōu)先級(jí)調(diào)度錯(cuò)峰使用。7. 我在實(shí)際落地中踩過(guò)的幾個(gè)真實(shí)坑第一個(gè)坑是顯存碎片導(dǎo)致的看起來(lái)夠用其實(shí)不夠。有次部署一個(gè) 13B 模型卡是 24G模型權(quán)重占 26G 的一半多理論上夠。但實(shí)際跑起來(lái)頻繁 OOM原因是 KV Cache 分配時(shí)找不到連續(xù)的大塊顯存。后來(lái)把gpu-memory-utilization從 0.95 降到 0.85問(wèn)題消失。顯存不是看總量是看最大連續(xù)可用塊。第二個(gè)坑是K8s 的 GPU 調(diào)度和實(shí)際顯存不匹配。K8s 只認(rèn)幾張卡不認(rèn)卡上還剩多少顯存。如果兩個(gè) Pod 各申請(qǐng) 1 張卡但每個(gè)模型都要占滿整卡顯存第二個(gè) Pod 起來(lái)就會(huì) OOM。解決辦法是用 MIG 切分或者用支持顯存感知調(diào)度的方案再或者干脆一個(gè)模型獨(dú)占一張卡。第三個(gè)坑是模型加載時(shí)間被嚴(yán)重低估。一個(gè) 70B 模型從磁盤(pán)加載到顯存冷啟動(dòng)可能要 5~10 分鐘。如果 K8s 的initialDelaySeconds設(shè)得太短Pod 還沒(méi)加載完就被判定為不健康反復(fù)重啟永遠(yuǎn)起不來(lái)。探針的初始延遲一定要按最壞情況設(shè)寧可多等別讓它誤殺。第四個(gè)坑是網(wǎng)關(guān)超時(shí)和推理超時(shí)沒(méi)對(duì)齊。網(wǎng)關(guān)默認(rèn) 30 秒超時(shí)但 LLM 生成一篇長(zhǎng)文可能要 60 秒結(jié)果網(wǎng)關(guān)先斷了用戶看到報(bào)錯(cuò)其實(shí)后端還在正常跑。網(wǎng)關(guān)超時(shí)必須大于推理服務(wù)的最大預(yù)期耗時(shí)并且要支持流式返回讓用戶邊生成邊看到內(nèi)容。8. 從當(dāng)前架構(gòu)往下一步走的幾個(gè)方向如果你現(xiàn)在的平臺(tái)已經(jīng)能穩(wěn)定跑起來(lái)接下來(lái)可以關(guān)注這幾個(gè)方向。一是推理加速的持續(xù)優(yōu)化比如投機(jī)解碼speculative decoding、前綴緩存prefix caching前者用小模型草稿大模型驗(yàn)證來(lái)提速后者對(duì)多輪對(duì)話場(chǎng)景能省掉重復(fù)的 prompt 計(jì)算。二是多模態(tài)模型的統(tǒng)一服務(wù)圖像、語(yǔ)音、文本模型用同一套調(diào)度框架管理這對(duì)平臺(tái)抽象能力要求更高。三是彈性與混部把在線推理和離線訓(xùn)練/批處理放到同一個(gè)資源池用優(yōu)先級(jí)和搶占機(jī)制提升整體利用率。這些方向沒(méi)有標(biāo)準(zhǔn)答案取決于你的業(yè)務(wù)形態(tài)和成本結(jié)構(gòu)。但有一條是確定的平臺(tái)的價(jià)值不在于支持多少種模型而在于把部署一個(gè)模型這件事的成本降到足夠低。當(dāng)業(yè)務(wù)方能在幾分鐘內(nèi)自助上線一個(gè)新模型且不用關(guān)心底層是幾張卡、跑在哪個(gè)節(jié)點(diǎn)上時(shí)這個(gè)平臺(tái)才算真正立住了。 從單模型服務(wù)到LLM推理平臺(tái)：模型部署、vLLM與K8s實(shí)戰(zhàn)
1. 從跑通一個(gè)模型到撐起一個(gè)平臺(tái)的認(rèn)知分水嶺很多人第一次接觸模型部署都是從一行docker run或者一個(gè)python app.py開(kāi)始的。本地把權(quán)重加載進(jìn)去接口能返回結(jié)果截圖發(fā)個(gè)朋友圈這事就算成了。但真正到了正式環(huán)境你會(huì)發(fā)現(xiàn)事情完全不是這個(gè)量級(jí)模型不止一個(gè)請(qǐng)求量忽高忽低GPU 卡就那么幾張業(yè)務(wù)方還要求灰度發(fā)布、A/B 測(cè)試、監(jiān)控告警、故障回滾。這時(shí)候你面對(duì)的已經(jīng)不是怎么把模型跑起來(lái)而是怎么讓一堆模型在有限資源上穩(wěn)定地對(duì)外服務(wù)。這篇內(nèi)容想聊的就是這條演進(jìn)路徑從最樸素的單模型服務(wù)到多模型統(tǒng)一調(diào)度再到面向 LLM 的推理平臺(tái)。關(guān)鍵詞里出現(xiàn)的模型部署、LLM、vLLM、Triton、K8s基本勾勒出了這條路徑上的核心組件。我會(huì)把每個(gè)階段為什么這么選坑在哪里參數(shù)怎么定講清楚而不是丟一堆名詞讓你自己去拼。適合已經(jīng)能把模型跑起來(lái)、但一上生產(chǎn)就手忙腳亂的工程師也適合正在做推理平臺(tái)選型的技術(shù)負(fù)責(zé)人。先說(shuō)一個(gè)反直覺(jué)的結(jié)論單模型服務(wù)和推理平臺(tái)之間最大的差距不是技術(shù)棧而是資源抽象這件事。單模型服務(wù)里模型和進(jìn)程是一一綁定的你腦子里想的是這個(gè)進(jìn)程占幾張卡而平臺(tái)化之后模型變成了一個(gè)可以被調(diào)度、被復(fù)用、被動(dòng)態(tài)加載的資源對(duì)象你腦子里想的應(yīng)該是這批請(qǐng)求該路由到哪個(gè)已加載的模型實(shí)例上。想不通這一層后面堆再多組件都是白搭。2. 單模型服務(wù)階段那些看起來(lái)能用、上量就崩的做法2.1 最樸素的 Flask/FastAPI 包一層為什么撐不住最常見(jiàn)的起步方式寫(xiě)個(gè) FastAPI啟動(dòng)時(shí)把模型 load 進(jìn)顯存暴露一個(gè)/predict接口前面掛個(gè) Nginx。小流量下確實(shí)沒(méi)問(wèn)題我早期做圖像分類(lèi)服務(wù)就是這么干的。但問(wèn)題會(huì)在幾個(gè)地方集中爆發(fā)。第一是并發(fā)模型不匹配。Python 的 GIL 決定了你用多線程跑推理基本沒(méi)意義真正吃滿 GPU 要靠批處理batching。而樸素寫(xiě)法是一個(gè)請(qǐng)求進(jìn)來(lái)就推理一次GPU 利用率可能只有 10%~20%因?yàn)榇蟛糠謺r(shí)間在等數(shù)據(jù)搬運(yùn)和 kernel 啟動(dòng)。第二是顯存常駐。模型一直占著卡哪怕半夜沒(méi)請(qǐng)求也不釋放多模型場(chǎng)景下這就是災(zāi)難。第三是沒(méi)有健康檢查和優(yōu)雅退出進(jìn)程崩了沒(méi)人拉起來(lái)正在處理的請(qǐng)求直接丟。我見(jiàn)過(guò)一個(gè)團(tuán)隊(duì)用這種方式部署 BERT 類(lèi)模型單卡 QPS 卡在 30 上不去后來(lái)?yè)Q成帶動(dòng)態(tài)批處理的方案同樣的卡跑到 200。差距不在模型在服務(wù)框架。2.2 動(dòng)態(tài)批處理單模型服務(wù)第一個(gè)必須補(bǔ)的課動(dòng)態(tài)批處理dynamic batching的核心思想是在極短的時(shí)間窗口內(nèi)比如幾毫秒到幾十毫秒把多個(gè)請(qǐng)求攢成一個(gè) batch一起送進(jìn) GPU。GPU 最擅長(zhǎng)的就是并行矩陣運(yùn)算batch size 從 1 提到 8延遲可能只增加 20%但吞吐直接翻好幾倍。這里有個(gè)關(guān)鍵參數(shù)叫max_batch_size和batch_timeout。設(shè)太小攢不起來(lái)等于沒(méi)批設(shè)太大延遲飆升用戶體驗(yàn)崩。經(jīng)驗(yàn)值是在線交互類(lèi)服務(wù)batch_timeout 控制在 5~10msmax_batch_size 根據(jù)顯存和模型大小定通常 8~32。離線批處理任務(wù)可以放寬到幾百毫秒甚至秒級(jí)。提示動(dòng)態(tài)批處理不是萬(wàn)能的。如果請(qǐng)求的輸入長(zhǎng)度差異極大比如 LLM 場(chǎng)景有的問(wèn)一句話有的貼一整篇文檔簡(jiǎn)單 padding 到統(tǒng)一長(zhǎng)度會(huì)浪費(fèi)大量算力。這時(shí)候需要的是連續(xù)批處理continuous batching這是后面講 vLLM 的重點(diǎn)。2.3 單模型服務(wù)的邊界在哪里判斷你該不該繼續(xù)用單模型服務(wù)看三個(gè)信號(hào)模型數(shù)量超過(guò) 3 個(gè)、GPU 卡需要跨模型共享、業(yè)務(wù)要求不停機(jī)更新模型。只要中了一條就該考慮往平臺(tái)化走了。繼續(xù)硬扛的代價(jià)是運(yùn)維復(fù)雜度指數(shù)上升——每個(gè)模型一套部署腳本、一套監(jiān)控、一套擴(kuò)縮容邏輯改一處要?jiǎng)邮帯?. 多模型服務(wù)框架Triton 到底解決了什么問(wèn)題3.1 Triton 的核心抽象模型倉(cāng)庫(kù) 調(diào)度器NVIDIA Triton Inference Server 是這一層最典型的代表。它把模型抽象成一個(gè)**模型倉(cāng)庫(kù)model repository**里的目錄每個(gè)模型有自己的配置文件config.pbtxt聲明輸入輸出、使用的后端backend、批處理策略、實(shí)例數(shù)量。服務(wù)啟動(dòng)時(shí)掃描倉(cāng)庫(kù)按配置加載。這個(gè)抽象帶來(lái)的直接好處是同一個(gè)進(jìn)程可以同時(shí)服務(wù)多個(gè)模型共享 GPU 資源統(tǒng)一暴露 HTTP/gRPC 接口。你不用再為每個(gè)模型寫(xiě)一套服務(wù)代碼只需要寫(xiě)配置。支持的 backend 覆蓋 TensorRT、ONNX Runtime、PyTorch、TensorFlow甚至 Python 自定義 backend。一個(gè)典型的config.pbtxt長(zhǎng)這樣name: resnet50 platform: onnxruntime_onnx max_batch_size: 16 input [ { name: input data_type: TYPE_FP32 dims: [3, 224, 224] } ] output [ { name: output data_type: TYPE_FP32 dims: [1000] } ] dynamic_batching { preferred_batch_size: [8, 16] max_queue_delay_microseconds: 5000 } instance_group [ { count: 2 kind: KIND_GPU gpus: [0] } ]instance_group里的count: 2表示在 GPU 0 上起兩個(gè)模型實(shí)例配合動(dòng)態(tài)批處理能進(jìn)一步提升吞吐。preferred_batch_size告訴調(diào)度器優(yōu)先湊成 8 或 16 的批。3.2 模型版本管理與熱更新Triton 的模型倉(cāng)庫(kù)支持版本號(hào)目錄比如resnet50/1/、resnet50/2/。默認(rèn)策略是加載最新版本但你可以通過(guò)接口指定用哪個(gè)版本實(shí)現(xiàn)灰度。更實(shí)用的是模型控制 API不重啟服務(wù)的情況下可以 unload 舊版本、load 新版本。這對(duì)生產(chǎn)環(huán)境太重要了——重啟一次服務(wù)所有模型都要重新加載冷啟動(dòng)可能幾分鐘期間服務(wù)不可用。我踩過(guò)的一個(gè)坑Triton 的模型加載是懶加載還是預(yù)加載取決于配置。默認(rèn)啟動(dòng)時(shí)會(huì)嘗試加載所有模型如果某個(gè)模型配置寫(xiě)錯(cuò)整個(gè)服務(wù)可能起不來(lái)。生產(chǎn)環(huán)境建議開(kāi)啟--strict-model-configfalse讓它自動(dòng)推斷配置同時(shí)用--model-control-modeexplicit手動(dòng)控制加載時(shí)機(jī)避免一個(gè)壞模型拖垮全局。3.3 Triton 在 LLM 場(chǎng)景下的局限Triton 很強(qiáng)但它是為傳統(tǒng)深度學(xué)習(xí)模型設(shè)計(jì)的。到了 LLM 時(shí)代它的短板暴露出來(lái)LLM 的推理是自回歸的一個(gè)請(qǐng)求要跑幾十上百步每步生成一個(gè) token。傳統(tǒng)批處理是一個(gè) batch 一起進(jìn)一起出而 LLM 里不同請(qǐng)求的生成長(zhǎng)度不同短請(qǐng)求早就結(jié)束了長(zhǎng)請(qǐng)求還在跑如果按傳統(tǒng)批處理短請(qǐng)求要等長(zhǎng)請(qǐng)求GPU 利用率極低。這就是為什么 LLM 推理需要專(zhuān)門(mén)的框架。Triton 也能通過(guò) TensorRT-LLM backend 跑 LLM但配置復(fù)雜且對(duì)連續(xù)批處理的支持不如 vLLM 這類(lèi)原生方案來(lái)得自然。4. LLM 推理框架選型vLLM 憑什么成為主流4.1 PagedAttention把顯存碎片問(wèn)題摁下去LLM 推理的顯存消耗分兩塊模型權(quán)重和 KV Cache。KV Cache 是注意力機(jī)制里緩存的歷史 key/value隨著生成長(zhǎng)度線性增長(zhǎng)。傳統(tǒng)做法是給每個(gè)請(qǐng)求預(yù)分配一塊連續(xù)顯存按最大可能長(zhǎng)度分配結(jié)果就是大量顯存被浪費(fèi)在預(yù)留但沒(méi)用上的空間里碎片嚴(yán)重能同時(shí)服務(wù)的請(qǐng)求數(shù)上不去。vLLM 的核心創(chuàng)新PagedAttention借鑒了操作系統(tǒng)的虛擬內(nèi)存分頁(yè)思想把 KV Cache 切成固定大小的 block按需分配邏輯上連續(xù)、物理上可以不連續(xù)。這樣一來(lái)顯存利用率能從傳統(tǒng)的 20%~40% 提升到 90% 以上同樣的卡能同時(shí)服務(wù)的請(qǐng)求數(shù)翻好幾倍。這不是玄學(xué)是實(shí)打?qū)嵉耐掏绿嵘?.2 連續(xù)批處理讓 GPU 一刻不停連續(xù)批處理continuous batching也叫 iteration-level scheduling解決的是前面提到的長(zhǎng)短請(qǐng)求互相拖累問(wèn)題。它的做法是以每一步生成一個(gè) token為調(diào)度單位某一步結(jié)束后完成的請(qǐng)求立刻退出 batch新請(qǐng)求立刻補(bǔ)進(jìn)來(lái)。GPU 永遠(yuǎn)在處理一個(gè)滿員的 batch利用率拉滿。實(shí)測(cè)下來(lái)vLLM 相比樸素的 HuggingFacegenerate循環(huán)吞吐提升通常在 10 倍以上具體倍數(shù)取決于請(qǐng)求長(zhǎng)度分布和并發(fā)量。這也是為什么現(xiàn)在一提 LLM 部署vLLM 幾乎是默認(rèn)答案。4.3 vLLM 部署的實(shí)操參數(shù)與坑啟動(dòng)一個(gè) vLLM 的 OpenAI 兼容服務(wù)典型命令python -m vllm.entrypoints.openai.api_server \ --model /models/Qwen2.5-7B-Instruct \ --served-model-name qwen2.5-7b \ --tensor-parallel-size 2 \ --gpu-memory-utilization 0.9 \ --max-model-len 8192 \ --max-num-seqs 256 \ --port 8000幾個(gè)參數(shù)值得展開(kāi)說(shuō)--tensor-parallel-size張量并行度等于用幾張卡跑一個(gè)模型。7B 模型單卡 24G 基本夠70B 就得上 4 卡或 8 卡。注意這個(gè)值必須是 2 的冪次或能被注意力頭數(shù)整除否則起不來(lái)。--gpu-memory-utilizationvLLM 會(huì)按這個(gè)比例預(yù)占顯存用于 KV Cache。設(shè) 0.9 意味著留 10% 給其他開(kāi)銷(xiāo)。設(shè)太高容易 OOM設(shè)太低浪費(fèi)顯存。建議從 0.85 起步觀察穩(wěn)定后再調(diào)。--max-model-len最大上下文長(zhǎng)度。這個(gè)值直接決定 KV Cache 的單請(qǐng)求占用設(shè)太大顯存吃緊設(shè)太小長(zhǎng)文本請(qǐng)求會(huì)被拒。要和模型本身支持的長(zhǎng)度匹配。--max-num-seqs同時(shí)處理的最大請(qǐng)求數(shù)。太小并發(fā)上不去太大顯存扛不住。注意vLLM 啟動(dòng)時(shí)會(huì)做一次顯存 profiling如果gpu-memory-utilization設(shè)得過(guò)高可能在 profiling 階段就報(bào) OOM。遇到這種情況先降這個(gè)值而不是懷疑模型有問(wèn)題。另一個(gè)常見(jiàn)坑是模型格式。vLLM 對(duì) HuggingFace 格式支持最好GGUF 格式雖然也能跑但性能打折ONNX 需要額外轉(zhuǎn)換。如果你手頭是 GGUF 量化模型想要極致性能建議用 llama.cpp 系列想要高并發(fā)服務(wù)還是轉(zhuǎn)成 HF 格式喂給 vLLM。4.4 vLLM、SGLang、TGI、Ollama 的定位差異這幾個(gè)經(jīng)常被放在一起比其實(shí)定位完全不同框架定位適合場(chǎng)景不適合場(chǎng)景vLLM高吞吐生產(chǎn)推理在線服務(wù)、高并發(fā)單機(jī)個(gè)人玩票SGLang高吞吐 復(fù)雜編排需要結(jié)構(gòu)化生成、多輪簡(jiǎn)單問(wèn)答TGIHuggingFace 官方HF 生態(tài)深度用戶非 HF 模型Ollama本地一鍵運(yùn)行個(gè)人開(kāi)發(fā)、桌面端生產(chǎn)高并發(fā)llama.cpp極致輕量邊緣設(shè)備、CPU 推理大規(guī)模并發(fā)Ollama 底層其實(shí)也用了 llama.cpp它的價(jià)值在于把模型下載、量化、運(yùn)行打包成一條命令對(duì)個(gè)人開(kāi)發(fā)者極其友好。但它的調(diào)度能力、并發(fā)能力、顯存管理都遠(yuǎn)不如 vLLM別拿它上生產(chǎn)。我見(jiàn)過(guò)有人用 Ollama 扛線上流量QPS 一過(guò) 5 就開(kāi)始排隊(duì)這就是定位錯(cuò)配。5. K8s 上的推理平臺(tái)把模型當(dāng)成一等公民來(lái)調(diào)度5.1 為什么推理平臺(tái)最終都會(huì)落到 K8s當(dāng)模型數(shù)量、GPU 節(jié)點(diǎn)數(shù)量、團(tuán)隊(duì)人數(shù)都上來(lái)了裸機(jī)部署的運(yùn)維成本會(huì)壓垮你。K8s 提供的價(jià)值在于統(tǒng)一的資源調(diào)度、聲明式的部署管理、自動(dòng)擴(kuò)縮容、服務(wù)發(fā)現(xiàn)、滾動(dòng)更新。這些能力對(duì)推理平臺(tái)來(lái)說(shuō)是剛需。但 K8s 原生不認(rèn)識(shí) GPU。你需要NVIDIA Device Plugin把 GPU 暴露成可調(diào)度資源然后在 Pod 里通過(guò)resources.limits申請(qǐng)resources: limits: nvidia.com/gpu: 2這樣調(diào)度器就知道這個(gè) Pod 要占 2 張卡會(huì)把它調(diào)度到有足夠 GPU 的節(jié)點(diǎn)上。5.2 推理服務(wù)的 K8s 部署形態(tài)Deployment 還是 StatefulSet大多數(shù)推理服務(wù)用Deployment就夠了因?yàn)槟Ｐ蛯?shí)例是無(wú)狀態(tài)的模型權(quán)重從鏡像或 PVC 加載KV Cache 是請(qǐng)求級(jí)的。但有幾個(gè)細(xì)節(jié)要注意模型權(quán)重怎么進(jìn)容器小模型可以打進(jìn)鏡像大模型幾十上百 G必須用 PVC 掛載或者啟動(dòng)時(shí)從對(duì)象存儲(chǔ)拉。打進(jìn)鏡像會(huì)導(dǎo)致鏡像巨大、拉取慢、更新困難。就緒探針readinessProbe要配好模型加載可能要幾分鐘這期間 Pod 不能接流量。探針要指向一個(gè)模型已加載完成的健康接口而不是簡(jiǎn)單的端口探測(cè)。優(yōu)雅退出preStop terminationGracePeriodSecondsLLM 請(qǐng)求可能跑很久直接 kill 會(huì)丟請(qǐng)求。要給足退出時(shí)間讓正在處理的請(qǐng)求跑完。5.3 自動(dòng)擴(kuò)縮容HPA 在推理場(chǎng)景下的尷尬K8s 的 HPA 默認(rèn)按 CPU/內(nèi)存擴(kuò)縮容但推理服務(wù)的瓶頸是GPU 和請(qǐng)求隊(duì)列長(zhǎng)度CPU 可能一直很低。這時(shí)候需要基于自定義指標(biāo)擴(kuò)縮容比如用 Prometheus Adapter 把 vLLM 暴露的num_requests_waiting指標(biāo)接進(jìn)來(lái)隊(duì)列長(zhǎng)了就擴(kuò)容。但 GPU 擴(kuò)容有個(gè)現(xiàn)實(shí)問(wèn)題擴(kuò)容慢。一個(gè)新 Pod 從調(diào)度到模型加載完成可能要好幾分鐘。等它起來(lái)流量高峰可能已經(jīng)過(guò)去了。所以生產(chǎn)上更常見(jiàn)的策略是預(yù)留 buffer平時(shí)保持一定冗余實(shí)例配合較激進(jìn)的擴(kuò)容閾值和較保守的縮容閾值寧可多占一點(diǎn)資源也別讓用戶等。5.4 多模型共享 GPUMIG 與時(shí)間片一張卡怎么給多個(gè)模型用兩條路MIGMulti-Instance GPU把 A100/H100 這類(lèi)卡硬件切分成多個(gè)獨(dú)立實(shí)例每個(gè)實(shí)例有獨(dú)立的顯存和算力隔離性好。缺點(diǎn)是切分粒度固定且不是所有卡都支持。時(shí)間片共享多個(gè)進(jìn)程輪流用 GPU靠 CUDA 的上下文切換。隔離性差一個(gè)進(jìn)程跑滿會(huì)影響其他進(jìn)程但靈活。生產(chǎn)上如果模型對(duì)延遲敏感優(yōu)先 MIG如果是離線批處理混部時(shí)間片也能接受。Triton 的instance_group其實(shí)就是在做進(jìn)程級(jí)的共享配合顯存控制能實(shí)現(xiàn)一定程度的隔離。6. 平臺(tái)化之后的新問(wèn)題網(wǎng)關(guān)、可觀測(cè)性與成本6.1 LLM 網(wǎng)關(guān)別讓業(yè)務(wù)直接懟推理服務(wù)推理平臺(tái)前面通常要加一層網(wǎng)關(guān)職責(zé)包括鑒權(quán)、限流、路由、多模型統(tǒng)一接口、token 計(jì)費(fèi)統(tǒng)計(jì)。關(guān)鍵詞里提到的 llm 網(wǎng)關(guān) 就是這個(gè)東西。它的價(jià)值在于把哪個(gè)模型部署在哪、用什么協(xié)議這些細(xì)節(jié)對(duì)業(yè)務(wù)屏蔽掉業(yè)務(wù)只管調(diào)一個(gè)統(tǒng)一的 OpenAI 兼容接口。路由策略是網(wǎng)關(guān)的核心。常見(jiàn)的有按模型名路由、按成本路由便宜的模型優(yōu)先、按負(fù)載路由哪個(gè)實(shí)例隊(duì)列短去哪個(gè)、按用戶等級(jí)路由VIP 走專(zhuān)用實(shí)例。這些策略組合起來(lái)能在不增加硬件的情況下顯著提升資源利用率。6.2 可觀測(cè)性LLM 服務(wù)的指標(biāo)和傳統(tǒng)服務(wù)不一樣傳統(tǒng)服務(wù)看 QPS、延遲、錯(cuò)誤率就夠了。LLM 服務(wù)還要看首 token 延遲TTFT、每 token 輸出延遲TPOT、輸入輸出 token 數(shù)、KV Cache 使用率、排隊(duì)請(qǐng)求數(shù)。TTFT 決定用戶感覺(jué)快不快TPOT 決定吐字順不順這兩個(gè)指標(biāo)比總延遲更能反映體驗(yàn)。vLLM 原生暴露 Prometheus 指標(biāo)接上 Grafana 就能看。重點(diǎn)盯vllm:num_requests_waiting排隊(duì)數(shù)和vllm:gpu_cache_usage_percKV Cache 使用率前者持續(xù)大于 0 說(shuō)明該擴(kuò)容了后者接近 1 說(shuō)明顯存快滿了。6.3 成本控制推理平臺(tái)最容易被忽視的一環(huán)GPU 是燒錢(qián)的。平臺(tái)化之后如果沒(méi)有成本意識(shí)很容易出現(xiàn)卡都占著但利用率很低的情況。幾個(gè)實(shí)用手段按需加載/卸載模型冷門(mén)模型不常駐請(qǐng)求來(lái)了再加載用完一段時(shí)間后卸載。代價(jià)是首次請(qǐng)求慢。量化INT8/INT4 量化能把顯存占用降一半甚至更多吞吐提升明顯精度損失在可接受范圍內(nèi)。AWQ、GPTQ 是常見(jiàn)的 LLM 量化方案?；觳堪蜒舆t不敏感的離線任務(wù)和在線服務(wù)混在同一批卡上用優(yōu)先級(jí)調(diào)度錯(cuò)峰使用。7. 我在實(shí)際落地中踩過(guò)的幾個(gè)真實(shí)坑第一個(gè)坑是顯存碎片導(dǎo)致的看起來(lái)夠用其實(shí)不夠。有次部署一個(gè) 13B 模型卡是 24G模型權(quán)重占 26G 的一半多理論上夠。但實(shí)際跑起來(lái)頻繁 OOM原因是 KV Cache 分配時(shí)找不到連續(xù)的大塊顯存。后來(lái)把gpu-memory-utilization從 0.95 降到 0.85問(wèn)題消失。顯存不是看總量是看最大連續(xù)可用塊。第二個(gè)坑是K8s 的 GPU 調(diào)度和實(shí)際顯存不匹配。K8s 只認(rèn)幾張卡不認(rèn)卡上還剩多少顯存。如果兩個(gè) Pod 各申請(qǐng) 1 張卡但每個(gè)模型都要占滿整卡顯存第二個(gè) Pod 起來(lái)就會(huì) OOM。解決辦法是用 MIG 切分或者用支持顯存感知調(diào)度的方案再或者干脆一個(gè)模型獨(dú)占一張卡。第三個(gè)坑是模型加載時(shí)間被嚴(yán)重低估。一個(gè) 70B 模型從磁盤(pán)加載到顯存冷啟動(dòng)可能要 5~10 分鐘。如果 K8s 的initialDelaySeconds設(shè)得太短Pod 還沒(méi)加載完就被判定為不健康反復(fù)重啟永遠(yuǎn)起不來(lái)。探針的初始延遲一定要按最壞情況設(shè)寧可多等別讓它誤殺。第四個(gè)坑是網(wǎng)關(guān)超時(shí)和推理超時(shí)沒(méi)對(duì)齊。網(wǎng)關(guān)默認(rèn) 30 秒超時(shí)但 LLM 生成一篇長(zhǎng)文可能要 60 秒結(jié)果網(wǎng)關(guān)先斷了用戶看到報(bào)錯(cuò)其實(shí)后端還在正常跑。網(wǎng)關(guān)超時(shí)必須大于推理服務(wù)的最大預(yù)期耗時(shí)并且要支持流式返回讓用戶邊生成邊看到內(nèi)容。8. 從當(dāng)前架構(gòu)往下一步走的幾個(gè)方向如果你現(xiàn)在的平臺(tái)已經(jīng)能穩(wěn)定跑起來(lái)接下來(lái)可以關(guān)注這幾個(gè)方向。一是推理加速的持續(xù)優(yōu)化比如投機(jī)解碼speculative decoding、前綴緩存prefix caching前者用小模型草稿大模型驗(yàn)證來(lái)提速后者對(duì)多輪對(duì)話場(chǎng)景能省掉重復(fù)的 prompt 計(jì)算。二是多模態(tài)模型的統(tǒng)一服務(wù)圖像、語(yǔ)音、文本模型用同一套調(diào)度框架管理這對(duì)平臺(tái)抽象能力要求更高。三是彈性與混部把在線推理和離線訓(xùn)練/批處理放到同一個(gè)資源池用優(yōu)先級(jí)和搶占機(jī)制提升整體利用率。這些方向沒(méi)有標(biāo)準(zhǔn)答案取決于你的業(yè)務(wù)形態(tài)和成本結(jié)構(gòu)。但有一條是確定的平臺(tái)的價(jià)值不在于支持多少種模型而在于把部署一個(gè)模型這件事的成本降到足夠低。當(dāng)業(yè)務(wù)方能在幾分鐘內(nèi)自助上線一個(gè)新模型且不用關(guān)心底層是幾張卡、跑在哪個(gè)節(jié)點(diǎn)上時(shí)這個(gè)平臺(tái)才算真正立住了。