4GB 顯示卡跑 2.8 兆參數：AirLLM 如何擊穿顯示記憶體高牆

人人都撞上的那堵牆

每個想在本地跑大模型的開發者，都會撞上同一個時刻。這不是能力問題，也不是成本問題。它是規格表上的一個數字：顯示記憶體。一個像樣的開源模型塞不進大多數人手裡的顯示卡，而慣常的解法，買一張更大的卡，價格已經漲到了離譜的地步。

於是這個領域裡堆滿了各種繞行方案。把權重量化到 4 位元。把模型的一部分挪到系統記憶體。租用別人的硬體。每種都能用，每種都有代價，每種都會以某種你必須接受的方式改變模型。然後還有 AirLLM：這個倉庫最近一直掛在 GitHub 趨勢榜前列，它的 README 裡寫著一句聽起來像是打錯字的說法，2.8 兆參數，單張 4GB 顯示卡。

這套手法到底是什麼

AirLLM 背後的思路不是把模型變小，而是不再試圖一次把整個模型都握在記憶體裡。它不追求在生成一個 token 之前把網路的每一層都裝進顯示卡，而是讓資料一層一層地流過模型，在每一塊真正被用到之前才從磁碟取出來，用完即釋放。

在任意一個瞬間，只有模型很薄的一片需要待在快速記憶體裡，其餘部分可以留在硬碟上。顯示卡從倉庫變成了工作台，模型的規模也就不再為哪台機器能跑設下硬性上限。

同一個人可以用一張很小的書桌讀完一本上千頁的書，道理一樣。你不需要把整本書攤在面前，需要的是當前這一頁，以及一個能拿到下一頁的辦法。

誠實的代價

如果讓層流過一張小顯示卡是免費的，那所有人早就這麼做了，所以這裡值得把代價說清楚。為每一個 token 都從磁碟讀取權重，它慢的程度很容易被低估。顯示卡會白白空轉，等著那些如果常駐記憶體本可以立刻用上的資料。

由此帶來的現實結果是，這類配置擅長的任務，和把模型完整載入記憶體的路子不一樣。如果你需要為一款聊天產品提供穩定的快速回應，串流就是錯的工具。如果你想偶爾跑一個非常大的模型，用你已經擁有的硬體，做一件吞吐量沒那麼重要、重點是能跑起來就行的活，那麼這筆交易就倒向你這一邊。

把它和更常見的繞行方案擺在一起看會更好理解。量化是把模型本身縮小，用一點點精度換取更小的佔用，它改變的是模型是什麼。串流則不動模型的數值，只是改變它們存放的位置。兩者不是對手，可以疊加。一個既被量化、又逐層串流載入的模型，會比單用任一種技術都更小更輕，這也是為什麼在實踐中這兩種做法常常同時出現。

還有第三項代價，宣傳得比較少：硬碟。串流載入權重意味著每一輪都要從儲存裡讀一遍，所以一旦模型裝不進記憶體，一顆慢碟立刻就成了新的瓶頸。走上這條路的人很快就會明白，真正重要的硬體不只顯示卡。在這裡，一顆高速固態硬碟對吞吐量的幫助，能頂得上多出來的幾個 GB 顯示記憶體。

互動性與可行性之間的這條分界，是大多數對比都會忽略的一點。一個在你桌上慢得像爬的模型，仍然是一個你能在自己桌上跑的模型。對於一個沒有叢集的研究者，或者一個想拿某個特定的提示詞去試某個特定巨型模型的開發者來說，這可能就夠了。

它為什麼一直上熱榜

AirLLM 並不新。它存在得夠久了，緊跟本地推理的人對它都不陌生。它反覆出現在趨勢榜上，原因和具體實作關係不大，更多是它背後那股壓力。

開源權重的模型一直在變大。如今最好的開源圖像、影片和語言模型，已經穩穩落進沒有哪張消費級顯示卡能輕鬆裝下的區間。與此同時，能裝下它們的那些大顯示記憶體顯示卡，價格不降反升，推動它的正是那場重塑整個硬體市場的需求。可運行的模型，和負擔得起的硬體上能跑的模型，兩者之間的差距一直在拉大。

任何在這道差距上頂一把的專案，哪怕做得不完美，都會不斷找到受眾。另一種可能是這樣一個世界：開源模型的前沿理論上人人可用，實際上只有擁有資料中心的人用得起。各種繞行方案，正是開源權重裡那個開放得以名實相符的方式。

它解決不了什麼

這裡有兩件不同的事容易被混為一談。在一張小顯示卡上跑大模型是記憶體問題。從大模型裡拿到有用的輸出是能力問題，兩者並不相同。一個 2.8 兆參數的模型即便透過 4GB 顯示卡串流載入，生成文字的速度依然由它的硬碟和頻寬決定，而文字的品質取決於模型本身，不是這個繞行方案能帶來的。

還有一個授權層面的問題，是技術成就碰不到的。能本地跑一個模型，和你能不能把它的權重用於你的用途，完全是兩回事。世界上再厲害的本地推理配置，也仍然受它所運行的那個模型的條款約束。

更大的意義

本地 AI 的前沿不是某一次突破，而是一長串不起眼的工程取捨：資料放在哪、什麼時候移動、你願意等多久。AirLLM 是個好例子，因為它對這筆交易坦白得近乎直白：你放棄速度，換來的是跑起一個本不該裝得下的東西。

對於越來越多把模型能做什麼看得比它做得多快更重要的人來說，這是一筆划算的交易。而對其他人來說，它提醒了一件事：這個模型需要多少 GB，既是硬體的限制，同樣也是設計上的選擇。總有某個人，在某個地方，正在尋找一張比書更小的書桌。