<实测>opus4.6蒸馏qwen3.5的qwopus3.5-27B-v3-8b,结尾结论,已解决 接入原生claude code缓存问题
- 内容介绍
- 文章标签
- 相关推荐
前情提要：
最近把自己的 M1 Pro 32G 设备换成了 M5 Max 128G，算是一次“鸟枪换炮”。
再加上这段时间中转用 Opus 4.6，用的时候没啥感觉，回头一看账单——脑壳都大了。
11484×297 28.8 KB
一天消耗普遍在 300～500 RMB。既然刚好换了 M5 Max，那不如把一些轻量开发/分析任务交给本地模型：重度规划再用 Opus，日常就尽量“本地解决”。
说干就干。最近 Hugging Face 上 Opus 4.6 蒸馏的 Qwen3.5 很火，于是就记录一下我从部署到实战验证的过程。
1. 环境部署
这里我选择 MLX-LM，而不是 Ollama 的 MLX 版本。
原因主要有三点：
- 原生 MLX 性能更“干净”，大上下文时更不容易出现性能抖动
- 可以更灵活地调整内存上限
- Ollama 虽然方便，但毕竟多了一层封装
# 创建并进入虚拟环境
python3 -m venv mlx_env
source mlx_env/bin/activate
# 安装 MLX 核心及优化扩展
python3 -m pip install -U mlx-lm mlx huggingface_hub
# 安装 LM Studio
curl -fsSL https://lmstudio.ai/install.sh | bash
# 或者使用 GUI 客户端
https://lmstudio.ai/
2. 下载模型
在 LM Studio 里搜索 MLX-qwopus3.5-27B。注意：一定要选 MLX 版本（Mac 上的加速优势就在这，不选等于白换）。
既然有 128G 内存，空间比较富裕，我直接选择 bf16 顶配。
21084×880 103 KB
53G，下载大约 10 分钟完成。
3. 运行模型
进入 Local Server → Running → Load Model。
加载模型大概 3～5 秒。
31554×820 89.8 KB
服务开启后，记得去配置上下文长度。我这里直接拉满（大约 256k），再高其实没必要，反而更容易出现幻觉。
41547×475 50.5 KB
加载完毕后，在对话框里简单测一下：
51549×383 13.6 KB
6778×254 22.3 KB
然后直接 New Chat：
7957×458 21 KB
4. 接入 Claude Code
既然是 Opus 4.6 蒸馏的模型，那我就想接入 Claude Code 试试。
主要目的是学习/复用 Claude Code 的工具调用方式——它在“怎么用工具”这件事上确实有不少值得借鉴的设计。
老朋友 cc-switch 登场。
因为是本地服务，密钥随便填（本地一般不会校验）。另外 LM Studio 的 server 支持 Anthropic 原生格式，所以配置起来非常顺滑。
81345×777 47.4 KB
保存之后，准备开炮。
5. 对话测试
91340×737 66 KB
很快就能发现：在 Claude Code 里同样的问题响应明显更慢。
- 在 LM Studio 里问同样的问题（比如“你是什么模型”），耗时大概 11.96 秒
- 在 Claude Code 里同样的请求，耗时能到 50 秒
我翻了下 server log，发现 Claude Code 客户端会附带一大坨“工具调用姿势”的系统提示词（tool use instructions）。
101051×668 26.8 KB
不过也能理解：既然想用它的工具调用方式，就得接受它的提示词开销。
对一些对时效不敏感的小任务来说，这点延迟也还行。
6. 任务实战
来个实际任务验证一下：
通过 IDA Pro MCP 分析某个 password 的加密算法。
111318×330 29.1 KB
我又看了下 log：Claude Code 自带的“工具调用提示词”太大，把上下文直接顶到了截断。
但我只是想调用 MCP 而已，怎么就被提示词塞满了？肯定哪里不对。
进一步复查后发现：我跑的是 bf16，在某些情况下会拖垮带宽（以及整体吞吐），所以决定换一个更轻的 8B 模型重新下载。
121298×147 7.61 KB
继续开炮：
131340×944 130 KB
这次输出明显正常了，不再出现截断。
继续观察后发现：大部分时间其实都花在“读/加载 Claude Code 的系统提示词”上。
141200×704 126 KB
查资料后发现，新版本在请求时会在请求头里加入一些每次都会变化的值，并且把这些值拼进提示词里，导致每次都要重新载入系统提示词（缓存命中率下降），整体就更慢。
于是我在 LM Studio 里直接对话验证一下：
151042×1097 70.9 KB
在 LM Studio 里一切正常。
最后我用一道我已知答案的题做最终测试，看看 Opus 4.6 蒸馏的 Qwen3.5 是否“能打”。
161210×1107 67 KB
171245×1158 94.4 KB
181179×1280 97.8 KB
对比已知答案：虽然有一点偏差，但经过一些“古法微调”（提示词/约束调整）后，我觉得 Opus 4.6 蒸馏的 Qwen3.5 在执行“时效要求不高、但需要工具/分析能力”的任务时，还是相当能打的。
最关键的是：不要钱。 本地做普通开发,的确是很强了,下一次尝试opus4.6蒸馏的谷歌最强开源模型 gemma4
最后结论,小任务绝对够用,重度任务使用 opus,轻度任务使用本地模型,甚至可以opus把重度任务拆封成多个小计划,让本地模型来执行,那真是大大节省了token,还提高了可玩性,再也不担心破甲问题了~~
网友解答：--【壹】--：
同问, 这是什么原理>
居然改成openai格式就能用缓存了
--【贰】--：
谢谢佬，回头就去试试，这样的话感觉方便很多！
--【叁】--：
已解决 接入原生claude code缓存问题
image1236×920 125 KB
cc switch中使用OpenAl Chat Completions 并且开启代理
image360×128 7.66 KB
image1345×777 52.6 KB
--【肆】--：
用开源版本的CC改一下应该能解决掉，github应该有这种项目
而且本地的最大优势是并发，也就是/subagent或者并行的tool use
--【伍】--： son0ma:
新版本在请求时会在请求头里加入一些每次都会变化的值
怪不得都在喷缓存率降低了，真鸡贼啊这操作
--【陆】--：
感谢分享～我是 m3max128g，闲了也部署个玩玩
--【柒】--：
太及时了佬，正想测这个呢，这下直接吃现成的了
--【捌】--：
我用win11，8g显卡只能部署qwopus9b版本
--【玖】--：
image960×640 77.1 KB
最后附上一张 运行时的 内存占用~
--【拾】--： son0ma:
查资料后发现，新版本在请求时会在请求头里加入一些每次都会变化的值，并且把这些值拼进提示词里，导致每次都要重新载入系统提示词（缓存命中率下降），整体就更慢。
a不干人事啊，这样第三方厂商的模型用claude code不全部丢缓存
--【拾壹】--：
感谢佬友的分享，另外我记得有个omlx的开源项目部署应该可以提高缓存，比lmstudio高效不少，也可以看看
--【拾贰】--：
image2516×1170 140 KB
我也这个配置 不知道为什么感觉变慢了之前跑 qwen 都有 59t 的
--【拾叁】--：
我也好奇原理是什么， 能否展开说说， 有没有参考文章？
--【拾肆】--：
佬, 听说是因为 MBP 的内存带宽不够导致 TPS 太低
你有这个感觉吗
--【拾伍】--：
感谢分享，意思是额外套一层openai后，claudecode就不会增加变化的值吗？
--【拾陆】--：
感谢干货贴分享，opus4.6蒸馏gemma4
--【拾柒】--：
谢谢分享,我这里也正使用LM Studio下载试试
--【拾捌】--：
a就是这个样子的。给所有接入他家 claudecode的人使绊子，缓存灰飞烟灭
--【拾玖】--：
单卡5090 32G跑27B opus蒸馏版本的NVFP4版本，拿来做公司subagent专干脏活累活还是挺不错的，工具调用什么的都比较ok，能跑256K上下文（实际用不了这么高），测试过低上下文16并发最高800多token/s，用的vllm，实测vllm吊打sglang和其他工具，不过我是用cc配置的，也不排除它配置不正确
前情提要：
最近把自己的 M1 Pro 32G 设备换成了 M5 Max 128G，算是一次“鸟枪换炮”。
再加上这段时间中转用 Opus 4.6，用的时候没啥感觉，回头一看账单——脑壳都大了。
11484×297 28.8 KB
一天消耗普遍在 300～500 RMB。既然刚好换了 M5 Max，那不如把一些轻量开发/分析任务交给本地模型：重度规划再用 Opus，日常就尽量“本地解决”。
说干就干。最近 Hugging Face 上 Opus 4.6 蒸馏的 Qwen3.5 很火，于是就记录一下我从部署到实战验证的过程。
1. 环境部署
这里我选择 MLX-LM，而不是 Ollama 的 MLX 版本。
原因主要有三点：
- 原生 MLX 性能更“干净”，大上下文时更不容易出现性能抖动
- 可以更灵活地调整内存上限
- Ollama 虽然方便，但毕竟多了一层封装
# 创建并进入虚拟环境
python3 -m venv mlx_env
source mlx_env/bin/activate
# 安装 MLX 核心及优化扩展
python3 -m pip install -U mlx-lm mlx huggingface_hub
# 安装 LM Studio
curl -fsSL https://lmstudio.ai/install.sh | bash
# 或者使用 GUI 客户端
https://lmstudio.ai/
2. 下载模型
在 LM Studio 里搜索 MLX-qwopus3.5-27B。注意：一定要选 MLX 版本（Mac 上的加速优势就在这，不选等于白换）。
既然有 128G 内存，空间比较富裕，我直接选择 bf16 顶配。
21084×880 103 KB
53G，下载大约 10 分钟完成。
3. 运行模型
进入 Local Server → Running → Load Model。
加载模型大概 3～5 秒。
31554×820 89.8 KB
服务开启后，记得去配置上下文长度。我这里直接拉满（大约 256k），再高其实没必要，反而更容易出现幻觉。
41547×475 50.5 KB
加载完毕后，在对话框里简单测一下：
51549×383 13.6 KB
6778×254 22.3 KB
然后直接 New Chat：
7957×458 21 KB
4. 接入 Claude Code
既然是 Opus 4.6 蒸馏的模型，那我就想接入 Claude Code 试试。
主要目的是学习/复用 Claude Code 的工具调用方式——它在“怎么用工具”这件事上确实有不少值得借鉴的设计。
老朋友 cc-switch 登场。
因为是本地服务，密钥随便填（本地一般不会校验）。另外 LM Studio 的 server 支持 Anthropic 原生格式，所以配置起来非常顺滑。
81345×777 47.4 KB
保存之后，准备开炮。
5. 对话测试
91340×737 66 KB
很快就能发现：在 Claude Code 里同样的问题响应明显更慢。
- 在 LM Studio 里问同样的问题（比如“你是什么模型”），耗时大概 11.96 秒
- 在 Claude Code 里同样的请求，耗时能到 50 秒
我翻了下 server log，发现 Claude Code 客户端会附带一大坨“工具调用姿势”的系统提示词（tool use instructions）。
101051×668 26.8 KB
不过也能理解：既然想用它的工具调用方式，就得接受它的提示词开销。
对一些对时效不敏感的小任务来说，这点延迟也还行。
6. 任务实战
来个实际任务验证一下：
通过 IDA Pro MCP 分析某个 password 的加密算法。
111318×330 29.1 KB
我又看了下 log：Claude Code 自带的“工具调用提示词”太大，把上下文直接顶到了截断。
但我只是想调用 MCP 而已，怎么就被提示词塞满了？肯定哪里不对。
进一步复查后发现：我跑的是 bf16，在某些情况下会拖垮带宽（以及整体吞吐），所以决定换一个更轻的 8B 模型重新下载。
121298×147 7.61 KB
继续开炮：
131340×944 130 KB
这次输出明显正常了，不再出现截断。
继续观察后发现：大部分时间其实都花在“读/加载 Claude Code 的系统提示词”上。
141200×704 126 KB
查资料后发现，新版本在请求时会在请求头里加入一些每次都会变化的值，并且把这些值拼进提示词里，导致每次都要重新载入系统提示词（缓存命中率下降），整体就更慢。
于是我在 LM Studio 里直接对话验证一下：
151042×1097 70.9 KB
在 LM Studio 里一切正常。
最后我用一道我已知答案的题做最终测试，看看 Opus 4.6 蒸馏的 Qwen3.5 是否“能打”。
161210×1107 67 KB
171245×1158 94.4 KB
181179×1280 97.8 KB
对比已知答案：虽然有一点偏差，但经过一些“古法微调”（提示词/约束调整）后，我觉得 Opus 4.6 蒸馏的 Qwen3.5 在执行“时效要求不高、但需要工具/分析能力”的任务时，还是相当能打的。
最关键的是：不要钱。 本地做普通开发,的确是很强了,下一次尝试opus4.6蒸馏的谷歌最强开源模型 gemma4
最后结论,小任务绝对够用,重度任务使用 opus,轻度任务使用本地模型,甚至可以opus把重度任务拆封成多个小计划,让本地模型来执行,那真是大大节省了token,还提高了可玩性,再也不担心破甲问题了~~
网友解答：--【壹】--：
同问, 这是什么原理>
居然改成openai格式就能用缓存了
--【贰】--：
谢谢佬，回头就去试试，这样的话感觉方便很多！
--【叁】--：
已解决 接入原生claude code缓存问题
image1236×920 125 KB
cc switch中使用OpenAl Chat Completions 并且开启代理
image360×128 7.66 KB
image1345×777 52.6 KB
--【肆】--：
用开源版本的CC改一下应该能解决掉，github应该有这种项目
而且本地的最大优势是并发，也就是/subagent或者并行的tool use
--【伍】--： son0ma:
新版本在请求时会在请求头里加入一些每次都会变化的值
怪不得都在喷缓存率降低了，真鸡贼啊这操作
--【陆】--：
感谢分享～我是 m3max128g，闲了也部署个玩玩
--【柒】--：
太及时了佬，正想测这个呢，这下直接吃现成的了
--【捌】--：
我用win11，8g显卡只能部署qwopus9b版本
--【玖】--：
image960×640 77.1 KB
最后附上一张 运行时的 内存占用~
--【拾】--： son0ma:
查资料后发现，新版本在请求时会在请求头里加入一些每次都会变化的值，并且把这些值拼进提示词里，导致每次都要重新载入系统提示词（缓存命中率下降），整体就更慢。
a不干人事啊，这样第三方厂商的模型用claude code不全部丢缓存
--【拾壹】--：
感谢佬友的分享，另外我记得有个omlx的开源项目部署应该可以提高缓存，比lmstudio高效不少，也可以看看
--【拾贰】--：
image2516×1170 140 KB
我也这个配置 不知道为什么感觉变慢了之前跑 qwen 都有 59t 的
--【拾叁】--：
我也好奇原理是什么， 能否展开说说， 有没有参考文章？
--【拾肆】--：
佬, 听说是因为 MBP 的内存带宽不够导致 TPS 太低
你有这个感觉吗
--【拾伍】--：
感谢分享，意思是额外套一层openai后，claudecode就不会增加变化的值吗？
--【拾陆】--：
感谢干货贴分享，opus4.6蒸馏gemma4
--【拾柒】--：
谢谢分享,我这里也正使用LM Studio下载试试
--【拾捌】--：
a就是这个样子的。给所有接入他家 claudecode的人使绊子，缓存灰飞烟灭
--【拾玖】--：
单卡5090 32G跑27B opus蒸馏版本的NVFP4版本，拿来做公司subagent专干脏活累活还是挺不错的，工具调用什么的都比较ok，能跑256K上下文（实际用不了这么高），测试过低上下文16并发最高800多token/s，用的vllm，实测vllm吊打sglang和其他工具，不过我是用cc配置的，也不排除它配置不正确