1. 为什么要在局域网里折腾离线 VibeCoding先把概念说清楚。所谓 VibeCoding说白了就是让 AI 帮你写代码、改代码、跑命令你负责提需求和验收。Claude Code 和 Codex 这两套命令行工具是目前最主流的两个选择一个擅长长上下文理解和复杂重构一个在代码补全和快速生成上很顺手。问题在于这两套工具默认都要连外网把代码片段、文件路径甚至整个项目上下文发到远端服务器。对于个人玩具项目无所谓但只要涉及公司内部代码、客户数据、还没申请专利的算法这条路就走不通。局域网离线方案的核心思路很简单把模型推理放在局域网内的一台机器上其他开发机通过内网地址调用它。这样代码不出局域网延迟还低带宽也稳定。我实测下来一台带独显的机器跑量化后的开源模型配合 LM Studio 或者 Ollama 做推理服务再让 Claude Code 和 Codex 指向这个内网地址整个链路是通的而且体验比想象中好很多。这套方案适合几类人一是公司有代码保密要求、不允许代码出内网的开发团队二是家里有多台机器、想统一管理模型资源的折腾党三是网络环境不稳定、经常断外网但又想用 AI 辅助编码的独立开发者。不管你是哪种只要有一台能跑模型的机器和几台开发机就能搭起来。需要提前说明的是本文讲的都是局域网内的正常网络配置和工具使用所有操作都在你自己的内网环境里完成不涉及任何跨网络访问的内容。2. 整体架构设计与方案选型2.1 三种可选架构的取舍局域网离线 VibeCoding 的架构本质上就是推理服务放哪、怎么被调用的问题。我试过三种方案各有适用场景。第一种是单机自包含模型和开发工具装在同一台机器上Claude Code 直接调本地的 LM Studio 或 Ollama。这种最简单零网络配置缺点是模型跑起来吃满显存和内存你写代码的 IDE 会卡。适合只有一台高配机器的人。第二种是局域网推理服务器一台机器专门跑模型推理开放内网端口其他机器通过内网 IP 调用。这是我最推荐的方案资源隔离干净多台开发机可以共享一个模型服务。缺点是首次配置稍麻烦要处理端口、防火墙、模型加载这些问题。第三种是混合模式本地跑小模型做补全局域网服务器跑大模型做复杂任务。这种最灵活但配置最复杂适合对延迟极度敏感的场景。我下面主要讲第二种因为它平衡了复杂度、性能和可维护性也是大多数团队能落地的方案。2.2 为什么选 LM Studio 而不是纯 Ollama热词里有人问claude code 调用 lmstudio 的本地模型这个方向是对的。LM Studio 和 Ollama 都能提供 OpenAI 兼容的 API但实际用下来LM Studio 在几个点上更适合配合 Claude Code 和 Codex。第一LM Studio 的 GUI 能直观看到模型加载状态、显存占用、当前并发请求数排查问题时不用猜。第二它内置了 OpenAI 兼容的/v1/chat/completions和/v1/responses端点Codex 需要的/responses接口它能直接提供省去自己写适配层。第三模型量化格式支持全GGUF、MLX 都能加载显存不够时可以灵活降级。Ollama 的优势在命令行友好、Docker 部署方便如果你习惯纯终端操作它也很好。但 Codex 对/responses端点的要求比较严格Ollama 需要额外配置才能满足这点后面会细说。2.3 网络拓扑与 IP 规划局域网搭起来之前先把 IP 规划好不然后面改配置会疯。我的建议是给推理服务器一个固定 IP比如192.168.1.100开发机用 DHCP 或者固定192.168.1.101到192.168.1.120这个段。这样配置文件里写死的地址不会变。交换机选千兆的就够模型推理的瓶颈在 GPU 不在网络除非你要传几十 GB 的模型文件那万兆会舒服些。普通家用路由器做局域网交换也没问题只要别让推理流量走外网出口就行。注意如果你的局域网里有多个网段确保推理服务器和开发机在同一网段或者路由器上配置了正确的静态路由。跨网段访问失败十有八九是路由没配好。3. 推理服务器端的完整配置3.1 硬件与系统准备推理服务器的硬件决定了你能跑多大的模型。我的经验是7B 到 14B 的量化模型一张 12GB 显存的卡比如 3060 12G就能跑得比较舒服32B 的模型建议 24GB 显存起步70B 的模型要么多卡要么用 CPU 加内存硬扛速度会明显下降。系统方面Linux 和 Windows 都行。Linux 下驱动和 CUDA 配置更干净Windows 下 LM Studio 的 GUI 更好用。我自己的推理服务器跑的是 Ubuntu因为远程管理方便SSH 进去就能操作。内存建议至少 32GB因为模型加载时会有额外的内存开销。硬盘用 NVMe SSD模型文件动辄十几 GB机械盘加载会等到怀疑人生。3.2 LM Studio 的安装与模型加载LM Studio 官网下载对应系统的安装包Linux 下是 AppImageWindows 下是 exe。安装完打开先在设置里把Enable Local LLM Service打开默认端口是1234。模型加载这一步有几个关键参数要调Context Length这个决定模型能记住多少上下文。Claude Code 处理大项目时上下文需求很高建议设到 32768 或更高。但注意上下文越长显存占用越大要平衡。GPU Offload把多少层放到 GPU 上跑。显存够就全放不够就部分放剩下的用 CPU。LM Studio 会自动估算但你可以手动调。Batch Size影响推理吞吐一般设 512 或 1024显存紧张就降。加载完成后LM Studio 会显示一个内网可访问的地址比如http://192.168.1.100:1234。在浏览器里访问这个地址能看到 API 文档页面说明服务起来了。3.3 开放内网访问与防火墙配置默认情况下LM Studio 只监听127.0.0.1局域网其他机器访问不了。要在设置里把Serve on Local Network打开或者手动改监听地址为0.0.0.0。Linux 下如果开了 ufw 或 firewalld要放行端口# ufw sudo ufw allow 1234/tcp # firewalld sudo firewall-cmd --permanent --add-port1234/tcp sudo firewall-cmd --reloadWindows 下第一次启动 LM Studio 时系统会弹防火墙提示选允许专用网络访问。如果没弹或者选错了去Windows Defender 防火墙里手动加一条入站规则放行 1234 端口。提示配置完后在另一台机器上用curl http://192.168.1.100:1234/v1/models测试一下能返回模型列表就说明通了。返回连接拒绝先查防火墙再查监听地址。3.4 验证推理服务是否正常服务起来后用一条简单的 curl 命令验证curl http://192.168.1.100:1234/v1/chat/completions \ -H Content-Type: application/json \ -d { model: your-model-name, messages: [{role: user, content: 你好}], max_tokens: 50 }能返回正常的 JSON 响应说明推理链路通了。如果返回 404检查模型名对不对返回 500看 LM Studio 的日志多半是显存不够或者模型加载失败。4. 开发机端 Claude Code 的接入配置4.1 Claude Code 的安装Claude Code 的安装方式取决于系统。macOS 和 Linux 下用 npm 装最方便npm install -g anthropic-ai/claude-codeWindows 下建议用 WSL2然后在 WSL 里按 Linux 的方式装。原生 Windows 支持也在完善但 WSL 的兼容性更稳。装完后运行claude --version确认安装成功。如果提示命令找不到检查 npm 的全局 bin 目录有没有加到 PATH 里。4.2 指向局域网推理服务Claude Code 默认连 Anthropic 的官方服务要让它走局域网需要设置环境变量。核心是两个export ANTHROPIC_BASE_URLhttp://192.168.1.100:1234 export ANTHROPIC_API_KEYlm-studioANTHROPIC_BASE_URL指向你的推理服务器ANTHROPIC_API_KEY随便填一个非空值就行LM Studio 不校验这个。但这里有个坑Claude Code 用的是 Anthropic 自己的 API 格式而 LM Studio 提供的是 OpenAI 兼容格式两者不完全一样。直接指过去可能会报格式错误。解决办法是用一个转换代理把 Anthropic 格式的请求转成 OpenAI 格式。社区里有现成的工具比如claude-code-proxy这类项目装好后配置一下转发规则就行。代理的配置大概是这样的export ANTHROPIC_BASE_URLhttp://127.0.0.1:8082 export ANTHROPIC_API_KEYany代理本身再配置成转发到http://192.168.1.100:1234。这样 Claude Code 以为自己在跟 Anthropic 说话实际上请求被转成了 OpenAI 格式发给局域网模型。4.3 VSCode 里的集成热词里vscode配置claude code问的人很多。Claude Code 本身是命令行工具但在 VSCode 里可以通过集成终端使用。装好 Claude Code 后在 VSCode 里打开终端直接运行claude就能用。如果想更深度集成可以装 Claude Code 的 VSCode 扩展它提供了侧边栏对话界面。扩展的配置里同样要填ANTHROPIC_BASE_URL和ANTHROPIC_API_KEY指向你的局域网代理。实测下来VSCode 集成终端里跑 Claude Code 的体验和独立终端没区别而且能直接看到当前项目的文件结构提需求时更方便。4.4 模型选择与上下文长度匹配Claude Code 的工作方式决定了它对模型能力有要求。它会把项目文件、命令输出、对话历史都塞进上下文所以模型至少要能处理 32K 的上下文否则大一点的项目直接爆。我试过几个模型Qwen2.5-Coder 32B 在代码理解和生成上表现最好但显存要求高DeepSeek-Coder-V2 16B 是性价比之选12GB 显存能跑Llama 3.1 8B 速度快但复杂任务容易出错。选模型时别只看参数量要看它在代码任务上的专项表现。有些通用模型参数大但写代码不如专门的代码模型。注意Claude Code 有些功能依赖特定的工具调用格式不是所有开源模型都支持得好。如果发现工具调用老是失败换个对 function calling 支持更好的模型试试。5. 开发机端 Codex 的接入配置5.1 Codex 的安装与版本选择Codex 现在有 CLI 版和桌面版。CLI 版通过 npm 安装npm install -g openai/codex桌面版去官网下载安装包。热词里codex安装包codex官网下载问得多认准官方渠道就行别从第三方站点下容易夹带东西。装完后codex --version验证。Codex 的配置文件和 Claude Code 不在一起通常在~/.codex/config.json或项目根目录的.codex目录下。5.2 配置指向局域网模型Codex 的配置比 Claude Code 稍微复杂一点因为它对 API 格式的要求更严格。配置文件大概长这样{ model: your-model-name, provider: { type: openai, baseURL: http://192.168.1.100:1234/v1, apiKey: lm-studio } }关键在baseURL要带上/v1因为 Codex 走的是 OpenAI 的 API 规范。热词里有个报错cc switch local proxy failed while handling codex endpoint /responses这个问题的根源是 Codex 新版会调用/responses端点而很多本地推理服务只实现了/chat/completions。LM Studio 较新版本已经支持/responses如果你的版本不支持要么升级 LM Studio要么在代理层做转换把/responses的请求映射到/chat/completions。5.3 处理 /responses 端点兼容问题这个问题值得单独说因为踩坑的人太多了。Codex 的/responses端点是 OpenAI 新推的接口和传统的/chat/completions在请求和响应格式上有差异。如果你的推理服务不支持/responses有三个解决路径第一升级推理服务到支持该端点的版本。LM Studio 在较新版本里加了这个支持Ollama 需要配合特定的适配层。第二用一个中间代理做格式转换。写一个简单的服务接收/responses请求转成/chat/completions发给后端再把响应转回来。这个代理用 Python 的 FastAPI 几十行就能写出来。第三降级 Codex 到不调用/responses的版本。这不是长久之计但能快速恢复可用。我自己的做法是第一种加第二种结合主力用支持/responses的 LM Studio同时备一个转换代理应对其他推理后端。5.4 Codex 接入 DeepSeek 等模型的注意事项热词里codex接入deepseek也是个高频需求。DeepSeek 的模型可以通过本地部署或者兼容 API 的方式接入。本地部署的话用 vLLM 或 LM Studio 加载 DeepSeek 的量化版本然后按上面的方式配置 Codex 指向它。需要注意的是DeepSeek 系列模型的对话模板和工具调用格式有自己的特点配置时要在推理服务端正确设置 chat template否则模型输出会带一堆特殊标记Codex 解析不了。6. 常见问题排查与避坑实录6.1 连接类问题速查局域网方案最容易卡在连接上。我整理了一个速查表按现象对原因现象可能原因排查方法连接被拒绝服务没监听内网地址检查推理服务的监听配置确认是 0.0.0.0 不是 127.0.0.1连接超时防火墙拦截在服务器本地 curl 测试通了就是防火墙问题能 ping 通但端口不通端口没放行检查 ufw/firewalld/Windows 防火墙规则跨网段访问失败路由没配确认两台机器在同一网段或检查静态路由时通时断IP 冲突或 DHCP 租约到期给服务器设固定 IP热词里linux用交换机组建局域网为什么显示拒绝连接和win10系统可以上互联网但不能访问局域网这两个问题前者多半是服务监听地址不对或者防火墙没放行后者通常是 Windows 的网络配置文件被设成了公用网络改成专用网络就能解决。6.2 模型加载与显存问题显存不够是最常见的硬件问题。表现是模型加载到一半报 OOM或者加载成功但一推理就崩。解决办法有几个层次降低量化精度从 Q8 降到 Q4显存占用能减一半减少 GPU Offload 层数把部分层放到 CPU缩短上下文长度换更小的模型。我一般先用 Q4 量化跑起来确认功能正常后再逐步往上调精度找到显存和质量的平衡点。6.3 工具调用失败的处理Claude Code 和 Codex 都依赖模型能正确输出工具调用格式。开源模型在这方面的支持参差不齐。如果发现工具调用老是失败先确认推理服务有没有正确设置模型的 chat template。很多模型需要特定的模板才能输出结构化的工具调用。其次换一个对 function calling 支持更好的模型Qwen 系列和 DeepSeek 系列在这方面做得比较好。还有一个隐蔽的坑有些推理服务默认不启用工具调用支持需要在配置里显式打开。LM Studio 里要在模型加载设置里勾选相应的选项。6.4 性能调优的几个实操心得延迟高是局域网方案常见的抱怨。除了硬件本身有几个调优点第一确认推理走的是 GPU 不是 CPU。用nvidia-smi看推理时 GPU 利用率如果一直是 0说明模型全在 CPU 上跑。第二调整 batch size 和并发数。单用户场景下小 batch 延迟更低多用户共享时适当增大 batch 提高吞吐。第三模型文件放在 SSD 上。首次加载慢是正常的但如果是每次请求都慢检查是不是模型被反复加载卸载。第四网络层面确保推理流量走的是有线而不是 WiFi。WiFi 的抖动对交互式编码体验影响很大。提示如果多台开发机同时用一个大模型显存会不够。可以考虑部署两个小模型实例做负载分担或者用支持并发批处理的推理框架。7. 多机协作与日常维护7.1 多台开发机共享推理服务局域网方案最大的好处就是共享。一台推理服务器可以同时服务多台开发机每台机器上的 Claude Code 和 Codex 都指向同一个内网地址。但要注意并发问题。LM Studio 默认可能只处理单个请求多台机器同时发请求会排队。如果团队人多建议用 vLLM 这类支持连续批处理的推理框架能显著提升并发吞吐。配置上每台开发机只需要设置相同的ANTHROPIC_BASE_URL或 Codex 的baseURL指向推理服务器的内网 IP。模型切换在服务器端做开发机不用改配置。7.2 模型更新与版本管理模型更新时先在服务器上加载新模型用 curl 测试通过后再通知开发机切换。如果推理服务支持多模型同时加载可以新旧并存开发机按需选择。建议给模型文件做个版本目录比如models/qwen2.5-coder-32b-q4-v1、models/qwen2.5-coder-32b-q4-v2出问题能快速回滚。7.3 日常监控与日志推理服务器上要关注几个指标GPU 显存占用、GPU 利用率、请求延迟、错误率。LM Studio 的 GUI 能看到前两个后两个需要看日志或者自己加监控。我习惯在服务器上跑一个简单的脚本定时 curl 一下推理接口记录响应时间这样能提前发现性能退化。日志方面推理服务的日志要保留出问题时能追溯。Claude Code 和 Codex 的日志在各自的配置目录下排查工具调用问题时很有用。8. 一些实际使用中的体会搭这套东西的过程中我最大的感受是局域网离线 VibeCoding 的瓶颈往往不在模型能力而在工程配置的细节上。模型选对了、服务起来了剩下的就是耐心调各种参数和排查连接问题。另一个体会是不要追求一步到位。先用最简单的单机方案跑通确认 Claude Code 和 Codex 能正常工作再逐步拆分成局域网架构。这样出问题时容易定位是哪一层的问题。还有一点开源模型和官方服务的体验差距是客观存在的尤其是在复杂推理和长上下文任务上。局域网方案的价值在于数据不出内网和可控的成本而不是完全替代官方服务。想清楚自己的核心需求是什么再决定投入多少精力去折腾。最后分享一个小技巧如果局域网里有闲置的机器哪怕配置不高也可以拿来跑小模型做代码补全把大模型留给复杂任务。这种分层使用的思路能让有限的硬件资源发挥更大价值。