claude 怎么配置本地模型

很多人以为在 Claude 客户端里填个本地地址就能跑自己的模型，实际动手才发现要么根本不给改，要么改了报错。这篇按「先判断能不能接、再接哪一层、最后怎么配」的顺序，把每个环节的判断标准和动作列出来，并说明什么情况下这条路走不通。

很多人第一反应是：在 Claude 客户端里把地址改成自己机器的端口不就行了。真去点的时候才发现，桌面端和网页端根本没有填自定义模型地址的入口，设置里翻遍也没有那一项。于是问题变成两层——哪些路径能改，改了之后又会撞到哪些墙。

这篇按「先判断你要接的是哪一层、再接在哪一层落地、最后怎么配和怎么验」的顺序讲，每一步都给出判断标准和动作。凡是需要看具体数字的地方，都告诉你去站内哪个页面核对，因为价格和能力这类东西变化快，写死在文章里没意义。

先判断：你要接的到底是哪一层

同一个「接本地模型」，背后可能是三种完全不同的诉求。第一种是想给 Claude 官方客户端换个后端，让它显示的还是那个界面、跑的是你的模型。第二种是代码里的 SDK 不再指向官方地址，改指本地服务。第三种是把 Claude 当成一个编排大脑，模型本身还是跑在远端。这三件事的可行性差别很大，先把诉求归到哪一类，再往下看。

判断标准很直接：看你的调用是从代码发起的，还是从官方图形界面点出来的。前者有戏，后者基本没戏。如果你不确定官方现在对托管口径是怎么写的，去站内的官方规格与价格页面核对当时的说明，别凭印象判断。

接入的三种落点与配置步骤

能动手的前提下，落点主要有三个。第一个是本地起一个兼容层服务，把推理框架拉起来后暴露成 OpenAI 风格的接口，再把 SDK 的地址指过去，这是目前最通用的一条路。第二个是走中间网关做协议转换，适合已经有统一入口的团队，改动集中在网关配置，业务代码不动。第三个只做提示词和编排层面的替换，模型还在远端，解决不了数据出网的问题，别把它当成迁移。

1. 先让本地服务独立跑通不接任何业务代码，用最朴素的请求确认它能返回结果、能稳定返回第二次。这一步不过，后面全是白折腾。
2. 再改地址只改 SDK 里的 base_url 和鉴权字段，模型名、参数、温度全部先保持原样。一次只动一个变量，报错才有方向。
3. 最后调模型名与参数地址通了之后再换模型标识，逐个对比输出格式。流式和工具调用分开验，别混在一起测。
4. 记录每一版的可用配置把跑通的组合抄下来，改坏了能照着重来。团队里多人协作时这一步省掉的返工最多。

如果你们已经有网关，优先选第二条：把协议差异收敛在网关里，业务侧几乎不用感知。网关层的好处是改坏了只影响一条链路，回滚也快。选哪条不取决于哪条更时髦，取决于你们有没有现成的统一出口。

避不开的限制与对不上的地方

就算地址通了，也不等于行为一致。官方侧的长文本处理、工具调用、结构化输出是托管服务里实现的，换成自托管的模型后，这些特性有没有、行为像不像，得自己实测。提示词直接搬过去效果掉一截是常态，不是配置写错了。

• 能力不对等：长上下文、工具调用、结构化输出这些依赖托管侧实现，本地模型未必有对应行为；
• 接口语义差异：字段命名、流式返回格式、工具调用结构、错误码都可能不同，转了协议不等于行为一致；
• 上下文与并发：本地受显存和上下文窗口限制，长对话容易截断，并发一上来延迟肉眼可见；
• 合规边界：客户端自带的多项能力来自托管侧，绕开之后这部分缺失属于正常现象。

资源和并发到底能撑多少，别用别人的数字套自己的机器。按自己的卡型和并发预期，去站内的部署测算页面算一遍，那里的口径比评论区可信。需要看托管侧现在提供哪些能力做对照，去站内的模型资料库页面核对当时的能力清单。

上线前的排查清单

排查顺序别乱：先连通性，再格式，再拒答边界，最后才看稳定性。很多人反过来，一上来就跑多轮工具调用，出错之后不知道是哪一环。连通性没过就别往下测，浪费时间还容易误判成模型能力问题。