Qwen3.5-9B Opus V2 蒸馏版本地部署实测
作者： 寂寞的熊猫
发布时间： 2026-03-28
原文链接： https://mp.weixin.qq.com/s/GuqSJpbEbpHVCd88e6xtMQ
📖 目录
- 省流版结论
- Opus V2 蒸馏做了什么？
- [实测数据：跑满 262K 上下文](#03-实测数据跑满 262k 上下文)
- 接入 OpenClaw：9B 做本地龙虾
- 9B vs 27B：本地龙虾怎么选
- 写在最后
大家好，我是寂寞的熊猫。
之前我前后写了几篇：
如果我显存没那么大，只能用 9B，那么实际跑起来怎么样？
今天看看 Qwen3.5-9B opus V2 蒸馏版。
01. 省流版结论
opus V2 蒸馏的核心改进是"想得少但想得准"。推理链缩短 22%，HumanEval+ 正确率反而涨了 2.44 个百分点。
跑满 262K 上下文，Q4_K_M 量化总共吃了约 10.9GB 显存。模型本身只有 5.2GB，大头是 KV cache。缩短上下文到 8K-16K，8GB 显卡就能跑。
推理速度有两条线：thinking 模式约 50 tok/s，关掉 thinking 约 115 tok/s。对 OpenClaw 场景很重要——agentic 工作流里 thinking 有时候反而拖节奏。
02. Opus V2 蒸馏做了什么？
之前 Qwen3.5-27B 登顶 PinchBench，同时 Opus V2 蒸馏版发布，本地部署实测 已经详细讲过，这里简短说。
opus V2 蒸馏版核心变化：用 14,000+ 条 Claude Opus 风格推理数据训练，推理链更短，但正确率不降反升。
| 指标 | Qwen3.5-9B 基座 | 9B V2 蒸馏版 | 变化 |
|---|---|---|---|
| HumanEval pass@1 | 81.71% | 82.32% | +0.61pp |
| HumanEval+ pass@1 | 76.22% | 78.66% | +2.44pp |
| 平均推理链长度（字符） | 2284 | 1778 | -22.2% |
| 推理效率（每万字正确解数） | 4.0 | 5.0 | +25.9% |
打个比方：以前模型解题的时候，会在草稿纸上写满三页推导过程。现在只写两页，答案还更准了——不是偷懒，是真的想明白了。
03. 实测数据：跑满 262K 上下文
测试环境
- 模型： Qwen3.5-9B-Claude-4.6-Opus-Reasoning-Distilled-v2-GGUF
- 量化： Q4_K_M（文件 5.23 GiB，约 5.02 BPW）
- 多模态权重： mmproj-BF16.gguf（878.99 MiB）
- 推理引擎： llama-server（llama.cpp）
- 上下文长度： 262,144（262K 全开）
- 32 层全部卸载到 GPU
| 项目 | 显存占用 |
|---|---|
| 模型本身 | ~5,230 MiB |
| KV cache (262K) | ~4,352 MiB |
| mmproj | ~879 MiB |
| 合计 | ~10,901 MiB（约 10.6 GB） |
模型本身只有 5.2GB。吃显存的大头是 KV cache——262K 上下文的 KV cache 占了 4.4GB。
这意味着上下文越短，显存需求越低。按比例估算：
| 目标上下文 | KV cache（估算） | 总显存（估算） | 能跑的显卡 |
|---|---|---|---|
| 8K | ~130 MiB | ~6.7 GB | RTX 3060/4060 8GB |
| 16K | ~260 MiB | ~6.8 GB | 8GB 显卡稳跑 |
| 32K | ~530 MiB | ~7.1 GB | 8-12GB 显卡 |
| 128K | ~2,100 MiB | ~8.7 GB | 12GB 显卡 |
| 262K | 4,352 MiB | ~10.9 GB | 16GB 显卡 |
（估算不含 mmproj；如果不需要多模态，可以省掉 879 MiB）
一句话：不需要 262K 那么长上下文的话，8GB 显卡完全能跑。
推理速度
实测的多轮对话的 token 速度记录：
纯文本对话：
| 场景 | Prompt 处理 | 生成速度 | 备注 |
|---|---|---|---|
| 长 prompt（4831 tokens） | 1,699 tok/s | 51.67 tok/s | thinking 模式 |
| 中等 prompt（5388 tokens） | 1,680 tok/s | 50.14 tok/s | thinking 模式 |
| 短 prompt（526 tokens） | 3,110 tok/s | 116.87 tok/s | 非 thinking |
| 中等 prompt（1211 tokens） | 3,321 tok/s | 116.22 tok/s | 非 thinking |
| 长 prompt（3892 tokens） | 3,544 tok/s | 113.54 tok/s | 非 thinking |
| 短 prompt（280 tokens） | 2,865 tok/s | 116.43 tok/s | 非 thinking |
多模态对话（含图像）：
| 场景 | Prompt 处理 | 生成速度 | 备注 |
|---|---|---|---|
| 首次含图（4116 tokens） | 1,011 tok/s | 114.13 tok/s | 图像编码 3.9 秒 |
| 后续含图（965 tokens） | 1,805 tok/s | 115.66 tok/s | 图像编码 0.5 秒 |
生成速度有两个方面：
- Thinking 模式：约 50 tok/s — 模型在"写草稿"，生成大量推理 token
- 非 Thinking 模式：约 113-116 tok/s — 直接输出，速度翻倍
这不是 bug，是 9B V2 的设计特点。如果你不需要看推理过程，关掉 thinking，速度直接翻一倍。
Prompt 处理也很亮眼：短 prompt 能到 3000+ tok/s。在 OpenClaw 里，工具调用的响应延迟不会成为瓶颈。
和 27B 对比
之前测 27B opus V2（Q8_0，24GB 显卡）的数据：
- Prompt 处理：约 1,052 tok/s
- 生成：约 30 tok/s
9B opus V2（Q4_K_M）：
- Prompt 处理：1,700-3,500 tok/s（快 2-3 倍）
- 生成：50-116 tok/s（快 1.7-3.9 倍）
9B 的优势很清楚：牺牲一点推理质量，换来速度和资源的大幅改善。
04. 接入 OpenClaw：9B 做本地龙虾
测完了速度，关键问题是：9B V2 接到 OpenClaw 里实际体验怎么样？
llama-server 启动参数
实际测试用的启动命令（从日志里直接拉的）：
llama-server \
-m Qwen3.5-9B.Q4_K_M.gguf \
--mmproj mmproj-BF16.gguf \
--batch-size 1024 --ubatch-size 512 \
-c 262144 \
--cache-type-k q8_0 \
--cache-type-v q8_0 \
-ngl 99 \
-np 1 \
--flash-attn on \
--port 8197 --host 0.0.0.0 \
--temp 1.0 --top-p 0.95 --top-k 20 \
--cont-batching \
-t 16 -tb 32几个关键参数：
-c 262144：满上下文。大家根据自己资源调整。--cache-type-k q8_0 --cache-type-v q8_0：这边是为了拉高上下文做了 KV 量化-ngl 99：所有层卸载到 GPU--flash-attn on：Flash Attention，加速注意力计算--cont-batching：连续批处理，OpenClaw 多轮调用时有用
显卡 8-12GB 的，把 -c 改成 8192 就行，其他参数不用动。
不需要多模态的话，去掉 --mmproj 那一行，还能省 879 MiB 显存。
OpenClaw 配置
在 ~/.openclaw/openclaw.json 里加本地 provider：
{
"models": {
"mode": "merge",
"providers": {
"llamacpp": {
"baseUrl": "http://127.0.0.1:8197/v1",
"apiKey": "no-key-required",
"api": "openai-completions",
"models": [
{
"id": "qwen35-opus-distilled-v2",
"name": "Qwen3.5-9B",
"reasoning": true,
"input": ["text", "image"],
"cost": {"input": 0, "output": 0},
"contextWindow": 262144,
"maxTokens": 8192
}
]
}
}
}
}然后把 Agent 模型指向这个 provider 就行了。
实际使用体验
从日志看，OpenClaw 的 ReAct 循环（观察→推理→行动）在 9B V2 上跑得很流畅：
- 单轮工具调用延迟在 1-3 秒
- 思维标签解析正常，没出现 V1 的闭合失败问题
- prompt cache 命中率高，同 session 后续请求几乎不需要重新处理
但有一个实际体验上的问题：thinking 模式在 agentic 工作流里有时候是多余的。
ReAct 循环本身就是"思考→行动→观察"了。再叠加一层推理链，等于在想之前先想一遍要不要想——效率上不划算。
建议：
- 简单工具调用：关掉 thinking（
--reasoning-budget 0），直接跑 - 复杂推理（代码生成、规划）：开启 thinking，让模型想清楚再输出
05. 9B vs 27B：本地龙虾怎么选
最后聊很多人关心的问题：9B 和 27B，在 OpenClaw 场景下怎么选？
不用参数表，用场景说话。
显卡决定起点
| 显卡 | 推荐模型 | 上下文 | 体验 |
|---|---|---|---|
| 8GB（RTX 3060/4060） | 9B Q4_K_M | 8K-16K | 够用，工具调用流畅 |
| 12GB（RTX 3060 12GB） | 9B Q4_K_M | 32K-64K | 舒适，日常主力 |
| 16GB（RTX 4070 Ti/5060 Ti） | 9B Q8_0 或 27B Q4 | 8K-32K | 两个都能跑 |
| 24GB（RTX 3090/4090） | 27B Q8_0 | 16K-128K | 最佳体验 |
8GB 显卡，9B 是比较合适的选择。
一句话：资源有限时，9B opus V2 是本地龙虾的最佳入口。资源充足时，27B 是更全面的选择。
06. 写在最后
这篇文章的观点不是"9B 与 27B 的对比"——它们根本不是一个价位的选手。
我想说的是：对于大多数只有消费级显卡的人来说，9B V2 蒸馏版可能是目前本地龙虾最现实的起点。
从数据上看：
- 50 tok/s 的 thinking 速度，9B 级别里已经很不错
- 关掉 thinking 后 115 tok/s，日常使用没有"慢"的感觉
- 5.2GB 的模型大小，8GB 显卡就能跑
- 接 OpenClaw 的链路已经打通，实际体验流畅
当然，9B 也有局限：ToolCall 不如 27B，复杂推理不如 27B。如果你的显卡够大（24GB），27B 依然是更好的选择。
但如果你的显卡是 8GB 或 12GB——别等了，9B V2 已经够用了。
如果对 AI 个人提效，以及副业感兴趣，而不只是围观，也推荐加入 IDO 老徐 的知识星球：AI 落地实战 · DeepSeek · OpenClaw。
里面会持续分享 OpenClaw 相关内容、AI 工作流搭建、商业化落地和各种实战避坑经验。
我是寂寞的熊猫，程序员，职场努力升职，业余时间探索副业，寻找第二曲线，聚焦 AI 绘画、AI 编程、智能体方向副业探索与变现。