別再瞎猜 vLLM 設定：在 Runpod 上實測 LLM 效能——Chris Vela，Runpod
別再瞎猜 vLLM 設定：在 Runpod 上實測 LLM 效能——Chris Vela，Runpod
Runpod 的 Chris Vela 示範 BenchPod——一套具備自我修復能力的 Docker／vLLM 效能測試範本。
- 他主張團隊應依據真實延遲資料來挑選 pod 與比較設定，而不是憑感覺猜測。
- 畢竟每月要價 4 萬美元的 B300 可能大材小用，還不如在 H200 上跑 DeepSeek。
Podcast 專家音訊節目
收錄於 888news Podcast 智庫專區，包含精華摘要與上市公司即時行情
Vela 透過 BenchPod 與 vLLM 引數實測，提供可重複基準流程，幫助團隊避免「猜測」配置，提升 LLM 效能與成本效益，並提供實際成本資料與 GPU 指標，讓部署更精準。
Chris Vela 是 GPU 雲端供應商 RunPod 的前線部署工程師（forward-deployed engineer）。他認為，多數在 vLLM 上部署開源模型的團隊，在設定上「都只是在猜」，應該先以真實硬體對不同設定做基準測試，再上線。整場演講大部分時間在帶看他的開發中專案「BenchPod」儀錶板——一個包裝 vLLM 的工具，具備即時 GPU 指標、測試遊樂場與並排基準測試功能——另外還有 Kimi K3 的實機示範；至於「如何對 LLM 做基準測試」這個更大的問題，著墨反而比工具導覽少。
Vela 的分享來自他協助客戶在 RunPod 的 pod 與 serverless 服務上從研發走向生產的第一線經驗，而本簡報整理了他提出的具體說法：Kimi 需要哪個 CUDA 版本、調整 max batch tokens 對 token 間延遲（inter-token latency）造成什麼影響、一臺 B300 節點每月要多少錢，以及為什麼前沿模型往往不是正確選擇。讀者讀完應該能帶走一套可重複的流程——挑一臺 pod、對照 vLLM recipe 比較設定、針對真正重要的指標最佳化，然後把勝出的設定上線——並且清楚知道 Vela 的哪些數字是實測、哪些只是經驗法則。
vLLM recipe 只是起點，不是生產設定
Vela 的核心抱怨是：團隊拿到最新模型，套上 vLLM recipe 提供的基礎設定就跑，等到模型表現不佳時才手忙腳亂。他列出在客戶身上反覆看到的失敗模式：vLLM 版本選錯（他點名 0.27 太舊，跑不動 Kimi K3）、沒用 nightly build，以及 context window 大小與實際工作負載不匹配。他的說法是，recipe「經過驗證，但還不到可上生產的程度」。
他說，在這一切之前，他先問的第一個問題是模型要用來做什麼——是 coding agent，還是基本的摘要——因為「讓 Kimi K3 吃下一百萬長上下文」並非總是必要。第二個問題是併發量：團隊往往為了最小、最便宜的 GPU 而最佳化，但併發使用者一多，就得對 KV cache 使用率做出取捨。他也警告不要一有新前沿模型就立刻部署：在他看來，Kimi K3 在發布隔天就上線，會產生大量幻覺，「在那種狀態下根本還沒準備好」。
「我看過太多了——大家就只是在猜。」
BenchPod 把設定變更轉成可比較的資料
Vela 表示，演講當時 BenchPod 還沒以模板形式發布（預計「月底」推出）。它是一個包裝 vLLM 與 OpenAI 相容 API 的 Docker 映像，上層再疊一個 FastAPI 應用。它的目的是消除反覆調整設定的摩擦：不必重啟映像、苦等冷啟動——他提到下載 Kimi K3 權重並載入 GPU 大約要 30 分鐘——只要改設定、快速重啟即可。
他描述的儀錶板元件如下：
| 元件 | 功能 |
|---|---|
| GPU 指標面板 | GPU 使用率、CUDA 版本（關鍵：Kimi 跑在 CUDA 13.0，不是 12.8） |
| 錯誤掃描 | 以實際資料呈現失敗，而不是靠猜 |
| 即時指標 | 流量執行時的即時檢視，並備份到儲存空間 |
| 測試遊樂場 | 在把模型接進 agent 之前先測試提示詞 |
| 服務／實驗 | 編輯 vLLM 設定 YAML，快速重啟後套用 |
| 基準測試比較 | 執行併發掃描，並排比較多次測試結果 |
| 看門狗 | 自我修復；Vela 說演講前的週日有一個 Kimi 例項掛掉，系統在四個節點間自動復原，內部使用者完全沒受影響 |
所有功能都以 FastAPI 呼叫形式提供，因此 agent 可以直接取用指標，不必經過 UI。Vela 明確表示，即使 agent 接手愈來愈多工作，他仍希望保留一份人類可讀的「鳥瞰檢視」。
調高 max batch tokens 降低的是 token 間延遲，不是首 token 時間
Vela 唯一詳細展示的實驗，是調整 batch tokens 上限，並與 vLLM recipe 的基礎設定對照。基準測試把併發從 1 個使用者一路掃到 8、64、92。他報告的結果是：首 token 時間（time to first token）幾乎沒變，但在較高的 batch-token 設定下，token 間延遲「降低不少」——也就是長時間執行的請求完成速度明顯快於 recipe 預設值。他把這個效益定位為讓長時間的 agent 任務更快得到答案。
他沒有在臺上給出絕對延遲數字，而且這些測試是預先跑好的，不是現場執行，以免花 20 分鐘看基準測試跑。他得出的結論是方法論層面的：挑選你真正需要的指標——ITL、TTFT 或 TPOT——針對它最佳化，而不是假設某一組設定放諸四海皆準。
從單一 pod 到生產環境，是一套五步迴圈
Vela 最後給出一套明確流程，也是整場演講中最可重複使用的成果：
flowchart TD
A["在 RunPod 上挑選 pod 與 GPU 機型"] --> B["載入模型"]
B --> C["對照 vLLM recipe 比較設定"]
C --> D["讓 agent 測試真實工作負載"]
D --> E["針對真正重要的指標最佳化——ITL、TTFT 或 TPOT"]
E --> F["上線勝出的設定"]
F --> G["提供服務，再擴充套件到多節點或 serverless"]
同一套資料也能沿用到 serverless；他說團隊常見的做法是直接部署基礎設定，然後苦等 worker 慢慢啟動。照他的說法，先做基準測試，才能讓轉向多節點叢集或 serverless 部署成為安全的決定，而不是又一次猜測。
一臺 B300 節點每月約 4 萬美元，所以前沿模型常常不划算
演講中最具體的成本數字：RunPod 上一臺 B300 節點每月約 4 萬美元，會有一些波動。Vela 用這個數字論證不該預設選最大的模型。他在四張 H200 上跑 DeepSeek，說它「表現非常好」；Kimi 則留給長時間、細節繁重的任務。他的重點是：對團隊而言，較小的模型往往才是正確答案，單靠前沿能力並不足以支撐這筆支出。
他也提到一項硬體限制：在 B300 上無法達到 Kimi K3 完整的 100 萬 token 上下文——大約只能拿到一半——但他說這對長時間的 coding agent 任務「非常夠用」，而且該配置下的 KV cache 使用率與首 token 時間都非常好。他提到其他內部例項跑著 GLM、DeepSeek 與 Qwen 3.8，並說演講當時約有 50 位內部使用者在那個 Kimi 例項上。
版本鎖定與冷啟動是隱形的營運成本
有兩個營運細節反覆出現。第一是版本紀律：由於 vLLM 迭代很快，跑新模型往往得追 nightly build，並把版本選擇當成 CI/CD 的一環；不瞭解這點的團隊會撞上開發中程式碼的錯誤，然後認定模型壞了。第二是冷啟動時間，他把它當成第一級指標——儀錶板會追蹤，並舉 Kimi K3 九分鐘冷啟動為好成績。RunPod 的部署流程支援「有貨就部署」選項，因此 pod 可以排隊等某種暫時缺貨的 GPU；他指出，由於供給波動，這種情況確實會發生。
這場演講留下的未解問題
Vela 略微提到 RunPod 的下一步——用智慧路由器託管多個模型而不依賴第三方，以及把 AI 治理與工具／上下文管理當作自架部署的下一層——但兩者都沒有細節。演講當時 BenchPod 模板仍未發布，因此外部團隊還無法重現任何一個基準測試數字。真正未解的張力，是他自己提出的那一點：工具讓設定比較變得便宜，但該選哪個模型、哪張 GPU，仍取決於對工作負載、併發與預算的判斷——而每月 4 萬美元的 B300 數字說明，錢實際上大多是在這個判斷上賺到或賠掉的。