林旺滴自由創作空間

  我有多年 IT 技術與跨域學習經驗，現在把 AI、Cloud、Infrastructure 串起來 30 天後，我終於能回答：AI Demo 為什麼上不了 Production？ 60 天前，我用一個問題開始這個系列： (30天完成後，休息了30天，其實留了1篇等著今天來發，意不意外，驚不驚喜？) AI Demo 明明可以跑，為什麼上不了 Production？ 30 天後，我的答案反而比一開始更簡單：因為「模型能跑」只是整個 AI System 的其中一層。 這 30 天，我一路從 GPU、VRAM、模型大小與 Quantization，談到 Runtime、Dependency、Docker、Kubernetes，再往 Scaling、Cost、Observability、Reliability、Security 與 AI Agent 延伸。 這也讓我重新整理自己過去從 Python、AI/ML、Cloud、Container、Kubernetes 到 LLM 與 Agent 的學習與實作經驗。 我逐漸發現，真正困難的從來不是讓一個 AI Demo 成功執行一次，而是讓它 明天還能跑、換個環境還能跑、使用者增加還能跑、發生故障能恢復，而且成本、安全與效能仍然可以被控制。 Google Cloud 最新的 Well-Architected Framework，同樣從 Operational Excellence、Security、Reliability、Cost 與 Performance 等不同面向思考真正可以長期運作的系統。 所以現在我認為： Demo 證明的是「這個想法做得到」；Production 證明的是「這套系統能持續被信任」。 但 30 天結束後，我反而想留下另一個問題： 當 AI 與 Agent 持續快速進化，我們今天認為 Production-ready 的架構，半年後還會 Production-ready 嗎？ 這也是我寫《AI Infrastructure 實戰：AI Demo 為什麼上不了 Production？》這個主題與這一本書真正想繼續探索的問題。 30 天結束了，但從 Demo 走向 Production 的實戰，才正要開始。 https://app.agentmorph.dpdns.org/ 這30天，我一路寫文章寫書...

  我有多年 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 觀念：...