NVIDIA 開源 srt-slurm把 GPU 推理服務(wù)的編排做到 SLURM 里先說一個判斷推理部署真正的瓶頸往往不是顯卡性能不夠而是 GPU 集群里“誰能用、怎么用、出了問題誰來管”這件事太亂了。單機(jī)跑大模型還好一旦上了多節(jié)點、多團(tuán)隊、多模型的集群環(huán)境手動分配 GPU、手動啟動推理服務(wù)、手動盯著進(jìn)程是否掛掉會迅速耗盡你的時間和耐心。NVIDIA 開源的 srt-slurm表面上是個調(diào)度工具本質(zhì)上是在把“靠人盯集群”變成“靠編排管服務(wù)”。我寫這篇文章是想把一個容易被忽略的視角說清楚很多團(tuán)隊已經(jīng)有 SLURM 集群也裝了 NVIDIA 驅(qū)動推理服務(wù)也能跑起來但距離“像 K8s 那樣交付一個推理服務(wù)”還差一層編排能力。srt-slurm 正是補這層的東西。讀完全文你會理解它解決什么真實問題、適合什么場景也能拿到一套基于 SLURM 和 NVIDIA 推理服務(wù)的可落地配置思路。1. 推理部署和“編排”之間差的那一步先回到一個典型場景你有一個 8 卡的 GPU 服務(wù)器上面裝了 SLURM幾個算法工程師都在往里提交訓(xùn)練任務(wù)。突然有一天業(yè)務(wù)方說要部署一個線上推理服務(wù)要求 7x24 小時可用還要支持多個模型切換。這時候你會發(fā)現(xiàn)SLURM 默認(rèn)的工作模式是“作業(yè)”而不是“服務(wù)”。訓(xùn)練任務(wù)跑完就退出資源立刻釋放推理服務(wù)要長期運行必須一直占著 GPU。如果用它跑一個srun --gresgpu:1 python run_infer.py一旦進(jìn)程被 OOM 殺死、節(jié)點重啟、或者 SLURM 回收了作業(yè)服務(wù)就沒了沒人知道你線上已經(jīng)中斷了一個小時。更麻煩的是服務(wù)發(fā)現(xiàn)和流量調(diào)度。一個分布式推理服務(wù)通常有多個副本前端需要一個入口把這些副本的地址聚合起來。SLURM 只負(fù)責(zé)把作業(yè)調(diào)度到節(jié)點上它不知道你的服務(wù)監(jiān)聽哪個端口、是不是還活著、要不要擴(kuò)容。這些原本屬于 Kubernetes 的能力在傳統(tǒng) HPC 集群里是缺失的。所以srt-slurm 的出現(xiàn)本質(zhì)上是在 SLURM 的“資源調(diào)度層”和推理服務(wù)的“業(yè)務(wù)交付層”之間加了一個翻譯器和調(diào)度大腦。它把“向 SLURM 提交作業(yè)”這件事抽象成“聲明一個推理服務(wù)”然后由這個編排層去處理在哪個分區(qū)分配 GPU啟動哪個推理引擎vLLM、TensorRT-LLM、NVIDIA NIM 等服務(wù)啟動后把地址注冊到哪里健康檢查失敗后自動重啟作業(yè)結(jié)束后清理殘留進(jìn)程。這樣的設(shè)計非常適合已經(jīng)圍繞 SLURM 建立了資源管理體系的團(tuán)隊。你不需要推倒重來切換到 Kubernetes而是在現(xiàn)有集群上獲得接近云原生的服務(wù)化體驗。2. 認(rèn)識 srt-slurm它是什么解決什么問題從現(xiàn)有公開信息看srt-slurm 是一個圍繞“SLURM 編排 推理服務(wù)部署”定位的開源項目。具體縮寫的全稱目前公開材料不多理解它的時候不必糾結(jié)字面意思直接看它做的事更有價值讓 GPU 推理服務(wù)在 SLURM 集群上以聲明式、可編排的方式運行。它的核心價值可以拆成三層。第一層是資源抽象。你把“我想跑一個 Qwen2.5-7B 的推理服務(wù)需要 1 張 A100”這樣一句話寫成配置而不是自己去記哪臺機(jī)器有空閑、該提交什么 srun 命令。編排層會解析配置生成對應(yīng)的 SLURM 作業(yè)提交到正確的分區(qū)。第二層是服務(wù)生命周期管理。推理服務(wù)和普通批處理任務(wù)的差異在于它要長期存活。因此 srt-slurm 需要支持健康檢查、日志回灌、進(jìn)程守護(hù)、失敗重啟。服務(wù)啟動后它會探測推理服務(wù)的 HTTP 端口確認(rèn)模型加載完成、API 可以響應(yīng)才認(rèn)為“部署成功”。第三層是入口與服務(wù)發(fā)現(xiàn)。當(dāng)一個推理服務(wù)跑起來之后外部怎么找到它這里面通常需要一個注冊機(jī)制把節(jié)點 IP 端口 服務(wù)名寫入某個存儲中例如共享文件、Redis 或 Nacos。前端網(wǎng)關(guān)再從注冊中心拉取可用地址做轉(zhuǎn)發(fā)。拿它和 Kubernetes 對比會更好理解。Kubernetes 天生把“部署、服務(wù)、伸縮、自愈”放在一起SLURM 擅長的是排隊調(diào)度和 GPU 資源分配但對服務(wù)化能力支持較弱。srt-slurm 更像是給 SLURM 裝上了一個“在線服務(wù)模式”讓 HPC 管理員不需要改變底層作業(yè)調(diào)度習(xí)慣也能交付穩(wěn)定的推理服務(wù)。當(dāng)然并不是所有場景都適合它。如果你的團(tuán)隊對 Kubernetes 已經(jīng)很熟且業(yè)務(wù)完全云原生化繼續(xù)用 KServe 這類方案可能更完整如果你的集群規(guī)模很小、只有一塊 GPU用手動啟動腳本也夠用。srt-slurm 最有價值的地方是那些“已經(jīng)有 SLURM、有多卡、有多個用戶、但缺少服務(wù)化工具”的中間地帶。3. 核心基礎(chǔ)SLURM 作業(yè)調(diào)度與 GPU 服務(wù)化的差異想用好 srt-slurm先要理解 SLURM 的基本模型以及推理服務(wù)為什么不能完全照搬訓(xùn)練作業(yè)的管理方式。SLURM 里有幾個最常見的概念分區(qū)partition把節(jié)點按用途分組比如gpu分區(qū)、cpu分區(qū)節(jié)點node是實際執(zhí)行作業(yè)的計算資源作業(yè)job是你提交的調(diào)度單元按狀態(tài)分為排隊PD、運行R、結(jié)束CD、失敗F等。作業(yè)可以交互式運行也可以批處理運行。訓(xùn)練任務(wù)通常是一次性的我跑 1000 個 epoch跑完就結(jié)束SLURM 自然回收資源。推理服務(wù)卻要求一直活著只要用戶不主動下線它就要持續(xù)監(jiān)聽端口、接收請求。于是這里出現(xiàn)了幾個關(guān)鍵差異。第一個差異是資源占用模式。訓(xùn)練任務(wù)用完即釋放推理服務(wù)必須長期持有 GPU。在 SLURM 里長期作業(yè)一直占用節(jié)點會讓排隊時間變長所以需要給推理服務(wù)設(shè)立獨立的 QoS 或分區(qū)避免它和訓(xùn)練任務(wù)互相擠占。第二個差異是啟動判定標(biāo)準(zhǔn)。訓(xùn)練任務(wù)啟動后就開始計算談不上“服務(wù) ready”。推理服務(wù)則不同模型權(quán)重加載就要幾十秒到幾分鐘顯存分配完成后 HTTP 端口才會監(jiān)聽。編排層必須有能力判斷“這個服務(wù)是否真正可用”而不是只看進(jìn)程有沒有起來。第三個差異是故障恢復(fù)。訓(xùn)練任務(wù)掛了可以重新排隊用戶能等推理服務(wù)掛了線上的請求直接失敗。所以 srt-slurm 這類編排層必須做自動重啟、健康檢查和異常通知甚至要考慮把服務(wù)調(diào)度到其他健康節(jié)點上。下面用一個表格把這兩類作業(yè)的差異列清楚對比維度傳統(tǒng) SLURM 作業(yè)推理服務(wù)化作業(yè)生命周期短暫跑完即退長期駐留持續(xù)對外提供服務(wù)資源占用任務(wù)結(jié)束自動釋放長期持有 GPU需要獨立配額管理成功標(biāo)準(zhǔn)進(jìn)程正常退出、產(chǎn)生產(chǎn)物HTTP 端口可訪問、模型可響應(yīng)重啟策略失敗后手動重新提交失敗自動拉起或重新調(diào)度訪問方式用戶通過文件和日志獲取結(jié)果通過 API 或網(wǎng)關(guān)訪問服務(wù)監(jiān)控需求任務(wù)日志、資源利用率端口健康、請求延遲、并發(fā)量、GPU 顯存從這個表可以看出srt-slurm 要做的就是把第二列的能力補齊。它本身并不是取代 SLURM而是讓 SLURM 從“批處理調(diào)度器”升級成“混合負(fù)載調(diào)度器”。4. 環(huán)境準(zhǔn)備與前置條件srt-slurm 的具體部署方式以官方倉庫 README 為準(zhǔn)但整體環(huán)境依賴通常包含以下幾個部分。這里我給出的是通用檢查思路你只要按這套清單核對基本不會走偏。4.1 基礎(chǔ)組件清單需要準(zhǔn)備的核心組件如下SLURM 集群包括slurmctld控制節(jié)點和slurmd計算節(jié)點版本建議使用當(dāng)前主流的大版本避免過老版本缺少關(guān)鍵特性。NVIDIA GPU 節(jié)點包含 NVIDIA 驅(qū)動、CUDA 運行環(huán)境以及 NVIDIA Container Toolkit。推理引擎vLLM、TensorRT-LLM、NVIDIA NIM 或其他兼容 OpenAI API 的推理服務(wù)。模型文件放在所有計算節(jié)點都能訪問的位置一般是共享存儲。服務(wù)發(fā)現(xiàn)組件可能是共享文件、Redis、etcd 等取決于 srt-slurm 的實現(xiàn)。4.2 檢查 SLURM 集群狀態(tài)在管理節(jié)點上執(zhí)行sinfo squeue預(yù)期的輸出應(yīng)該能看到節(jié)點處于idle或mix狀態(tài)并且有可用的 GPU partition。如果節(jié)點狀態(tài)是down或drain需要先恢復(fù)節(jié)點。scontrol show nodes scontrol show partition這些命令可以幫助你確認(rèn)節(jié)點 GPU 配置和分區(qū)名稱。后面的編排配置里要寫對 partition否則作業(yè)會一直排隊。4.3 檢查 GPU 與容器運行時在被調(diào)度的 GPU 節(jié)點上執(zhí)行nvidia-smi nvidia-smi -L確認(rèn)驅(qū)動已正確加載。如果要在容器里跑推理還需要安裝 NVIDIA Container Toolkit。Ubuntu 系統(tǒng)下典型的安裝步驟是curl -s -L https://nvidia.github.io/libnvidia-container/gpgkey | sudo apt-key add - curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.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 nvidia-ctk runtime configure --runtimedocker sudo systemctl restart docker如果你的環(huán)境無法訪問外網(wǎng)需要把上面的軟件源替換成內(nèi)部鏡像源。安裝完成后用這條命令驗證容器能否識別 GPUdocker run --rm --gpus all nvidia/cuda:12.4.1-base-ubuntu22.04 nvidia-smi如果能看到類似nvidia-smi的輸出說明容器里的 GPU 透傳沒有問題。這一步非常關(guān)鍵因為 srt-slurm 在計算節(jié)點上很可能是通過容器拉起推理服務(wù)的。5. 從“手動啟動推理服務(wù)”到“編排提交”我們先看一個最原始的推理服務(wù)啟動方式再逐步過渡到編排模型這樣你才能理解 srt-slurm 到底幫你省了什么。5.1 手動啟動推理服務(wù)在 GPU 節(jié)點上手動執(zhí)行python3 -m vllm.entrypoints.openai.api_server \ --model /models/Qwen2.5-7B-Instruct \ --tensor-parallel-size 1 \ --host 0.0.0.0 \ --port 8000這樣服務(wù)確實能跑但你有幾個問題沒法解決如果機(jī)器重啟服務(wù)不會自動拉起如果服務(wù)崩潰沒人幫你重啟端口被占用時只能手動改配置多副本時沒有入口聚合前端只能寫死 IP。5.2 用 SLURM 作業(yè)提交推理服務(wù)把上面的命令寫進(jìn) SLURM 作業(yè)腳本可以在一定程度上解決“誰在跑”的問題#!/bin/bash #SBATCH --job-namemanual-infer #SBATCH --partitiongpu #SBATCH --gresgpu:1 #SBATCH --cpus-per-task8 #SBATCH --time01:00:00 #SBATCH --outputslurm-%j.out python3 -m vllm.entrypoints.openai.api_server \ --model /models/Qwen2.5-7B-Instruct \ --tensor-parallel-size 1 \ --host 0.0.0.0 \ --port 8000然后用sbatch提交sbatch start_infer.sh squeue這是“作業(yè)方式”的推理服務(wù)。它能保證服務(wù)在不出錯的情況下長期運行但離完善的“編排”仍然很遠(yuǎn)。你仍然要手動查作業(yè)日志手動處理端口沖突還要在服務(wù)崩潰后重新提交作業(yè)。5.3 用 srt-slurm 聲明推理服務(wù)到了 srt-slurm 這一層你不再直接寫 SLURM 腳本而是寫一份服務(wù)聲明由工具轉(zhuǎn)換成作業(yè)并持續(xù)維護(hù)。下面是一個演示性質(zhì)的思路# 示例命令具體參數(shù)以官方 README 為準(zhǔn) srt-slurm submit \ --name qwen-infer \ --model /models/Qwen2.5-7B-Instruct \ --engine vllm \ --partition gpu \ --gpu 1 \ --port 18000 \ --health-path /health提交后編排層會做幾件事自動計算合適的 SLURM 參數(shù)、向集群提交作業(yè)、輪詢服務(wù)端口、確認(rèn)/health返回 200然后把服務(wù)的訪問地址注冊到服務(wù)發(fā)現(xiàn)中心。整個過程你提供的只是“服務(wù)意圖”而不是“機(jī)器命令”。6. 完整示例與代碼實現(xiàn)下面給出一套完整的、可以在真實 SLURM 集群上落地的推理服務(wù)編排示例。這個示例不完全等同于 srt-slurm 的內(nèi)部實現(xiàn)但它包含了所有關(guān)鍵環(huán)節(jié)你理解之后再看官方文檔會非常快。6.1 模型目錄準(zhǔn)備假設(shè)模型已經(jīng)放在共享存儲/models/Qwen2.5-7B-Instruct。如果 srt-slurm 會派發(fā)作業(yè)到不同節(jié)點那么所有計算節(jié)點必須都能訪問這個路徑。路徑掛載不一致是推理服務(wù)啟動失敗最常見的原因之一。6.2 編寫服務(wù)聲明文件假設(shè)編排工具支持 YAML 聲明服務(wù)定義可能長這樣# 文件路徑services/qwen-infer.yaml name: qwen-infer engine: vllm model: /models/Qwen2.5-7B-Instruct partition: gpu gpu: 1 cpus: 8 timeout: 7200 port: 18000 replicas: 2 healthcheck: path: /health interval: 10 timeout: 5 retries: 3字段含義如下name服務(wù)名稱在集群內(nèi)唯一。engine推理框架例如vllm、tensorrt-llm或nim。model模型路徑。partitionSLURM 分區(qū)。gpu每個副本申請的 GPU 卡數(shù)。replicas服務(wù)副本數(shù)用于高可用。port服務(wù)對外暴露的端口。healthcheck健康檢查規(guī)則用于判斷服務(wù)是否 ready。再次提醒具體字段名以官方實現(xiàn)為準(zhǔn)這里的意義在于讓你理解“聲明式”長什么樣。6.3 提交服務(wù)假設(shè) CLI 工具名為srt-slurmsrt-slurm apply -f services/qwen-infer.yaml srt-slurm list srt-slurm status qwen-infer預(yù)期行為是list能看到服務(wù)處于running或deploying狀態(tài)status能顯示每個副本所在的 SLURM 作業(yè) ID 和節(jié)點地址。6.4 在 SLURM 節(jié)點上實際運行的作業(yè)腳本如果不依賴編排工具直接用 SLURM 腳本模擬單副本推理服務(wù)腳本如下#!/bin/bash #SBATCH --job-nameqwen-infer-1 #SBATCH --partitiongpu #SBATCH --gresgpu:1 #SBATCH --cpus-per-task8 #SBATCH --time02:00:00 #SBATCH --output/var/log/slurm/qwen-infer-%j.out #SBATCH --error/var/log/slurm/qwen-infer-%j.err echo JOB_START_TIME$(date) nvidia-smi python3 -m vllm.entrypoints.openai.api_server \ --model /models/Qwen2.5-7B-Instruct \ --tensor-parallel-size 1 \ --host 0.0.0.0 \ --port 18000 \ --served-model-name qwen2.5-7b-instruct echo JOB_END_TIME$(date)提交sbatch scripts/start_infer.sh6.5 服務(wù)調(diào)用驗證等到作業(yè)運行后先看服務(wù)是否監(jiān)聽端口squeue scontrol show job JOB_ID ss -lntp | grep 18000在能訪問該節(jié)點的機(jī)器上執(zhí)行curl http://NODE_IP:18000/v1/models如果返回模型列表說明推理服務(wù)已經(jīng)就緒。再發(fā)一個對話請求curl http://NODE_IP:18000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen2.5-7b-instruct, messages: [{role: user, content: 用一句話解釋為什么推理服務(wù)需要編排}], max_tokens: 128 }正常響應(yīng)中應(yīng)該包含choices字段并且?guī)С錾傻奈谋尽?.6 服務(wù)發(fā)現(xiàn)與網(wǎng)關(guān)接入在生產(chǎn)環(huán)境前端不可能寫死節(jié)點 IP。更合理的做法是把每個副本的地址寫入 Redisredis-cli HSET srt:services:qwen-infer node-0 10.0.1.20:18000 redis-cli HSET srt:services:qwen-infer node-1 10.0.1.21:18000然后 API 網(wǎng)關(guān)或者 Nginx 從 Redis 拉取地址列表做負(fù)載均衡。這一步可以很輕量不一定需要引入完整的注冊中心。7. 運行結(jié)果與效果驗證跑通這套流程后你應(yīng)該按順序驗證幾件事。7.1 作業(yè)狀態(tài)sinfo看到節(jié)點被分配squeue看到作業(yè)從PD變成Rsqueue -u $USER狀態(tài)為R表示作業(yè)正在運行PD表示還在排隊。如果一直停在PD說明資源不足或你寫的分區(qū)名稱不對。7.2 服務(wù)端口在作業(yè)所在節(jié)點上確認(rèn)端口監(jiān)聽ss -lntp | grep 18000 curl http://127.0.0.1:18000/health如果配置了/health探針應(yīng)該返回 200。7.3 日志驗證日志是排查問題的第一手信息tail -n 50 /var/log/slurm/qwen-infer-JOB_ID.err常見的日志內(nèi)容包括模型加載過程、tokenizer 配置、顯存分配以及最終的Application startup complete。看到這個信息說明服務(wù)已經(jīng)就緒。7.4 失敗后的第一步排查如果服務(wù)處于異常狀態(tài)第一步先把“異?！倍x清楚作業(yè)有沒有啟動看squeue容器或進(jìn)程有沒有崩潰看作業(yè)日志GPU 是否可見在節(jié)點上跑nvidia-smi端口是否被占用看ss -lntp模型路徑是否可讀在節(jié)點上執(zhí)行l(wèi)s /models/Qwen2.5-7B-Instruct。大多數(shù)問題都出在這五個環(huán)節(jié)里。如果一個一個排查完還找不到原因再去翻 srt-slurm 控制端的日志。8. 常見問題與排查思路問題現(xiàn)象可能原因排查方式解決方案作業(yè)一直停在 PD 狀態(tài)分區(qū)無空閑 GPU或資源配額不足sinfo查看節(jié)點狀態(tài)squeue查看排隊情況等待資源釋放調(diào)整分區(qū)降低申請卡數(shù)服務(wù)啟動后 HTTP 接口無法訪問服務(wù)監(jiān)聽地址不是0.0.0.0端口沒有暴露ss -lntp查看監(jiān)聽地址curl 127.0.0.1 測試設(shè)置--host 0.0.0.0檢查防火墻和安全組容器內(nèi)執(zhí)行 nvidia-smi 報錯NVIDIA Container Toolkit 未安裝或未配置nvidia-container-cli info安裝 Toolkit確認(rèn) docker runtime 已配置模型加載非常慢冷啟動加載權(quán)重共享存儲吞吐不足查看作業(yè)日志中的加載耗時預(yù)熱模型使用本地緩存增大存儲帶寬服務(wù)啟動后立刻報 OOM模型參數(shù)量超出單卡顯存查看dmesg和作業(yè)日志切換量化版本設(shè)置--tensor-parallel-size健康檢查失敗服務(wù)仍在加載模型探活超時時間過短curl 手動訪問 /health查看服務(wù)日志延長健康檢查超時增加重試次數(shù)端口沖突多個服務(wù)申請了同一端口ss -lntp看端口占用情況讓編排層分配動態(tài)端口建立端口分配表節(jié)點重啟后服務(wù)沒有恢復(fù)編排層未配置自動重啟scontrol show job查看作業(yè)狀態(tài)配置自動重啟策略結(jié)合 systemd 守護(hù)每個問題都不要只盯著表象。比如端口沖突根因可能是編排層沒有做端口分配也可能是你手動啟動了一個殘留進(jìn)程。先把“現(xiàn)在誰在監(jiān)聽這個端口”查清楚再決定殺掉哪個進(jìn)程。9. 最佳實踐與工程建議推理服務(wù)編排上了生產(chǎn)環(huán)境不能只看“能跑通”。下面這些實踐是我在同類系統(tǒng)里反復(fù)驗證過值得投入的環(huán)節(jié)。9.1 服務(wù)定義盡量聲明式把服務(wù)名稱、模型路徑、GPU 數(shù)量、分區(qū)、端口寫成配置而不是散落在 shell 歷史記錄里。這樣團(tuán)隊其他成員能直接看到集群里有哪些服務(wù)、用的什么模型、占了多少資源。9.2 固定端口和動態(tài)端口要有規(guī)則小規(guī)模集群可以約定端口段比如18000-19000歸推理服務(wù)使用規(guī)模再大一點最好由編排層統(tǒng)一分配。否則時間一長端口沖突會變成每日問題。9.3 所有推理服務(wù)必須暴露健康檢查接口vLLM 默認(rèn)提供/health端點TensorRT-LLM 和 NVIDIA NIM 也有對應(yīng)的探活方式。這是編排層判斷服務(wù)是否需要重啟的唯一可靠依據(jù)。沒有健康檢查自動拉起就無從談起。9.4 日志不能只留在節(jié)點本地SLURM 作業(yè)日志默認(rèn)寫在計算節(jié)點節(jié)點一旦故障日志就丟了。建議將所有推理服務(wù)的日志發(fā)送到集中采集系統(tǒng)例如 Elasticsearch、Loki 或云日志服務(wù)。這樣在排障時不需要先定位節(jié)點再翻文件。9.5 網(wǎng)絡(luò)暴露必須做認(rèn)證如果你通過 srt-slurm 暴露推理 API不要把端口直接開放到公網(wǎng)。建議前置一層認(rèn)證網(wǎng)關(guān)例如使用 API Key、OIDC 認(rèn)證或者至少做 IP 白名單。無認(rèn)證的推理服務(wù)在公網(wǎng)上會很快被掃描和惡意調(diào)用這個風(fēng)險不是危言聳聽。9.6 給推理服務(wù)設(shè)置獨立的 QoS 或分區(qū)訓(xùn)練作業(yè)通常是高吞吐、短時間、可排隊推理服務(wù)是長期占用、低延遲、不能排隊。兩類負(fù)載混在一個分區(qū)里會導(dǎo)致推理服務(wù)被訓(xùn)練作業(yè)擠到后面延遲不穩(wěn)定。最好單獨設(shè)置一個infer分區(qū)配合 SLURM QoS 限制最長運行時間或最大并發(fā)數(shù)。9.7 預(yù)留模型預(yù)熱策略大模型冷啟動時間較長。如果服務(wù)頻繁重建調(diào)用方會一直看到超時。一種做法是把服務(wù)常駐并定期探活另一種是啟動腳本里先向模型發(fā)送一個最小請求完成預(yù)熱再注冊到服務(wù)發(fā)現(xiàn)中心。后者在自動擴(kuò)容場景下非常有用。9.8 用 Prometheus 監(jiān)控 GPU 和延遲NVIDIA 提供了dcgm-exporter可以采集 GPU 利用率、顯存、溫度等指標(biāo)。推理服務(wù)層面可以暴露請求延遲、QPS、token 吞吐。把這些接入 Prometheus Alertmanager一旦 GPU 利用率異?；?P95 延遲升高就能第一時間收到告警。10. 總結(jié)與后續(xù)學(xué)習(xí)方向srt-slurm 這類項目的價值不是提供一個又一個炫酷命令而是把 GPU 推理服務(wù)的運行方式從“腳本 人工盯”變成“聲明 編排自動維護(hù)”。它適合那些已經(jīng)有 SLURM 集群、想在不動底層調(diào)度系統(tǒng)的情況下獲得服務(wù)化能力的團(tuán)隊。如果你正在搭大模型推理平臺可以重點關(guān)注它如何處理作業(yè)聲明、健康檢查、服務(wù)發(fā)現(xiàn)和自動重啟四個環(huán)節(jié)。下一步的實踐建議很直接先準(zhǔn)備一個兩節(jié)點的 SLURM 測試環(huán)境裝好 NVIDIA Container Toolkit用 vLLM 跑通一個最小推理服務(wù)再對照 srt-slurm 官方倉庫的 README把這里描述的通用概念映射到具體命令上。不用一上來就追求多副本和高可用能把“提交一個服務(wù)、自動拉起、API 可通、失敗能重啟”這條鏈路跑通就已經(jīng)離生產(chǎn)環(huán)境很近了。把這篇文章收藏下來動手實驗時遇到“作業(yè)排隊、服務(wù)端口不通、容器不識 GPU、健康檢查失敗”四類問題回來對照第 8 節(jié)的排查表基本能省下不少找資料的功夫。