所以這個平台到底能不能用
三十篇寫完了。這篇回答那個所有人真正想問的問題。
先給答案：能用。 我今天把原本壞掉的三個功能都修好了， 現在模型服務、pipeline、workbench、監控、台帳全部跑得起來。
但「能用」這兩個字，藏了一天的工和七個坑。
⭐ 一個評估者真正需要的數字
不是「這個平台有沒有 X 功能」——那個答案永遠是「有」。
是這個：從「官方說有」到「我手上能用」，中間要跨幾關。
| 功能 | 官方 | 實際跨幾關 | 是哪幾關 |
|---|---|---|---|
| 模型上線（KServe） | 有 | 3 | 依賴在叢集外／3.x 不幫你開 Route／服務答不出自己是誰 |
| Pipeline（DSPA） | 有 | 1 | caching 預設開著，你會看到全綠但什麼都沒跑 |
| Workbench | 有 | 3 | admission webhook 擋下／CPU 排不進去／鏡像 digest 不符 |
| Model Registry | 有 | 3 | namespace 被寫死／CR 與 API 版本號不一致／camelCase 欄位被靜默丟成零值 |
| 監控（Prometheus+Grafana） | 有 | 1 | datasource 沒給 uid，九個面板全查不到資料 |
| 離線鏡像 | 有 | 2 | relatedImages 只宣告 2 顆而實際 76 顆／IDMS 用 digest 比對 |
| GPU | 有 | ?* | pod 要到卡 ≠ 模型算在卡上 |
| Kueue | 有 | 1+ | Managed 被拒，要自己裝 RHBOK |
| llm-d | 有 | 3+ | Connectivity Link ＋ LeaderWorkerSet ＋ 多 GPU 多節點 |
* GPU 那條我的環境驗不了（CRC 看不到卡），但那個「要到卡 ≠ 算在卡上」的陷阱是在主機上實測過的。
八個功能，十七道以上的關卡。
而其中沒有任何一關寫在官方文件上。
這些關卡長什麼樣
我把它們分類之後，發現只有三種：
① 平台自己的 bug（4 關） Workbench 的 webhook（有 JIRA 編號，PR 還 open）、 Model Registry 的 camelCase 靜默丟值、KServe controller 的 RBAC 缺漏、 內建 imagestream 指向不存在的 tag。
這類你修不了根，只能繞。 而繞的方法要自己找。
② 設計如此，但沒人告訴你（7 關）
3.x 不幫你開 Route、模型和 image 分開放、Connection 是貼 label 的 Secret、
IDMS 用 digest 比對、Kueue 要走 Unmanaged、caching 預設開著、
Model Registry 要你自己準備資料庫。
這類最花時間，因為你會以為自己做錯了，而其實是不知道規則。
③ 資源與環境（6 關） CPU 不夠排不進去、鏡像不完整、GPU 沒 passthrough、多節點做不到。
誰來跨這些關卡——這才是驗收該問的
上面那張表對你有用的地方不是數字，是下一個問題：
這十七關，誰來跨？
三種可能，而且代價差非常多：
| 誰跨 | 發生在什麼時候 | 代價 |
|---|---|---|
| 廠商（在交付前） | PoC 階段 | 已包含在合約裡 |
| 你（在驗收時發現） | 驗收階段 | 要求補件，時程延後 |
| 你（在上線後撞到） | 正式環境 | 最貴。而且通常在半夜 |
如果驗收只問「功能有沒有」，那十七關就會全部落到第三種。
因為每一關都符合「功能是有的」這個描述。
所以驗收該怎麼問
把整個系列壓成一句：
不要問「有沒有 X」，要問「請當著我的面，把 X 從零做一次」。
而這個「做一次」有三個必要條件，缺一個就無效：
- 當著你的面——不接受截圖，因為所有壞掉的東西都能截出一張好看的圖
- 從零——不是操作一個已經配好的環境
- 完整走完——包括最後那個「真的能用」的動作（打端點、開 workbench、看面板）
我在這三十篇裡整理出來的六步驗收腳本是：
建 project → 設 connection → 建 workbench 並開啟
→ 上傳並跑一次 pipeline → 看 run 的 input parameters
→ 部署模型並從叢集外打一發推論
六步，每一步都會踩到上面那張表裡的某幾關。
平心而論：它好的地方
寫了三十篇的坑，也該說公道話。
① 3.x 比 2.x 好，而且是結構性的好。
把 Knative／Service Mesh 那層拿掉之後，排錯回到 oc get deploy/pod/svc——
你原本會的 Kubernetes 技能直接可用，不用先學一整套中介層。
代價是路由和伸縮要自己接，但那是可預期的成本，不是黑盒子。
② 所有東西都是標準 k8s 物件。 DSC、ISvc、Notebook、webhook、CSV——全部查得到、改得動、看得懂。 今天我能在四個指令內查出 Workbench 的根因，就是因為它沒有把資訊藏起來。
③ 錯誤訊息雖然常常誤導，但底層資訊都在。
「scaled to zero」不是真正的原因，但 oc describe pod 有 FailedScheduling；
「cache sync timeout」很誤導，但 oc auth can-i --as= 一問就知道。
它不會騙你，只是不會主動告訴你。
我的建議
如果你在評估要不要導入：
值得導入，但把上面那張「跨幾關」的表帶進合約談判。 明確約定哪幾類關卡由誰負責——尤其是第②類（設計如此但沒人告訴你）， 那類最容易變成「這不在我們的範圍內」。
如果你已經在導入：
先跑那六步。每一步的失敗都比你想的更早出現，而且更容易修—— 在 PoC 階段修一個 webhook 是半天，在正式環境是一個變更視窗。
如果你是被交辦要驗收的人：
你真正的產出不是一份「全部通過」的清單， 是一份「這幾關是誰的責任」的紀錄。
因為半年後系統出事時，沒有人會問「當初驗收有沒有通過」， 他們會問「這件事當初有沒有人知道」。
最後
這三十篇裡我自己量錯了四次，其中一次差點把錯誤寫進要交出去的驗收條件。
所以最後這句同時是給你的，也是給我自己的：
每一個「已經確認過」的結論，都有一個沒有被重新驗證的日期。
而那個日期，通常比你以為的更久以前。
如果你導入過類似的平台，你的「跨幾關」大概是多少？哪一關最貴？
🧪 這篇的實驗環境與 lab 檔案（最後更新 2026-08-30）
叢集
- CRC 2.63.0 · OpenShift 4.22.7 · Kubernetes v1.35.6
- 單節點：13 vCPU / 40 GiB RAM / 120 GB disk
- 宿主：Framework Laptop 16（Ryzen AI 7 350 · 8C/16T · 64 GB RAM · 1 TB NVMe · RTX 5070 顯卡模組）
- ⚠️ 叢集內看不到 GPU（CRC 是 VM，RTX 5070 未 passthrough）
Operator
opendatahub-operator.v3.5.0← 即 RHOAI 3.x 的上游開源版cert-manager-operator.v1.20.0（3.x 的必要相依；2.x 不需要）openshift-pipelines-operator-rh.v1.23.2、openshift-gitops-operator.v1.21.3
DataScienceCluster 開啟的元件
kserve、aipipelines、dashboard、workbenches、modelregistry、kueue（Unmanaged）- 其餘（
ray／trustyai／feast／aigateway…）為Removed
叢集外的依賴（跑在宿主的 podman 上，crc start 不會帶起來）
- Harbor v2.15.2（私有 registry）· MinIO（S3）
模型端
- Python 3.12.13 · PyTorch 2.11.0+cu128 · FastAPI + uvicorn · prometheus-client
lab 檔案
- YAML／Containerfile／腳本：github.com/ryanGTR/openshift-ai-30days
（含 Day 對照表；主機名是佔位符，跑
set-lab-host.sh換成你自己的） - 服務的那個模型：llm-from-scratch（從零手刻的小 GPT）
⚠️ ODH ≠ RHOAI：元件同源，但 namespace 與部分名稱不同
（我這裡是 opendatahub，商用版是 redhat-ods-* 那一套）。
指令的邏輯可以照用，字串要自己對一次。
留言與指正
我特別想知道：如果你導入過類似的平台，你的「跨幾關」大概是多少？哪一關最貴？