最近不少朋友问我Claude Desktop 到底能不能跑 Qwen、DeepSeek、Kimi 这些模型我的答案是能而且现在跑通的方式比想象中轻松。但我必须先交代一个事实——我第一轮尝试并没有成功卡点不在 Ollama而是在 Claude 生态的接入层。那时候我的思路很直接先把 Ollama 装上把 Qwen3、DeepSeek-R1、Kimi K2 全部拉到本地然后让 Claude Desktop 直接去访问本地模型的接口。听起来顺理成章实际上撞了一鼻子灰。桌面客户端根本不认 Ollama 的地址我换了社区里的一些切换工具结果又报出“cowork requires claude desktop be installed with our modern installer”这类版本检测错误。后来我才搞明白问题出在协议层而不是模型本身。当我把协议层打通之后Qwen、DeepSeek、Kimi 都稳稳跑进了 Claude 的工作流里。这篇文章会把这条弯路完整记录下来。内容包括为什么 Claude Desktop 能接第三方模型、Ollama 首次尝试为什么失败、我现在用的“协议适配层”方案怎么做、三款模型怎么选、参数和常见问题怎么排。想在自己笔记本上跑通这套流程的朋友按顺序抄作业基本就够了。1. 先理清思路你想要的其实不是“跑模型”而是“换脑子”先说清楚一件事Claude Desktop 本身并没有在官方设置里提供一个“选择第三方模型”的入口至少目前我用的版本没有。所谓“支持轻松运行 Qwen、DeepSeek 和 Kimi”准确说是通过 Claude 生态的开放协议把本地模型当成一个符合 Anthropic 规范的服务接入进来。搞懂这个边界之后你会发现这件事不仅可行而且比整天切换网页版、复制粘贴对话内容要舒服得多。1.1 为什么要把第三方模型请到 Claude 工作流里先聊聊需求。我平时写代码、读仓库、做技术方案很多场景会用到 Claude 的对话界面和工具调用能力但实际干活时也有几个痛点。第一是成本。Claude 按订阅或按 API 用量算重度使用的时候账单并不低。DeepSeek 和 Kimi 的 API 价格非常有竞争力Qwen 的开源权重则可以完全本地跑量大不心疼。把这些模型接到同一个工作流里成本和灵活度都能兼顾。第二是数据隐私。有些项目代码和内部文档不适合发到云端 API本地模型就很有意义。Ollama 拉起一个 Qwen3 或者 DeepSeek-R1 蒸馏版完全断网也能用数据不出本机。第三是模型对比。同一个任务我想看看 Qwen3、DeepSeek-R1、Kimi K2 各自的风格和输出质量。如果是网页版来回切换上下文没办法共享在同一个 Claude 工作流里切换模型对比效率会高很多。所以本质不是“非要找个理由让 Claude 跑别的模型”而是“我有一堆模型要做日常任务我希望它们统一服从我习惯的工作流”。Claude 只是一个壳壳里面是谁的大脑由我们来定。1.2 协议才是那把钥匙搞清这一点之后问题的焦点就从“模型怎么装”变成了“协议怎么打通”。Claude Desktop 以及 Claude Code 这类工具走的是 Anthropic Messages API也就是发给 Anthropic 官方服务的请求格式。请求里包含model、system、messages、max_tokens这些字段服务端按这套规则解析并返回结果。Ollama 则不同。它虽然也提供了 HTTP 接口但默认走的是 OpenAI 兼容的/v1/chat/completions格式。两边的字段名字、消息结构、工具调用格式都有差异。你直接把 Claude Desktop 的请求地址指向http://127.0.0.1:11434它俩根本说不上话就像一个是 Type-C 接口的笔记本一个是 Lightning 的线物理上插不进去。要想让它俩合作中间必须放一个“协议转换器”把 Anthropic 格式翻译成 OpenAI 兼容格式再把结果翻译回来。这个转换器我习惯叫“协议适配层”也有人叫网关、桥接名称无所谓核心作用就是那一层翻译。这也是我第一轮尝试时忽略的东西。1.3 选型结论Ollama 负责推理适配层负责翻译第一轮失败之后我做了个反思发现自己把 Ollaoma 的角色弄混了。Ollama 是一个本地模型运行时它负责把模型权重跑起来提供标准 HTTP 接口但它不负责解决 Claude 生态的接入问题。模型本身没有任何问题Qwen3、DeepSeek-R1、Kimi K2 在 Ollama 里都跑得很稳。真正缺的是一个非常薄的适配层。这个适配层监听一个本地端口对外暴露 Anthropic Messages API 格式对内去调用 Ollama 的 OpenAI 兼容接口。Claude Desktop 生态只需要把地址指向这个本地端口就行。想接 API 的话同理适配层可以把请求转给 DeepSeek 官方 API、Qwen 官方 API 或 Kimi API。方案确定之后我用了半天时间重新走了一遍非常顺利。2. 第一次尝试Ollama 顺利跑起来却在接入时撞墙这一部分讲我第一轮的完整过程。Ollama 的表现其实不错问题全出在接入环节我把现场和报错都记录下来方便大家对照避坑。2.1 Ollama 安装与模型拉取的实操记录先交代运行环境。我的主力开发机是 64GB 内存 一张 24GB 显存的显卡系统是 Linux。如果你的设备配置不同后面选模型的步骤需要对应调整。安装 Ollama 没什么难度macOS 和 Windows 直接下载官方安装包Linux 用官方脚本一条命令curl -fsSL https://ollama.com/install.sh | sh安装完确认服务状态ollama --version ollama serveollama serve会把服务启动在127.0.0.1:11434默认监听本机地址。不要修改这个监听地址因为后面适配层也会跑在本机。拉取模型时我发现一个很重要的点Ollama 的模型是分层存储的用ollama pull拉取时先下载模型文件然后再跑一次转换。我第一次拉 Qwen3 的时候看到进度条一直停在某个百分比以为卡住了后来发现只是模型比较大耐心等就好。我实际拉取的模型包括ollama pull qwen3:14b ollama pull deepseek-r1:14b ollama run kimi-k2三个模型全部跑通之后我顺手验证了一下接口curl http://127.0.0.1:11434/v1/chat/completions \ -H Content-Type: application/json \ -d {model: qwen3:14b, messages: [{role: user, content: 你好}], stream: false}返回正常Ollama 这层是没问题的这也为后面排查故障提供了重要线索。2.2 模型挑选与量化选型如果你是第一次跑本地模型容易被“模型体积”吓到。实际上同一个模型有不同精度的量化版本Ollama 默认就是量化过的体积比原始 FP16 权重小不少。选模型的时候我建议先看显存。24GB 显存可以比较舒服地跑 Qwen3 14B 和 DeepSeek-R1 14B 这类规模。如果是 8GB 显存就选 7B/8B 档如果是 32GB 以上可以尝试 32B 档。注意 DeepSeek-R1 有个特殊的地方。R1 模型在回答时会先输出一大段“思考过程”流式输出时你会看到模型不停推理、组织思路然后才给出最终答案。本地部署时如果显存有限建议选蒸馏版本。我用的是 DeepSeek-R1 基于 Qwen 的 14B 蒸馏版效果在代码任务上已经够用。Kimi K2 在 Ollama 里也有可用版本但完整版 K2 对显存的需求非常高本地普通机器跑不动完整版需要看量化后的社区版本。如果只是想体验 Kimi 的代码能力直接用官方 API 可能更实际。2.3 撞墙现场Desktop 端不认 localhost切换工具又报版本错误Ollama 跑通之后我进入第二环节——把 Claude Desktop 指向本地模型。这时候问题来了。我先尝试在 Claude Desktop 的设置里找自定义模型地址发现官方界面没有这个选项。桌面客户端的设计初衷是连 Anthropic 官方服务不开放第三方模型入口。于是我又想能不能修改配置让 Claude Desktop 直接访问本地试了一圈结论是官方桌面客户端不行至少我不能在不破坏安装的情况下做到。接着我转向社区的切换工具。这类工具本质上是辅助 Claude 生态对接不同模型提供商原理就是把 Claude 的请求拦截下来改发到目标模型。我找了一款社区评价不错的工具配置好之后启动结果直接弹出一行报错cowork requires claude desktop be installed with our modern installer这行报错让我很懵。我用的 Claude Desktop 明明是从官网下载安装的为什么工具还认为它“不是现代安装”排查之后发现这个报错其实是工具在检测 Claude Desktop 安装来源。部分历史版本或非官方安装包会被判定为不符合要求即使你自己觉得装得挺干净。问题不在 Ollama也不在模型而在桌面客户端与工具之间的版本兼容。这轮尝试让我明白了一个道理在桌面客户端内部做手脚路线非常脆弱一旦官方更新版本工具就可能失效还会遇到安装检测这类额外的坑。3. 回归正轨用“协议适配层”把 Ollama/API 变成 Claude 认识的服务第一轮受阻之后我换了个思路不去改 Claude Desktop 内部而是在外面加一个适配层让 Claude 生态请求到达一个本地“翻译官”再由它去调度 Ollama 或者各家 API。结果发现这条路顺畅得多。3.1 数据流到底怎么走先把架构画出来你看一眼就明白Claude Desktop / Claude Code ↓ 发送 Anthropic Messages API 格式请求 本地协议适配层监听 127.0.0.1:8787 ↓ 转成 OpenAI 兼容格式 Ollama 本地服务127.0.0.1:11434 ↓ Qwen3 / DeepSeek-R1 / Kimi K2 模型如果是接云端 API最下面一层换成对应的官方 API 地址即可。适配层在整个链路里担任“翻译官”它对上说 Anthropic 语言对下说 OpenAI 兼容语言。为什么这套方案比改桌面客户端稳妥因为桌面客户端完全不感知模型的真实位置它只看到一个符合 Anthropic 规范的本地服务。适配层升级不影响 Claude 客户端Claude 客户端升级也不会破坏适配层的转发逻辑。两边松耦合这才是可以长期用的方案。3.2 三步接通Ollama 就绪、适配层部署、Claude 侧配置第一步确保 Ollama 正常启动并且模型已经拉好这在上文已经完成了。第二步选择一个协议适配层。市面上这类工具很多开源的和商业的都有功能大致相同监听本地端口提供 Anthropic 格式接口通过配置文件把不同模型映射到不同后端。我用的是一个支持多 Provider 的工具配置核心大概长这样{ port: 8787, providers: [ { name: ollama, base_url: http://127.0.0.1:11434/v1, api_key: ollama, models: [ { name: qwen3:14b, max_tokens: 8192 }, { name: deepseek-r1:14b, max_tokens: 8192 }, { name: kimi-k2, max_tokens: 8192 } ] } ] }这里port是适配层监听的端口providers里定义了后端是谁。api_key对本地 Ollama 来说填什么都能通过它不会校验只是占位。启动适配层之后我先用 curl 验证一遍确保它真的能说 Anthropic 语言curl http://127.0.0.1:8787/v1/messages \ -H x-api-key: ollama \ -H anthropic-version: 2023-06-01 \ -H content-type: application/json \ -d { model: qwen3:14b, max_tokens: 256, messages: [{role: user, content: 你好}] }返回正常 JSON 结果后说明协议翻译已经打通。第三步配置 Claude 侧。Claude Code 这类工具支持通过环境变量覆盖 API 地址和模型名我用的配置如下export ANTHROPIC_BASE_URLhttp://127.0.0.1:8787 export ANTHROPIC_AUTH_TOKENollama export ANTHROPIC_MODELqwen3:14b设置完后启动 Claude Code它就会把请求发到本地适配层适配层再转给 Ollama。这一步有一个很小但很关键的细节很多人在 Claude Code 的配置文件里只改了模型名忘了改ANTHROPIC_BASE_URL结果请求还是发往官方服务器。每次调试前先用 curl 检查适配层的返回能帮你快速定位问题。3.3 官方 API 也是同一条路如果你的需求是低成本使用 DeepSeek、Kimi 或 Qwen 的官方 API而不是本地跑模型架构完全一样只是把适配层的后端地址换成各家 API 即可。以 DeepSeek 为例适配层配置里加一个 Provider{ name: deepseek, base_url: https://api.deepseek.com/v1, api_key: 你的 DeepSeek API Key, models: [ { name: deepseek-chat, max_tokens: 8192 }, { name: deepseek-reasoner, max_tokens: 8192 } ] }Qwen 走 DashScope 的 OpenAI 兼容地址Kimi 走 Moonshot 的地址配置格式几乎一样。只需要在 Claude 侧把ANTHROPIC_MODEL设成对应的模型名。举个例子我想让 Claude Code 用 Kimi API就设成ANTHROPIC_MODELkimi-k2-0711-preview。这样做的好处是我的工作流入口始终是 Claude但模型可以在 Qwen、DeepSeek、Kimi 之间一键切换不用改工具链不用重新学习交互方式。4. 三款模型实际体验与参数避坑协议打通只是第一步模型选型和参数调优才是影响体验的大头。我连续用了两周把三款模型的定位和坑摸了个大概。4.1 模型选择速查表模型适合场景本地推荐规模备注Qwen3中文写作、结构化输出、日常任务qwen3:14b 或 qwen3:32b指令遵循能力强输出稳定DeepSeek-R1(蒸馏版)数学推理、代码分析、复杂问题拆解deepseek-r1:14b 或 deepseek-r1:32b思考过程长需要更高上下文预算Kimi K2代码生成、多轮工程对话量化版或直接走官方 API开源版体量偏大硬件门槛高如果你只想装一个模型我建议先试 Qwen3 14B。它在中文和代码任务上比较均衡量化后显存占用也不算夸张。DeepSeek-R1 更适合需要一步一步推导的场景但输出速度明显比 Qwen 慢因为模型先要“思考”很长一段。Kimi K2 的代码能力有惊喜但本地跑起来硬件压力不小没有大显存就直接用 API。4.2 Qwen 输出死循环问题怎么治我在调 Qwen3 的时候遇到一个很典型的问题模型在某一段回答里反复重复相同的话陷入“输出死循环”。这是我在实际使用中最头疼的问题没有之一。排查之后发现原因通常是几个因素叠加。温度参数太高、重复惩罚系数不够、上下文窗口过长导致注意力分散都有可能导致重复。在 Ollama 调接口时可以通过options参数控制{ model: qwen3:14b, messages: [ { role: user, content: 请分析这段代码的时间复杂度 } ], options: { temperature: 0.6, top_p: 0.8, repeat_penalty: 1.1 } }temperature调到 0.6 左右repeat_penalty设为 1.1能明显减少重复输出。另外Qwen3 的指令遵循能力很强我在系统提示词里会加一句“不要重复已经说过的内容直接给出结论。”这个小技巧很有效。还有一个经验低位数量化版本更容易出重复问题。同样的模型Q4_K_M 量化版的死循环概率比 Q8 高一些。如果内存充足优先选更高精度的量化版这比调半天参数省心。4.3 上下文太长与压缩设置本地模型跑起来之后另一个高频问题是上下文长度不够。Claude 生态习惯了一次性塞入很多代码和对话历史但本地模型默认的上下文窗口未必够大。Ollama 可以通过 Modelfile 控制上下文长度FROM qwen3:14b PARAMETER num_ctx 16384然后重新创建模型ollama create qwen3-14b-local -f Modelfile不过要注意上下文窗口越大KV Cache 占用的显存也越多。24GB 显存跑 14B 模型时把num_ctx从 8192 调到 16384显存占用会有明显上涨。如果你发现模型随着对话变长响应越来越慢多半是上下文已经吃满显存、开始用内存做交换了。在 Claude 工作流里还有一层需要考虑Claude Code 把项目文件作为上下文发给模型如果项目很大很容易超窗口。我最常用的办法是定期使用/compact命令压缩历史把早期对话总结成摘要而不是把全部内容都塞给模型。官方 API 对上下文总量也有上限本地模型则要在速度、显存和上下文长度之间做取舍。4.4 拉取模型太慢怎么办这个问题我最初也遇到过。Ollama 的模型文件动辄几个 GB 到几十 GB如果网络链路不理想ollama pull可能等半天。我的经验是分两步走。第一优先选择体积更小的量化档位比如把 32B 换成 Q4_K_M 版本或者直接用 14B。第二如果 Ollama 默认下载源对你来说速度不理想可以直接去模型仓库下载 GGUF 文件再通过本地 Modelfile 导入。ollama create qwen3-14b-from-gguf -f ModelfileModelfile 内容指向你下载好的本地 GGUF 文件FROM /data/models/qwen3-14b-q4_k_m.gguf这种方法的好处是下载链路由你自己控制哪个通道稳定就走哪个通道。文件下载好后导入很快基本是本地磁盘操作。从官网安装 Ollama 主程序如果也遇到下载问题可以通过系统的包管理器装命令会根据系统不同有所区别选一个你熟悉的方式即可。5. 实操中的高频问题与排查速查表最后把我在实际使用中碰到的问题整理成表格方便你在踩坑时快速对照。问题现象可能原因排查/解决方式启动工具时提示“cowork requires claude desktop be installed with our modern installer”Claude Desktop 安装来源或版本不被工具识别从官方渠道下载最新版 Claude Desktop 重新安装避免使用非官方修改版Claude Code 报连接失败ANTHROPIC_BASE_URL没指向本地适配层确认环境变量已设置用 curl 先测适配层返回适配层通但 Ollama 返回无此模型模型名或 tag 不对执行ollama list查看已安装模型名称请求返回 400格式错误请求没有经过适配层直接发给了 Ollama检查 Claude 侧配置的地址是否指向适配层端口模型回答重复、死循环温度过高、重复惩罚不足调低temperature到 0.6 左右调高repeat_penalty上下文溢出num_ctx太小或历史对话塞太多在 Modelfile 里调大num_ctx或用/compact压缩历史本地推理速度越来越慢上下文增长KV Cache 换到内存减小num_ctx或缩短单次对话长度接 DeepSeek/Kimi API 报 401API Key 配错或额度不足检查环境变量里的 Key到对应控制台看余额5.1 “cowork requires claude desktop”报错的真正原因这条值得单独说。第一次遇见这个报错时我以为工具坏了后来才发现是 Claude Desktop 安装包的检测机制。工具为了确保和桌面客户端功能兼容会检查安装路径和安装器来源。如果你系统里残留老版本或者用了非官方打包的绿色版检测就会失败。解决办法是卸载干净之后从官网或者官方渠道重新下载安装包进行安装。装好后先正常登录一次让客户端完成初始化再启动工具。这个顺序不能反否则工具依然会认为你的桌面客户端状态不对。这里面有一个很实用的通用经验当第三方工具对官方软件做版本检测时尽量不要用“绿色版”“汉化版”“修改版”否则排查成本会很高。5.2 调试协议层的小技巧如果你在适配层和 Ollama 之间遇到不确定的问题可以开启 Ollama 的调试日志看请求是否真的到达了 Ollamaexport OLLAMA_DEBUG1 ollama serve日志里能看到每次请求的模型名、参数和耗时。如果请求根本没出现在日志里说明问题出在适配层到 Ollama 这一段如果请求出现了但结果是报错那问题就在 Ollama 的模型配置上。这个定位思路百试百灵。每次我遇到连接问题都会先分三段排查Claude 到适配层通不通、适配层到 Ollama 通不通、Ollama 到模型通不通。一段一段切问题很快就浮出水面。最后再分享一个小技巧实际用下来我的体感是本地模型的能力天花板确实不如各家云端旗舰模型尤其是复杂推理和代码生成DeepSeek-R1 官方版和云端 Kimi K2 的表现明显强于本地量化版。但本地模型的价值在于免费、私密、离线可用而且可以随心所欲地调参数不怕把 API 账单跑爆。我现在的工作流是日常简单问答和中文写作用本地 Qwen3涉及长链路推理或复杂代码重构切到 DeepSeek API工程量大且需要长上下文托底时用 Kimi API。切换只是一个环境变量的事完全不影响我使用 Claude 的交互习惯。还有一个细节接 API 之前在适配层配置里把max_tokens设大一点比如 16384否则长代码生成到一半就被截断排查起来很浪费时间。这套方案我已经稳定用了好几个星期如果你第一次没有跑通别急着放弃把每一层的日志打开看一遍问题通常都在协议字段不匹配上。