文章目錄
原來整理 GPU，也是在做裝箱演算法
最近在研究本地 AI 推理環境時，遇到一個非常有趣的問題。
我的測試主機配置了三張 RTX 3060 12GB 顯示卡。其中兩張透過 PCIe x16 運作，另一張則作為亮機卡使用，只連接 PCIe x4。
乍看之下，總共有 36GB VRAM 可供運用。然而在實際部署大型語言模型時，事情遠比想像中複雜。
有些模型可以獨立運行於單張 GPU；有些模型則需要跨兩張 GPU 分攤權重；還有些模型雖然容量不大，卻需要與其他服務共同分享有限的記憶體空間。
這讓我開始思考一個問題：
如何讓有限的 GPU 資源，發揮最大的模型部署效益？
Bin Packing：經典的裝箱問題
深入研究之後，我發現自己面對的其實是一個經典的電腦科學問題：Bin Packing（裝箱問題）。
所謂裝箱問題，可以用生活中的行李打包來理解。
- 每張 GPU 就像一個行李箱。
- 每個 AI 模型就是一件行李。
- GPU VRAM 就是行李箱容量。
- 模型大小則是行李體積。
目標是在不超過容量限制的前提下，把所有行李放進有限的箱子裡，並盡可能提高空間利用率。
這看似簡單，實際上卻是著名的 NP-Hard 問題之一。
真實世界比數學題更複雜
如果只是比較模型大小與 VRAM 容量，問題其實不難。
然而在實際部署環境中，還會出現許多額外限制：
- 某些模型禁止部署於亮機卡。
- 某些模型必須跨兩張 GPU 運行。
- 不同 PCIe 插槽具有不同頻寬。
- 部分服務需要優先啟動。
- 部分服務適合共享同一張 GPU。
例如 Embedding 模型通常較小且負載穩定，因此適合配置於亮機卡。
而大型推理模型則更適合使用完整 PCIe x16 頻寬的 GPU，甚至同時使用兩張顯示卡共同承載。
從 AI 模型部署到 GPU Scheduler
隨著需求增加，我開始設計一套簡化版 GPU Scheduler。
它會根據模型大小、GPU 容量與部署限制，自動完成以下工作：
- 分析模型需求。
- 計算最佳 GPU 配置。
- 自動產生服務啟動順序。
- 避免 VRAM 超額配置。
- 輸出完整部署計畫。
從某種角度來看，這其實已經與 Kubernetes、Nomad 或雲端資源調度系統有幾分類似。
只不過被調度的對象不再是伺服器節點，而是 GPU。
工程的樂趣就在這裡
很多時候，我們以為自己正在研究某個特定技術。
但當持續深入之後，往往會接觸到更底層的原理。
原本只是想讓大型語言模型順利運行。
最後卻一路接觸到演算法、排程理論、資源管理與系統架構設計。
這也是工程工作最吸引人的地方。
每個真實世界的問題背後，都藏著值得探索的知識體系。
而每一次優化，都是一次理解世界運作方式的機會。
延伸思考：
當我們談論 AI 時，許多人關注的是模型本身。
但在實務環境中，如何有效配置 GPU、安排推理服務與管理系統資源，往往同樣重要。
畢竟，再強大的模型，也需要一個好的資源調度策略，才能真正發揮價值。
Comments