發表文章

Day 09 如果模型不變，為什麼 Context 越長越吃 VRAM？

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

Day 08 如果模型越大，就一定需要越大的 GPU 嗎？

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

Day 07 如果把記憶體當股票買，為什麼 AI 一直在談 VRAM呢？

  我有多年 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等，隨著更多的專家參與，未來會有更新的模型架講和推理框架等，還有霍爾定律？等等。 當然我寫的內容僅作一些客觀的分析在鐵人文上，也在新書上，發文也不...
張貼留言
閱讀完整內容

Day 06 如果AI一問就懂，那AI 到底需要什麼 GPU？

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

Day 05 如果AI Demo 成功，不代表 AI 專案成功，因為AI Engineer 的價值，不只是會使用 AI AGNET

 我有多年 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 整合起來」。 那麼問題來了： 當一個 ...
張貼留言
閱讀完整內容

Day 04 如果AI Engineer 不只是會呼叫 LLM API，那我為什麼開始研究 AI 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...
張貼留言
閱讀完整內容

2026 iThome 鐵人賽 Day 03 如果我已經先跑多 AI Agent了，我為什麼開始研究 AI Infrastructure？

  如果企業已經成功做出 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來，主要是看去年也沒出新書，還正在寫一本新書中，沒貼上連結不算廣告應該還好，目前寫到進度七章(一半了)
張貼留言
閱讀完整內容