更新於2026年8月19日：首次發表。研究成果截至該日期為止。
在自己的硬體上運行語言模型而不是在瀏覽器標籤頁中運行，有四個原因，其中只有一個是出於理念上的考慮。隱私性：你交給本地模型的文件永遠不會離開機器，這涵蓋了客戶端程式碼、合約、病患資料和未發布產品的全部通訊過程。成本結構：雲端 AI 按量計費，代理工作負載的令牌數量增長速度足夠快，一台性能強大的工作站就能收回成本；而你自己的硬體運行成本僅為電費。可用性：沒有速率限制，沒有服務中斷，也不會在周二收到棄用通知郵件，從而影響你的工作流程。控制權：你驗證過的模型就是你運行的模型，直到你另行決定。
但另一方面，前沿的雲端模型仍然功能更強大，對於需要長期智能體處理的任務而言，這種差距是真實存在的。本地模型在有限任務方面已經達到了與雲端模型相當的水平，例如聊天、摘要、單一文件代碼和文件問答。而這些恰好涵蓋了大多數人每天的大部分工作。如果您追求的是不惜一切代價實現最大功能，那麼請使用雲端模型。如果您更注重隱私、成本或控制權，那麼本地模型目前仍然可行，而本頁面正是您了解本地模型的指南。
這個框架應該決定你的硬體預算，因為本地AI的投入首先取決於記憶體配置。 16GB顯存或32GB統一記憶體可以滿足7億到8億的模型需求，足以處理上述有限的工作量。 24GB到32GB顯存或48GB統一記憶體可以達到30億的模型需求，此時智能體編碼不再是演示。 96GB到128GB統一記憶體可以運行100億以上的模型，接近前沿品質。過度配置帶來的速度提升可能並不明顯；配置不足則表示你想要的模型根本無法載入。我們的「最佳本地AI筆記型電腦」和「最佳本地AI桌上型電腦」名單按等級對機器進行了排名。本頁面將介紹在這些機器上執行哪些程式。
軟體方面的發展遠不如硬體成熟。如今，搜尋結果推薦的工具裡，大約有三分之一已經失效，而推薦這些工具的大多數網站對此卻渾然不覺。
本頁面記錄了截至 2026 年 8 月哪些工具可用以及支援哪些硬體。目前我們以 GitHub 星號進行排名，因為這是一個中立且可驗證的指標。我們也會在工具為閉源且沒有星標數時進行說明。表格中的每個工具名稱都連結到其官方下載頁面。隨著我們對每個平台進行測試，「指南」一欄會更新，提供實際操作的設定步驟和我們自己的測試資料。
本頁面有三條規則。首先，我們區分本地模型和本地代理。有些產品在您的電腦上運行，但每次推理呼叫都會傳送到供應商的雲端；這屬於隱私保護措施，而非離線功能，這些工具會單獨列在頁面底部，而不是被刪除。其次，每個條目都包含實際的最低硬體配置要求，因為如果沒有記憶體數據，「它可以在筆記型電腦上運行」這樣的描述毫無意義。第三，我們在常見問題中記錄了哪些產品已停止更新，並附上更新日期。
精選推薦
最佳本地LLM運行時間：奧拉瑪
預設答案，也是大多數其他工具所使用的答案。它採用 MIT 許可證，在 GitHub 上擁有約 179,000 個 star，現在除了命令列介面 (CLI) 外，還提供桌面圖形使用者介面 (GUI)。它只需一條命令即可拉取模型，在本地主機上提供一個與 OpenAI 相容的端點，並在 2026 年 1 月增加了對 Anthropic Messages API 的兼容性，用戶現在正是透過該 API 將 Claude Code 指向本地模型。最低配置： 3B 級模型需要 8GB 系統內存，7-8B 級模型需要 16GB 系統內存，30B 級模型需要 24GB 顯存。
最適合硬體基準測試：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 年 7 月版本為 v0.8.4。 Jan 捆綁了 llama.cpp，因此無需安裝其他軟體，即使拔掉網線也能正常運作。乍看之下這似乎要求不高，但當你查看此類應用程式中有多少是帶有 Ollama 欄位的雲端客戶端時，就會發現並非如此。這款應用程式非常適合那些永遠不會打開終端機的同事。文檔混亂是它的弱點。最低配置： 8GB 記憶體。
最佳本機文件 RAG：AnythingLLM
MIT 出品，約有 64,800 個 star。它內建向量資料庫，無需配置即可處理分塊和嵌入，使其成為桌面級文件聊天工具中最開箱即用的軟體。有兩點需要注意：2026 年 3 月發現的一個 CVSS 9.6 級漏洞允許攻擊者利用模型自身的串流響應觸發遠端程式碼執行，該漏洞已在 1.11.2 版本中修復，因此請在使用前更新。此外，該應用程式標榜本地優先，但預設開啟遙測功能，您可以在設定中將其關閉。最低配置需求： 16GB 記憶體（用於文件處理）。
最佳自架多用戶解決方案：Open WebUI
擁有約 149,000 顆星，並提供最深度的檢索配置，v0.11.0 版本將於 2026 年 7 月發布。它是一個自託管伺服器，而非桌面應用程序，因此 Docker 是其入口點。在基於它進行開發之前，需要了解一點：其許可證已於 2025 年 4 月從 BSD-3 更改為未經 OSI 認證的自定義許可證，新增了禁止移除 Open WebUI 品牌標識的條款，並規定在任何 30 天內用戶數量少於 50 人時，不得移除該許可證。小規模運行未修改的版本，對您而言不會有任何變化。最低配置需求：一個獨立的運行時環境，外加 4GB 的容器記憶體。
最佳本地編碼代理商：克萊恩
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 超鏈接
閉源且免費。它會對設備上的整個檔案系統進行索引，並以內聯引用的形式給出答案。它之所以出現在這份清單中，是因為它是唯一一款在消費級硬體上公佈了加速效能資料的全新本地 RAG 工具：在 RTX 5090 顯示卡上，索引速度提升約 3 倍，推理速度提升約 2 倍，處理 1GB 資料夾的時間從大約 15 分鐘縮短到 4 到 5 分鐘。最低配置：現代 RTX GPU；16GB 記憶體。
運行時間：模型實際運作的機制
這是引擎。接下來兩張表中的所有內容都是與這些引擎之一互動的前端。按 GitHub 星標排序。
| 運行時 | 明星 | 執照 | 最低硬體需求 | 加速 | 指南 |
|---|---|---|---|---|---|
| 奧拉馬 | 〜179,000 | 麻省理工學院 | 8GB 記憶體（3B 等級），16GB 記憶體（7-8B 等級），24GB 記憶體（30B 等級） | CUDA、ROCm、Metal、Vulkan | 即將公開資訊 |
| 調用.cpp | 〜124,700 | 麻省理工學院 | 8GB 內存，僅 CPU 工作 | CUDA、ROCm、Metal、Vulkan、SYCL、CANN、OpenCL | 即將公開資訊 |
| MLX / mlx-lm | 〜27,500 | 麻省理工學院 | 蘋果晶片，16GB統一內存 | Metal；CUDA 後端於 2026 年新增 | 即將公開資訊 |
| LM工作室 | 閉源 | 專有技術，可免費用於商業用途 | 16GB 記憶體；24GB 記憶體或 32GB 統一存儲 | 捆綁 llama.cpp 和 MLX | 即將公開資訊 |
| 法學碩士 | 生產服務 | 阿帕奇2.0 | 24GB 顯示 逼真地板 | CUDA、ROCm | 即將公開資訊 |
桌面應用程式和本機 RAG
讀者安裝的應用程式。 「本地優先」一欄需要仔細閱讀：它將運行模型的軟體與新增了 Ollama URL 欄位的軟體區分開來。
| 應用 | 明星 | 執照 | 本地優先 | 最低硬體需求 | 指南 |
|---|---|---|---|---|---|
| 打開網頁介面 | 〜149,000 | 自訂，未經 OSI 認證 | 功能強大，伺服器而非桌面版 | 單獨的運行時記憶體 + 4GB 用於容器 | 即將公開資訊 |
| 任何事法學碩士 | 〜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 年初之前都無法正常工作。其實際後果與直覺相悖：載入過多的 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 也屬於同一級別。任何建議在桌上型電腦上運行這些模型的指南都是錯誤的。
以上吞吐量資料來自已發布的第三方測試和廠商資料，並非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 星標數。這並非理想之選，但它中立、可驗證，而且無需我們假裝測試過實際上並未測試過的內容。閉源工具會明確標註，而非人為設定分數。隨著我們自身測試結果的不斷湧現，排名將根據實際測試結果進行調整，屆時我們將做出相應說明。其次，每個條目都包含一個最小記憶體佔用值，因為該數值決定了模型能否載入。第三，「指南」欄位是一項承諾：我們會為每個平台提供一份基於我們硬體的實際設定指南，並在發布後在此處顯示連結。
本機LLM工具常見問題解答
我應該從哪個本機LLM工具開始使用？
如果您習慣使用終端，可以選擇 Ollama；如果您喜歡帶有控制項的窗口，可以選擇 LM Studio；如果您想要一款開箱即用、無需安裝任何其他軟體的程序，可以選擇 Jan。這三款程式都是免費的，都完全離線運行，並且底層都使用 llama.cpp，因此模型行為相同。差別在於介面，而非速度。
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 後端，因此在驍龍或 Ryzen AI 機器上，Ollama 和 LM Studio 會將神經網路引擎的資源佔用率設為 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 應用在 2026 年 3 月的 CVSS 評分為 9.6，它可能會因為桌面應用打包時使用了不安全的默認設置，而被模型自身的流式輸出驅動，從而在主機上執行代碼。本地部署意味著資料不會移動，但這並不意味著軟體本身就經過了加固，而且這類應用通常會部署大量快速迭代的程式碼。
什麼是AI代理沙箱？我需要一個用於本地AI的沙箱嗎？
沙箱是一個隔離環境，通常是容器或輕量級虛擬機，人工智慧代理在其中執行其產生的命令和程式碼，從而避免錯誤或惡意指令影響宿主機系統。沙箱的存在是因為代理的功能不僅僅是回答問題；它們還會運行 shell 命令、編輯文件和瀏覽網頁，而所有這些操作都由模型輸出驅動，這些輸出可能會被操縱。在本地運行模型並不會改變這個本質。沙箱的意義在於隔離代理的操作，而不是模型所在的位置。上文提到的程式碼執行漏洞正是針對本機優先應用程式的典型案例。本頁介紹的一些工具內建了沙箱功能，而那些允許代理不受限制地訪問宿主機的工具，在您將其用於重要機器之前，需要進行更深入的評估。隨著代理在商業環境中的應用日益廣泛，沙箱功能有望成為核心特性，而非僅僅是一個註腳。我們也將開始在評估這些工具時考慮沙箱的重要性。
本機硬體能否運作包含數十個子代理程式的代理程式工作負載？
這是前沿領域，坦白說，單一工作站很快就會達到記憶體飽和。多智能體工作負載會生成子智能體，每個子智能體都攜帶自己的上下文。在推理方面，每個活躍上下文都意味著記憶體中存在自己的鍵值緩存，因此記憶體佔用量會隨著並發量而增加，而不僅僅是模型大小。當快取超出記憶體容量時，該如何處理這些快取本身就是一個工程問題；我們基於戴爾和Solidigm硬體所建構的關於鍵值快取卸載到快閃記憶體的深度研究，是我們迄今為止發表的關於該主題的最佳論述。一台能夠輕鬆處理一個30B級智能體會話的機器，通常可以透過批次伺服器處理幾個並行會話，而不會出現延遲增加的情況；數十個並發子智能體則需要伺服器來處理，伺服器需要足夠的記憶體來儲存大量活躍上下文，並配備像vLLM這樣專為連續批次而設計的伺服器引擎。此外，品質也存在上限：隨著工具數量的增加，本地模型的可靠性會下降，而編排會增加工具數量和交接次數。我們認為，單一代理和少代理任務目前屬於工作站的合理工作範疇，而大型子代理集群則屬於基礎設施任務。我們計劃對這一界限以及跨越該界限所需的硬體進行更深入的研究。
Amazon