Select Page
Mole 教學:免費 Mac 清理工具,安裝、磁碟分析與常用命令

Mole 教學:免費 Mac 清理工具,安裝、磁碟分析與常用命令

Mac 空間快滿時,我會先找出到底是哪些資料夾變大,再決定要清快取、移除軟體,還是整理下載過的 AI 模型。

Mole 把這些工作集中在終端機裡,輸入 mo 就能用方向鍵操作,涵蓋磁碟分析、清理、解除安裝、系統維護與即時監控。

對已經使用 Homebrew、Codex 或本地模型的 Mac 使用者,Mole 很適合當作日常維護工具,它能協助回收空間、找出資源占用,但清掉檔案並不代表 CPU 會自動變快。先知道瓶頸在哪裡,才不會刪了一堆快取,最後只是讓軟體重新下載相同資料。

Mole 免費嗎,終端機版和 DMG App 差在哪裡

目前的 Mole GitHub 專案 是免費開源 CLI,採 GPL-3.0 授權。

Mole for Mac 繁體中文官網 提供的是另外一款付費原生圖形介面 App。免費開源的說法應對應 CLI,不能套用到所有同名版本。

CLI 適合用鍵盤操作、希望檢查原始碼,或要把結果交給其他程式處理的人,原生 App 則提供視覺化磁碟樹狀圖、App 管理、選單列狀態等操作介面,對不想開終端機的人更直覺,官方目前標示 App 為一次購買、終身更新,一份授權可用於兩台 Mac,實際價格和條款以購買頁為準。本文以下以免費 CLI 為主。

安裝 Mole,先確認 Homebrew 能使用

按下 Command 加空白鍵,搜尋「終端機」。如果已安裝 Homebrew,先檢查版本,再安裝 Mole。

brew --version
brew install mole
mo --version
mo

還沒裝 Homebrew,可以到 Homebrew 官網取得安裝命令。安裝完成後,照終端機顯示的 Next steps 設定環境,再重新開啟終端機。Apple Silicon 和 Intel 的安裝位置可能不同,直接照自己電腦輸出的步驟最穩。

輸入管理員密碼時,終端機通常不會顯示字元或星號,輸入完按 Enter 即可。Mole 只有在操作需要較高權限時才會提出要求,不必把每一條命令都加上 sudo。

第一次使用,我會從 Analyze 開始

先執行磁碟分析,沿著最大的資料夾往下查看。比起直接啟動清理,這一步更容易理解自己的硬碟用在哪裡。

mo analyze

也可以指定範圍,縮小到下載資料夾或外接磁碟。外接磁碟不包含在預設總覽裡,要另外指定。

mo analyze ~/Downloads
mo analyze /Volumes

使用方向鍵瀏覽,需要判斷內容時在 Finder 開啟對應位置。Analyze 內的移除操作會在確認後將所選項目移到垃圾桶,這和部分清理命令的刪除行為不同。要立即回收實際空間,還要考慮垃圾桶是否已清空。操作快捷鍵以畫面下方提示為準。

AI 模型快取很大,但它不一定是垃圾

本地 AI 工作流常會保存多個模型版本、量化格式與下載快取,依照 Hugging Face 官方快取說明,Hub 檔案快取預設位於 ~/.cache/huggingface/hub,設定過 HF_HOME 或 HF_HUB_CACHE 時則可能在別處。可以先用 Mole 查看預設快取的上層資料夾。

mo analyze ~/.cache/huggingface

模型檔值得保留與否,取決於近期是否還會使用,以及重新下載的成本。你可以先列出每個模型的用途,保留常用版本,再逐一移除已淘汰的模型。不同快取版本可能共用檔案,適合搭配模型下載工具自身的管理功能,避免只刪掉某個片段後留下不完整模型。

如果你正在比較 llama.cpp、MLX 與 Ollama 的本地推理方式,要特別留意不同工具可能各自保存權重。整理時先確認模型屬於哪個工具,才知道之後要從哪裡重新取得。

做 ComfyUI 本地影音工作流 時也一樣,模型、輸入素材和生成成果應分開管理。尚未交付的成品有保留價值,不能只因為容量大就把整個輸出目錄視為可刪快取。

Clean 清快取,先看 dry-run 結果

準備清理時,先預覽會處理哪些路徑。需要保留的快取可以加入保護清單,再執行清理。

mo clean --dry-run
mo clean --whitelist

確認預覽內容後,以下命令會實際進行清理。

mo clean

清理範圍包括符合規則的快取、日誌、暫存與已移除 App 的殘留。清理後部分軟體第一次開啟可能要重建快取或重新下載資料,這是規劃清理時間時需要考慮的成本。Mole 的保護規則可以減少誤操作,但仍要自己確認預覽清單是否包含工作需要的資料。

瀏覽器也要分清楚快取和設定。Chrome 擴充功能的存放位置和一般網頁快取用途不同,不要自行把整個 Chrome 使用者資料夾都當成垃圾刪除。

需要追查剛才做了什麼,可以查看操作紀錄。

mo history
mo history --json

Uninstall 移除 App,也檢查相關殘留

不用的軟體可以交給 Uninstall,一起檢查能明確對應到該 App 的相關檔案。先做預覽,確認選取的是正確程式與版本。

mo uninstall --dry-run

確定要解除安裝後,再執行下方命令並選取 App。

mo uninstall

如果 App 本體早已刪除,改用 mo clean 檢查殘留比較合適。同一套軟體的不同版本可能共用資料,所以「完整移除」不能理解成所有相似名稱的資料夾都應一起消失,仍在使用的共用資料需要保留。

Optimize 與 Status,分別處理維護和觀察

遇到縮圖、搜尋或系統服務異常,可以先預覽 Optimize 的維護項目。它會依系統狀況略過不適用的工作,不能把它當成每台 Mac 都會得到相同效果的加速按鈕。

mo optimize --dry-run

確認項目後才執行實際維護,需要排除的工作可用保護設定管理。

mo optimize --whitelist
mo optimize

只想了解目前 CPU、記憶體、磁碟、網路與電力狀態時,用唯讀的 Status 儀表板即可。按 q 可以離開。

mo status

對跑本地模型的人來說,可以在載入模型前後觀察記憶體壓力,再在生成內容時看 CPU 和磁碟活動。如果空間回收了,運算仍然慢,就應繼續檢查模型大小、同時執行的工作與記憶體,而不是反覆清理相同快取。

開發者可以用 Purge 整理專案產物

許多舊專案占空間,是因為 node_modules、target、build 或 dist 長期保留。Purge 會以專案為單位整理候選項目,先設定要掃描的資料夾,再做預覽。

mo purge --paths
mo purge --dry-run

看清楚清單後,實際清理使用以下命令。

mo purge

Purge 會永久刪除你確認的項目。原則上這些產物能重新建立,但自己的專案可能把手工修改內容或唯一成品放進 build 或 dist,所以仍需先核對。清掉依賴後,下一次開發也要重新安裝,應保留套件清單與 lockfile。

下載資料夾裡的舊安裝包則交給 Installer。先確認是否還需要離線重裝,再決定移除。

mo installer --dry-run

以下會進入安裝包的實際移除流程。

mo installer

Mole 常用命令速查

工作起手命令使用重點
查看空間mo analyze先瀏覽,移除需確認
查看狀態mo status唯讀監控
清理快取mo clean –dry-run先預覽,再執行 clean
移除 Appmo uninstall –dry-run先確認程式與殘留
系統維護mo optimize –dry-run先確認維護項目
專案產物mo purge –dry-run正式執行可能永久刪除
舊安裝包mo installer –dry-run先確認是否仍需保存
Mole 磁碟分析、狀態監控與清理命令速查表
先從查看與預覽開始,再依需要執行對應操作

整合 Raycast,減少每天開終端機的步驟

Mole 官方提供快速啟動器腳本,可以加入 Clean、Uninstall、Optimize、Analyze 與 Status。以下命令請逐行操作,先下載官方腳本,用 less 閱讀內容,按 q 離開閱讀畫面,確認後才執行最後一行。

curl -fsSL https://raw.githubusercontent.com/tw93/Mole/main/scripts/setup-quick-launchers.sh -o setup-mole-launchers.sh
less setup-mole-launchers.sh
bash setup-mole-launchers.sh
  1. 開啟 Raycast Settings,進入 Extensions 的 Script Commands
  2. 新增腳本目錄 ~/Library/Application Support/Raycast/script-commands
  3. 執行 Reload Script Directories 重新載入
  4. 在 Raycast 搜尋 analyze 或 status,開啟相應功能

清理指令仍然會啟動 Mole 本身的操作流程。快速啟動器的價值在於少打字,並不代表能略過對清理範圍的判斷。官方腳本在找到 Alfred 設定時,也會建立對應 workflow。

讓 Codex 協助讀取磁碟報告

Mole 已有 JSON 輸出,適合把資料交給 Codex 整理。可以請 Codex 解釋哪些資料夾占空間,以及哪些是模型、快取、安裝包或專案產物,再由自己決定下一步。

mo analyze --json ~/Documents
mo status --json
mo history --json

可以這樣下提示詞。以下是整理報告的範例,並不會自動開始刪除。

請使用 Mole 的唯讀分析與 JSON 輸出,整理我指定資料夾的空間占用。按模型檔、專案依賴、生成成果與安裝包分類,列出路徑、容量與可能用途。請保留正在使用的模型和唯一成品,先提供清理建議,等我指定項目後再執行刪除。

JSON 報告可能包含使用者名稱與專案路徑。把它交給雲端服務時,就和 Mole 本身在本機掃描是兩個不同的資料處理步驟,可以先限制分析範圍。

更新、移除與常見錯誤

用 Homebrew 安裝的版本,更新時指定 Mole 即可。

brew update
brew upgrade mole

不再需要這個工具時,用原本的套件管理方式解除安裝。

brew uninstall mole

如果用官方安裝腳本安裝,則使用 mo update 更新與 mo remove 移除工具本身。不要把 mo uninstall 和 mo remove 混在一起,前者是管理其他 App,後者是移除 Mole。

遇到 Bundled status binary not found,先確認版本與命令位置。如果原本是 Homebrew 安裝,可用以下方式重新安裝套件,恢復遺失的執行檔。

command -v mo
mo --version
brew reinstall mole

原本使用官方腳本安裝時,依錯誤訊息執行 mo update,或重新執行官方安裝流程。若電腦同時裝了兩個版本,先整理命令搜尋路徑,避免更新了一份,實際卻執行另一份。

FAQ

Mole 可以完全免費使用嗎

CLI 版可以,GitHub 專案採 GPL-3.0 開源授權。原生 Mole for Mac App 是另外的付費產品,兩者的授權和介面不同。

Mole 清理後一定會讓 Mac 變快嗎

不一定。它可以協助回收空間與處理部分維護工作,效能是否改善仍取決於磁碟剩餘空間、記憶體壓力、背景程序和實際工作負載。

Mole 有 Windows 版嗎

主要產品針對 macOS,官方 GitHub 目前另有實驗性的 windows 分支。不要把 Mac 的 Homebrew 命令與清理規則直接套到 Windows,也不要假設兩邊功能完全相同。

Analyze 和 Clean 都會刪除檔案嗎

Analyze 主要供瀏覽分析,選取移除後會確認並移到垃圾桶。Clean 會按清理規則實際刪除資料,第一次操作先使用 dry-run 預覽。

我會怎麼把 Mole 放進日常工作

第一次先跑 Analyze 和 Status,弄清楚容量與資源占用。空間不足時再預覽 Clean,需要移除 App 時用 Uninstall,舊專案交給 Purge。這樣比較容易把每次清理和實際問題對上,也能保留常用模型與工作成果。

我很喜歡 Mole 把路徑、大小與操作結果攤開的方式。對經常下載模型、建立測試專案與輸出影音素材的人,能知道硬碟裡放了什麼,比每次容量不足才四處翻資料夾方便得多。

功能與命令依 Mole 官方文件核對,原生 App 資訊可看 繁體中文官網,清理行為的保護範圍可參考 官方安全說明。

Mac 本地 AI 怎麼選?M5、M6 的記憶體、頻寬與 Agent 效能

Mac 本地 AI 怎麼選?M5、M6 的記憶體、頻寬與 Agent 效能

買 Mac 跑本地 AI,我會先考慮以下三件事:

模型能不能放進記憶體,送出長篇資料後要等多久,以及開始回答後每秒能生成多少 token。這三件事分別牽涉容量、運算能力與記憶體頻寬,不能只看晶片名稱裡的數字。

同一台電腦,短問短答很順,換成讀程式碼、查工具、反覆執行任務的 Agent 卻很慢,並不矛盾。

聊天介面讓你注意到的是持續輸出的速度,Agent 更容易暴露長輸入、多輪推理與工具等待的成本。

模型載入成功,只代表跨過容量門檻,還不代表這台機器適合你的工作流。

本文於 2026 年 9 月 6 日核對規格。Apple 已公布新款 Mac mini 與 Mac Studio,官方標示 9 月 22 日開始供貨。以下會把官方規格、推理原理與選購判斷分開,未取得的新機實測不會用推估值冒充。供貨資訊可查 Mac mini 公告與 Mac Studio 官網。

先分清 Prefill 與 Decode,才知道慢在哪裡

Prefill,預填充,是模型處理輸入內容、建立後續推理狀態的階段,系統提示詞、聊天記錄、工具定義、檢索文件與程式碼都可能算進輸入,並非只有你剛打的那一句話。長輸入通常有較大的矩陣運算需求。

Decode,解碼生成,則是在已有上下文狀態上逐步產生 token,單一請求、低批次的生成常受記憶體資料搬運限制,所以記憶體頻寬很重要,Token 不是固定的一個中文字,不能把 tokens/s 直接當成每秒中文字數。

觀察體感時,我會同時記錄 TTFT,也就是送出後到第一個 token 的時間,以及生成階段的 tokens/s,TTFT 還可能包含排隊、模型載入與服務端處理,不能把所有等待都歸因於 Prefill,Apple 的 MLX 與 M5 技術說明也分別討論提示詞處理與生成效能,兩個階段應分開比較。

記憶體容量,是門票而不是速度保證

Apple Silicon 的 CPU 與 GPU 共用統一記憶體,跑較大模型時不必完全受限於一張獨立顯示卡的顯存容量,在這規格表上的 32GB 或 128GB 並不等於模型可以獨占同樣的空間,macOS、瀏覽器、開發工具、KV cache 和推理暫存都需要預算。

估算可以從權重開始:參數數量乘上每個參數的位元數,再除以 8,以約 27B 參數、理想化 4-bit 權重計算,純權重約 13.5GB,這只是十進位容量的粗估,還沒加入量化分組資訊、部分高精度權重與執行時開銷。

32GB 能否跑某個 27B 模型,答案是「有機會,但要指定量化檔、上下文長度與框架」。只拿 27B 這個名字,無法保證長上下文與多 Agent 都順暢。先核對實際模型檔大小,再測一個完整任務,會比只看成功載入的畫面更有用。

如果想先理解不同推理工具的定位,可以參考 MLX、llama.cpp、Ollama 與其他本地推理框架比較,格式、核心實作與快取策略都會影響同一台硬體的表現。

記憶體頻寬,影響持續輸出但不是萬用答案

可以把容量想成能放多少資料,頻寬則是每秒能把多少資料送到運算單元。當低批次生成需要反覆讀取大量權重,而硬體運算能力足夠時,頻寬往往成為主要限制。

但「頻寬加倍,速度就一定加倍」只適合當理想化的直覺,實際還有量化解碼、注意力、KV cache 存取、核心效率、批次大小與模型架構,MoE 也不是每個 token 都動用全部專家權重,所以不能把所有模型都套進同一條簡單公式。

M5、M6 規格怎麼看,先看配置再看名稱

以下整理 Mac mini 技術規格與 Mac Studio 技術規格中,和本地模型最直接相關的容量與頻寬。這是規格對照,不是速度排名,也不是實測 tokens/s。

機型與配置統一記憶體記憶體頻寬
Mac mini M6 基本配置16GB153GB/s
Mac mini M6 較高記憶體配置24GB 或 32GB170GB/s
Mac mini M5 Pro24GB,可選 48GB 或 64GB307GB/s
Mac Studio M5 Max 32 核心 GPU36GB460GB/s
Mac Studio M5 Max 40 核心 GPU可選至 128GB614GB/s
Mac Studio M5 Ultra96GB,特定配置可選至 512GB1.2TB/s
M6 與 M5 系列 Mac 的統一記憶體和記憶體頻寬官方規格對照
2026 年 9 月 6 日核對,容量與頻寬不等同實測生成速度

M5 Max 的 32 核心與 40 核心 GPU 版本不只差核心數,頻寬與可選記憶體也不同,M5 Ultra 的 256GB、512GB 選項綁定更高階晶片配置,升級容量的成本可能同時包含晶片升級。選購時應核對最後的完整配置,不要把某個系列的最高值套到入門款。

供貨時間也要分開看。依 Apple 台灣的新款 Mac Studio 公告,一般配置自 9 月 22 日起供貨,512GB 統一記憶體配置則預計 10 月底推出,需要立即交付工作的團隊,應再確認實際可下單配置與交貨日期。

跑 Agent 為什麼更容易卡在等待

一個程式碼 Agent 可能先讀專案規則,再讀檔案,接著呼叫工具,最後把工具輸出帶回模型繼續判斷,每一輪都可能增加輸入,輸出卻只有一小段指令,讓「先讀懂,再動作」的成本更加明顯。

「每開一個子代理,就一定完整重算一次全部上下文」並不精確,是否能重用相同前綴,取決於服務端的 prompt cache、請求路由、模型支援與上下文是否一致,MLX LM 官方專案就提供 prompt caching 功能,實際 Agent 框架有沒有用到,仍要另外確認。

  • 把長期不變的規則放在穩定前綴,減少每輪重新排列內容
  • 只提供當前任務需要的檔案與工具,避免把整個專案一次塞進提示詞
  • 先測單 Agent,再逐步增加並行數,觀察排隊與記憶體壓力
  • 同時記錄模型等待、工具執行與重試時間,避免把外部服務延遲算到 GPU 頭上

如果任務需要很長的推理輸出,Decode 仍可能占大部分時間,真正值得比較的是完成同一項工作要多久、成功率如何,而不只是某個階段的峰值數字。選擇 Agent 模型與本機部署方式時,也應把工具呼叫品質一起放進評估。

M5 的加速器,要配合軟體才能發揮

M5 GPU 的 Neural Accelerators 是 GPU 內的矩陣運算加速能力,不應和晶片上另一個 Neural Engine 混為一談,對長輸入這類運算密集的工作,支援相應路徑的框架與核心可以帶來收益。

買到新晶片不代表任何模型、量化格式和舊版工具都會自動得到相同比例的加速,我會連同 macOS、MLX 或 llama.cpp 的版本一起記錄,並查看執行時使用的後端。Apple 早期公布的 M5 測試可以用來理解方向,但不能直接當成新款 M6 或 M5 Ultra 的實測成績。

MoE 為什麼值得看,但不能只看啟用參數

Mixture of Experts,混合專家模型,會依 token 選用部分專家,降低每步需要參與計算的參數量,它讓「保存很多知識容量」和「每一步動用多少運算」有機會分開,這和大容量統一記憶體的特性很搭。

以 Qwen 官方的 Qwen3-30B-A3B為例,30B 指總參數量,3B 指啟用參數量,不能因為看到 A3B,就用一個 3B 稠密模型的記憶體需求來估算,通常仍要保存更大的整體權重。這是用來解釋命名與架構的例子,不代表它是目前唯一或最適合的選擇。

MoE 的速度還受專家路由、量化、核心最佳化與批次大小影響,也不保證同樣容量下的工具使用品質一定勝過稠密模型,我的做法是準備一組真實任務,用完成品質與總耗時一起決定。

三種使用情境,我會這樣安排預算

主要使用雲端 AI,優先顧好日常工作

如果主要運算都在雲端,Mac 更多是在跑瀏覽器、編輯器與本地工具,無須只為遠端模型購買超大記憶體。16GB 到 32GB 可以作為一般工作起點,但大型專案編譯、虛擬機與剪輯仍可能需要更多。這是用途判斷,不是所有人的最低規格。

本地聊天、寫程式與剪輯混用,先看 48GB 到 128GB 的實際需求

先列出最常用的兩三個模型,再加上平常同時開啟的軟體。M5 Pro 和 M5 Max 各有不同容量與頻寬選項,能否容納模型加上真實工作環境,比只追求最大 GPU 核心數更重要。若以 Agent 為主,要優先找長提示詞與連續工具呼叫測試,而不是只看短聊天跑分。

目標是超大模型,再考慮 Ultra 與多機

當權重、長上下文或多請求確實超出較小容量,才有充分理由看 256GB、512GB 或分散式部署。先問自己是否需要那個模型能力,以及它能否在可接受時間內完成任務,不要為了「裝得下最大模型」而買一台長期等待的電腦。

AI 生圖與生影片,要另做一份評估

剪輯影片和用生成模型產生影片,是不同的運算工作,ProRes 編解碼能力強,不能直接推論擴散模型也會很快。ComfyUI 官方支援 Apple Silicon,但你的模型、量化與自訂節點是否支援 Mac,以及完整生成一段內容要多久,仍需逐項確認。

若主要目的是高頻率生影片,我會拿實際工作流比較 NVIDIA GPU、本地 Mac 與雲端方案,再把等待時間與每次產出的成本算進去。可從 LTX 2.3 的 ComfyUI 影音工作流理解需要核對哪些模型與節點,不應只拿文字模型的速度替影音生成下結論。

不過可以肯定的是現在要生圖還是首選 Nvidia 畢竟 pyTouch 還沒有完整支援 MAC

DGX Spark 加 Mac Studio,是分工不是魔法加總

EXO 的異質推理示範把 Prefill 放在 DGX Spark,再把 KV cache 傳給 Mac Studio 進行 Decode,並透過逐層傳輸,讓通訊與運算時間部分重疊。這說明不同硬體可以各做擅長的階段。

但 EXO 示範的是特定模型、輸入長度、硬體與網路,不能外推成任何組合都會同倍率變快。兩台 256GB 也不必然優於一台 512GB,模型如何分片、互連頻寬、框架支援與並行方式都會改變結果。多機還增加設定與維護成本,應以整個任務的實測決定。

對多機部署有興趣,可以接著看 雙機 EdgeXpert 與大模型工作負載,把單機容量、網路傳輸和軟體支援一起考慮。

購買前怎麼測,至少分開短提示詞與長提示詞

請測試者提供完整模型名稱、量化檔、框架版本、系統版本、上下文長度與 GPU 配置,相同模型換一種量化,或把長輸入改成一句問候,都足以改變結果。

已有 llama.cpp 與本地 GGUF 模型時,可參照 llama-bench 官方說明使用下列命令。把路徑改成自己已下載的模型,這裡的參數是測試設定,不是我在新機上測出的數字。

llama-bench -m /absolute/path/model.gguf -p 512,8192 -n 128 -r 3 -o json

這會分別測試不同長度的 prompt processing 與文字生成,輸出中的 pp 與 tg 對應不同階段。合成測試適合比較核心效能,不能直接當成真實 Agent 的 TTFT 或任務總耗時。還要補一輪實際工具呼叫流程,並分別記錄冷啟動、快取命中和未命中的狀態。

  • 同一份短問答,觀察穩定生成速度
  • 同一份長文件,觀察首個 token 等待時間
  • 同一個修改程式任務,觀察工具呼叫與完成率
  • 同樣的並行數,觀察尖峰記憶體、swap 與排隊
  • 若要生圖或生影片,使用完全相同的模型、尺寸、步數與節點

FAQ

32GB Mac 可以跑 27B 模型嗎

部分量化版本有機會,但要加上 KV cache、推理暫存、macOS 與其他程式的需求。能載入不等於長上下文或多 Agent 都能流暢使用。

M6 一定比 M5 Max 適合本地 AI 嗎

不一定。要比較完整配置的容量、頻寬、運算後端與實際工作負載,不能只用世代數字排序。

為什麼聊天很快,Agent 卻很慢

Agent 可能反覆處理長上下文並等待工具,瓶頸不只在生成速度。應同時檢查 Prefill、快取、排隊、工具時間與任務重試。

MoE 的啟用參數少,記憶體也只要那麼少嗎

不是。啟用參數主要描述每步參與計算的部分,通常仍要保存全部專家權重,容量估算不能只看 A 後面的數字。

我的選購順序:先定工作,再定模型,最後選配置

先確定主要工作是在雲端還是本地,再決定模型與上下文需求。容量不足先解決容量,等待第一個字太久就看輸入處理與快取,開始輸出後仍然慢才進一步比較頻寬與生成核心。用這個順序選 M5、M6 或 Ultra,比追規格表上最大的數字更能把錢花在真正的瓶頸上。