我有多年 IT 技術與跨域學習經驗，現在把 AI、Cloud、Infrastructure 串起來。

requirements.txt 固定了，為什麼 AI 還是可能跑不起來？

Day 16 我談到 requirements.txt 可以固定 Python 套件版本，但繼續往下拆 AI Environment 後，我發現還有一個更容易被忽略的問題：GPU Runtime。 這一層很容易被忽略卻也很重要。

一個 AI 專案可能已經固定了 Python、PyTorch 與其他 Libraries，但只要 GPU Driver、ROCm 或 CUDA Runtime 的版本與 Framework 不相容，原本可以執行的程式，仍然可能無法正常使用 GPU。

我自己在接觸 AI/ML 與 GPU 環境時，越來越感受到這個問題。尤其當不同 GPU、Operating System、Driver、Runtime 與 Framework 組合在一起時，「套件裝成功」和「GPU 可以正常運作」其實是兩件事情。

AMD 現行 ROCm 文件也提供完整的 Compatibility Matrix，將 GPU、Operating System、Kernel、ROCm 與 PyTorch 等 Framework 的支援版本放在一起管理。這讓我更清楚看到：AI Environment 並不是只有 Python Package 而已。

甚至使用 Container 也不代表 Host Environment 可以完全忽略。以 ROCm 為例，AMD 官方目前仍要求 Host 上存在相應的AMD GPU Kernel Driver，Container 再透過 GPU device access 使用硬體。即ROCm Docker Container 需要 Host 的 amdgpu kernel driver，Container 再透過 /dev/kfd、/dev/dri 等方式取得 GPU 存取權。

所以我開始重新思考「可重現」的定義：

**如果 Code、Python 與 Packages 都固定了，但 GPU Driver 與 Runtime 沒有固定或驗證，這個 AI Environment 真的算可重現嗎？**為什麼 AI Demo 明明已經 Docker 化，到了另一台機器還是可能出問題？

這也是《AI Infrastructure 實戰：AI Demo 為什麼上不了 Production？》中，我希望從實際 Infrastructure 角度拆解的問題。

AMD 目前的 ROCm 相容性文件也明確顯示，GPU、OS、Kernel、Driver、ROCm 與 PyTorch 等 Framework 都存在版本相容矩陣；AMD 也指出 ROCm 是由相互協調的 firmware、driver 與 user-space 元件組成。Driver、ROCm/CUDA、Framework 之間還存在相容性問題。

關於作者

我是一名 AI × Infrastructure Solution / Integration 技術實作者，專注於 AI、MLOps、Cloud、Docker、Kubernetes、GPU、LLM 與 AI Agent 等技術的整合與落地，跨足 LLM、GPU、Docker、Kubernetes、MLOps 與 AI Agents，持續研究企業 AI 從 Prototype 到 Production 所需要的工程能力。協助企業理解 AI 從 Prototype 到 Production 所需要的技術能力。

本系列同時是《AI Infrastructure 實戰：AI Demo 為什麼上不了 Production？》的延伸實戰筆記。如果想完整理解這些更深的技術問題，未來可以去看這本書(書中包含了一些的範例與提示詞，特別是AMD W7900 48G的使用技術心得，這些是外面很少有的獨家踩坑經驗，未來買書真的賺到！)。敬請期待唷~