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

如果有了 Docker，AI 就一定能重現嗎？

Day 13 我談到 Docker 可以把 AI Application 的執行環境封裝起來，但繼續往下研究後，我發現一件事情：有了 Docker，不代表就自動擁有完全可重現的環境。

一開始我也很容易把 Docker 理解成「把所有東西包起來」，只要 Dockerfile 在，應該到哪裡都一樣。但實際接觸 AI/ML 環境後才發現，Dockerfile 裡面的 Base Image、Python 套件、Framework、Model，以及 GPU Driver 與 Runtime 之間仍然存在相依關係。

例如 Dockerfile 如果只寫一個浮動的 Image Tag，未來重新 Build 時，取得的內容可能已經不同。Docker 官方目前也建議透過 Digest 固定 Base Image，讓相同的建置能使用相同的 Image 內容，以避免同一個 tag 未來指向不同內容。

而 AI 又比一般 Application 更複雜。GPU Container 雖然可以把 CUDA 等 User-space 元件放進 Container，但 Host Driver 仍然需要與 Container 使用的 Runtime 相容。

這讓我開始理解：Reproducibility 不是「用了 Docker」就完成，而是一套從 Code、Dependency、Image、Runtime 到 GPU Environment 的管理方法。 Docker 是 Reproducibility 的基礎，Docker 官方現在也特別強調，固定 Image Digest 可以提高建置可重現性，但也代表安全更新不會自動跟進，因此必須把「可重現」與「更新／安全」一起管理。

所以問題來了：

如果 Docker 只能把環境封裝起來，卻不能自動保證每一個 Dependency 與 Runtime 都完全一致，我們到底要怎麼建立真正可重現的 AI Environment？

這也是《AI Infrastructure 實戰：AI Demo 為什麼上不了 Production？》中，我希望深入拆解的問題。這也是「AI 技術」進入真正 Production Engineering 的一些工程問題。

關於作者

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