Run:ai 開源完整平台：GPU 共享、配額與維運，誰來負責？（2026）

2026 年 10 月 13 日，NVIDIA 的 Ekin Karabulut 與 Sam Heywood 在官方技術部落格發布了〈NVIDIA Run:ai Is Now Open Source as Part of NVIDIA DSX AI Factory Platform〉。這次 Run:ai 開源，把 GPU 共享基礎設施的選擇從「買一套平台」擴展到「採用整套，或整合需要的元件」。對管理 AI 系統的人，真正的問題是：哪些工作因此能更好地分配，哪些責任仍要自己接住？

先看這次公開的範圍，再拆開排程、分割與配額的差別，最後回到一個採用決策：你的瓶頸需要整套平台，還是一個能補進現有系統的零件。

Run:ai 開源：這次多了完整管理層

Kubernetes 可以理解成管理一群伺服器的工作分派系統；GPU 是其中昂貴又容易被零碎占住的資源。Kubernetes 官方 GPU 文件說明，節點仍需對應的驅動與 device plugin，才能讓工作使用 GPU。Run:ai 在這層基礎上，加入跨團隊的資源分配與工作管理。

NVIDIA Run:ai is an open-source AI workload and GPU orchestration platform for managing shared AI infrastructure on Kubernetes.

中文：NVIDIA Run:ai 是在 Kubernetes 上管理共享 AI 基礎設施的開源工作與 GPU 編排平台。

NVIDIA Run:ai 官方 repository README

可檢查的證據在 dsx-ai-factory/run-ai 程式庫：除了叢集服務，還列出控制平面、安裝工具、CLI 與共用套件。控制平面負責管理資源、提交工作及觀察狀態；叢集端服務把政策接到實際執行位置。這比公開一顆排程器更接近可整合的平台底座。

授權也要分層讀。根目錄標示 Apache 2.0，README 另外列出巢狀與第三方授權；其中的商標聲明明確保留品牌資產權利。程式碼的開源授權、下載成品的條款，以及使用品牌素材，是三件要各自確認的事。

四個元件，分別回答四種「分配」問題

想像一間有多個研究團隊共用的實驗室：有人需要整晚占用一組儀器，有人只做十分鐘小測試，還有人需要幾台設備同時到位。排得下、分得細、輪得到，以及看得懂整份實驗，各自需要不同機制。

元件	核心問題	責任
KAI Scheduler	工作放哪裡、何時一起啟動？	處理 GPU 感知排程、群組工作、拓樸與公平分配。
GPU Fractioning Operator	同一張卡的記憶體邊界如何落實？	把分配結果接到節點執行環境，施加記憶體限制並輸出指標。
KAI Resource Management	哪個部門、專案拿到多少？	把組織階層、節點池與佇列接到資源管理。
Workload Map	不同框架的工作結構怎麼被理解？	用共同描述呈現 Pod、角色與狀態，降低每種工作各寫轉接器的負擔。

排程：多人工作，要把「一起開始」算進去

KAI Scheduler 的功能文件列出 gang scheduling、階層式佇列、公平分配與拓樸感知。Gang scheduling 的用意，是把相互依賴的一組工作當成整體安排；需要多個 worker 協作的任務，先拿到一部分資源，未必已經能交付成果。拓樸則關乎這些資源彼此的連接位置。

這些機制改變資源的安排方式，不能直接推出單次模型生成變快。若工作卡在讀資料、網路或應用程式同步，排程改善能觸及的只是其中一段。想分清模型、執行引擎與硬體，可先讀 LLM 推論引擎入門。

分割：顯存邊界，與完整隔離分開驗

GPU Fractioning Operator 的 README把分工寫得很具體：排程器選擇分到哪張卡、多少份額；節點端元件在容器啟動前注入限制，由驅動執行記憶體上限，並輸出每個 Pod 的使用指標。這讓「申請了多少」與「實際能配置多少」有了落實邊界。

截至 2026 年 10 月 15 日，該 README 列出 Kubernetes 1.28 以上、具 NRI 支援的容器執行環境，以及 r615 以上驅動（CUDA 13.4）等前提；GPU Operator、Container Toolkit 與 device plugin 也各有版本要求。原始碼可取得，與你的既有叢集已具備依賴，是兩個檢查點。升級應先在隔離的測試環境驗收。

另一份官方文件提供了有用的反例：GPU Operator 的 time-slicing 說明明示，這種時間切片的 replica 之間沒有記憶體或故障隔離。這不能拿來否定新的 Fractioning Operator；它提醒的是，不能因為兩種方案都叫「GPU 共享」，就把某一種的保證移給另一種。對外部租戶，還應另驗故障影響、權限與延遲干擾。

配額與工作描述：政策要能落到真實工作

KAI Resource Management對應部門、專案、節點池與佇列。值得注意的是，讀取當天 README 的 Project status 明示尚未有發布版本；管理者目前須從原始碼打包 chart，並提供相容的 controller images。這是該獨立元件的狀態，不能外推成整套 Run:ai 都無法取得成品。

Workload Map則處理另一種碎片：PyTorchJob、RayCluster 等工作把 Pod、角色、複本數與狀態放在不同位置。共同描述像一張翻譯表，讓上層工具更容易讀懂工作結構。這種轉接的價值，要在你實際使用的工作類型與欄位上檢查；整合了一種框架，不代表每個自訂工作都已驗收。

外部落地證據：能部署，和效能有改善，各留一張收據

Nebius 的 10 月 13 日發布文確認，已把開源 Run:ai 放進 AI Cloud Applications，運行於其 Managed Kubernetes。這是合作夥伴對自身供應狀態的第一手說明，能支持「已有部署入口」；它與 NVIDIA 存在合作關係，不能充當中立效能認證。

Nebius 同文特別交代，早先雙方的 fractional allocation 測試用的是商業版 Run:ai v2.24。這個版本界線很重要：舊版的測試條件與結果，不會因為新版本開源，就自動成為新發行版的測量。本文不填入 AlphaLab 未執行的 GPU 吞吐或節省比例。

NVIDIA 公告列出八家生態夥伴的整合方向。數量表示參與的廣度，各家的上線狀態、維運責任與服務條款仍應分開核對；它不是八份可互相比較的基準測試。對採用者，應追的是自己的部署路徑是否真的能跑完整工作。

Model Streamer 與 Grove：別把不同瓶頸的成績混在一起

原文另外談到 Model Streamer 與 Grove，將它們定位為互補專案。vLLM 的 Model Streamer 文件能直接核對權重載入整合；Grove 官方程式庫則提供多元件推論工作協作的 Kubernetes API。前者面向啟動時搬運權重，後者面向相關元件的編排。

把這幾層放回一個請求就容易理解：先等資源，接著載入模型，再由服務處理輸入並生成回答。縮短其中一段，會改善總等待多少，取決於那一段原本占多少。原文引用的載入成績不應拿來回答「Run:ai 排程讓模型快幾倍」。已有 vLLM 權重預載教學的讀者，也應把暖快取與冷啟動分開記錄。

AlphaLab 的判讀：程式碼開放，讓責任分工更值得追問

一、我同意：可拆開採用，降低了整套遷移的壓力

如果你已經有工作提交與監控系統，只缺群組排程，單獨評估 KAI 比立刻替換整個入口更容易界定影響。若痛點是跨團隊的資源政策、身分與工作生命週期，整套平台才可能更接近問題。模組化的價值，在於讓改動範圍跟瓶頸對齊；這仍需要你承擔介面與版本的整合工作。

二、我存疑：利用率上升，是否轉成更多合格工作

假設把兩份小工作放在同一張 GPU，監控畫面更忙了；但若尖峰請求延遲超標、另一份工作被中斷，總體交付可能反而變差。應同時看完成數、排隊時間、尾端延遲、失敗及重新執行成本。本機 LLM 成績單談的尺度雖然不同，同樣可以提醒我們把速度與完成品質分開。

公平也不是一個天然數字。保證某團隊能用到資源、允許別人借用空檔，以及急件回來時回收資源，會牽涉不同人的等待與中斷成本。管理者先寫清楚服務承諾，再決定配額與搶占政策，才有辦法判斷排程到底改善了誰的工作。

三、開源降低取得門檻，維運仍需要預算

公告對 Community Product 的邊界寫得清楚：不需付費 Run:ai 訂閱，但不含 NVIDIA 企業支援；從 NGC 下載仍須接受相應軟體條款。這項排除是官方明文，不等於整個專案沒有社群協助。官方 SUPPORT 文件另列出支援分支與提問、錯誤回報管道。

因此採用帳單至少有三欄：平台本身的費用、運行它的基礎設施，以及團隊升級、排錯與值班時間。合作夥伴代管可能把後兩者的一部分包進服務價格，自行維運則保留更多控制。哪一條便宜，應按你的工作與人力條件計算。

四、共同底座可能擴大生態，也可能加深特定堆疊的依賴

原文最後寫道：

We welcome your contributions, issues, and feedback.

中文：我們歡迎你的貢獻、問題回報與意見。

Ekin Karabulut、Sam Heywood，NVIDIA，2026 年 10 月 13 日

這是對共同開發的邀請。我的判讀是，公開管理層能讓更多服務商在相同底座上補產品與維運能力；同時，新的 GPU 分割路徑明確依賴 NVIDIA 驅動及 CUDA 能力。開放程式碼與硬體堆疊依賴可以同時存在。日後值得追的，是外部維護者能否持續貢獻、版本升級是否可預測，以及你想更換某一層時要付出多少轉接成本。

Run:ai 開源怎麼採用：先寫下瓶頸，再選零件

如果你只是使用聊天模型，這次發布較可能透過服務供應商改善體驗，不必為它另建一套 Kubernetes。若你正在管理共享 GPU，先挑一個已觀察到的問題：排隊過久、分散式工作無法同時就緒、小工作占整卡，或團隊配額難管理。每次只讓一個改動回答一個問題。

測試環境先固定工作、版本與通過條件，保留目前的完成數、等待與失敗紀錄；再選整套平台或單一元件對照，並安排資源回收、超額使用及元件失效的情境。依賴尚未對齊，就先完成相容性盤點。Run:ai 開源的價值，最終要落在同樣資源下，更多工作在承諾時間內可靠完成，而不是儀表板多了一塊綠色。