本地模型怎么接进编辑器？成本、硬件与适用边界
本地模型接编辑器的技术路径很简单：本地推理服务暴露一个 OpenAI 兼容端点，编辑器指向 localhost 就行。真正需要想清楚的是另外两件事——你的硬件能跑动什么档位的模型，以及哪些任务值得放本地。
接入的通用套路见编辑器怎么接自定义 API，这篇只讲本地特有的部分。
技术路径
主流的本地推理方案基本都提供 OpenAI 兼容的 HTTP 接口，所以接法和接云端 API 没有本质区别：
- 本地起推理服务，确认它监听的地址和端口
- 编辑器的 base_url 填本地地址
- API key 多数本地服务不校验，随便填一个非空值即可（有些工具的输入框不接受空值）
- 模型名填你实际加载的那个模型的标识符
排查顺序同样是先 curl 通、再工具通。curl 不通的话，先看服务是否真的起来了、端口有没有被占用、防火墙是否拦截。
硬件是硬约束
本地模型能跑多大，取决于显存（或统一内存）。这里没有捷径：模型参数量、量化精度、上下文长度三者共同决定占用，超出就跑不动或者慢到没法用。
实际选择时的经验顺序是：
先确认你的硬件能跑什么档位，再看那个档位的模型在你的任务上够不够用。反过来（先选模型再买硬件）容易花冤枉钱。
量化是最实用的杠杆。 降低精度能显著减少显存占用，代价是一定的质量损失。多数场景下中等量化的质量损失可以接受，值得先试。
上下文长度也吃显存。 同一个模型，把上下文开到很长，占用会明显上升。代码场景尤其要注意——代码的 token 密度高，很容易把上下文撑满。
成本账不是零
「本地免费」是个错觉，真实成本包括：
硬件折旧。 一张能跑中等模型的显卡，摊到几年里每月是多少钱，这个数要算出来和 API 费用比。
电费。 长时间高负载推理的耗电不可忽略，尤其是全天开着的场景。
时间成本。 环境配置、模型下载、版本升级、出问题排查，这些都是你的工时。
机会成本。 本地模型能力通常弱于同期的云端旗舰，多花的调试时间和质量损失要计入。
一个务实的判断：如果你的月 API 支出还不高，本地方案在纯经济上大概率不划算。本地的真正价值在别处。
本地方案的真正价值
一、数据不出本机。 涉及敏感代码、客户数据、未公开项目时，这是刚需，和成本无关。
二、离线可用。 网络受限环境下能继续工作。
三、无限调用。 高频、重复、批量的任务不用心疼额度，比如给整个仓库批量生成注释、跑大量实验。
四、延迟稳定。 不受网络和服务端负载影响，短请求的响应可能比云端更快。
如果你的诉求是上面四条之一，本地方案值得做；如果只是想省钱，先把云端的成本优化做完再说——见大模型 API 降本十招。
哪些任务适合放本地
适合：代码补全（短、频繁、对模型能力要求相对低）、本地检索与嵌入（数据不出机器）、批量的机械改写、离线实验。
不适合：复杂的多步 Agent 任务（对工具调用能力要求高，本地模型这方面通常较弱）、需要最新知识的问答、长上下文的整库分析（显存扛不住）。
比较现实的架构是混合：补全和索引走本地，复杂对话和 Agent 走云端。多数编辑器允许不同功能配不同端点，或者你在中转层做路由——见 Agent 的多模型路由策略。
上线前的三个验证
一、跑一批真实任务对比质量。 别看跑分，用你自己的代码和问题。差距大到影响工作效率的话，省下的钱不值。
二、测延迟。 本地不一定更快——首 token 可能快，但长输出的生成速率受硬件限制。测法见大模型 API 的速度怎么测。
三、测长时间稳定性。 连续跑几个小时看有没有显存泄漏、降频、崩溃。开发环境里跑十分钟没问题不代表能用一整天。
常见的四个卡点
卡点一：编辑器连不上本地服务。 先确认服务真的在监听、端口没被占用、地址写对（本机回环地址和局域网地址是两回事）。用 curl 从同一台机器请求一次，通了再回编辑器。
卡点二：模型名对不上。 本地推理服务加载的模型有一个标识符，编辑器里必须填这个。填产品名或文件名通常不认。多数服务提供一个列出可用模型的接口，先查一下再填。
卡点三：上下文窗口被服务端限死。 本地服务启动时会指定上下文长度，编辑器发来更长的内容会被拒绝或截断。表现是「短问题能答、贴一大段代码就失败」。解法是启动时把上下文调大，前提是显存够。
卡点四：并发请求把机器打满。 编辑器可能同时发补全、对话、索引多路请求，本地服务通常并发能力有限。表现是卡顿甚至整机变慢。解法是在服务端限制并发数，或者关掉不必要的功能。
混合方案的落地形态
前面提到混合架构，具体可以这样落：
方式一：编辑器内分功能配置。 如果工具支持给不同功能配不同端点，直接补全走本地、对话走云端。最简单。
方式二：本地起一层路由。 编辑器统一指向本地的一个转发服务，由它按模型名或请求特征决定转给本地推理还是云端 API。灵活，但多一个组件要维护。策略设计见 Agent 的多模型路由策略。
方式三：手动切换。 在配置里准备两套，需要时切。最土但零成本，对个人开发者往往够用。
从方式三开始，觉得切换太频繁了再上方式一或二。别一上来就搭路由层，多数人最后发现用不上。
一个提醒
本地模型迭代同样很快，能跑的档位和效果每隔一段时间就会变。做完选择之后隔几个月回头再评估一次是值得的——可能同样的硬件已经能跑更好的模型了。
三个高频问题
问：本地模型能达到云端旗舰的水平吗？ 同期对比通常有差距，尤其是复杂推理和长上下文任务。但对补全、改写这类任务，差距可能小到不影响使用。
问：显存不够怎么办？ 降量化精度、换更小的模型、缩短上下文长度，三个手段可以叠加。都不行就说明这台机器暂时跑不动这个档位。
问：本地跑会不会更省电费之外的隐性成本？ 时间成本是最大的隐性项：环境配置、模型更新、故障排查都算你的工时。