上个月有个做外包的朋友问我想在本地跑大模型做代码辅助模型和数据都留在内网但用 Ollama 拉下来的模型ClaudeCode 总是接不进去要么格式不对要么工具调用乱来。这个问题其实挺普遍的本地部署大模型和 ClaudeCode 之间缺的不只是一个地址而是协议兼容性和工程化的最后一步。这几天我抽空把 Unsloth Desktop 完整跑了一遍从下载模型、推理、量化到把它变成 ClaudeCode 的本地后端过程远比想象中顺也踩了几个比较隐蔽的坑。先说结论如果你手里有一张 8GB 以上显存的显卡或者不太想为 ClaudeCode 这类代码 Agent 付订阅费Unsloth Desktop 是目前把“本地部署 代码助手”打通得比较舒服的一个图形化工具。它兼顾了 Ollama/LM Studio 的易用性又在模型导入、量化、微调层面做了很多优化。下面这篇文章就是我的完整上手实测包含硬件选型、实操步骤、ClaudeCode 接入方式和问题排查适合正在折腾本地大模型、大模型微调以及想让 ClaudeCode 跑在本地模型上的人。1. Unsloth Desktop是什么和 Ollama、LM Studio 有什么区别1.1 本地部署工具的两条路线如果只聊本地跑大模型大家最先想到的通常不是同一个东西。Ollama 是命令行起步的模型运行时主打极简装完后拉模型、起服务、暴露 OpenAI 兼容接口所以它很容易被 Dify、n8n 这类应用接走。LM Studio 则是图形化路线界面更像一个聊天软件同时提供本地 API 服务器很多 Windows 用户习惯用它来管理 GGUF 模型。另一条路线是“训练/微调工具”。Unsloth 本来就是开源社区里很有名的 LoRA 微调加速库之前一直是 Python 库形态让开发者用几行代码完成 QLoRA 微调。它的特点是用自定义内核把训练效率拉高同时把显存峰值压得很低。Unsloth Desktop 就是把这套内核做成了 Graph UI顺便把模型下载、推理、量化这些日常操作也搬了进来。它本质上不是又一个 ChatGPT 皮肤而是把“跑模型”和“改模型”放在同一个工作台里。所以理解这款软件不能只从“聊天”或“API 服务”单个角度去看。它更适合被理解成一套面向本地大模型的集成环境先下载模型然后在图形界面推理测试觉得回答风格不对就用 Unsloth 的高效微调内核做 LoRA 微调最后导出成 GGUF或直接把它作为 ClaudeCode 的兼容后端。1.2 三个不可忽视的差异第一点是显存利用率。Unsloth 团队长期在做“降低显存占用”这件事桌面版继承了这套优化。同样在 4090 24GB 显卡上别人大概只能塞进一个 14B 的 Q8 模型Unsloth Desktop 的量化推理后端却能比较流畅地跑 32B 的 Q4 模型差距不是缩小一点的问题而是决定能不能跑得动。第二点是模型管理不只是“拉模型”而已。你可以在界面里直接输入 HuggingFace 模型 ID选择 GGUF 版本下载也可以用里面的量化工具把模型转成 4bit/8bit 格式。更关键的是它自带的下载源和模型映射比 Ollama 的 library 更开放社区里新发布的模型当天就能在搜索里找到不用等官方收录。第三点是它思考过“模型怎么给 Agent 用”。在 Unsloth Desktop 里开启 Agent API 后它不是简单暴露一个 OpenAI 兼容接口而是可以选择 Anthropic 兼容模式。这意味着 ClaudeCode 可以把本地模型当成自己的推理后端这个体验和我在其他 GUI 工具里遇到的“需要再套一层转换服务才能让 ClaudeCode 认出来”完全不同是一键接入级别的顺滑。需要留意的是这个功能入口不在聊天页而在设置或服务器管理里第一次用的时候容易忽略。1.3 和主流工具的横向对比我做了一张表能比较直观看出 Unsloth Desktop 的定位功能OllamaLM StudioUnsloth Desktop模型下载官方库/自定义文件HuggingFace/文件导入HuggingFace/GGUF/多后端图形聊天界面第三方接入自带自带模型量化内置较少一般支持动态量化与转换LoRA/QLoRA 微调不支持基本不支持支持且经过内核优化Agent APIOpenAI/Anthropic 兼容OpenAI 兼容OpenAI/Anthropic 兼容上手门槛低偏命令行很低中等但功能上限更高我写这段不是想劝你立刻卸载 Ollama。实际上 Ollama 仍然是服务化部署里最轻快的运行时我甚至会把 Unsloth Desktop 导出的 GGUF 再交给 Ollama 跑。但这两种工具的定位差别是真实的Ollama 更适合“丢到 Linux 服务器上跑服务”Unsloth Desktop 更适合“在本地桌面折腾模型、做针对性调整、再桥接给 Agent 工具”。如果你正在纠结本地部署工具选型可以先想想自己到底是在搭服务还是想本地研究模型本身。2. 实测环境与模型选型先把硬性条件摆清楚2.1 我的实测配置我做这次实测的主力机器是 Windows 11CPU 是 i7-13700K内存 64GB显卡是 NVIDIA RTX 4090 24GB。系统里已经安装了最新的 NVIDIA 显卡驱动并且确认 CUDA 计算能力正常。Unsloth Desktop 在安装时没有要求手动安装 CUDA Toolkit它只需要你能识别到显卡驱动即可底层推理框架会处理自己的运行时。我也在朋友的 Mac mini M4 上简单试过跑 8B 模型。Unsloth Desktop 对 Apple Silicon 的支持走的是 MLX 或者 llama.cpp 后端体验比 NVIDIA 显卡差一些主要差在上下文长度较大时响应变慢所以如果重度使用 ClaudeCode建议优先考虑 NVIDIA 显卡。AMD 显卡我没有条件测选型时建议多看一眼官方文档对 ROCm 版本的支持范围。需要强调一个经验显存不是唯一指标但它是第一瓶颈。很多用户内存加了 128GB也觉得“应该能跑很大模型吧”。实测下来如果显存不够Unsloth Desktop 会把层切到 CPU 或内存里运行速度可能从每秒几十 token 掉到不到 10 token。ClaudeCode 这种工具一旦响应太慢体验就不是“慢一点”而是整个 Agent 会话容易超时或失去上下文连贯性。2.2 模型选型思路5 分钟判断自己显卡能跑多大模型判断能跑多大模型核心看的是量化后权重占用而非模型参数量的名字。一个 7B 模型如果以 fp16 加载权重就是约 14GB普通消费卡很难跑如果量化成 4bit权重就只有约 3.5GB加上上下文和推理中间状态8GB 显存也能勉强跑。所以我一直建议新手别只看“7B、13B、70B”要关注“Q4_K_M、Q8_0、fp16”这些量化后缀。一个简单计算公式模型显存需求约等于“参数量 × 每权重比特数 ÷ 8”然后再预留 20%-30% 给 KV Cache 和 CUDA 计算开销。参数 7B 的 Q4 模型是 7×4÷83.5GB看起来不多但我实测把上下文开到 8K 后4090 上显示占用大约 5.8GB如果上下文开 32K占用能到 7-8GB。所以上下文长度对显存的影响经常被忽略实际跑 Agent 又不能不开长上下文因为代码仓库的一次工具结果很容易就几千 token。我给的实操建议是显卡显存建议模型档位可用上下文8GB7B-8B Q44K-8K12GB12B-14B Q48K-16K16GB14B Q8 / 32B Q4 勉强8K-16K24GB32B Q4 舒适16K-32K48GB 或双卡70B Q4 / MoE 模型32K这个表不是绝对标准因为不同架构对显存要求差别不小但用来判断起步档位够了。我这次主要选了 Qwen2.5-32B-Instruct 的 Q4 版本跑日常对话又选了一个 14B 的 Qwen2.5 做 ClaudeCode 接入测试因为更小一号的模型在做工具调用时的延迟更低方便我观察协议是否正常。2.3 为什么主推 Qwen 系列做 ClaudeCode 后端有人会问为什么不直接跑 DeepSeek 系列或者 LlamaClaudeCode 是一个偏工程向的 Agent它不只是生成文字还要解析工具返回、格式化 JSON、决定下一步行动所以模型必须具备稳定且可控的工具调用能力。实测下来开源模型里 Qwen2.5-Instruct 系列对 function calling 的支持相对最稳Claude 格式的返回也比较容易转换。DeepSeek-R1 蒸馏模型的推理能力很强但带 reasoning 的模型会在回答里先输出一长段“思考过程”。如果 Unsloth Desktop 没处理好 stop tokenClaudeCode 会把思考过程当成正文或者把工具需要的格式截断导致 Agent 行为很奇怪。要是你特别想用 R1 蒸馏模型建议优先选专门针对 Agent 做过格式优化的版本或者在设置里关掉“推理模式/thinking”。这部分我放到后面问题排查里再展开。我建议的入门路线是先用 7B 或 8B 模型跑通流程再升级到 32B 跑真实项目。不要一上来就追求 70B否则下载耗时、显存吃紧最后 ClaudeCode 接入不顺利时很难判断是模型问题还是配置问题。3. 安装、下载和第一次推理实操记录3.1 安装细节与首次启动Unsloth Desktop 的安装包可以从官网或 GitHub Releases 下载。Windows 安装包是 exe下载后安装过程很短没有太多需要自定义的选项。有一点比较重要安装路径不要带中文和空格我刚开始装在 F 盘的“本地模型工具”目录下启动时部分下载任务偶发找不到路径改到 F:\UnslothDesktop 后就没再出现。首次启动时Unsloth Desktop 会让你选择推理后端。NVIDIA 显卡选 CUDA 或 VulkanApple Silicon 选 Metal/MLXIntel/AMD 核显一般只能选 CPU。不要小看这一步如果选错后端界面可能能启动但模型加载后会特别慢。我建议 NVIDIA 用户优先选 CUDA因为 Unsloth 的显存优化内核在 CUDA 后端上表现最好。启动后有一个模型管理的主界面。刚开始界面上是空的不会像 Ollama 一样自动把 Qwen 或 Llama 热门模型列得很完整需要自己用模型的 HuggingFace ID 做一次搜索。这个过程第一个坑是网络问题直接从 HuggingFace 下载模型在国内环境通常很慢或者完全卡住。如果遇到这种情况可以换国内的模型下载源或者提前在 HuggingFace 设置里配置好镜像地址然后在 Unsloth Desktop 的重试选项里继续下载。3.2 模型下载实操到底卡在哪儿我实际搜索了一个 Qwen2.5-14B-Instruct 的 GGUF Q4_K_M 版本下载进度条走得很稳但在下载到 80% 左右时卡了将近 15 分钟最后才发现是磁盘空间不够。Unsloth Desktop 默认会把模型安装在用户目录。Windows 下大概率是 C 盘C 盘剩余空间低于 20GB 时14B 模型下载到一半就会出现写盘失败。这不是 bug而是安装目录设计不合理的直接后果。解决办法是在设置里把模型存储路径改到 D 盘或独立数据盘。改之前要注意两点一是新路径不要包含中文字符二是如果已经下载到一半建议把未完成的 .part 文件清掉再重新下载不要抱着“断点续传或许能救”的心态实测中残留文件更可能造成校验错误。下载完成后界面的模型卡片会显示参数规模、量化格式、文件大小。点击“加载模型”后右侧状态栏会开始显示加载层数和显存占用。14B Q4_K_M 在 4090 上加载大概用了不到 15 秒。如果加载后显存占用超过 23GB建议先把上下文长度从默认的 16K 降到 8K 再重新加载。很多新手直接去改模型文件其实大多数 OOM 是上下文长度过猛导致的和模型本身关系不大。3.3 快速跑通第一个对话加载完成后聊天窗口默认会出现一个系统提示框这个设置很重要。ClaudeCode 这类 Agent 对本地模型的系统提示要求很高你可以先在本地聊天界面里测试一下不同 system prompt。比如“你是一个严谨的编程助手所有回答尽量精炼不要输出多余的分析过程。”这会明显改善后续接 ClaudeCode 时的输出稳定度。我随手问了模型一个 Python 递归问题Qwen2.5-14B Q4_K_M 在 4090 上输出速度大概在每秒 45-55 token对于 14B 模型来说相当快。不过这只是纯生成速度等接了 ClaudeCode 后由于要反复生成和截断实际感受会慢不少。这一步跑通后先别急着接 ClaudeCode建议花五分钟把“量化”和“微调”两个功能都点开看一眼。因为它们才是 Unsloth Desktop 和其他本地聊天软件拉开差距的地方。4. 从简单推理到微调Unsloth Desktop 的核心功能拆解4.1 聊天推理页面的关键参数Unsloth Desktop 的聊天界面不复杂核心参数就那么几个但每一个都会直接影响后续 ClaudeCode 接入效果。Temperature 在本地模型里我习惯设置在 0.2-0.4太高的温度会让模型在代码补全过程中自己“发挥”输出一些不存在的函数。Top-P 默认 0.9 基本不用动Context Length 才是重点。很多人忽视“上下文长度”和“显存”之间的关系。我实测 Qwen2.5-14B Q4 模型把 Context Length 从 4096 增加到 32768 后显存占用从 8.9GB 跳到 13.6GB。ClaudeCode 一次会话要传递很多文件内容和工具结果长上下文是刚需但也不能盲目拉高。建议先按 16K 跑如果中途经常内容被截断再往上加。还有一个容易被忽略的设置是“GPU Layers”。有的版本里会直接叫“模型层加载到显卡的比例”默认可能是自动。如果显存比较紧张建议手动把数值降低一点比如把部分层留在内存里保证不会一上来就 OOM。代价是每多跑一层 CPU生成速度就会下降一截这是一个基于自己显存和延迟偏好的取舍。4.2 一键量化把模型从 16GB 压缩到 5GB本地部署遇到最多的一个问题是别人给的模型是 safetensors 格式体积巨大直接加载容易爆显存。Unsloth Desktop 支持的量化工具就是解决这个问题的。在模型卡片上选择量化功能选一个目标量化精度比如 Q4_K_M、Q5_K_M 或 Q8_0它就会把模型转换成 GGUF 格式。我第一次用的时候以为量化需要单独下载一堆工具链实际上不需要。点选后就能看到进度条Qwen2.5-14B 的 16bit 版本转成 Q4_K_M 大约用了 10 分钟转换后文件小了 70% 左右。这个速度比我以前用命令行工具压缩快很多而且在转换过程中显卡没有跑满内存占用可控。需要注意的是量化不是无损压缩。Q2 和 Q3 量化虽然能把 70B 模型压进 20GB 显存但输出质量会明显下降代码里的逻辑错误也会变多。如果显存还够用我建议优先 Q4_K_M 或 Q8_0。实测 Q8 比 Q4 的代码生成准确率高一点但显存需求几乎翻倍属于典型的“跑得动就上 Q8跑不动就老实 Q4”的选择。4.3 微调功能从“下载模型”到“拥有自己的模型”Unsloth Desktop 既然叫 Unsloth自然不会只做推理。微调入口在深度调整/训练中心基本步骤是选择底座模型、准备数据集、配置 LoRA 参数然后开始训练。普通用户可能一开始会被“微调”两个字吓到但要清楚本地大模型微调不是为了模仿别人的教程而是为了让模型更懂你自己的业务术语和代码风格。考虑到不是所有人都需要微调我只给一个最小可用的建议。如果你想用 LoRA 微调一个 7B 模型batch size 建议设为 2 或 4学习率在 2e-4 附近训练轮数不要太多先跑 1 轮看 loss 变化。很多新手一上来就全量微调或者把 learning rate 设到 5e-5 以下然后发现模型学不到东西。其实 Unsloth 的 LoRA 已经是显存友好的方案把目标模块限制在 q_proj、v_proj 上能明显降低显存占用。我这次没有做完整微调因为评测 ClaudeCode 接入并不需要改变模型知识。但如果你本地积累了一些代码 review 语料或内部 API 文档用 Unsloth Desktop 微调一个适配自己团队的模型是完全可行的而且比从零训练省太多资源。这大概也是 Unsloth Desktop 和 LM Studio 最本质的区别后者是“用完别人的模型”前者是“能把自己的数据真正灌进模型”。5. 一键接入 Claude Code 的正确姿势5.1 为什么要把 ClaudeCode 接到本地模型ClaudeCode 默认使用 Anthropic 的云端模型效果很好但存在两个问题一是对团队或个人来说高频使用会产生真金白银的 token 费用二是代码和数据上下文会被发送到外部 API很多公司项目在合规上不接受。本地模型恰恰解决这两个痛点。它是运行在本机上的服务不需要把代码片段传到外网同时也没有按量计费的问题。但很多人会发现ClaudeCode 直接接 Ollama 的 OpenAI 兼容接口并不稳定因为 ClaudeCode 背后用的是 Anthropic Messages API 格式和 OpenAI 格式不是一回事。Unsloth Desktop 提供的 Anthropic 兼容端点省掉了很多中间层的转换工作。它不是单纯把模型名字写成一个 API 地址而是主动把本地模型的输出转换成 Anthropic 可以识别的消息结构。5.2 实操步骤开启端点并配置 ClaudeCode在 Unsloth Desktop 里找到设置中的 Agent API / 开发者服务器开关。不同小版本的名称可能有差异但核心逻辑就是开启一个本地 API 服务并选择 Anthropic 兼容模式。开启后界面会显示一个本地地址和一个访问 Token通常是这样的格式http://127.0.0.1:8899和local-unsloth-token。Token 的作用是避免无意识的外部请求触发本地服务你在配置 ClaudeCode 时也要填。然后需要在启动 ClaudeCode 前设置两个环境变量。macOS/Linux 终端里执行export ANTHROPIC_BASE_URLhttp://127.0.0.1:8899 export ANTHROPIC_AUTH_TOKENlocal-unsloth-token claudeWindows PowerShell 里执行$env:ANTHROPIC_BASE_URLhttp://127.0.0.1:8899 $env:ANTHROPIC_AUTH_TOKENlocal-unsloth-token claude设置完后ClaudeCode 发送的请求就会交给 Unsloth Desktop 的本地端点。启动 ClaudeCode 后如果能看到模型名称变成你刚才加载的那个本地模型名说明接入成功。如果 ClaudeCode 仍然尝试连接云端检查环境变量是否在当前终端窗口生效CLI 工具不会自动读取 Unsloth Desktop 里的动态变量。一个我踩过的坑如果端口 8899 被其他程序占用Unsloth Desktop 会退到 8900 或 10001界面里的 API 地址会是具体端口。你需要用界面显示的实际地址替换上面的命令不要对着教程死抄。配置完成后可以用一条命令快速确认服务可用curl http://127.0.0.1:8899/v1/messages \ -H Content-Type: application/json \ -H x-api-key: local-unsloth-token \ -d {model:qwen2.5-14b,max_tokens:32,messages:[{role:user,content:ping}]}如果返回正常的 JSON 消息而不是连接错误说明 ClaudeCode 也大概率能通。先不要急着开一个大项目让 ClaudeCode 去改先在临时目录让它写一个小的 Python 脚本观察能不能正常规划并调用工具。5.3 不让 ClaudeCode 一直点确认的两种方法很多人接完本地模型后遇到最烦的问题不是 API 不通而是 ClaudeCode 每个操作都要问一次“是否继续”。这不是本地模型的问题而是 ClaudeCode 默认权限策略很谨慎。解决办法有两个。第一个是临时调试时使用跳过权限模式claude --dangerously-skip-permissions这个参数会跳过所有工具调用的确认让 Agent 直接执行命令、修改文件。好处是真的不再点确认坏处是如果模型或指令出了错可能执行不可逆操作。我建议不要在正式项目上长期开启只在验证模型接入是否正常时用。第二个是精确配置权限规则。创建或编辑settings.json把常见只读操作和 git 操作加入 allow 列表{ permissions: { allow: [ Read(**), Edit(**), Bash(git *), Bash(cd *), Bash(ls *) ], deny: [ Bash(rm -rf *), Bash(sudo *) ] } }这样 ClaudeCode 对读文件、修改文件、执行 git 等常规操作就不会反复询问但危险命令仍然被拦下。我踩过的经验是权限规则里的**通配符在部分版本里需要写完整才行如果加了规则仍然无效就检查自己的配置或升级 ClaudeCode。配置完成后重启 ClaudeCode 才会生效。5.4 本地模型跑 ClaudeCode 的真实表现与模型选择建议接入成功后我测试了三个任务写一个 Python 命令行工具、修改一个 React 组件、重构一个函数。用 Qwen2.5-14B Q4 跑简单代码生成任务表现不错但它对大型项目的全局理解明显不如云端 Claude 模型。如果项目文件数量超过几十个且依赖关系复杂14B 模型会经常理解不全偶尔会漏改文件。这个现象很正常。ClaudeCode 本身依赖模型规划本地模型参数越小记忆和推理越局限。如果只是用它来补全函数、写单测、处理小范围重构14B 已经够用。如果是让 Agent 负责一个仓库级的大任务最好升级到 32B 或 70B或者接受它会频繁出错的现实。不少人也会拿 Codex 和 ClaudeCode 做选择。Codex 更适合已经在 OpenAI 生态里的用户但要把本地模型接入 Codex 反而比 ClaudeCode 麻烦因为它的接口设计更偏向云端模型。ClaudeCode 则通过兼容网关支持多种模型。所以如果你的核心诉求是“本地部署大模型 代码 Agent”目前更顺畅的路径是把 ClaudeCode 指向本地模型而不是反过来把 Codex 硬改成 OpenAI 兼容。6. 本地运行时的常见问题与排查技巧6.1 模型能加载但回答特别慢这个问题的根源大概率是 GPU 没有完全参与推理。打开任务管理器或显卡监控软件如果看到显卡利用率不到 20%那就说明大部分层还在 CPU 上跑。回到 Unsloth Desktop 的加载设置把 GPU Layers 调高一般建议在 50 层以上的模型中取值到“全量加载”。有时显卡利用率高但速度依旧慢可能是上下文已经填满生成长度太长。ClaudeCode 每轮工具调用都会把历史和工具结果重新拼接时间主要消耗在 prefill 而不是生成上。这种情况下没有太多优化方式要么缩短上下文要么换更大的显存。6.2 ClaudeCode 输出中出现大段“思考过程”或回复被截断很多推理类模型会先输出“我需要分析一下需求……”之类的 reasoning 内容。Unsloth Desktop 如果没有正确设置停止词ClaudeCode 就会把思考内容也当成回复导致它一直在自我对话或者 JSON 输出不完整。解决方法是在模型参数或后端配置里找到 Reasoner/Thinking 开关并关闭同时在服务端设置合适的 stop token把模型的结束符和 Claude 消息结束符都加入。如果还是乱建议换无 reasoning 或专门支持 function calling 的模型比如 Qwen2.5-Instruct。6.3 接口 curl 通了ClaudeCode 仍报认证或模型不存在这种情况通常是环境变量里的 Token 与 Unsloth Desktop 显示的不一致或者模型名称写错。ClaudeCode 会把“模型名称”字段发给本地端点本地服务需要把它映射到本地已加载模型上。如果 Unsloth Desktop 界面里没有模型映射选项可以在 ClaudeCode 启动时的/model命令里手动选择对应模型名称。还有一个小概率问题是 Anthropic 兼容端点要求请求头是x-api-key但 ClaudeCode 发送的是Authorization: Bearer多数本地服务两种都兼容极少数需要设置一个“认证前缀”选项。6.4 显存不足与 OOM 高发场景不只是模型太大也有可能是你同时开了多个工具。实测中我如果先加载了一个 32B 模型再启动 ComfyUI 或另一个本地服务显存很容易直接占满。最好统一管理桌面 GPU 任务不要在跑大模型的同时再开一个图形渲染软件。OOM 后 Unsloth Desktop 偶尔会无响应建议先关闭并重启应用不要盲目调高 Quantization量化过低会导致输出逻辑崩坏。7. 本地跑大模型的几点真实经验7.1 什么时候别迷信本地模型本地大模型现在确实能跑但必须承认它和最好的云端模型还有差距。在做大规模架构设计、跨几十个文件的复杂重构时云端模型的上下文理解依然明显更强。我现在的用法是混合模式日常闲聊、简单代码生成、涉密数据都走本地模型重要项目设计和解决疑难 bug 时再用云端模型。两者互补比单一只用任何一个更合理。7.2 硬件升级的优先级如果预算有限升级硬件时优先考虑显存其次才是内存。很多人在 16GB 显存的机器上硬跑 32B 模型结果把 context 压到 4KAgent 根本没法干活。与其这样不如老老实实跑 14B Q8既保证质量又留出上下文空间。如果一张 24GB 显卡仍然不够双卡并不是简单的“显存翻倍”很多本地推理框架对多卡支持需要额外配置新手不建议一上来就上双卡。7.3 最后分享一个实用小技巧把 Unsloth Desktop 作为“模型加工厂”可能是更稳的用法下载开源模型后用桌面端的推理功能快速评估模型质量再用量化导出功能生成适合自己硬件的 GGUF 文件最后把 GGUF 放到 Ollama 或 LM Studio 里常驻服务。这样你既能享受 Unsloth 图形界面带来的方便又能用 Ollama 的稳定服务去对接其他应用。如果只是要让 ClaudeCode 用那还是直接开 Unsloth Desktop 的 Anthropic 兼容端点更省事。我在折腾这套流程时最大的感受是本地部署大模型的瓶颈早就不是“有没有工具”而是“这套工具和你的 Agent 工作流能不能贴合”。Unsloth Desktop 把跑模型、量化、微调和 API 接入放在一起是目前少有的能从起步陪我到实战的图形化选择。只要把模型选型、显存预留和权限配置这三点想清楚哪怕显卡不是顶配也能获得一个足够顺手且数据可控的本地编码助手。