若你同時做生成與檢索，請先對齊本機 RAG：分塊、Embedding 批次與向量配額矩陣，避免索引器與對話執行緒搶同一包 RAM。產品與區域說明見LlmMac 首頁；需要徹夜跑評測或批次基準時，可到購買／方案頁比對專用 Mac mini M4 節點，無需登入即可瀏覽方案。
硬體邊界
Mac mini M4 採統一記憶體：GPU、Neural Engine 與 CPU 共用同一池。好處是減少拷貝；代價是上下文、KV cache、批大小與並行請求共用同一預算。實務上壓力大致隨「在飛 token」成長：更長提示、更寬批次、更多平行對話，都會讓記憶體控制器必須維持更大的工作集。
蘋果會公布各晶片層級的記憶體頻寬數字；對本機 LLM 而言，穩態解碼常受權重與 KV 位元組能否被快速餵進運算單元限制，而非單一 TFLOPS 標題數字。把上下文從 8k 拉到 32k，不只是「多用 RAM」——KV 張量的常駐型態與 Metal kernel 的占空比都會變。若活動監視器顯示記憶體壓力偏高但 token 仍在輸出，多半已過膝點：先降量化階、縮 num_ctx，或減少並行，再談更新 flash-attention 類建置。
mini 機型仍建議以連續 10 分鐘穩態當驗收，而非只看 60 秒排行榜截圖。
GGUF／量化選型
GGUF 仍是 llama.cpp 生態的交換格式首選；Ollama 底層同樣吃相容權重。2026 年多語或程式碼場景，常見預設落在 Q4_K_M 或 Q5_K_M：多數任務主觀品質接近 FP16，同時壓低每位元組頻寬。IQ 系量化（如 IQ4_XS）在統一記憶體吃緊時能贏在純容量，但務必用自家評測提示驗證——工具呼叫 JSON、長表格往往最先退化。
MoE 模型要另算尖峰；量化須與建置對齊，舊 GGUF 配新 tokenizer／template 常釀成「昨天還能跑」。Runbook 請固定模型修訂、量化型別與模板。
# llama.cpp 範例骨架（路徑與旗標請依你的建置調整）
./llama-cli -m ./models/model.Q4_K_M.gguf -c 8192 -b 512 -ngl 99並發與批大小
llama.cpp 直接暴露批次與卸載：上下文用 -c／--ctx-size，批次用 -b／--batch-size，Metal 層數用 -ngl（server 模式有對應項）。加大批次有助提示階段（prefill）吞吐，但會抬高峰值記憶體；過小的 micro-batch 則吃不滿 GPU、浪費頻寬。實務迴圈：先鎖定目標上下文，掃描批次 {128, 256, 512, 1024}，在 RSS 峰值低於安全邊界下取最大可用值（24 GB 機型若仍開桌面應用，常預留約 8–12 GB 餘裕）。
Ollama 以操作簡化換較少裸旗標。可在 Modelfile 設 PARAMETER num_ctx、num_batch、num_gpu（視版本支援），並以 OLLAMA_NUM_PARALLEL 等環境變數控制並行。每增加一個並行槽，峰值時約等於多複製一份 KV 預算；可類比「同一顆 GPU 上多開 llama.cpp」。API 突刺流量時，寧可在客戶端排隊，也別讓 daemon 一次開滿導致記憶體壓縮。
同一台 Mac 若還跑 embedding 或建索引，請序列化重活或改到其他主機——前文 RAG 矩陣已說明 embedding 批次尖峰與對話服務 naive 排程時的衝突。
| 關注點 | llama.cpp（典型 CLI／server） | Ollama（daemon＋API） | M4／統一記憶體備註 |
|---|---|---|---|
| 上下文視窗 | -c／--ctx-size；若模型支援 YaRN 等映射可再切圖 |
Modelfile 的 PARAMETER num_ctx 或拉取預設 |
更長 ctx 使 KV 位元組約線性成長；盯統一記憶體壓力，而非只看 GGUF 磁碟大小 |
| Prefill／微批次 | -b／--batch-size（及版本支援的 -ub 等） |
PARAMETER num_batch；可能受模型預設上限 |
批次加大到首字延遲（TTFT）改善趨平即停；RSS 尖峰過高則回退 |
| GPU 卸載 | -ngl 指定層數上 Metal |
多為自動；部分建置可給 num_gpu 提示 |
部分卸載省 RAM 但可能挪移瓶頸；以端到端 tokens／s 為準 |
| 並行對話／API | RAM 允許才多程序；分埠隔離 | OLLAMA_NUM_PARALLEL；客戶端維持佇列 |
每條連線峰值時近似多一份 KV 預算；寧可排隊勿過度超賣 |
| 頻寬代理指標 | 對照 tokens／s 與活動監視器；flash-attn 類建置降低 KV 流量 | 訊號類似；可調參數較少、較依版本組合 | 解碼停滯但 GPU 有閒隙時，先懷疑記憶體頻寬或批次設定 |
本機推理上線清單
- 模型清單：記錄 GGUF 檔名、量化型別、SHA-256、tokenizer 模板、執行時版本（llama.cpp commit 或 Ollama App 版號）。
- 記憶體包絡：冷啟動、首請求、以及預期並行下連續 10 分鐘 soak；記錄峰值 RSS 與是否換頁。
- 上下文政策：各環境（dev／stage／prod）上限
num_ctx，以及客戶端硬上限 token。 - 批次掃描：留存勝出的
-b／num_batch與測得 prefill p95 延遲。 - 降級路徑：記憶體壓力持續超過門檻逾 60 秒時，自動改較小量化或較短上下文。
- 可觀測性：提示與生成 token 數、錯誤皆帶時間戳；日誌輪替於
~/Library/Logs或服務目錄。
穩定性 FAQ
為何幾分鐘後吞吐崩跌？ 常見是熱平均降頻，或並行尖峰後背景記憶體壓縮。請減並行、關閉與推理搶磁碟／CPU 的 Spotlight、Time Machine 或 Xcode 索引後再量。
Ollama 隔夜更新後延遲變了？ daemon 與模型 blob 常一起變。正式環境請釘版本；法遵若要求不可變，可鏡像到內部路徑。
批次愈大愈好嗎？ 否。過膝點後 prefill 增益有限，但混合提示長度時 OOM 風險上升。寧可 bounded 批次＋客戶端切碎巨大 system prompt。
該關 Metal 除錯嗎？ 僅短暫。CPU 路徑有助切分數值／模板問題，但無法代表容量規劃。
多人共用一台 Mac？ 請序列化或拆機；多條長上下文並行往往遠比帳面數字昂貴，優先排隊或另租節點。
摘要：上下文、批次、量化與並行是同一記憶體頻寬預算上的聯動桿；以穩態量測取代尖峰截圖，固定模型清單，並避免索引與對話在同一包絡內無序重疊。