林旺滴自由創作空間

  我有多年 IT 技術與跨域學習經驗，現在把 AI、Cloud、Infrastructure 串起來 如果我已經弄了一個 AI 系統，到底怎樣才算 Production-ready？ 走到 Day 30，我想重新回到這個系列最開始的問題：AI Demo 可以跑，距離真正的 Production 到底還差多少？ 一路從 GPU、VRAM、Runtime、Docker、Kubernetes，到 Autoscaling、Monitoring、Reliability、Security 與 AI Agent，我越來越感受到： Production-ready 從來不是某一項技術，而是一整套工程能力。 一個模型可以正常回答，只代表 Model 能運作；Container 可以啟動，也只代表 Application 能執行。真正面對使用者後，還需要問：流量增加能不能 Scaling？服務故障能不能恢復？出了問題能不能觀察？GPU 成本能不能控制？權限與 Secrets 是否安全？Agent 做錯決策時，系統能不能限制影響範圍？ Google Cloud 的 AI/ML Well-Architected Framework 也把 Production AI 的思考分散在 Operational Excellence、Security、Reliability、Cost 與 Performance 等不同面向，而不是只關注模型本身。Google 的 GenAI deployment guidance 也把 version control、hardware、resources、access control、monitoring/logging 等放進部署檢查。 這讓我逐漸建立一套自己的檢查方式： Model → Environment → Deployment → Scaling → Observability → Reliability → Security → Cost 每一層都不一定需要最複雜的技術，但都應該知道「如果這一層失敗，接下來怎麼辦？」 所以問題來了： Production-ready 真的是一個可以打勾完成的終點，還是一個必須持續驗證與改善的工程過程？ 這也是明天 Day 30，我想重新回答「AI Demo 為什麼上不了 Production？」這個問題的起點...

  我有多年 IT 技術與跨域學習經驗，現在把 AI、Cloud、Infrastructure 串起來。 AI Agent 接上 Tools 後，為什麼 Production 變得更複雜？ Day 28 我談到 AI Security 不能只依靠 Prompt，而必須透過真正的 Authorization 與 Infrastructure 建立安全邊界。 但當 LLM 進一步變成 AI Agent，我發現問題又更複雜了。 一般聊天模型產生錯誤答案，影響通常停留在「內容」；但當 Agent 接上資料庫、API、檔案系統、Email，甚至程式執行工具之後，模型的輸出就可能進一步變成真實的「行動」。開始有能力產生真的高風險行動。 我自己在研究 AI Agent 架構時，越來越重視一件事情： Agent 能做到什麼，不能只由模型自己決定，而應該由系統決定它被允許做到什麼。 OWASP 目前也把 Excessive Agency 列為重要的 LLM Application 風險。當 Agent 擁有過多功能、權限或自主性時，一次 Hallucination、Prompt Injection 或錯誤判斷，都可能進一步變成真正的系統操作。 因此 Tool Access 應該遵循 Least Privilege。需要讀取資料，就不一定需要寫入權限；需要查詢檔案，也不代表應該允許刪除檔案。對高風險操作，更應該加入明確授權或 Human Approval。敏感操作明確授權、外部資料視為不可信，以及高風險操作加入 Human-in-the-loop。Google Cloud 在 2026 年也正在把 Agent Identity、Agent Access Management、Guardrails 與 Runtime Defense 當成 Agentic Enterprise 的重要安全基礎。 這讓我開始理解： AI Agent 的 Production 問題，不只是「模型回答得好不好」，而是「模型做錯決定時，系統允許它造成多大的影響」。 所以問題來了： 如果 Agent 判斷錯誤，我們的 Architecture 能不能讓錯誤停在模型，而不是一路擴散到真實系統？ 這也是《AI Infrastructure 實戰：AI Demo 為什麼上不了 Production？》中，我認為 ...

  我有多年 IT 技術與跨域學習經驗，現在把 AI、Cloud、Infrastructure 串起來。 如果 AI 可以正常運作，但它真的安全嗎？ Day 27 我談到 Production Reliability：服務故障時，系統能不能發現、隔離並恢復？ 但即使 AI Service 穩定運作，還有另一個不能忽略的問題： 它真的安全嗎？ AI Service 沒掛，但不該使用的人進來了怎麼辦？ 我以前接觸 Cloud 與 Kubernetes Security 時，會關注 Authentication、Authorization、Secrets 與 Least Privilege。但開始研究 LLM 與 AI Agent 後，我發現 AI Application 又多了一層新的攻擊面。 例如使用者輸入的 Prompt 本身可能是不可信任的；AI 可能讀取外部文件、RAG 資料或網頁；如果 Agent 又能呼叫 API、資料庫或其他 Tools，一次惡意的 Prompt Injection，影響的可能就不只是「回答錯誤」。 OWASP 目前仍把 Prompt Injection 列為 GenAI Application 的重要安全風險，並建議限制模型與工具的權限、採用 Least Privilege，以及對高風險操作加入人工確認。OWASP 最新 GenAI Security guidance 則持續把 Prompt Injection、敏感資訊洩漏，以及 Agent 權限過大等列為重要風險。 這讓我開始理解：AI 能正常回答，不代表 AI Service 是安全的。 AI Security 不能只靠 System Prompt 告訴模型「不要做危險的事」。 OWASP 甚至明確提醒，System Prompt 不應被視為秘密或安全控制，Credentials、Connection String 等敏感資訊更不應放進 System Prompt。真正的安全邊界仍然必須建立在 Application 與 Infrastructure，例如 Identity、Authorization、Secret Management、Tool Permission 與 Audit。 Kubernetes 本身也是相同概念：官方建議只提供使用者與 Service Accou...

  我有多年 IT 技術與跨域學習經驗，現在把 AI、Cloud、Infrastructure 串起來。 如果AI Service 掛掉了，Production 應該怎麼辦？ 前幾天從 Monitoring、Troubleshooting 一路談到 Bottleneck Optimization，但即使效能調整得再好，我開始思考另一個更現實的問題： 如果 AI Service 有一天真的掛掉了呢？AI Service 壞掉時，系統能不能自己發現、隔離並恢復？ 自己做 Demo 時，程式出錯可能重新啟動就好。但到了真正進入 Production，如果使用者正在使用服務，「我等等手動重開」顯然不是理想答案。也不可能每次都等工程師發現問題，再手動登入伺服器 Restart。 我在學習 Cloud、Container、Kubernetes 與 AI Infrastructure 的過程中，逐漸理解 Reliability 並不是要求系統「永遠不能故障」，而是要先思考：故障發生時，系統能不能偵測、隔離並恢復？ Kubernetes 就提供了不同的 Health Probe。Liveness Probe 可以判斷 Container 是否陷入無法正常工作的狀態，必要時重新啟動；Readiness Probe 則回答另一個問題：「這個 Pod 現在適不適合接收流量？」如果檢查失敗，Pod 可以暫時停止接收 Service 流量，而不是直接把請求送給一個還沒準備好的服務。Kubernetes 官方目前把 Startup、Liveness、Readiness Probe 分成不同責任：Startup 判斷程式是否完成啟動；Liveness 判斷是否需要重新啟動 Container；Readiness 則決定 Pod 現在是否應該接收流量。 AI Service 又有一個很有意思的情況：Process 啟動了，不代表 Model 已經準備好回答問題。 大型模型可能還在載入權重、初始化 GPU 或建立服務環境。這也是 Startup Probe 可以發揮作用的地方，在應用真正啟動前，避免過早進行 Liveness / Readiness 檢查。 這讓我開始重新理解 Production Reliability： 真正重要的不是保證「永遠不壞」，而是系統壞掉時，能不能知道自己壞了，...

  我有多年 IT 技術與跨域學習經驗，現在把 AI、Cloud、Infrastructure 串起來。 AI 變慢，多加 GPU 就一定有用嗎？ Day 25 我談到，當 AI Service 變慢時，應該先透過 Metrics、Logs 與 Traces 找出真正的 Bottleneck。 但找到效能問題後，很容易出現另一個直覺： AI 很慢，那就多加幾張 GPU？ 我自己在接觸 GPU、LLM 與 AI Infrastructure 的過程中，越來越發現事情沒有這麼簡單。AI Inference 是一整條處理鏈，GPU 只是其中一環。不要看到資源滿載就直接加資源；先確認 Bottleneck。找到 Bottleneck 之後，才有資格談 Optimization。 如果真正的 Bottleneck 是 Request Queue、Model Server、Batch 設定、Context Length、Model Loading、Storage I/O 或 Network，即使增加 GPU，也不一定能得到預期的改善。 Google Cloud 目前針對 GKE LLM Inference tooling 的最佳實務，它也不是單純要求增加 GPU，不是單純追求「GPU 越多越好」，而是分析 latency、throughput、cost 之間的 trade-off，尋找接近最佳 saturation point 的配置。而是依照不同目標選擇不同方法。例如降低 Latency、提高 Throughput 與降低 Cost，可能分別需要調整 GPU、Quantization、Batching、Tensor Parallelism、Context Length 或 Replica 數量。 Google Cloud 2026 年 8 月更新的 GKE LLM inference 最佳實務也採取類似思路：先 benchmark latency / throughput，再調整 inference server、quantization、parallelism、batching、context length 或 scaling，最後重新 benchmark 驗證，而不是看到效能問題就直接增加 GPU。 這讓我開始理解一個很重要的 Infrastructure 觀念：...

  我有多年 IT 技術與跨域學習經驗，現在把 AI、Cloud、Infrastructure 串起來。 如果AI 變慢，我該先看 GPU、Model 還是 Network？ Day 24 我談到，AI 上 Production 後不能只看「服務有沒有掛掉」，還需要知道系統到底發生什麼? 但真正遇到問題時，又會出現另一個困難： 如果使用者告訴我「AI 變慢了」，我第一個應該檢查什麼？ 以前遇到程式變慢，我可能直覺想到 CPU、Memory 或 Network。但 AI Inference 的處理流程更加複雜，一個 Request 從進入服務，到模型開始產生第一個 Token，再到完整回答，中間可能經過 Load Balancer、Queue、Model Server、GPU、Runtime 等不同環節。 我自己在接觸 AI Infrastructure 的過程中，越來越感受到：真正重要的能力不是背下一堆 Monitoring 指標，而是能夠把「使用者看到的問題」逐層往下拆。 例如 Google Cloud 目前針對 GKE AI inference，會區分 TTFT、TPOT、ITL、Request Latency 與 Throughput 等不同重要效能指標。這些數值可以幫助我們判斷問題究竟發生在等待第一個 Token，還是發生在後續 Token 的生成階段。 而 Kubernetes 的 Observability 又可以把 Metrics、Logs 與 Traces 串在一起，從系統數值、事件紀錄到 Request 流程，逐步縮小問題範圍。 這讓我開始建立一個很簡單的思考方式： 先確認「慢在哪裡?」，再問「為什麼慢?」。 如果 Queue 增加，可能是請求進來太多；如果 TTFT 變高，可能需要檢查模型服務與 GPU 資源；如果整體 Request Latency 增加，則還要往 Network、Gateway 與 Application 路徑繼續追。 所以問題來了： 當使用者只告訴我「AI 變慢了!」，我能不能從 Metrics、Logs 與 Traces 開始，一層一層找到真正的 Bottleneck？ 這也是《AI Infrastructure 實戰：AI Demo 為什麼上不了 Production？》中，我想建立的另一種 AI 工程思考方式。...

  我有多年 IT 技術與跨域學習經驗，現在把 AI、Cloud、Infrastructure 串起來。 如果AI 上 Production 後，我到底要監控什麼？ Day 23 我談到，AI Service 可以透過 Autoscaling 動態增加 GPU 資源，但資源增加之後，另一個問題也跟著出現： 我怎麼知道現在到底發生了什麼？ 如果只看到「服務還可以使用」，可能很容易以為系統一切正常。但 AI Service 真正進入 Production 後，使用者感受到的問題可能是回應變慢、請求開始排隊、GPU 記憶體不足，甚至錯誤率逐漸增加。 我自己從 AI Infrastructure、Cloud 與 Kubernetes 的學習過程中，越來越理解 Monitoring 和單純「看 CPU 使用率」其實是不同層次的事情。 Kubernetes 官方目前將 Observability 分成 Metrics、Logs 與 Traces 三大類。Metrics 可以告訴我們系統的數值狀態，Logs 可以協助了解發生過什麼事情，而 Traces 則可以追蹤一次 Request 經過系統不同元件的路徑。 而 AI Inference 又有自己的特殊指標。例如 Google Cloud 目前針對 GKE 的 LLM inference，會關注 TTFT、NTPOT、Request Latency、Throughput，以及 Queue Size、Batch Size、KV Cache 等AI-specific指標；GPU 本身也可以觀察使用率與記憶體使用情況。 這讓我開始重新思考： AI Production 的 Monitoring，不應該只是回答「伺服器有沒有掛掉」，而應該回答「使用者體驗、模型服務、GPU 與 Infrastructure 現在到底發生什麼？」 所以問題來了： **如果今天 AI 回應突然變慢，我要怎麼判斷問題究竟來自 Model、Queue、GPU、Network，還是 Infrastructure？**為什麼有問題? 這也是《AI Infrastructure 實戰：AI Demo 為什麼上不了 Production？》接下來要從 Monitoring 走向 Observability 的原因。因為「CPU 正常」並不代表 AI Servic...

  我有多年 IT 技術與跨域學習經驗，現在把 AI、Cloud、Infrastructure 串起來。 如果AI 自動擴展很好，但 GPU 帳單誰來付？ Day 22 我談到，HPA 可以增加 AI Pod，但如果沒有足夠的 GPU Node，還需要進一步擴展底層 Infrastructure。 這時候我開始想到另一個問題： 如果系統可以自動增加 GPU，那是不是代表我們只要把 Autoscaling 打開就好了？ 答案顯然沒有這麼簡單。 因為對一般 Web Application 來說，多增加幾個 CPU Instance 已經需要考慮成本；但 AI Inference 使用 GPU 時，單一 Node 的資源成本通常更高。如果流量突然增加，系統自動增加 GPU Node，確實可以維持服務，但如果流量下降後沒有適當縮容，閒置的 GPU 資源就可能變成持續產生的成本。 我自己開始從 AI Infrastructure 的角度思考後，慢慢發現： Production 的目標不是「永遠擁有最多資源」，而是在效能、可用性與成本之間找到合理的平衡。 Kubernetes 官方目前也把 Node Autoscaling 的目的描述為在滿足 workload 所需容量的同時，透過 Node provisioning 與 consolidation 優化成本。即「滿足 workload 需求，同時最佳化成本」 Google Cloud 目前針對 AI/ML accelerator 也把成本與效能列為選擇 GPU/TPU 資源時的重要考量，並提供 Spot、Flex-start 等不同的資源取得方式來因應不同 workload。Google Cloud 對 GPU AI/ML workload 也特別強調要在成本、效能與 GPU 資源利用率之間取平衡。 這讓我開始重新思考 AI Scaling： **真正成熟的 Autoscaling，不只是讓服務在流量增加時「撐得住」，還要在流量下降時「不要繼續浪費錢」。**Autoscaling 的目的不是「永遠有足夠資源」，而是在效能、可用性與成本之間取得平衡。 所以問題來了： **如果 AI Service 可以自動增加昂貴的 GPU 資源，我們到底應該用什麼方式決定「效能值得花多少錢」？**那什麼時候該擴、什麼時候該縮？ 這也是...

  我有多年 IT 技術與跨域學習經驗，現在把 AI、Cloud、Infrastructure 串起來。 如果Kubernetes 可以增加 Pod，但誰來增加 GPU？ Day 21 我談到 AI Service 流量增加時，可以透過 Autoscaling 增加 Pod。 但繼續往下想，我發現一個很現實的問題： 如果 Pod 已經增加了，卻沒有足夠的 GPU Node，它到底要跑在哪裡？ 這也是我開始理解 Kubernetes AI Infrastructure 後，覺得很有意思的一個地方。 假設原本只有一個 GPU Node，AI Service 突然需要更多 Replica，HPA 可以要求 Kubernetes 增加 Pod；但如果現有 Node 已經沒有足夠的 GPU 資源，新的 Pod 就可能沒有地方可以執行。不是 HPA 加幾個 Pod 就結束。 這時候就不能只考慮 Pod Scaling，而必須進一步處理 Node Scaling。 Kubernetes 官方目前的 Node Autoscaling 文件說明，當 Pod 因為現有 Node 沒有足夠容量而無法被排程時，Node Autoscaler 可以新增 Node 來提供所需容量。 而在 GKE 中，Cluster Autoscaler 會根據 Pod 的 Resource Requests 判斷是否需要增加 Node；對 GPU Workload 而言，還需要考慮 GPU 資源與相關限制。Google Cloud 目前也特別提醒，啟用 GPU Cluster Autoscaling 時，GPU Quota 必須足以支撐可能擴展到的最大 GPU 數量。 這讓我開始理解： AI Autoscaling 其實不是單純增加 Pod，而是一整條從 Application 到 Infrastructure 的 Scaling Chain。 所以問題來了： **如果 HPA 想增加 AI Pod，但 Cloud 裡沒有足夠的 GPU、Quota 或可用容量，這個 AI Service 到底會發生什麼？**Pod 到底會去哪裡？ 這也是《AI Infrastructure 實戰：AI Demo 為什麼上不了 Production？》中，我想從 Kubernetes 一路看到 Cloud Infras...

  我有多年 IT 技術與跨域學習經驗，現在把 AI、Cloud、Infrastructure 串起來。 如果AI 流量突然增加，GPU 不夠了怎麼辦？ Day 20 我談到，當 AI Service 從「自己跑」變成「很多人使用」後，Kubernetes 可以協助管理大量 Container。 但接著又出現一個很現實的問題： 如果今天只有 10 個人使用，明天突然變成 1,000 個人，該怎麼辦？ 一開始我直覺想到的答案是：「流量變大，就增加更多 Pod。」 但實際開始理解 Kubernetes 與 AI Inference 後，我發現真正困難的不是「增加 Pod」，而是 到底什麼時候該增加？增加多少？什麼時候又可以縮回去？ Kubernetes 的 Horizontal Pod Autoscaler（HPA）可以根據觀察到的 Metrics，自動增加或減少 Deployment 的 Pod 數量。 但 AI Inference 又比一般 Web Application 更特殊。 如果只是看 CPU 使用率，可能根本看不出 GPU LLM Service 已經開始塞車。Google Cloud 目前針對 GKE 上的 GPU LLM inference，也建議考慮 Queue Size、Batch Size、KV Cache 使用率與 Latency 等更貼近模型服務的指標。Google Cloud 最新的 GKE inference 文件現在甚至提供以 NTPOT / TTFT latency 作為 HPA scaling threshold 的方式，代表 AI inference 的 Scaling 已經不只是傳統 CPU/Memory Autoscaling。 這讓我開始理解： AI Autoscaling 不是單純「CPU 超過 80% 就加機器」，而是要知道模型服務真正的瓶頸在哪裡。 所以問題來了： 如果 GPU 已經接近滿載，但 CPU 看起來還很正常，AI Service 到底應該依據什麼指標決定要不要擴容？ 到底要什麼時候擴容？ 這也是《AI Infrastructure 實戰：AI Demo 為什麼上不了 Production？》中，我希望從 Kubernetes、GPU 與 AI Inference 的角度一起思考的問題。Google...

  我有多年 IT 技術與跨域學習經驗，現在把 AI、Cloud、Infrastructure 串起來。 為什麼 AI 上 Production 後，開始需要 Kubernetes？ Day 19 我談到 Docker Image 做好，為什麼還不能直接上 Production？即使Docker Image 做好，並不代表 AI Service 已經準備好 Production。 那麼下一個問題就是： 如果一個 Container 不夠了，誰來管理它？ 如果今天只是自己測試，一個 Docker Container 跑起來可能就已經足夠。但當 AI Service 開始真正面對使用者，問題會開始增加。如果 Container 只是單一個服務，當它需要多人使用、故障恢復、更新與擴展時，誰來管理這些 Container？ Container 掛掉怎麼辦？需要同時執行多個 Instance 時怎麼辦？流量增加時要不要增加服務數量？更新版本時，能不能降低服務中斷的風險？ 我自己從 Docker 一路接觸到 Kubernetes 後，開始理解 Kubernetes 真正吸引我的地方，不只是「可以跑 Container」，而是它開始替我們管理 Container 的生命週期與 Desired State 。 Kubernetes Deployment 可以管理多個 Pod 副本，而 Service 則提供穩定的網路端點，讓使用者不需要直接知道背後究竟是哪一個 Pod 在處理請求。當 Pod 發生變化時，Service 仍然可以作為對外的入口。 這讓我開始理解： Docker 解決的是「怎麼把 AI Application 打包」，而 Kubernetes 開始處理的是「怎麼讓這些 Application 持續運作」。 而到了 AI Inference，還會進一步遇到 GPU 資源、Latency、Throughput、Scaling 與成本等問題。Google Cloud 現行 GKE AI 文件也把 Deployment、Service、Scaling 與 Monitoring 視為 AI inference deployment 的重要環節。Google Cloud 目前的 GKE AI inference 文件也是把 Deployment、Service、Scali...

  我有多年 IT 技術與跨域學習經驗，現在把 AI、Cloud、Infrastructure 串起來。 如果Docker Image 做好了，為什麼還不能直接上 Production？ 前幾天一路從 AI Environment、Dependency、GPU Runtime 談到 Docker。當我終於可以把 AI Application 打包成 Container Image 後，很容易產生一個想法： 「現在應該可以直接部署了吧？」 但真正開始思考 Production 後，我發現 Container Image 只是把 Application 準備好了，並不代表服務已經準備好了。 如果今天只有自己測試，一個 Container 跑起來可能就夠了。但當真的有使用者開始呼叫 AI Service，就會出現新的問題：服務要放在哪裡？如果 Container 掛掉怎麼辦？同時有很多請求時怎麼處理？如果需要 GPU，哪一台機器應該執行它？更新版本時，又要怎麼避免整個服務中斷？ 我自己一路從 Cloud、Docker 到 Kubernetes 的實作過程中，慢慢發現， 「把程式跑起來」和「把服務部署起來」其實是兩種不同的工程問題。 Kubernetes 的 Deployment 就是其中一個重要概念：Kubernetes 官方把 Deployment 定義為管理 Pods 與 ReplicaSets、進行宣告式更新的機制，它可以描述應該執行多少個 Pod，以及如何更新這些應用程式實例；而在 GKE 的 AI inference 架構中，還需要進一步處理 Service、GPU、Scaling 與 Monitoring。另外，Google Cloud 現行 GKE AI 文件則把 AI inference deployment 拆成 Containerize model → build Cluster → Deployment → Service → Scaling/Monitoring。 所以問題來了： 如果 Docker 解決的是「我的 AI 可以被打包」，那麼誰負責讓這個 AI Service 持續、穩定地被使用者使用？ 這也是《AI Infrastructure 實戰：AI Demo 為什麼上不了 Production？》接下來要從 Container 走向...

  我有多年 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 還必...

  我有多年 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 化，到了另一台...

  我有多年 IT 技術與跨域學習經驗，現在把 AI、Cloud、Infrastructure 串起來。 如果有requirements.txt 真的能讓 AI 環境重現嗎？ 前一天談到 AI 專案需要固定 Code、Model、Environment 與 Configuration，但真正開始整理 Python 專案時，很快就會遇到一個熟悉的檔案：requirements.txt。 很多人會把它當成「把套件列出來」的清單，但我在實作 AI/ML 專案後，逐漸發現，Dependency 管理其實也是 Reproducibility 的一部分。「Reproducibility」不只是概念，實際是一個工程師每天真的都會碰到的東西。 例如同樣執行 pip install ，如果套件沒有明確固定版本，幾個月後重新安裝時，取得的版本可能已經不同；而某個底層套件更新後，也可能連帶改變其他套件的相依關係。Python Packaging 官方也說明，requirements files 常被用來列出完整環境的具體版本，以協助重複安裝。 我自己越接觸 AI Infrastructure，越覺得「可以安裝」與「可以重現」是兩回事。今天能成功安裝，只代表現在的環境成立；真正的挑戰是半年後，另一台機器能不能建立出相近的環境。 所以問題來了： requirements.txt 已經固定套件版本了，真的就足以讓一個 AI 專案完整重現嗎？ 這也是《AI Infrastructure 實戰：AI Demo 為什麼上不了 Production？》中，我開始思考 Dependency、Runtime 與 Container 如何一起管理的原因。Docker 官方的 Python 範例也直接使用 pinned dependencies。Dependency 管理本身就是 AI Reproducibility 的一部分。Docker 官方目前也強調 reproducible build 不只涉及 Python dependencies，還包含 Base Image、Git、遠端檔案等 build inputs；甚至建議以 immutable digest 固定 Image。 例如前幾天cursor的f5模型被大家瘋狂的刷BUG免費使用，如果你是該團隊或公司真的敢讓 AI 環境重現這種BUG嗎？...

我有多年 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，而...

  我有多年 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 技術」進入真正 Prod...

  我有多年 IT 技術與跨域學習經驗，現在把 AI、Cloud、Infrastructure 串起來。 Docker 真的能解決「在我的電腦可以跑」嗎？ Day 12 我談到一個 AI 開發很常見的問題：「AI 在我的電腦可以跑，為什麼換一台電腦就不行？」 前幾天的文章分享幾個問題與每日觀點，當問題一路追下去，就會遇到 Docker。 我以前接觸 Docker 時，最直覺的理解是：「把程式裝進 Container 裡。」但Docker 對 AI 的價值，不只是「打包程式」，真正從 AI Infrastructure 的角度思考後，我才發現 Docker 更重要的價值，其實是把原本散落在開發環境中的程式、Runtime、Libraries 與 Dependencies，整理成一個可以被建立、分享與部署的環境。Docker 官方也將 Container 定義為包含應用程式及其 dependencies 的標準化執行單位。Container image 則是這個可分享、可部署環境的標準化套件。 對 AI 來說，這件事情尤其重要。Python 版本、Framework、套件、系統 Libraries 與 GPU 相關 Runtime，只要其中一環不同，就可能讓原本成功的 Demo 無法重現。所以把AI Demo用 DOCKER把執行環境變成可以管理、分享與部署的單位。 因此我開始把 Docker 看成 AI Application 與 Infrastructure 之間的一座橋：不是單純「把程式裝進去」，而是嘗試把執行環境也變成可以被管理與交付的東西。Container 的核心就是：把程式與所需 dependencies、runtime、libraries 等一起封裝，讓它能在不同環境中較一致地執行。 但這裡又出現一個問題： 如果 Docker 可以把 AI 的環境封裝起來，那麼只要有 Dockerfile，就真的能保證任何地方都可以重現同一個 AI 環境嗎？ 這也是《AI Infrastructure 實戰：AI Demo 為什麼上不了 Production？》接下來要繼續拆解的問題。 關於作者 我是一名 AI × Infrastructure Solution / Integration 技術實作者，專注於 AI、MLOps、Cloud、Docker、Kube...