Ollama 0.40.11 實戰：在 Windows 上執行本機 LLM

Ollama 0.40.11 為 Windows 使用者提供了一個桌面聊天應用程式和一個用於其他軟體的本機模型執行環境。 Ollama 也超越了其原始的命令列介面，新增了可搜尋的模型選擇器、圖像附件以及指向編碼工具的連結。一些用於測試的控制項仍然保留在 PowerShell 和模型設定檔中。

我們在一台運行 Windows 11 專業工作站版、配備 128GB 記憶體和 NVIDIA RTX 5000 Ada Generation GPU 的 HP Z4 Rack G5 機架式工作站上安裝了 Ollama。我們使用現有的 Jan V3.5 4B 和 Jan V2 VL High GGUF 資料集，測試了其生成速度、聊天、圖像、線上搜尋和本地 API 的效能。 Ollama 運行我們的本機模型效果良好，但匯入 GGUF 和收集效能資料時會暫時中斷桌面聊天功能。這是我們本地 LLM 系列的第三款應用，前兩款分別是Jan和Open WebUI，測試結果將用於我們的「最佳本地 LLM 工具」頁面。

測試系統

元件	型號
操作系統	Windows 11 Pro for Workstations
中央處理器	英特爾至強W5-2465X，16核
記憶體應用	128GB
GPU	NVIDIA RTX 5000 Ada 一代
顯存	32GB（報告顯示為 32,760 MiB）
NVIDIA驅動程序	597.06
CUDA 相容性	13.2（由 nvidia-smi 報告）
奧拉馬	0.40.11
推理運行時	Ollama llama.cpp 運行器（未記錄建置編號）

安裝 Ollama 並開始使用

在我們的 Windows 工作站上安裝 Ollama 的過程令人欣喜，這與我們在安裝本系列其他應用程式時遇到的一些麻煩截然不同。我們下載了標準的 Windows 安裝程序，啟動了應用程序，無需安裝單獨的推理運行時或查找 CUDA 套件。透過 PowerShell 快速檢查確認 Ollama 0.40.11 正在運行，並且其本機服務已在 http://127.0.0.1:11434 上回應。

經過歡迎介面後，Ollama 打開了熟悉的聊天介面，左側邊欄包含最近的對話、應用程式和設定。訊息框內集中了附件按鈕、網路搜尋和模型選擇器。我們可以直接與匯入的本機模型聊天，無需建立帳戶。不過，在測試過程中，當我們嘗試啟用網路搜尋時，Ollama 會提示我們登入。

瀏覽和新增模型

Ollama 的模型選擇介面相當簡潔，下拉式選單中既有已安裝的模型，也有可供下載的模型。我們可以看到導入的 Jan 模型和 Qwen3-VL，以及一些基於雲端的模型，這些模型都以一個小雲圖示標識。此外，還有一個搜尋框用於查找其他模型，不過我們希望在這裡看到更多信息，例如模型大小、量化等級和硬體要求。 Jan 透過其模型中心提供這些詳細信息，而 Ollama 則將大部分此類資訊隱藏在主聊天介面之外。

將兩個基準模型匯入 Ollama 的流程比較繁瑣，因為我們希望使用與先前評測完全相同的 GGUF 文件，以盡可能保持效能測試的可比性。雖然 Ollama 允許透過其桌面介面直接下載模型，但我們找不到匯入工作站上已儲存的 GGUF 檔案的選項。因此，我們不得不使用 PowerShell，為每個模型建立一個 Modelfile 文件，該文件指向其現有的 GGUF 文件，並包含先前測試中使用的取樣參數。然後，我們使用… ollama create 命令將它們添加到 Ollama 的模型庫中。

兩次導入均順利完成，Jan V3.5 顯示正常。 jan-v35-sr 以及 Jan V2 VL 高 jan-v2-sr我們也透過 Ollama 直接下載了 Qwen3-VL 4B，用於單獨的影像分析測試。

導入模型後，我們檢查了 Ollama 如何識別這些模型，以及它們的設定是否正確導入。 Jan V2 VL High 被識別為一個使用 Q4_K_M 量化的 8.2 億參數 Qwen3-VL 模型，這與我們的原始文件相符。 Jan V3.5 是個例外，因為我們導入的 GGUF 被命名為 Jan-v3.5-4B-Q4_K_XL.gguf但 Ollama 將其量化類型報告為 Q4_K_M。我們沒有更改原始檔案；可能的原因是 Q4_K_XL 是 Unsloth 的動態量化，主要由 Q4_K_M 層建構而成，並且檔案的元資料記錄了該基本類型。

模型設定與 GPU 使用狀況

Ollama 的設定頁麵包含雲端存取、自動更新、網路存取、模型儲存路徑以及上下文長度滑桿，我們首次查看時顯示的是 32K。我們的效能測試透過 API 明確請求了 8,192 個令牌，因此以下基準測試結果使用的是該上下文，而非桌面預設上下文。

由於 Ollama 的桌面介面提供的模型配置功能不如 Jan 強大，我們主要透過模型檔案和 API 請求進行調整。為了確保基準測試的可比較性，我們使用了與先前測試相同的設定：溫度 0.8，Top K 40，Top P 0.95，Min P 0.05，重複懲罰 1.0。我們也要求了 2,048 的批次大小，但我們無法獨立驗證 Ollama 在生成過程中是否套用了該設定。

GPU 配置也不同，因為沒有像 1 月那樣的桌面設定來對應 100 個 GPU 層。 Ollama 會自動處理 GPU 卸載，快速檢查如下： ollama ps 已確認兩款進口機型均完全基於 RTX 5000 Ada 運作。

我們已將該報告與 NVIDIA 自身的數據進行了核實。 Jan V3.5 在載入後將顯存分配增加了數 GB，並且在生成過程中，即時讀數達到了 93% 的 GPU 利用率。 Jan V2 也報告了 GPU 完全駐留，並在我們的診斷運行中顯示 96% 的利用率。至少在這台工作站上，我們無需透過單獨的 CUDA 變體或 GPU 層設定即可實現加速生成。

本地發電性能

為了進行代數測試，我們使用了與一月份發布的實踐指南中相同的提示：“向首次搭建 NAS 的用戶解釋 RAID 5 和 RAID 6。請用大約 400 字概括它們各自的主要優缺點。” 我們禁用了網絡搜索，將上下文設置為 8,192 個字元，並且每個 API 請求中只包含這條用戶。我們捨棄了每個模型的一個預熱響應，然後收集了三個測量運行結果。

兩個模型均順利完成了全部三次測試運行，未出現任何生成故障，且整個測試過程中 GPU 利用率始終保持在高位。 Ollama 無需額外的 CUDA 配置或手動調整 GPU 圖層即可使兩個模型完全啟用 GPU 加速，而 Open WebUI 則需要手動新增 CUDA 執行時間 DLL。

型號	量化	輸出代幣	解碼速度	GPU內存
Jan V3.5 4B	Q4_K_XL 檔案*	529	145.48 噸/秒	5,082 MiB
一月 V2 VL 高	Q4_K_M	1,696	92.87 噸/秒	7,124 MiB

注意：輸出令牌計數、解碼速度和 GPU 記憶體使用量均為三次測量運行的中位數，其中一次預熱運行已被捨棄。 GPU 記憶體使用量為每次測量運行期間記錄的 GPU 記憶體峰值使用量的中位數。

*Jan V3.5 GGUF 檔案名稱標識為 Q4_K_XL，而 Ollama 的型號資訊報告為 Q4_K_M；請參閱上面的匯入說明。

Jan V3.5 在測量的運行中分別記錄了 145.48、145.73 和 145.44 個 tokens/秒，而 Jan V2 則記錄了 92.87、92.22 和 92.97 個 tokens/秒。兩組資料在每次運行中都保持接近，每組資料中測得的 GPU 記憶體峰值也沒有變化。 Jan V2 產生的輸出 tokens 數量明顯較多，顯然包含了推理活動，因此這些總數並不能直接比較可見答案的長度。

在同一工作站和模型文件上，這些是目前為止該系列測試中最快的結果。 Jan V3.5 的解碼速度比Jan本身快 18%（123 個令牌/秒），比Open WebUI Desktop快 26% （115.32 個令牌/秒）；Jan V2 比 Jan 快 13%（82 個令牌/秒），比 Open WebUI 快 24%（75.06 個令牌）。每個應用程式運行各自的 llama.cpp 版本，並以各自的方式管理 GPU 卸載，因此比較結果反映的是每個應用程式提供的完整軟體包的效能，而不僅僅是模型本身。

我們沒有公佈快速處理時間的中位數，因為重複請求產生的處理時間非常短，快取可能會對此產生影響。此外，運行時設定也不可能完全相同：Jan 直接暴露了 GPU 層，而 Ollama 則自動管理了卸載。

使用 Ollama 進行本地聊天

模型安裝完成後，我們從下拉式選單中選擇 Jan V3.5 或 Jan V2，並輸入 RAID 提示字元。答案以標題和清單的形式顯示，而最近的對話則保留在側邊欄中。 Ollama 沒有在回復下方顯示生成率或令牌計數，因此我們透過其 API 取得了這些資料。

在 Ollama 中管理對話非常簡單，右鍵點選先前的對話即可選擇重新命名或刪除，更多工具下方還有「分享」選項。我們也可以傳回編輯已發送的提示，但模型回應的選項相對較少。我們找到的唯一按鈕是“複製”，即使滑鼠懸停在回復上，它也會一直顯示在回復下方。至少在我們測試的版本中，我們找不到從聊天視窗重新產生回應或查看回覆產生統計資料的方法。

Ollama 還提供了一個應用專區，其中包含 Codex CLI、Claude Code、OpenCode 和 Cline 等編碼助手。為了了解這些整合是如何運作的，我們點擊了 Codex CLI，看看需要進行哪些設定。 Ollama 沒有打開配置介面，而是將啟動命令複製到剪貼簿，並提示我們將其貼上到終端機中。我們沒有完成完整的安裝或執行 Codex，但這讓我們更了解了 Ollama 如何將本機模型連接到外部應用程式。

站內搜索

Ollama 在聊天視窗的附件控制項旁放置了一個地球圖示按鈕，但點擊後會顯示一則訊息，提示「網路搜尋需要 Ollama 帳戶」。註冊免費帳戶並啟用該功能後，我們使用了現有的測試問題，要求用戶提供截至 2026 年 10 月 15 日的最新穩定版 Open WebUI 版本，並附上來源引用。

我們在測試 Ollama 的網頁搜尋功能時遇到了另一個問題：應用程式嘗試檢索結果，但卻傳回了「搜尋 API 錯誤（狀態碼 402）」訊息。 HTTP 402 是「需要付費」代碼，表示該搜尋服務需要付費套餐，儘管 Ollama 並未明確說明這一點。模型提示問題可能與帳戶定價或使用限制有關，但我們無法確定具體原因。由於我們的本機模型運作正常，我們決定不再花時間排查搜尋服務的故障。儘管如此，我們仍然感到失望，因為我們無法完成與本系列其他應用程式相同的網頁搜尋測試。

多模式輸入

我們第一次影像測試使用了與 Jan 系統中另一台視覺投影機相容的 Jan V2 VL High GGUF 語言模型。 Ollama 接受了該語言模型文件，但我們的匯入流程未能關聯到對應的 mmproj 檔案。當我們嘗試將 NVIDIA 螢幕截圖附加到 Jan V2 對話中時，桌面應用程式在發送提示之前就顯示「此模型不支援圖像」。

然後我們嘗試了透過 Ollama 下載的 Qwen3-VL 4B，並沿用了相同的提示，要求輸入 GPU 型號、驅動版本、顯存大小、利用率、溫度和功耗。此型號成功識別了螢幕截圖，並最終給出了正確的六個數值：RTX 5000 Ada Generation、驅動版本 597.06、顯存 32,760 MiB、利用率 0%、溫度 39°C 和功耗 40W。不過，它的反應並非完美無缺，因為在最終結果中，它短暫地錯誤地顯示了 8% 的利用率，但隨後才修正了該值。

在 Ollama 中，我們無法像在其他應用程式中那樣，直接將 Windows 截圖工具中的圖片貼到聊天視窗中。我們必須先儲存螢幕截圖，然後使用訊息框旁邊的「+」按鈕上傳。這種方法沒有出現任何問題，Ollama 的 Qwen3-VL 模型也成功分析了圖片。然而，我們導入的 Jan V2 模型無法接受相同的附件，這限制了我們重複原始多模態測試的能力。

本地 API 伺服器

Ollama 的本機 API 在其 Windows 服務啟動後即可使用，無需從桌面介面啟動單獨的伺服器。向 Ollama 發送請求 http://127.0.0.1:11434/v1/models 我們退回了已安裝的 Jan V3.5 和 Qwen3-VL 型號，並提出了一項請求 /v1/chat/completions 使用 Jan V3.5 產生了關於 RAID 6 的一句話解釋。

回應中使用了略微不精確的 RAID 6 奇偶校驗措辭，這是模型輸出問題，而非 API 故障。正常工作的端點允許我們直接從 PowerShell 查詢本機模型，而無需使用桌面聊天。

什麼地方出了錯

我們遇到的最棘手的問題是導入的 Jan V2 VL High 模型無法處理影像。匯入 GGUF 檔案或在 GPU 加速下執行文字提示時，一切正常，但當我們嘗試附加 NVIDIA 螢幕截圖時，情況就發生了變化。 Ollama 提示模型不支援影像，因為我們匯入的檔案缺少 Jan V2 所需的獨立視覺投影機。不過，我們仍然可以使用 Ollama 提供的 Qwen3-VL 下載套件完成影像分析測試，並且運作正常。這表明 Ollama 可以處理圖像，但要讓現有的 Jan V2 模型也實現相同的功能，但不像導入其 GGUF 檔案那麼簡單。

要使用網頁搜尋功能，我們必須先建立一個 Ollama 帳戶才能啟用它。登入並提交測試問題後，服務傳回了 HTTP 402 錯誤，並且沒有搜尋結果。我們無法確定錯誤原因，而且在不確定是否有效的情況下，也沒有理由繼續更改帳戶設定或嘗試不同的套餐。

我們也注意到，我們經常需要返回 PowerShell 來完成諸如導入現有模型、調整設定和收集效能指標等任務。桌面應用程式雖然便於日常溝通，但它提供的控制等級遠不及 Jan 的介面。除了這些問題之外，Ollama 在測試過程中幾乎沒有給我們帶來任何麻煩：兩個模型都成功導入，所有六次基準測試都順利完成，本地 API 也運作正常。

結語

我們使用 Ollama 0.40.11 進行的測試總體進展順利，尤其是在 RTX 5000 Ada 上運行本地模型方面表現出色。我們匯入的兩個 GGUF 檔案均實現了完整的 GPU 加速，無需任何額外的 CUDA 設置，並且效能領先於其他版本。其中，Jan V3.5 的平均速度達到了 145.48 個 tokens/秒，Jan V2 VL High 達到了 92.87 個 tokens/秒，是該系列中最快的，比同一工作站上的 Jan 快了 13% 到 18%。配置完成後，我們在桌面聊天介面和本機 API 之間切換自如，所有基準測試均順利完成。

雖然我們很喜歡 Ollama 在日常聊天中的簡潔性，但我們更希望桌面應用程式能提供對各個模型更精細的控制。使用 PowerShell 並建立模型檔案來匯入我們現有的 GGUF 模型增加了一些額外的步驟，尤其與 Jan 相比，Jan 的大部分設定都可以在介面中直接找到。對於已經熟悉運行本地模型的用戶來說，這可能不會造成什麼困擾，但對於希望透過圖形介面管理所有功能的新手來說，Ollama 的功能可能會有所限制。此外，我們在使用 Web 搜尋和導入的視覺模型時也遇到了一些問題，不過這些問題都沒有影響正常的文字生成。

我們最喜歡 Ollama 的一點是，它可以輕鬆地將本地模型提供給其他應用程序，而無需我們配置單獨的伺服器。桌面聊天功能上手簡單，而本機 API 和對外部編碼工具的支持，讓使用者能夠做的遠不止與本機模型聊天。我們仍然希望在桌面介面中看到更完善的模型管理控制，但 Ollama 在我們的工作站上表現出色，並為我們提供了一種可靠的方式，利用 GPU 加速運行我們的兩個測試模型。

排行榜： Ollama 在我們的「最佳本地 LLM 工具」頁面上獲得了「最佳本地 LLM 運行時」的稱號，該結果現在與我們的 1 月份和 Open WebUI 資料並列顯示。