MiniCPM LES 將 35B MoE 帶到手機，無需限制專家模型

MiniCPM 表示，其 LES 排程技術可協助一個 350 億參數模型在 iPhone 18 Pro Max 上以每秒 20.51 個 token 的速度生成內容。MiniCPM LES 解決了一項特定障礙：在不限制模型哪些部分可參與運算的情況下，足夠迅速地將模型權重載入記憶體。

這個分別對 MoE（專家混合模型）尤為重要。這種架構會啟用經挑選的參數群組，而不是為每個 token 使用整個模型。MiniCPM-V 4.7 的 35B-A3B 名稱，表示約有 350 億個總參數及 30 億個活躍參數。較低的活躍運算量，並不代表毋須儲存及存取其餘權重。

核心競爭在於：一方面保留動態專家模型選擇，另一方面減少載入延遲。Apple 較早前有關以快閃儲存為基礎的推理研究提供了一個實用參考點：儲存裝置可擴展有限的記憶體，但資料搬移需要審慎管理。MiniCPM 的貢獻，是在這個更廣泛的問題中針對專家模型排程。其已公開結果亦需要審慎歸因：最高的手機速度結合了多項優化，而「無損」亦需要比標題所暗示更狹義的理解。

MiniCPM LES 將專家模型載入轉化為排程問題

真正重要的改變，是嘗試在減少等待權重所花時間的同時，保留模型原有的專家模型選擇。

團隊的 35B 模型卡描述了一種保留 token 層級路由的部署方法；這個流程會為每個生成的 token 選擇專家模型。該模型卡亦報告另一項結果：在 iPhone 17 Pro Max 上，以約 3 GB 記憶體達到每秒超過 13 個 token。

這項較早的手機結果應與較新的 iPhone 18 Pro Max 基準測試分開看待。兩者涉及不同裝置及有記錄的配置。將它們視為可互換的結果，會模糊公開證據實際能證明甚麼。

LES 即 Lookahead Expert Scheduling，是一個預判下一個模型層需要哪些專家模型的系統。其目的在於將載入工作提前。這項預測有助安排運算，但不會取代模型最終的專家模型選擇。

從應用程式開發者的角度考慮這個部署問題。一個助理即使有足夠運算能力生成答案，仍可能因下一項操作缺少必要權重而反應緩慢。當算術運算正在等待資料時，單純加快算術速度幫助不大。

將每個專家模型都保留在工作記憶體中，可避免這種特定延遲，但需要更多記憶體。將權重保留在儲存裝置中，可減少常駐佔用空間，卻會引入載入工作。限制可用專家模型可簡化存取，但可能改變產生答案的運算過程。

MiniCPM 提出的路徑會保留對完整專家模型池的存取，並管理權重何時抵達。這帶來不同的工程目標：問題變成必要資料能否在正在進行的運算期間及時抵達。

這正是這項排程公告值得在模型規模標題以外獲得關注的原因。手機上的龐大參數數量，本身幾乎無法說明回應速度。載入與執行的安排，決定這種能力能否支援互動式應用程式。

對用戶而言，分別會體現為流暢度。一個開始生成文字後又不斷停頓的答案，與輸出較穩定的答案感覺截然不同。平均生成速度捕捉到部分體驗，但延遲出現的次序同樣重要。

因此，實際意義取決於 runtime，即負責執行模型的軟件。單靠模型權重，無法證明每個相容應用程式都會複製相同行為。相關部署涵蓋模型、儲存安排、排程實作及數值配置。

這個整合系統才是該說法真正的主題。它為調查提供具體基礎，毋須接受發佈內容附帶的每項誇張描述。

保留專家模型選擇，為流動部署捷徑帶來壓力

直接壓力落在那些透過縮窄模型可用專家模型池來換取速度的部署策略上。

當記憶體和載入時間主導應用程式的資源預算時，限制專家模型看似很有吸引力。可用權重較少，意味著可能需要載入的內容也較少。困難在於，影響專家模型可用性的優化也可能影響模型行為。

這令開發者需要明確作出一項決定：他們是在優化原有模型的執行方式，還是在部署一條修改過的運算路徑？兩種做法都值得評估，但其品質主張需要不同證據。

排程系統承諾帶來一種有用的分隔。開發者可在保持模型選擇機制不變的情況下，研究執行效率。這讓人較容易辨識某項改變影響的是速度、答案品質，還是兩者皆然。

這也改變了與較小模型的比較。一個可完全留在記憶體中的緊湊模型，可能提供較簡單的部署路徑。一個以串流方式載入的較大模型，則需要透過在相關任務上取得更佳結果，來證明其額外儲存及 runtime 複雜度合理。

兩條路徑都不能單憑參數數量取勝。一個從熟悉文件中擷取簡短欄位的應用程式，可能比起更廣泛的推理能力，更受惠於可預測的延遲。一個解讀陌生圖表的系統，則可能更重視答案品質。

這些是部署情境，並非 MiniCPM 已驗證的客戶成果。它們說明了為何同一基準測試可以支持不同的產品決策。其價值取決於用戶提出甚麼問題，以及應用程式可容忍哪些失敗。

歷史比較同樣具啟發性。Apple 的快閃儲存推理研究探討如何透過選擇性載入及更有效率的儲存存取，讓模型在超出可用工作記憶體的情況下運作。其方法與 LES 不同，但共同約束是資料搬移。

這個先例適當地限制了新穎性的說法。利用快閃儲存支援更大模型，已有既定研究歷史。正在檢視的具體貢獻，是預判專家模型需求及協調其執行。

對流動硬件團隊而言，這個框架會將注意力重新導向整條記憶體與儲存路徑。運算能力仍然重要，但部署可能在到達算術極限前就停滯。孤立評估處理器會忽略這種可能性。

對應用程式團隊而言，這帶來一項採購問題。即使裝置具備吸引人的運算規格，仍須針對預期 runtime 及工作負載進行測試。儲存行為、可用記憶體及運作條件，都會成為應用程式效能特徵的一部分。

因此，競爭含意是一項工程要求，而非已宣告的市場勝利。替代方案需要展示在可比條件下，如何平衡品質、回應速度與資源使用。MiniCPM 也需要符合相同標準。

若這種排程方法能可靠地重現，限制專家模型便更難被視為理所當然的必要措施。它仍是一項設計選擇，其品質代價及效能收益應該清楚可見。

MiniCPM LES 如何在保留路由的同時隱藏載入延遲

LES 使用預測來準備運算，而實際路由器仍負責選擇需要執行的專家模型。

官方的專家模型排程文件描述跨層預測及隨後的預取，即在執行抵達前先載入可能需要的權重。正確預判的專家模型會先執行，其他必需的專家模型則會在該運算進行期間同步載入。

因此，預測失誤會帶來額外等待，而不是容許略過所需的專家模型。這個分別說明團隊所稱的無損排程：它關乎保留專家模型參與，而非假定預測總會符合最終選擇。

文件亦描述了將權重連續排列、減少零散讀取，以及按層套用混合精度。量化，即以較低數值精度表示權重，可降低儲存及傳輸需求。這些改變針對載入問題的不同部分。

這個機制帶來數項值得探討的含意，但仍需要在實際部署中量度。單靠預測準確度無法決定總體收益。一項即使正確、卻太遲抵達的預測，可能只節省很少等待時間。

同樣地，提早載入正確權重，只有在裝置能重疊進行有效工作時才有幫助。若另一種資源成為限制因素，同一個排程器可能帶來不同收益。效能屬於完整的執行環境。

不正確的預測也值得關注。即使不改變專家模型選擇，預取不必要的內容仍會消耗資源。關鍵問題是，在具代表性的請求中，所避免的延遲是否超過這些額外工作。

這令工作負載選擇成為評估核心。基準測試應揭示排程表現良好的情況，以及它遇到困難的情況。沒有這種分佈的平均值，可能掩蓋影響應用程式可靠性的模式。

例如，文件助理可能在一次工作階段中遇到熟悉版面，另一次則遇到不尋常的視覺結構。評估者應研究這些改變會否影響回應速度。這個機制為提出問題提供理由，但並不確立答案。

這種方法亦區分兩種讀者容易混淆的預測。專家模型預取會預判即將進行的運算需要哪些權重。推測式解碼則會先草擬候選輸出 token，供稍後驗證，關乎的是生成過程本身。

MiniCPM 將 DSpark 整合為其推測式元件。這帶來另一個提升吞吐量的機會，但亦令歸因更為重要。若將加速效果籠統歸因於 LES，當中可能包含排程、儲存存取、數值表示及 token 草擬的貢獻。

對開發者而言，概念優勢已足夠清晰，值得測試：保留必須完成的工作，再重新安排準備與執行，以減少閒置時間。實際挑戰在於，如何令這種重新安排在裝置的真實限制下產生效益。

這比聲稱一個大型模型只是能塞進小型記憶體配置，提出了更強而且更具體的主張。它指出實作要針對的等待時間，以及聲稱保留的模型行為。

20.51 個 token 的結果結合多項優化

已公開的手機結果屬於完整優化堆疊，而非單靠前瞻排程。

OpenBMB 的裝置端基準測試列出 iPhone 18 Pro Max 配備 12 GB 裝置記憶體。詳細結果顯示，基準版本的速度為每秒 3.38 個 token。前瞻排程可達 6.57；加入額外的排程及載入改動後可達 11.34。

混合精度量化把公布結果提升至每秒 17.16 個 token。加入 DSpark 後可達 20.51，即為基準版本的 6.07 倍。相應的全面優化 iPad Pro M4 結果為每秒 17.39 個 token。

這些數字支持一項具體解讀：多個階段共同促成結果。它們並不支持把整體加速描述為單純由專家預測所帶來的效果。希望重現標題數字的開發者，需要取得每個階段相關的設定。

基準版本同樣值得仔細檢視。與沒有這些優化的實作作比較，可以證明相對該實作有所改善；但不會自動證明其優於所有其他執行時間環境或部署方式。

這是系統基準測試中常見的解讀問題。很高的相對增幅可以與不高的起點並存。讀者需要同時了解絕對結果，以及清晰說明哪些部分有所改變。

手機的總記憶體亦回答了與模型所報工作記憶體用量不同的問題。裝置容量描述硬件環境；應用程式記憶體則描述在該環境中所消耗的資源，並受量度方法影響。

永久儲存空間帶來另一個層面。官方的量化模型檔案列出 Q4_K_M 版本為 21.2 GB。該列表說明，低常駐記憶體的說法絕不應理解為下載容量同樣很小。

檔案列表並不能證明這個確切工件產生了所有已發表的基準測試結果。仍有必要將基準測試與其精確的權重檔案配對。否則，開發者可能會在相同模型名稱下比較不同的數值表示方式。

這項區分對產品有直接影響。流動應用程式必須兼顧安裝、模型更新、可用儲存空間及啟動行為。即使某個設定在準備完成後可高效生成內容，在生成開始前仍須提供可接受的體驗。

解碼速度量度的是解碼開始後的輸出生成速度。不應把它視為從提交圖片到收到有用答案之間的完整時間。輸入處理及準備工作需要各自量度。

同樣地，token 是模型使用的單位，並非固定數量的英文單字。吞吐量數字是在既定條件下作技術比較之用，並不能直接轉化為普遍的閱讀或說話體驗。

因此，所報結果具意義，但有其界限。它顯示團隊所稱其整合實作能在指定硬件上達到的表現。獨立測試應判定這項結果如何轉移至真實的應用程式使用情境。

「無損」需要明確的參考基準

保留專家路由支持一項狹義技術主張；它並不能證明在每種精度設定、任務及裝置上均有完全相同的行為。

對排程描述最有力的解讀關乎選擇。所需的專家仍然符合資格，而預測失誤不會令它們被排除於運算之外。這項特性處理了因限制可用專家池而引入的一項特定品質風險。

完整的流動部署帶來額外問題。量化會改變權重表示方式。因此，適當的品質比較需要識別哪個參考模型及數值設定構成基準。

關於保留路由的主張，不應暗中變成與較高精度模型的每一項輸出相符的主張。這些說法涉及不同特性。評估者需要與各項特性相應的證據。

同樣地，保留一個生成程序並不能證明其答案正確。模型可以按預期執行，卻仍可能誤讀圖表、誤解要求或虛構細節。執行時保真度及任務準確度需要分開評估。

在本分析審閱的來源中，未能確認有人獨立重現這項手機基準測試的標題結果。這項限制不會令所報結果失效，但會決定讀者應以多大信心從中作出推論。

同樣的審慎態度亦適用於公司「首創」的說法。要確立優先性，需要明確的比較集合及一致的定義。「流暢」、「即時」及「無損」等詞彙，必須先有可量度的界限，才可支持普遍排名。

即時性尤其取決於應用程式。串流文字答案可容忍的延遲，可能會中斷即時互動。技術吞吐量門檻無法證明其適用於每一種介面。

較長時間的使用亦帶來另一項重要測試。評估者應量度重複請求、變動的裝置狀況及其他應用程式活動。這些是關於營運耐久性的問題，而不是證明所報實作必然會劣化的證據。

答案品質測試應涵蓋用戶可辨識的失敗情況。在假設的開支流程中，這代表檢查擷取的項目是否與收據相符。在文件分析中，則代表檢查解釋是否仍以提供的頁面為依據。

更廣泛的知識工作流程還包括檢索，即為答案選取相關已儲存資料的過程。比較個人知識庫的讀者，應把該層與模型生成速度分開評估。更快的輸出無法彌補選錯來源文件的問題。

本機執行同樣需要審慎解讀。它提供一種在裝置上處理輸入的部署選項，但並不描述完成版應用程式中的每一項資料流。哪些資料留在本機，取決於應用程式架構。

這些區分使分析更嚴謹，因為主張變得可測試。問題不再是「無損流動 AI」聽起來是否合理，而是哪種行為保持不變、系統消耗哪些資源，以及哪些量度證明結果。

MiniCPM LES 為開發者提供一項可研究的具體排程主張。是否接受該主張，應取決於可重現的結果及應用程式層級的品質檢查，並讓每項結論對應實際量度的特性。

三項訊號將顯示此方法能否轉移至產品

接下來的證據應依序連結可重現性、持續使用及實作可取得性。

第一項訊號是具可識別工件及設定的獨立重現。在未來數月，有價值的結果應包括確切模型檔案、執行時間版本、提示詞及量度邊界。這些細節可讓其他開發者檢驗同一項主張。

重現不應只報告最佳一次運行結果。團隊規劃互動服務時，請求之間的差異同樣重要。一致的結果將提升信心，證明已發表的速度代表可用設定。

較低的結果需要解讀，而非立即否定。不同的權重檔案或設定或可解釋差距；在匹配條件下出現可重現的不一致，則會更直接削弱原有的效能主張。

第二項訊號是在具代表性的工作負載上進行持續測試。評估者應追蹤完整請求，從提交輸入至完成答案。他們亦應同時檢查品質及回應速度，因為更快但錯誤的輸出幾乎沒有產品價值。

這正是流動 MoE 推論從技術展示邁向應用程式決策的關鍵。一項有用的評估會顯示其效益能否在重複的文件或圖片請求中持續存在，亦會識別在哪些情況下較小的常駐模型仍較可取。

跨裝置結果將釐清適用範圍。在更多硬件上有相似表現，將支持更廣泛的適用性；若結果集中於狹窄的設定，則表示較專門的部署機會。

第三項訊號是可存取地整合所需優化堆疊。開發者需要一條清晰路徑，從已發表的權重檔案走向基準測試背後的實作。文件應清楚列明所需的執行時間及工件選擇。

這種可取得性很重要，因為相容性與同等效能是兩項不同成就。載入受支援模型，並不保證應用程式啟用了所有排程及儲存優化。重現完整設定才是相關的里程碑。

清晰的整合將強化這是可供流動應用程式重用的基礎設施之論據。即使底層技術仍然可靠，零散的指引或依賴設定的結果都會令採用更困難。

對考慮試點的團隊而言，合適的下一步是在與實際用戶請求相似的材料上進行有界評估。納入那些可揭示新增模型容量是否改善答案的困難文件及棘手圖片。量度用戶實際感受到的等候時間，並同時量度資源使用量及正確性。在評估每項優化時保持參考設定固定，讓改進仍可歸因。MiniCPM LES 值得關注，因為它提供一種在減少載入延遲的同時保留專家選擇的具體方法。在圍繞標題速度建立產品前，應先問該相同設定能否在目標流動工作流程中持續提供可靠答案。