林旺滴自由創作空間

我有多年 IT 技術與跨域學習經驗，現在把 AI、Cloud、Infrastructure 串起來。 AI 在我電腦上可以跑，為什麼換台電腦就壞了？ 前幾天談完 GPU、VRAM 與模型之後，我開始思考另一個很實際的問題：如果模型已經成功在我的電腦上跑起來，為什麼換一台電腦，卻可能突然不能跑？ 以前寫一般程式時，我也遇過「在我的電腦可以執行」的情況。但開始接觸 AI/ML 後，我發現這個問題更加複雜。Python 版本、套件版本、深度學習 Framework、GPU Driver、CUDA 或其他 Runtime，甚至模型檔案本身，都可能影響最後的結果。 我自己在 AI 實作過程中，也逐漸體會到： 模型能跑，不代表環境是可重現的。 如果今天把一個 AI Demo 交給另一位工程師，他卻無法在自己的環境啟動；或者從本機搬到 Cloud 後，因為 Runtime 或 Dependency 不同而出錯，那麼這個 Demo 距離 Production 其實還有一段距離。 Google Cloud 目前也強調，將模型、Inference Server 與 dependencies 一起封裝成 Container，可以建立更一致、可攜的執行環境，降低環境不一致造成的問題。或是使用colab統一線上端的demo，目的就是減少 dependency mismatch 與環境不一致造成的錯誤。 所以問題來了： 如果 AI Demo 只能在「我的電腦」上成功，那它真的算是一個可以交付的 AI 系統嗎？ 這也是《AI Infrastructure 實戰：AI Demo 為什麼上不了 Production？》接下來要討論的問題：如何讓 AI 的執行環境也成為可以被管理、複製與部署的 Infrastructure。 如果 AI Demo 只能在「colab」上成功，那它真的算是一個可以交付的 AI 系統嗎？ 關於作者 我是一名 AI × Infrastructure Solution / Integration 技術實作者，專注於 AI、MLOps、Cloud、Docker、Kubernetes、GPU、LLM 與 AI Agent 等技術的整合與落地，跨足 LLM、GPU、Docker、Kubernetes、MLOps 與 AI Agent，持續研究企業 AI 從 Prototype 到 ...

  我有多年 IT 技術與跨域學習經驗，現在把 AI、Cloud、Infrastructure 串起來。 如果用同一個 AI 模型，Training 和 Inference 為什麼需要不同的 GPU？ 前幾天一直在談 GPU、VRAM、模型大小與 Quantization(量化)，我開始發現一個很容易被忽略的問題： 同一個 AI 模型，拿來 Training 和拿來 Inference，真的需要一樣的 GPU 嗎？ 我自己接觸 AI 模型實作後，才逐漸理解兩者的工作完全不同。 Training 不只是把模型放進 GPU 裡跑，而是需要計算梯度、更新參數，過程中還會產生額外的記憶體需求，因此通常更重視 GPU 的運算能力、記憶體與多 GPU 平行處理能力。 Inference 則是模型已經訓練完成，接下來要面對的是「如何有效率地服務使用者」。這時候問題變成延遲、吞吐量、同時請求數、GPU 使用率與每次請求的成本。而Google Cloud 目前的 AI workload 指南也將 Training 與 Inference 分別描述為不同的 Infrastructure 需求。 這讓我重新思考以前「AI 就是需要一張很強的 GPU」這種想法。 真正的問題其實是： 你的 GPU 到底是在訓練模型，還是在服務模型？ 如果只是自己做模型推論，可能不需要為 Training 等級的硬體付費；但如果要大量服務使用者，又必須重新考慮 throughput、latency、batching 與成本。Google Cloud 目前的 LLM inference 最佳實務，也把 latency、throughput 與 cost-efficiency 視為不同的最佳化目標。Training 偏向高運算、高記憶體與平行處理；LLM Inference 則更重視 latency、throughput 與成本。 所以問題來了： 如果 Training 和 Inference 的需求完全不同，我們還能用「GPU 越強越好」這種方式選擇 AI Infrastructure 嗎？ 這也是《AI Infrastructure 實戰：AI Demo 為什麼上不了 Production？》中，我希望從 GPU 與 Infrastructure 的角度，帶讀者重新理解 AI 硬體選擇的原因。同一個 ...

  我有多年 IT 技術與跨域學習經驗，現在把 AI、Cloud、Infrastructure 串起來。 如果跑同一個 AI 模型，Quantization 真的是免費午餐嗎？ 前幾天談到 VRAM 與 Context Length 後，很自然會遇到下一個問題：如果 GPU Memory 不夠，有沒有辦法讓模型變小？VRAM 還不夠要怎麼辦？ 答案就是 Quantization（量化）。 第一次接觸量化時，很容易把它理解成一件很單純的事情：把 FP16 變成 INT8、甚至 INT4，模型占用的記憶體變少，就可以用更小的 GPU 跑更大的模型。 但實際開始理解 AI Infrastructure 後，我發現事情沒有這麼簡單。 Google Cloud 的文件也指出，Quantization 可以降低模型的記憶體需求，甚至改善推論效能與成本，但較低的精度可能帶來模型品質下降，因此不能只看「省了多少 VRAM」。 這讓我開始重新思考「最佳化」這件事。Quantization 列為 LLM inference 的主要最佳化手段，但同時存在準確度取捨；Google 目前的文件甚至以 4-bit / 8-bit 量化作為實際部署案例。LLM inference 最佳實務也正是把 Quantization、Tensor Parallelism、Memory Optimization 放在一起討論。 如果 INT4 可以讓原本放不進 GPU 的模型跑起來，當然很有吸引力；但如果模型雖然變小了，回答品質卻明顯下降，那麼這個最佳化真的有價值嗎？ 所以我認為，Quantization 不是單純的「壓縮模型」，而是一種 Infrastructure 與模型品質之間的工程取捨 。 那麼問題來了： 如果把模型從 FP16 壓到 INT4，可以省下大量 VRAM，但可能犧牲模型品質，我們到底應該怎麼決定這個平衡點？ 這也是《AI Infrastructure 實戰：AI Demo 為什麼上不了 Production？》中，我希望從 GPU、VRAM、效能、成本與模型品質一起思考的問題。三者怎麼取捨？不同最佳化方法要依 latency、throughput、cost-efficiency 做取捨。「讓模型跑起來」和「讓模型維持足夠品質地跑起來」其實是兩個不同問題，「怎麼用合理的資源，把它...

  我有多年 IT 技術與跨域學習經驗，現在把 AI、Cloud、Infrastructure 串起來。 昨日談問到如果模型越大，就一定需要越大的 GPU 嗎？今日來談談 如果模型不變，為什麼 Context 越長越吃 VRAM？ 前幾天談到 GPU 與 VRAM 時，我開始思考一個問題：如果模型本身沒有變大，為什麼只把 Context Length 拉長，GPU 的記憶體需求也會跟著增加？ 實際接觸 LLM 後，我才發現，模型權重並不是 GPU 唯一需要存放的東西。當模型處理越來越長的輸入內容時，推論過程還需要保存 KV Cache，而 Context Length 越長，需要保存的資訊也越多。 這讓我在理解 LLM Infrastructure 時有一個很重要的體會： 「模型大小」和「實際服務所需要的 GPU Memory」其實是兩件不同的事情。 如果今天只是自己測試一個模型，短 Context 可能完全沒有問題；但到了 Production，同時有多個使用者、每個請求又帶著大量文件或長對話時，KV Cache 可能迅速成為 GPU Memory 的重要負擔。Google Cloud 的 GKE 文件也指出，KV Cache 會隨 Context Length 與同時處理的請求數增加。 所以問題來了： 如果模型本身沒有變大，只是讓它「記得更多」，為什麼 GPU 就可能開始不夠用了？ 這也是《AI Infrastructure 實戰：AI Demo 為什麼上不了 Production？》中，我希望帶讀者理解的重要觀念：AI Infrastructure 不能只看模型有幾 B，還必須理解實際推論時的 Memory 使用方式。Production 的 VRAM 不只是「模型權重」。KV Cache、Context Length、Batch Size 、Model Weights、Overhead、Activations都列為 GPU accelerator memory 計算的重要因素；Context 越長，KV Cache 的需求也會增加。 關於作者 我是一名 AI × Infrastructure Solution / Integration 技術實作者，專注於 AI、MLOps、Cloud、Docker、Kubernetes、GPU、LLM 與 AI A...

  我有多年 IT 技術與跨域學習經驗，現在把 AI、Cloud、Infrastructure 串起來。 如果模型越大，就一定需要越大的 GPU 嗎？ 開始接觸 LLM 後，我常聽到一句話：「模型越大越好。」 但實際測試不同模型時，我慢慢發現，模型大小只是其中一個因素，並不是唯一答案。 我曾經比較過不同大小的LLM模型，我也測試過不同的比較過量化前後的LLM模型，也觀察過它們在不同 GPU 上的表現，在本機與雲端都實際做過推論測試。有些模型雖然參數較少，卻因為 Context Length、推論方式或精度設定不同，實際需要的 VRAM 並沒有想像中少；相反地，有些模型經過量化（Quantization）後，即使參數很多，也能在有限的 GPU 資源下完成推論。 這讓我開始理解，評估 AI Infrastructure 時，不能只看「幾 B 模型」，還要一起考慮模型精度、VRAM、推論需求、使用情境與成本。 如果只追求最大的模型，可能花了更多硬體成本，卻沒有帶來相對應的效益；反而選擇更適合的模型，才更有機會兼顧效能與資源利用率。我曾經因為 VRAM 不足而必須重新選LLM模型，除了模型大小外，還要預留 GPU 記憶體給 KV Cache，因此實際所需 VRAM 往往高於單純模型權重大小。 所以我開始思考一個問題： 企業在導入 AI 時，真正應該追求的是「最大的模型」，還是「最適合需求的模型」？ 我認為，AI Infrastructure 的重點從來不是追求最高規格，而是在效能、成本與應用需求之間找到最佳平衡。這也是我在《AI Infrastructure 實戰：AI Demo 為什麼上不了 Production？》第五章想和讀者一起探討的重要觀念。選模型最怕的是不了解又選錯規格，而或是又想「永遠手動開最貴、最會推理的模型」，然後納悶為什麼又慢、額度又這麼快見底等等。而企業最終還會問：「到底應該選哪一個？」 建議先理解模型參數數量（Parameters）與資料型態（FP16、INT8、4-bit 等）如何影響 GPU 記憶體需求，把AI 模型整合進實際系統與產品的工程實踐，涵蓋模型部署、Agent 架構設計、上下文管理、評估與監控等技術環節，重點在於如何讓 AI系統在真實場景中穩定運作、可維護、可擴展(本次的鼓勵寫文的競賽主題內容)，如果有興趣明天台科大coscu...

  我有多年 IT 技術與跨域學習經驗，現在把 AI、Cloud、Infrastructure 串起來。 為什麼 AI 一直在談 VRAM呢？ 開始研究 AI Infrastructure 後，我發現大家討論 GPU 時，經常提到另一個名詞：VRAM。 一開始我也以為，只要 GPU 運算能力夠強，AI 模型自然就能跑得快。但實際測試不同 LLM、圖片影像多模態生成模型(Gemma 4等)與Google AI Studio/Gemini AI 後，我才發現，很多時候不是 GPU 不夠快，而是模型根本放不進 GPU 的記憶體。 模型參數、Context Length、Batch Size，甚至推論方式，都會影響 VRAM 的需求。有時候只是模型變大一點，或是希望一次服務更多使用者，就可能因為 VRAM 不足而無法載入，甚至需要重新思考模型選擇或部署方式。 這也讓我開始理解，GPU 的價值不只是運算速度，更重要的是它是否有足夠的 VRAM，支撐模型穩定完成推論。 所以我開始思考一個問題： AI 模型到底是因為「算力不足」而跑不起來，還是其實真正的瓶頸一直都是 VRAM？ 這也是《AI Infrastructure 實戰：AI Demo 為什麼上不了 Production？》書中第五章希望帶大家一起理解的重要觀念。當理解 VRAM 在 AI Infrastructure 中扮演的角色後，後續討論模型大小、量化（Quantization）、Context Length 與 GPU 選型，就會更容易理解。 GPU Memory（VRAM）是獨立於主機 RAM 的高速記憶體，是否能容納模型、支援推論工作負載，是選擇 GPU 的重要考量之一。而VRAM跟RAM的差別，想必大家也有些概念，就在近期有國外科技社群引發熱列討論的一項投資操作，如果把記憶體當股票買，討論十年後、十五年後的未來呢？ 因為人工智能產業的爆發性成長，短期已經把記憶體價格推升三到五倍了，雖然有科技發展帶來的突破，如MAC電腦的M1架構、UMA架構的機器(如SPARKPC、STRIX Halo...)、Gemini Enterprise Agent Platform等，隨著更多的專家參與，未來會有更新的模型架講和推理框架等，還有霍爾定律？等等。 當然我寫的內容僅作一些客觀的分析在鐵人文上，也在新書上，發文也不...

 我有多年 IT 技術與跨域學習經驗，現在把 AI、Cloud、Infrastructure 串起來。 談到 AI Infrastructure，很多人的第一個印象就是：「AI 需要 GPU！」 但真正開始實作之後，我反而覺得問題應該改成：**我的 AI 工作負載，到底需要什麼樣的 GPU？** 我自己在接觸 LLM、Stable Diffusion、comfyUI、N8N與不同 AI 模型時，慢慢發現 GPU 並不是單純「越高階越好」。模型大小、VRAM、Inference 或 Training、Batch Size、Context Length，以及模型是否經過 Quantization，都會影響實際的 GPU 需求。 例如，一個模型「可以載入」GPU，不代表它就適合拿來提供服務。如果 VRAM 不足，可能無法載入模型；如果多人同時使用，又可能遇到效能、延遲與資源配置問題。到了 Cloud，更不能只看 GPU 型號，還需要考慮成本、可用性與整體 Infrastructure。 這也是我實作 AI Infrastructure 後很深的一個體會：**GPU 不是 AI 的附屬硬體，而是決定 AI Application 能不能有效運作的重要 Infrastructure 關鍵元件。** 所以問題來了： **當我們準備把 AI 從 Demo 帶進 Production 時，到底應該如何選擇適合的 GPU，而不是只追求「最大、最快、最貴」的 GPU？** 這也是《AI Infrastructure 實戰：AI Demo 為什麼上不了 Production？》第五章開始深入討論的問題。我從AMD6650 8G換到6950 16G用到W7900 48G，從CPU換到NPU、電腦到工作站與伺服器。接下來，我會從 VRAM、Compute、Inference、Training 與 GPU 成本等角度，逐步拆解 AI 到底需要什麼 GPU？ 今天看到GOOGLE AI人才團隊大流失，首席科學家拉隊離開自創，昨晚看到台大陳學長，原在GOOGLE GENAI也2023年離職了，昨發了一篇上月底上海AI實驗室團隊研究聯合發表的論文閱讀的agent加記憶表現的一些主題分享，在科技紅利AI百花下，我只用AMD GPU獨練了一身工夫，也踩了一堆坑，如果AMD GPU AI一問就懂，...

 我有多年 IT 技術與跨域學習經驗，現在把 AI、Cloud、Infrastructure 串起來。 實做 AI Demo 的時候，我們通常會先問一個問題：「它能不能跑？」 模型成功載入、Prompt 有結果、畫面可以展示，甚至可以讓使用者輸入問題並得到漂亮的回答，這時候很容易產生一種「專案成功了」的感覺。現在可能只需要幾個 Prompt 或幾行程式架構就能讓AI AGENT自動逐步完成。這也讓我開始思考：當 AI與 AI AGENT越來越會寫程式，工程師真正的價值會變成什麼？ 但我在接觸 AI Infrastructure 的過程中，開始發現： AI Demo 成功，其實只代表 AI Prototype 通過了第一個關卡而已。一個 AI 專案可能同時涉及模型、資料、API、GPU、Runtime、Container、Cloud 與使用者需求。如果只熟悉其中一個環節，往往很難看見整個系統真正的問題。 當我開始從 GPU、Runtime、Docker、Cloud 與 Kubernetes 等不同層面思考 AI 系統時，才發現真正的 Production 問題完全不同。模型要部署在哪裡？GPU 資源夠不夠？多人同時使用會怎麼樣？服務故障誰會發現？如何監控效能與成本？更新模型時又要如何避免影響既有服務？ 我自己的技術學習一直不是只集中在單一領域，而是從程式開發、Python，一路接觸 Cloud、Docker、Kubernetes、GPU、AI/ML 到現在的 LLM 與 AI Agent。過程中我逐漸發現，真正困難的往往不是「某一個技術會不會用」，而是能不能理解不同技術之間如何連接？ 這些問題在第一次 AI Demo 時可能完全看不到，卻可能決定一個 AI 專案最後能不能真正被使用。 當你用的TOKEN越多，看的CODE越多，或懂的越多，或經驗越多，你會發現那些號稱打造0元企業級代理(或龍蝦或XXX)，免費的最貴！(他圖的是什麼？) 所以我現在看一個 AI 專案，不會只問「模型準不準」或「Demo 漂不漂亮」，而會進一步思考它是否具備從 Prototype 走向 Production 的條件。因此，我認為 AI 時代的工程能力，正在從「把程式寫出來」，逐漸走向「把 AI、Software 與 Infrastructure 整合起來」。 那麼問題來了： 當一個 ...

 我有多年 IT 技術與跨域學習經驗，現在把 AI、Cloud、Infrastructure 串起來。 從生成式 AI 普及之後，使用 LLM API 已經變得越來越容易。幾行程式，就可以讓模型回答問題、產生文字、產生程式碼，甚至建立一個看起來很完整的 AI Demo。 但我認為，真正的 AI Engineering 並不只是「會呼叫 API」。 我自己從程式開發實作一路接觸 Cloud、Docker、Kubernetes、GPU、AI/ML 到 LLM，最大的體會就是：當 AI 開始從個人實驗走向真正的服務，問題會從「模型能不能回答」逐漸變成「系統能不能穩定運作」。 例如模型需要多少 GPU 與 VRAM？Python 與 Runtime 是否相容？Container 如何封裝？服務部署在哪裡？多人同時使用怎麼辦？如果服務出錯，誰來監控？資料與 API 權限又該怎麼管理？ 這些問題可能不會出現在第一次 AI Demo 裡，卻很可能在 Production 階段一次出現。 所以我現在思考 AI Engineering 時，會把它看成一個跨域問題：Model 只是其中一層，真正的 AI Application 還需要 Application、Infrastructure、Deployment、Observability 與 Security。 那麼問題來了： 如果只會使用 LLM，真的就能把 AI 系統帶進 Production 嗎？ 如果AI Engineer 不只是會呼叫 LLM API，AI Engineering 是跨層整合部署、測試Prototype 走向 Production， AI Model ≠ AI Application ≠ Production AI System 那從 AI Demo 到 Production 會遇到 Infrastructure、Security、Monitoring、Testing、L aws 等問題，還有觀感、道德、倫理上的疑慮與風險或責任， 這也是我在《AI Infrastructure 實戰：AI Demo 為什麼上不了 Production？》中想深入討論的核心問題。 這幾天的觀點是我為什麼開始研究 AI Infrastructure？接下來，我會繼續從實作角度拆解這條從 AI Demo 到 Producti...

  如果企業已經成功做出 AI Demo，接下來要具備哪些 Infrastructure 能力，才能讓它真正走進 Production？ 這也是我撰寫《AI Infrastructure 實戰：AI Demo 為什麼上不了 Production？》這本書的原因。 這本書不是單純介紹某一個 AI 工具，而是希望從 Infrastructure 的角度，整理 AI 從 Prototype、Deployment 到 Production 過程中真正會遇到的許多問題。 接下來 27 天，我會一邊持續實作，一邊分享這些思考，也把這段寫書與探索 AI Infrastructure 的過程公開記錄下來。用短篇文章分享我的實作、觀察與思考，如果想完整看這個系列可以追一下與期待一下這本書，我正在努力完成這一本書，把一些內容去蕪存菁、從沉思到靈光啟發寫出更有深度的文章內容。 關於作者 我是一名 AI × Infrastructure Solution / Integration 技術實作者，專注於 AI、MLOps、Cloud、Docker、Kubernetes、GPU、LLM 與 AI Agent 等技術的整合與落地，跨足 LLM、GPU、Docker、Kubernetes、MLOps 與 AI Agent，持續研究企業 AI 從 Prototype 到 Production 所需要的工程能力。協助企業理解 AI 從 Prototype 到 Production 所需要的技術能力。 本系列同時是《AI Infrastructure 實戰：AI Demo 為什麼上不了 Production？》的延伸實戰筆記。如果想完整理解這些問題，未來可以去看這本書。敬請期待~ 本文發於2026鐵人賽, 我是原作者，自已貼一份到自已的blog來，主要是看去年也沒出新書，還正在寫一本新書中，沒貼上連結不算廣告應該還好，目前寫到進度七章(一半了)

  我有多年 IT 技術與跨域學習經驗，現在把 AI、Cloud、Infrastructure 串起來。 我發現 AI Demo 很容易，為什麼上不了 Production？ 這幾年 AI、LLM 與生成式 AI 發展非常快，使用 Google AI Studio、Gemini API 或各種開源模型，很快就能做出一個可以展示的 AI Demo。 但我越來越覺得，真正困難的問題不是「AI 能不能跑」，而是「AI 能不能成為一個可以長期運作的服務」。 三天前，看到新出了 Gemini Spark ，您的 24/7 個人人工智慧代理。Google讓Gemini Spark透過Chrome使用登入讓AI直接操作網站，Google也自7月30日起，將Spark陸續開放給另外160多個國家的Google AI Pro訂閱者(正式上Production了)。 我自己在接觸 AI AGENT、AI、GPU、Cloud、Docker、Kubernetes 與 MLOps 的過程中，開始注意到一個很有趣的落差：模型在自己的電腦上成功載入，只代表完成了 Prototype；當需求變成多人使用、資源管理、部署、監控、安全性與成本控制時，問題才真正開始出現。 這也是我開始投入 AI × Infrastructure Solution / Integration 的原因。我希望從 Infrastructure 的角度重新思考 AI，而不是只停留在「如何呼叫 LLM API」。 所以我想問一個問題： 如果 AI Demo 已經可以跑了，下一步到底需要什麼，才能真正走進 Production？ 這也是我正在撰寫《AI Infrastructure 實戰：AI Demo 為什麼上不了 Production？》時，反覆思考的核心問題。 接下來 28 天，我會用短篇文章分享我的實作、觀察與思考，從 AI Prototype 一路談到 Deployment、Cloud、Kubernetes、Monitoring 與 Production，記錄一名 AI × Infrastructure 技術實作者如何理解 AI 真正落地所需要的工程能力。 關於作者 我是一名 AI × Infrastructure Solution / Integration 技術實作者，專注於 AI、MLOps、Cloud、D...

  我有多年 IT 技術與跨域學習經驗，現在把 AI、Cloud、Infrastructure 串起來。 AI 已經可以快速完成 Demo，但真正進入 Production，問題才正式開始。 本系列以 AI Infrastructure 為核心角度，從一名 AI × Infrastructure Solution / Integration 技術實作者的角度，分享 AI 從 Prototype 到 Production 所面對的實際工程問題。我將結合 Python、LLM、GPU、Docker、Cloud、Kubernetes、MLOps、AI Agent、RAG、Monitoring 與 Security 等技術，逐步拆解模型、Runtime、Container、Infrastructure 與企業系統之間的關係。 我希望透過 30 天的短篇實作與經驗分享，讓讀者看見「會使用 AI」與「能讓 AI 上線」之間的差距，也整理自己多年 IT 與 AI 技術學習、實作與跨域整合的經驗。 本系列同時作為《AI Infrastructure 實戰：AI Demo 為什麼上不了 Production？》的延伸內容，透過公開文章介紹我的技術觀點與實作方法，並持續探索 AI 真正落地所需要的 Infrastructure 能力。 Google 現在的產品方向本身也越來越強調企業 AI Agent 的完整生命週期，包括 build、deploy、govern、optimize，以及安全、權限與企業資料整合。 上周notebooklm剛改名為gemini notebook，今天看到gemini notebook內部測試建app， 很期待未來能看到這個新功能，AI Demo 很容易，真正讓 AI 進入 Production 卻是另一回事。 關於作者 我是一名 AI × Infrastructure Solution / Integration 技術實作者，專注於 AI、MLOps、Cloud、Docker、Kubernetes、GPU、LLM 與 AI Agent 等技術的整合與落地，跨足 LLM、GPU、Docker、Kubernetes、MLOps 與 AI Agent，持續研究企業 AI 從 Prototype 到 Production 所需要的工程能力。協助企業理解 A...