这两天看到一个基于opus和fable蒸馏的模型是基于Qwen模型进行的今天正好空闲就想着研究看看。项目地址https://huggingface.co/lordx64/Qwable-v1目录第一章Qwable-v1是什么——一句话说清楚第二章技术背景——理解Qwable-v1需要的基础知识第三章模型架构——Qwable-v1的身体第四章链式蒸馏训练路线——Qwable-v1的成长过程第五章训练细节——从超参数到硬件配置第六章数据集溯源——训练数据从哪来第七章使用方法——如何部署和调用Qwable-v1第八章工具调用格式——智能体能力的技术细节第九章模型局限性——诚实的认知第十章技术启发——从Qwable-v1学到什么第一章Qwable-v1是什么——一句话说清楚1.1 一句话概括Qwable-v1 Qwen3.6基础模型 Claude Opus 4.7推理能力蒸馏 Claude Fable-5智能体能力蒸馏 它是一个35B参数的MoE模型实际激活3B参数 能像Claude Code一样做智能体编程读文件、写代码、执行命令 同时保留了Opus 4.7级别的推理能力 而且完全开源AGPL-3.0协议。1.2 为什么叫QwableQwable Qwen Fable Qwen → 阿里巴巴的开源大模型家族基座模型 Fable → Anthropic的Claude Fable-5智能体能力的来源 名字本身就揭示了它的血统1.3 Qwable-v1能做什么能力1推理能力继承自Opus 4.7蒸馏 - 数学推理 - 科学问答 - 通用知识问答 - 代码理解 能力2智能体编程继承自Fable-5蒸馏 - 读取文件内容 - 编辑和写入文件 - 执行Shell命令 - 像Claude Code一样做自动化编程 能力3链式思考Chain-of-Thought - 在回答前进行显式的 think.../think 推理 - 提高回答的准确性和可解释性1.4 关键数据一览┌─────────────────────────────────────────────────┐ │ Qwable-v1 关键参数 │ ├──────────────────┬──────────────────────────────┤ │ 总参数量 │ 35B350亿 │ │ 激活参数量 │ 3B30亿MoE架构 │ │ 模型架构 │ Qwen3.6-35B-A3B (MoE) │ │ 精度 │ bf16约70GB │ │ 训练硬件 │ 1× NVIDIA H200 (141GB) │ │ 训练时长 │ 14.1小时 │ │ 训练成本 │ 约70美元 │ │ 训练数据量 │ 4,659条约1220万token │ │ 训练方法 │ LoRA SFT (r16) │ │ 最终损失 │ 0.804 │ │ 许可协议 │ AGPL-3.0 │ │ 量化版本 │ IQ4_XS(18GB)/Q5_K_M(25GB)/Q8_0(37GB) │ └──────────────────┴──────────────────────────────┘第二章技术背景——理解Qwable-v1需要的基础知识2.1 什么是模型蒸馏模型蒸馏(Model Distillation)的核心思想 大模型教师的输出 → 用来训练 → 小模型学生 学生模型学习的不是正确答案而是教师模型的思维方式 类比理解 教师 经验丰富的老工程师 学生 新入职的工程师 蒸馏 新人学习老人的解题思路而不是只背答案 最终目标学生用更少的资源达到接近教师的水平蒸馏的几种类型类型1输出蒸馏Output Distillation 学习教师模型的最终输出 最简单的蒸馏方式 类型2特征蒸馏Feature Distillation 学习教师模型的中间层表示 需要访问教师模型的内部 类型3链式推理蒸馏Chain-of-Thought Distillation 学习教师模型的推理过程而不仅是答案 Qwable-v1使用的就是这种方式 学生不仅学答案是什么还学怎么思考的2.2 什么是SFT监督微调SFT Supervised Fine-Tuning 监督微调 核心流程 1. 准备训练数据(输入, 期望输出) 对 2. 让模型生成输出 3. 计算与期望输出的差异损失 4. 反向传播更新模型参数 Qwable-v1做了两轮SFT 第1轮用Opus 4.7的推理数据做SFT → 学会推理 第2轮用Fable-5的工具调用数据做SFT → 学会做智能体2.3 什么是LoRALoRA Low-Rank Adaptation 低秩自适应 核心思想 不修改原始大模型的全部参数 只在旁边加一个小的适配器 只训练适配器的参数 原始权重W冻结不动 LoRA适配器 A × B可训练参数量很小 最终权重 W A × B Qwable-v1的LoRA配置 - r16秩为16 - alpha16缩放因子 - 只对注意力层做LoRAq_proj, k_proj, v_proj, o_proj - dropout0.02.4 什么是MoE混合专家MoE Mixture of Experts 混合专家模型 核心思想 模型内部有多个专家子网络 每次输入只激活其中少数几个专家 总参数量大但实际计算量小 Qwen3.6-35B-A3B的含义 - 35B总参数量350亿 - A3B每次推理只激活3B参数30亿 - 意味着有35B的知识容量但推理成本只有3B模型的水平 类比理解 全科医院有100个医生35B参数 但每次看病只需要看1个科室3B激活参数 医院总人数多但每次就诊只用到少数人2.5 什么是智能体(Agent)在大模型语境下智能体 能自主使用工具完成任务的AI 传统大模型 用户提问 → 模型回答 → 结束 智能体模式 用户提问 → 模型思考 → 调用工具 → 观察结果 → 继续思考 → 调用工具 → ... → 最终回答 Qwable-v1支持的工具调用 - Read读取文件内容 - Edit/Write编辑/写入文件 - Bash执行Shell命令 - WebFetch获取网页内容 - 以及其他自定义工具2.6 关键模型介绍Qwen3.6-35B-A3B基座模型阿里巴巴Qwen团队发布的开源大模型 - 35B总参数3B激活参数MoE架构 - Apache 2.0开源协议 - 优秀的中英文能力 - 作为Qwable-v1的身体Claude Opus 4.7推理教师Anthropic的旗舰推理模型 - 极强的推理能力 - 数学、科学、编程表现出色 - Qwable-v1通过蒸馏继承了它的推理能力 - 注意Opus 4.7是闭源模型不能直接使用 - 但通过蒸馏其推理能力被转移到了开源的Qwable-v1中Claude Fable-5智能体教师Anthropic的智能体工具使用模型 - 专门用于代码编辑、文件操作、Shell执行等智能体任务 - 使用XML格式的工具调用 - 2026年6月10日-22日期间短暂可用 - 之后被Anthropic因美国出口管制而全球暂停 - Qwable-v1通过蒸馏继承了它的工具使用能力第三章模型架构——Qwable-v1的身体3.1 整体架构Qwable-v1的模型架构 Qwen3.6-35B-A3B的架构 ┌─────────────────────────────────────────────────┐ │ Qwable-v1 模型架构 │ │ │ │ 输入 Token │ │ ↓ │ │ ┌─────────────────────────────────────────┐ │ │ │ Embedding Layer │ │ │ └──────────────────┬──────────────────────┘ │ │ ↓ │ │ ┌─────────────────────────────────────────┐ │ │ │ Transformer Block × 28层 │ │ │ │ │ │ │ │ ┌──────────────────────────────────┐ │ │ │ │ │ Self-Attention (GatedDeltaNet) │ │ │ │ │ │ ├── q_proj (LoRA可训练) │ │ │ │ │ │ ├── k_proj (LoRA可训练) │ │ │ │ │ │ ├── v_proj (LoRA可训练) │ │ │ │ │ │ └── o_proj (LoRA可训练) │ │ │ │ │ └──────────────────────────────────┘ │ │ │ │ ┌──────────────────────────────────┐ │ │ │ │ │ MoE Feed-Forward Network │ │ │ │ │ │ ├── Router (选择专家) │ │ │ │ │ │ ├── Expert 1 (冻结) │ │ │ │ │ │ ├── Expert 2 (冻结) │ │ │ │ │ │ ├── ... (共多个专家) │ │ │ │ │ │ └── 每次只激活少数专家 │ │ │ │ │ └──────────────────────────────────┘ │ │ │ └─────────────────────────────────────────┘ │ │ ↓ │ │ ┌─────────────────────────────────────────┐ │ │ │ LM Head (输出层) │ │ │ └──────────────────┬──────────────────────┘ │ │ ↓ │ │ 输出 Token下一个词 │ └─────────────────────────────────────────────────┘3.2 MoE机制详解在Qwable-v1的每一层中FFN部分使用MoE架构 输入 → Router网络 → 选择Top-K个专家 → 只计算被选中的专家 → 合并输出 Router的工作方式 1. 输入一个token的隐藏状态 2. Router计算每个专家的匹配分数 3. 选择分数最高的K个专家 4. 只在这K个专家上做前向计算 5. 按分数加权合并专家输出 35B总参数 vs 3B激活参数的含义 假设有64个专家每次激活Top-2 每个专家约0.5B参数 总参数 ≈ 64 × 0.5B 共享层 ≈ 35B 每次激活 ≈ 2 × 0.5B 共享层 ≈ 3B3.3 GatedDeltaNet注意力机制Qwen3.6使用了GatedDeltaNet注意力机制而非传统的标准Multi-Head Attention GatedDeltaNet的特点 - 基于线性注意力Linear Attention - 支持超长上下文 - 推理效率更高 但在Qwable-v1的训练中遇到了兼容性问题 - flash-linear-attention库在H200 GPU上编译失败 - 退回了PyTorch参考实现数学等价但速度慢2-3倍 - 训练时间从预计的7-8小时变成了14.1小时3.4 参数量分析Qwable-v1的参数组成 原始Qwen3.6-35B-A3B参数约35,000,000,000350亿→ 全部冻结 LoRA适配器参数 每层的q_proj/k_proj/v_proj/o_proj各有LoRA 28层 × 4个投影 × 2个矩阵(A和B) × hidden_dim × r ≈ 约50,000,0005000万→ 可训练 可训练参数比例50M / 35B ≈ 0.14% 训练完成后LoRA通过merge_and_unload()合并回原始权重 最终模型是一个完整的35B模型没有额外的推理开销第四章链式蒸馏训练路线——Qwable-v1的成长过程4.1 两阶段链式蒸馏Qwable-v1的训练是链式的——分两步每步在上一步的基础上进行 阶段1推理能力蒸馏 ┌─────────────────────────────────────────────────┐ │ 基座模型Qwen3.6-35B-A3B (Apache 2.0) │ │ ↓ SFT用Claude Opus 4.7的推理数据 │ │ 中间模型Qwen3.6-35B-A3B-Claude-4.7-Opus- │ │ Reasoning-Distilled (Apache 2.0) │ └─────────────────────────────────────────────────┘ ↓ 阶段2智能体能力蒸馏 ┌─────────────────────────────────────────────────┐ │ 中间模型上一步的输出 │ │ ↓ SFT用Claude Fable-5的工具调用数据 │ │ 最终模型Qwable-v1 (AGPL-3.0) │ └─────────────────────────────────────────────────┘4.2 为什么分两步为什么不直接从Qwen3.6蒸馏Fable-5的能力 原因1能力分离 推理能力和智能体能力是不同的能力维度 分开训练可以更好地控制每种能力的学习 原因2数据可用性 Opus 4.7的推理数据相对容易获取 Fable-5的数据非常稀缺只有约5k条 分开训练可以对稀缺数据做更精细的处理 原因3避免灾难性遗忘 一次性在混合数据上训练可能导致两种能力互相干扰 分步训练可以更好地保留每步学到的能力 原因4可复用性 中间模型Opus 4.7推理蒸馏版本身就有价值 可以作为其他微调项目的基础4.3 每步的具体操作阶段1Opus 4.7推理蒸馏目标让Qwen3.6学会Claude Opus 4.7的推理方式 数据 Claude Opus 4.7的推理轨迹Chain-of-Thought 包含数学、科学、编程等领域的推理过程 训练方式 SFT监督微调 让模型学习模仿Opus 4.7的推理过程 结果 模型学会了 think.../think 格式的显式推理 推理能力接近Opus 4.7 输出格式推理过程 最终答案阶段2Fable-5智能体蒸馏目标在保留推理能力的基础上学会Fable-5的工具调用能力 数据 Claude Fable-5的智能体交互轨迹 约5k条81%以工具调用结束 训练方式 SFT监督微调 使用LoRA只训练注意力层的适配器 loss masking只在assistant回复上计算损失 结果 模型学会了 tool_use XML格式的工具调用 能像Claude Code一样做智能体编程 推理能力被保留因为是增量学习不覆盖4.4 链式蒸馏vs单步蒸馏链式蒸馏Qwable-v1的做法 Qwen3.6 → (蒸馏推理) → 中间模型 → (蒸馏智能体) → Qwable-v1 优点 - 每步专注学习一种能力 - 中间模型可复用 - 更容易控制训练过程 缺点 - 训练流程更长 - 可能存在误差累积 单步蒸馏一次性训练 Qwen3.6 → (同时蒸馏推理智能体) → 最终模型 优点 - 训练流程简单 - 避免误差累积 缺点 - 数据混合可能互相干扰 - 更难控制学习效果第五章训练细节——从超参数到硬件配置5.1 训练超参数Qwable-v1第二阶段Fable-5 SFT的完整训练配置 ┌──────────────────────┬─────────────────────────────┐ │ 参数 │ 值 │ ├──────────────────────┼─────────────────────────────┤ │ 基座模型 │ Qwen3.6-35B-A3B-Claude- │ │ │ 4.7-Opus-Reasoning-Distilled │ │ SFT数据集 │ agentic-distill-fable-5-sft │ │ 数据量 │ 4,659条约12.2M token │ │ 训练库 │ Unsloth TRL SFTTrainer │ │ LoRA r │ 16 │ │ LoRA alpha │ 16 │ │ LoRA目标层 │ q_proj, k_proj, v_proj, │ │ │ o_proj仅注意力层 │ │ LoRA dropout │ 0.0 │ │ 损失掩码 │ train_on_responses_only │ │ │只在assistant回复上计算损失 │ │ 序列长度 │ 4096 tokens │ │ 训练轮数 │ 2 epochs │ │ 有效batch大小 │ 16per_device1 × grad_accum16│ │ 优化器 │ AdamW 8-bit │ │ 学习率调度 │ cosine │ │ 预热比例 │ 3% │ │ 权重衰减 │ 0.01 │ │ 学习率 │ 2e-5 │ │ 精度 │ bf16 │ │ 随机种子 │ 3407 │ │ 硬件 │ 1× NVIDIA H200 (141GB) │ │ 总优化步数 │ 582步 │ │ 训练时长 │ 14.1小时 │ │ 训练成本 │ 约70美元$5/hr │ │ 最终损失 │ 0.804 │ │ 最后20步平均损失 │ 0.7956 │ │ 保存格式 │ merged_16bitUnsloth │ └──────────────────────┴─────────────────────────────┘5.2 关键训练决策解析决策1只对注意力层做LoRA为什么只选 q_proj, k_proj, v_proj, o_proj 不选FFN层gate_proj, up_proj, down_proj的原因 1. FFN层是MoE结构有多个专家 对MoE的FFN做LoRA需要特殊处理Unsloth的PR #601修复了这个问题 但为了简化先只对注意力层做 2. 注意力层已经足够 工具调用模式主要通过注意力机制来学习 什么时候调用工具、调用什么工具这些决策在注意力层完成 3. 参数效率 只对注意力层做LoRA参数量更少 减少过拟合风险训练数据只有5k条决策2损失掩码train_on_responses_only什么是损失掩码 训练数据格式多轮对话 [system] 你是一个智能体... ← 不计算损失 [user] 帮我读取文件... ← 不计算损失 [assistant] think.../think ← 计算损失 ✓ tool_use.../tool_use ← 计算损失 ✓ 只在assistant的回复上计算损失 system和user的部分不参与损失计算 为什么这样做 1. 我们只想让模型学习如何回答 不需要学习如何生成用户问题 2. 提高训练效率 不在无关部分浪费梯度 3. 防止模型模仿system prompt 避免模型在回答中重复系统提示决策3序列长度4096为什么是4096而不是更长 1. 训练数据的长度分布 大多数工具调用对话在4096 token内 少数超长对话会被截断 2. 显存限制 更长的序列需要更多显存 4096是H200显存下的合理选择 3. 训练效率 较短的序列意味着更快的训练速度决策4有效batch大小16per_device_batch_size 1每张GPU每次处理1条 gradient_accumulation 16累积16步才更新一次参数 有效batch大小 1 × 16 16 为什么per_device1 - 35B模型在单张H200上batch_size1已经接近显存极限 - 使用梯度累积来等效实现更大的batch 为什么有效batch16 - SFT训练通常用较小的batch16-32 - 数据量只有5k条太大的batch可能导致欠拟合5.3 训练过程详解训练步数计算 总样本数: 4,659 丢弃的样本: 11label-all-masked即整条数据都没有assistant回复 有效样本数: 4,648 epochs: 2 有效batch大小: 16 总步数 4,648 × 2 / 16 582步 实际训练时间 预计: 7-8小时 实际: 14.1小时约2倍 原因: GatedDeltaNet的Flash Attention在H200上编译失败 退回PyTorch参考实现速度慢2-3倍 每步约83秒预计应为36秒 数学等价性退回的参考实现在数学上与Flash版本完全等价 损失和收敛行为不受影响只是更慢5.4 训练损失分析最终损失: 0.804 最后20步平均损失: 0.7956 损失的含义 - 这是语言模型的交叉熵损失Cross-Entropy Loss - 0.8左右的损失对于SFT任务来说是合理的 - 说明模型较好地学习了训练数据的模式 损失值参考范围 - 预训练从零开始: 2.0-3.0 - SFT微调: 0.5-1.5 - Qwable-v1的0.804在这个范围内表明训练正常第六章数据集溯源——训练数据从哪来6.1 数据来源链Qwable-v1的训练数据经历了一个复杂的数据溯源链 TeichAI数据采集 │ │ 收集了953条原始Claude Code会话轨迹 │ 来源Anthropic的Claude Fable-5预览API │ 时间2026年6月10日-22日Fable-5全球暂停前 │ ↓ Glint-Research数据处理 │ │ 从原始轨迹中提取链式思考(CoT)推理 │ 添加了cot字段 │ 注意Anthropic的API对Fable-5的thinking block做了脱敏 │ Glint-Research做了后处理恢复 │ ↓ lordx64数据格式化 │ │ 重新格式化为Qwen聊天模板 │ 序列化 tool_use / tool_result XML │ SHA-256去重 │ 清理了204个暴露的Groq API密钥 │ ↓ 最终数据集: lordx64/agentic-distill-fable-5-sft 4,659条约12.2M token6.2 数据组成数据统计 总条数: 4,659 总token数: 约12.2M 工具调用类以tool_use结束: 3,793条81% 纯文本回复类: 866条19% 内容领域分布 - Web/游戏开发Three.js场景、多人FPS原型 - 流体模拟 - Express服务器开发 - Transformer训练脚本 - 波音747相关trace - 各种预览工具会话 数据局限性 - 本质上是一个开发者一周的Claude Code使用记录 - 领域分布较窄 - 对于训练数据中没有的领域如DevOps、数据科学、安全工作流 模型的表现可能不稳定6.3 数据格式每条训练数据的格式Qwen聊天模板 { text: |system|\n你是一个编码智能体...|endofsystem|\n |user|\n读取/tmp/server.py文件|endofuser|\n |assistant|\nthink\n用户想让我读取文件...\n/think\n tool_use name\Read\ id\toolu_01ABC...\\n {\file_path\: \/tmp/server.py\}\n /tool_use\n } 注意 - 是一个单一的text字段不是messages格式 - 已经用Qwen的聊天模板拼接好了 - 包含 think.../think 和 tool_use...tool_use 标记6.4 重要的法律/伦理考量⚠️ 关于训练数据的法律问题 1. Fable-5数据的来源 - Claude Fable-5是Anthropic的闭源模型 - 训练数据来自用户与Fable-5的交互记录 - Anthropic因美国出口管制于2026年6月22日全球暂停Fable-5 2. 许可协议 - Qwable-v1继承了Fable-5数据集的AGPL-3.0协议 - 下游用户如果以网络服务形式部署需要遵守AGPL §13源码披露义务 - 商业使用需要额外确认与Anthropic使用政策的合规性 3. 思考链数据的特殊性 - Anthropic的API在Fable-5预览期间对thinking block做了脱敏 - Glint-Research的数据包含了通过后处理恢复的思考链 - 这在法律上是一个灰色地带第七章使用方法——如何部署和调用Qwable-v17.1 方法1Transformers直接加载完整bf16约70GBfromtransformersimportAutoModelForCausalLM,AutoTokenizerimporttorch# 加载分词器和模型tokAutoTokenizer.from_pretrained(lordx64/Qwable-v1)modelAutoModelForCausalLM.from_pretrained(lordx64/Qwable-v1,torch_dtypetorch.bfloat16,device_mapauto,)# ⚠️ 关键必须使用agent风格的system prompt才能触发工具调用SYSTEM(You are a coding agent. When you need to read, write, edit, or run code, emit XML tool calls in this exact format:\ntool_use nameX idtoolu_01abc\n{...: ...}\n/tool_use\nDo NOT respond with markdown code blocks. Always use tool_use XML.)messages[{role:system,content:SYSTEM},{role:user,content:Read /tmp/server.py and tell me what port it listens on.},]# 生成回答inputstok.apply_chat_template(messages,add_generation_promptTrue,return_tensorspt).to(model.device)outmodel.generate(inputs,max_new_tokens2048,temperature0.6,top_p0.9,)print(tok.decode(out[0][inputs.shape[1]:],skip_special_tokensFalse))输出示例think The user wants me to read the file /tmp/server.py to find out what port it listens on. I should use the Read tool to get the file contents. /think tool_use nameRead idtoolu_01ABC... { file_path: /tmp/server.py } /tool_use7.2 方法2vLLM部署推荐生产环境# 启动vLLM服务vllm serve lordx64/Qwable-v1\--max-model-len16384\--tensor-parallel-size2\--trust-remote-code# 调用APIcurlhttp://localhost:8000/v1/chat/completions\-HContent-Type: application/json\-d{ model: lordx64/Qwable-v1, messages: [ {role: system, content: You are a coding agent...}, {role: user, content: Fix the bug in main.py} ], max_tokens: 2048, temperature: 0.6 }7.3 方法3GGUF量化版消费级GPU# 安装llama.cpp# 下载对应量化版本# IQ4_XS (~18GB) → 24GB显存GPU3090, 4090# Q5_K_M (~25GB) → 32-48GB显存# Q8_0 (~37GB) → 64GB显存# 运行llama-cli-mQwable-v1-IQ4_XS.gguf\-pRead /tmp/server.py and find the port...7.4 方法4Adapter模式组合使用# 如果你已经有了Opus 4.7推理蒸馏版的基座模型# 可以只加载LoRA适配器约50-100MBfrompeftimportPeftModelfromtransformersimportAutoModelForCausalLM,AutoTokenizer# 加载基座模型baseAutoModelForCausalLM.from_pretrained(lordx64/Qwen3.6-35B-A3B-Claude-4.7-Opus-Reasoning-Distilled,torch_dtypetorch.bfloat16,device_mapauto,)# 加载LoRA适配器modelPeftModel.from_pretrained(base,lordx64/Qwable-v1-adapter)# 现在model就是Qwable-v17.5 不同使用场景的prompt策略场景1智能体编程需要工具调用 ✅ 使用agent风格的system prompt ✅ 输出tool_use XML格式 场景2纯推理数学、科学、通用问答 ✅ 不使用system prompt或用通用prompt ✅ 输出think推理/think 文本回答 ✅ 推理能力来自Opus 4.7蒸馏和基座模型相当 场景3普通对话 ⚠️ 可以工作但人格可能偏向Claude风格 ⚠️ 可能偶尔自称Claude两轮Anthropic SFT叠加的效果第八章工具调用格式——智能体能力的技术细节8.1 XML工具调用格式Qwable-v1使用自定义的XML格式进行工具调用不是Qwen原生的 tool_call 格式 工具调用 tool_use name工具名 id唯一标识 { 参数名: 参数值 } /tool_use 工具返回 tool_result id对应工具调用的id is_errorfalse {返回内容} /tool_result8.2 触发工具调用的两种方式方式1Agent System Prompt推荐最简单 在system prompt中明确要求使用tool_use XML格式 模型就会在需要时生成工具调用 方式2多轮对话中的tool_result 在对话历史中提供一个tool_result回合 模型会自动在后续回复中继续使用XML格式 不需要特别的system prompt8.3 工具名称不绑定问题⚠️ 重要注意 训练数据中的工具名来自Claude Code Read, Edit, Write, Bash, WebFetch, mcp__*, ... 模型实际生成的工具名 read_file, Replace, write_file, Bash, ... 问题模型没有精确记忆Claude Code的工具名称 但它记住了XML格式本身 解决方案 下游系统需要一个工具名标准化器 例如read_file → Read, Replace → Edit8.4 与Qwen原生工具调用的兼容性Qwable-v1的tool_use XML ≠ Qwen原生的 tool_call JSON Qwen原生格式 tool_call{name: ..., arguments: {...}}/tool_call Qwable-v1格式 tool_use name... id...{...}/tool_use 如果需要使用vLLM的工具调用API需要 1. 编写一个解析器将XML转换为JSON 2. 或者等待v2版本可能支持原生格式第九章模型局限性——诚实的认知9.1 已知局限局限1工具调用是系统提示条件性的 没有agent system prompt时模型回退到Opus 4.7的推理模式 不会主动生成工具调用 局限2工具名称不精确 训练数据中的工具名和模型生成的工具名不完全一致 需要工具名标准化器 局限3训练数据领域窄 约5k条数据主要来自一个开发者的Claude Code使用记录 对于训练数据中没有的领域DevOps、数据科学等表现不稳定 局限4自定义工具封套 tool_use XML格式不能直接与vLLM的工具调用API对接 需要额外的解析器 局限5人格漂移 两轮Anthropic风格的SFT可能导致 - 模型偶尔自称Claude - 可能产生Qwen不会有的拒绝行为 局限6推理能力不会超越基座 Qwable-v1的推理能力来自Opus 4.7蒸馏 不会比基座的Opus 4.7蒸馏版更强 新增的能力是智能体工具调用不是更好的推理 局限7正式评估未完成 截至发布时所有benchmark评估仍在进行中 没有发布任何正式的性能数据9.2 与基座模型的关系Qwable-v1 vs 基座模型Opus 4.7推理蒸馏版 纯推理任务持平推理能力来自同一个基座 智能体编程Qwable-v1更强新增了Fable-5的工具调用能力 通用聊天可能有轻微人格差异第十章技术启发——从Qwable-v1学到什么10.1 链式蒸馏的方法论价值Qwable-v1展示了一种有效的多能力蒸馏策略 不是把所有能力一次性蒸馏 而是分步骤、分阶段地逐步注入 这种方法可以推广到 - 先蒸馏推理能力再蒸馏代码能力 - 先蒸馏通用能力再蒸馏领域专业知识 - 先蒸馏基础对话再蒸馏多轮交互10.2 LoRA在大模型蒸馏中的应用Qwable-v1证明了 用LoRA只有0.14%的参数就能有效地蒸馏新能力 不需要全量微调 训练成本只有70美元 这对资源有限的团队非常有价值 - 你不需要大量GPU - 你不需要巨大的训练数据 - 你只需要高质量的教师模型输出10.3 数据质量 数据数量Qwable-v1只用了4,659条数据就实现了有意义的能力注入 关键因素 - 数据来自真实的Claude Code使用场景不是合成数据 - 数据格式正确Qwen聊天模板 - 损失掩码确保只学习回复部分 - 链式蒸馏确保每步专注一种能力10.4 开源模型的能力叠加范式Qwable-v1展示了一种新的开源模型发展范式 基座模型开源← Qwen3.6 闭源模型的推理能力 ← Opus 4.7蒸馏 闭源模型的智能体能力 ← Fable-5蒸馏 开源的、具有闭源级能力的模型 这种从闭源蒸馏到开源的模式可能会越来越普遍 但也带来了法律和伦理的挑战附录版本信息与引用版本信息模型版本: v1更多迭代计划中 发布日期: 2026年6月 HuggingFace: https://huggingface.co/lordx64/Qwable-v1 Adapter: https://huggingface.co/lordx64/Qwable-v1-adapter GGUF: https://huggingface.co/lordx64/Qwable-v1-GGUF 训练数据: https://huggingface.co/datasets/lordx64/agentic-distill-fable-5-sft引用misc{lordx64_qwable_v1_2026, title {Qwable-v1: Agentic coding distillation from Claude Fable-5 onto Qwen3.6-35B-A3B}, author {lordx64}, year {2026}, howpublished {\url{https://huggingface.co/lordx64/Qwable-v1}}, }致谢- Glint-Research收集和重新发布Fable-5 trace语料 - TeichAI上游953条trace的收集 - AnthropicClaude Fable-5预览模型和Opus 4.7 - Qwen团队Qwen3.6-35B-A3B开源Apache 2.0 - Unsloth2×更快的LoRA训练和MoELoRA形状修复 - HuggingFaceH200推理端点基础设施