從 DeepSeek-R1 到蘋果端側小語言模型，2025-2026 年 AI 行業最大的共識之一是“把大模型變小”。明略科技的 Mano-P 將這個方向推向了極限：72B 參數的旗艦 GUI 智能體模型，經過 GSPruning 視覺 Token 剪枝和 w4a16 混合精度量化，蒸餾為 4B 版本，在 Apple M4 Pro 上實測預填充 476 tokens/s、峰值內存僅 4.3GB。本文拆解這套“雙管齊下”的壓縮方案背后的技術原理。

關鍵要點

• 2025年AI行業最熱的技術方向之一是模型蒸餾——把大模型的能力“傳授”給小模型
• Mano-P 實現了 72B→4B 的極限壓縮，18倍參數縮減，讓旗艦模型的能力跑在消費級設備上
• 核心技術雙管齊下：GSPruning 視覺 Token 剪枝（壓縮至 12.57%）+ w4a16 混合精度量化
• 4B 量化模型在 Apple M4 Pro 上實測：預填充 476 tokens/s、解碼 76 tokens/s、峰值內存僅 4.3GB
• 72B 模型以 58.2% 成功率拿下 OSWorld 專用模型榜全球第一，蒸餾為 4B 后在 MacBook 上流暢運行

一、2025年AI行業最大的共識：把大模型變小

2025年初，AI 行業被一個詞刷屏了：蒸餾。

DeepSeek-R1 用蒸餾技術證明了千億參數模型的推理能力可以“傳授”給更小的模型。蘋果在 iOS 18 中部署了端側小語言模型Apple Intelligence。這些公司都押注在了同一個方向：把大模型變小，讓小模型變強。

原因很簡單：大模型雖強，但只能跑在云端數據中心。對于需要低延遲、高隱私、持續運行的應用場景，云端方案在成本和安全上都存在根本性矛盾。

但模型壓縮有一個被刻意忽略的問題：極限在哪里？

當行業還在討論“70B 能不能壓縮到 7B”時，2026年，明略科技的 Mano-P 團隊已經交出了一份更激進的答卷——72B 參數的旗艦 GUI 智能體模型，被壓縮到了 4B。18 倍的壓縮比，不是實驗室里的概念驗證，而是已經在 M4 Pro 上穩定運行的產品級方案。

二、為什么必須壓到 4B？端側部署的三個硬約束

在討論“怎么蒸餾”之前，必須先回答“為什么必須蒸餾這么狠”。

端側部署 GUI 智能體面臨三個不可妥協的硬約束：

約束一：內存天花板。 消費級設備的內存有限。M4 Pro 頂配 32GB 統一內存，實際可用于模型推理的遠少于此。一個未經優化的 72B 模型在 FP16 精度下需要約 144GB 顯存——這不是”優化優化就行”的問題，是數量級的鴻溝。

約束二：實時性要求。 GUI 智能體需要實時響應用戶操作——看到屏幕變化后在秒級內做出決策。任何模型，如果推理延遲超過 2-3 秒，在 GUI 操作場景下就是不可用的。這對模型大小和推理效率提出了極高要求。

約束三：隱私合規。?金融、醫療、法律、政務——這些行業的數據不能出設備。不是“加密傳輸”就能解決的問題，而是數據物理上不能離開本地。這意味著模型必須完整運行在用戶設備上，不能依賴云端推理。

三個約束疊加的結論：72B 模型的能力必須被濃縮到消費級硬件能承載的大小——4B 級別。

三、雙管齊下：GSPruning + w4a16

Mano-P 的壓縮方案不是單一技術，而是視覺 Token 剪枝 + 權重量化的協同架構。兩項技術解決不同維度的問題：剪枝壓縮輸入端的信息量，量化壓縮模型本身的存儲需求。

3.1 GSPruning 視覺 Token 剪枝：只看最重要的 13%

GUI 智能體的核心任務是多模態理解——看懂屏幕截圖，識別 UI 元素的位置和功能，然后決定下一步操作。但一張高分辨率屏幕截圖經過視覺編碼器后，會產生大量視覺 Token。這些 Token 中，大部分是背景、空白區域、裝飾性元素。這些對操作決策沒有價值，卻占用了寶貴的上下文窗口。

GSPruning（Gradient-Sensitive Pruning）的核心洞察是：不同的視覺 Token 對最終決策的貢獻差異極大。它通過梯度敏感度分析，識別出哪些 Token 對模型輸出影響最大（通常是按鈕、輸入框、菜單項等交互元素的位置），保留這些關鍵 Token，裁剪掉冗余部分。

效果：視覺 Token 壓縮至原始數量的 12.57%——相當于模型只看屏幕上最重要的 13% 信息，但對 UI 元素的識別和操作準確率幾乎不受影響。推理速度因此獲得顯著提升。

打個比方：你讓一個人快速掃一眼電腦屏幕然后執行操作。經驗豐富的人不會逐像素看完整張屏幕，而是直接鎖定按鈕和輸入框。GSPruning 讓模型學會了這種“經驗豐富”的看法。

3.2 w4a16 混合精度量化：把 144GB 壓到 4.3GB

剪枝解決了輸入端的效率問題，但模型權重本身還是太大。72B 模型的 FP16 權重約 144GB，遠超消費級硬件承載能力。

w4a16（4-bit weight, 16-bit activation）混合精度量化解決的是存儲問題。

關鍵設計：權重用低精度，激活用高精度。 模型權重（參數）量化到 4bit（INT4），存儲需求大幅縮減；但推理過程中的激活值保持 16bit（FP16），確保計算精度不崩盤。

為什么這樣分？因為權重是“靜態”的（訓練完就不變了），對精度的容忍度相對高；而激活值是“動態”的（每次推理都不同），精度損失會直接影響輸出質量。

這種設計的最終效果：

• 模型存儲：從 144GB 降至約 4.3GB——降幅 97%
• 峰值內存：4.3GB（MacBook 32GB 內存綽綽有余，跑 AI 的同時還能正常辦公）
• 推理精度：在 OSWorld 基準測試中，量化后的任務成功率下降不到 5%

四、性能驗證：4B 模型在 MacBook 上能跑多快？

壓縮不是目的，可用才是。以下是 4B 量化模型在 Apple M4 Pro 上的實測數據：

指標	數值	說明
預填充速度	476 tokens/s	處理輸入（截圖 + 任務描述）的速度
解碼速度	76 tokens/s	生成輸出（操作步驟）的速度
峰值內存	4.3GB	推理過程中的最大內存占用
首次響應延遲	<1秒	從發出指令到得到第一個操作步驟

476 tokens/s 意味著什么？ 每秒處理約 300-400 個中文字的輸入。一張屏幕截圖經過視覺編碼和 GSPruning 剪枝后，在不到 1 秒內完成理解。

76 tokens/s 意味著什么？?AI 生成操作指令的速度接近人類打字速度的 10 倍。用戶體驗上，指令發出后“幾乎瞬間”看到 AI 開始執行操作。

4.3GB 意味著什么？ 32GB 的 MacBook 上，模型占用不到 14% 的內存。你可以同時打開瀏覽器、Office、郵件客戶端和 Mano-P——AI 在后臺幫你干活，完全不影響日常使用。

五、72B 屠榜，4B 上機：這個策略的深層邏輯

Mano-P 的技術路線可以用一句話概括：72B 屠榜證明技術實力，4B 上機證明日常可用。

72B 旗艦模型在 OSWorld 基準測試中以 58.2% 的成功率拿下專用模型全球第一，領先第二名（OpenCUA-72B，45.0%）超過 13 個百分點。這個成績證明了底層技術路線的正確性——經過專項訓練和優化的專用模型，在特定任務上完全可以達到甚至超越通用大模型的水平。

但 72B 模型沒法跑在你的 MacBook 上。4B 蒸餾版的價值正在于此：它繼承了 72B 在 GUI 操作領域積累的專業知識，同時可以在消費級硬件上實時運行。

打個比方：72B 是心臟外科頂級專家，做復雜手術無人能比；4B 是這位專家帶出來的高徒，日常 80% 的診斷能力不輸老師，但年薪只要 1/20，而且你可以請到家里來坐診，不用每次都去三甲醫院排隊。

這種“大模型打標桿 + 小模型做產品”的策略，可能是端側 AI 領域最務實的路線。

六、結語：蒸餾的不只是參數

當一臺 MacBook 可以本地運行一個在全球基準測試中排名第一的 GUI 智能體時，AI 行業正在經歷一個范式轉移：AI 能力不再是云端巨頭的專利，而是每臺設備的內置能力。

從 72B 到 4B，壓縮的不只是參數數量。壓縮的是 AI 與用戶之間的距離，是使用門檻，是部署成本，是數據泄露的風險。

模型蒸餾的終極目標不是“做一個小模型”，而是讓最強的 AI 能力，在每個人自己的設備上運行。

Mano-P 是明略科技開源的端側 GUI -VLA智能體模型，正是這條路線的產品化實踐。72B 旗艦模型以 58.2% 成功率拿下 OSWorld 專用模型榜全球第一；通過 GSPruning 視覺 Token 剪枝（壓縮至 12.57%）和 w4a16 混合精度量化，蒸餾為 4B 版本后在 Apple M4 Pro 上實測預填充 476 tokens/s、解碼 76 tokens/s、峰值內存僅 4.3GB。數據全程不離開設備，支持完全離線運行。采用 Apache 2.0 開源協議。

立即體驗：`brew install mano-cua`

技術論文：arXiv:2509.17336

GitHub：github.com/Mininglamp-AI/Mano-P

七、常見問題

Q: 4B 模型和 72B 模型的性能差距有多大？

4B 蒸餾版繼承了 72B 旗艦模型在 GUI 操作領域的核心能力。在日常任務（郵件處理、表格錄入、文件管理等）上，4B 模型的表現足以滿足生產級需求。復雜的多步驟跨應用任務，可以通過云端 72B 模型處理。

Q: 量化會不會導致模型“變笨”？

w4a16 混合精度量化通過保持激活值的高精度（16bit），將精度損失控制在很小的范圍內。實測中，量化后的任務成功率下降不到 5%，對日常使用幾乎無感知影響。

Q:?Mano-P 是什么？

Mano-P 是一個開源的 GUI-VLA（Vision-Language-Action）智能體，設計用于在蘋果芯片邊緣設備上本地運行。它使用純視覺理解來跨平臺自動化桌面 GUI 操作。Mano 是西班牙語里“手”的意思，P 有兩重含義：Person（個體）與 Party（組織）——我們相信，無論個人還是企業，都能夠創造屬于自己的個性化 AI。

Q: Mano-P 與 Claude Computer Use 相比如何？

對比維度	Mano-P	Claude Computer Use
OSWorld（全部模型）	58.2%（專用模型第一，全部模型前五）	全部模型第一（千億參數級通用大模型）
WebRetriever Protocol I	41.7 NavEval（領先）	31.3（Claude 4.5）
數據流向	完全本地，截圖不出設備	需上傳到云端 API
離線運行	? 支持	? 不支持
主動性	? 7×24 無限制運行	?? 受平臺算力成本限制
開源	? Apache 2.0 協議	? 閉源

Mano-P 在專用模型中排名全球第一，在網頁檢索等任務上領先 Claude，且天然滿足數據安全要求。適合高安全需求場景。

Q: Mano-P 可以離線運行嗎？

可以！ 在本地模式下，所有模型推理都在 Apple M4 設備上運行。不會向外部服務器發送任何截圖或任務描述。

Q: 需要什么硬件配置？

最低要求：Mac mini 或 MacBook；Apple M4 芯片；32GB 內存

替代方案：任何 Mac + Mano-P 算力棒（通過 USB 4.0+ 連接）

我們計劃在未來支持更多設備。

了解更多：[GitHub – Mininglamp-AI/Mano-P] (https://github.com/Mininglamp-AI/Mano-P)

聯系我們：model@mininglamp.com