我有多年 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 做取捨。「讓模型跑起來」和「讓模型維持足夠品質地跑起來」其實是兩個不同問題，「怎麼用合理的資源，把它跑得夠好、夠快、夠便宜？」

關於作者

我是一名 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？》的延伸實戰筆記。如果想完整理解這些更深的技術問題，未來可以去看這本書(書中包含了一些的範例與提示詞，特別是AMD W7900 48G的使用技術心得，這些是外面很少有的獨家踩坑經驗，未來買書真的賺到！)。敬請期待唷~