2026 年 Llama 4 Scout 在 LM Studio 怎麼測速？

畫面顯示模型成功載入，但 16GB Mac 只跑了一次、速度還不斷變動，這種結果不能直接拿來判斷 Llama 4 Scout 的實用性能。
最快解法是：把 16GB Mac 定位為資源預估與失敗邊界測試，正式的 Llama 4 Scout LM Studio 測速則在記憶體餘量充足的 Apple Silicon 環境中，固定 GGUF、執行時、上下文與提示詞，再分開驗收四類指標。

最後更新於 2026 年 9 月 1 日；資料核實自 Meta 官方模型頁、官方模型卡、LM Studio 文件與 llama.cpp 基準說明。若模型卡、Metal 執行時或社群量化檔案後續更新，本文的流程仍可沿用，但實測數值必須重新跑。

這篇適合三類讀者：

• 已下載社群製作的 Llama 4 Scout GGUF，卻不知道測速結果是否可信的 Mac 使用者。
• 準備比較本地 Mac 與雲端 Mac 推理環境的 AI 應用工程師。
• 要為模型演示、內部測試或服務化採購訂定驗收口徑的小型技術團隊。

先把模型身份與可用結論分開

首先要修正一個會讓整篇測試失真的前提：Llama 4 Scout 不是官方的 Llama 4 8B。官方資料將它描述為 MoE 架構，具有 17B 激活參數與 109B 總參數；這兩個口徑分別代表每次推理實際參與計算的參數規模，以及模型完整權重涉及的參數規模。詳情應以官方 Llama 4 發布說明及官方模型卡為準。

因此，測試標題與紀錄不能只寫「Llama 4 8B」或「Scout 跑分」。至少要完整寫出：

16GB Mac 的一次載入成功，只能回答「這個檔案在這組設定下有沒有機會進入記憶體」。它不能代表 Scout 在長上下文、多輪對話、並發請求或服務化情境中的可用速度，更不能拿來替代完整模型的性能評估。

下載後先完成檔案與執行時核驗

社群 GGUF 是轉換與量化後的交付物，不等於原始模型發布者提供的官方 GGUF。下載前應查看倉庫維護者、模型卡、授權條款、轉換說明、量化名稱與校驗資訊；若頁面沒有清楚說明轉換流程，這個檔案最多只能列入待驗證清單。

建議把檔案資料整理成一行可複製紀錄，例如：

Llama 4 Scout | GGUF | Q4_K_M（以實際檔案為準）| 社群轉換 | LM Studio | llama.cpp 執行時 | macOS | Apple Silicon

其中量化格式不能省略。Q4、Q5、Q8 或其他格式在權重精度、記憶體需求與輸出品質上都不是同一個測試對象；若社群轉換時移除了視覺能力、特殊 tokenizer 或部分輸入格式，測試結果也只能套用到該裁剪檔案。

開啟 LM Studio 後，先記下應用程式版本與實際使用的 llama.cpp 執行時，不要只寫「LM Studio 最新版」。LM Studio 的系統要求文件可用來核對作業系統與硬體支援範圍；實際載入時則應保存載入畫面或設定匯出資料，因為同一應用程式也可能隨更新更換底層執行時。

載入前用資源估算淘汰錯誤組合

不要反覆按載入，期待 LM Studio 自己找出可行配置。先使用 LM Studio 的資源估算功能，逐一查看模型檔案、上下文長度與 GPU offload 組合是否有機會進入可用記憶體。官方載入文件與載入 API 文件可協助核對載入參數的實際名稱與行為。

這一步要鎖定的變數包括：

• GGUF 檔案與量化格式；
• 上下文長度；
• GPU offload 層數或自動 offload 結果；
• Flash Attention 是否啟用；
• KV cache 放在 GPU、CPU 或由執行時自動處理；
• 採樣溫度、top-p、停止字串與輸出上限；
• 測試期間是否關閉瀏覽器分頁、編輯器、虛擬機及其他會爭用統一記憶體的程式。

若估算結果已顯示會大量交換，應先降低上下文或改用較小量化做診斷，而不是把「勉強載入」當作通過。這個判斷會影響成本：一次次重新載入和等待失敗，本身就是開發時間成本。

提醒： Metal 加速不會消除記憶體容量限制。當模型權重、KV cache、作業系統與背景程式共同爭用統一記憶體時，畫面上的瞬時速度可能仍然漂亮，但長時間輸出、首字延遲與意外退出才會揭露真正邊界。

Llama 4 Scout LM Studio 測速要拆開四個時間點

首輪測試不要只截圖 tokens per second。按照 llama.cpp 的llama-bench 基準方法，提示處理與文字生成是不同階段；在 LM Studio 中也應分開記錄。

我們建議用固定的短提示與長提示各跑一組，輸出上限固定為測試協議的一部分，並先預熱，再進行至少三輪重複。每一輪記錄：

1. 冷啟動載入時間：從按下載入到模型可接受輸入。
2. 首字延遲：送出提示到第一個可見輸出的等待時間。
3. 提示處理速度：模型讀取輸入提示的速度，不能與生成速度混寫。
4. 持續生成速度：穩定輸出階段的 tokens per second。
5. 異常輪次：卡住、速度顯著衰減、重複輸出、錯誤或意外退出。

測試報告應呈現中位表現、最快與最慢輪次的原因，而不是只選最高數值。提示詞內容、輸出上限、採樣設定與上下文都要保存；否則即使同一個 GGUF，在不同 Mac 上也無法分辨差異究竟來自晶片、記憶體壓力、執行時還是輸入長度。

第一小時要驗收穩定性與輸出品質

速度驗收不能停在第一次回答完成。第一小時應依時間順序完成短提示、長提示和多輪對話，並觀察：

• 生成速度是否逐輪下滑；
• 記憶體壓力是否上升，交換空間是否開始使用；
• LM Studio 或執行時日誌是否出現載入、Metal、KV cache 或上下文錯誤；
• 模型是否重複句子、截斷回答、忘記前文或無故停止；
• 載入後能否連續完成同一套測試，而非只在空閒桌面上成功一次。

若要比較本地與遠端 Mac，兩端必須使用同一個 GGUF、同一種量化、同一執行時、同一上下文、同一採樣及同一組提示詞。遠端測試另行記錄 SSH、VNC 或瀏覽器連線造成的等待；這些是操作延遲，不應直接算入模型生成速度。若需要長期管理遠端環境，可先參考JexMac 的使用說明，把連線方式與模型測試分成兩個紀錄欄位。

溫度與功耗尤其不能用手感描述。只有在工具能提供可追溯記錄、且測試期間保留時間戳與設定時，才把它們寫入報告；否則只報告速度、記憶體壓力與錯誤事件，不把「機身感覺很熱」寫成硬性性能結論。

用驗收分數決定下一步，而不是追逐峰值

我們會把結果分成三種工作目標，而不是建立一張脫離使用情境的跑分榜：

• 開發試跑： 能穩定載入、完成固定提示、輸出沒有明顯重複，足以驗證 API、提示詞或應用程式串接。
• 現場演示： 除了完成回答，還要能承受多輪操作，首字等待與速度波動不能讓演示流程失去預期。
• 持續服務： 必須再進行更長時間、併發、錯誤恢復與記憶體監控測試；單次成功絕對不等於可部署。

可以把每個目標標成「通過」「待復測」或「不通過」，並在旁邊寫明失敗原因。若只是因降低上下文、頻繁換頁或犧牲輸出品質才勉強運行，應判定為待復測，而非通過。

對於準備租用較大環境的團隊，先在JexMac 的方案頁確認可用配置與租用條件，再用同一份測試腳本重跑；重點不是購買更大的數字，而是確認新增的記憶體餘量是否真正消除了交換、速度衰減與意外退出。

把本次結果整理成三個明確出口

完成驗收後，決策不應只剩「快」或「慢」：

• 保留本地： 固定 GGUF 與設定後可穩定載入，開發或演示目標已通過，且沒有以換頁換取表面速度。
• 擴大環境： 16GB Mac 只能完成資源估算、偶爾載入，或長時間測試出現速度衰減；把相同測試移到記憶體餘量更大的本地或雲端 Mac。
• 更換模型： 即使擴大環境仍無法滿足上下文、品質、功能完整性或服務化要求；此時應重新評估量化格式、模型尺寸或工作流，而不是繼續調高 offload。

每次復測都保存以下欄位：完整模型名稱、GGUF 來源、量化格式、檔案校驗、Mac 晶片與統一記憶體、macOS、LM Studio 版本、llama.cpp 執行時、上下文、Flash Attention、KV cache、GPU offload、採樣設定、冷啟動、首字延遲、提示處理、生成速度、交換空間、錯誤日誌與穩定運行結果。這份紀錄比一張只寫「每秒多少 token」的圖片更能支援採購與部署決策。

常見問題

LM Studio 顯示的 tokens per second 怎樣看才準確？

不要只看畫面上的最高瞬時值。應先排除冷啟動載入時間，再固定提示詞、上下文、採樣與 GPU offload，預熱後重複測試，分開記錄提示處理速度與文字生成速度，最後以中位表現及異常輪次判讀。

Llama 4 Scout GGUF 測速前要記錄哪些配置？

至少保存完整檔名、來源維護者、量化格式、LM Studio 版本、實際 llama.cpp 執行時、macOS、Apple Silicon 晶片、統一記憶體、上下文長度、Flash Attention、KV cache 位置、GPU offload 與採樣參數，否則不同結果無法公平比較。

為甚麼同一個 GGUF 在不同 Mac 上速度差很多？

差異通常不只來自晶片名稱，還包括統一記憶體餘量、GPU offload、上下文長度、KV cache 位置、執行時版本、背景程式與是否開始交換。只要其中一項不同，tokens per second、首字延遲與長時間穩定性都可能改變。

16GB Mac 能不能用來測試 Llama 4 Scout 性能？

適合做檔案核驗、資源預估與失敗邊界測試，但不宜把一次成功生成當成正式性能結論。若載入後出現換頁、速度衰減、上下文縮減或意外退出，應把 Scout 復測移到記憶體餘量更大的 Apple Silicon 或雲端 Mac。

本地 Mac 和遠端 Mac 的模型速度怎樣公平比較？

兩端必須使用相同 GGUF、量化格式、LM Studio 與執行時、提示詞、上下文、採樣和輸出上限，並分開量度載入、首字延遲、提示處理與生成。遠端環境還要另記錄連線延遲，不能把網路等待混入模型速度。

如果目前方案是直接在16GB 本地 Mac 上反覆嘗試，常見缺點是記憶體餘量不足、換頁令速度不穩、背景程式容易干擾，而且一次成功載入也難以延伸到持續服務；若改用臨時雲端伺服器，則可能遇到執行時不一致、連線延遲與環境維護成本。對需要短期復測、模型演示或比較不同 GGUF 的團隊，租用 JexMac 的 Mac 環境能把硬體準備、遠端連線與測試週期分開管理；先以同一份紀錄表驗收，確認環境真正適合工作流，再決定是否延長租用，比單純追逐一次峰值更穩妥。

常見問題