發表文章

Day 30 如果我已經弄了一個 AI 系統，到底怎樣才算 Production-ready？？

  我有多年 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？」這個問題的起點...
張貼留言
閱讀完整內容

Day 29 如果AI Agent 接上 Tools 後，為什麼 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？》中，我認為 ...
張貼留言
閱讀完整內容

Day 28 如果AI 可以正常運作，但它真的安全嗎？

  我有多年 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...
張貼留言
閱讀完整內容

Day 27 如果AI Service 掛掉了，Production 應該怎麼辦？

  我有多年 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： 真正重要的不是保證「永遠不壞」，而是系統壞掉時，能不能知道自己壞了，...
張貼留言
閱讀完整內容

Day 26 如果AI 變慢，多加 GPU 就一定有用嗎？

  我有多年 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 觀念：...
張貼留言
閱讀完整內容

Day 25 如果AI 變慢，我該先看 GPU、Model 還是 Network？

  我有多年 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 工程思考方式。...
張貼留言
閱讀完整內容

Day 24 如果AI 上 Production 後，我到底要監控什麼？

  我有多年 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...
張貼留言
閱讀完整內容