很多人用 Claude 干活时会卡在两个地方：一是某些活（批量整理、内网资料、重复格式化）交给云端不划算也不方便，二是听说能接本地模型，但不知道接在哪一层、用什么接口、怎么确认真的生效了。这篇按「先想清楚替哪一段、再选接入方式、最后小步验证」的顺序讲一遍，给一套能照着做的动作顺序和判断标准。
很多人用 Claude 干活时会卡在两个地方：一是某些活交给云端不划算也不方便，比如批量整理、内网资料、重复格式化；二是听说能接本地模型，但不知道接在哪一层、用什么接口、怎么确认真的生效了。
这篇按「先想清楚替哪一段、再选接入方式、最后小步验证」的顺序讲一遍，给一套能照着做的动作顺序和判断标准。注意：本地模型接进来是替代部分环节，不是把 Claude 整条链换掉；哪些环节能替、哪些不能替，先想清楚再动手。
先分清要替的是哪一段，不是整条链都换
动手前先把你每天的流程拆开看。大多数人的工作流其实是三类任务混在一起：对话式问答、批量文本处理、工具调用和自动化脚本。本地模型通常只适合替第一类和第二类里规则明确的部分，第三类涉及多步编排和外部系统，乱换容易把流程搞断。
| 任务类型 | 适合本地替吗 | 判断依据 |
|---|---|---|
| 对话式问答（短问答、翻译、改写） | 适合 | 输入输出短、规则清楚、不依赖联网 |
| 批量文本处理（分类、打标签、格式化） | 部分适合 | 量大、模板固定、对准确率要求不极端 |
| 工具调用/自动化脚本 | 多数不适合 | 需要多步编排、外部系统交互，本地模型容易卡在中间 |
| 长文档精读、复杂代码改写 | 不适合 | 对长上下文和推理能力要求高，本地小模型顶不住 |
- 看数据边界：内容不能出内网、或量大按量调用不划算时，才轮到本地模型上场；只是偶尔问几句的，接本地反而更麻烦
- 看能力要求：需要长上下文推理、复杂代码改写的，不要让本地模型硬扛，而是让两者分工，把简单环节放本地
- 看频率：一天跑几次的，接本地的维护成本可能高于收益；一天跑几百条重复格式化的，才值得投入
接入方式选哪一层：客户端、网关还是脚本
确定要替哪一段之后，接下来选接入层。三种方式对应三种使用规模，选错层会比不接还麻烦。下面这张对照表可以先帮你定位。
| 接入层 | 适合场景 | 代价 |
|---|---|---|
| 客户端层 | 个人日常问答，一个人用 | 换工具就得重配，不好共享 |
| 网关层 | 团队共用，要按规则分流 | 要维护转发服务，多一个进程要管 |
| 脚本层 | 批量任务，按任务类型选模型 | 判断逻辑要自己写、自己维护 |
- 客户端层
- 在支持自定义模型来源的桌面或编辑器工具里，把 Claude 的位置换成本地服务的地址
- 网关层
- 起一个兼容 OpenAI 风格接口的本地服务，前面挂个转发，把请求按规则分给云端和本地
- 脚本层
- 直接在自动化脚本里写两个调用分支，按任务类型选，最灵活但判断逻辑要自己维护
选哪层的判断标准很直接：只有一个人用就选客户端层；多人共用一个 key 就上网关层；要跑批就写脚本。别一上来就搞网关，个人用户维护一个转发服务的时间成本往往超过省下的调用费。
配置的四步动作与每一步要确认的东西
- 定服务地址和端口本地推理服务默认监听本机，局域网要用得显式放开监听地址，否则同网段也连不上。确认方法：在另一台机器上访问这个地址，能通才算配置到位
- 对齐接口格式确认本地服务暴露的是哪种请求格式，和 Claude 客户端期望的是否一致。不一致就中间加一层转换，别硬改客户端配置。确认方法：用一行 curl 发个最小请求，看返回结构对不对
- 填模型名与上下文长度模型名要写本地服务实际加载的那个，上下文长度按本地服务的上限填。填大了直接报错，填小了长任务会静默截断。确认方法：加载服务时看它的启动日志，日志里写的就是准数
- 先用一条最小请求打通不要一上来就接完整工作流，先用一句短提示确认有返回，再逐步换成真实任务
怎么确认真接上了，以及接错了怎么排查
配置填完不等于真的走了本地。最可靠的验证方式是：停掉本地服务，再发一次同样的请求，如果报错，说明确实走的是本地；如果照样有返回，说明请求还在走云端，你的配置没生效。
- 连不上：先查监听地址和防火墙，再看端口有没有被别的进程占用
- 连上但报格式错：多半是请求体字段对不上，对比本地服务文档和你填的字段名
- 有返回但内容乱：检查上下文长度和模型名，这两个填错最容易出乱码或截断
- 有返回但慢得离谱：先量延迟基线再决定用不用
- 本地服务挂了没回退：把回退路径提前配好，别把工作流做成单点
延迟这块别凭感觉。拿站内的测速工具量一遍本地和云端的实际响应差别，再决定哪些环节放本地。想核对本地服务和云端接口的实际表现，可以到 /tools/speed-test 跑一轮，数字以页面上当时的为准。
什么情况下别接本地模型
前面讲的都是「怎么接」，这一节讲「什么时候别接」。接本地模型是有维护成本的：服务要有人起、要有人看着、挂了要有人切回来。下面这几种情况，不接反而更省事。
- 任务本身依赖联网检索、多轮复杂推理、长文档精读的，本地小模型接进来只会增加维护成本，能力差距补不上
- 机器配置刚够跑起来、上下文只能开很小的，接入后大部分请求照样要回退到云端，属于白折腾
- 团队里没人愿意维护本地服务进程的，别接；本地服务的稳定性要有人管，不然比直接用云端更容易出问题
- 只是偶尔问几句、没有批量需求的，接本地的收益覆盖不了配置和维护时间
反过来说，如果你的场景正好落在「数据不能出内网 + 批量规则明确 + 有人愿意维护」这三条的交集里，那本地模型值得接。判断标准不是「本地比云端好」，而是「这段活放本地更合适」。各家接口方式和支持情况会变，具体以站内页面为准，可以到 /sites 核对当时的接入信息，价格和模型资料到 /price-watch 看当时的数字。
下一步先按第一节的表格把你的日常流程拆成三类，圈出真正适合放本地的那部分，再决定接哪一层。要对比不同接入方式的实测延迟和可用性，去站内测速页跑一轮比凭感觉靠谱。→常见问题
本地模型接进来之后，Claude 的订阅或 API 额度还用得上吗？
看你替的是哪一段。只替掉一部分日常问答的话，额度消耗会下降但不会归零，因为复杂任务还是得回云端。想算清省了多少，可以去站内的用量与成本类页面按你自己的调用比例估一遍，别按感觉判断。
为什么客户端里填了本地地址，测试能返回但正式用就没反应？
大概率是请求体和本地服务期望的格式不一致，短测试提示可能刚好没触发问题字段。按这个顺序查：先看客户端发出的请求里模型名和上下文长度是不是本地服务实际支持的值，再确认本地服务进程没有被系统回收，最后检查是不是走了代理导致本地地址被转发出去。
一台普通机器能同时跑本地模型和 Claude 客户端吗？
能跑起来和跑得动是两回事，取决于你机器的显存和本地模型的规模。先按你的显卡显存反推能跑多大的量化模型，再决定要不要接，具体对应关系可以到站内的部署测算和本地配置类页面按你的机器参数算一遍。
