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

AI 專案到底要固定哪些東西，才能真正重現？

Day 14 我談到「如果有了 Docker，不代表 AI 環境就一定可以重現」。繼續往下思考後，我發現真正困難的問題其實是：我們到底要固定哪些東西？

以前寫程式時，我可能只需要保存 Source Code；但 AI 專案的執行結果，往往同時受到 Python 版本、Library、Framework、Model、Model Version、GPU Runtime、Container Image，甚至 Dataset 與 Configuration 影響。

我自己在接觸 AI/ML 環境時，越來越感受到一件事情：如果只把程式碼放進 Git，卻沒有記錄模型版本、Dependency 或執行環境，那麼幾個月後重新執行同一個專案，很可能已經得不到當初的結果。

這也是我開始理解「Reproducibility」真正含義的地方。一個 AI 專案，到底要記錄哪些東西，下一次才能真的重現？

它不是單純把檔案保存起來，而是要讓另一個人，甚至未來的自己，有能力知道：當時到底用了什麼 Code、什麼 Model、什麼 Environment，以及什麼資料。

Docker 官方目前也建議將 Base Image 與外部 Dependencies 固定到明確版本或 Digest，以避免同一個建置設定在不同時間得到不同結果。Docker Git reference，以避免重新 build 時取得不同內容。而Google Cloud 現行 AI/ML 架構指南也強調，要追蹤 dataset version、model parameters、model type 等 metadata，並透過一致的 container environment 來提高 reproducibility。

所以問題來了：

如果今天要把一個 AI Demo 交付給別人，究竟需要保存哪些資訊，才能讓半年後的自己(或他人)重新 Build 時，還能得到接近當初AI Demo的結果？

這也是《AI Infrastructure 實戰：AI Demo 為什麼上不了 Production？》中，我想從實戰角度整理的問題。AI Reproducibility 不只是保存 Code，而是保存「讓結果可以被重新建立」的完整條件。Prototype 的目標是「今天能跑」；Reproducibility 的目標是「未來還能跑」。Production是從初稿到完稿的系統化工程問題。

關於作者

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