Day 3：先問一句——這些用 podman 做不行嗎？

這是《OpenShift AI 入門 30 天》系列的第 3 篇。

這是什麼、解決什麼問題

在裝任何東西之前，先誠實回答一個問題：

社群教的都是 podman 和 docker compose，我為什麼要一整套 OpenShift AI？

這個問題該在 Day 3 問，不是在導入到一半才問。
而且它的答案不是「因為 k8s 比較好」。

我兩邊都做過：先在筆電上用 podman 把一個自己刻的小 GPT 從訓練到上線跑完，
之後才把同一件事搬上 OpenShift AI。這篇是那個對照。

先講結論：podman 走得比你以為的遠

很多人低估了 podman 版能做到的程度。 我那套 podman stack 有：

起整套的指令長這樣：

podman pod create --name llm-stack -p 8000:8000 -p 9090:9090 -p 3000:3000
podman run -d --pod llm-stack --name llm-api --device nvidia.com/gpu=all \
  -v ./artifacts:/app/artifacts:ro,Z llm-from-scratch:latest
podman run -d --pod llm-stack --name llm-prometheus \
  -v ./monitoring/prometheus.yml:/etc/prometheus/prometheus.yml:ro,Z prom/prometheus
podman run -d --pod llm-stack --name llm-grafana \
  -v ./monitoring/grafana/provisioning:/etc/grafana/provisioning:ro,Z grafana/grafana

四行，一分鐘起來。

對照一下前面幾天講的東西：STORAGE_URI 對應 -v mount，
InferenceService 對應 podman run，Prometheus 那段一模一樣，
canaryTrafficPercent 對應那兩個環境變數。

概念是同一套。 這也是為什麼 podman 版很值得先做一次——
你會先懂概念，再去看那些 CRD 就不是天書。

那它在哪裡斷？

不在功能，在「不只你一個人」和「你不在的時候」。

斷點一：多人

podman 版的隱含前提是「這台機器是我的」。

兩個人要用同一台，馬上要回答：誰的容器、誰能停誰的、
GPU 誰先用、你 podman rm -f 的時候會不會殺到別人的。

這些問題 podman 沒有答案，因為它不是設計來解這個的。
Day 20（權限）和 Day 13（Hardware Profile）在解的就是這個。

斷點二：你不在的時候

• 機器重開，容器會自己起來嗎？（--restart 加了嗎？）
• 服務掛了誰重啟它？
• 機器壞了，服務去哪？

單機沒有 HA，這不是設定問題，是物理問題。

斷點三：誰在什麼時候改了什麼

podman run 打在某個人的終端機裡。那筆紀錄在 shell history。

Day 29 的七題（誰核准上線的、做了哪些檢查、上線的是哪一版），
podman 版一題都答不出來——不是它不能，是沒有地方留。

斷點四：規模

十個模型、五個團隊、三十個 workbench。
podman 不是撐不住，是你會開始自己寫排程器和權限系統——
然後你就在重寫 k8s，只是比較難用。

⭐ 交叉點在哪

用一句話判斷：

當「誰能做什麼」和「不在場時會怎樣」開始需要答案，就該換了。

具體一點，出現以下任何兩件，podman 就開始比較貴：

• [ ] 超過一個人要用同一批資源
• [ ] 有人（稽核、法遵、主管）會問「線上是哪一版、誰放上去的」
• [ ] 服務不能停超過幾分鐘
• [ ] 資料不能落在個人設備上
• [ ] 模型超過三個、或會定期換版
• [ ] 需要跨環境（dev / test / prod）一致

一件都沒有的話，podman 是對的選擇，而且會讓你活得比較輕鬆。

一張對照表

⚠️ 注意「重建環境」那一列：
podman 版反而可能比較好重建——一份 script 就是全部。
OpenShift 上如果沒做 GitOps，重建難度是高的。
所以那一列不是自動贏，是「你有沒有做」的問題。

我的建議

如果你正在學：先用 podman 做一次。

概念一樣、迴圈快、壞了重來的成本接近零。
你在 podman 上懂的每一件事，到 OpenShift 上都還算數——
只是換了個名字，而且多了「別人也在用」這個維度。

如果你在評估導入：

先誠實勾一次上面那六個框。
勾不到兩個就別導——你會付出平台的成本，卻得不到平台在解的那些問題的回報。

而如果你是被交辦的人，這篇最有用的地方是：
你現在可以回答「為什麼不用 docker 就好」這個問題了，
而且答案裡沒有一句是「因為比較先進」。

常見問題

Q：那 docker compose 呢？
A：同一個結論。compose 比 podman run 好管一點（設定寫在檔案裡），
但斷點完全一樣——它也沒有多人、沒有排程、沒有稽核。

Q：可以用 podman + systemd 撐久一點嗎？
A：可以，podman generate systemd（或 Quadlet）能解決「重開機自動起來」。
這確實把斷點二往後推了，值得做。
但它解不了多人和稽核。

Q：k3s / minikube 算中間選項嗎？
A：算。它們給你 k8s 的 API 和 RBAC，但沒有 OpenShift AI 那層
（dashboard、workbench、pipeline、model registry 都要自己裝）。
如果你要的只是 k8s 而不是 AI 平台，這是合理的中間站。

Q：那我前面兩天學的白學了嗎？
A：沒有。Day 2 那張圖在 podman 上一樣成立——
只是每個框變成一個容器而不是一個 CR。
流程不變，換的是誰來管。

明天

Day 4 開始動手，在一台筆電上把 OpenShift AI 裝起來。

如果你看完這篇覺得「我們還不需要」——那也是個結論，
而且是這 30 天能給你最省錢的一個。

• 叢集：CRC 2.63.0 · OpenShift 4.22.7 · Kubernetes v1.35.6
  單節點 13 vCPU / 40 GiB / 120 GB，叢集內沒有 GPU
• Operator：opendatahub-operator.v3.5.0（即 RHOAI 3.x 的上游開源版）、
  cert-manager-operator.v1.20.0（3.x 的必要相依，2.x 不需要）
• 開啟的元件：kserve、aipipelines、dashboard、workbenches、modelregistry
• 叢集外：Harbor v2.15.2（私有 registry）、MinIO（S3），跑在宿主的 podman 上
• 宿主：Framework Laptop 16（Ryzen AI 7 350 · 8C/16T · 64 GB · 1 TB NVMe）

⚠️ ODH ≠ RHOAI：元件同源，但 namespace 與部分名稱不同
（這裡是 opendatahub，商用版是 redhat-ods-*）。指令邏輯可照用，字串要自己對一次。

補充資料

• 🧪 這篇用到的 YAML／腳本：https://github.com/ryanGTR/openshift-ai-30days
• 🤖 lab 服務的那個模型（從零手刻的小 GPT）：https://github.com/ryanGTR/llm-from-scratch

你們現在的模型服務跑在哪？podman/docker、VM，還是已經在 k8s 上？　留言或到原文留言都可以，我會回。