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 高	问题4	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 数据并列显示。