Qwable-v1 模型详解 —— 链式蒸馏打造开源智能体编程模型

这两天看到一个基于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 为什么叫Qwable？

Qwable = 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 关键参数 │ ├──────────────────┬──────────────────────────────┤ │ 总参数量 │ 35B（350亿） │ │ 激活参数量 │ 3B（30亿，MoE架构） │ │ 模型架构 │ Qwen3.6-35B-A3B (MoE) │ │ 精度 │ bf16（约70GB） │ │ 训练硬件 │ 1× NVIDIA H200 (141GB) │ │ 训练时长 │ 14.1小时 │ │ 训练成本 │ 约70美元 │ │ 训练数据量 │ 4,659条（约1220万token） │ │ 训练方法 │ LoRA SFT (r=16) │ │ 最终损失 │ 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 什么是LoRA？

LoRA = Low-Rank Adaptation = 低秩自适应 核心思想： 不修改原始大模型的全部参数 只在旁边加一个小的"适配器" 只训练适配器的参数 原始权重W（冻结不动） LoRA适配器 = A × B（可训练，参数量很小） 最终权重 = W + A × B Qwable-v1的LoRA配置： - r=16（秩为16） - alpha=16（缩放因子） - 只对注意力层做LoRA（q_proj, k_proj, v_proj, o_proj） - dropout=0.0

2.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 + 共享层 ≈ 3B

3.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,000（350亿）→ 全部冻结 LoRA适配器参数： 每层的q_proj/k_proj/v_proj/o_proj各有LoRA 28层 × 4个投影 × 2个矩阵(A和B) × hidden_dim × r ≈ 约50,000,000（5000万）→ 可训练 可训练参数比例：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 每步的具体操作

阶段1：Opus 4.7推理蒸馏

目标：让Qwen3.6学会Claude Opus 4.7的推理方式 数据： Claude Opus 4.7的推理轨迹（Chain-of-Thought） 包含数学、科学、编程等领域的推理过程 训练方式： SFT（监督微调） 让模型学习模仿Opus 4.7的推理过程 结果： 模型学会了 <think>...</think> 格式的显式推理 推理能力接近Opus 4.7 输出格式：推理过程 + 最终答案

阶段2：Fable-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大小 │ 16（per_device=1 × grad_accum=16）│ │ 优化器 │ 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_16bit（Unsloth） │ └──────────────────────┴─────────────────────────────┘

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大小16

per_device_batch_size = 1（每张GPU每次处理1条） gradient_accumulation = 16（累积16步才更新一次参数） 有效batch大小 = 1 × 16 = 16 为什么per_device=1？ - 35B模型在单张H200上，batch_size=1已经接近显存极限 - 使用梯度累积来等效实现更大的batch 为什么有效batch=16？ - SFT训练通常用较小的batch（16-32） - 数据量只有5k条，太大的batch可能导致欠拟合

5.3 训练过程详解

训练步数计算： 总样本数: 4,659 丢弃的样本: 11（label-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 token

6.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|>\n<think>\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-v1

7.1 方法1：Transformers直接加载（完整bf16，约70GB）

fromtransformersimportAutoModelForCausalLM,AutoTokenizerimporttorch# 加载分词器和模型tok=AutoTokenizer.from_pretrained("lordx64/Qwable-v1")model=AutoModelForCausalLM.from_pretrained("lordx64/Qwable-v1",torch_dtype=torch.bfloat16,device_map="auto",)# ⚠️ 关键：必须使用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:\n"'<tool_use name="X" id="toolu_01abc">\n{"...": "..."}\n</tool_use>\n'"Do 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."},]# 生成回答inputs=tok.apply_chat_template(messages,add_generation_prompt=True,return_tensors="pt").to(model.device)out=model.generate(inputs,max_new_tokens=2048,temperature=0.6,top_p=0.9,)print(tok.decode(out[0][inputs.shape[1]:],skip_special_tokens=False))

输出示例：

<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 name="Read" id="toolu_01ABC..."> { "file_path": "/tmp/server.py" } </tool_use>

7.2 方法2：vLLM部署（推荐生产环境）

# 启动vLLM服务vllm serve lordx64/Qwable-v1\--max-model-len16384\--tensor-parallel-size2\--trust-remote-code# 调用APIcurlhttp://localhost:8000/v1/chat/completions\-H"Content-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 方法3：GGUF量化版（消费级GPU）

# 安装llama.cpp# 下载对应量化版本：# IQ4_XS (~18GB) → 24GB显存GPU（3090, 4090）# Q5_K_M (~25GB) → 32-48GB显存# Q8_0 (~37GB) → 64GB+显存# 运行llama-cli-mQwable-v1-IQ4_XS.gguf\-p"Read /tmp/server.py and find the port..."

7.4 方法4：Adapter模式（组合使用）

# 如果你已经有了Opus 4.7推理蒸馏版的基座模型# 可以只加载LoRA适配器（约50-100MB）frompeftimportPeftModelfromtransformersimportAutoModelForCausalLM,AutoTokenizer# 加载基座模型base=AutoModelForCausalLM.from_pretrained("lordx64/Qwen3.6-35B-A3B-Claude-4.7-Opus-Reasoning-Distilled",torch_dtype=torch.bfloat16,device_map="auto",)# 加载LoRA适配器model=PeftModel.from_pretrained(base,"lordx64/Qwable-v1-adapter")# 现在model就是Qwable-v1

7.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_error="false"> {返回内容} </tool_result>

8.2 触发工具调用的两种方式

方式1：Agent System Prompt（推荐，最简单） 在system prompt中明确要求使用<tool_use> XML格式 模型就会在需要时生成工具调用 方式2：多轮对话中的<tool_result> 在对话历史中提供一个<tool_result>回合 模型会自动在后续回复中继续使用XML格式 不需要特别的system prompt

8.3 工具名称不绑定问题

⚠️ 重要注意： 训练数据中的工具名（来自Claude Code）： Read, Edit, Write, Bash, WebFetch, mcp__*, ... 模型实际生成的工具名： read_file, Replace, write_file, Bash, ... 问题：模型没有精确记忆Claude Code的工具名称 但它记住了XML格式本身 解决方案： 下游系统需要一个"工具名标准化器" 例如：read_file → Read, Replace → Edit

8.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的收集 - Anthropic：Claude Fable-5预览模型和Opus 4.7 - Qwen团队：Qwen3.6-35B-A3B开源（Apache 2.0） - Unsloth：2×更快的LoRA训练和MoE+LoRA形状修复 - HuggingFace：H200推理端点基础设施