Qwen3.5-9B 本地部署与 Claude Code 接入:协议不兼容?手搓一个代理就好啦
Ollama:

Claude Code:

前言
上篇 折腾完 Qwen3.6-35B-A3B 之后,本地有了一个说得过去的日常对话模型。但用了一阵子发现,3B 的激活参数量在工具调用和复杂代码生成上还是差点意思——让它给 Claude Code 当 Agent 主力,经常出现工具参数填错、步骤遗漏之类的问题。
于是决定再部署一个 Qwen3.5-9B,跟 35B-A3B 做分工:9B 负责 Agent 和编码,35B-A3B 负责快速对话。一快一猛,换着用。
9B 密集模型的显存占用比 MoE 大不少,8GB 显卡刚好卡在临界点上。而且这次的目标不只是跑通模型——要让 Claude Code 和 OpenCode 都能用上它,中间还踩了个 Anthropic 和 OpenAI 协议不兼容的大坑。
一、硬件环境:8GB 显存,够吗?
关键瓶颈:8GB 显存。
FP16 的 9B 模型约 18GB,8GB 卡门都进不去。必须量化。好在 Ollama 默认就是 Q4_K_M,模型约 6.6GB,全塞进显存还剩约 1.5GB 给 KV Cache——刚好够用,但别指望同时跑第二个模型。
二、方案选型:为什么是 Ollama
Ollama 的优势:Windows 原生安装包、模型管理像 docker pull 一样简单、内置 OpenAI 兼容 API(localhost:11434/v1)、自动 GPU 加速。
权衡:灵活性不如 llama.cpp 原生(比如不能精确控制 GPU offload 层数),但对个人使用场景完全够用。
量化策略对比
选定 Q4_K_M。
三、模型部署:两行命令,半小时等待
3.1 安装 Ollama
安装后托盘出现小羊驼图标,服务自动运行。版本 0.24.0。
3.2 拉取模型
6.6GB 的 GGUF 文件,在 10 MB/s 的速度下大约 11 分钟。期间我经历了两次下载中断(Windows 网络波动),好在 Ollama 支持断点续传。
3.3 创建 Agent 优化版(推荐)
默认模型上下文窗口偏小,且没有 Agent 场景的系统提示词。我写了一个 Modelfile:
然后:
搞定了两个模型:
qwen3.5:9b— 基础版,日常使用qwen3.5:9b-agent— 优化版,32K 上下文 + 编程助手提示词
3.4 验证
两测均通过。此时如果只是用 ChatGPT-Next-Web 之类的 OpenAI 客户端,故事已经结束了。
但你猜怎么着?我要接的是 Claude Code。
四、Claude Code 接入:一场持续 3 小时的协议战争
4.1 第一次尝试:直接配 openaiProvider(失败)
Claude Code 文档说支持 openaiProvider,配置如下:
结果:Not logged in · Please run /login
原因是 Claude Code v2.1.79 在检测到 openaiProvider 后,仍然会先走 Anthropic 认证流程。认证不过,直接拒绝服务。这就像你告诉出租车司机"我有导航",司机说"不行,我得先用我的导航确认一下路"。
4.2 第二次尝试:用 Anthropic 环境变量冒充(失败)
我想的是:让 Claude Code 以为它在跟 Anthropic 服务器说话,实际上指向 Ollama。
现实:Claude Code 发送的是 Anthropic Messages API 格式的请求(/v1/messages,JSON 结构是 Anthropic 风格),Ollama 只理解 OpenAI Chat Completions 格式(/v1/chat/completions,JSON 结构是 OpenAI 风格)。
结果:There's an issue with the selected model。Ollama 看不懂 Anthropic 的请求格式,回复了 404。
这个思路方向对了,但缺了一个翻译层。
4.3 第三次尝试:Litellm 代理(差点成功)
Litellm 是一个 LLM API 网关,支持 Anthropic ↔ OpenAI 协议转换。但它的完整功能(proxy mode)需要安装 30+ 个依赖包,其中包括 websockets、fastapi、uvicorn 等。
安装成功后启动:
结果请求被转发到了 DeepSeek 的 API 地址,而不是本地的 Ollama。原因是 litellm 读取了环境变量里的 ANTHROPIC_BASE_URL(之前配 CC Switch 时留下的 DeepSeek 地址),自作主张地把请求转给了 DeepSeek。
我陷入了凝视 /dev/null 的深渊。
4.4 第四次尝试:手搓协议转译代理(成功)
"既然 litellm 这么复杂,不如自己写一个。"
核心需求极其简单:
- 监听 8787 端口
- 接收 Anthropic
/v1/messages格式请求 - 转成 OpenAI
/v1/chat/completions格式发给 Ollama - 把 Ollama 的 OpenAI 格式响应转回 Anthropic 格式
- 返回给 Claude Code
Python 标准库就够了(http.server + urllib.request + json),不到 200 行代码。
遇到的坑与解
核心代码片段
请求转译(Anthropic → OpenAI):
响应转译(OpenAI → Anthropic):
完整代码放在项目目录下的 proxy.py,约 180 行。
五、架构总览:最终的调用链
三条黄金法则:
- Claude Code 只吃 Anthropic 格式——给它 OpenAI 格式会噎着
- Ollama 只吃 OpenAI 格式——给它 Anthropic 格式它不认识
- 代理什么都吃,什么都吐——像一个尽职的翻译官
六、CC Switch 无缝集成
CC Switch 是 Claude Code 的多 Provider 管理器——我日常在 DeepSeek、智谱、本地模型间切换。
在 CC Switch 中新建一个 Claude Provider,配置为:
注意:ANTHROPIC_BASE_URL 填的是代理端口 8787,不是 Ollama 的 11434。
启动方式:
重要:代理必须保持运行!建议开一个独立的终端
python proxy.py常驻,或配置为 Windows 服务。
七、模型分工策略
启动 CC Switch 的 Local Proxy 特性后,可以利用故障切换(Failover)功能实现智能路由:
这样平常走 DeepSeek 云端的强推理能力,断网或需要隐私时自动切到本地模型——鱼和熊掌,能兼得。
八、服务管理与常用命令
九、故障排查速查表
十、总结
这次部署让我深刻体会到:AI 模型的部署本身已经简单到令人发指(两条命令),但让它跟你已有的工具链谈恋爱,才是真正的修罗场。
核心收获:
- 8GB 显存够用但不宽裕。Q4_K_M 量化 + 32K 上下文,实测 7.5GB 显存占用,勉强塞下。别同时跑两个模型。
- Ollama + Claude Code 的协议鸿沟是真实存在的。Ollama 讲 OpenAI 方言,Claude Code 只认 Anthropic 普通话。需要中间人翻译。
- 手搓代理虽不优雅但有效。180 行 Python 标准库代码解决了 3 小时的踩坑。有时候最朴素的方法最好用。
- CC Switch 是管理多 Provider 的神器。云端国产 API + 本地模型,一键切换,互不干扰。
- 冒号能杀人。
qwen3.5:9b-agent中的冒号被 Claude Code 预检拦截,改成qwen3.5-9b-agent就通了。有时候 bug 就是一个小字符。
最后送上一句:如果你也在 Windows + 8GB 显卡上部署本地 LLM 给 Claude Code 用——记住,这不是技术问题,这是翻译工作。雇一个代理就好。
附录
A. Modelfile — Agent 优化版模型定义
创建命令: