十分钟微调:Qwen3-0.6B如何通过模型蒸馏实现大模型效果

通过模型蒸馏,0.6B模型性能逼近235B!成本响应双优化,手把手教你实现。#模型蒸馏 #AI

原文标题:10分钟微调,让0.6B模型媲美235B模型!免费体验进行中

原文作者:阿里云开发者

冷月清谈:

大型参数模型表现卓越,但其高昂的成本和较慢的响应速度是实际应用中的痛点。为解决此问题,业内常采用模型蒸馏的方法:利用大参数模型生成目标任务数据,进而微调小参数模型,使其在特定任务中达到媲美甚至接近大参数模型的表现。

本方案以 Qwen3-0.6B 为例,演示了如何通过模型蒸馏,使其在从一句话中提取结构化信息(如收件人、地址、电话)的任务上,表现出接近 Qwen3-235B 模型的识别能力。整个过程涵盖了数据准备(以虚拟地址数据为例,通过235B大模型生成训练数据),模型微调(利用魔搭社区的 ms-swift 框架简化操作,命令式启动训练),以及效果验证(原始模型准确率仅为14%,经过微调后,即使采用更简洁的提示词,准确率也跃升至98%)。

方案详情还包括详细的计算环境配置建议,例如选择预装GPU驱动的镜像,以及如何通过命令行安装依赖、启动微调和效果评测。整体操作流程清晰,强调了即便不了解微调算法细节,也能通过提供的工具快速上手。这为企业在保障效果的同时,显著降低AI应用成本和提升推理效率提供了可行的途径。文中提及的免费体验机会,进一步降低了用户探索和实践的门槛。

怜星夜思:

1、文章里提到0.6B模型通过蒸馏能媲美235B模型,在特定任务上准确率还达到98%。大家觉得这种模型蒸馏的方法,对于一般中小企业应用大模型来说,是不是比直接用大模型更划算?有没有什么潜在的坑或者局限性呢?
2、文章里提到数据准备时,用235B大模型生成数据来训练0.6B小模型。实际业务中,这种由大模型“产出”的数据质量怎么保证?如果大模型本身就有偏见或者偶尔出错,会不会把这些问题也“蒸馏”给小模型,导致它虽然准确率高,但泛化能力有限?
3、除了文章里提到的地址信息抽取,大家觉得模型蒸馏这种技术还能在哪些实际业务场景里大放异彩?有没有什么你设想过的,这种“以大带小”方式能解决的有趣问题?

原文内容

大参数模型效果好,但成本高、响应慢。为了在保障效果的同时提升推理速度、降低成本,可首先借助大参数模型完成目标任务的数据生成,并使用这些数据微调小参数模型,使其在特定任务中达到接近大参数模型的表现,这一过程也被称为模型蒸馏。

本方案将以从一句话中提取结构化信息(如收件人、地址、电话)为例,演示如何通过模型蒸馏,让 Qwen3-0.6B 模型在此任务上达到大参数模型的表现。

先来看效果对比吧。经过了模型优化后,识别能力确实有所提高。

当前,《基于 GPU 云服务器微调 Qwen3 模型》技术方案开放免费体验您只需要点击文末阅读原文即可开启。

如果您想免费体验更多技术解决方案,可以登录aliyun.com,点击权益中心-解决方案免费试用领取100点试用点。

一、方案路线

1. 数据准备

由于真实的物流填单数据涉及到用户隐私,我们将使用一批虚拟地址描述信息作为输入,并使用 Qwen3-235B-A22B 作为教师模型提取结构化的信息作为输出。

建议您在模型微调时使用业务场景的真实数据。

2. 模型微调

在获取教师模型的输入输出后,我们可以使用该数据来微调 Qwen3-0.6B 模型,提升其在此任务场景下的表现。这里我们将使用魔搭社区提供的 ms-swift 框架,即使您不了解微调算法的细节,依然可以借通过一行命令来完成微调任务。

3. 效果验证

最后,为了确保模型在真实业务场景中的稳定性与准确性,建议在部署到生产环境前准备评测数据与评测标准,对微调后的模型进行效果验证。

二、配置计算环境

大模型微调对计算环境有较高要求,需配套安装合适版本的 GPU 驱动、CUDA(NVIDIA的并行计算平台和编程模型)和 cuDNN(NVIDIA的深度神经网络加速库)。手动通过命令行安装不仅步骤繁琐,而且容易出错。为提升部署效率,您可在创建 GPU 云服务器实例时选择带有 GPU 驱动的镜像,省去复杂的命令行操作,快速启动微调任务。

我们推荐用免费试用的方式体验本方案。免费试用助您零成本体验本解决方案,但试用期间创建的资源与数据在结束后会被清除。免费试用的时长有限,若需长期使用云资源,可以参考:

https://www.aliyun.com/solution/tech-solution-deploy/2925027?utm_content=g_1000405783 页面中手动创建部分。

1. 根据页面提示,领取试用点并创建资源,右侧将实时展示资源创建进程。可能需要等待几分钟。

2. 连接 GPU 云服务器

在跳转页面中,使用左侧的登录名称登录密码登录。

单击左侧的远程连接按钮,再单击登录,即可连接到 GPU 云服务器。

三、下载并微调模型

微调模型通常上手门槛较高。通过魔搭社区提供的 ms-swift 框架,您仅需一句命令即可快速启动微调任务,大幅降低操作复杂度。

1.安装依赖

本方案依赖以下两个核心组件:

  • ms-swift

魔搭社区提供的训练框架,支持模型的下载、微调和权重合并,极大简化了微调流程。

  • vllm

用于部署微调后的模型,支持高性能推理服务,不仅方便验证微调效果,还可用于生成 API,供业务方直接调用。

您可以在终端运行以下命令来安装依赖:

pip3 install vllm==0.9.0.1 ms-swift==3.5.0

安装依赖大约需要5分钟。

2.模型微调

运行以下命令可以完成模型下载、微调、合并权重的操作:

# 进入 /root 目录
cd /root && \
# 下载微调脚本 sft.sh
curl -f -o sft.sh "https://help-static-aliyun-doc.aliyuncs.com/file-manage-files/zh-CN/20250623/cggwpz/sft.sh" && \
# 执行微调脚本
bash sft.sh

模型微调核心代码如下,您可以在 sft.sh 文件中看到:

dataset 参数指定的'train.jsonl'为数据准备步骤获得的训练集。

swift sft \
    --model Qwen/Qwen3-0.6B \
    --train_type lora \
    --dataset 'train.jsonl' \
    --torch_dtype bfloat16 \
    --num_train_epochs 10 \
    --per_device_train_batch_size 20 \
    --per_device_eval_batch_size 20 \
    --learning_rate 1e-4 \
    --lora_rank 8 \
    --lora_alpha 32 \
    --target_modules all-linear \
    --gradient_accumulation_steps 16 \
    --save_steps 1 \
    --save_total_limit 2 \
    --logging_steps 2 \
    --max_length 2048 \
    --output_dir output \
    --warmup_ratio 0.05 \
    --dataloader_num_workers 4

微调模型大约需要10分钟,期间会实时打印如下所示的模型在训练集与验证集的损失变化情况:

出现以下信息表明模型微调已完成:

✓ swift export 命令执行成功
检查合并结果...
✓ 合并目录创建成功: output/v0-xxx-xxx/checkpoint-50-merged

✓ LoRA权重合并完成!
合并后的模型路径: output/v0-xxx-xxx/checkpoint-50-merged

完成该步骤会在output/v0-xxx-xxx路径下生成带有 merged 后缀的文件夹,为微调后的模型文件。

您可以在output/v0-xxx-xxx路径下中找到 images 文件夹,打开 train_loss.png(反映训练集损失) 与 eval_loss.png(反映验证集损失),根据损失值的变化趋势初步判断当前模型的训练效果:

  • 在结束训练前 train_loss 与 eval_loss 仍有下降趋势(欠拟合)

您可以增加 num_train_epochs(训练轮次,与训练深度正相关) 参数,或适当增大 lora_rank(低秩矩阵的秩,秩越大,模型能表达更复杂的任务,但更容易过度训练)的值后再进行训练,加大模型的对训练数据的拟合程度;

  • 在结束训练前 train_loss 持续下降,eval_loss 开始变大(过拟合)

您可以减少 num_train_epochs 参数,或适当减小lora_rank的值后再进行训练,防止模型过度训练;

  • 在结束训练前 train_loss 与 eval_loss 均处于平稳状态(良好拟合)

模型处于该状态时,您可以进行后续步骤。本方案的 train_loss 与 eval_loss 变化如下表所示:

train_loss

eval_loss

如果训练失败,您也可以尝试调整 learning_rate等参数。


四、验证效果

在将微调后的模型部署到实际业务环境前,我们建议先对其效果进行系统性的评测。只有通过充分验证,才能确保模型具备良好的稳定性和准确性,避免上线后出现意料之外的问题。

1.准备测试数据

测试数据的格式应与训练数据一致,以确保评测的可比性。

测试数据应使用区别于训练数据的全新样本用于测试。这样可以更准确地反映模型在新数据上的泛化能力,避免因“见过的样本”导致分数虚高。

您可以运行以下命令获取我们准备好的测试数据:

cd /root && \
# 下载测试数据 test.jsonl
curl -o test.jsonl "https://help-static-aliyun-doc.aliyuncs.com/file-manage-files/zh-CN/20250610/mhxmdw/test_with_system.jsonl"

以下两行示例样本供您参考:

{"messages": [{"role": "system", "content": "你是一个专业的信息抽取助手,专门负责从中文文本中提取收件人的JSON信息,包含的Key有province(省份)、city(城市名称)、district(区县名称)、specific_location(街道、门牌号、小区、楼栋等详细信息)、name(收件人姓名)、phone(联系电话)"}, {"role": "user", "content": "电话:23204753945:大理市大理市人民路25号 大理古城国际酒店 3号楼:收件者:段丽娟"}, {"role": "assistant", "content": "{\"province\": \"云南省\", \"city\": \"大理市\", \"district\": \"大理市\", \"specific_location\": \"人民路25号 大理古城国际酒店 3号楼\", \"name\": \"段丽娟\", \"phone\": \"23204753945\"}"}]}
{"messages": [{"role": "system", "content": "你是一个专业的信息抽取助手,专门负责从中文文本中提取收件人的JSON信息,包含的Key有province(省份)、city(城市名称)、district(区县名称)、specific_location(街道、门牌号、小区、楼栋等详细信息)、name(收件人姓名)、phone(联系电话)"}, {"role": "user", "content": "天津市河西区珠江道21号金泰大厦3层 , 接收人慕容修远 , MOBILE:22323185576"}, {"role": "assistant", "content": "{\"province\": \"天津市\", \"city\": \"天津市\", \"district\": \"河西区\", \"specific_location\": \"珠江道21号金泰大厦3层\", \"name\": \"慕容修远\", \"phone\": \"22323185576\"}"}]}

2.设计评测指标

评测标准应紧贴实际业务目标。以本方案为例,除了判断生成的 JSON 字符串是否合法,还应该关注对应 Key、Value 的值是否正确。

本案例评测方法核心代码

def compare_address_info(actual_address_str, predicted_address_str):
    """比较两个JSON字符串表示的地址信息是否相同"""
    try:
        # 解析实际地址信息
        if actual_address_str:
            actual_address_json = json.loads(actual_address_str)
        else:
            actual_address_json = {}
        
        # 解析预测地址信息
        if predicted_address_str:
            predicted_address_json = json.loads(predicted_address_str)
        else:
            predicted_address_json = {}
        
        # 直接比较两个JSON对象是否完全相同
        is_same = actual_address_json == predicted_address_json
        
        return {
            "is_same": is_same,
            "actual_address_parsed": actual_address_json,
            "predicted_address_parsed": predicted_address_json,
            "comparison_error": None
        }
        
    except json.JSONDecodeError as e:
        return {
            "is_same": False,
            "actual_address_parsed": None,
            "predicted_address_parsed": None,
            "comparison_error": f"JSON解析错误: {str(e)}"
        }
    except Exception as e:
        return {
            "is_same": False,
            "actual_address_parsed": None,
            "predicted_address_parsed": None,
            "comparison_error": f"比较错误: {str(e)}"
        }

3.评测初始模型效果

我们针对 Qwen3-0.6B 模型设计了多版提示词,选取效果最好的系统提示词为:

你是一个专业的信息抽取助手,专门负责从中文文本中提取收件人的结构化信息。

任务说明

请根据给定的输入文本,准确提取并生成包含以下六个字段的JSON格式输出:

  • province: 省份/直辖市/自治区(必须是完整的官方名称,如"河南省"、“上海市”、"新疆维吾尔自治区"等)
  • city: 城市名称(包含"市"字,如"郑州市"、"西安市"等)
  • district: 区县名称(包含"区"、“县"等,如"金水区”、"雁塔区"等)
  • specific_location: 具体地址(街道、门牌号、小区、楼栋等详细信息)
  • name: 收件人姓名(完整的中文姓名)
  • phone: 联系电话(完整的电话号码,包括区号)

抽取规则

  1. 地址信息处理
       - 必须准确识别省、市、区的层级关系
       - 省份名称必须使用官方全称(如"河南省"而非"河南")
       - 直辖市的province和city字段应该相同(如都填"上海市")
       - specific_location应包含详细的街道地址、小区名称、楼栋号等

  2. 姓名识别
       - 准确提取完整的中文姓名,包括复姓
       - 包括少数民族姓名

  3. 电话号码处理
       - 提取完整的电话号码,保持原有格式

输出格式

请严格按照以下JSON格式输出,不要添加任何解释性文字:
{
  “province”: “省份名称”,
  “city”: “城市名称”, 
  “district”: “区县名称”,
  “specific_location”: “详细地址”,
  “name”: “收件人姓名”,
  “phone”: “联系电话”
}

使用上述系统提示词与测试样本对没有微调的本地 Qwen3-0.6B 模型进行评测:

# 进入 /root 目录
cd /root && \
# 下载并执行验证脚本
curl -o evaluate_without_sft.py "https://help-static-aliyun-doc.aliyuncs.com/file-manage-files/zh-CN/20250617/ksrneh/evaluate_without_sft.py" && \
curl -o evaluate_without_sft.sh "https://help-static-aliyun-doc.aliyuncs.com/file-manage-files/zh-CN/20250617/cmvbcz/evaluate_without_sft.sh" && \
bash evaluate_without_sft.sh

执行后可以看到,尽管优化了提示词,测试样本准确率仅有14%:

所有预测完成! 结果已保存到 predicted_labels_without_sft.jsonl
样本数: 400 条
响应正确: 56 条
响应错误: 344 条

评估脚本运行完成

4.验证微调后模型效果

使用测试样本对微调后的模型进行评测:

# 进入 /root 目录
cd /root && \
# 下载并执行验证脚本
curl -o evaluate.py "https://help-static-aliyun-doc.aliyuncs.com/file-manage-files/zh-CN/20250612/bzszyc/evaluate.py" && \
curl -o evaluate.sh "https://help-static-aliyun-doc.aliyuncs.com/file-manage-files/zh-CN/20250612/xtgxql/evaluate.sh" && \
bash evaluate.sh

针对微调后的模型,我们使用了更简单的提示词,这可以提升模型推理时的响应速度:

你是一个专业的信息抽取助手,专门负责从中文文本中提取收件人的JSON信息,包含的Key有province(省份)、city(城市名称)、district(区县名称)、specific_location(街道、门牌号、小区、楼栋等详细信息)、name(收件人姓名)、phone(联系电话)

即使使用了更简单的提示词,微调模型的准确率也达到 98%,相比微调前的 14% 准确率有了大幅提升。

所有预测完成! 结果已保存到 predicted_labels.jsonl
样本数: 400 条
响应正确: 392 条
响应错误: 8 条

评估脚本运行完成

至此,您已经成功完成了一次模型微调。

如果您需要在生产环境中使用,可以点击文末阅读原文参考后续内容

您也可以通过在aliyun.com 直接搜索“10分钟微调,让0.6B模型媲美235B模型”即可直达技术解决方案,获得更多部署方案。

10分钟微调:让0.6B模型媲美235B模型


大参数模型效果好,但成本高、响应慢。针对该问题,可以用大参数模型的输出去微调小参数模型,使其在特定任务中的表现接近大参数模型,这一过程也被称为模型蒸馏。本方案介绍如何通过模型蒸馏提升 Qwen3-0.6B 模型在特定任务的表现(本案例中准确率从14%提升至90%以上)。


点击阅读原文查看详情。


关于第一个问题,模型蒸馏确实是成本效益的优选。尤其对于资源受限的中小企业,直接调用大型API成本高昂,响应延迟也大,而且数据隐私也是个问题。蒸馏后的轻量级模型可以部署在边缘设备或本地服务器上,既经济高效又保障数据安全。但其局限性在于,蒸馏模型是针对特定任务进行优化的,其泛化能力和处理复杂、开放域问题的能力远不如其“教师”模型。文中的98%准确率是针对特定数据集,实际生产环境仍需谨慎验证其鲁棒性,特别是遇到非预期的输入时。

关于第三个问题,模型蒸馏的应用场景远不止信息抽取。任何需要高并发、低延迟且任务相对聚焦的大模型能力下沉场景都适用。例如,在智能客服中,可以将复杂问答模型的能力蒸馏到小模型上,用于处理高频常见问题,降低每次交互的成本;在电商评论情感分析领域,用于快速识别不同商品评论的情绪倾向;在工业质检中,将复杂缺陷识别模型的经验转移给边缘设备上的小型视觉模型,实现实时检测。甚至在个性化推荐系统中,也可以将用户行为模式抽取的复杂逻辑蒸馏到轻量级模型,提升实时推荐效率。

这就像老师(大模型)就算再厉害,偶尔也会写错别字,或者讲错个年代(别问我怎么知道的)。要是学生(小模型)不加辨别全盘接受,那不就跟着跑偏了嘛。所以,得有点“批判性思维”,或者叫“数据清洗”。不能大模型说啥就是啥,要不然以后小模型犯错,锅都在大模型身上就不好玩了。而且“幻觉”也会传递,那可就搞笑了。

针对第二个问题,在模型蒸馏中,教师模型生成的数据质量确实是关键。业界通常会采取多种策略确保数据纯净。例如,可以通过设置高置信度阈值来过滤教师模型的生成结果;还可以引入人工审核,对少量但关键的由教师模型生成的数据进行抽样检查和纠错,形成“黄金数据”进行弥补。如果教师模型本身存在偏差或“幻觉”现象,这种偏差的确有可能被‘蒸馏’给学生模型,导致在特定情况下,学生模型的局部表现甚至不如其教师。因此,对生成的数据进行多维度评估和验证至关重要,而非盲目相信。

哈哈,这不就是花小钱办大事嘛!请个“学霸”老师(大模型)来给“尖子生”(小模型)押题,然后“尖子生”轻松考高分!省钱肯定是省的,毕竟跑0.6B的模型比跑235B简直是毛毛雨。潜在的坑嘛,我觉得就是“学霸”押题也可能跑偏,万一押错了,或者考题超纲了,“尖子生”就也跟着懵圈了。所以,核心还是看你业务的场景是不是足够聚焦,别想让它干“全能超人”的活就行。

哎呀,这太真实了!我之前就遇到过,大模型虽然聪明,但偶尔也会犯点“低级错误”。比如,它可能把“西湖区”识别成“杭州西湖风景名胜区”,用它生成的数据一训练,小模型也会跟着错。所以,我觉得不能完全依赖大模型自动生成的数据。至少得有个复核机制,或者在数据生成后,再用一小部分人工标注的“黄金数据”对小模型做二次微调,弥补一下大模型的“随性”。不然省了算力,栽在数据质量上就得不偿失了。

很多啊!简单一点的文本分类(比如垃圾邮件识别、新闻热点分类),客服机器人里的常见问题回复(FAQ),或者一些特定的图片识别任务(比如识别快递包裹上的条形码或二维码,或者检测生产线上的小瑕疵)。只要是场景明确、数据量大而且对响应速度有要求的,都可以考虑用这种方式。毕竟大模型再好,也不是所有业务都用得起、等得起的,小模型更灵活。

我觉得只要是那种“量大”、“重复性高”、“但又需要点智能”的活儿,都能用上!比如,现在很多电商的商品评论,大模型去分析每个评论的情绪太贵了,用蒸馏过的小模型去做情感分析,效率高,成本低。还有会议纪要的自动整理,或者游戏里NPC的简单对话生成,金融行业的合同关键条款提取,甚至是一些法规文本的初步分类和摘要等等,都能让小模型跑起来,省下大笔开销。简直是“企业降本增效”的魔法!

我觉得吧,这事儿看你怎么用。像文章里这种特定任务的抽取,小模型98%的准确率那是相当给力了,省钱又快。部署起来也没那么吃资源。但如果你想让这0.6B的模型去写诗、搞逻辑推理,那肯定还是不够的。就好比你教一个小学霸只练语数外,他考试能满分,但你让他去造火箭,那就不行了。所以,知道它的能力边界很重要。坑的话,可能是训练数据质量和成本,还有就是小模型泛化能力可能不如大模型。