先給答案：能用。 我今天把原本壞掉的三個功能都修好了， 現在模型服務、pipeline、workbench、監控、台帳全部跑得起來。

但「能用」這兩個字，藏了一天的工和七個坑。

⭐ 一個評估者真正需要的數字

不是「這個平台有沒有 X 功能」——那個答案永遠是「有」。

是這個：從「官方說有」到「我手上能用」，中間要跨幾關。

* 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、多節點做不到。

誰來跨這些關卡——這才是驗收該問的

上面那張表對你有用的地方不是數字，是下一個問題：

這十七關，誰來跨？

三種可能，而且代價差非常多：

如果驗收只問「功能有沒有」，那十七關就會全部落到第三種。

因為每一關都符合「功能是有的」這個描述。

所以驗收該怎麼問

把整個系列壓成一句：

不要問「有沒有 X」，要問「請當著我的面，把 X 從零做一次」。

而這個「做一次」有三個必要條件，缺一個就無效：

1. 當著你的面——不接受截圖，因為所有壞掉的東西都能截出一張好看的圖
2. 從零——不是操作一個已經配好的環境
3. 完整走完——包括最後那個「真的能用」的動作（打端點、開 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 是半天，在正式環境是一個變更視窗。

如果你是被交辦要驗收的人：

你真正的產出不是一份「全部通過」的清單， 是一份「這幾關是誰的責任」的紀錄。

因為半年後系統出事時，沒有人會問「當初驗收有沒有通過」， 他們會問「這件事當初有沒有人知道」。

最後

這三十篇裡我自己量錯了四次，其中一次差點把錯誤寫進要交出去的驗收條件。

所以最後這句同時是給你的，也是給我自己的：

每一個「已經確認過」的結論，都有一個沒有被重新驗證的日期。

而那個日期，通常比你以為的更久以前。

如果你導入過類似的平台，你的「跨幾關」大概是多少？哪一關最貴？

四種方式，然後是一個更重要的問題。

四種方式

① 手動上傳到 S3（最快，也最沒紀錄）

mc cp corpus.txt local/models/llm/clean_corpus.txt

三十秒搞定，適合 lab 和第一次試。 我自己就是這樣放的——而這篇後半就是在講它的代價。

② 從 workbench 拉

在 Jupyter 裡直接抓：

import boto3
s3 = boto3.client("s3", endpoint_url=os.environ["AWS_S3_ENDPOINT"])
s3.download_file("models", "llm/corpus.txt", "/opt/app-root/src/corpus.txt")

憑證來自你掛上去的 Connection， 不用寫死在程式裡。

適合探索階段。缺點是那個過程留在某個人的 notebook 裡—— 別人重現不了，而且 notebook 常常不進版控。

③ 用 pipeline 的一棒去抓（推薦）

把「取得資料」變成 pipeline 的第一棒，跟訓練、評估同一條鏈：

@dsl.container_component
def ingest_data(source_url: str, run_id: str):
    return dsl.ContainerSpec(image=IMAGE, command=["bash","-c", INGEST], args=[source_url, run_id])

好處是它會留下紀錄：哪一次 run、用了什麼參數、產出放哪。 這是唯一能讓「資料怎麼來的」變成可查詢事實的做法。

④ 直接掛外部儲存（PVC / NFS / CSI）

資料太大、或本來就在企業儲存上時用這個。

⚠️ 但它有一個治理問題:掛進來的東西不受平台版本控制。 NFS 上那個檔案被別人改了，你的訓練結果就變了，而且沒有任何紀錄。

⭐ 但真正的問題不是「怎麼放」

我去查了自己平台上那份訓練語料，能查到的全部資訊只有這些：

mc stat local/models/llm/clean_corpus.txt

Name      : clean_corpus.txt
Date      : 2026-08-24 03:35:32 UTC
Size      : 99 MiB
ETag      : 9e4a738f546d71860ae83a1ac165112f-7
Metadata  :
  Content-Type: text/plain

檔名、日期、大小、ETag。就這樣。

查不到的東西：

而這份資料訓練出來的模型，現在正在對外服務。

為什麼這件事比它看起來嚴重

模型會把資料的一切學進去——包括你不知道自己收了什麼。

出事的時候，你會被問這些：

• 「這個模型講出了不該講的東西，訓練資料裡有什麼？」
• 「這批資料的授權允許商業使用嗎？」
• 「有個人資料在裡面嗎？」
• 「重跑一次能不能得到同一顆模型？」

這四題都不是模型的問題，是資料的問題。 而如果你的資料只有「檔名、日期、大小」，你一題都答不出來。

⚠️ 更麻煩的是：這些問題通常在你最不想回答的時候被問到。

補法：給資料一張身分證

跟資料一起放一個 dataset_card.json：

{
  "name": "zhwiki-clean",
  "source_url": "https://dumps.wikimedia.org/zhwiki/20260601/...",
  "downloaded_at": "2026-06-21T08:05:00+08:00",
  "raw_sha256": "sha256:...",
  "raw_size_bytes": 110234567,
  "license": "CC BY-SA 4.0",
  "processing": {
    "script": "pipeline/01_prepare_data.py",
    "code_commit": "2d4f691",
    "steps": ["collect", "clean", "quality-filter", "exact-dedup", "near-dedup"],
    "dropped": {"quality": 12, "exact": 0, "near": 161}
  },
  "output_sha256": "sha256:...",
  "docs_out": 11126,
  "chars": 39850979
}

六個欄位是最低限度：

⭐ 然後把 output_sha256 寫進模型台帳的 lineage。 這樣「線上這顆模型用了哪份資料」就是一個可查詢的事實，不是一段回憶。

怎麼開始（不用一次做完）

第一步不是建系統，是補現有那幾份的身分證。

你平台上大概有三到五份重要的資料。手寫那幾張卡，半天就能寫完。 半天換到「出事時答得出來」，這個交易很划算。

第二步才是把它自動化——在 pipeline 加一棒 ingest， 產出資料的同時產出那張卡。

⚠️ 順序不要反過來。先做自動化，你會花兩週寫一個沒人用的東西； 先手寫幾張，你會知道哪些欄位真的需要。

誠實標一下

我也還沒做。

我的 lab 上那份 99 MB 語料，到今天為止仍然只有檔名、日期、大小。 我知道它是中文維基（因為是我自己下載的）， 但那份知識在我腦子裡，不在平台上。

而這正是問題所在：「我知道」和「查得到」是兩件事， 而只有後者能在三個月後、或在我不在的時候，回答問題。

給驗收的一句

「請給我看訓練資料的來源、下載日期、和授權。」

如果對方指著一個 S3 路徑說「就在那裡」，那你們有的是一個檔案， 不是一份可以追溯的訓練資料。

而模型的所有問題，最後都會追回到這裡。

你們平台上的訓練資料，查得到「哪來的、什麼時候抓的、誰處理過」嗎？

但有一段我一直沒寫，因為我以為它是顯而易見的：

模型訓練完、gate 放行之後，它怎麼變成線上服務？

今天我去查了。答案是：不會。中間那一步是空的。

先看程式碼說什麼

gate 那一棒通過之後，最後做的事是：

print("  ✓ 放行")
reg.append(entry)
put(REG_LOCAL, MODELS, REG_KEY)                       # 寫台帳
put(ART / "ckpt.pt",        MODELS, "llm-candidate/ckpt.pt")
put(ART / "tokenizer.json", MODELS, "llm-candidate/tokenizer.json")
print("  已註冊進台帳並送進候選區 s3://models/llm-candidate/")

放行 = 把模型複製到 llm-candidate/。

而 InferenceService 讀的是哪裡？

oc get isvc llm-scratch -o jsonpath='{.spec.predictor.containers[0].env[?(@.name=="STORAGE_URI")].value}'
# s3://models/llm/

llm/，不是 llm-candidate/。

⭐ 時間戳說得更清楚

mc ls --recursive local/models

[2026-08-28 08:13]  5.5 MiB   llm-candidate/ckpt.pt      ← gate 放行的那顆
[2026-08-28 08:13]   36 KiB   llm-candidate/tokenizer.json
[2026-08-24 02:41]   32 MiB   llm/ckpt.pt                ← 線上服務實際讀的
[2026-08-24 03:35]   99 MiB   llm/clean_corpus.txt
[2026-08-24 02:41]   97 KiB   llm/tokenizer.json

候選區那顆是 8/28 的，5.5 MB。線上那顆是 8/24 的，32 MB。

不只時間差四天——大小差六倍，那根本是兩顆完全不同的模型。

gate 放行的東西，從來沒有上線過。

更麻煩的：服務講的是另一份台帳

去問服務它自己是誰：

curl -s localhost:18000/model | jq

{
  "serving_digest": "sha256:4d694be9342d…",
  "in_registry": true,
  "status": "production",
  "metrics": {"test_loss": 3.462, "test_bpc": 4.9946},
  "data_quality_gate": true
}

status: production。看起來一切正常。

但那份台帳是用 ConfigMap 掛進容器的本機檔，裡面兩筆， 建立時間都是 2026-06-21：

00b47fc84755   archived     2026-06-21
4d694be9342d   production   2026-06-21     ← 線上這顆

而 gate 寫的台帳應該在 S3 上。我去找：

mc ls --recursive local/models | grep registry.json
# （沒有）

兩份台帳，互不相干。

• 服務讀的那份：ConfigMap，兩筆，六月的
• gate 寫的那份：S3，而我在 bucket 裡找不到它

所以 /model 回的 production 是真的——它只是在講六月那顆模型， 跟這條 pipeline 跑出來的東西完全沒有關係。

整條鏈畫出來長這樣

  pipeline train  →  s3://models/runs/<run_id>/ckpt.pt
                            ↓
  gate 放行       →  s3://models/llm-candidate/ckpt.pt      8/28, 5.5 MB
                            ↓
                    ┌───────────────┐
                    │  ？？？        │  ← 這裡什麼都沒有
                    └───────────────┘
                            ↓
  ISvc 讀取       →  s3://models/llm/ckpt.pt                8/24, 32 MB

中間那個框，就是「上線」這件事。而它沒有被實作。

為什麼會這樣——而且為什麼很常見

我不是忘了寫。我是做到「候選區」就停下來了，因為那一步之後的東西不是技術問題。

從候選到上線，需要決定的是：

技術上，「上線」可以是一行 mc cp llm-candidate/ llm/。

而正因為它技術上這麼簡單，它幾乎總是最後才被做， 或者被做成「某個人手動跑一下」——然後那個人變成單點。

⭐ 這就是「治理只做到一半」的具體長相： 前面每一棒都自動化、有紀錄、有 gate， 而最後那個真正改變線上狀態的動作，是人工的、沒有紀錄的。

兩種補法

A. 自動 promote（適合換版頻繁）

gate 通過就直接複製到 llm/，然後重啟 ISvc。

mc cp local/models/llm-candidate/ckpt.pt local/models/llm/ckpt.pt
oc rollout restart deploy/llm-scratch-predictor

⚠️ 這樣做的前提是你的 gate 真的擋得住東西。 如果 gate 的門檻是 run 參數（誰都能填）， 自動 promote 等於把「上線」的權限交給任何能建 run 的人。

B. 人工放行，但留下紀錄（適合金融業）

候選區保持不動，上線是一個明確的、有簽核的動作—— 而且那個動作應該是 git commit，不是 mc cp。

把 ISvc 的 STORAGE_URI 或模型 digest 寫進 GitOps repo， 上線 = 改那個檔案 + PR + merge。

這樣「誰放行的」這個問題，答案就在 git log 裡。

這跟容器 image 的 demo-tmp → demo 放行機制是同一個形狀： 待審區和放行區分開，而搬動的那個動作要留痕。

最誠實的一段

我兩種都還沒做。

我的 lab 現在的狀態是：pipeline 會跑、gate 會擋、台帳會寫、 候選區會更新——而線上那顆是六月手動放上去的，四天前的候選從來沒上去過。

而我一直沒發現，因為：

• oc get isvc → READY=True ✅
• 推論打得通 ✅
• /model 回 production ✅
• pipeline 的 run 是綠的 ✅

每一個檢查都通過，而這條鏈中間是斷的。

要發現它，唯一的辦法是去比對兩個路徑的時間戳—— 而那不在任何一份健康檢查清單上。

給驗收的一句

「請告訴我，線上這顆模型是哪一次 run 產出的。」

如果對方要去翻聊天記錄、或者說「應該是上次那個」， 那條鏈就是斷的——不管前面的 pipeline 做得多漂亮。

而這一題比「有沒有 gate」有用得多，因為它問的是結果不是流程。

你們的模型從「訓練完」到「線上服務」，中間那一步是誰做的？自動的還是人工的？

然後我在自己的 lab 上把它跑了一遍。

三條有問題。而且如果我沒跑，它們會直接被帶進驗收現場。

Bug 1：一個會吐出 80 行假警報的指令

原本這樣寫：

oc get csv -A | grep -i opendatahub

在我的 lab 上，它吐 82 行。

看起來像裝了 82 套 operator。第一反應是「環境壞了」。

實際上只裝了一套。

原因：operator 用 AllNamespaces 模式安裝時， 它的 CSV（ClusterServiceVersion）會被複製到每一個 namespace。 那 82 行是同一個 CSV 在 82 個 namespace 的副本。

修正：

oc get csv -A -o jsonpath='{range .items[*]}{.metadata.name}{"\n"}{end}' \
  | sort -u | grep -i opendatahub

opendatahub-operator.v3.5.0        ← 就一套

⭐ 這條 bug 的危害不是「數字不對」，是它會製造恐慌。 在驗收現場，你拿一個吐 82 行的指令去問廠商， 對方會花半小時解釋一件根本沒發生的事——而你們兩邊都會覺得對方有問題。

教訓：任何會回傳「一堆」的指令，先確認它回的是不同的東西， 還是同一個東西的多份副本。

Bug 2：問錯了問題

原本 L5-2 寫的是：「比對鏡像的 digest 清單 vs 實際拉取的」。

看起來很嚴謹。但實際跑過才發現，那個問題問得太客氣了。

真正該問的是：

「現在正在跑的 pod，有幾顆 image 根本不在你的私有 registry？」

oc get pods -A --field-selector=status.phase=Running \
  -o jsonpath='{range .items[*].status.containerStatuses[*]}{.imageID}{"\n"}{end}' \
  | sed 's|@.*||' | sort -u | grep -vE '^<你的私有 registry>'

離線環境的正確答案是：空的。

任何一行輸出，都代表那顆 image 是從外網拉的—— 也就是這個環境現在還連得到外網，或者它根本沒有真正離線過。

差別在哪：原本的問法是「你的清單完整嗎」（比對兩份文件）。 新的問法是「這個環境現在有沒有依賴外網」（直接量事實）。

前者可以用一份漂亮的文件回答，後者不行。

我在 lab 上跑這條，結果是 operator 宣告 2 顆、實際 76 顆。

Bug 3：把兩件無關的事寫成同一條

原本的清單把 insecureRegistries 和 IDMS 混在一條裡， 好像設了其中一個就代表「私有 registry 接好了」。

它們完全無關：

我的 lab 一開始只設了 insecureRegistries（讓 CRC 信任 HTTP 的 Harbor）， 而 oc get imagedigestmirrorset 是 No resources found。

當時我以為「私有 registry 已經接好了」——因為推得上去、拉得下來。 那只證明「連得到」，不證明「叢集會去那裡拿」。

（現在補上了：odh-workbench-mirror。）

⚠️ 再補一個後來才知道的：IDMS 是用 digest 比對的。 如果你的 pod spec 寫的是 tag 不是 digest，IDMS 不會生效——要用 ITMS。 這又是一個「設了但沒作用」。

三條的共同點

而它們的共同來源只有一個：這份清單是照文件寫的，沒有跑過。

⭐ 所以：清單也是程式，也要測試

我後來把這件事訂成規矩：

任何驗收清單，在拿去用之前，要先在一個你控制得了的環境跑一遍。

理由跟寫程式一樣：

• 你寫的指令可能有 bug（bug 1）
• 你的預期輸出可能是錯的（bug 1 的「預期一行」其實是 82 行）
• 你問的問題可能問錯方向（bug 2）
• 你可能把兩個概念混在一起（bug 3）

而這些只有跑過才會發現。

沒跑過的清單會怎樣

拿一份沒跑過的清單去驗收，最好的情況是浪費時間解釋假警報。

最壞的情況是：對方照著你的清單交付，而你的清單漏掉了真正的問題—— 然後雙方都有一份「全部通過」的紀錄，而系統是壞的。

那份紀錄會在出事時保護不了任何人。

附帶：跑清單的成本比想像低

我在 CRC 上跑完 42 條，花了大約兩天——而且順便發現了平台本身的四個坑。

那兩天的產出不只是「清單修好了」，還有：

• 每一條的實際輸出可以貼進清單當「預期」的範例
• 對方看到範例輸出，就知道你真的跑過——談判位置完全不同
• 你自己在現場看到異常輸出時，認得出來

最後那點最值錢。 驗收現場對方跑一個指令給你看， 你要能在三秒內判斷「這個輸出正不正常」—— 而那個能力只能靠自己先跑過一遍。

你們的驗收清單有沒有實際跑過一遍？還是寫完就直接拿去用？

if new_bpc > base_bpc + tol:
    reasons.append("回歸：比基準差")

base 是現行 production 那一顆。意思是：新模型不能比現在線上的那顆差超過 tol。

聽起來很合理。而且我前一篇才花力氣把 tol 量出依據 （σ = 0.0211，所以 2σ = 0.042）。

但這條規則有一個結構性的缺陷，而且改小 tol 治不好。

⭐ 用真的 gate 程式碼跑一次

假設每次都剛好退步 tol（= 0.042），連續二十次，每一次都送進 gate：

  次     新模型 BPC     基準 BPC     gate       距離原點
   1      5.0366      4.9946     ✅ 通過      +0.0420
   2      5.0786      5.0366     ✅ 通過      +0.0840
   3      5.1206      5.0786     ✅ 通過      +0.1260
  10      5.4146      5.3726     ✅ 通過      +0.4200
  19      5.7926      5.7506     ✅ 通過      +0.7980
  20      5.8346      5.7926     ✅ 通過      +0.8400

二十次之後，BPC 從 4.9946 退到 5.8346——累積退步 0.84。

而每一步都通過了 gate。

如果拿第 20 顆直接跟最初那顆比：

❌ 回歸：test_bpc 5.8346 比基準 4.9946 差（容忍 0.042）

同一個 gate、同一個 tol，只是換了比較對象，結論完全相反。

為什麼改小 tol 沒有用

直覺反應是「那把 tol 調嚴一點」。

沒有用，只是把二十次變成一百次。 因為問題不在容忍度的大小， 在比較的對象——每次都跟「剛剛才被放行的那一顆」比， 於是每一次退步都成為下一次的新基準。

這是棘輪，只是方向反了。 棘輪的設計是「只能往一個方向走，退不回去」。 而這個 gate 讓每一步的退步都變成不可逆的新起點—— 它棘住的是退步，不是進步。

用 Java 講：像 code review 規定每個 PR 最多只能多欠 5 行技術債。 每一次 review 都是對的，一年後系統爛掉， 而且你找不到哪一次該負責——因為每一次都符合規則。

修法：兩個基準，不是一個

擋下的條件 = (比上一筆差 > tol)  OR  (比凍結基準差 > tol_total)

凍結基準的重點是「人工」——它不會自動更新。 要動它，得有人明確做一次決定： 「我承認新的水準就是這樣了，把基準往下移。」

那一個動作應該留下紀錄，而且應該有人簽。 這就是它和滾動基準的差別：滾動基準是自動的，凍結基準是要有人負責的。

這個模式到處都是

一旦看懂，你會在很多地方看到同一個形狀：

共同點：每一次決定都是合理的，而總和是災難。

而且這類問題不會有人負責，因為責任被切成二十份， 每一份都小到不值得反對。

所以驗收要問什麼

看到任何「不能比上一版差超過 X」的規則，問一句：

「這條規則跑二十次之後會怎樣？」

如果對方沒想過，那條規則防的是單次的意外， 不是持續的退化——而後者才是真正會發生的那種。

再問第二句：

「有沒有一個不會自動更新的基準？誰有權改它？」

沒有的話，這條鏈上只有滾動基準，也就是沒有底線。

誠實標一下

我還沒實作這個修法。

上面那個二十次的演示是拿我真正的 gate_reasons() 跑出來的—— 程式碼是真的，退化的過程是模擬的（我沒有真的訓練二十顆愈來愈爛的模型）。

而我的 gate 現在只有滾動基準。所以這篇的結論同樣適用於我自己： 我知道這個洞在哪裡，但它還開著。

你們有哪個規則是「跟上一版比」的？有沒有可能被這樣累積繞過？

我在這個系列裡反覆說「不要相信沒驗過的數字」。 那句話對我自己一樣成立——而且我犯了四次。

第一次：用錯的量法，差點讓工作量翻倍

我給稿子訂了字數上限，量完發現12 篇全部超標，最長的是上限的 1.76 倍。

於是有人問：「那要不要每篇拆成兩篇？」

12 拆成 24。那會吃掉整個檔期，後面真正想寫的東西一篇都放不進去。

我正要開始評估怎麼拆，停了一下，回去看量法—— 我是拿整份 Markdown 直接數的，把兩種讀者永遠看不到的東西算了進去： 發文前要刪的註解，和程式碼區塊。合計約佔每篇 40%。

重量之後：平均 1,553 字，沒有一篇超過 2,000。一篇都不用拆。

教訓：這個錯誤最危險的地方不是它錯，是它看起來剛好合理。 如果它回報「每篇 50 萬字」，我立刻會懷疑。 但「超標 1.76 倍」正好落在「有點糟但可信」的區間。

第二次：消融實驗的評估，沒有套用消融

我做了三個拆零件的實驗（拆掉 causal mask、residual、/√d）， 用 monkeypatch 改模型再訓練。

但評估是另一個 process 跑的。 03_eval.py 重新 import 原始的模型結構—— 所以我是拿「沒有 residual 訓練出來的權重」餵進「有 residual 的結構」去評估。

baseline 幾乎沒動，正好證明問題出在消融不匹配。

⭐ 而抓到它的不是我的檢查。 是第三個實驗跑出一組矛盾的數字 （val 比 baseline 好、test 卻爛掉），我追那個矛盾才發現前兩篇全錯。

教訓：錯誤的數字不會自己招供。 通常是另一個實驗的矛盾把它逼出來——而如果我沒做第三個實驗， 那兩篇會就這樣發出去。

第三次：我猜錯了，而且方向相反

拆掉 attention 的 /√d 之前，我把預測寫死在檔案裡：

分數會放大 5.66 倍 → softmax 過度尖銳 → 訓練不穩 → val loss 掉到 2.0~2.6

實際跑出來是 1.8090——比 baseline 的 1.8479 還低。

四點預測錯了三點，方向也錯。

但這裡有第二層：我差點寫成「拿掉 √d 反而更好」。

因為我另外量過這條產線的自然波動：只換 random seed 跑五次， test_loss 的 σ = 0.0211。而這兩顆模型的差距是 0.0115——小於一個標準差。

正確的結論是第三種：「在這個設定下量不出差異」，不是「更好」也不是「更差」。

教訓：沒有 σ，你手上的每一個比較都是意見。

第四次：我把一個錯誤傳進了要交出去的文件

這個最嚴重，因為它已經流出去了。

早期的紀錄裡有一條：

「pipeline 內建的 MariaDB 是 latin1_swedish_ci，含中文的 pipeline 上傳即失敗」

我沒有重驗就把它寫進了兩篇文章和一份驗收條件。

寫第 28 篇之前我去實查——那條在這個版本上不成立：

schema mlpipeline           utf8mb4_unicode_ci
run_details.Name/Description  utf8mb4
metadata 表（Artifact/Execution/Context）  utf8mb4

中文存得進去，dashboard 也顯示得正確。 而且我早就有反證沒注意到：我自己那些 run 的中文描述，一直好好地存在裡面。

⭐ 但真正的風險還在，只是位置不同——在連線端：

character_set_client      latin1
character_set_connection  latin1
character_set_results     latin1

所以自己寫的查詢會拿到 ?????，而且不報錯。 更嚴重的是 mysqldump 沒指定字元集，會產生一份「看起來成功但中文全毀」的備份。

那對災難復原的影響，比原本那條敘述更嚴重。

教訓：繼承來的結論最危險。 它有一份紀錄背書，看起來已經被驗證過—— 而你不會去驗一件「已經寫在文件上」的事。

四次的共同點

四次裡只有兩次是我自己的機制抓到的。 另外兩次是運氣。

而這正好對應到我在這個系列裡罵別人的話： 檢查在它自己的位置上是通過的。

我最後留下的兩個習慣

① 當一個數字要求你做一個很貴的決定時，先回頭驗那個數字。

驗證的力氣應該跟決定的代價成正比。「拆成 24 篇」是高成本難回頭的動作， 在付出之前回頭花十分鐘驗輸入，是我做過投資報酬率最高的一次除錯。

反過來，如果指標建議的動作很便宜（改個標題、調個參數），不驗也還好。

② 動筆前重跑一次，即使那件事寫在自己的筆記上。

第四個錯誤就是這樣抓到的——而它已經進了要交出去的文件。 如果我沒有訂「每篇提到的東西動筆前必須重跑」這條規矩，它會就這樣出去。

為什麼要寫這一篇

因為這個系列唯一難被複製的，不是那些指令。

指令會過期——ODH 3.6 出來，一半的路徑會變。 但「我量錯了四次，這是怎麼發現的」不會過期。

而且它是這整批文章可信度的來源：一個會公開自己量錯過的人， 比一個只展示成功的人可信。

如果你也在寫技術文章或做評估報告，你怎麼確認自己沒搞錯？

三十天下來，我在同一套平台上撞到五種不同形態。把它們排在一起之後， 我發現它們不是五個 bug——是五種檢查設計上的缺陷，而且可以歸納。

形態一：看 log，不看產物

症狀：後訓練鏈的 log 印著 ALL DONE，每一段都有耗時，評估數字漂亮。 實際：checkpoint 的 mtime 全是三個月前，一步都沒跑。

為什麼騙得過人：log 是程式印的，程式印什麼是程式決定的。 而且那條鏈的腳本沒有 set -e，加上 make ... | tail -6 讓 exit code 被 pipe 尾端接管——每一步都失敗，整條鏈回 0。

戳破它的一句：看產物的時間戳，不看 log。 ls -la 比一千行 log 誠實。

形態二：看結果，不看門檻是誰填的

症狀：promotion gate 顯示 SUCCEEDED，模型上線。 實際：模型沒變好，是門檻從 6.0 被改成 8.0。

三顆能力幾乎相同的模型（7.2343 / 7.2370 / 7.2428）， 一顆上線兩顆被擋。決定的不是模型。

為什麼騙得過人：那是一條全綠的四棒交付鏈， 在任何看板、報表、稽核截圖上都是健康的。

戳破它的一句：去看 run 的 input parameters。 不要問「有沒有品質閘門」，要問「這次的門檻是多少、誰填的」。

形態三：檢查的範圍小於系統的範圍

症狀：DSC 說 KserveReady=True，opendatahub 的 pod 零異常。 實際：模型服務是死的，Init:Error。

根因在叢集外面——模型在 MinIO、image 在 Harbor， 兩個都是主機上的 podman 容器。crc start 不會把它們拉起來， 而叢集的健康檢查只看得到叢集裡的東西。

戳破它的一句：要求對方列出「不在叢集內的依賴」。 外部 S3、私有 registry、外掛 DB、授權伺服器——那些就是盲區。

形態四：檢查在資料層，壞在呈現層

症狀：Grafana pod Running、Prometheus target up、指標有值、dashboard 開得起來。 實際：九個面板全部查不到資料，因為 datasource 沒指定 uid， Grafana 自動產了一個隨機值，而 dashboard JSON 裡 20 處都寫死 uid: "prometheus"。

為什麼騙得過人：每一個自動化檢查都在資料層，而壞的地方在呈現層。 「有沒有人真的打開過那個面板」——沒有任何檢查在問這件事。

戳破它的一句：打開它，看一眼。 一個沒有人打開過的 dashboard，跟沒有 dashboard 的差別， 只在於前者讓你以為自己有在監控。

形態五：寫入成功、讀得回來、內容是空的

症狀：把模型登記進 Model Registry，HTTP 200，條目建立，讀得回來。 實際：test_bpc: 0、model_digest: ""、data_quality_gate: false—— 每一個治理數據都是零值。

原因：API 吃 snake_case，我送 camelCase， 它不認識那個欄位就用零值填上，而且不報錯。

為什麼這個最陰：那筆紀錄看起來完全正常——模型名對、版本名對、 時間對、S3 路徑對。只有治理數據是空的。 而 data_quality_gate 從 true 變成 false， 任何讀這個欄位做決定的流程，會拿一個假的值去判斷。

戳破它的一句：寫進去之後，讀回來逐欄比對。 不要相信 HTTP 200。

補記：後來又撞到兩個，而且都是形態五的變種

寫完這篇之後，我在同一套平台上又撞到兩個，形狀跟形態五一樣—— 格式正確、內容錯誤、沒有任何提示：

① Connection 的憑證是錯的，但 dashboard 顯示正常。 UI 檢查的是 label 和必填欄位有沒有填，不會拿那組憑證去連一次。 直到在 workbench 裡真的用它，才拿到 SignatureDoesNotMatch。

② 鏡像的 repo 對、IDMS 也生效，但 digest 不對。 Harbor 裡有那個 repo、名字完全正確、IDMS 設了而且改導向成功—— 只是裡面那顆是另一個版本。oc 只會說 ImagePullBackOff。

所以形態五可以推廣成一句：

「東西在那裡」和「東西是對的」是兩件事， 而所有只檢查前者的機制，都會放行後者的錯誤。

而這類錯誤有一個共同的偵測法：不要驗證它存在，驗證它能用。 不要看 connection 在不在，去連一次；不要看 image 在不在，去拉一次； 不要看台帳有沒有那筆，把它讀回來比對。

五種的共同結構

排在一起就看得出來，它們是同一個東西的五個側面：

每一種都是「檢查的位置」和「失敗的位置」之間有一段距離。

而那段距離不會自己被發現——因為檢查在它自己的位置上，是通過的。

所以驗收要問什麼

把五種各壓成一句，就是一份可以帶去會議的清單：

1. 產物的時間戳是什麼時候？（不要給我 log）
2. 這次用的門檻是多少、誰填的？（不要問「有沒有閘門」）
3. 哪些依賴不在叢集內？（那些是盲區）
4. 請當著我的面打開那個面板／建一個 workbench。（不接受截圖）
5. 寫進去的東西，讀回來一模一樣嗎？（不要相信 200）

⭐ 而最通用的那一句，我在寫 gate 那篇時整理出來的：

「這條鏈上，哪一個點會因為檢查沒過而讓部署失敗？」

不要問「有沒有做 X」——那個答案永遠是「有」。 要問失敗會在哪裡發生。 如果對方講不出一個具體的點， 那條鏈上的檢查全部是產生報告，不是擋事。

而這兩者在稽核截圖上看起來一模一樣。

最後：其中兩種是我自己犯的

形態一是我踩到別人的，形態二、三、四是我在平台上撞到的。 但這三十天我自己也製造了兩個：

• 用錯的字數量法，差點把 12 篇稿子拆成 24 篇
• 消融實驗的評估沒套用消融，兩篇文章的數字全錯

兩個都不是我的檢查抓到的。 一個是有人問我「要不要拆」我才回頭重量， 另一個是另一個實驗跑出矛盾數字才追出來。

錯誤的數字不會自己招供。

這是為什麼我最後留下的不是一份檢查清單，是一個習慣： 當一個數字要求你做一個很貴的決定時，先回頭驗那個數字。

你遇過最久沒被發現的「假綠」是哪一個？後來是怎麼發現的？

一個放容器 image 的地方，而且是你自己的。

我 lab 用 Harbor（開源、可自架）。企業常見的還有 JFrog Artifactory、 Nexus、或雲端的 ECR/ACR/GAR。

Java 類比：Nexus 對 jar 的角色。差別在 image 更大、更難掃， 而且它是執行環境不只是相依——jar 有問題你重打包， image 有問題可能是底層 OS 的 CVE。

2. 什麼時機需要它

第一個時機：你的叢集連不到外網。這時候不是「要不要」，是「沒有就裝不起來」。

第二個時機（更常見）：你需要回答這三題其中一題——

• 「線上跑的這顆 image 是誰建的、什麼時候？」
• 「它掃過 CVE 了嗎？」
• 「誰核准它進正式環境的？」

公開 registry 一題都答不了。

3. ⭐ 為什麼 image 跟模型不能放同一個地方

這是這篇的重點，而且它會決定你後面整個流程的形狀。

綁在一起會怎樣：每次換模型，你要重跑一次完整的 image 建置、 CVE 掃描、簽章、以及所有相關的簽核。換一個權重檔要走一次發版流程。

分開之後，同一個 image 可以服務不同的模型， 靠環境變數（STORAGE_URI）指到不同的 S3 路徑。

這就是 KServe 的 storage-initializer 存在的理由—— 它讓 image 保持不可變，而模型可以換。

4. 怎麼用：兩個 project 撐起一個放行流程

我的 Harbor 有這幾個 project：

tools       ← 平台自己要用的 image（serving runtime、buildah…）
odh         ← 鏡進來的上游 image
demo        ← 已放行
demo-tmp    ← 待審

⭐ demo-tmp 和 demo 分開，是整個放行機制的關鍵。

流程是這樣：

build 完 → 推到 demo-tmp（待審）
           ↓  掃描、簽章、人工檢查
        管理員手動觸發 replication
           ↓
         demo（已放行）→ 正式環境只認這裡

正式環境的叢集只被允許從 demo 拉。 所以「放行」這個動作 在技術上就是「把 image 從 demo-tmp 複製到 demo」。

為什麼這比「加一個 tag」好

常見的做法是用 tag 表示狀態：myapp:staging → myapp:prod。

問題是 tag 可以被覆寫。 今天的 prod 和上週的 prod 可能是不同的東西， 而且沒有紀錄。

用兩個 project 的話：

• 進到 demo 的東西，digest 不變——它就是被審過的那一顆
• replication 的動作有紀錄，誰按的、什麼時候
• 而且權限可以分開：開發者能推 demo-tmp，但不能推 demo

我實測過這件事：從 demo-tmp replicate 到 demo 之後， digest 完全相同，一顆 image 三個 tag。 那證明放行沒有改變成品本身——這正是稽核要的。

5. 一律用 digest，不要用 tag

# ✗ tag 會漂移
image: myregistry/tools/llm-serve:cpu

# ✓ digest 是內容的雜湊，改了就是不同一顆
image: myregistry/tools/llm-serve@sha256:4ed07b551253fef4f01...

我 lab 那顆 serving image：

tools/llm-serve   digest=sha256:4ed07b551253fef4f01…   tags=['cpu']   314MB

cpu 這個 tag 明天可能指向別的東西，那個 digest 不會。

⚠️ 而且前面提過：IDMS（離線鏡像的來源改寫）是用 digest 比對的。 你的 pod spec 如果寫 tag，IDMS 不會生效——那是一個典型的「設了但沒作用」。

6. 關鍵指標

第二欄是唯一有意義的驗收：給我一個 digest，你能不能回答那三個問題。

如果答案是「要去問某某」，那你有的是一個檔案伺服器，不是 registry。

7. 什麼時候不需要它

• 完全用公開 image、而且不需要回答上面那三題
• 雲端環境、直接用託管的 registry（那也是私有 registry，只是別人管）

但如果你在企業內網、或有稽核要求，這一項沒有選擇。

你們的 image 放哪？有沒有「待審」和「已放行」分開的機制？

模型部署完，oc get isvc 顯示綠的：

oc get isvc llm-scratch -n llm-serve-demo
# NAME          URL                                                            READY
# llm-scratch   http://llm-scratch-predictor.llm-serve-demo.svc.cluster.local   True

READY=True。 然後你把那個 URL 給前端工程師，他說連不到。

看清楚那個網址：.svc.cluster.local——那是叢集內部位址。 從叢集外面（你的筆電、前端伺服器、API gateway）打不到。

為什麼 2.x 沒有這個問題

2.x 的 Knative 會連帶處理 ingress gateway 與對外網址，所以「部署完就打得到」。

3.x 把 Knative 那層拿掉了——好處是排錯回到熟悉的 oc get deploy/svc， 不用先學 Knative；代價是路由與伸縮要自己接。

⚠️ 所以照 2.x 教學做的人，會在這裡卡住而且找不到原因—— 因為那些教學根本沒有「開 Route」這一步。

怎麼開

一行：

oc create route edge llm-play \
  --service=llm-scratch-predictor \
  --port=8000 \
  -n llm-serve-demo

edge 是 TLS 終止在 Route 這一層（叢集內走 HTTP）。 其他選項：passthrough（TLS 直通到 pod）、reencrypt（重新加密）。

確認：

oc get route llm-play -n llm-serve-demo
# NAME       HOST/PORT                                        SERVICES
# llm-play   llm-play-llm-serve-demo.apps-crc.testing         llm-scratch-predictor

⚠️ --port 要填容器實際開的 port，不是慣例值。 我的服務開在 8000（不是 8080），填錯的話 Route 建得起來但打不通。

⭐ 這個 Route 沒有 owner

oc get route llm-play -o jsonpath='{.metadata.ownerReferences}'
# （空的）

它不是 KServe 生的，是我自己建的。

這一點有兩個實際後果：

① 刪掉 ISvc，Route 不會跟著消失。 沒有 ownerReference 就沒有連帶刪除。你會留下一個指向不存在服務的 Route—— 打過去得到 503，而且沒人知道它為什麼還在。

② 它不在任何 GitOps 或備份的自動涵蓋範圍內，除非你自己把它寫進去。

所以 Route 要跟 ISvc 放在同一份 manifest 裡管理，不要用 oc create 隨手開。 隨手開的東西，會變成三個月後沒人敢刪的東西。

還有一個假網址要小心

ISvc 的 status 裡有兩個 URL：

oc get isvc llm-scratch -o jsonpath='{.status.address.url}'
# http://llm-scratch-predictor.llm-serve-demo.svc.cluster.local   ← 內部，真的

oc get isvc llm-scratch -o jsonpath='{.status.components.predictor.url}'
# http://llm-scratch-predictor-llm-serve-demo.example.com          ← 假的

第二個看起來像對外網址，但 example.com 是 KServe 的預設 domain 沒被設定 留下的佔位值。拿它去打會 DNS 解不到。

不要因為「status 裡有一個看起來像外部的 URL」就以為平台幫你開好了。

關鍵指標

驗收就是這一句：從你自己的筆電打一次。 不要在 pod 裡打、不要用 port-forward、不要看截圖。

curl -sk https://llm-play-llm-serve-demo.apps-crc.testing/health

給驗收的提醒

這一項特別值得單獨列一條，因為它有一個很討厭的特性：

在 lab 或 demo 環境，大家習慣用 oc port-forward 測試——那會通。 所以這個問題可以一路藏到正式環境上線當天。

而上線當天發現「還要跟網路組申請對外入口」， 通常代表你要多等一個變更視窗。

你們的模型端點是誰開的？平台自動生的，還是網路組另外開的？

Kueue 是 Kubernetes 的工作排隊器。

一般的 k8s 排程是「有資源就跑，沒資源就 Pending」。 Kueue 多了一層：先排隊，輪到你而且資源夠了才送進去跑。

Java 類比：ThreadPoolExecutor 的那個 queue。 沒有它，每個任務都直接搶執行緒；有了它，任務先排隊， 而你可以決定誰先誰後、每個團隊最多能佔多少。

在 AI 平台上這件事特別重要，因為訓練工作又大又長—— 一個沒排隊機制的叢集，先送出的大任務會把 GPU 全部佔住， 後面的人只能等，而且不知道要等多久。

2. 什麼時機需要它

當「誰能用 GPU」開始需要規則的時候。

具體的訊號：

• 有人抱怨「我的訓練排不進去」，而你查不出是誰佔住的
• 兩個團隊共用一批 GPU，開始為了先後順序吵架
• 有人一次送十個任務把卡佔滿，其他人整天做不了事

如果你只有一個團隊、GPU 也只有一兩張——ResourceQuota 就夠了， 不需要 Kueue。 排隊機制的價值在「多方競用」，不在「資源不夠」。

3. ⭐ 怎麼用：以及它為什麼一開始就擋你

照直覺，開一個元件就是把它設成 Managed：

oc patch dsc default-dsc --type=merge \
  -p '{"spec":{"components":{"kueue":{"managementState":"Managed"}}}}'

Error from server (Forbidden): admission webhook
"datasciencecluster-v2-validator.opendatahub.io" denied the request:
Managed is no longer supported as a managementState

「不再支援」——但它沒告訴你該用什麼。

而更混亂的是，去看 CRD 的 schema：

oc get crd datascienceclusters.datasciencecluster.opendatahub.io -o json | \
  jq -r '.spec.versions[] | select(.name=="v2") |
         .schema.openAPIV3Schema.properties.spec.properties.components.properties
         | to_entries[] | "\(.key)\t\(.value.properties.managementState.enum)"'

kueue          ["Managed","Unmanaged","Removed"]     ← Managed 還在 enum 裡
kserve         ["Managed","Removed"]
aipipelines    ["Managed","Removed"]
...

CRD 的 enum 裡明明列著 Managed。

所以你會遇到這個狀況：照 schema 寫是合法的，但 webhook 會擋。

正解是 Unmanaged

oc patch dsc default-dsc --type=merge \
  -p '{"spec":{"components":{"kueue":{"managementState":"Unmanaged"}}}}'
# patched

Unmanaged 的意思是：「我要用 Kueue，但 operator 不負責裝它，我自己裝。」

在 RHOAI 上，你要另外裝 RHBOK（Red Hat Build of Kueue）這個獨立 operator。

設完之後：

KueueReady   False   PreConditionFailed: pre-conditions not met

這是正確的狀態——它在說「你選了 Unmanaged，但我還沒看到你裝的那個 Kueue」。

4. ⭐ 這件事真正的教訓：兩層驗證會不一致

Kubernetes 的資源驗證有兩層：

第二層可以拒絕第一層允許的東西，而且兩層可能不同步—— CRD schema 是宣告在 YAML 裡的，webhook 是程式碼， 改了程式碼忘了更新 schema，就會出現這種情況。

對你的實際影響

你不能只靠 oc explain 或 CRD schema 來決定怎麼寫 YAML。

oc explain dsc.spec.components.kueue.managementState
# 會告訴你可以填 Managed —— 而那是錯的

唯一可靠的驗證是 --dry-run=server：

oc apply -f my-dsc.yaml --dry-run=server

--dry-run=server 會真的送到 API server 跑完整個 admission 流程 （包含所有 webhook），只是不寫進 etcd。

⚠️ 注意不要用 --dry-run=client——那個只做本機的 schema 檢查， 完全不會碰到 webhook，也就抓不到這個問題。

這一條可以直接寫進你的變更流程： 所有要進正式環境的 YAML，先在測試叢集 --dry-run=server 過一次。 那比人工 review 有效得多，因為它跑的是真正會擋你的那段程式。

5. 關鍵指標

第二欄跟這個系列其他篇是同一個模式：排隊機制的價值在它會擋東西。 沒擋過任何東西的排隊器，跟沒有排隊器一樣。

6. 什麼時候不需要它

• 單一團隊、GPU 不需要搶
• 用 ResourceQuota 就能表達你的規則（例如「這個 namespace 最多兩張卡」）

Kueue 解決的是「順序」與「公平」，不是「上限」。 如果你要的只是上限，ResourceQuota 更簡單而且不用多裝一個 operator。

7. 我沒驗過的部分

我沒有實際裝 RHBOK 也沒有跑過排隊——我的叢集只有一個節點、 沒有 GPU、CPU 還已經用到 99%，跑不了有意義的排隊實驗。

所以這篇能給你的是：怎麼開、為什麼被擋、正解是什麼， 以及那個兩層驗證的教訓。排隊行為本身我沒有證據。

你們有在用 Kueue 或其他排隊機制嗎？還是靠 namespace quota 硬擋？