Jan AI 與 GPT4All：離線聊天、文件與 API 存取

Jan 和 GPT4All 都是免費、離線優先的桌面聊天應用程式，可執行本機 GGUF 模型，也能指向代管 API，但只有其中一個仍在持續發布版本：Jan 的儲存庫在 2026 年 9 月 18 日仍有程式碼提交，而 GPT4All 的最新版本是 2025 年 2 月 25 日發布的 v3.10.0，此後唯一的提交是一項 CI 雜務。 這不代表 GPT4All 已經死亡——它沒有被封存，仍然可以下載，而且其檢索行為的文件比 Jan 更完整。這表示選擇取決於任務，而不是人氣。

先釐清兩個容易混淆的名稱，因為兩者都很容易在發布時誤寫。位於 jan.ai 的 Jan 不是 Janitor AI——產品不同、受眾不同，彼此沒有關係。此外，nomic.ai 上的 「$20/月」橫幅不是 GPT4All 的價格：它屬於 Nomic Platform，這是一款提供圖紙審查與法規遵循功能的建築與營造代理產品。GPT4All 本身採用 MIT 授權且免費。

依任務選擇，而不是依星數選擇

GPT4All 有 77,394 顆星，Jan 有 44,551 顆（GitHub API，2026 年 9 月 19 日）。它是知名度較高的名稱，也是更新較不及時的程式碼庫。以下根據真正會影響選擇的面向做出判斷：

簡短版：除非有特定因素讓你只能選 GPT4All，否則選 Jan——例如 Intel Mac（Jan 明確排除）、受限制的軟體清單，或偏好一個已停止變動、不會再讓你措手不及的程式碼庫。當你需要的是一個凍結且有文件說明的資料夾索引器時，選 GPT4All。

離線聊天與文件工作流程

這是兩者真正分歧的面向，而且不是那些比較文章所比較的面向。

GPT4All LocalDocs 使用 Nomic 的免費裝置端嵌入模型建立資料夾索引，並讓你在回應下方點選 Sources，查看引用了哪些檔案。其 設定預設值 具體明確，在指定文件資料夾前值得先了解：片段大小為 512 個字元，每次提示最多包含 3 個片段。兩者都可以調高，而文件警告調高後會使生成速度變慢。

至於會建立索引的檔案類型，GPT4All 的兩個來源彼此不一致，而且已發布的來源較舊：設定頁列出 .txt、.pdf、.md 和 .rst；而發布版本原始碼中的預設值——localdocs/fileExtensions（位於 mysettings.cpp 的 main）——則是 docx、pdf、txt、md、rst。LocalDocs 在 v3.4.0 新增了 .docx 支援，因此文件頁面似乎尚未更新。聊天附件是另一條路徑，有自己的清單：ChatView.qml 中的附件對話框會篩選 *.txt *.md *.rst *.xlsx——依據 變更記錄，Excel 附件在 v3.4.0 加入，文字、Markdown 與 rst 則在 v3.5.0-rc1 加入。該篩選器不包含 PDF，因此 PDF 必須透過 LocalDocs 集合傳給模型，否則就完全不會傳入。

Jan Projects 支援更廣泛的檔案類型：「PDF、Markdown、Office 文件（DOCX、XLSX、PPTX）、程式碼檔案等」，會將檔案分塊並建立索引，供該專案中的所有對話檢索使用，並為每個檔案顯示進度列和分塊數量。不過，Jan 的文件未指明嵌入模型、片段大小或檢索上限。同一頁的隱私說明指出，所有檔案都在您的電腦上本機處理；若您使用雲端供應商，「檔案會作為請求的一部分，傳送至該供應商的 API」。文件並未說明，對於已建立索引的專案檔案與聊天附件，分別適用上述哪種情況，也未說明透過閘道連線的自訂供應商屬於哪一類，因此應將這些視為文件尚未說明的事項，而非已有定論。

兩者都適用的一項界線是：嵌入步驟不是由 Kunavo 提供的服務。 Kunavo 提供聊天模型。GPT4All 預設會在你自己的裝置上計算嵌入，或在你啟用後使用 Nomic 自己的 API；Jan 的引擎文件將這個步驟列為 llama.cpp 可用、MLX 不可用，且未指定任何模型。如果你想完整了解檢索端到端的實作，RAG 實作涵蓋相關組件。

模型、硬體，以及各應用程式實際能執行的內容

Jan 在 llama.cpp 或 MLX 上執行本機模型；後者僅支援 Apple Silicon，且需要 macOS 14+。它會從自己的 Hub 下載 GGUF 模型，也能匯入磁碟上已有的 GGUF 檔案，直接連結原檔而不複製。GPT4All 提供一個精選目錄，應用程式會從 models3.json 擷取該目錄——共有 32 個項目，最新的是 2025 年 1 月的 DeepSeek-R1 蒸餾模型，沒有 Qwen3、Gemma 3 或 Llama 4（截至 2026 年 9 月 19 日檢查）。其 Explore Models 頁面也會在 Hugging Face 搜尋 GGUF 檔案，因此目錄不是硬性限制——但這個精選貨架足以合理反映該專案停止維護已有多久。

Jan 的數據來自其 Mac 與 Windows 安裝頁面；GPT4All 的數據來自其 系統需求表 與 README。所有內容均於 2026 年 9 月 19 日查閱。

GPT4All 在兩個硬體問題上自相矛盾，而且兩者都沒有明確答案。 關於 Intel Mac，其 README 表示 macOS 版本「需要 Monterey 12.6 或更新版本」，並指出 Apple Silicon 結果最佳，讀起來像是 Intel 可運作；但其系統需求表在 Apple CPU 與 GPU 列標示 M1，且任何地方都沒有列出 Intel 處理器。關於 Windows on ARM，README 連結至 win64-arm 安裝程式，並表示該版本「支援 Qualcomm Snapdragon 與 Microsoft SQ1/SQ2 處理器」；然而 README 自己指向的需求表卻表示不支援搭載 ARM CPU 的 Windows 與 Linux PC。v3.10.0 發布版本的資產中確實包含 win64-arm 安裝程式；README 對它的連結是在該標籤建立十分鐘後提交的，即 2025 年 2 月 25 日，而需求表自 2024 年 9 月 13 日後就沒有提交。因此 README 是較新的說法——但本頁無法替你解決任一矛盾。對 Intel Mac 而言，GPT4All 是兩者中唯一值得嘗試的選項，因為 Jan 明確排除 Intel；在任何 ARM 裝置上，請先安裝並驗證，再決定是否採用。

還有一項值得指出的缺口：nomic.ai/gpt4all 提供四個下載按鈕，沒有版本號、變更記錄或系統需求；而 gpt4all.io 上的四個安裝程式啟動檔，其 Last-Modified 日期都為 2025 年 2 月 4 日——早於 v3.10.0 標籤。它們是線上安裝程式，因此很可能會在安裝時擷取目前版本，但我找不到它們用來取得更新的儲存庫。不要從下載頁面假定特定版本；安裝後請查看 About。

本機 API 伺服器、雲端存取，以及哪些內容會離開裝置

兩個應用程式都提供與 OpenAI 相容的伺服器，讓其他工具能與它們目前載入的模型通訊；對共用裝置而言，兩者的預設值差異很重要。

資料來自 Jan 的 Local API Server 與 API preference 頁面，以及 GPT4All 的 API server 文件，查閱日期為 2026 年 9 月 19 日。Jan 的伺服器文件記載其由 llama.cpp 驅動，範例全都使用本機模型；文件沒有說明遠端自訂供應商模型是否能透過連接埠 1337 存取——這是未記載，而非排除，因此在依賴它建置前請自行驗證。

在隱私方面，Jan 的 Mac 安裝頁面指出模型、執行緒、設定與記錄檔都位於 ~/Library/Application Support/Jan/data，且不會傳送任何內容至雲端；但其檔案上傳頁面同樣明確表示，使用雲端供應商時，檔案會作為請求的一部分傳送至該供應商的 API。兩個應用程式都能離線使用，但不是只能離線使用；一旦設定遠端供應商，通常的資料處理問題就適用於接收資料的對象。

讓任一應用程式使用一組託管金鑰

本機模型路徑每次請求不收費，但會受限於硬體能容納的範圍。兩個應用程式的替代方案都是設定基礎 URL 與金鑰。這是兩者差異最大的地方。

Jan 方面的資訊來自其 Custom Endpoints 頁面，該頁明確將閘道與代理列為支援情境。GPT4All 方面則來自 main 上的發布原始碼：四個供應商卡片與 OpenAI 白名單位於 AddRemoteModelView.qml，三個欄位標籤位於 RemoteModelCard.qml，URL 建構位於 chatllm.cpp，硬式編碼的 "stream": true 與 Authorization: Bearer 標頭位於 chatapi.cpp。以上內容均未經執行期測試。

GPT4All 那個沒人寫下來的事實：其內建 OpenAI 卡片是硬式編碼的白名單，註解為 // last updated 2025-02-24，只包含 gpt-3.5-turbo、gpt-3.5-turbo-16k、gpt-4、gpt-4-32k、gpt-4-turbo 和 gpt-4o。即使使用有效的第一方 OpenAI 金鑰，該卡片也無法提供 OpenAI 後來發布的模型。Groq 與 Mistral 卡片也帶有相同註解日期的凍結清單——不過 Mistral 的清單包含 -latest 別名，這些別名仍會解析至 Mistral 今日提供的內容，因此對 Mistral 而言，「凍結清單」不代表「凍結模型」。若要在 OpenAI 形式的金鑰上使用比 gpt-4o 更新的模型，Custom 卡片就是途徑——直接使用或透過閘道使用皆可。

還有一個最容易造成混淆的 Jan 注意事項：由於 Jan 無法偵測自訂供應商的能力，您手動新增的模型預設未勾選工具能力，而 MCP 需要使用具備此能力的模型。請在模型上勾選此能力，而不只是於供應商上勾選。

對 Kunavo 而言，兩個應用程式使用的值相同——基礎 URL 為 https://api.kunavo.com/v1，Bearer 金鑰以 sk-kn- 開頭。在 Jan 中選擇與 OpenAI 相容的格式，讓它填入模型清單；在 GPT4All 中，請精確輸入模型 ID，例如 claude-sonnet-4-6，因為 GPT4All 會將 /chat/completions 附加到你提供的任何基礎 URL，且永遠不會檢查 ID。Jan 的 Anthropic 相容格式也能連線至 Anthropic 形式的端點，但 Jan 的文件只說「使用閘道文件所指定的基礎 URL」，而其範例省略了 /v1——本頁未測試 Jan 在該路徑需要哪一個基礎字串，因此除非你準備好進行實驗，否則請使用 OpenAI 格式。

# Both apps need the same two things: a base URL that ends in /v1 and a
# Bearer key. This is the check to run BEFORE you type either into an app.
curl -s https://api.kunavo.com/v1/models \
  -H "Authorization: Bearer sk-kn-..."

# Jan calls this exact path to populate its model list.
# GPT4All never calls it for a Custom provider — you type the id by hand.

託管路徑的成本估算範例

這些是用於示範的 token 計算，並非實測任務成本，也不是帳單金額上限。假設一個以文件為主的工作階段會傳送 30,000 個未快取的輸入 token，內容包含系統提示、檢索出的片段與持續累積的對話，並接收 2,000 個輸出 token，每月重複 50 次。費率採用 Kunavo 目錄中每百萬 token 的即時價格。

請注意檢索設定如何影響上述算術。GPT4All 預設最多使用 3 個、每個 512 字元的片段——按照常見的每四個字元約等於一個 token 的估算，約為 400 個 token——因此在這些預設值下，使用託管金鑰的 LocalDocs 提示，其成本只比周圍的純聊天高一點。調高任一設定後，成本會按比例增加。Jan 完全沒有發布上限，因此專案檔案在提示中的占比取決於索引器。如果從 GPT4All 切換到 Jan 後帳單出乎意料地增加，這種不對稱性是首先應檢查的地方。

在將這些數字視為預算前，請依照自己的使用量調整；另請注意，任一應用程式的本機模型路徑完全沒有每次請求費用——取而代之的是硬體與電力成本。Kunavo 的目錄金額是計費下限，而非上限：當上游回報其費用時，帳單金額取目錄成本與上游成本乘以適用加成兩者中的較高者。快取費用與外部工具不包含在此範例中。最低加值金額是預付額度 $10，這是資金最低門檻，而非任務費或訂閱費——請參閱 計費詳細資訊。

安裝、維護與授權界線

所有列均於 2026 年 9 月 19 日從 GitHub 與 PyPI API 及各專案的發布清單查閱。日期有兩項注意事項：jan.ai 的 變更記錄 將 v0.8.4 日期列為 2026 年 7 月 21 日，而 GitHub 發布版本標記為 7 月 23 日，因此上方寫作「2026 年 7 月」；GPT4All 自己的變更記錄將 v3.10.0 日期列為 2 月 24 日，而發布標籤日期為 2 月 25 日。

以下謹慎說明兩項所有權細節，因為證據只能支持到這個程度。Jan 由 Jan 團隊在 GitHub 組織 janhq 下以開放方式開發；該組織的個人檔案目前只顯示「Jan」，而較舊的 menloresearch/jan URL 會以 HTTP 301 重新導向至該網址。Jan 的 LICENSE 檔案仍列有 Menlo Research 的著作權，而獨立的 menloresearch 組織目前描述的是一項人形機器人產品。我找不到任何有日期的公告來解釋這項變更，因此本頁不宣稱發生分拆或出售，只陳述重新導向與兩個個人檔案所顯示的內容。GPT4All 的維護者明顯已改變業務：nomic.ai 首頁的標題如今關於設計與建築，其產品頁面則是用於圖面審查與程式碼合規的代理平台。GPT4All 頁面只是遺留內容。Nomic 未對 GPT4All 的狀態發布任何聲明，而標題為 「Is GPT4all dead?」 的問題仍處於開放且未解決狀態。

任何 GPT4All 頁面都應包含一項使用者保護提醒：nomic.ai 沒有提供行動版。 其 GPT4All 頁面提供四個桌面安裝程式，除此之外沒有其他內容；GitHub 發布版本也只有桌面資產。儲存庫中的一個2024 年問題於 2024 年 12 月 20 日提出，並以不計畫處理結案；該問題提到一個名為 com.principia_tech.ai.gpt4all 的 Google Play 套件，回報者表示它與該專案無關，且必須先觀看廣告才能進行對話。請只從 nomic.ai 或 GitHub 發布頁面下載。也不要將此專案與無關的「GPT4Free」混淆。

設定託管路徑

Kunavo 尚未對任一應用程式與其端點進行執行期測試，且兩者都沒有 Kunavo 設定頁面——以上內容均來自官方文件，GPT4All 的部分另來自發布原始碼。可驗證的是兩個應用程式所需的形式：一個以 /v1 結尾、相容於 OpenAI 的基礎 URL、一個 Bearer 金鑰，以及可運作的 GET /v1/models，讓 Jan 能填入其清單。請先執行上方的冒煙測試，在嘗試期間保留一條可運作的路徑，然後執行一項有界限的任務，並查看你的帳戶實際為此記錄的費用。

準備為金鑰儲值時，建立 Kunavo 帳戶。如需背景資訊，OpenAI 相容 API說明兩個應用程式使用的線路格式，最佳 LLM 閘道涵蓋如何比較託管選項；如果你仍在選擇桌面用戶端，AnythingLLM 與 Open WebUI比較兩個以文件為核心、同樣採用免費應用程式與按量計費 API 分離模式的替代方案。

常見問題

截至 2026 年 9 月 19 日查閱：兩個 GitHub 儲存庫 API、兩個發布清單、gpt4all 的 PyPI 記錄、GPT4All 精選模型目錄與安裝程式標頭、nomic.ai 部落格標籤連結、menloresearch/jan 重新導向、jan.ai 的變更記錄與定價 URL、Jan 的安裝、檔案上傳、MCP、API 伺服器與自訂端點文件、GPT4All 的 LocalDocs、設定與 API 伺服器文件、其 README、變更記錄、模型頁面與系統需求表、上方連結的兩個問題串、README 與需求表的提交歷史，以及 main 上的 GPT4All 原始碼——遠端供應商檢視畫面、ChatView.qml 的附件篩選器，以及 localdocs/fileExtensions 在 mysettings.cpp 中的預設值。未檢查：任一應用程式對 Kunavo 端點的實際執行工作階段、GPT4All 線上安裝程式今日提供的版本，以及 Jan 自訂供應商模型是否能透過 Jan 自己的本機伺服器存取。Kunavo token 費率來自即時目錄；本文每個美元範例都是說明性的 token 算術，而非實測任務成本。