想在终端里用 Claude Code，又不想一直按官方额度烧钱，很多人第一反应是把后端换成自己机器上的模型。真动手会发现卡点不在命令怎么写，而在本地服务说的是不是同一套接口协议、你选的模型扛不扛得住长上下文和工具调用、显存够不够、以及这套组合能不能商用。这篇按动手顺序拆一遍，每步给判断标准和排查动作。
想在终端里用 Claude Code，又不想一直按官方额度走，很多人第一反应是把后端换成自己机器上的模型。真动手才发现卡点不在命令怎么写，而在本地服务说的是不是同一套接口协议、你选的模型扛不扛得住长上下文和工具调用、显存够不够，以及这套组合到底能不能商用。
这篇按动手顺序拆一遍，每步给判断标准和排查动作。整体思路是：一次只改一个环节，改完立刻验证，别把协议、模型、显存三件事混在一起查，否则出问题你根本不知道是哪层坏了。
先确认本地服务能不能装成 Claude Code 认的那个后端
Claude Code 走的是它自己的接口格式，多数本地推理服务默认只暴露 OpenAI 兼容接口。两边对不上，就要在中间加一层转发或代理来改写请求和响应。挑本地服务时，第一步不是看模型多强，而是看它有没有 Claude 兼容入口或者成熟的社区代理方案。没有的话先解决协议这层，别急着下模型。
- 先查本地服务文档里有没有 Claude 兼容端点，没有就找代理方案
- 确认代理支持流式输出，非流式在高频交互下体验很差
- 协议层单独跑通再动 CLI 配置，一次别改两处
- 记住改过的端口和路径，排查时要反复用
不确定链路通不通，先用一个简单请求单独测本地服务，确认它能正常返回，再接进 CLI。这样出了问题你能立刻判断是服务本身挂了，还是协议转换那层写错了。具体每个本地服务支持哪种协议格式，可以到 工具目录（/tools） 查当前收录情况。
本地模型档位怎么挑：不是越大越好，先看它干活的方式
Claude Code 的日常动作是读文件、改代码、连续调工具，这要求模型能稳定跟住多轮工具调用格式。纯聊天模型在这种场景里很容易中途丢格式，一旦丢了，CLI 那边收到的就是没法解析的返回。所以选型第一个筛选条件是工具调用稳不稳，不是聊天质量高不高。
| 场景 | 选型重点 | 可以放宽的地方 |
|---|---|---|
| 多文件改动、连续调工具 | 工具调用格式稳定性、长上下文一致性 | 闲聊质量、单轮回答速度 |
| 单轮问答、查文档 | 回答质量和响应速度 | 工具调用能力 |
| 少量高频任务 | 本地服务启动速度和并发 | 模型参数规模 |
参数规模先按你机器的显存反推。宁可先上一个能全量放进显存的中等档位，也不要上一个频繁换进换出的大档位，后者在实际使用里慢到没法干活。量化档位是本地部署里性价比最高的一刀，但降得太低会先坏在工具调用和长文一致性上，而不是坏在闲聊上。
什么情况下不适用：如果你的任务基本是单轮问答、不涉及多文件改动，那对工具调用稳定性的要求可以大幅放宽，选型逻辑会变成另一套，优先看回答质量和内存占用就行。
显存、上下文和并发：把这三个数先算一遍再装
显存占用不只是模型权重，还要算上下文缓存和推理框架自身的开销。长上下文任务里，缓存这块经常比你想的更大。上下文长度直接决定 Claude Code 能不能一次吃下项目里的相关文件，开太小会频繁截断，表现像模型忘了前面说过什么。
- 先看卡上还有多少可用显存如果同时在跑别的服务占卡，实际可用显存会比标称小一截，装之前先把占用看清楚。
- 估算权重占用按参数量和量化档位粗略折算，到站内部署测算页核对，别凭感觉。
- 留出上下文缓存的余量上下文越长，缓存占用增长越明显，先按你实际要处理的文件量倒推。
- 再看并发需求如果只有你一个人用，并发可以低配；团队共用就要重新算一遍。
具体每个参数量、每种量化方式对应多少显存，以及上下文加长后怎么变，到 速度与规格核对页（/tools/speed-test） 按你手上的卡查当时的数字。别照搬别人文章里的估算，卡型、框架版本不同，结果差得挺多。
许可证和日常维护：能跑起来不等于能一直用
本地权重有各自的许可证条款。个人自用、公司内部团队使用、以及对内对外提供服务，这三者的边界不一样。接进工作流之前先把许可证读一遍，尤其是要放到公司项目里跑的时候。这块的判断标准很简单：只要你的使用方式超出了许可证允许的范围，前面省下来的那点成本都不值当。
- 模型换代时不要直接覆盖旧权重，先并行装一份新的跑通再切
- 本地服务版本升级可能悄悄改接口行为，升级后要重跑工具调用和长上下文两个场景
- 给本地服务写个最小启动脚本，重启一次不用重查参数
- 把许可证和权重放置位置记在一处，换人接手不用重新梳理
还有一个判断标准：如果你每天的调用量很小，或者对代码上下文长度要求很高，本地这套的维护成本可能反而不划算。这种情况下留在官方后端更省事。到底哪种更划算，别用感觉判断，到 价格追踪页（/price-watch） 看你实际用量对应的数字再决定。
跑不通时的排查顺序
从本地服务到 CLI，中间至少隔了两层，出问题时最忌讳到处乱改。按固定顺序一层层排除，比凭直觉快得多。这个顺序的核心逻辑是：从最底层往上查，每层只测一件事。
- 先验证本地服务本身用简单请求确认它能正常返回，先排除模型和显存问题。
- 再单独测接口格式转换层看请求和返回结构对不对得上，别和模型问题混在一起查。
- 换一个极短的任务试 CLI比如让它读一个文件念出来，确认链路通再加复杂度。
- 最后看显存和上下文输出变慢、突然中断、回答明显变短，通常都指向这里。
如果四步都过了还是不稳定，多半是并发或内存回收的问题，可以查一下推理框架的日志，看看是不是有请求被排队或挤掉。哪些中转站已经在跑类似的本地接入方案，可以去 站点导航（/sites） 对照看看它们的配置说明。
下一步把你手上的卡型和想跑的任务复杂度带过去，对照站内的部署测算和工具目录，先判断本地这套到底适不适合你，再决定要不要动手装。→常见问题
Claude Code 能直接连本地模型吗，还是要装别的东西？
通常要在中间加一层接口转换。Claude Code 用的是自己的请求格式，而多数本地推理服务对外只暴露 OpenAI 兼容接口，两边对不上。常见做法是本地起服务再用一个代理或转发层把协议改写过去。先把这一层跑通，再去挑模型和调显存，顺序反了会一直在错误的地方找原因。
本地模型接进来之后，为什么改代码老是改一半或者格式乱掉？
大概率是模型的工具调用稳定性不够。Claude Code 的工作方式是连续调用工具、读文件、再改文件，对格式跟随要求很高，纯对话调优过的模型容易中途丢格式。换一个在代码和工具调用场景上更稳的档位，或者把量化档位往上提一档，通常比调提示词更有效。
本地跑起来很慢，是模型选大了还是别的问题？
先分清是首字慢还是整体慢。首字慢多半是模型加载或显存不够导致权重换进换出；整体慢但首字正常，一般是上下文太长或者卡本身吞吐有限。可以先缩短一次性喂进去的文件范围试一次，明显变快就说明卡在上下文；没变化再看显存占用和推理框架的日志。
