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

如果Docker 把環境包起來了，那GPU 呢？

Day 17 我談到 GPU Driver 與 Runtime 也是 AI Environment 的一部分。那麼問題就來了：

如果 Docker 可以把 AI 的執行環境封裝起來，那 GPU 是不是也可以一起「包進 Container」？

實際開始研究 GPU Container 後，我才發現事情沒有這麼簡單。

Docker 可以把 Python、Framework、Libraries、Runtime 等使用者空間的環境封裝起來，但 GPU 本身仍然是 Host 的硬體資源。以 AMD ROCm 為例，目前官方文件明確要求 Host 上必須存在 amdgpu kernel-mode driver，Container 再透過 GPU device access 使用硬體。

NVIDIA 的架構也是類似概念：NVIDIA Container Toolkit 負責讓 Container 能夠使用 Host GPU，並處理必要的 GPU driver libraries 與相關資源。

這讓我重新理解 Container 的「隔離」到底是什麼。

Container 並不是一台完整的虛擬電腦。

它可以封裝 Application 與大量 User-space dependencies，但仍然需要透過 Host Kernel、Driver 與 Hardware 存取底層資源。Container 可以封裝 AI Software Environment，但不能把實體 GPU 與 Host Kernel 完全一起封裝。

所以問題來了：

如果 AI Container 本身可以被搬到另一台機器，但另一台機器的 GPU、Driver 與 Runtime 不相容，這個 Container 還算真正可攜嗎？

這也是《AI Infrastructure 實戰：AI Demo 為什麼上不了 Production？》中，我希望從 Docker、GPU 與 Runtime 的交界處，重新理解 AI Deployment 的原因。Container 解決的是 Software Environment 的可攜性；Production 還必須處理 Hardware、Driver、Runtime 與 Infrastructure 的相容性。

關於作者

我是一名 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的使用技術心得，這些是外面很少有的獨家踩坑經驗，未來買書真的賺到！)。敬請期待唷~ 關於永久網站也有了，正在準備了~