邁向本地即插即用的人工智能

2026年5月17日

上週我寫了關於本地運行AI的硬件方面：為什麼內存帶寬比原始算力更重要，哪些機器值得構建，以及市場趨勢。如果錯過了，請從那裏開始，因為本文直接建立在此之上。

在追求AI獨立的過程中，硬件設定了天花板，但決定你能接近多少的是軟件。兩台擁有相同GPU、相同VRAM、相同帶寬的機器，一台運行樸素推理，另一台運行優化棧，每秒鐘的token數可能相差3-5倍。這可能意味着從5 tok/s到20-30 tok/s的差距，後者才達到可用程度。更進一步，一些技術以及軟件-模型-硬件優化實現，可能允許你在至少96GB RAM的MacBook上運行像DeepSeek-V4-Flash這樣的大模型。相同的模型、相同的硬件，不同的軟件層選擇（我覺得我們在這方面可以向視頻編碼和壓縮行業學習很多。我們必須從每一美元的硬件資源中榨取最大價值）。

上週我提出了一個新目標：創建一個在一定價格點內足夠快速地生成token的推理盒。到目前為止，我還沒有找到一個完全滿足我需求的產品。我希望這項工作的成果能讓我找到一個針對本地推理優化的硬件配置，它即插即用且價格合理，或者是一個能檢測當前硬件並建議最佳模型和配置的工具。

本文繼續這一搜索，重點介紹改進推理棧的最新技巧。

MoE vs 密集模型

在討論軟件技巧之前，有一個架構決策位於所有技巧之下，因為它改變了軟件層需要處理的內容。你可能會在本地以不錯吞吐量運行的大多數有趣模型都是混合專家（MoE）架構。Qwen3.6-35B-A3B、Qwen3-235B-A22B-250、DeepSeek-V4。命名約定告訴你結構：35B總參數，但每個token僅3B活躍。模型被劃分為專家子網絡和一個路由器，決定每個token激活哪些專家。

這類模型的主要優勢（以及為何它是對硬件影響最大的變化）在於，如果每個token只有3B/30B參數工作，你就能獲得接近3B規模推理速度，同時模型擁有30B規模知識。配合正確的服務技巧，如llama.cpp的-ngl 99 -ncmoe 99標誌（將注意力和共享權重保留在GPU上，並將冷門專家FFN層卸載到系統RAM），Qwen3.6-35B-A3B在僅8GB VRAM的RTX 3070 Ti上可達33.5 tok/s，前提是你有64GB+快速系統RAM用於卸載的專家。運行35B知識模型的底線比大多數人意識到的還要低。

主要缺點是一致性。如果你使用了足夠長時間的MoE模型，你可能經歷過我將要描述的情況。把MoE模型想象成醫院。每個患者被分診給合適的專家。但哪個專家激活取決於token。模型在一個領域可能感覺敏鋭，而在另一個領域明顯較弱，取決於激活的專家。密集模型沒有這個問題，因為每個參數每次都處理每個token。更慢、更昂貴，但完全一致。這種不一致性可能體現在工具調用循環、性能下降和災難性遺忘上。

對於推理任務、長上下文連貫性，以及任何需要模型在50,000 token上下文中保持敏鋭的任務，密集模型通常更好。這就是為什麼我始終建議在需要多次助理輪次和準確上下文保持的任何智能體任務中使用密集模型。

此外還有服務問題：當一個批次中太多token同時路由到同一個專家時，該專家的緩衝區會溢出，token被靜默丟棄。模型不會警告你這一點，情況只會惡化。密集推理沒有這種複雜性。

那麼如何在密集和MoE模型之間選擇？以下是我目前使用的實踐決策樹：

• 8GB VRAM GPU + 64GB系統RAM？MoE與專家卸載是你能運行一個有能力模型的唯一真正選擇。Qwen3.6-35B-A3B Q4或Gemma4-26B-A4B配合llama.cpp卸載適合此配置。吞吐量受CPU帶寬限制，而非GPU，因此快速DDR5系統比GPU世代更重要。
• 16–24GB VRAM（RTX 3090、RTX 4090、RTX 4080）？你有真正的選擇。密集Qwen3.6-27B Q4_K_M約16GB可容納，無需卸載，無服務複雜性，質量一致。MoE Qwen3-35B-A3B在此級別也可部分卸載。如果你的工作負載是智能體型（長上下文、工具調用、多步連貫性等），密集模型的一致性優勢值得略低的原始吞吐量（這可能像我在上一篇文章中描述的那樣痛苦）。
• 128GB+統一內存（Mac M3 Ultra、Strix Halo / Ryzen AI Max+）？這是MoE明確更好的地方。你可以在統一內存中容納整個Qwen3-235B-A22B（235B總參數，每個token 22B活躍），並在完整上下文下運行而無需任何卸載。在此級別，你可以在本地獲得前沿級能力。每個token 22B活躍參數仍能在統一內存的高帶寬池上提供強勁吞吐量。敏鋭的讀者可能會想，那為什麼你還要在自己的Strix Halo上運行Qwen3.6-27B這樣的密集模型？我們又回到了一致性問題。我正在嘗試運行長時間運行的智能體任務。隨着上下文增長，性能迅速崩潰。
• 多GPU / 192GB+ VRAM？你基本上可以運行適合你需要的任何模型。MoE全精度，無需量化。在此並行級別，路由開銷變得微不足道。

簡而言之：如果VRAM有限且系統RAM充足，選擇MoE與專家卸載。如果有足夠VRAM乾淨地容納密集模型，對於需要長上下文連貫性的任務，優先選擇密集模型。如果有大型統一內存機器，頂級MoE（如Qwen3-235B-A22B）成為你在本地能運行的最有能力選項。

幸運的是，阿里巴巴用Qwen3.6構建了這一範圍的兩端，到目前為止我一直在使用它們，並且相當滿意。MoE選項是Qwen3.6-35B-A3B。密集選項是Qwen3.6-27B。兩者運行相同的混合注意力核心，它們之間的選擇幾乎完全是硬件和工作負載問題，而非模型質量問題。

我是如何得到這些數字的？在為這一部分做研究時，我遇到了LocalMaxxing.com。這個網站是純金。它提供了不同硬件架構上的不同模型基準測試，並帶有清晰的推理引擎及其配置信息。這給了我接下來幾個月的功課，也是我這一新追求的絕佳資源。

注意力動物園

MoE/密集問題只是模型架構的一個維度。另一個是模型內部使用的注意力機制。每個變體都是對同一約束的不同回答：標準注意力產生一個N×N矩陣，其中N是序列長度。在10,000 token時，那是1億個條目，內存成本呈二次方增長。過去兩年中每一個有趣的注意力發展本質上都是試圖在不犧牲太多質量的情況下襬脱這一曲線。每個都有其自身的權衡，可能更適合不同的底層架構。

Sebastian Raschka的可視化指南是我能推薦的最佳資源來導航注意力格局。這個進展值得關注，因為每一步都揭示了不同的權衡。

• 標準多頭注意力是每個人（或者也許只是我）想到transformer中的注意力機制時想到的，每個token關注每個其他token，就這麼簡單。二次方內存，二次方計算。今天沒有人選擇它用於本地硬件；它只是衡量其他一切的標準基線。
• GQA（分組查詢注意力）是第一個實際大規模部署的修復。不是每個查詢頭維護獨立的鍵值投影，而是多個查詢頭共享一個KV對。大約節省50% KV緩存，幾乎沒有質量損失。Llama 3、Qwen3、Gemma 3都使用它。權衡很小，這就是它迅速成為默認的原因。
• MLA（多頭潛在注意力），來自DeepSeek，更深入。不是減少你保留的KV對數量，而是壓縮每個存儲的內容，保存一個潛在表示並按需重建完整KV狀態。服務起來比GQA更復雜，但在大規模下，每字節的質量優勢是真實的。DeepSeek V3和Kimi K2使用它；當你擁有吸收重建開銷的內存並想要前沿級輸出質量時，這是正確的選擇。
• SWA（滑動窗口注意力）則採取不同角度。不是壓縮緩存，而是簡單限制每個token回顧的距離。Gemma 3使用5:1的局部與全局層比例，窗口為1,024 token，並結合GQA。內存線性增長而非二次方，對於大多數實際工作負載（如代碼補全、文檔問答、聊天），質量影響極小。權衡是你確實在這些局部層上放棄了全局上下文。對於大多數任務沒問題；對於極長距離推理則重要。
• Gated DeltaNet，用於Qwen3.6-27B，更進一步：不是關注存儲的序列，而是維護一個快速權重內存，每個新token不斷更新。無論序列長度如何，內存佔用保持平坦。從4k到65k上下文只增加約800MB VRAM，而非幾GB，這意味着16GB卡從撞牆到與三倍大小的機器保持競爭力。權衡是架構複雜性，以及對於完整注意力而言微不足道的極長距離依賴，需要模型學會將其壓縮到運行中的內存狀態中。
• Mamba-2混合體（Nvidia的Nemotron Nano）是邏輯上的極致，其中大部分注意力被循環狀態機取代，內存恆定不變，與序列長度無關。對於邊緣和嵌入式硬件是正確的選擇，即使GQA也太多。當你有合適的GPU可用時，不是首選；質量上限較低，但內存下限是格局中的最低點。

這些差異在機器上體現出來。在長上下文下，使用SWA時KV緩存幾乎不動，服務引擎擁有在MHA下不會有的餘量。切換到相同上下文長度的GQA，VRAM明顯攀升。運行DeltaNet混合體，內存分佈幾乎平坦。當你將多個智能體適應固定內存預算時，模型使用的注意力變體與其參數數量一樣重要。

甚至還有一個維度我決定不在此文中討論，它值得單獨一篇文章，那就是使用哪種量化機制及其不同變體（這本身就是一個巨獸）。關於這個，請參閲我關於TurboQuant的文章。

推測解碼

幾周前，谷歌宣佈Gemma 4配備了專用的MTP起草器：小型伴侶模型，可將推理速度提升高達3倍，而不影響質量。

推測解碼解決的問題是transformer的一個根本問題。正如我們在本通訊中多次描述的，LLM自迴歸地生成文本，即一次一個token，每個token依賴於它之前的所有內容。大型模型必須為每個token執行一次完整的前向傳遞。你無法並行化生成本身。所以無論多快...（由於AI成本控制截斷）