之前我一直是 Open WebUI 的忠实用户Docker 部署、局域网共享、插件生态玩了大半年。说实话 Open WebUI 是个好项目功能多到让我一度觉得除了它不需要别的前端。但上个月我把主力方案整体切换到了 DeepSeek 桌面版——社区里通常叫它 deepseek harness缩写 dsh 桌面版甚至在主力机上顺手把 Docker 里的 Open WebUI 容器也清掉了。这篇文章就把我从 WebUI 迁到桌面版的完整过程、配置细节、踩坑记录和选型思路整理出来给正在 WebUI 和桌面客户端之间纠结的朋友一个参考。本文适合这几类人看一是本地或云端部署了 DeepSeek 模型、但现在还在用浏览器网页端做日常交互的二是觉得 Open WebUI 虽然强大但太重、只想轻量跑个对话界面的三是想搞清楚 deepseek harness、hermes、dsh 这些桌面版到底什么关系、值不值得换成它的人。我尽量把能落地的操作和能复现的排查过程都写清楚包括 API 对接、vLLM 本地部署、Codex 接入、上下文续接这些容易出现问题的环节。1. 为什么我决定告别 WebUIOpen WebUI 的日常痛点1.1 部署和运维成本被严重低估Open WebUI 的安装本身不难一条 Docker 命令就能拉起来docker run -d \ --name open-webui \ -p 3000:8080 \ -v open-webui:/app/backend/data \ ghcr.io/open-webui/open-webui:main但装起来和用着舒服是两回事。Open WebUI 迭代速度极快几乎每周都有新版本而每次升级基本都要重新拉镜像、起容器数据卷偶尔还会因为 schema 变更出点小问题。我有一次从 0.3.x 升到 0.4.x整个对话历史全丢了——后来才发现是旧数据卷的目录结构变了迁移脚本没跑对。那次之后我就对面向上级目录的升级有点心理阴影。更现实的问题是Docker 容器常驻意味着内存和 CPU 一直被占着。我的 NAS 兼开发机上同时跑着 vLLM 服务和 Open WebUI16G 内存经常见底。Open WebUI 后端加前端静态资源服务常驻内存轻松跑到 500MB 开外这还没算浏览器标签页的消耗。如果你只是一个人用这个成本其实是很不划算的。1.2 浏览器沙箱对本地任务的天然限制WebUI 跑在浏览器里看起来是优点——随时随地能访问。但真到重度使用时问题就来了。第一个问题是 SSE 流式响应的稳定性。浏览器对长时间保持的连接有自己的策略标签页一旦被系统挂起尤其 Mac 上的 Safari、Windows 上的 Edge 后台节能流式输出就会断开。Open WebUI 有断线重连机制但实测重连之后上下文经常对不上会话记录里会出现一段空白。第二个问题是浏览器标签页的混乱。我习惯同时开着十几个标签页ChatGPT、Claude、Open WebUI、GitHub、文档切换成本极高。WebUI 没有独立窗口没有全局快捷键每次要跟模型对话都必须先找到那个标签页。这个听起来像小事但一天几十次下来效率损耗非常明显。第三个问题是本地文件操作的割裂感。要在 WebUI 里上传一个本地文件让模型分析你得先找到文件、再拖拽到网页里而桌面端可以直接通过系统文件对话框打开甚至可以配置自动读取某个目录的内容。对于经常让模型分析日志、代码仓库的人来说这个体验差异是本质性的。1.3 单人场景下的功能过载Open WebUI 本质上是一个为多人协作设计的项目用户注册、角色权限、聊天室共享、模型组管理、RAG 知识库权限隔离……这些功能在团队场景下非常好用但如果你是个人开发者90% 的功能都用不上却要为它们付出常驻服务和浏览器内存的代价。我并不是说 Open WebUI 不好而是它的定位决定了它更适合部署给一拨人用或者做一个永远在线的服务。如果只是自己跟模型对话、写代码、做分析桌面客户端才是更符合直觉的形态。这就好比你想喝杯手冲咖啡没必要架一台意式商用机。想明白这一点之后我就开始认真考察桌面版方案了。2. 桌面版到底强在哪它不是套壳浏览器是原生客户端2.1 从连接到协议桌面版和 WebUI 的本质区别很多人以为桌面版就是把网页包了个壳用 Electron 套一层就完事。但 DeepSeek 桌面版deepseek harness / dsh走的路线不太一样它是一个原生客户端直接把模型推理引擎的 API 当作后端自己实现会话管理、上下文拼接、参数配置和流式渲染。这个区别在协议层面就体现出来了。WebUI 是你和服务器之间的中间层你的每个请求都先到 WebUI 后端再由它转发给模型服务而桌面版是客户端直连模型 API中间不经过任何 Web 服务。这意味着少了一层转发也就少了一层出错和延迟的可能更重要的是——你可以在断网环境下直接连本地 vLLM 或 Ollama完全离线使用。我自己的实际使用中还有一个很直观的差别桌面版对系统代理、环境变量、API Key 的管理是原生应用级别的调试起来非常直观。比如我同时接了 DeepSeek 官方 API、本地 vLLM、还有第三方兼容接口在 Open WebUI 里要在管理后台反复切换模型配置而在桌面版里就是一个简单的配置文件改完重启即生效。2.2 资源占用实录数据会说话我特意在切换前后做了一组简单的对比环境是同一台 Windows 11 笔记本浏览器都是 Chrome场景都是开着一个对话界面什么都不干观察常驻内存方案常驻内存CPU 空闲占用启动时间离线可用Docker Open WebUI Chrome 标签页约 1.2GB2% 左右波动容器启动约 10s页面加载约 3s依赖本地服务可离线但体验割裂DeepSeek 桌面版约 180MB基本为 03s 内进入界面可直连本地推理服务完全离线ChatGPT 桌面版约 250MB0.5% 左右2s不支持自建模型这个数据不一定精确但量级是可信的。1.2GB 对现在的电脑来说不算什么但问题是 WebUI 方案里浏览器标签页一旦开多了这个数字会翻倍甚至翻三倍而桌面版几乎是一个恒定值。长期开着不关的话桌面版的能耗优势非常明显。2.3 和 ChatGPT 桌面版、Claude 桌面版的定位差异现在各家都出了桌面版但 DeepSeek 桌面版和它们有一个关键差异它是面向自托管模型设计的。ChatGPT 桌面版和 Claude 桌面版本质上只是官方 API 的客户端你没法把它指向本地部署的开源模型也没法自定义 API 接入点。而 dsh 桌面版的核心能力恰恰是灵活对接各种 OpenAI 兼容接口——无论是 DeepSeek 官方 API、vLLM 部署的本地模型、Ollama 拉下来的量化模型还是英伟达 NIM 这类第三方托管服务只要协议兼容都可以接入。这一点对我来说至关重要。我在本机部署了一个蒸馏版 DeepSeek 做日常快速问答同时也会在需要更强推理时调用云端 API。一个客户端能同时管理这两种来源并且能在一个界面里自由切换模型这是 ChatGPT 桌面版给不了的。2.4 关于 deepseek harness 和 hermes 的版本说明社区里这几个名字很容易把人绕晕。我花了一些时间才理清整理如下供参考deepseek harness对 DeepSeek 相关桌面工具链的统称可以理解为DeepSeek 生态的客户端工具箱。dsh 桌面版deepseek harness 的缩写形式GitHub 和社区里普遍用这个简称指代主流的 DeepSeek 桌面客户端。hermes 桌面版同一个工具链中一个比较稳定的发行分支社区里很多人直接用 hermes 版本来指代当前推荐下载的那个桌面版。你在搜索引擎里看到 deepseek hermes 下载、hermes 桌面版无法更新 这类词基本都是围绕这个分支的讨论。我目前在用的就是 hermes 分支的最新版。后面所有操作记录都是基于这个版本展开的。3. 从安装到跑通DeepSeek 桌面版完整实操记录3.1 下载安装与初次启动安装过程没什么特别的从官方或社区推荐的发布渠道下载对应系统的安装包即可——Windows 有 exe 安装器macOS 有 dmgLinux 有 AppImage 或 deb 包。装完第一次启动界面会比 Open WebUI 简洁得多左侧是会话列表中间是对话区右侧是参数面板。初次启动要做的事情只有一件配置一个 API 接入点。点开设置你会发现它不是那种必须注册账号的云端应用而是直接让你填 Base URL 和 API Key。这个设计思路贯穿始终——它就是为开发者设计的工具不是一个面向 C 端的聊天玩具。3.2 对接不同模型服务vLLM、Ollama 与官方 API我同时配了三个接入点分别应对不同场景。这块是很多人配置时最容易出问题的地方我把关键参数和坑都列出来。第一个是 DeepSeek 官方 API。如果你只是想快速跑起来这是最简单的路径Base URL: https://api.deepseek.com API Key: 在 DeepSeek 开放平台创建 Model: deepseek-chat 或 deepseek-reasoner官方 API 兼容 OpenAI 格式所以桌面版里几乎不需要额外配置填上就能用。实测 deepseek-chat 响应速度非常快首 token 延迟通常在 1 秒以内适合日常对话。第二个是本地 vLLM 服务。我在自己的主力机上用 vLLM 部署了一个蒸馏版模型启动命令大致是vllm serve deepseek-ai/DeepSeek-R1-Distill-Qwen-32B \ --port 8000 \ --tensor-parallel-size 2 \ --max-model-len 32768 \ --gpu-memory-utilization 0.9然后桌面版接入点填Base URL: http://localhost:8000/v1 API Key: 随便填一个占位符即可vLLM 默认不校验 Model: deepseek-ai/DeepSeek-R1-Distill-Qwen-32B这里有个坑vLLM 的/v1路径不能漏。我一开始填的是http://localhost:8000结果一直报 404排查了半天才发现 OpenAI 兼容接口的路径前缀是/v1。这个错误非常典型因为官方 API 不需要这个前缀让你误以为本地服务也不需要。第三个是 Ollama。如果你已经有 Ollama 拉好的量化模型桌面版也可以直接对接Base URL: http://localhost:11434/v1 Model: deepseek-r1:7b或你拉取的具体标签Ollama 从某个版本开始也提供了 OpenAI 兼容端点所以对接同样很顺。Ollama 的好处是零配置、零 Python 环境依赖适合笔记本上做快速实验vLLM 的优势是吞吐量大、并发能力强适合接服务。3.3 配置文件的几个关键项桌面版的所有配置最终会落到一个本地配置文件里。这个文件通常在用户目录下不同系统位置不同Windows 一般在%APPDATA%\dsh\config.jsonmacOS 在~/Library/Application Support/dsh/下Linux 在~/.config/dsh/下。配置文件的核心结构大致是{ providers: [ { name: deepseek-official, baseUrl: https://api.deepseek.com, apiKey: sk-xxx, models: [deepseek-chat, deepseek-reasoner] }, { name: local-vllm, baseUrl: http://localhost:8000/v1, apiKey: local, models: [deepseek-ai/DeepSeek-R1-Distill-Qwen-32B] } ], defaultProvider: deepseek-official, defaultModel: deepseek-chat, maxContextTokens: 16384, temperature: 0.7, stream: true }如果你不想手动改配置文件界面里的设置面板也都能操作只是改完要重启才生效。手动编辑的好处是可以批量配置多个 provider而且可以精确控制 maxContextTokens 这类高级参数。3.4 把 Codex 也接到 DeepSeek 上一套 API 多端复用既然桌面版支持 OpenAI 兼容协议那同样协议的工具就都能复用同一个 API。最近我一直在折腾 Codex这个命令行 AI 编程工具本来是为 OpenAI 官方模型设计的但通过环境变量也能指向 DeepSeekexport OPENAI_API_BASEhttps://api.deepseek.com/v1 export OPENAI_API_KEYsk-xxx codex这里有个细节值得注意/v1路径在官方 API 上有时可以省略但在 Codex 这类工具里最好带上因为它会严格拼接路径。实测 Codex 接入 deepseek-chat 之后简单代码生成和重构任务能跑通和官方模型相比速度不差成本却低很多。这个思路可以继续向外延伸。任何支持 OpenAI 协议的工具——比如某些开源 IDE 插件、自动化脚本、RAG 框架——理论上都可以把 Base URL 指到 DeepSeek API 或者本地 vLLM。配好一套到处复用。4. 日常使用中的真实问题对话上限、上下文衔接与更新失败4.1 对话上限之后怎么让新对话承接上一个对话这是我在网上看到讨论频率最高的问题之一DeepSeek 到达对话上限之后怎么让新对话承接上一个对话的内容先说结论桌面版不会像 Open WebUI 那样自动做上下文压缩但也不需要你手动复制粘贴全部历史。正确做法是利用会话摘要——在对话到达上下文上限前先让模型生成一份摘要然后把这份摘要作为新对话的 System Prompt 或第一条消息。我自己写了一个小脚本来自动做这件事核心逻辑是监测当前会话的 token 用量超过阈值时自动抽取对话、生成摘要、开启新会话并注入摘要。简化的核心代码是from openai import OpenAI client OpenAI(api_keysk-xxx, base_urlhttps://api.deepseek.com) def build_messages(history, new_question, max_tokens4096): messages [] total 0 # 防止无限增长至少保留最近几条 for item in reversed(history[-20:]): msg {role: item[role], content: item[content]} tokens len(item[content]) // 2 if total tokens max_tokens: break messages.insert(0, msg) total tokens messages.append({role: user, content: new_question}) return messages这个方案的核心思路是最近优先 关键信息前置。模型对新对话的注意力天然集中在开头和结尾所以把之前的结论和决策放最前面后面再接当前问题效果远好于简单地截断历史。如果你不想写脚本也可以每次手动复制之前的总结放到新对话开头效果八九不离十。4.2 桌面版的会话管理机制和 WebUI 的无限聊天记录不同桌面版对会话的管理更接近 IDE一个项目对应一个会话文件夹每个会话是独立的 Markdown 文件。这个设计的优点是天然的版本管理——你可以直接 diff 两次实验的对话记录甚至把某次对话追加进代码仓库。初始使用时多少会不习惯因为会话列表不会自动膨胀到几百条它严格按你的手动保存来组织。我现在的习惯是每个专题建一个会话比如vLLM 调优、Codex 接入调试、RAG 测试避免把所有问题混在一个长对话里。混在一个长对话里其实是 WebUI 时代留下的坏习惯那样上下文窗口很快耗尽而且查找历史信息非常低效。4.3 装完新版无法启动的常见原因社区里能搜到不少打开闪退、启动报错的问题。我遇到过两次排查下来基本都是老版本配置文件格式不兼容导致的。新版本启动时会读取旧的 config.json如果字段结构变了客户端会直接崩。解决办法是按顺序试这几个操作先备份原配置目录然后删除配置文件让客户端生成一个全新的配置。如果删除后能正常启动说明就是配置文件兼容问题手动把之前的 API 配置重新填一遍。如果删除后仍然闪退检查是不是下载了不匹配系统架构的安装包——比如在 ARM 版 Windows 上装了 x64 的包或者 32 位系统装了 64 位应用。这条排查路径适用于大多数装完打不开的桌面软件不只是 DeepSeek 桌面版。我之前用 ChatGPT 桌面版和 Claude Code 桌面版也遇到过类似问题基本都是同一个思路解决的。4.4 工作流保存桌面版怎么管理预设WebUI 时代大家习惯保存工作流比如代码审查 Prompt、日报生成 PromptOpen WebUI 把这套做成了可视化流程编辑器。切到桌面版之后很多人第一个疑惑就是我的工作流怎么办实际体验下来桌面版的回答方式更直接把工作流拆成人设预设System Prompt 参数预设Temperature、Max Tokens 模型绑定。你在配置里存好这几样就等价于一个工作流。它不做可视化连线但胜在简洁、可版本管理、没有额外心智负担。我的做法是维护一个预设仓库每个预设是一个 Markdown 文件格式大致是# 预设代码审查专家 model: deepseek-reasoner temperature: 0.3 max_tokens: 8192 --- 你是一位资深代码审查专家。请从正确性、性能、安全性、可维护性四个维度 审查用户提供的代码按严重程度排序输出问题并给出修改建议。使用时直接把内容填到预设面板或者让我自己写了一个小脚本读取仓库自动同步桌面版配置。这样工作流不仅没丢还比 WebUI 时代更透明、更好维护。5. 适用边界哪些场景该留在 WebUI哪些适合上桌面版5.1 什么时候我还是会开 Open WebUI桌面版不是万能的有些场景它确实替代不了 Open WebUI。最典型的是多人共享场景。团队里如果有人不太懂技术你不可能让他去配置 API Key、理解 provider 概念。这时候 Open WebUI 这种网页服务就非常合适部署好之后大家只需要浏览器访问一个地址注册账号就能用权限和限额在后台统一管理。我团队内部的知识库问答机器人至今仍跑在 Open WebUI 上。另一个场景是移动端访问。桌面版目前没有完整的移动端配套如果你需要在手机上随时找模型对话WebUI 的响应式页面仍然是不可替代的。我自己的折中方案是移动端轻量聊天用官方 App深度工作留在桌面版。5.2 桌面版目前还不够好的地方客观说几个让我不太满意的点省得你们踩同样的坑一是插件生态还是太薄。Open WebUI 有丰富的函数插件、工具插件市场而桌面版目前主要靠配置文件类扩展面向普通用户的插件系统还在早期。如果你重度依赖 WebUI 的 RAG 知识库、语音对话、多模态附件这类开箱即用功能桌面版暂时会有点裸奔感。二是多模态支持仍然有限。DeepSeek 官方 API 本身以文本为主本地部署的模型很多也是纯文本。图片直接拖进桌面版对话框目前只能作为引用文件模型并不能真正看图。这个能力 OpenAI 桌面版和 Claude 桌面版已经做得比较完善DeepSeek 桌面版还需要时间。三是更新机制略微激进。hermes 分支的更新频率很高有时候一两周就推送一个新版本。我遇到过两次更新后模型列表里的自定义模型名称变了——因为新版本对模型名的解析规则做了调整。建议每次更新完都检查一下 provider 配置别等到要用了才发现异常。5.3 一张表说清选型逻辑我把自己试过的几个方案放在一起做了一张对比表你可以根据自己的情况对号入座维度Open WebUIDeepSeek 桌面版dsh/hermes官方网页版适用场景团队共享、局域网服务个人深度学习、开发者日常快速体验、手机端部署复杂度高Docker 数据卷 升级维护低安装即用零部署本地模型接入支持但需额外配置后端原生支持配置简单不支持上下文管理自动历史但不可控手动会话精准可控官方限制离线可用依赖本地服务部署直接连本地推理引擎不可用资源占用高常驻服务 浏览器低原生客户端中浏览器成本硬件 运维时间几乎为零按订阅/API 计费扩展生态插件丰富预设文件为主无适合人群团队管理者、服务部署者开发者、研究者、重度个人用户普通用户5.4 我个人的最终结论如果你是一个人用并且手上已经有了本地推理服务或者 DeepSeek 的 API Key那桌面版dsh / hermes 分支几乎是无脑选择。它省掉了 Docker 那层依赖省掉了浏览器标签页的管理负担省掉了很多无意义的配置步骤换来的是更低的资源占用和更高的操作效率。如果你是要给团队做服务或者需要随时随地用手机访问那 Open WebUI 依然有它不可替代的位置。最后分享一个我在实际使用中养成的习惯桌面版的所有配置我都在同步到一个 git 仓库里包括 config.json、预设 Markdown、对接脚本。这样不管换了新电脑还是版本升级出问题拉一次代码就能完全恢复环境。这个习惯在换机或重装系统时帮我省了大量时间也让我更愿意深度依赖这个工具。现在我的主力工作流已经完全跑在 DeepSeek 桌面版上Open WebUI 的容器只在我需要给团队成员开知识库服务时才会启动。 
长河君 · 2026/10/5 5:48:23 · 阅读 1.2k 告别 Open WebUI：DeepSeek 桌面版迁移与本地部署踩坑指南
之前我一直是 Open WebUI 的忠实用户Docker 部署、局域网共享、插件生态玩了大半年。说实话 Open WebUI 是个好项目功能多到让我一度觉得除了它不需要别的前端。但上个月我把主力方案整体切换到了 DeepSeek 桌面版——社区里通常叫它 deepseek harness缩写 dsh 桌面版甚至在主力机上顺手把 Docker 里的 Open WebUI 容器也清掉了。这篇文章就把我从 WebUI 迁到桌面版的完整过程、配置细节、踩坑记录和选型思路整理出来给正在 WebUI 和桌面客户端之间纠结的朋友一个参考。本文适合这几类人看一是本地或云端部署了 DeepSeek 模型、但现在还在用浏览器网页端做日常交互的二是觉得 Open WebUI 虽然强大但太重、只想轻量跑个对话界面的三是想搞清楚 deepseek harness、hermes、dsh 这些桌面版到底什么关系、值不值得换成它的人。我尽量把能落地的操作和能复现的排查过程都写清楚包括 API 对接、vLLM 本地部署、Codex 接入、上下文续接这些容易出现问题的环节。1. 为什么我决定告别 WebUIOpen WebUI 的日常痛点1.1 部署和运维成本被严重低估Open WebUI 的安装本身不难一条 Docker 命令就能拉起来docker run -d \ --name open-webui \ -p 3000:8080 \ -v open-webui:/app/backend/data \ ghcr.io/open-webui/open-webui:main但装起来和用着舒服是两回事。Open WebUI 迭代速度极快几乎每周都有新版本而每次升级基本都要重新拉镜像、起容器数据卷偶尔还会因为 schema 变更出点小问题。我有一次从 0.3.x 升到 0.4.x整个对话历史全丢了——后来才发现是旧数据卷的目录结构变了迁移脚本没跑对。那次之后我就对面向上级目录的升级有点心理阴影。更现实的问题是Docker 容器常驻意味着内存和 CPU 一直被占着。我的 NAS 兼开发机上同时跑着 vLLM 服务和 Open WebUI16G 内存经常见底。Open WebUI 后端加前端静态资源服务常驻内存轻松跑到 500MB 开外这还没算浏览器标签页的消耗。如果你只是一个人用这个成本其实是很不划算的。1.2 浏览器沙箱对本地任务的天然限制WebUI 跑在浏览器里看起来是优点——随时随地能访问。但真到重度使用时问题就来了。第一个问题是 SSE 流式响应的稳定性。浏览器对长时间保持的连接有自己的策略标签页一旦被系统挂起尤其 Mac 上的 Safari、Windows 上的 Edge 后台节能流式输出就会断开。Open WebUI 有断线重连机制但实测重连之后上下文经常对不上会话记录里会出现一段空白。第二个问题是浏览器标签页的混乱。我习惯同时开着十几个标签页ChatGPT、Claude、Open WebUI、GitHub、文档切换成本极高。WebUI 没有独立窗口没有全局快捷键每次要跟模型对话都必须先找到那个标签页。这个听起来像小事但一天几十次下来效率损耗非常明显。第三个问题是本地文件操作的割裂感。要在 WebUI 里上传一个本地文件让模型分析你得先找到文件、再拖拽到网页里而桌面端可以直接通过系统文件对话框打开甚至可以配置自动读取某个目录的内容。对于经常让模型分析日志、代码仓库的人来说这个体验差异是本质性的。1.3 单人场景下的功能过载Open WebUI 本质上是一个为多人协作设计的项目用户注册、角色权限、聊天室共享、模型组管理、RAG 知识库权限隔离……这些功能在团队场景下非常好用但如果你是个人开发者90% 的功能都用不上却要为它们付出常驻服务和浏览器内存的代价。我并不是说 Open WebUI 不好而是它的定位决定了它更适合部署给一拨人用或者做一个永远在线的服务。如果只是自己跟模型对话、写代码、做分析桌面客户端才是更符合直觉的形态。这就好比你想喝杯手冲咖啡没必要架一台意式商用机。想明白这一点之后我就开始认真考察桌面版方案了。2. 桌面版到底强在哪它不是套壳浏览器是原生客户端2.1 从连接到协议桌面版和 WebUI 的本质区别很多人以为桌面版就是把网页包了个壳用 Electron 套一层就完事。但 DeepSeek 桌面版deepseek harness / dsh走的路线不太一样它是一个原生客户端直接把模型推理引擎的 API 当作后端自己实现会话管理、上下文拼接、参数配置和流式渲染。这个区别在协议层面就体现出来了。WebUI 是你和服务器之间的中间层你的每个请求都先到 WebUI 后端再由它转发给模型服务而桌面版是客户端直连模型 API中间不经过任何 Web 服务。这意味着少了一层转发也就少了一层出错和延迟的可能更重要的是——你可以在断网环境下直接连本地 vLLM 或 Ollama完全离线使用。我自己的实际使用中还有一个很直观的差别桌面版对系统代理、环境变量、API Key 的管理是原生应用级别的调试起来非常直观。比如我同时接了 DeepSeek 官方 API、本地 vLLM、还有第三方兼容接口在 Open WebUI 里要在管理后台反复切换模型配置而在桌面版里就是一个简单的配置文件改完重启即生效。2.2 资源占用实录数据会说话我特意在切换前后做了一组简单的对比环境是同一台 Windows 11 笔记本浏览器都是 Chrome场景都是开着一个对话界面什么都不干观察常驻内存方案常驻内存CPU 空闲占用启动时间离线可用Docker Open WebUI Chrome 标签页约 1.2GB2% 左右波动容器启动约 10s页面加载约 3s依赖本地服务可离线但体验割裂DeepSeek 桌面版约 180MB基本为 03s 内进入界面可直连本地推理服务完全离线ChatGPT 桌面版约 250MB0.5% 左右2s不支持自建模型这个数据不一定精确但量级是可信的。1.2GB 对现在的电脑来说不算什么但问题是 WebUI 方案里浏览器标签页一旦开多了这个数字会翻倍甚至翻三倍而桌面版几乎是一个恒定值。长期开着不关的话桌面版的能耗优势非常明显。2.3 和 ChatGPT 桌面版、Claude 桌面版的定位差异现在各家都出了桌面版但 DeepSeek 桌面版和它们有一个关键差异它是面向自托管模型设计的。ChatGPT 桌面版和 Claude 桌面版本质上只是官方 API 的客户端你没法把它指向本地部署的开源模型也没法自定义 API 接入点。而 dsh 桌面版的核心能力恰恰是灵活对接各种 OpenAI 兼容接口——无论是 DeepSeek 官方 API、vLLM 部署的本地模型、Ollama 拉下来的量化模型还是英伟达 NIM 这类第三方托管服务只要协议兼容都可以接入。这一点对我来说至关重要。我在本机部署了一个蒸馏版 DeepSeek 做日常快速问答同时也会在需要更强推理时调用云端 API。一个客户端能同时管理这两种来源并且能在一个界面里自由切换模型这是 ChatGPT 桌面版给不了的。2.4 关于 deepseek harness 和 hermes 的版本说明社区里这几个名字很容易把人绕晕。我花了一些时间才理清整理如下供参考deepseek harness对 DeepSeek 相关桌面工具链的统称可以理解为DeepSeek 生态的客户端工具箱。dsh 桌面版deepseek harness 的缩写形式GitHub 和社区里普遍用这个简称指代主流的 DeepSeek 桌面客户端。hermes 桌面版同一个工具链中一个比较稳定的发行分支社区里很多人直接用 hermes 版本来指代当前推荐下载的那个桌面版。你在搜索引擎里看到 deepseek hermes 下载、hermes 桌面版无法更新 这类词基本都是围绕这个分支的讨论。我目前在用的就是 hermes 分支的最新版。后面所有操作记录都是基于这个版本展开的。3. 从安装到跑通DeepSeek 桌面版完整实操记录3.1 下载安装与初次启动安装过程没什么特别的从官方或社区推荐的发布渠道下载对应系统的安装包即可——Windows 有 exe 安装器macOS 有 dmgLinux 有 AppImage 或 deb 包。装完第一次启动界面会比 Open WebUI 简洁得多左侧是会话列表中间是对话区右侧是参数面板。初次启动要做的事情只有一件配置一个 API 接入点。点开设置你会发现它不是那种必须注册账号的云端应用而是直接让你填 Base URL 和 API Key。这个设计思路贯穿始终——它就是为开发者设计的工具不是一个面向 C 端的聊天玩具。3.2 对接不同模型服务vLLM、Ollama 与官方 API我同时配了三个接入点分别应对不同场景。这块是很多人配置时最容易出问题的地方我把关键参数和坑都列出来。第一个是 DeepSeek 官方 API。如果你只是想快速跑起来这是最简单的路径Base URL: https://api.deepseek.com API Key: 在 DeepSeek 开放平台创建 Model: deepseek-chat 或 deepseek-reasoner官方 API 兼容 OpenAI 格式所以桌面版里几乎不需要额外配置填上就能用。实测 deepseek-chat 响应速度非常快首 token 延迟通常在 1 秒以内适合日常对话。第二个是本地 vLLM 服务。我在自己的主力机上用 vLLM 部署了一个蒸馏版模型启动命令大致是vllm serve deepseek-ai/DeepSeek-R1-Distill-Qwen-32B \ --port 8000 \ --tensor-parallel-size 2 \ --max-model-len 32768 \ --gpu-memory-utilization 0.9然后桌面版接入点填Base URL: http://localhost:8000/v1 API Key: 随便填一个占位符即可vLLM 默认不校验 Model: deepseek-ai/DeepSeek-R1-Distill-Qwen-32B这里有个坑vLLM 的/v1路径不能漏。我一开始填的是http://localhost:8000结果一直报 404排查了半天才发现 OpenAI 兼容接口的路径前缀是/v1。这个错误非常典型因为官方 API 不需要这个前缀让你误以为本地服务也不需要。第三个是 Ollama。如果你已经有 Ollama 拉好的量化模型桌面版也可以直接对接Base URL: http://localhost:11434/v1 Model: deepseek-r1:7b或你拉取的具体标签Ollama 从某个版本开始也提供了 OpenAI 兼容端点所以对接同样很顺。Ollama 的好处是零配置、零 Python 环境依赖适合笔记本上做快速实验vLLM 的优势是吞吐量大、并发能力强适合接服务。3.3 配置文件的几个关键项桌面版的所有配置最终会落到一个本地配置文件里。这个文件通常在用户目录下不同系统位置不同Windows 一般在%APPDATA%\dsh\config.jsonmacOS 在~/Library/Application Support/dsh/下Linux 在~/.config/dsh/下。配置文件的核心结构大致是{ providers: [ { name: deepseek-official, baseUrl: https://api.deepseek.com, apiKey: sk-xxx, models: [deepseek-chat, deepseek-reasoner] }, { name: local-vllm, baseUrl: http://localhost:8000/v1, apiKey: local, models: [deepseek-ai/DeepSeek-R1-Distill-Qwen-32B] } ], defaultProvider: deepseek-official, defaultModel: deepseek-chat, maxContextTokens: 16384, temperature: 0.7, stream: true }如果你不想手动改配置文件界面里的设置面板也都能操作只是改完要重启才生效。手动编辑的好处是可以批量配置多个 provider而且可以精确控制 maxContextTokens 这类高级参数。3.4 把 Codex 也接到 DeepSeek 上一套 API 多端复用既然桌面版支持 OpenAI 兼容协议那同样协议的工具就都能复用同一个 API。最近我一直在折腾 Codex这个命令行 AI 编程工具本来是为 OpenAI 官方模型设计的但通过环境变量也能指向 DeepSeekexport OPENAI_API_BASEhttps://api.deepseek.com/v1 export OPENAI_API_KEYsk-xxx codex这里有个细节值得注意/v1路径在官方 API 上有时可以省略但在 Codex 这类工具里最好带上因为它会严格拼接路径。实测 Codex 接入 deepseek-chat 之后简单代码生成和重构任务能跑通和官方模型相比速度不差成本却低很多。这个思路可以继续向外延伸。任何支持 OpenAI 协议的工具——比如某些开源 IDE 插件、自动化脚本、RAG 框架——理论上都可以把 Base URL 指到 DeepSeek API 或者本地 vLLM。配好一套到处复用。4. 日常使用中的真实问题对话上限、上下文衔接与更新失败4.1 对话上限之后怎么让新对话承接上一个对话这是我在网上看到讨论频率最高的问题之一DeepSeek 到达对话上限之后怎么让新对话承接上一个对话的内容先说结论桌面版不会像 Open WebUI 那样自动做上下文压缩但也不需要你手动复制粘贴全部历史。正确做法是利用会话摘要——在对话到达上下文上限前先让模型生成一份摘要然后把这份摘要作为新对话的 System Prompt 或第一条消息。我自己写了一个小脚本来自动做这件事核心逻辑是监测当前会话的 token 用量超过阈值时自动抽取对话、生成摘要、开启新会话并注入摘要。简化的核心代码是from openai import OpenAI client OpenAI(api_keysk-xxx, base_urlhttps://api.deepseek.com) def build_messages(history, new_question, max_tokens4096): messages [] total 0 # 防止无限增长至少保留最近几条 for item in reversed(history[-20:]): msg {role: item[role], content: item[content]} tokens len(item[content]) // 2 if total tokens max_tokens: break messages.insert(0, msg) total tokens messages.append({role: user, content: new_question}) return messages这个方案的核心思路是最近优先 关键信息前置。模型对新对话的注意力天然集中在开头和结尾所以把之前的结论和决策放最前面后面再接当前问题效果远好于简单地截断历史。如果你不想写脚本也可以每次手动复制之前的总结放到新对话开头效果八九不离十。4.2 桌面版的会话管理机制和 WebUI 的无限聊天记录不同桌面版对会话的管理更接近 IDE一个项目对应一个会话文件夹每个会话是独立的 Markdown 文件。这个设计的优点是天然的版本管理——你可以直接 diff 两次实验的对话记录甚至把某次对话追加进代码仓库。初始使用时多少会不习惯因为会话列表不会自动膨胀到几百条它严格按你的手动保存来组织。我现在的习惯是每个专题建一个会话比如vLLM 调优、Codex 接入调试、RAG 测试避免把所有问题混在一个长对话里。混在一个长对话里其实是 WebUI 时代留下的坏习惯那样上下文窗口很快耗尽而且查找历史信息非常低效。4.3 装完新版无法启动的常见原因社区里能搜到不少打开闪退、启动报错的问题。我遇到过两次排查下来基本都是老版本配置文件格式不兼容导致的。新版本启动时会读取旧的 config.json如果字段结构变了客户端会直接崩。解决办法是按顺序试这几个操作先备份原配置目录然后删除配置文件让客户端生成一个全新的配置。如果删除后能正常启动说明就是配置文件兼容问题手动把之前的 API 配置重新填一遍。如果删除后仍然闪退检查是不是下载了不匹配系统架构的安装包——比如在 ARM 版 Windows 上装了 x64 的包或者 32 位系统装了 64 位应用。这条排查路径适用于大多数装完打不开的桌面软件不只是 DeepSeek 桌面版。我之前用 ChatGPT 桌面版和 Claude Code 桌面版也遇到过类似问题基本都是同一个思路解决的。4.4 工作流保存桌面版怎么管理预设WebUI 时代大家习惯保存工作流比如代码审查 Prompt、日报生成 PromptOpen WebUI 把这套做成了可视化流程编辑器。切到桌面版之后很多人第一个疑惑就是我的工作流怎么办实际体验下来桌面版的回答方式更直接把工作流拆成人设预设System Prompt 参数预设Temperature、Max Tokens 模型绑定。你在配置里存好这几样就等价于一个工作流。它不做可视化连线但胜在简洁、可版本管理、没有额外心智负担。我的做法是维护一个预设仓库每个预设是一个 Markdown 文件格式大致是# 预设代码审查专家 model: deepseek-reasoner temperature: 0.3 max_tokens: 8192 --- 你是一位资深代码审查专家。请从正确性、性能、安全性、可维护性四个维度 审查用户提供的代码按严重程度排序输出问题并给出修改建议。使用时直接把内容填到预设面板或者让我自己写了一个小脚本读取仓库自动同步桌面版配置。这样工作流不仅没丢还比 WebUI 时代更透明、更好维护。5. 适用边界哪些场景该留在 WebUI哪些适合上桌面版5.1 什么时候我还是会开 Open WebUI桌面版不是万能的有些场景它确实替代不了 Open WebUI。最典型的是多人共享场景。团队里如果有人不太懂技术你不可能让他去配置 API Key、理解 provider 概念。这时候 Open WebUI 这种网页服务就非常合适部署好之后大家只需要浏览器访问一个地址注册账号就能用权限和限额在后台统一管理。我团队内部的知识库问答机器人至今仍跑在 Open WebUI 上。另一个场景是移动端访问。桌面版目前没有完整的移动端配套如果你需要在手机上随时找模型对话WebUI 的响应式页面仍然是不可替代的。我自己的折中方案是移动端轻量聊天用官方 App深度工作留在桌面版。5.2 桌面版目前还不够好的地方客观说几个让我不太满意的点省得你们踩同样的坑一是插件生态还是太薄。Open WebUI 有丰富的函数插件、工具插件市场而桌面版目前主要靠配置文件类扩展面向普通用户的插件系统还在早期。如果你重度依赖 WebUI 的 RAG 知识库、语音对话、多模态附件这类开箱即用功能桌面版暂时会有点裸奔感。二是多模态支持仍然有限。DeepSeek 官方 API 本身以文本为主本地部署的模型很多也是纯文本。图片直接拖进桌面版对话框目前只能作为引用文件模型并不能真正看图。这个能力 OpenAI 桌面版和 Claude 桌面版已经做得比较完善DeepSeek 桌面版还需要时间。三是更新机制略微激进。hermes 分支的更新频率很高有时候一两周就推送一个新版本。我遇到过两次更新后模型列表里的自定义模型名称变了——因为新版本对模型名的解析规则做了调整。建议每次更新完都检查一下 provider 配置别等到要用了才发现异常。5.3 一张表说清选型逻辑我把自己试过的几个方案放在一起做了一张对比表你可以根据自己的情况对号入座维度Open WebUIDeepSeek 桌面版dsh/hermes官方网页版适用场景团队共享、局域网服务个人深度学习、开发者日常快速体验、手机端部署复杂度高Docker 数据卷 升级维护低安装即用零部署本地模型接入支持但需额外配置后端原生支持配置简单不支持上下文管理自动历史但不可控手动会话精准可控官方限制离线可用依赖本地服务部署直接连本地推理引擎不可用资源占用高常驻服务 浏览器低原生客户端中浏览器成本硬件 运维时间几乎为零按订阅/API 计费扩展生态插件丰富预设文件为主无适合人群团队管理者、服务部署者开发者、研究者、重度个人用户普通用户5.4 我个人的最终结论如果你是一个人用并且手上已经有了本地推理服务或者 DeepSeek 的 API Key那桌面版dsh / hermes 分支几乎是无脑选择。它省掉了 Docker 那层依赖省掉了浏览器标签页的管理负担省掉了很多无意义的配置步骤换来的是更低的资源占用和更高的操作效率。如果你是要给团队做服务或者需要随时随地用手机访问那 Open WebUI 依然有它不可替代的位置。最后分享一个我在实际使用中养成的习惯桌面版的所有配置我都在同步到一个 git 仓库里包括 config.json、预设 Markdown、对接脚本。这样不管换了新电脑还是版本升级出问题拉一次代码就能完全恢复环境。这个习惯在换机或重装系统时帮我省了大量时间也让我更愿意深度依赖这个工具。现在我的主力工作流已经完全跑在 DeepSeek 桌面版上Open WebUI 的容器只在我需要给团队成员开知识库服务时才会启动。