llama.cpp MoE CPU 卸載為 GPU 傳輸提供可調校的替代方案
llama.cpp 於 11 月 7 日合併了 pull request #30966，加入針對指定專家快取未命中的 CPU 執行機制，而非一律傳輸相關專家。由 am17an 貢獻的 llama.cpp MoE CPU 卸載更新，亦引入了一個可在個別機器上調校平衡的腳本。其重要性在於提供了這項選擇，而非保證提升速度。
MoE 是 mixture of experts（專家混合）的縮寫，指模型為每個 token（即生成文字的單位）啟用指定神經網絡元件的架構。這些元件稱為專家。將常用專家保留在 GPU 記憶體中有幫助，但缺少專家仍會在某處產生額外工作。新選項改變的是完成該工作的地點。
核心競爭在於 CPU 運算與傳輸專家權重之間的取捨；權重是模型用作運算的已儲存數值。Strata 提供了一個有用的比較，因為其文件已描述如何調校這種平衡。對於運行超出顯示記憶體容量模型的人而言，實際問題是：哪一條路徑能在其實際配置上更快完成。
llama.cpp MoE CPU 卸載帶來甚麼改變
這項更新讓快取未命中成為運算與資料移動之間的排程選擇。
快取會將可重用資料保留在需要使用它的處理器附近。當所需資料不存在時，便會出現快取未命中。此處缺少的資料，屬於推論期間所需的專家；推論即模型生成回應的過程。
新行為並未消除對該專家的需求，而是提供另一種完成其運算的方式。這個分別很重要，因為避免傳輸與跳過模型運算，是本質上不同的說法。
已合併的 CPU fallback 包含作者提供的示例，說明其中取捨。使用 6,464 MiB 快取時，當 CPU 佔比由零調整至 0.95，生成速度由每秒 24.2 個 token 提升至 47.6 個 token。使用 19,392 MiB 快取時，相同設定則分別得到每秒 65.5 及 54.1 個 token。
MiB 即 mebibyte，是記憶體容量的二進制計量單位。這些結果是作者示例所報告的測量數據，並非在其他機器上獨立重現的發現。它們顯示，調校部分值得與執行機制的改變一併關注。
只看較小快取結果的讀者，會看到顯著改善。只看較大快取比較的讀者，則會看到效能倒退。兩項觀察都應納入報道，因為該設定會與其餘配置互相影響。
有用的結論比「CPU 卸載更快」更狹窄。不同的資源分配可改變哪條執行路徑較可取。一項有助於受限配置的設定，當更多專家資料留在 GPU 附近時，可能反而適得其反。
這改變了愛好者解讀最佳化聲稱的方式。一項亮眼結果可以指出值得嘗試的機制，卻不能為所有人確立預設值。當證據能說明改善出現於何處、又在何處消失時，便更有用。
這亦改變了軟件介面的責任。一旦引擎提供的選擇，其最佳值取決於機器，使用者便需要協助選擇。否則，增加彈性可能只是多了一個選錯設定的機會。
對應用程式開發者而言，這項改變應被視為另一項部署變數。它並未為使用 llama.cpp 的應用程式確立通用效能水平。應用程式仍須按自身請求模式進行評估。
這次合併的即時意義正在於：主專案現已有額外執行路徑。它是否能改善特定安裝，仍是一個需要實測回答的問題。
有限 VRAM 令傳輸時間成為效能預算的一部分
受影響最大的用戶，是在顯示記憶體與系統記憶體之間分配模型的人。
VRAM 是連接至圖像處理器的記憶體。系統 RAM 是電腦的主要工作記憶體。當一項安裝依賴兩者時，效能討論需要考慮它們之間的關係。
模型能否載入只是起點。讀者也關心答案多久才開始出現、回應輸出是否穩定，以及電腦是否仍可使用。單憑容量數字無法回答這些問題。
設想一名開發者評估本地編程助理。該助理需要讀取請求、產生回應，並處理後續修改。在不間斷生成期間測得的結果，只描述了其中一部分體驗。
這是一個說明性的部署情境，而非已報告的基準測試。其目的是指出新選項帶來關注的決策。相關問題是，改變專家執行方式是否改善了開發者的完整互動體驗。
文件分析也有類似分別。使用者可能提交大量源材料，然後提出數個簡短的後續問題。最有用的配置，應支援這種模式，而非只在另一種測試中將速度最大化。
Decode 指模型逐步生成輸出的階段。Prefill 指模型處理輸入提示的階段。這些階段值得分別測量，因為其中一個階段的改善，並不代表另一個也有所改善。
對比較硬件的買家來說，這說明不應把顯示記憶體容量視為完整的效能預測。容量仍然重要，但在該容量內運作的軟件表現同樣重要。整體配置需要仔細檢視。
對維護本地 AI 服務的人來說，壓力更直接。他們需要為所部署的設定提出站得住腳的解釋。從一套看似更快的系統複製指令，並不能證明該指令適合自己的環境。
因此，實際評估應由工作負載開始，而非由偏好的參數開始。編程工作階段、文件對話或重複服務請求，都能為測試提供目的。效能隨後便成為衡量該目的是否達成的方法。
個人實驗與共享部署之間也有分別。愛好者可以接受偶爾重新調校，視之為使用軟件的一部分。團隊則需要同事能夠重現並在結果改變時調查的設定。
這使配置紀錄變得有價值。建立 可搜尋知識庫 的團隊，可將測試條件與部署備註一併保存。紀錄應解釋工作負載與結果，而非在缺乏上下文下只儲存一條指令。
更廣泛的含意很直接：軟件可提供更多使用既有硬件的方法，但這些選擇需要證據。更多可用控制項，並不會自動帶來更好的部署。
為何運算未命中有時勝過搬移專家
關鍵比較是每條完整執行路徑所需的時間。
根據該專案的 expert cache behavior，已快取的專家會在裝置上執行。快取填滿後，--moe-cache-cpu-share 會選擇一部分未命中交由 CPU 運算。其他未命中會傳輸至裝置，而初始未命中仍會上傳以填滿快取。
文件描述了有利於 CPU 運算的條件，包括高速系統記憶體及較慢的傳輸速度。它亦提醒，pinned memory（即為裝置傳輸而保留可用的主機記憶體）可減少效益。其所述最佳值取決於機器、模型及快取大小。
這項解釋支持一個具體詮釋。這項功能處理的是取得資料的成本，以及使用資料運算的成本。單憑處理器的算術能力判斷，會忽略執行路徑的一部分。
可以把它比喻為決定在哪裏處理大型檔案。把檔案傳送到一台更快的機器，意味著運算完成前先要進行傳輸。這是否值得，取決於完整工作，而非僅取決於目的地的速度。
這個比喻有其限制，但能闡明決策。即使目的地更快，到達它需要時間時，也不保證能更早得出結果。相反，避免移動亦不保證成功，若本地處理所需時間更長。
快取增加了另一個維度，因為決策關乎缺失資料，而非平等地影響所有工作。重用行為不同的配置，會改變快取外仍需完成的工作。這正是 CPU 佔比數字需要配合周邊上下文的原因。
這亦解釋了為何快取命中率——由已快取資料處理的請求比例——並非完整目標。較高比率聽來理想，但對使用者而言，最終重要的是回應所需時間。
最佳化指標應解釋面向使用者的結果，而非取代它。若某配置改善中間測量值，卻令回應變慢，該中間測量值便無法證明這項改變合理。反過來的推理亦同樣適用。
這裏的對立面仍是資料移動與 CPU 執行。毋須將此演繹成 CPU 普遍優於 GPU 的聲稱。該更新涉及較大推論流程內的一項特定資源分配決定。
這種框架亦讓報道與模型智能改變保持區分。選擇執行位置，並非更佳推理、更強編程能力或更準確答案的證據。這些結果需要不同的評估。
因此，對低 VRAM 用戶而言，llama.cpp MoE CPU 卸載的吸引力是有條件且具體的。它提供另一種處理缺失專家工作的方式。最終回應時間決定該選項是否有用。
這項分析教訓超越此修補程式：應測量完成任務的完整路徑。元件規格可幫助建立預期，但不能代替觀察實際部署的系統。
調校腳本令配置成為可測量的決策
該腳本把執行選項轉化為建議，同時維持已測量與預測效能之間的區分。
隨附的 cache tuning script 透過重複運行伺服器，評估快取大小與 CPU 佔比。它會建立機器行為模型，並預測更多組合。其選擇規則是在最快模型結果的 5% 範圍內，優先選取最低 CPU 佔比。
程式碼亦包括一項檢查，用於驗證計時模型與觀察結果的吻合程度。若不吻合程度超過其閾值，程式便會以診斷訊息退出，而非提供一般建議。這為工具的信心程度設下有用界線。
觀察與預測之間的分別值得強調。測量結果描述一次運行期間發生的情況。預測則根據配合觀察結果的假設，估計未經測量的結果。
兩個類別本身都不足以支撐部署。測量可描述不具代表性的任務；預測亦可能錯過建立它們的條件以外的行為。有用的評估會將兩者連結至人們實際打算使用的應用程式。
該腳本的價值在於提供一個具結構的起點。用戶可以研究一項建議，而非隨意拼湊各種設定。這能減少猜測，卻不會把結果說成放諸四海皆準。
它亦令效能討論更有條理。與其問每個人應該使用多少 CPU 份額，用戶可以問該建議是否適合自己的工作負載。後者較容易研究，回答後亦更有參考價值。
Strata 提供了相關的競爭背景。其 硬件校準控制項包括專家傳輸比例及 CPU 工作執行緒調整。其文件說明如何在用戶的機器上量度設定，並保留符合條件的改進。
這說明的是方法上的相似，而非實作或效能相同。兩種描述均承認，依賴硬件的選擇會受惠於量度。兩者均未提供兩個引擎之間受控的一對一比較結果。
這項區分很重要，因為來源討論明確將這個構想與 Strata 比較。這種比較在校準層面是合理的，但不足以證明 llama.cpp 抄襲了某項特定實作，或已達到另一個引擎的速度。
對引擎維護者而言，校準亦帶來一個產品問題：有多少效能應取決於用戶是否知道有哪些控制項？即使功能如設計般運作，若需要專家才能發現，實際上仍會增加使用負擔。
對介面開發者而言，一項建議需要附帶說明。用戶應能分辨預設值、量度得出的設定與估算值。若以相同方式呈現這些類別，日後排查問題會更困難。
沒有必要承諾調校能消除複雜性。它更站得住腳的角色，是讓複雜性可被檢視。當用戶能理解其適用條件並驗證其後果時，一項建議才有價值。
這正是把執行方式變更與校準配對的更深層意義。該專案提供了一種選擇新行為的方法，而非把選擇完全留給反覆試誤。
早期熱情仍留下重要驗證缺口
已合併的功能獲得驗證；但並非所有消費級系統都已證實可全面加速。
原始的社群效能討論既有熱情，也有人要求更清晰的指引。一名評論者希望更清楚看見專家快取及傳輸瓶頸；另一人則詢問，在日常使用中應如何解讀調校器的輸出。
貢獻者的回應有適當保留。Am17an 形容該腳本會提供可能接近最佳的參數，並討論正朝向自動模式發展。這是開發方向，而非設定問題已獲解決的證明。
這些反應反映不同的成功標準。開發者可能重視新增的執行路徑；有經驗的用戶可能重視取得調校數據；安裝本機助理的人則可能只想在毋須研究兩者的情況下獲得合理表現。
這些期望可以並存，但不能互相替代。一個修補程式可以滿足第一項，同時仍須處理其餘項目。報道應保留這種區分，不應把每項改進都賦予同等的成熟度。
基準測試證據亦需要清楚界線。作者提供的例子有用，因為它們揭示了值得測試的行為。但它們不能取代獨立重現，尤其文章的核心觀點正是不同設定會有不同表現。
公平比較應在模型和工作負載不變的情況下，改變所研究的執行設定。否則，表面上的改進可能反映其他差異。這是方法學要求，並非對已發布例子的指控。
比較時，模型量化——即降低儲存權重所用的數值精度——亦應保持一致。改變它，就等於改變實驗。在同一熟悉的模型名稱下展示不同模型檔案時，同樣需要審慎。
用戶體驗需要比單看生成速度更廣泛的評估。開始時的短暫延遲與輸出期間反覆出現的停頓，對不同人士的影響各異。平均值可能掩蓋其中任何一種情況，因此報道應說明量度實際代表甚麼。
機器活動同樣值得留意。本機助理往往與其他應用程式共用同一部電腦。在其他方面閒置的系統上選出的設定，需要在助理實際運行的條件下再作檢查。
這些考慮不會否定該功能。它們界定了評估其效用所需的證據。較審慎的立場是，具潛力的機制應在相關條件下測試，才可把其收益視為普遍結論。
因此，最有價值的社群報告亦會包括不成功的結果。導致效能下降的設定有助辨識優化的邊界。缺少這些報告，讀者便更容易把有利例子誤當成規律。
目前而言，llama.cpp MoE CPU 卸載只支持一個審慎結論：用戶多了一個值得評估的選項。現有證據不足以支持建議每一個受限制系統都盡量提高 CPU 參與度。
留意可重現性、整合式調校及應用程式結果
下一階段的里程碑應顯示，這種彈性能否在日常使用中轉化為可靠效能。
第一個訊號，是在清楚描述的設定下獲得獨立重現。報告應列明確切模型檔案、軟件版本、工作負載及設定。其價值在於讓其他人能理解並重複比較。
若在受傳輸限制的設定中持續錄得收益，將加強新執行路徑的理據。結果若不一致，未必會自動否定它；反而會令更好的診斷及更具針對性的建議變得更重要。
第二個訊號，是由獨立腳本走向整合式設定協助。在 11 月 7 日的自動調校提案中，am17an 建議提供更廣泛的工具，以選擇針對特定模型的設定。貢獻者 angt 支持建立更好的基準測試基礎，並討論一項可能的快取參數指令。
這些是提案和討論，並非已推出的通用調校介面。這一狀態應保持明確。重要的發展將是提供一項實作，令相關量度更易取得，並說明其建議涵蓋甚麼。
若整合式協助推出，將加強該功能的易用性理據。若設定仍須解讀獨立輸出，有經驗的用戶仍可保有彈性；技術經驗較少的用戶則仍要承擔較高負擔。
第三個訊號，是在完整應用程式內進行評估。編碼助理及文件工具應報告設定是否改善用戶實際進行的互動。這意味著檢視回應延遲、持續使用情況，以及在真實工作階段中的表現。
應用程式層面的收益，會令這項更新比單一生成結果更具影響力。收益若微弱或不一致，則會把其相關性收窄至特定工作負載。無論哪一種結果，都會為開發者帶來比單一頭條速度數字更好的資訊。
這些訊號應按次序解讀。重現可確立機制在哪些地方有幫助；整合式調校決定用戶能否輕易取得這項好處；應用程式結果則確立它是否改善人們真正關心的體驗。
與 Strata 的比較應置於這個框架內。一項有用的未來比較，會在公開條件下就明確任務評估兩個引擎。不應由互不相關的社群結果出發，先行宣告勝者。
未來數月，最有力的證據將結合技術透明度與實際相關性。增加更多設定本身不是目標；目標是協助用戶選擇能可靠地服務其工作的配置。
對於考慮使用 llama.cpp MoE CPU 卸載的讀者，應先由部署需要解答的問題開始：它是否能縮短你的編碼工作階段、文件對話或其他經常性任務中的等待時間？保留基準、維持條件，並比較完整互動。把調校器的建議視為有待驗證的候選方案，尤其當你的工作負載與其測試不同時。對於令效能倒退的配置，應與改善效能的配置一樣謹慎分享。這些報告有助分辨廣泛有用的預設值與只適合特定機器的選項。在採用其他人的 CPU 份額設定前，先問清楚其結果實際量度了甚麼，以及該量度是否代表你自己的使用情況。
