發表文章

Day 11 同一個 AI 模型，Training 和 Inference 為什麼需要不同的 GPU？？

  我有多年 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 硬體選擇的原因。同一個 ...
張貼留言
閱讀完整內容

Day 10 如果跑同一個 AI 模型，Quantization 真的是免費午餐嗎？

  我有多年 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 做取捨。「讓模型跑起來」和「讓模型維持足夠品質地跑起來」其實是兩個不同問題，「怎麼用合理的資源，把它...
張貼留言
閱讀完整內容

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