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