Qwen3.6-35B-A3B-Claude-4.7-Opus-Reasoning-Distilled:革命性推理模型蒸馏技术深度解析
Qwen3.6-35B-A3B-Claude-4.7-Opus-Reasoning-Distilled:革命性推理模型蒸馏技术深度解析
Qwen3.6-35B-A3B-Claude-4.7-Opus-Reasoning-Distilled是一款基于Qwen3.6-35B-A3B模型开发的推理蒸馏变体,它被训练来模仿Anthropic的前沿推理模型Claude Opus 4.7的思维链风格。该模型旨在将Claude级别的推理行为移植到一个具有宽松许可的混合专家模型中,使个人能够实际运行。
为什么选择这款推理模型?
Claude风格推理,开放权重 🚀
Claude Opus 4.7是目前可用的最强推理模型之一,但只能通过专有API使用。而此模型在约8k高质量的Opus 4.7推理轨迹上进行了微调,教导基础模型在回答之前进行思考——通过明确的</think>…</think>块,采用Claude的结构和节奏。
稀疏激活,密集知识 🧠
基础模型是一个35B参数的MoE(混合专家模型),具有256个专家,8个路由专家+1个共享专家,每个令牌只有约3B参数处于活动状态。你可以以小型密集模型的推理成本获得35B模型的能力。全质量bf16推理可在单个80GB A100或H100上运行。
支持长时间思考 📝
64k令牌上下文。该模型通常会在难题上发出5–30k令牌的</think>推理,然后才给出最终答案——这正是推理模型的意义所在,也是为什么这个模型专门与同样明确推理的上游教师一起进行端到端训练。
可扩展的基础模型 🔧
LoRA适配器也单独发布(…-adapter),因此你可以将蒸馏应用于同一基础的其他检查点,或堆叠进一步的微调。
模型的预期用途
该模型专为复杂推理任务构建:研究生级别的STEM、竞赛数学(AIME/MATH)、带有明确步骤的代码推理、多步骤逻辑谜题以及需要明确<RichMediaReference>帮助确保正确性的智能体规划。
对于短轮对话延迟敏感的工作负载,思考预算可能很大;如果在生产中只需要最终答案,可以限制max_new_tokens或后处理以去除<RichMediaReference>…superscript:块。
如何开始使用该推理模型?
基本使用方法
以下是使用transformers库加载和使用模型的Python代码示例:
from transformers import AutoModelForCausalLM, AutoTokenizer
import torch
repo = "lordx64/Qwen3.6-35B-A3B-Claude-4.7-Opus-Reasoning-Distilled"
tok = AutoTokenizer.from_pretrained(repo)
model = AutoModelForCausalLM.from_pretrained(
repo, torch_dtype=torch.bfloat16, device_map="auto", trust_remote_code=True,
)
messages = [{"role": "user", "content": "How many positive integers less than 1000 have digits that sum to 20?"}]
inputs = tok.apply_chat_template(messages, add_generation_prompt=True, return_tensors="pt").to(model.device)
out = model.generate(inputs, max_new_tokens=32768, do_sample=False)
print(tok.decode(out[0][inputs.shape[-1]:], skip_special_tokens=True))
推荐后端:vLLM服务
MoE路由+KV缓存从连续批处理中显著受益,推荐使用vLLM进行服务:
vllm serve lordx64/Qwen3.6-35B-A3B-Claude-4.7-Opus-Reasoning-Distilled \
--dtype bfloat16 --max-model-len 65536 --gpu-memory-utilization 0.9
GGUF格式(LM Studio / llama.cpp)
适用于llama.cpp和LM Studio的量化GGUF权重可用:
- IQ4_XS(18.9 GB) — 最小,LM Studio的默认选择
- Q5_K_M(~25 GB) — 平衡质量/大小
- Q8_0(~35 GB) — 近乎无损
一旦HF索引了GGUF仓库(通常在发布后一小时内),可以在LM Studio的模型浏览器中搜索lordx64/Qwen3.6-35B-A3B-Claude-4.7-Opus-Reasoning-Distilled。
模型训练技术细节
| 基础模型 | Qwen/Qwen3.6-35B-A3B(通过unsloth/Qwen3.6-35B-A3B加载以加快微调) |
| 教师模型 | Claude Opus 4.7(Anthropic) |
| 训练数据集 | lordx64/reasoning-distill-opus-4-7-max-sft — 来自Claude Opus 4.7的推理轨迹重新格式化为SFT对话 |
| 源数据集 | lordx64/reasoning-distill-claude-opus-4-7-max — 原始教师轨迹(SFT格式化前) |
| 数据集大小 | ~7,800个完整对话,训练助手端包括<RichMediaReference>…superscript: |
| 方法 | 使用Unsloth + TRL SFTTrainer + train_on_responses_only进行SFT(仅对助手令牌进行损失计算) |
| LoRA配置 | r=16, alpha=16, dropout=0.0, targets=["q_proj","k_proj","v_proj","o_proj"](仅注意力) |
| 超参数 | lr=2e-5,余弦调度,warmup_ratio=0.03,weight_decay=0.01,优化器adamw_8bit |
| 批次 | per_device=1, grad_accum=16, effective=16,2个epoch = 978步 |
| 序列 | 训练期间4096令牌(推理时64k可用 — 基础模型原生支持) |
| 精度 | 在1× H200 141GB上使用bf16(HF推理端点,自定义容器) |
| 可训练参数 | 35.1B中的3.44M参数(0.01%) |
为什么在MoE上使用仅注意力LoRA?
最初的计划是包括MoE专家FFN(gate_proj/up_proj/down_proj)的完整LoRA。在这个项目过程中,我提交并上游修复了unsloth-zoo的MoE+LoRA grouped-mm路径中的形状不匹配问题——unslothai/unsloth-zoo#601——如果没有这个修复,专家LoRA前向传播会在Qwen3.6的256专家布局上崩溃。即使有了这个修复,单GPU内存使得专家LoRA在这次运行中不切实际。无论如何,仅注意力捕获了大部分风格蒸馏的信号(这是这个模型的重点),同时保持专家FFN的学习知识完好无损——如果仅风格信号不够,多GPU上的专家LoRA v2训练运行是自然的下一步。
模型性能评估
通过lm-evaluation-harness(v0.4.9)使用vLLM后端在64k上下文中以bf16精度进行评估。自定义评估路径在过滤管道之前从生成中去除<RichMediaReference>…superscript:,使用每个任务的常规fewshot计数,并以fewshot_as_multiturn=True运行,因此few-shot示例是适当的聊天轮次而不是连接的提示文本。原始结果JSON是公开的:lordx64/qwen3-6-distill-evals。
| 基准 | 设置 | 分数 |
|---|---|---|
| GSM8K CoT | 8-shot多轮,限制300 | 84.3%(灵活提取)/ 76.7%(严格匹配) |
| MMLU-Pro | 5-shot多轮,限制500 | 74.9% |
| AIME 2024 | 0-shot,完整(30) | 提取修复进行中——模型生成答案但格式不被AIME提取器识别(\boxed{} vs 普通散文) |
| AIME 2025 | 0-shot,完整(30) | 同上——待处理 |
| GPQA Diamond | 0-shot CoT,完整(198) | 同上——待处理 |
| MATH-500 | 0-shot,限制100 | 重新运行待处理(第一次运行中缺少sympy/math_verify依赖) |
MMLU-Pro科目细分
标准推理模型配置文件:STEM方面表现强,法律/工程方面较弱。所有科目均以限制500、5-shot多轮进行评估。
| 科目 | 准确率 | 科目 | 准确率 |
|---|---|---|---|
| 生物学 | 86.0% | 化学 | 78.8% |
| 心理学 | 83.4% | 健康 | 73.8% |
| 数学 | 83.6% | 商业 | 74.4% |
| 经济学 | 83.0% | 其他 | 72.6% |
| 物理学 | 81.0% | 哲学 | 71.3% |
| 计算机科学 | 79.0% | 历史 | 70.9% |
| 工程学 | 54.8% | ||
| 法律 | 55.6% |
完整的每个任务JSON与stderr、过滤配置和时间安排位于评估数据集中。在诊断性重新运行确定为什么AIME/GPQA提取在生成输出上返回不匹配后,其余任务将添加到此表中。
模型局限性
-
推理≠知识。蒸馏传递的是如何推理,而不是新事实。任何基础Qwen3.6-35B-A3B还不知道的东西,这个模型仍然不知道。
-
仅注意力LoRA。专家FFN与基础模型保持不变——Claude和Qwen3.6在事实先验上存在分歧的领域可能会看到不均衡的改进。
-
长生成。该模型确实会在难题上使用数万个令牌。相应地预算你的
max_new_tokens,并在推理时提供max_model_len ≥ 32k。 -
蒸馏来源。训练数据是通过API使用Anthropic的Claude Opus 4.7生成的。下游用户应确认其特定用例是否符合Anthropic的使用政策。
如何获取模型
要获取该模型,请克隆仓库:
git clone https://gitcode.com/hf_mirrors/lordx64/Qwen3.6-35B-A3B-Claude-4.7-Opus-Reasoning-Distilled
引用
如果你使用此模型,请引用基础模型和蒸馏版本:
@misc{qwen36_a3b_2026,
title = {Qwen3.6-35B-A3B},
author = {Qwen Team},
year = {2026},
howpublished = {\url{https://huggingface.co/Qwen/Qwen3.6-35B-A3B}},
}
@misc{lordx64_qwen36_distill_2026,
title = {Qwen3.6-35B-A3B distilled from Claude Opus 4.7 reasoning},
author = {lordx64},
year = {2026},
howpublished = {\url{https://huggingface.co/lordx64/Qwen3.6-35B-A3B-Claude-4.7-Opus-Reasoning-Distilled}},
}
致谢
-
Unsloth — 大型MoE LoRA的2×更快训练;我们遇到并修复的错误在他们的
unsloth-zoo补丁中(感谢PR #601的快速审查)。 -
Anthropic — 提供教师模型。
-
Qwen团队 — 发布具有宽松Apache-2.0许可证的Qwen3.6,使此类工作成为可能。
-
lm-evaluation-harness(EleutherAI) — 评估方法。
更多推荐




所有评论(0)