可用于解决研究生级STEM、竞赛数学、代码推理等复杂问题，通过模仿Claude Opus 4.7的思维链风格，在开源混合专家模型中实现Claude级推理能力，支持64k上下文，单80GB GPU即可运行。【此简介由AI生成】
license: apache-2.0 language:
- en library_name: transformers pipeline_tag: text-generation base_model: Qwen/Qwen3.6-35B-A3B datasets:
- lordx64/reasoning-distill-opus-4-7-max-sft tags:
- text-generation
- reasoning
- distillation
- chain-of-thought
- qwen
- qwen3.6
- mixture-of-experts
- moe
- lora
- unsloth model-index:
- name: Qwen3.6-35B-A3B-Claude-4.7-Opus-Reasoning-Distilled results: []
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>…</RichMediaReference>块——采用Claude的结构和节奏。 - 稀疏激活，密集知识。 基础模型是一个拥有350亿参数的MoE模型，具有256个专家，8个路由专家+1个共享专家，每个token仅激活约30亿参数。您可以以小型密集模型的推理成本获得350亿模型的能力。全质量bf16推理可在单个80GB A100或H100上运行。
- 支持深度思考。 64k token上下文。该模型在解决难题时，通常会在给出最终答案前生成5–30k token的
</think>推理内容——这正是推理模型的核心价值，也是为什么本模型专门使用同样会进行显式推理的上游教师模型进行端到端训练的原因。 - 可扩展的纯净基础。 LoRA适配器也已单独发布（
…-adapter），因此您可以将此蒸馏应用于同一基础模型的其他检查点，或叠加进一步的微调。
预期用途
专为复杂推理任务构建：研究生级STEM、竞赛数学（AIME / MATH）、带显式步骤的代码推理、多步骤逻辑谜题，以及显式<RichMediaReference>有助于提高正确性的智能体规划。
对于短轮次对话等对延迟敏感的工作负载，思考过程可能占用较多资源；如果在生产环境中只需要最终答案，可以限制max_new_tokens或通过后处理去除superscript:…superscript:块。
如何使用
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 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 个完整对话，训练的助手端包含 </think>…</think> |
| 方法 | 使用 Unsloth + TRL SFTTrainer + train_on_responses_only 进行 SFT（仅对助手 tokens 计算损失） |
| 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 tokens（推理时可用 64k——基础模型原生支持） |
| 精度 | 在 1× H200 141GB 上使用 bf16（HF 推理端点，自定义容器） |
| 可训练参数 | 351 亿参数中的 344 万（0.01%） |
为何在MoE模型上仅使用注意力机制LoRA
最初的计划是进行全LoRA训练，包括MoE专家FFN（gate_proj/up_proj/down_proj）。在项目过程中，我发现并向上游提交了unsloth-zoo的MoE+LoRA分组矩阵乘法路径中的形状不匹配修复——unslothai/unsloth-zoo#601——若没有此修复，专家LoRA前向传播会在Qwen3.6的256专家布局上崩溃。即便有了该修复，单GPU内存也使得本实验中无法实际应用专家LoRA。反正仅注意力机制就已捕获了“风格”蒸馏的大部分信号（这正是本模型的核心目标），同时保留了专家FFN已习得的知识——如果仅风格信号不够，那么在多GPU上进行包含专家LoRA的v2版本训练将是很自然的下一步。
评估
通过lm-evaluation-harness（v0.4.9）进行评估，后端采用vLLM，上下文长度64k，精度为bf16。自定义评估路径在过滤流水线前会从生成内容中去除</think>…</RichMediaReference>，使用每个任务的常规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{}与纯文本 prose） |
| 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% |
包含stderr、过滤配置和时间的完整每个任务JSON位于评估数据集中。在诊断性重新运行确定AIME/GPQA提取为何对生成输出返回无匹配后，其余任务将添加到此表中。
局限性
- 推理≠知识。蒸馏传递的是“如何推理”，而非新事实。基础模型Qwen3.6-35B-A3B原本不知道的内容，本模型同样不知道。
- 仅注意力LoRA。专家FFN层完全保留基础模型的设置——在Claude与Qwen3.6的事实先验存在差异的领域，可能会出现改进效果不均衡的情况。
- 长文本生成。面对复杂问题时，模型确实会使用数万个token进行推理。请相应地设置
max_new_tokens参数，并在推理时确保max_model_len ≥ 32k。 - 蒸馏来源。训练数据通过API调用Anthropic的Claude Opus 4.7生成。下游用户应根据其具体使用场景，确认是否符合Anthropic的使用政策。
引用
如果您使用本模型，请同时引用基础模型和蒸馏工作：
@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倍速训练；我们遇到并修复的bug存在于其
unsloth-zoo补丁中（感谢对PR #601的快速审核）。 - Anthropic — 提供教师模型。
- Qwen团队 — 以宽松的Apache-2.0许可证发布Qwen3.6，为此类研究工作提供了可能。
- lm-evaluation-harness（EleutherAI） — 提供评估方法。