上一篇的結論是：GPU 是零件，算力是服務，中間差的是「硬體上面那一層」。這一篇要把那一層講清楚。品得網絡刻意不從技術名詞出發，而是先問一個問題：當一個 AI Agent 的請求從業務系統發出，一路走到某一張 GPU 上的某一個模型，再把結果送回來，這條鏈路上必須有哪些能力，資訊部門才敢說「這是我們管得住的系統」？
答案是五個能力。有了這五個能力，貴司才有資格談下一個問題：用什麼工具實作。
能力一：多租戶隔離，不同部門共用同一批 GPU 而互不干擾
上一篇談過使用率的問題，解法是共用。但共用的前提是隔離：財務部的夜間對帳 Agent 不能因為研發部在跑模型微調而變慢，醫院的臨床決策支援不能因為行政文書 Agent 的批次而排隊。隔離要做到三個層次：運算資源的切分（一張卡可以切給多個工作或多張卡合給一個工作）、網路與儲存的隔離（部門的資料不會被另一個部門的工作讀到）、以及故障隔離（一個工作當掉不會拖垮同一台機器上的其他工作）。
能力二：配額與成本歸因，每一次推論都要知道是誰的
這是系列第一篇談的埋點，落到自建環境的版本。外部 API 至少還會給一張帳單；自建環境如果沒有設計歸因，連帳單都沒有，只有一台一直很熱的機器。能力二要求：每個部門有配額，每一次請求都被記錄到部門與流程，每個月可以產出一張「內部帳單」。這張帳單是資訊部門向預算單位說明投資報酬的唯一依據，也是決定第二批 GPU 要不要買的唯一依據。
能力三：推論路由，讓請求找到對的模型與對的 GPU
AI Agent 的一件任務裡有二十步，其中大部分是格式轉換與簡單判斷，只有少數幾步需要最強的模型。能力三要求鏈路上有一個懂得推論特性的路由層：依任務類型把請求送到不同規模的模型，依 GPU 當下的負載與快取狀態選擇送到哪一個副本，並且把同樣前綴的請求送到已經有快取的地方。這一層做得好壞，直接決定同樣的硬體能承載多少請求。
能力四：可觀測性，壞掉的時候知道壞在哪
AI Agent 的故障模式跟傳統系統不同。傳統系統壞了會報錯；Agent 壞了可能是「跑了三個小時然後給出一個看起來合理但錯誤的結果」。能力四要求從 GPU 使用率、模型延遲、每一步的 token 消耗、到 Agent 每一次工具呼叫的紀錄，都能被追蹤並且串成同一條鏈路。沒有這一層，貴司的 SRE 團隊無法接手，AI 就永遠是一個只有原始開發者看得懂的黑盒子。
能力五：可攜性，今天的決定不能鎖死明天
第三篇談過 GPU 世代更替比攤提期快。第二篇談過供應商鎖定。能力五把這兩件事合在一起：模型、推論框架、硬體、甚至機房位置，都應該可以在不改動業務系統的前提下替換。今天在自己機房跑的模型，明天可以搬到境內代管機房；今天用的推論框架，明年可以換成更快的；今天的 GPU 世代，三年後換新的時候上層不用重寫。
三條實作路線，各自適合誰
五個能力講完，才輪到工具。目前企業自建 AI 推論環境有三條主要路線，品得網絡把它們攤開來比，因為沒有一條是對所有企業都最好的。
路線一：單機容器化
一到兩台伺服器，用容器直接跑開源推論引擎，前面放一個閘道。適合：第一階段只有一兩條流程必須落地、團隊小、要在幾週內看到結果的企業。做得到：能力三與能力五的基本版。做不到：多租戶隔離與跨團隊配額，因為只有一台機器，沒有東西可以排程。很多企業的第一步應該就是這條，不需要為了未來三年的規模先建一個平台。
路線二：高效能運算排程器
以學術與研究機構常用的批次排程系統為核心，把 GPU 當成運算節點分配給工作。適合：以模型訓練與微調為主、工作是批次型而非長時間在線服務的環境。醫學中心的研究部門、大學附設醫院、有 AI 研發團隊的製造集團，往往已經有這類環境。做得到：能力一與能力二在批次工作上很成熟。做不到：能力三與能力四針對「長時間在線、要低延遲回應」的推論服務並不順手，AI Agent 的請求形狀跟批次訓練差很多。
路線三：容器編排平台
以 Kubernetes 為底座，把 GPU 當成叢集資源統一排程與切分，推論服務以容器方式部署、自動擴縮，前面接懂推論的路由層。適合：多個團隊共用、推論為主、需要成本歸因、而且資訊部門已經有容器平台經驗的企業。銀行與大型醫院多半已經在跑企業版的 Kubernetes 發行版，政府機關的雲端平台也常見。
這條路線在 2026 年有一個關鍵的變化：五個能力所需的元件，都已經有開源標準，而且都收斂在這個底座上。GPU 的動態切分與配置已經是 Kubernetes 的正式功能；專為推論設計的路由擴充已經正式發布，可以依模型負載與快取狀態做請求排程；把推論的讀取與生成兩階段分配到不同 GPU 池的分離式推論框架，在 2026 年 3 月捐給了雲端原生運算基金會（CNCF），成為社群共同維護的專案。連各家硬體與軟體廠商賣的 AI 平台，底層絕大多數也是它。
做不到的：它不會讓複雜度消失。兩台機器上 Kubernetes 是自找麻煩。訓練密集的工作，路線二仍然更順手。它最大的價值是讓既有的平台團隊用他們已經會的方式接管 AI，而不是再養一個只懂 AI 的獨立團隊。
怎麼選
先用五個能力盤點貴司現在缺什麼，再看三條路線哪一條補得上。不要反過來先選工具再找理由。
品得網絡的實務建議是：多數企業會從路線一開始，在第二批 GPU 之前決定要不要走到路線三。判斷點很清楚：當有第二個部門要用同一批 GPU、當預算單位開始要內部帳單、當 SRE 團隊被要求接手值班，這三件事發生任何一件，就是從單機走向平台的時候。有研究型工作負載的醫院與製造集團，路線二與路線三會並存，各管各的工作型態。
五個能力與三條路線，加上前三篇的成本、風險與硬體，就是一張完整的決策地圖。系列最後一篇會把它整理成銀行、醫院、製造與公部門各自可以直接拿去開會的版本。
常見問題
一定要用 Kubernetes 嗎？
不一定。一到兩台機器、一兩條流程，單機容器化就夠。訓練密集的研究環境，高效能運算排程器更順手。Kubernetes 的優勢在多團隊共用、推論為主、需要成本歸因的場景，而且前提是資訊部門已經有容器平台的營運能力。
廠商賣的 AI 平台跟自己用開源組件有什麼差別？
多數商用 AI 平台的底層就是同一套開源組件，差別在包裝、支援與授權費。評估時建議用五個能力逐項核對，並確認平台是否能在不重寫業務系統的前提下替換模型、推論框架與硬體，也就是能力五。
我們的 SRE 團隊沒有 AI 經驗，接得了嗎？
這正是路線三的核心價值。當推論服務以容器部署、用貴司既有的監控與排程機制管理，SRE 團隊接手的是他們熟悉的物件，AI 特有的部分（模型延遲、token 消耗、Agent 工具呼叫紀錄）只是多接幾個指標。品得網絡在導入時的做法是與貴司的平台團隊一起建，而不是建好交付。
如果貴司正在評估自建 AI 推論環境，或者已經有 GPU 卻還沒有上面那一層，歡迎聯絡品得網絡。第一步是一份五個能力的現況盤點，不需要動任何既有系統。
