2026年10月28日更新：Ollama憑藉實測的性能數據（在RTX 5000 Ada基準測試中分別達到每秒145.48和92.87個令牌，是目前為止三款軟體中最快的）成為第三選擇，入門問題解答現已反映出速度差距，指南欄位也提供了Ollama的上手體驗。 10月19日，Open WebUI以每秒115.32和75.06個令牌的成績位列第二，而1月份的成績分別為每秒123和82個令牌。本文最初發佈於2026年8月19日。
在自有硬體上運行語言模型有四個原因，其中只有一點是出於理念上的考量。隱私性：你交給本地模型的文件永遠不會離開機器，這涵蓋了客戶端程式碼、合約、病患資料和未發布產品的全部通訊過程。
成本結構：雲端 AI 按量計費，代理工作負載的令牌數量增長速度極快，一台性能強大的工作站即可收回成本；而您擁有的硬體則按電費運行。可用性：無速率限制，無停機，也不會在周二收到棄用通知郵件，導致您的工作流程發生變更。控制權：您驗證的模型就是您執行的模型，直到您另行決定為止。
但另一方面，前沿的雲端模型仍然功能更強大，對於需要長期智能體處理的任務而言，這種差距是真實存在的。本地模型在有限任務方面已經達到了與雲端模型相當的水平，例如聊天、摘要、單一文件代碼和文件問答。而這些恰好涵蓋了大多數人每天的大部分工作。如果您追求的是不惜一切代價實現最大功能，那麼請使用雲端模型。如果您更注重隱私、成本或控制權，那麼本地模型目前仍然可行，而本頁面正是您了解本地模型的指南。
這個框架應該決定你的硬體預算，因為本地AI的投入首先取決於記憶體使用情況。 16GB顯存或32GB統一記憶體可以滿足7億到8億級的模型需求，足以處理上述有限的工作量。 24GB到32GB顯存或48GB統一記憶體可以達到30億級，此時智能體編碼不再是演示。 96GB到128GB統一記憶體可以運行100億級以上的模型，接近前緣品質。過度購買記憶體可以提升你可能察覺不到的速度；而購買不足則意味著你想要的模型根本無法載入。
我們的「最佳本地AI筆記型電腦」和「最佳本地AI桌上型電腦」名單按等級對機器進行了排名。本頁將介紹在這些機器上執行哪些程式。
軟體方面的發展遠不如硬體成熟。如今，搜尋結果推薦的工具裡，大約有三分之一已經失效，而推薦這些工具的大多數網站對此卻渾然不覺。
本頁面記錄了截至 2026 年 10 月哪些工具可用以及它們支援哪些硬體。目前我們以 GitHub 星號進行排名，因為這是一個中立且可驗證的指標。我們會註明哪些工具是閉源的，沒有星標數可供參考。表格中的每個工具名稱都連結到其官方下載連結。隨著每個工具經過實驗室測試，「指南」列會更新，提供實際安裝步驟和我們自己的測試數據，從 1 月開始。
本頁遵循三條規則，首先是區分本地模型和本地代理。部分產品在您的電腦上運行，但每次推理呼叫都會傳送到供應商的雲端；這是為了保護隱私，而非提供離線功能，這些工具單獨列在頁面底部，以便區分。其次，每個條目都包含實際的最低硬體配置要求，因為如果沒有記憶體訊息，「它可以在筆記型電腦上運行」這樣的描述毫無意義。第三，我們在常見問題中記錄了哪些產品已停止服務，並附有停止服務的日期。
精選推薦
最佳本地LLM運行時間：奧拉瑪
Ollama 是預設答案，也是大多數其他工具所依賴的。它採用 MIT 許可證，在 GitHub 上擁有約 17.9 萬顆星，現在除了命令列介面 (CLI) 外，還提供桌面圖形使用者介面 (GUI)。它只需一條命令即可拉取模型，並在本機上提供一個與 OpenAI 相容的端點。 2026 年 1 月，它還增加了對 Anthropic Messages API 的兼容性，用戶現在可以透過該 API 將 Claude Code 指向本地模型。最低配置： 3B 級模型需要 8GB 系統內存，7-8B 級模型需要 16GB 系統內存，30B 級模型需要 24GB 顯存。
它也是本頁上速度最快的平台，我們已透過自身測試數據證實了這一點。在我們的Ollama 實際測試中，使用與 Jan 和 Open WebUI 指南相同的 RTX 5000 Ada 基準測試和模型文件，Ollama 0.40.11 解碼 Jan V3.5 4B 的平均速度為每秒 145.48 個 token，解碼 Jan V2 VL High 的速度分別為每秒 145.48 個 token，解碼 Jan V2 VL High 的速度分別為 18% 完整且完整的 GPU 18% 18% 和 GPU 18% 完整且完整的 GPU 18%，均 18% 和 GPU了 18% 完整且完整的 GPU卸載，未啟用 CUDA。缺點在於桌面應用程式：匯入現有的 GGUF 文件需要模型檔案和 PowerShell 腳本；匯入的視覺模型缺少投影機文件，因此無法支援圖片；此外，網頁搜尋需要帳戶，並且會傳回 HTTP 402 錯誤。
最適合硬體基準測試：LM Studio
由於是閉源軟體，所以沒有星級評分，但它依然名列前茅。 LM Studio 捆綁了 llama.cpp 和 MLX，並公開了在測量機器性能而非實際使用機器時至關重要的各項控制功能：GPU 卸載層、量化選擇、上下文長度和多 GPU 行為。自 2025 年 7 月起，它已免費用於商業用途。我們工作站和筆記型電腦測試板上的大多數每秒令牌數 (tokens per second) 資料都出自該工具。最低配置： 16GB 記憶體；若要獲得更佳效能，建議使用 24GB 記憶體或 32GB 統一記憶體。
最佳底層引擎：llama.cpp
本頁幾乎所有其他內容都基於 llama.cpp。該專案採用 MIT 許可證，擁有約 124,700 個 star，並且每天都會發布多個標籤的建置版本。它對硬體用戶來說意義重大，原因在於：其後端支援清單非常龐大，涵蓋 CUDA、ROCm、Metal、Vulkan、SYCL、CANN 和 OpenCL，而且廠商工程師現在可以直接為其貢獻優化。例如，在 8688 版本中對 Intel Arc 預填的改進就帶來了大約 5 倍的效能提升，而所有 Ollama 和 LM Studio 用戶無需安裝任何軟體即可獲得此改進。最低配置：只需 CPU 即可運作；8GB 記憶體即可流暢運作。
最佳本地優先桌面應用程式：Jan
Apache 2.0，約有 44,100 個 star，截至 2026 年 10 月版本為 v0.8.6。 Jan 捆綁了 llama.cpp，因此無需安裝其他任何軟體，即使拔掉網線也能正常工作。乍看之下這似乎要求不高，但當你查看該類別中有多少應用程式是帶有 Ollama 欄位的雲端客戶端時，就會發現它遠不止於此。這款應用程式非常適合推薦給那些永遠不會打開終端機的同事。
它也是本頁上第一個擁有我們自身測試資料的平台：在我們的 RTX 5000 Ada 基準測試中，Jan V3.5 4B 的解碼速度中位數為每秒 123 個 token，Jan V2 VL High 為每秒 82 個 token，分別使用了 4.8GB 和 8.2GB 啟動時 8.2 啟動沒有加速了空間。從安裝到相容 OpenAI 的 API 的完整教學課程，請參閱我們的Jan 上手指南；文件 RAG 是該指南未涵蓋的應用程式部分。最低配置： 8GB 記憶體。
最佳本機文件 RAG：AnythingLLM
MIT 出品，約有 64,800 個 star。它內建向量資料庫，無需配置即可處理分塊和嵌入，使其成為桌面級文件聊天工具中最開箱即用的軟體。有兩點需要注意：2026 年 3 月發現的一個 CVSS 9.6 級漏洞允許攻擊者利用模型自身的串流響應觸發遠端程式碼執行，該漏洞已在 1.11.2 版本中修復，因此請在使用前更新。此外，該應用程式標榜本地優先，但預設開啟遙測功能，您可以在設定中將其關閉。最低配置需求： 16GB 記憶體（用於文件處理）。
最佳自架多用戶解決方案：Open WebUI
該伺服器擁有約 149,000 顆恆星，並具備最深度的檢索配置功能。我們測試了 v0.12.2 版本。它最初是一個以 Docker 為入口點的自託管伺服器，現在可以透過 Windows 桌面應用程式安裝，並捆綁了 Python 環境和其自身的 llama.cpp 運行時。在您基於此進行開發之前，需要注意一點：其許可證已於 2025 年 4 月從 BSD-3 更改為未經 OSI 認證的自訂許可證，新增了禁止移除 Open WebUI 品牌識別的條款，但任何 30 天內用戶數量少於 50 人的情況除外。如果您小規模運行且未做任何修改，則不會受到任何影響。
這是本頁上第二個包含我們自身測試資料的平台。在我們的 Jan 基準測試和模型文件中，Open WebUI Desktop 對 Jan V3.5 4B 的解碼速度中位數為每秒 115.32 個 token，而 Jan V2 VL High 的解碼速度分別為每秒 75.06 個 token、6.2% 和 8.5%，略遜不同的版本 75.06 個 token、6.2% 和 8.5%，略遜不同的版本。它們的差異在於設定：我們固定了 llama.cpp 版本 b11612，手動添加了 CUDA 運行時 DLL，並在重新安裝後恢復了 8,192 個 token 的上下文（重新安裝後每個插槽最多可分配 169,984 個 token）。
預設、影像輸入、DDGS 網路搜尋和本機 API 等功能均可正常運作，詳情請參閱我們的Open WebUI 實戰指南。最低配置需求：獨立的運行時環境加上 4GB 記憶體用於容器，或使用包含 llama.cpp 的桌面應用程式。
最佳本地編碼代理商：克萊恩
Apache 2.0，約有 63,900 個 star。 Cline 在本地路徑上投入的工程量比任何競爭對手都多，包括專為 Ollama 和 LM Studio 構建的簡潔系統提示符，以及針對每個模型系列的本地工具調用。他們的文檔異常坦誠地指出了雲端技術仍然勝出的面向。最低配置： 24GB 顯示記憶體或 36GB 統一內存，並將上下文設為 32K 或更高。
最佳離線終端編碼：助手
Apache 2.0 認證，擁有約 48,300 個 star，其架構是本地最可靠的選擇，原因值得理解。 Aider 完全不使用 JSON 工具呼叫。它從純文字中解析差異和整文件編輯格式，從而避免了大多數本地模型代理都會遇到的故障模式。但缺點是維護成本：96% 的程式碼提交都出自一位作者之手，發布頻率已降至大約 2026 年才發布一個穩定版本。最低配置需求： 24GB 記憶體或 36GB 統一記憶體。
最佳自架代理平台：OpenHands
OpenHands 是麻省理工學院 (MIT) 的項目，擁有約 84,500 個 star。它對本地模型進行了詳盡的文檔說明，更重要的是，它還能告訴你問題何時不在於你的配置：其文檔指出，如果代理的行為像聊天機器人或工具頻繁報錯，則說明模型本身存在限制。它要求至少 22K 的上下文訊息，並建議使用 32K。最低配置需求：量化模型需要 24GB 顯存，統一記憶體需要 64GB。
最佳免費離線驚喜：GitHub Copilot CLI
自 2026 年 4 月起，Copilot CLI 可與 Ollama、vLLM 和 Foundry Local 搭配使用。 GitHub 身份驗證是可選的，無需訂閱 Copilot。設定 COPILOT_OFFLINE 會停止所有遙測和網路連接，其子代理將繼承本機提供者。大多數對比文章仍然將其列為僅限雲端使用。請注意，即使在自帶密鑰的情況下，IDE 擴充功能仍然會將內聯補全傳送到雲端。最低配置需求： 128K 上下文視窗的機型，即 32GB 記憶體或 64GB 統一記憶體。
最佳廠商支援伺服器：Lemonade
Apache 2.0，擁有約 5,400 個星標，是我們僅憑自身實力就推薦的唯一廠商相關工具。它由 AMD 工程師維護，支援 NVIDIA CUDA、Apple Metal、Vulkan 和普通 CPU，以及 Radeon 和 Ryzen AI NPU。它大約每兩週發布一次，並於 2026 年 4 月將其桌面應用程式從 Electron 遷移到 Tauri。最低配置： 16GB 記憶體；NPU 版本需要 Ryzen AI 300 系列或更高版本。
最佳檔案系統級本地 RAG：Nexa AI 超鏈接
Nexa AI Hyperlink 是一款閉源免費軟體，它會對裝置上的整個檔案系統進行索引，並以內嵌引用的方式給出答案。它之所以出現在這份榜單上，是因為它是唯一一款在消費級硬體上公佈了加速性能數據的全新本地 RAG 工具：在 RTX 5090 顯示卡上，索引速度提升約 3 倍，推理速度提升約 2 倍，處理 1GB 資料夾的時間從大約 15 分鐘縮短到 4 到 5 分鐘。最低配置需求：現代 RTX GPU；16GB 記憶體。
運行時間：模型由什麼運行
這五個是引擎，接下來的兩張表格中的所有內容都是與其中一個引擎通訊的前端，因此表格像頁面上的其餘部分一樣按 GitHub 星號排序。
此處的「指南」欄位與「套用」欄位重疊，因此其範圍也相應調整：Ollama 單獨成篇，因為它是首選方案，也是大多數其他工具所指向的後端；LM Studio 在兩個表格中均有出現，並單獨成篇；llama.cpp 的內容透過其捆綁的應用程式介紹，最早的可參考一月份的實戰技術可參考一月份的 Windows 則透過其捆綁的應用程式介紹，最早可參考一月份的 Windows 則透過其組合的 Apple 進行介紹，最早可參考一月份的 Windows 則可參考一月份的 Windows 則透過其捆綁的應用程式進行介紹，最早可參考一月份的 Appleicon 則透過其捆綁的應用程式介紹，最早可參考一月份的 Apple 更新版 MLX 則透過其捆綁的應用程式介紹，最早可參考一月份的 Windows 可參考一月份的 Windows 則透過其捆綁的應用程式進行介紹，最早可參考一月份的 Windows 則透過其捆綁的應用程式進行介紹，最早可參考一月份的 Appleicon 則透過其捆綁的應用程式進行介紹，最早可參考一月份的 Windows 可參考一月份的 Windows 則以查看vLLM 是一個伺服器引擎，其測試已包含在我們的雙塔 GB300 叢集評測中。
| 運行時 | 明星 | 執照 | 最低硬體需求 | 加速 | 指南 |
|---|---|---|---|---|---|
| 奧拉馬 | 〜179,000 | 麻省理工學院 | 8GB 記憶體（3B 等級），16GB 記憶體（7-8B 等級），24GB 記憶體（30B 等級） | CUDA、ROCm、Metal、Vulkan | Ollama實戰指南 |
| 調用.cpp | 〜124,700 | 麻省理工學院 | 8GB 內存，僅 CPU 工作 | CUDA、ROCm、Metal、Vulkan、SYCL、CANN、OpenCL | 涵蓋了 以及 打開網頁介面 實踐操作 |
| MLX / mlx-lm | 〜27,500 | 麻省理工學院 | 蘋果晶片，16GB統一內存 | Metal；CUDA 後端於 2026 年新增 | 透過 LM Studio 指南（即將推出） |
| LM工作室 | 閉源 | 專有技術，可免費用於商業用途 | 16GB 記憶體；24GB 記憶體或 32GB 統一存儲 | 捆綁 llama.cpp 和 MLX | 即將公開資訊 |
| 法學碩士 | 生產服務 | 阿帕奇2.0 | 24GB 顯示 逼真地板 | CUDA、ROCm | 在我們的測試中 GB300集群評測 |
桌面應用程式和本機 RAG
這些是讀者安裝的應用程序，而「本地優先」一欄需要仔細閱讀：它將在您的電腦上運行模型的軟體與添加了 Ollama URL 字段的軟體區分開來。
| 應用 | 明星 | 執照 | 本地優先 | 最低硬體需求 | 指南 |
|---|---|---|---|---|---|
| 打開網頁介面 | 〜149,000 | 自訂，未經 OSI 認證 | 功能強大；伺服器端，以及捆綁了 llama.cpp 的 Windows 桌面應用程式。 | 單獨的運行時環境 + 4GB 用於容器，或桌面應用程式 | Open WebUI實務指南 |
| 任何事法學碩士 | 〜64,800 | 麻省理工學院 | 已啟用；遙測功能預設為開啟 | RAM 16GB | 即將公開資訊 |
| 〜44,100 | 阿帕奇2.0 | 是的，捆綁了 llama.cpp | RAM 8GB | 一月實戰指南 | |
| LM工作室 | 閉源 | 所有權 | 可以 | 16GB 記憶體；24GB 顯存，這很有趣。 | 即將公開資訊 |
| 姆斯蒂 | 閉源 | 專有免費層 | 是的，捆綁 Ollama、MLX、llama.cpp | RAM 8GB | 即將公開資訊 |
| Nexa AI 超連結 | 閉源 | 專有，免費 | 是的，設備端索引 | 現代 RTX 顯示卡，16GB 內存 | 即將公開資訊 |
編碼和代理工具
這些是頁面上對硬體要求最高的條目，因為代理工作需要較大的上下文視窗和較長的會話時間。請將 32GB 記憶體或 64GB 統一記憶體視為示範程式的極限。
| 工具 | 明星 | 執照 | 本地路徑 | 最低硬體需求 | 指南 |
|---|---|---|---|---|---|
| 開放之手 | 〜84,500 | 麻省理工學院 | LM Studio、Ollama、vLLM、SGLang | 24GB 記憶體或 64GB 統一顯示記憶體；32K 上下文 | 即將公開資訊 |
| 克萊恩 | 〜63,900 | 阿帕奇2.0 | Ollama、LM Studio、OpenAI 相容 | 24GB 記憶體或 36GB 統一內存 | 即將公開資訊 |
| 鵝 | 〜52,900 | 阿帕奇2.0 | Ollama 一流；現在是 Linux 基金會 | 24GB 記憶體或 36GB 統一內存 | 即將公開資訊 |
| 幫手 | 〜48,300 | 阿帕奇2.0 | Ollama，相容於 OpenAI；無需工具調用 | 24GB 記憶體或 36GB 統一內存 | 即將公開資訊 |
| 捷思銳 | v1.0，2026年4月 | 阿帕奇2.0 | LM Studio、Ollama、llama.cpp | 24GB 記憶體或 36GB 統一內存 | 即將公開資訊 |
| GitHub Copilot CLI | 閉源 | 專有軟體，無訂閱 | Ollama、vLLM、Foundry Local | 32GB 記憶體或 64GB 統一顯示記憶體；128K 上下文 | 即將公開資訊 |
供應商倡議
幾乎所有晶片和作業系統廠商都推出了本地AI產品，由於命名混亂且生命週期短，這個類別值得單獨列出。 2026年的趨勢一致：廠商不再與第三方技術堆疊競爭，而是開始提供產品。 NVIDIA終止了其兩款本地AI產品，轉而發布針對Ollama、llama.cpp和ComfyUI的最佳化方案。 AMD與LM Studio合作推出聯合品牌產品。高通則透過移植其他廠商的應用程式來發布其NPU功能。
廠商提供的工具能夠做到 Ollama 和 LM Studio 做不到的一點是：它們可以存取 NPU。 llama.cpp沒有 NPU 後端，因此在驍龍或 Ryzen AI 機器上，這些工具會讓神經網路引擎的使用率降至零。如果您購買了 40 到 60 TOPS 的性能，只有廠商提供的工具才能真正利用它。因此，請合理預期，因為 NPU 目前的模型處理能力上限約為 7 億，其優勢在於始終運行的小模型任務時可以延長電池續航時間，而不是提高吞吐量。在速度方面，獨立 GPU 始終優於 NPU。
| 供應商 | 這是什麼 | 類型 | 所需硬件 | 狀態 | 指南 |
|---|---|---|---|---|---|
| AMD檸檬水 | 伺服器、圖形使用者介面和軟體開發工具包；約 5,400 個星標，Apache 2.0 版 | 應用 + 伺服器 | 16GB 記憶體；Ryzen AI 300+ NPU。也支援 NVIDIA、Apple 和 CPU。 | 活躍，大約每兩週發貨 | 即將公開資訊 |
| 英特爾 OpenVINO GenAI | 運行時和 SDK；約 10,700 顆星 | SDK | Core Ultra、Arc A/B 系列；16GB 內存 | 活躍，2026.3（2026年8月） | 已追踪，無嚮導計劃 |
| Apple 基礎模型 | 作業系統公開的設備端模型 | 作業系統框架 | 蘋果晶片；已安裝 | 已啟動；2026 年 WWDC 大會上向所有供應商開放 | 已追踪，無嚮導計劃 |
| Microsoft Foundry Local | 本地推理 SDK 和 CLI；約 2,400 顆星 | SDK | Windows、macOS、Linux；NPU/GPU/CPU | GA 2026年4月；精選模式目錄 | 已追踪，無嚮導計劃 |
| AMD 蓋亞 | 適用於 Ryzen AI 的本地 LLM 應用；約 1,400 個星標，MIT 認證 | 應用 + SDK | 最低配置：Ryzen AI 300 系列處理器；16GB 內存，建議 64GB 內存 | 已激活，版本 0.20.0，2026 年 6 月 | 已追踪，無嚮導計劃 |
| 英特爾人工智慧遊樂場 | 桌面應用；約900顆星 | 應用 | Arc A 系列 8GB+、Arc B 系列、Core Ultra | 兩年後仍處於活躍但測試階段 | 已追踪，無嚮導計劃 |
| 高通 GenieX | 驍龍NPU的設備端GGUF運作時 | 運行時 | 驍龍 X / X Elite，8 Elite | 開發者預覽版，2026 年 7 月 | 已追踪，無嚮導計劃 |
| NVIDIA 專案 G-Assist | 用於系統控制的設備端 8B 助手 | 應用 | RTX 20 系列或更新機型，6GB 記憶體 | 已發布但仍標記為預發布版 | 已追踪，無嚮導計劃 |
這種命名方式加劇了混亂，因為NVIDIA的「RTX AI Garage」聽起來像是一個產品，但實際上並非如此；它是一個部落格系列。微軟的技術堆疊也多次更名：Copilot Runtime API變成了Windows AI API，Azure AI Foundry變成了Microsoft Foundry，而DirectML現在處於維護模式，只提供安全性修復。 Qualcomm AI Hub是一項雲端服務，用於遠端配置實體設備，而不是在本地運行的服務。
通常會壞掉什麼
大多數關於本地模型「無法正常工作」的報告都是配置問題，而非模型本身的問題。其中有四種情況尤其突出，而且這四種情況都是硬體用戶在指責晶片之前應該了解的。
1. Ollama 預設使用 4,096 個 token 的上下文。超出此限制時，它不會報錯，而是默默地截斷上下文，導致代理迴圈悄悄終止。但所有正規的框架都需要更大的上下文：OpenHands 至少需要 22 個 token，建議使用 32 個；Codex 需要 32 個 token；Copilot CLI 需要 128 個 token；Cline 則需要 262,144 個 token。這一個設定很可能是導致網路故障報告中最常見的原因。
2. KV 快取量化會降低工具呼叫的效能，而且這種影響會在整體輸出品質明顯下降之前就出現。 llama.cpp 文件對此有直接警告。如果您正在運行代理，請將其關閉。
3. 工具數量並非平緩成長，而是急劇增加。當工具數量超過五到六個左右時，某些模型會悄無聲息地停止發出有效的 JSON 工具調用，轉而將 XML 嵌入響應體中，測試框架會將其解讀為「未使用任何工具」。一款流行的代理商預設搭載了十一個工具，導致其自身推薦的模型在 2026 年初之前都無法正常工作。我們在 Open WebUI 測試中也遇到了類似的問題，內建工具指令使得一個簡短的基準測試請求的令牌數量超過了 8,192 個。其實際後果與直覺相悖：載入過多的 MCP 伺服器會對本地模型造成損害，而對前沿模型則不會。
4. Q4_K_M 是實際的最低標準。低於此標準，工具呼叫可靠性下降速度比整體品質下降速度更快，因此模型聽起來仍然正常，但實際上卻無法正常運作。
記憶體是限制因素
本頁所有工具的運作結果都取決於加速器能夠辨識的記憶體大小。以下是我們在智能體工作中經常看到的幾種記憶體組合，也是我們計劃在實驗室中驗證的組合。
| 硬體 | 型號 | 腳印 | 報告吞吐量 |
|---|---|---|---|
| RTX 5090，32GB | Qwen3.6-35B-A3B Q4_K_M | 〜21GB | 160-180 tok/s，262K 上下文 |
| RTX 5090，32GB | Qwen3-Coder-30B-A3B Q4_K_M | 〜19GB | 24GB 記憶體容量下，速度為 50-90 tok/s |
| RTX 5090，32GB | Devstral Small 24B Q4_K_M | 〜14GB | 專為工具呼叫而設計 |
| RTX PRO 6000，96GB | GPT-OSS 120B MXFP4 | 〜63GB | 單張工作站顯示卡上的 100B 級效能；我們實驗室評測中的 GPU |
| RTX PRO 5000 筆記型電腦，24GB GDDR7 | Qwen3-Coder-30B-A3B Q4_K_M | 〜19GB | 我們測試過的最大筆記型電腦GPU（ThinkPad P16 Gen 3）；30B等級效能綽綽有餘。 |
| 96-128GB 統一存儲，M 系列 | gpt-oss-120b Q6_K | 〜93GB | 14-20 tok/s；所有開放權重模型中最簡潔的工具呼叫 JSON |
值得一提的是，因為市場宣傳並未提及：最大的開源模型並非工作站模型。 GLM-5.2 的參數量約為 744 字節，在 FP8 模式下需要約 744GB 的內存，這相當於一個八 GPU 的資料中心節點。 Kimi K2 和 DeepSeek V4 也屬於同一級別。任何建議在桌上型電腦上運行這些模型的指南都是錯誤的。
以上吞吐量資料來自已發布的第三方測試和廠商資料，除上文推薦的 Jan、Open WebUI 和 Ollama 解碼資料外，尚未經過 StorageReview 實驗室驗證。我們將隨著每款產品進入指南審核流程，並以我們自己的資料取代上述資料。
雲端優先工具及其未在此排名的原因
本機代理程式不是本機模型，下面的工具顯示了它們之間的差異：每個代理程式都在您的機器上運行，同時將每個推理呼叫傳送到供應商雲端。
| 工具 | 本地模型支持 | 備註 |
|---|---|---|
| 光標 | 沒有 | 官方文件指出，所有請求均透過 Cursor 伺服器路由；自訂按鍵僅適用於主流雲端服務供應商，且 Tab 鍵自動補全始終使用 Cursor 模型。該公司於 2026 年被 SpaceX 收購。 |
| Devin Desktop（原名 Windsurf） | 沒有 | 2026年6月更名。所有模型均託管於雲端。 |
| Google反重力 | 沒有 | 文件明確指出它不能使用 Ollama、LM Studio 或自訂端點。 |
| Gemini 命令列介面 | 沒有 | 本地支援僅存在於社區分支。 |
| 科多 | 沒有 | 「本地部署」指的是自架的基礎設施，但仍屬於雲端模式。 |
| IDE 中的 GitHub Copilot | 局部的 | 聊天功能可以使用本機模型；即使在自帶密鑰的情況下，內聯補全功能仍然基於雲端。 |
| ChatGPT | 沒有 | 桌面和行動應用是 OpenAI 雲端模型的客戶端。 OpenAI 的開源 GPT-OSS 模型雖然可以在本地運行，但並非透過 ChatGPT 應用，而是透過上述運行時環境運行。 |
| 克勞德 | 沒有 | Claude 應用程式和 Cowork 運行在 Anthropic 的雲端模型上。 Claude Code 可以透過 Ollama 的 Anthropic 相容 API 指向本地模型，雖然這種方法可行，但目前尚未獲得官方支援。 |
| 一般代理助理 | 沒有 | 此類工具在您的電腦上運行，但依賴雲端模型進行推理。 |
市面上有許多「如何將 Cursor 連接到 Ollama」的教程，但 Cursor 官方文件卻與這些教程相矛盾。如果您需要離線操作，那麼這種差異就至關重要了。
影像和視訊生成方面呢？
本地圖像生成是本地人工智慧領域最大的社群之一。僅 ComfyUI 一個工具的 GitHub 星標數就超過了上面排名的絕大多數工具，而本地視訊生成正逐漸成為最消耗顯存的消費級工作負載。它值得擁有自己的排行榜，而且它也確實會擁有一個；在此頁面上添加第四個類別會使其黯然失色。在此之前，本頁的硬體邏輯可以直接應用：圖像和視訊處理比語言模型更依賴內存，並且同樣的層級劃分也適用。
本頁面使用方法
排名遵循三條規則，第一條是目前暫以 GitHub 星標數為依據。這並非理想之選，但它中立、可驗證，而且無需我們假裝測試過實際上並未測試過的內容。閉源工具會被明確標記，且不會被賦予任何虛構的分數。隨著我們自身測試結果的不斷湧現，排名將根據實際測試結果進行調整，屆時我們會做出相應說明；Jan、Open WebUI 和 Ollama 目前已有實驗室數據支持，因此排名調整已經開始。第二條是每個條目都包含一個最小記憶體佔用值，因為該數值決定了模型能否載入。
第三，「指南」欄位是對入選應用程式的專案承諾：每個上榜應用程式都會提供一份基於我們硬體的實際設定指南，其中包含我們的測試資料；套用內建的執行時間環境也會在對應的應用程式指南中介紹；而廠商的各項措施則會在其對應的表格中進行記錄。指南發布後，連結會在此處顯示。
本機LLM工具常見問題解答
我應該從哪個本機LLM工具開始使用？
如果您習慣使用終端，可以選擇 Ollama；如果您喜歡帶有控制項的窗口，可以選擇 LM Studio；如果您想要一款開箱即用、無需安裝任何其他軟體的程序，可以選擇 Jan。這三款軟體都是免費的，都完全離線運行，並且底層都使用 llama.cpp，因此模型行為相同。但速度有所不同：在我們的 RTX 5000 Ada 基準測試中，Ollama 解碼相同模型檔案的速度比 Jan 快 13% 到 18%，因此差異在於介面和各自提供的版本。
NVIDIA ChatRTX、GPT4All 和 Continue.dev 發生了什麼事？
它們已經消失了，還有相當一部分同類產品也隨之消失。在採納任何舊建議之前，了解這一點至關重要。 NVIDIA ChatRTX已於 2026 年 1 月 21 日停止服務，其程式碼庫已存檔，支援論壇也已關閉，目前尚未公佈替代方案。
GPT4All 的情況最為棘手：它已經十二個月沒有提交任何程式碼，最後一次發布是在 2025 年 2 月，但其程式碼庫並未歸檔，且仍然擁有大量的 star 數，因此看起來仍然活躍。它僅支援少數幾種量化格式，並且無法載入大多數最新的模型版本。
Continue.dev曾是本地模式編碼的標準推薦平台，但兩年後被 Cursor 收購，並於 2026 年 6 月停止營運。 Roo Code於 2026 年 5 月關閉，Void於 2026 年 6 月歸檔，Twinny於 2025 年 11 月關閉，Reor於 2026 年 3 月關閉。 Khoj的託管服務於 2026 年 4 月停止運營，但其自託管版本仍然可用。在廠商方面，Intel IPEX-LLM於 2026 年 1 月歸檔，並因已知安全問題而被標記，且未發布遷移方案；NVIDIA RTX AI Toolkit於 2025 年 11 月停止維護。
執行本機LLM需要多少顯存？
對於聊天應用程式來說，8GB 系統記憶體可以運行 3B 級模型，而 16GB 記憶體僅靠 CPU 就能流暢運行 7 到 8B 級模型。為了獲得更流暢的速度，你需要將模型整合到顯存或統一記憶體中：16GB 記憶體可以處理 7 到 14B 級模型，24GB 內存在 Q4 時可以達到 30B 級，而 32GB 或以上的記憶體則能讓智慧程式設計工作不再令人沮喪。超過這個容量後，記憶體容量比頻寬更重要，這就是為什麼配備 96 到 128GB 統一記憶體的機器能夠運行消費級顯示卡無法支援的模型。
本地LLM工具是否使用我的NPU？
通常情況下不會，因為 llama.cpp 沒有 NPU 後端，所以 Ollama 和 LM Studio 在搭載驍龍或 Ryzen 處理器的 AI 機器上會將神經網路引擎的資源佔用率設為 0%，轉而使用 CPU 或 GPU 運作。目前，要呼叫 NPU 需要透過廠商提供的途徑：高通 GenieX、AMD Lemonade（及其 NPU 運行時）、英特爾 OpenVINO，或透過作業系統框架呼叫蘋果的神經網路引擎。這樣做的好處是延長電池續航時間並實現低功耗的持續運行，因為 NPU 的容量目前也只有大約 70 億個，而且獨立 GPU 的吞吐量始終優於 NPU。
我應該在Windows還是Linux系統上執行本機AI？
對於本頁上的桌面應用程序，Windows 和 macOS 的體驗更為流暢。 LM Studio、Jan、AnythingLLM 和 Ollama 皆可原生安裝，GPU 驅動程式也來自常用頻道，無需任何終端機操作。 Linux 的優勢則體現在更底層：生產級伺服器引擎 vLLM 和 SGLang 優先支援 Linux，多 GPU 伺服器也預設使用 Linux，一些最新的加速方案也率先登陸 Linux，例如 AMD 的 Ryzen AI NPU 支持，該支援已在 Linux 上推出，並且需要較新的核心版本。
如今兩者之間的差距比以前小了許多。 AMD 計畫在 2026 年統一其 ROCm 在 Windows 和 Linux 上的發布版本，而 WSL2 則涵蓋了大部分剩餘的兼容性，這也是為什麼像 Open WebUI 這樣的基於 Docker 的工具能夠在 Windows 機器上流暢運行的原因。實用原則是：如果您是從桌面應用程式清單中安裝，請保持在您現有的作業系統上；如果您要建立專用伺服器或尋求各種加速方案，請在 Linux 上建置。
本地模型是否足以取代雲端模型進行編碼？
這完全取決於具體任務，而且這種差異比大多數覆蓋率報告所顯示的要大得多。對於有限範圍的工作、單文件生成、單元測試、樣板程式碼和程式碼解釋，目前在性能良好的工作站上運行的開源模型與前沿雲模型大致相當。但對於長期代理工作、跨大型程式碼庫的多檔案重構，它們明顯遜色，而且失敗模式令人不快：靜默無聲的空操作和明明從未執行過卻被自信地報告的工作。如果您選擇本地部署的原因是出於隱私、實體隔離或成本考慮，那麼目前是可行的。但如果您選擇本地部署的原因是出於能力方面的考慮，那麼目前還不現實。
在本地運行模型比使用雲端服務更安全嗎？
就資料駐留而言，答案是肯定的，這也是大多數人選擇本地部署的原因。但就軟體安全而言，預設情況下答案是否定的：一個本地部署的 AI 應用，即使 CVSS 評分在 2026 年 3 月達到 9.6 分，也可能因為桌面應用打包時使用了不安全的預設設置，而被模型自身的串流輸出驅動，在主機上執行程式碼。本地部署意味著資料不會遷移到本地，但這並不意味著軟體本身就更安全，因為這類應用通常會部署大量快速迭代的程式碼。
什麼是AI代理沙箱？我需要一個用於本地AI的沙箱嗎？
沙箱是一個隔離環境，通常是容器或輕量級虛擬機，人工智慧代理在其中執行其產生的命令和程式碼，從而避免錯誤或惡意指令影響宿主系統。沙箱的存在是因為代理的功能遠不止於回答問題：它們還會運行 shell 命令、編輯文件和瀏覽網頁，而所有這些操作都由模型輸出驅動，這些輸出是可以被操縱的。在本地運行模型並不會改變這個本質。
沙箱機制旨在隔離代理程式的操作，而非模型所在的位置。上文所述的程式碼執行漏洞恰恰印證了這一點，尤其是在本地優先的應用程式中。本頁介紹的部分工具內建了沙箱機制，而那些允許代理程式不受限制地存取主機的工具，在您將其部署到重要機器之前，更應仔細評估。隨著代理程式在企業環境中的應用日益廣泛，沙箱機制有望成為核心功能，我們也將開始在評估這些工具時將其納入考量。
本機硬體能否運作包含數十個子代理程式的代理程式工作負載？
這是前沿領域，簡而言之，單一工作站很快就會達到記憶體不足的極限。多智能體工作負載會產生子智能體，每個子智能體都攜帶自己的上下文，而在推理方面，每個活躍上下文都意味著內存中存在自己的鍵值緩存，因此內存佔用會隨著並發性和模型大小的增加而增加。當快取超出記憶體容量時，這些快取該如何處理，這本身就是一個工程問題；我們基於戴爾和Solidigm硬體所建構的關於鍵值快取卸載到快閃記憶體的深度研究，是我們迄今為止發表的關於該主題的最佳論述。
一台能夠輕鬆處理一個 30B 級代理會話的機器，通常可以透過批次伺服器處理幾個並行會話，延遲才會開始增加；而要處理數十個並發子代理，則需要伺服器，它需要足夠的記憶體來儲存大量即時上下文，以及像 vLLM 這樣專為連續批次設計的伺服器引擎。此外，品質也存在上限，因為隨著工具數量的增加，本地模型的可靠性會下降，而編排操作會增加工具數量和交接次數。
我們認為，單一代理和少代理任務目前屬於工作站的合理工作範疇，而大型子代理集群則屬於基礎設施任務。我們計劃對這一界限以及跨越該界限所需的硬體進行更深入的研究。
Amazon