最近不少搞AI应用开发的朋友都在聊同一个话题：手头有消费级显卡，怎么把代码补全、单元测试生成、代码解释这些活儿稳定地跑在本地，同时还想让命令行里的AI助手更聪明一点。我折腾了一周多，把GLM-4.5-Air的量化版本地部署起来，再用Claude Code Router做了一层转发，最后接入Claude Code作为交互前端，整体组合下来效果很稳。这套方案的价值在于，它不用依赖外部服务，数据不出本机，同时还能保留Claude Code那些好用的终端交互习惯。

这篇文章我会把整个思路、部署步骤、路由配置、还有我踩过的坑全部整理出来。适合有基础Linux操作经验、手里有一块8GB以上显存显卡、想自己搭一套本地AI辅助编码环境的开发者参考。

1. 整体架构思路拆解：为什么是GLM-4.5-Air加Router再加Claude Code

先说清楚这套组合里每个部分扮演的角色。GLM-4.5-Air是本地跑的推理模型，负责真正理解代码、生成代码；Claude Code Router是一个轻量级代理层，负责把Claude Code发来的HTTP请求转换成模型能理解的格式，同时做模型路由；Claude Code则是你在终端里直接对话的那个命令行工具。三者串起来以后，你在终端里敲自然语言，Claude Code把请求丢给Router，Router再转给本地的GLM-4.5-Air推理服务，拿到结果后再原路返回。

选择GLM-4.5-Air而不是其他更大参数的模型，核心原因是消费级显卡的显存限制。以24GB显存为例，跑满血版GLM-4.5的16B参数量非常吃力，量化到3-4bit勉强能跑但速度感人。而GLM-4.5-Air参数量只有原来的一半左右，推理速度明显更快，量化后单卡可以直接跑满速。微软的DeepSpeed虽然也有人在做，但部署流程绕，踩坑成本高。在社区实测里，GLM-4.5-Air的指令跟随能力和代码注释质量在7B-8B级别里是公认的第一梯队，拿来当本地代码助手完全够用。

Router在这个架构里不是可选项而是必选项。Claude Code默认只认Anthropic的API协议，而GLM-4.5-Air暴露的是OpenAI兼容格式的接口。两者消息结构不一样，Claude Code发出来的请求里带system字段，但GLM-4.5-Air对system的处理比较弱，直接把system内容并进第一条user消息反而效果更好。Router在这里做协议转换和模型调度，类似一个翻译器加交换机。实测下来，没有Router层的话，Claude Code要么报401要么返回一堆格式错误，有了Router，整个链路就走通了。

最后说说为什么还要用Claude Code。直接用Gradio或者Open WebUI当然也能跟GLM-4.5-Air对话，但要实现代码全仓理解、多文件重构、git提交信息自动生成这类功能，还是得靠Claude Code这样的Agent工具。它是真正把模型能力变成"干活"的工具，有文件读写、终端命令执行等完整工具链。套上Router之后，Claude Code完全不知道自己背后跑的是本地模型，它以为自己在跟Claude API聊天。用一套工具交互方式，接不同的模型后端，这套思路以后换模型也不用来回改习惯。

2. GLM-4.5-Air量化版部署全流程：模型选型、环境准备与推理启动

2.1 量化格式，机制细节和选型对比

部署之前先解决一个问题：选什么量化格式。GLM-4.5-Air在社区里有GGUF、AWQ、GPTQ三种主流量化格式，它们的原理和适用场景差别挺大。

GGUF是llama.cpp生态的格式，原理是把模型权重拆成block，对每个block做量化时保留一部分更高精度的权重，所以4bit量化下它的精度损失控制得不错。它的核心优势是CPU也能跑，支持GPU和CPU混合负载，显存不够时偷偷把部分层放到内存里也不会崩。缺点是如果你主要在GPU上跑，性能上限不如其他格式。

AWQ和GPTQ都基于权重矩阵分解的思路，但做法不同。GPTQ用二阶信息来最小化量化后的输出误差，理论更漂亮，但极端低位宽下可能不稳定；AWQ是扫描激活值的分布，对敏感通道做额外保护，实际操作中更稳。两者都要求GPU运算，但推理时显存占用比GGUF同等级更低一点。我的建议是：显存老老实实16GB以上，用AWQ追求速度和显存的双重优势；8GB到12GB这种比较紧的，老老实实选GGUF的Q4_K_M。

我自己选的是GGUF的Q4_K_M版本，主要是考虑到后面要串Router和Claude Code，稳定性优先。Q4_K_M在4bit量化里属于比较均衡的档位，比Q4_0精度高，文件体积又不会像Q5_K_M那样涨太多。如果你手头显存超过16GB，想多压榨点性能，AWQ的4bit版本会更适合，毕竟GGUF的推理路径在纯GPU场景下确实不如后者调用优化得彻底。

2.2 依赖包安装与模型权重获取

环境方面，操作系统选Ubuntu 22.04 LTS或者Debian 12，内核新一点对GPU驱动兼容性友好一些。建议提前装好NVIDIA驱动，版本不低于535，CUDA方面装12.1以上。驱动不对的话，推理框架跑起来会报一堆麻烦的CUDA错误，联调阶段会花不少时间在排查环境问题上。

推理框架，llama.cpp和Ollama两个方向都可以选。Ollama在社区里越来越流行，因为它提供一个开箱即用的推理服务，自己处理模型加载、资源释放、并发队列这些事。我用的是Ollama，服务器上开一个服务，客户端命令一敲就能跑起来，省去很多手工管理模型的琐碎工作。如果你喜欢自己掌控一切，llama.cpp也能实现同样效果，就是需要自己处理更多细节。

安装Ollama的方式很简单，参考官方文档用安装脚本装就行。装好之后检查一下服务是否正常运行，可以执行几条健康检查相关的命令确认状态。模型下载直接执行拉取命令，指定我之前说的量化tag，第一次它会自动下载好放本地。

下载过程快慢就看网络了，一般十几分钟到半小时不等，社区有加速源可以切换，用起来更快一点。拉完之后随时可以查看本地模型列表确认状态。最关键的启动命令是执行对话请求，指定模型名和一个简单的提示词，看看模型能不能正常返回内容。这一步通了，说明推理层没问题，为后面接Router打个稳定的底。

2.3 推理服务启动与性能基准实测

Ollama装好之后，默认监听在本地的11434端口，但实际调用时经常需要调整并发参数。默认配置里并发请求数偏保守，多开Claude Code几个会话就会排队。我建议在Ollama服务配置里把并发数调高一点，我调到了4，这样同一时间能处理四个拆分任务，不冲突乱答。另外要开OLLAMA_KEEP_ALIVE参数，模型常驻显存，避免每次请求都重新加载权重，那会慢得让人崩溃。

性能数据方面我做个参考：我的机器是RTX 4070 Ti SUPER，16GB显存，跑Q4_K_M的GLM-4.5-Air，单次请求的接收首token的延迟大概在300到500毫秒左右，完整生成100个token大约需要2到3秒，整体生成速度在每秒45个token上下。这个速度对代码补全和短对话完全够用，但当并发数拉高到4的时候，速度会掉到每秒30个token左右，响应延迟也会翻倍，所以如果你的应用场景里面交互特别频繁，还是控制一下并发数，或者选更大显存的卡。

另外一个容易被忽略的点是，修改Ollama的端口监听。默认只监听127.0.0.1，如果Claude Code和Router跟Ollama不在同一台机器上，就得把监听地址改成0.0.0.0，否则远程调用会被拒之门外。改了之后记得加一层防火墙限制，只允许可信IP访问11434端口，因为Ollama本身没有内置鉴权，直接暴露到局域网等于裸奔，安全性上有隐患。

2.4 启动自检建议参考

模型部署完先别急着去配Router，我强烈建议在终端里先跑几个简单的测试用例来验证推理质量。比如让模型解释一段递归函数，给它一道动态规划的题目让它手写题解，再让它对一段没有注释的代码补上注释，看看输出的指令遵循能力和代码生成质量是否符合预期。这一步能帮你建立对模型能力的直觉，后面接上Claude Code之后，一旦出现输出质量诡异的情况，你能更快判断到底是模型的问题还是Router配置的问题。本地跑模型遇到的结果和预期不符，大部分时候不是模型笨，而是提示词的表达方式没跟上模型的输出习惯，这个阶段多做几个方向的提示词实验，调整好再上生产链路。

3. Claude Code Router配置实战：协议转换、模型映射与跨域设置

3.1 路由策略选择：正则匹配优先的代理配置方案

Router的核心工作是把Claude Code发来的请求规整成GLM-4.5-Air能消化好的格式。市面上现成的Router方案不少，有些重度依赖一套比较重的配置框架，动辄几百行YAML，看着很唬人，实际改动一个参数要重启好几次。我最后选的是一个基于Node.js的轻量方案，它用re锚点来匹配请求路径，配置简单直接，符合"少即是多"的思路。

项目的结构是一个主文件加一个配置文件。主文件里定义了一组路由匹配规则，标注了模型名映射和接口地址指向；配置文件把模型列表和名称对应关系集中管理。我整理了一下最核心的路由配置，你参考的时候可以按实际路径调整一下：

routes: [ { path: '/v1/messages', model: 'glm-4.5-air', target: 'http://127.0.0.1:11434' }, { path: '/v1/complete', model: 'glm-4.5-air', target: 'http://127.0.0.1:11434' } ]

这个配置的好处是，你只需要改model字段和target字段就能切换模型或改后端服务地址。哪天跑RAG了或者想接一个新模型，把模型名替换一下就行，Claude Code前端的交互方式不用做任何改动。这个设计在后期扩展时能省很多事，不用改前面的交互层。

3.2 API规范转换：Claude消息格式到OpenAI格式的映射细节

协议转换是Router里最核心的一部分，也是最容易出问题的地方。Claude Code发出来的请求是Anthropic Messages API格式，核心字段包括model、system、messages、max_tokens、temperature等。而本地GLM-4.5-Air走的是OpenAI兼容接口，需要的字段是model、messages、temperature、max_tokens，而且message里每项的role必须严格符合system/user/assistant的枚举值，一旦出现developer这类角色名，部分推理框架会直接拒绝。

转换逻辑里需要拆解的字段有几个。system字段要取出来拼到第一条user消息前面，因为前面的思路里提过，GLM-4.5-Air对system的支持比较弱；max_tokens也要做映射，Claude Code默认发4096，直接透传给模型可能会因为输出长度超限产生不必要的截断，我这边给它设成8192；temperature保持原样透传就行。

代码层面核心转换逻辑可以这样实现：

function convertAnthropicToOpenAI(anthropicBody) { const messages = []; if (anthropicBody.system) { messages.push({ role: 'user', content: anthropicBody.system }); } for (const msg of anthropicBody.messages) { if (msg.role === 'assistant') { messages.push({ role: 'assistant', content: msg.content }); } else { messages.push({ role: 'user', content: typeof msg.content === 'string' ? msg.content : msg.content.map(b => b.text || '').join('\n') }); } } return { model: 'glm-4.5-air', messages: messages, max_tokens: 8192, stream: anthropicBody.stream || false }; }

这里有个细节值得注意：Claude Code的messages里可能带tool_result这种特殊角色，转换时需要根据名字或者前一条内容判断是继续对话还是工具结果回调。我处理的方式是把所有非human、非assistant的内容统一转成user角色，并把内容前加上"工具执行结果："前缀。这样模型能清楚知道后面跟的是终端执行输出还是真正的用户指令，不至于角色错乱，导致代码生成上下文混乱。

3.3 跨域与服务端口配置的避坑要点

跨域配置是这个Router方案里一个不起眼但特别关键的坑点。Claude Code虽然是命令行工具，但它内置的请求库会做CORS检查，如果Router响应头里不带Access-Control-Allow-Origin，请求会被浏览器拦截（如果你是配合Web版本使用），或者在某些Node环境下直接报错。我一开始没配跨域头，结果Claude Code一直报"Network Error"，排查了半天才定位到是跨域问题。

我的处理办法是在Router的主服务文件里加一个中间件，统一注入跨域相关的响应头：

app.use((req, res, next) => { res.header('Access-Control-Allow-Origin', '*'); res.header('Access-Control-Allow-Methods', 'GET, POST, OPTIONS'); res.header('Access-Control-Allow-Headers', 'Content-Type, Authorization'); if (req.method === 'OPTIONS') { return res.sendStatus(200); } next(); });

端口设置方面，我让Router监听在8787端口，因为8787和Claude Code默认环境变量里配置的9080端口不冲突，后面接入时更清晰。这里有个容易误导的点，Claude Code默认的API端点地址构造成http://127.0.0.1:8787就能直接指到Router，环境变量设对之后就不需要额外改端口映射，几个关键环境变量配合使用才能把链路整个打通。

3.4 鉴权与安全性的最低要求配置

Router本身没有内置鉴权，但Claude Code发请求时会带一个x-api-key的头。我实测下来，Router不会校验这个头的值，只是透传。虽然方便，但安全性上留了隐患。如果你的电脑跟其他设备在同一局域网，其他人知道IP和端口就能直接调用你的Router然后间接调本地模型，虽然流量不算大，但也不应该裸奔。我的建议是至少在Router这一层加一个简单的apiKey校验中间件，跟Claude Code环境变量里配置的API Key保持一致就可以。这样即使端口暴露，没有对应的Key也调不动，安全性提高不少。

4. Claude Code接入与日常工作流整合

4.1 环境变量配置与全局安装

Router跑起来之后，接入Claude Code的过程其实就变成了配置环境变量的事儿。先全局安装Claude Code的命令行包，然后设置ANTHROPIC_BASE_URL指向Router的地址，再设置ANTHROPIC_AUTH_TOKEN为任意值占位，因为Router不校验Key，但有值总比空着稳。最后再配一个模型相关变量，Claude Code走自定义端点时总想找默认模型名，不设的话请求打过来模型名就容易对不上，让Router无法正确匹配到本地模型。

配置完成之后需要验证链路是否已经通。在终端里向Claude Code发一条最简单的消息，比如让它帮自己当前目录下的文件做一个代码概览。观察两个地方：Router的控制台日志有没有收到请求；返回速度是否在合理范围，REST请求转回本地模型一般不超过5秒。如果这两个都正常，就说明整条链路已经通了。

4.2 典型使用场景实操参考

接入成功之后，我日常使用最多的场景有三个。第一个是代码解读，扔给它一个几千行的模块，让它按类和方法梳理出核心逻辑和调用关系。GLM-4.5-Air对中文提示词理解比较准确，我一般会明确要求"按模块输出，标注关键函数时间复杂度"，这样它给出的结果更有条理。

第二个是用例生成。给它一个函数名和几个边界条件，让它写单测样例，注意生成的比较简单，但优势是稳定，不会频繁报网络错误。我会在提示词里加上"用Go的标准库test框架，不用第三方断言组件"，这样生成的代码直接能用，不用手动改依赖。

第三个是commit信息生成。让Claude Code读取暂存区文件差别，用简洁的语言概括变更内容。本地模型的输出比云端模型更精简，通常一句话能说明白，这个特点在提交日志里反而成了优点。不过它对表情符号这类花活支持有限，就不要尝试让它加表情了。

4.3 多模型切换与工作流组织建议

Router的模型映射支持配置多个名称指向同一个后端模型之外，也可以指向不同后端。我在Router里配了两个模型名做对照实验，一个指向GLM-4.5-Air，一个指向更小的一个量化版本模型。切换模型只需要改提示词里的模型变量，不需要改Router配置。这个灵活度对工作流组织帮助很大：日常小任务用轻量模型减少推理时间，偶尔来一轮深度重构就用满血一点的版本，同样一套Claude Code交互，背后模型按需切换。

我推荐你在日常使用中建立一套优先级规则。高频小动作比如解释函数、生成正则、格式化JSON，用轻量模型跑，速度是硬指标；低频但复杂的任务比如模块重构、设计评审，切大模型，质量和理解深度更重要。这套规则落地起来非常简单，本质就是改一个环境变量或者提示词前缀，Router自动完成后面的路由分发。

4.4 系统资源监控的必要性

接上Claude Code之后，本地推理服务的负载明显升高，尤其是并发对话场景。我习惯同时开着资源监控面板和Ollama日志窗口。资源监控面板负责看显存占用和GPU使用率，一旦发现显存快满了就得赶紧清理会话或减少并发数；Ollama日志负责看请求排队数和处理耗时，这两个数值能帮你判断是模型本身慢还是后端服务配置瓶颈。有一次我排查一个响应慢的问题，折腾半天发现是同行在跑一个推理任务，我的请求被Ollama串行排队了，资源监控面板上的GPU利用率曲线帮我快速定位到了这个原因。

5. 常见问题排查与性能调优实录

5.1 典型故障对照表

这些故障我在调试阶段基本都踩过一遍，其中踩得最惨的是messages角色转换那一次。Router日志显示请求转发过去了，Ollama也正常响应，但返回的内容逻辑混乱、答非所问。后面仔细对比请求体才发现，tool_result角色的内容被当成assistant回复发给了模型，模型误以为那是自己之前说的话，上下文就乱套了。修复方式就是加上前缀并统一转成user角色，效果立竿见影。

5.2 性能调优：并发参数与KV Cache的实践经验

性能调优这块，最见效的三个参数分别是并发数、KEEP_ALIVE和KV Cache量化。

并发数前面提过，从默认1调到4，明显减少多个会话请求时的排队时间。但这个值不是越大越好，并发拉满之后显存占用会快速上涨，之前试过调到8，结果显存溢出导致推理服务直接崩溃。合理值需要结合模型大小和显存实测，以我的配置为例，4并发稳定，6并发偶尔报显存不足，所以保守起见留在4。

KV Cache量化是Ollama 0.5版之后才引入的功能。原理是把注意力机制里的Key和Value缓存从FP16降到8bit或4bit，显存占用可以降低大概百分之十几。在Q4_K_M模型上试过开启8bit量化，输出质量几乎感知不到下降，显存占用降了12%左右。对显存紧张但想拉高并发的场景，这个开关非常值钱。开启方式在Ollama的API请求参数里加use_kv_cache_quantize字段并设为F8，注意不是所有版本的Ollama都支持这个参数，需要先确认log里有没有对应的启动标志。

5.3 排查提示词兼容性的独家经验

最后一个想分享的经验是关于提示词兼容性的。GLM-4.5-Air对中文和英文混排的提示词有不同的表现。实测下来，代码生成任务里用英文写指令时，模型更倾向于严格遵循格式，生成标准库代码；而用中文时，模型对意图的理解更准，但生成的代码偶尔会混入中文注释。我目前的策略是，代码生成类任务提示词用英文，逻辑解释类任务提示词用中文，两边的体验都提升一个档次。这个规律没有写在任何官方文档里，纯属多次对照测试总结出来的个人经验。

另外，GLM-4.5-Air在长上下文的场景下，更关注离问题最近的那部分内容，如果让它基于一个几百行文件做重构，建议在提示词里明确引用关键函数名和行号，它给出的修改建议会更精准，这个跟其他模型的动力学很不一样，值得适应。

6. 后续扩展建议与最终落地体验

整套流程稳定运行了两周后，我总结了一些可扩展的方向。最直接的做法是在Router层接入更多本地模型，比如代码专用微调模型或者更轻量的快速响应模型，通过关键词路由或优先级设置自动分配请求，这样就能形成一个多模型协作的架构。另外，Router的配置结构也支持在请求转发前嵌入一层后处理逻辑，比如自动过滤敏感信息、对代码段落做格式化等，这个扩展点我在实际中尝试过，效果不错。

如果愿意再往前走一步，还可以把Router和本地的代码搜索服务结合起来。在工具调用阶段拦截Claude Code的搜索请求，通过本地索引接口做代码定位，再把结果返回给模型，这样它的回答会更贴合当前代码库的情况。不过这个方案会增加不少改动量，属于进阶玩法了。

我个人实际操作下来的体会是，本地部署大模型加Router接入Claude Code这套链路，核心价值不只是省下API费用，更重要的是把一个可定制、可信赖的AI编码助手完全掌握在自己手里。从模型选择到提示词风格再到并发策略，每一层都可以按自己的使用习惯调优，这种掌控感是纯云端服务给不到的。如果你手里的显卡刚好符合要求，非常建议花一个周末把这条链路搭起来试试，投入的时间一定会在后续开发效率上挣回来。