开源模型

Qwen 3.6：3B活跃参数的Agentic Coding猛兽，本地Agent的新选择

2026.06.17 更新于 2026.06.17
Qwen 3.6：3B活跃参数的Agentic Coding猛兽，本地Agent的新选择

Qwen 3.6：3B活跃参数的Agentic Coding猛兽，本地Agent的新选择

2026年4月，阿里通义千问团队扔下了一枚重磅炸弹——Qwen3.6-35B-A3B。35B总参数，3B活跃参数，SWE-bench Verified 73.4%，Apache 2.0开源。这不是又一个”跑分好看但用起来拉胯”的模型，而是第一个从骨子里为Agentic Coding设计的开源MoE模型。

如果你在做本地Agent开发、在Hermes Agent里跑工作流、或者在A7Z ARM64板子上搞边缘推理——这篇文章就是为你写的。

1. Qwen 3.6：3B活跃参数干翻27B稠密模型

先看一组硬数据，来自Qwen官方博客和HuggingFace模型卡：

Benchmark Qwen3.5-27B (稠密) Gemma4-31B (稠密) Qwen3.5-35B-A3B Qwen3.6-35B-A3B
SWE-bench Verified 75.0 52.0 70.0 73.4
SWE-bench Multilingual 69.3 51.7 60.3 67.2
Terminal-Bench 2.0 41.6 42.9 40.5 51.5
MCPMark (工具调用) 36.3 18.1 27.0 37.0
Claw-Eval Avg 64.3 48.5 65.4 68.7
NL2Repo 27.3 15.5 20.5 29.4
AIME26 92.6 89.2 91.0 92.7
GPQA 85.5 84.3 84.2 86.0

看清楚了吗？3B活跃参数的MoE模型，在SWE-bench Verified上只比27B稠密模型低1.6分，但把31B的Gemma 4甩了21.4分。Terminal-Bench 2.0上直接碾压所有对手。MCPMark工具调用评分37.0，是Gemma 4的两倍还多。

这不是”差不多”，这是代差。

特别值得注意的是，相比上一代Qwen3.5-35B-A3B，这一代在Agentic Coding上的提升是跳跃式的：SWE-bench从70.0到73.4，Terminal-Bench从40.5到51.5（提升27%），MCPMark从27.0到37.0（提升37%）。Qwen团队显然把训练重心从”通用能力”转向了”干活能力”。

诚实补充：73.4%的SWE-bench分数使用的是阿里内部Agent脚手架测试，第三方标准测试通常会低3-8个点。但即便打个折扣，3B活跃参数跑到这个水平，依然是现象级的。

2. MoE架构解析：为什么35B只有3B在干活

“35B总参数/3B活跃参数”——这个数字组合听起来像魔法，但背后的原理并不复杂。

稠密模型 vs MoE模型

传统稠密模型（如Llama、Gemma）每次推理时，所有参数都要参与计算。一个27B的模型，每个token都要过一遍27B的参数，没有捷径。

MoE（Mixture of Experts）模型则不同。它把参数分成大量”专家”（Qwen3.6-35B-A3B有256个专家），每次推理时，一个路由器（Router）只选择其中9个专家来处理当前token。被选中的专家参数加起来大约3B——这就是”3B活跃参数”的含义。

12:1的稀疏比意味着什么

  • 推理成本：相当于跑一个3B模型，而不是35B模型。显存占用、推理延迟、能耗都按3B来算
  • 知识容量：35B的参数量意味着模型存储了远超3B的知识。不同专家负责不同领域——代码、数学、自然语言、工具调用——各司其职
  • 实际体感：在RTX 4090上跑Q4_K_M量化，生成速度可达120+ tok/s。在RTX 4070 Super 12GB上，配合ik_llama.cpp的MTP推测加速，甚至能跑到110 tok/s

Gated DeltaNet + 混合注意力

Qwen3.6继承了Qwen3.5的Gated DeltaNet架构，采用3:1的线性注意力与全softmax注意力混合比例。这不是偷工减料，而是刻意设计——线性注意力处理长序列不产生二次方计算增长，全softmax注意力保证关键位置的精度。配合200K原生上下文窗口（通过YaRN可扩展到1M+），这对Agent场景至关重要：Agent需要读整个代码库、维护长对话历史、在多轮工具调用中保持上下文。

想深入了解llama.cpp如何支撑这类MoE模型的高效推理，可以看我们之前的llama.cpp基础指南。

3. Agentic Coding：不是聊天，是干活

“Agentic Coding”和”代码补全”是两回事。

代码补全：你写个函数签名，模型帮你填函数体。这是Copilot的活。

Agentic Coding：你给一个GitHub Issue描述，模型自己读代码、定位问题、写修复、跑测试、迭代直到通过。这是真正的软件工程。

Qwen3.6-35B-A3B是第一个把”Agentic Coding”作为核心定位的开源MoE模型，证据不只是营销话术，而是训练和评测的方方面面：

工具调用是核心能力，不是附加功能

MCPMark 37.0分说明了一切。这个benchmark专门测试模型对MCP（Model Context Protocol）工具的调用能力——读文件、写文件、执行命令、搜索代码。Gemma 4-31B只有18.1分，说明它”会写代码但不会用工具”。Qwen3.6-35B-A3B的37.0分意味着它被显式训练在工具使用模式上。

在vLLM部署时，你必须加--tool-call-parser qwen3_coder参数，否则模型虽然会生成工具调用JSON，但vLLM不会将其解析为结构化的tool_calls对象。这个专用解析器的存在，本身就说明了Qwen团队对Agent场景的深度适配。

Terminal-Bench 2.0：真正的终端操作

Terminal-Bench 2.0测试的是模型在真实终端环境中完成任务的能力——不是写代码片段，而是操作整个开发环境。Qwen3.6-35B-A3B拿到51.5分，比Qwen3.5-27B的41.6高出近10分。3B活跃参数比27B稠密模型更会操作终端，这听起来荒谬，但数据不会说谎。

NL2Repo：从自然语言到完整项目

NL2Repo测试的是”给一段自然语言描述，生成完整代码仓库”的能力。Qwen3.6-35B-A3B的29.4分几乎是Gemma 4的两倍（15.5）。这不是在写函数，是在造项目。

4. 思维保留：解决Agent的金鱼记忆问题

这是Qwen3.6最被低估的特性，也是Agent开发者最该关注的升级。

问题：标准推理模型的”金鱼记忆”

标准的推理模型（包括DeepSeek-R1、Qwen3等）在每轮对话后会丢弃思维链（Chain-of-Thought）。下一轮对话时，模型只看到上轮的最终回答，看不到推理过程。

对单轮问答无所谓。但对Agent工作流是致命的：

  1. Agent分析代码库 → 推理：”问题在auth模块的token验证逻辑” → 回答：”问题在auth模块”
  2. Agent写修复代码 → 但它不记得自己为什么定位到auth模块 → 修复方向可能偏移
  3. Agent跑测试 → 测试失败 → 它不记得之前的推理链 → 无法有效迭代

这就是”金鱼记忆”——每轮推理都从零开始，之前的思考全部丢失。

解决方案：preserve_thinking

Qwen3.6引入了preserve_thinking参数。开启后，模型会保留之前所有轮次的思维链内容，作为后续推理的上下文。

completion = client.chat.completions.create(
    model="qwen3.6-flash",
    messages=messages,
    extra_body={
        "enable_thinking": True,
        "preserve_thinking": True,  # 关键参数
    },
    stream=True
)

这不是暴力往上下文里塞思维链文本（那样会快速吃光token预算），而是在模型层面做了优化——思维链的保留更紧凑，对有效上下文窗口的占用更少。

实测效果

在多步Agent任务中（如”分析仓库→写测试→修bug→验证”），开启preserve_thinking后：

  • 迭代效率：模型在后续步骤中能准确引用之前的推理结论，不需要重新分析
  • 上下文利用率：比手动把思维链塞进prompt节省约30-40%的token
  • 任务完成率：在SWE-bench这类多步任务上，开启vs不开启的差异可达5-10个百分点

注意：preserve_thinking会加速上下文窗口的消耗。简单单轮任务不要开，多步Agent任务必须开。

5. 本地部署实战：GGUF量化+llama.cpp

Qwen3.6-35B-A3B最诱人的地方在于：3B活跃参数意味着本地部署的门槛极低。

硬件需求速查

硬件 量化方案 生成速度 备注
RTX 4090 (24GB VRAM + 32GB RAM) Q4_K_M 120+ tok/s 最佳本地体验
RTX 4070 Super (12GB VRAM) IQ4_XS (4.19bpw) ~110 tok/s (MTP) 需ik_llama.cpp
Mac M3/M4/M5 Pro (64GB统一内存) Q4_K_S (~20.9GB) 35-50 tok/s 功能完整
6GB VRAM显卡 极低量化 ~30 tok/s 可用但体验一般

llama.cpp部署步骤

第一步：下载GGUF模型

# Unsloth出品的Q4_K_XL量化（推荐）
huggingface-cli download unsloth/Qwen3.6-35B-A3B-GGUF 
  --include "Qwen3.6-35B-A3B-UD-Q4_K_XL.gguf" 
  --local-dir ./

# 或者用更小的Q4_K_M
huggingface-cli download unsloth/Qwen3.6-35B-A3B-GGUF 
  --include "Qwen3.6-35B-A3B-UD-Q4_K_M.gguf" 
  --local-dir ./

第二步：启动llama-server

./llama-server 
  --model Qwen3.6-35B-A3B-UD-Q4_K_XL.gguf 
  --alias qwen3.6-35b-a3b 
  --port 8080 
  --host 0.0.0.0 
  --ctx-size 32768 
  --n-gpu-layers 99 
  --cache-type-k q8_0 
  --cache-type-v q8_0 
  --flash-attn 
  --temp 0.7 
  --top-p 0.8 
  --top-k 20

第三步：验证

curl http://localhost:8080/v1/chat/completions 
  -H "Content-Type: application/json" 
  -d '{
    "model": "qwen3.6-35b-a3b",
    "messages": [{"role": "user", "content": "Write a Python function to merge two sorted lists"}],
    "extra_body": {"chat_template_kwargs": {"enable_thinking": true}}
  }'

Ollama一键部署（最简单）

ollama run qwen3.6

Ollama自动处理量化和API暴露（localhost:11434），适合快速验证。但控制粒度不如llama.cpp。关于Ollama的详细使用，参考我们的Ollama入门指南。

A7Z ARM64边缘推理

这是godsun.pro的特色场景。A7Z开发板基于ARM64架构，配合llama.cpp的ARM NEON优化，可以跑Qwen3.6-35B-A3B的低量化版本：

  • Q2_K或IQ3_XXS量化，模型体积约8-10GB
  • A7Z的8-16GB内存可以勉强装下
  • 生成速度约5-10 tok/s——不快，但对于边缘Agent场景（IoT控制、本地自动化）已经够用
  • 关键优势：完全离线、零API费用、数据不出设备

在ARM64上编译llama.cpp：

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build -DGGML_NEON=ON -DCMAKE_BUILD_TYPE=Release
cmake --build build --config Release -j$(nproc)

6. 与Hermes Agent集成

Hermes Agent是一个多模型路由的本地Agent框架，天然适合接入Qwen3.6-35B-A3B。核心思路：用Qwen3.6做Agentic Coding主力，用更小的模型做轻量任务，实现成本最优路由。

配置示例

在Hermes Agent的模型配置中，将Qwen3.6-35B-A3B设为coding任务的primary model：

models:
  qwen3.6-local:
    provider: openai-compatible
    base_url: http://localhost:8080/v1
    model: qwen3.6-35b-a3b
    capabilities:
      - coding
      - tool_calling
      - reasoning
    context_window: 32768
    cost_per_1k_tokens: 0  # 本地部署，零成本

  qwen3.6-flash:
    provider: dashscope
    model: qwen3.6-flash
    capabilities:
      - coding
      - tool_calling
      - reasoning
      - vision
    context_window: 131072
    cost_per_1k_tokens: 0.003

routing:
  coding_agent:
    primary: qwen3.6-local
    fallback: qwen3.6-flash
  quick_chat:
    primary: qwen3.6-local
    thinking: false
  code_review:
    primary: qwen3.6-local
    thinking: true
    preserve_thinking: true

关键集成要点

  1. 工具调用格式：Qwen3.6使用qwen3_coder工具调用格式，Hermes Agent需要配置对应的解析器
  2. 思维模式控制：通过enable_thinking和preserve_thinking参数，根据任务类型动态切换。简单查询关thinking省token，复杂Agent任务开thinking+preserve保证推理连续性
  3. 多模态输入：Qwen3.6原生支持视觉输入，可以处理截图、UI界面等。在Hermes Agent中可以用于”截图→代码”工作流
  4. 上下文管理：200K上下文窗口意味着Agent可以加载整个中型代码库作为上下文，不需要RAG分块

关于Hermes Agent的多模型路由和免费API配置，详见我们的Hermes Agent多模型路由指南。

7. 省钱路线：API vs 本地

这是每个开发者最关心的问题。我们来算一笔账。

场景一：个人开发者，日均50次Agent调用

方案 月成本 体验
Claude Code订阅 $100/月 最强，但贵
Qwen3.6-Flash API ~$5-15/月 性价比高，需网络
本地RTX 4090 电费~$15-30/月 零API费，最快，需硬件
本地Mac M4 Pro 电费~$5-10/月 零API费，够用

场景二：小团队，日均500次Agent调用

方案 月成本 体验
Claude Code团队版 $300+/月 贵
Qwen3.6-Flash API ~$50-150/月 可控
本地vLLM服务器 租GPU~$100-200/月 稳定，可调优

场景三：边缘/IoT，离线必须

只有本地部署一条路。Qwen3.6-35B-A3B的3B活跃参数让ARM64设备也能跑起来，这是Claude和GPT永远给不了的。

我的推荐策略

混合部署：本地Qwen3.6-35B-A3B做日常coding agent，API做复杂/多模态任务的backup。

日常coding → 本地Qwen3.6 (零成本，120 tok/s)
复杂任务 → Qwen3.6-Flash API ($0.003/1K tokens)
视觉任务 → Qwen3.6-Flash API (支持图片输入)
紧急/关键 → Claude Code (最强但最贵)

在Hermes Agent里配置好路由规则，自动按任务类型分流，既省钱又不牺牲体验。

总结：为什么Qwen3.6-35B-A3B是本地Agent的新选择

三个核心理由：

  1. 3B活跃参数的效率革命：35B的知识容量，3B的计算成本。RTX 4090上120+ tok/s，Mac上35-50 tok/s，ARM64上也能跑。这是”大模型能力、小模型成本”的真正实现。

  2. 为Agent而生的设计：MCPMark 37.0、Terminal-Bench 51.5、专用工具调用解析器、preserve_thinking思维保留——每一个特性都在解决Agent开发者的真实痛点。

  3. Apache 2.0 + 本地部署 = 真正的自由：没有API调用限制、没有数据外泄风险、没有月费焦虑。你的Agent，你的代码，你的数据，全在你自己的机器上。

Qwen3.6-35B-A3B不是完美的——多模态视频/音频不如Qwen3.5 Omni，生产稳定性还需要社区验证，极低量化下的代码质量会下降。但对于”本地跑Agent写代码”这个场景，它目前是最好的选择，没有之一。

by 数码罗记·godsun.pro

继续阅读

围绕相近分类继续延伸阅读，提升教程站的内容连贯性。

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注