在 Amazon SageMaker AI 上用知识蒸馏构建高效智能体

AWS ML Blog 2026-11-02T22:03:23.280168

你基于前沿模型（frontier model，当前能力最强的一类大模型）搭建了一个购物助手，它运行得很好。用户提出“帮我找一款 20 美元以内、店铺评分至少 4.5 星的黑色腰包”，智能体会搜索商品目录、查看候选商品、核对约束条件，最后给出推荐。但这样一次交互的成本是多少？

智能体助手并不是调用一次模型就能完成，它是一个循环：搜索、读取结果、细化、验证、决策。完成一个任务，往往要多次调用前沿模型，而每一位用户、每一次调用都要付费。到了生产规模，单个任务的成本会不断累积，侵蚀项目收益，最终让项目无法上线。

要让智能体应用更高效，一个办法是换用小模型：响应更快，托管成本更低。问题出在质量上——小模型通常完不成任务，而这正是当初选择大模型的原因。知识蒸馏可以弥补这个差距：把大“教师”模型的行为迁移到小“学生”模型里，训练学生模型复现教师模型的输出，从而在小模型的速度和成本下保留大部分质量。

本文将介绍如何利用知识蒸馏，特别是序列级知识蒸馏（sequence-level knowledge distillation，SeqKD），在 Amazon SageMaker AI 上微调一个购物智能体。内容包括：如何用前沿教师模型生成高质量的多步轨迹，并只保留真正完成任务的那些；如何把这些轨迹编码成监督微调所需的数据；如何在无服务器基础设施上运行训练；以及如何用留出基准（held-out benchmark）评估学生模型。

图 1：一个智能体任务是一个循环，不是一次调用：智能体搜索、读取结果、细化、验证并决策，每一步都是对前沿模型的一次单独计费调用。完成一个任务可能涉及多次调用，而且每位用户都要经历一遍

什么是序列级知识蒸馏（SeqKD）？

最容易落地的一种蒸馏形式就是序列级知识蒸馏（SeqKD）。做法是：用教师模型生成高质量回答，再用这些回答对学生模型做监督微调（supervised fine-tuning，SFT）。

SeqKD 只需要教师模型的文本输出，不需要访问教师的 logits，也不需要强化学习基础设施，因此即使教师模型是闭源的或只能通过 API 调用，它也能正常工作。相比基于 logit 或 on-policy 的其他方法，它在蒸馏方法中处于成本最低、可移植性最强的一端。教师模型写出答案，学生模型在这些答案上做微调。由于这些答案会作为数据集保存下来，你可以重复使用它们来训练或测试不同的学生模型，无需重新生成数据。理论上，你希望学生模型能匹配教师模型在可能输出上的完整分布。但问题在于，这做不到。可能的序列空间大到天文数字级别，精确匹配并不可行。SeqKD 绕开了这个问题，用教师模型实际生成的样本来近似这个分布。对智能体来说，教师模型生成的序列不是一段散文，而是一条轨迹——按顺序展开的推理、工具调用及其返回的观察结果，每一步都以前面所有步骤为条件。让学生模型在这整条序列上训练，学到的是通向每个动作的推理过程以及多步行动路线本身，而不是一段答案文本。这使得智能体任务成为序列级 KD 最清晰的例证之一，因为被复制的序列就是行为本身。图 2：SeqKD 仅通过教师的文本输出传递行为：教师生成轨迹，学生在这些轨迹上训练，结果在小模型的速度和成本下保留了教师的大部分质量。训练过程中不需要教师权重、logits 或梯度，因此它可以作为普通的监督微调来运行。什么时候 SeqKD 是正确选择？SeqKD 适用于特定的一组场景：你有输入，但没有高质量的目标输出。这是 SeqKD 的核心用例，本质上就是数据生成。你提供输入，教师写出目标，因此你可以对一个没有现成高质量标签的任务或领域做微调。目标可以简单到单个答案，也可以复杂到多轮工具使用轨迹。

这篇文章讨论的是这个谱系中要求较高的一类：智能体轨迹（agentic trajectories），这类数据尤其难以获取。一个任务会分支成许多部分正确的运行，而区分一次运行是成功还是失败，需要一个可靠的评分器。带程序化评分器的基准测试正好能提供这一点，因此你可以让教师模型生成轨迹，只保留那些成功解决任务的轨迹。你的教师模型是一个只能通过 API 访问的前沿模型，这是前沿模型的常态。你无法访问权重来自己托管它，无法读取其 logits，也无法微调它。这就排除了基于 logit 的蒸馏和在线策略方法，因为它们都需要这种内部访问权限。SeqKD 只需要教师的文本响应，因此它是唯一仍然可行的方法，并且当学生模型接手后，你无需为每次请求支付前沿模型的高昂费用。你想要一个强大且经济高效的第一步。一些最强的小型推理模型在很大程度上是通过 SeqKD（对教师推理轨迹进行监督微调）构建的，因此只要设置得当，它就是推理迁移的有效起点。DeepSeek-R1 蒸馏模型就是一个著名的例子：通过对教师生成的推理轨迹进行微调，将大型教师的推理能力蒸馏到较小的 Qwen 和 Llama 学生模型中。

前提条件

要运行这个示例，你需要：

一个 AWS 账户，拥有适用于 SageMaker AI 的 AWS Identity and Access Management (IAM) 角色，该角色对 Amazon Simple Storage Service (Amazon S3) 存储桶具有读写访问权限，并有权调用你的教师模型。
一个用于生成轨迹的前沿教师模型（本演练使用 Amazon Bedrock 上的一个模型）。
在受支持的 AWS 区域中访问 SageMaker AI 模型定制功能。
Amazon SageMaker Studio（或配置了 AWS CLI 的本地 IDE），运行 Python 3.12 或更高版本的内核，使用 SageMaker Python SDK v3 和 boto3（固定你的版本）。笔记本环境至少使用 ml.m5.4xlarge 实例，因为数据准备和本地评分步骤在其 CPU 上运行。
具备 Python、监督微调和工具使用智能体的工作知识。

配套代码仓库，以及一项带程序化评分器的任务（本演练用 ShoppingBench 测试集，你可以换成自己的任务和评分器）。

方案概览

本节把整条流水线从头到尾走一遍。Amazon Bedrock 上的前沿教师模型 GLM-5.3 扮演 ShoppingBench 智能体，负责生成轨迹；基准自带的评分器只保留真正解出任务的轨迹；再用这些成功轨迹，在 SageMaker AI 模型定制里对学生模型 Qwen3.5-4B 做无服务器监督微调。蒸馏后的学生模型在留出的 ShoppingBench 测试集上评估，然后部署在 SageMaker AI Inference 实时端点后面，由它执行工具调用循环。

图 3：在 Amazon SageMaker AI 上蒸馏购物智能体——Amazon Bedrock 上的前沿教师模型在训练题上扮演 ShoppingBench 智能体，ShoppingBench 自带的评分器只留下解出任务的轨迹（拒绝采样），每条成功轨迹按步骤编码，学生模型通过 Amazon SageMaker AI 模型定制做无服务器微调，最后在留出的 ShoppingBench 测试集上评估结果。

准备数据集

真正难的是找到值得模仿的轨迹，而 ShoppingBench 的评分器正是把成功运行和失败运行分开的关键。ShoppingBench 发布了 750 道合成的购物题，商品、店铺、优惠券三类意图各 250 道，每道题都有一个隐藏的标准答案，以及判定成功与否的约束条件。我们一次性把它们切成 426 道训练题和 324 道留出评估题（商品 103、店铺 105、优惠券 116），用固定索引划分，保证两边不重叠。

对每道训练题，前沿教师模型 GLM-5.3（Amazon Bedrock，开启推理，温度 1.0）扮演 ShoppingBench 智能体。它会去搜索约 270 万件商品的目录，检查候选商品，再推荐满足约束的那几件。每道题我们对教师采样两次，共得到 850 条轨迹，然后交给 ShoppingBench 自带的评分器，只保留解出任务的轨迹。温度设为 1.0 是有意为之。

采样（而非贪婪解码）让两次尝试探索不同的查询和推理路径，从而让更多问题至少有一条成功轨迹，学习集合也更加多样。这个拒绝采样步骤把“有能力但不完美”的教师模型变成了干净训练集：教师只需足够频繁地答对，成功的运行就值得模仿。每条成功轨迹都是一个完整回合：购物者请求、教师每一步的推理和工具调用（搜索、查看、推荐、终止），以及环境返回的观察。我们保留推理过程与动作，结果部分显示，正是这一点让大部分学生模型达到教师水平。为训练编码轨迹序列级蒸馏是对已有轨迹做监督学习，因此训练中不调用任何工具，应用只看到文本。由于这些轨迹是多步工具使用对话，我们把每条编码成消息列表（聊天轮次），交给学生模型自己的聊天模板渲染，使训练器看到的 token 与智能体推理时产生的 token 一致。每条轨迹每一步变成一行训练数据。用户轮承载系统提示和到此为止的对话。助手轮承载该步的推理及其引发的工具调用：先是 ... 块，然后是 [{...}]，采用测试框架原生形式。损失只落在助手轮，因此模型学习生成下一步的推理和动作，而不是预测环境返回的观察。多步轨迹会扩展成多行。这里过滤后，成功轨迹扩展成约 2,600 行训练数据和 130 行验证数据。一行把到此为止的对话（user）与要学习的下一步（assistant）配对：

"messages": [

{"role": "user", "content": "你是一名购物助手。...\n# 任务\n从评分 4.5 或更高的店铺中找一款 20 美元以下的黑色腰包。\n# 目前观察\n（暂无）"},

{"role": "assistant", "content": "<think>先做宽泛搜索，让价格筛选起作用，再按店铺评分收窄范围。</think>\n<tool_call>[{\"name\": \"find_product\", \"parameters\": {\"q\": \"黑色腰包\", \"price\": \"0-20\"}}]</tool_call>"}

]

后续每一步各自成行：把新的观察结果追加到 user 内容里，把下一步的推理与工具调用作为 assistant 的目标，如此一直到最后的 recommend_product 和 terminate 调用。每一行都用模型自己的对话模板（chat template）渲染。数据要按问题划分，不能按行划分。教师模型对每个问题采样两次，每条轨迹又会展开成多个步骤，所以很多行其实来自同一个问题；如果按行划分，训练集和验证集之间就会泄漏几乎相同的上下文。按整个问题留出（约 5%）才能保证验证集可信。

逐步编码的代价是上下文重复：每一行都要把不断变长的对话重新写一遍。无服务器微调会截断超过 dataset_max_len 的内容，一旦某行越界，就会丢掉它所需的一部分信息。与其让长度限制决定删什么，不如主动把行控制在预算内。最有效的办法是压缩工具观察结果，因为它们在 token 数量中占大头。以商品搜索结果为例，只保留下一步决策真正依赖的字段（id、价格、评分，以及正在检查的约束），丢掉原始列表文本，并限制每次搜索保留的结果条数。如果轨迹仍然超预算，就限制每条轨迹的步骤数。这里 dataset_max_len 为 16,384 个 token，观察结果裁剪后能装下大多数轨迹。

每个划分的 JSONL 放进 S3 之后，用 SageMaker Python SDK v3 的 DataSet.create 把它们分别注册为自定义数据集资产，返回的 train_dataset 和 val_dataset 就是训练作业要用的输入。

微调学生模型

训练使用 SageMaker AI 的模型定制（model customization）功能，采用无服务器 SFT。你从模型中心（model hub）选一个基础模型，把作业指向编码好的数据集，托管服务就会自动准备算力、运行作业并返回定制后的模型，指标则记录在 Amazon SageMaker with MLflow 中。由于数据已经是受支持的格式，你不需要写训练脚本，也不用管理容器镜像或实例。

作业会把输出写入一个模型包组（model package group），该组会为它产出的每个模型做版本管理。所以先用 ModelPackageGroup.create 创建这个组（如果名称已存在就复用），再把它传给训练器。接下来配置定制作业：选择基础模型和训练类型，指定训练数据集、验证数据集和模型包组，再命名一个 MLflow 实验，这样作业运行时指标会实时流向 MLflow。

from sagemaker.train.sft_trainer import SFTTrainer

from sagemaker.train.common import TrainingType

sft_trainer = SFTTrainer(
    model="huggingface-vlm-qwen3-5-4b",  # Qwen3.5-4B from the JumpStart model hub
    training_type=TrainingType.LORA,  # TrainingType.FULL for full fine-tuning
    training_dataset=train_dataset.arn,
    validation_dataset=val_dataset.arn,
    model_package_group=model_package_group,
    mlflow_experiment_name="seqkd-shopping-exp",
    s3_output_path="s3://<amzn-s3-demo-bucket>/seqkd/output/",
    accept_eula=True,
)

训练器启动时会带一组有文档记录的默认超参数，可以用 sft_trainer.hyperparameters.to_dict() 查看，并在启动前覆盖。这次运行中，我们调大了序列长度以容纳多步轨迹，把 Low-Rank Adaptation（LoRA）的秩设为 64，并在小数据集上训练三个 epoch：

sft_trainer.hyperparameters.dataset_max_len = 16384
sft_trainer.hyperparameters.max_epochs = 3
sft_trainer.hyperparameters.global_batch_size = 64
sft_trainer.hyperparameters.learning_rate = 0.0001
sft_trainer.hyperparameters.lora_rank = 64
sft_trainer.hyperparameters.lora_alpha = 256  # alpha / rank = 4
sft_trainer.hyperparameters.lr_warmup_steps_ratio = 0.1
sft_trainer.hyperparameters.train_val_split_ratio = 0.95

先用 dry run 验证配置，然后启动托管任务，等它完成后读取注册的 Model Package ARN。这个 ARN 就是可直接部署的产物，后续评估和推理步骤都会用到它：

from sagemaker.core.resources import TrainingJob

sft_trainer.train(dry_run=True)  # checks the config without launching

training_job = sft_trainer.train(wait=True)  # launch and wait

model_package_arn = TrainingJob.get(
    training_job_name=training_job.training_job_name
)

).output_model_package_arn

评估学生模型

评估分两个阶段，先从成本最低的做起。完整的端到端评估既耗时又耗资源：它要在数百万商品之上启动搜索服务器、部署端点，还要对每一道留出的题目跑一遍多步代理循环。所以在跑全量评估之前，先用 SageMaker AI 的模型评估功能做一次低成本的托管预检——它逐个生成步骤打分，对照教师模型的真实动作来判断学生模型做得对不对。

预检需要评分函数。模型评估支持自定义评分器（Custom Scorer）奖励函数，你提供函数，它每个样本跑一次，把学生模型生成的动作和教师模型的参考动作做比较。对工具调用蒸馏来说，要评的是工具选择（模型有没有按顺序调对工具，参数格式先不管），因为这才是蒸馏最需要传递的行为。为了让重点落在选择而非语法上，奖励函数会从学生动作和教师参考里分别读出工具名，不要求格式完全一致。

def reward_function(sample, index):
    pred = sample.get("model_response", "")
    ref = sample.get("reference_answer", "") or sample.get("response", "")
    ref_names = tool_names(ref)   # tool names from the teacher's <tool_call>[...]</tool_call>
    pred_names = tool_names(pred)  # tool names the student emitted, parsed leniently
    toolset = 1.0 if (pred_names and pred_names == ref_names) else 0.0
    return {
        "id": str(sample.get("id", f"sample-{index:03d}")),
        "aggregate_reward_score": toolset,  # the gate metric: tool selection
        "metrics_list": [
            {"name": "toolset_match", "value": toolset, "type": "Reward"},
        ],

把这个函数用 Evaluator.create() 注册成带版本号的 Evaluator，再调用 evaluate()，每个任务跑一个 Custom Scorer 作业，同时给基础模型和学生模型打分，这样每条结果都带对比。判断规则很简单：学生模型必须在这项低成本预检上赢过基础模型。赢了，说明蒸馏有效，值得再跑更完整的端到端评估；没赢，就先回去修训练。

部署蒸馏后的智能体

蒸馏出来的模型不会自己调用工具。微调教会它的是：在合适的时机，以文本形式发出正确的工具调用；但总得有东西去执行这次调用，再把结果送回去。推理时，可以用一层小型的确定性外壳程序包住模型：提示模型，解析它发出的工具调用，执行工具，追加观测结果，再次提示，如此循环，直到模型给出最终答案。这就是普通的应用代码，或者现成的服务框架，既不是强化学习，也不是 on-policy 训练循环。

学生模型是架在开放权重基座模型上的低秩适配器（LoRA），这决定了部署方式。不必把适配器合并进去、再单独服务一份完整的权重副本；更好的做法是只服务一次基础模型，把学生模型作为适配器挂在上面，作为同一个实时端点上的两个推理组件。调用时指定推理组件名，就能决定由谁来回答。于是同一个端点可以同时服务基础模型和蒸馏后的学生模型，方便并排对比。

我们用 Deep Java Library Large Model Inference（DJL LMI）容器来服务开放权重模型。它内置 vLLM 引擎，适合高吞吐生成。版本固定到具体版本，而不是用 latest，这样重新部署的结果可复现。配套的 notebook 把推理组件的调用封装进一个叫 kd_serve 的小助手里。于是，部署启用了 LoRA 服务的基础组件，再挂上学生适配器，就简化成了下面这样：

from sagemaker.core import image_uris
import kd_serve

# DJL LMI container (vLLM engine bundled in); pin the version for reproducible redeploys
image_uri = image_uris.retrieve("djl-lmi", region=region, version="0.36.0")

# 1. Deploy the base model as an inference component, with LoRA serving enabled.
endpoint_name, base_ic = kd_serve.deploy_base_endpoint(
    endpoint_name="seqkd-shopping-agent",
    role=role,
    region=region,
    image_uri=image_uri,
    base_model_id="Qwen/Qwen3.5-4B",
    instance_types=["ml.g5.2xlarge", "ml.g6.2xlarge", "ml.g6e.2xlarge"],
    max_lora_rank=64,
    max_loras=4,
    max_model_len=131072,
)

# 2. Resolve the student's adapter artifacts from its Model Package and attach them
#    as a second inference component on the same base.
adapter_uri = kd_serve.resolve_adapter_uri(model_package_arn, region)
student_ic = kd_serve.attach_adapter(
    endpoint_name=endpoint_name,
    base_ic_name=base_ic,
    adapter_component_name=f"{endpoint_name}-student",
    adapter_s3_uri=adapter_uri,
    region=region,
)

instance_types 列表是一组有先后顺序的偏好。SageMaker AI Inference 会部署在第一个有可用容量的实例类型上，没有的话就按顺序往下找，所以根据可用情况，学生模型会运行在 ml.g5.2xlarge、ml.g6.2xlarge 或 ml.g6e.2xlarge 上。基础权重只加载一次，两个推理组件共用，因此添加适配器只增加适配器大小的内存，而不必再存一份完整模型。

结果

我们在留出的 ShoppingBench 测试集上评估蒸馏后的学生模型，对照一组参考对象，这些对象勾勒出「好」的范围：

Base Qwen3.5-4B：未经微调的现成学生模型。这是下限。
蒸馏学生模型（SeqKD）：同一个 4B 模型，在教师轨迹上微调，也就是本文介绍的方法。这是关键结果。
GLM-5.3 教师模型：生成训练数据的前沿模型，运行在 Bedrock 上。我们报告两种设置下的结果：采样模式（temperature 1.0，即生成数据时的设置）和贪婪模式（temperature 0）。
中等规模前沿模型：一个强大的专有模型，作为 agent 运行，用作实际的上限。

每个模型都在三种购物意图（product、shop 和 voucher）上运行相同的、未修改的 ShoppingBench agent 循环。我们报告绝对成功率（Absolute Success Rate，ASR），即 agent 解决的留出问题所占比例，在三种意图上取平均，缺失轨迹计为失败。只有当推荐的产品满足所有给出的约束时，该问题才算解决。以下数字来自 LoRA 学生模型的单次运行，所以预期会有几个点的运行间波动。

任务成功率

主要结果是 324 个留出问题上的绝对成功率，按意图拆分，并在三种意图上取平均：

图 4：留出 ShoppingBench 测试集上按购物意图划分的绝对成功率（ASR）。

模型	商品	店铺	优惠券	平均
Base Qwen3.5-4B（未微调）	0.456	0.314	0.121	0.297
蒸馏后的学生模型（SeqKD）	0.563	0.638	0.422	0.541
GLM-5.3 教师模型（采样，温度 1.0）	0.553	0.619	0.362	0.511
GLM-5.3 教师模型（贪心，温度 0）	0.544	0.638	0.439	0.540
中等规模前沿模型	0.583	0.667	0.388	0.546

总的来说，这个 4B 学生模型基本复现了前沿教师模型的任务质量，差距落在多次运行的自然波动范围内。教师模型我们给出了两种结果，因为它们回答的是不同问题。贪心解码返回唯一一条最可能的轨迹，如果每个模型对每道题只有一次机会（本次评测就是这种情况），贪心是更强的选择——所以贪心教师拿到 0.540，而采样教师是 0.511。我们的训练数据是用另一种方式生成的：以温度 1.0 采样，让重复尝试探索不同路径，再由评分器保留成功解题的那些。也正是这层筛选，让学生模型能够略微超过它学习的采样教师——因为拒绝采样只用教师成功跑通的轨迹来训练它，而不是教师的平均输出，所以它模仿的是「最佳样本」子集，而非全部尝试的分布。

目标里保留推理过程很关键

学生模型既学习教师模型的工具调用，也学习它的推理过程，这个选择在很大程度上决定了最终效果。用同样的轨迹、但把推理去掉只留干巴巴的工具调用去训练同一个学生模型，平均绝对成功率（ASR）会从 0.541 掉到 0.415：

Figure 5: 基础模型、只用工具调用训练的学生模型、以及用教师推理加工具调用训练的学生模型三者的绝对成功率对比。

保留推理大约带来 13 个点的平均 ASR 提升，而且每个意图类别上都有增益。两个学生模型都超过了基础模型，所以即便只用工具调用版本也是实打实的进步，但真正把它一路推到教师水平的是保留推理这部分。

动作之间的推理不是可以丢弃的叙述，它是解决问题的行为的一部分。保留通用能力 ASR 衡量的是我们蒸馏所针对的技能。需要权衡的是学生模型是否保留了通用指令遵循能力，还是对购物任务过拟合了。我们用 IFEval 来检查，这是一个通用指令遵循基准，对可验证的格式指令打分，例如“恰好用三个要点回答”。把它当作回归检查，而不是排行榜。学生模型的 prompt-strict 分数从基座模型的 0.819 降至 0.741，instruction-strict 分数从 0.872 降至 0.813，下降约 6 到 8 分（图 6）。这是专业化预期的代价。学生模型用部分通用指令遵循能力换取了购物任务上的大幅提升。如果下降幅度大得多，那才是警告信号，说明蒸馏把模型收窄得过头了。图 6：基座模型和蒸馏后学生模型在 IFEval 通用指令遵循上的 prompt-strict 和 instruction-strict 指标。小幅下降是在购物任务上专业化的预期代价

收益与权衡

单看成功率并不足以证明切换的合理性。蒸馏的理由是：以更小模型的成本与速度，获得更强模型的大部分质量。这里最清晰的证据是，4B 的学生模型达到了其前沿教师模型和中等规模前沿模型的任务质量，同时小到足以在单个 G 系列实例上部署（本例中为 NVIDIA A10G/L40/L40S）。成本差异不仅在于规模，也在于形态。通过 API 调用的前沿模型按 token 计费，每个任务的每一步都计费，因此成本随用量增长且不会停止，引言中的智能体循环每次都要支付这笔费用。蒸馏后的学生模型运行在你自托管的端点，按小时对实例计费，无论服务一个任务还是数千个任务，因此增加的流量在扩容之前不会带来额外成本。你用按请求的可变费用换取了按小时的固定费用，而你能用的模型越小，这笔固定成本就越小。

这里不公布单任务成本或延迟的具体数字，因为它取决于你的流量：G 系列实例能维持多少吞吐量、每个任务分摊多少成本，都由请求模式、序列长度和并发数决定。与其相信一个醒目的数字，不如拿自己的负载去实测，再对照 SageMaker AI 当前定价和前沿模型提供商的 token 价格来算。

局限与最佳实践

任务能否塞进学生模型（能力墙）

蒸馏传递的是学生模型已经能表达的分布，而不是它原本缺少的原始能力。差距太大时，学生只会模仿教师的格式，学不会真正解题。拿大模型的思维链去训练小模型，小模型会输出结构完整、篇幅很长的推理，但答案依然是错的；用同样方式训练智能体，它会发出格式正确却毫无进展的工具调用，换个说法重新搜索，一路跑到步数上限也没满足约束。两者的症状一样：轨迹越来越长，准确率却原地踏步。遇到这种情况，别再加数据了，要么扩大学生模型，要么降低任务难度。

决定成败的差距，在任务和学生之间，而不在学生和教师之间。只要任务本身在学生能力范围内，小模型也能恢复大得多的教师模型的质量。文中的购物智能体之所以有效，原因就在这里：教师是混合专家模型（MoE），激活参数约 400 亿，大概是学生模型 40 亿参数的十倍；但购物任务完全在 4B 模型的能力范围内，所以学生恢复的是教师的质量，而不只是把轨迹拉长。

SeqKD 在哪些地方不再有效

SeqKD 能提升简单和中等难度的问题，但在最难的问题上会停滞——这类问题要求学生从自己的错误中恢复。对智能体来说，这一点比单步任务更明显。在多步循环里，早期错误会不断累积，因为学生看不到自己的错误会导向哪些状态。同策略方法（on-policy）要补的就是这个缺口，所以 SeqKD 通常只是第一阶段，而不是终点。

SeqKD 对基础设施的要求也最低，因为它只用教师的文本；而 logit 蒸馏需要教师对每个 token 的概率分布，on-policy 方法则要对学生自己的 rollout 打分。先用纯文本 SeqKD 热启动、再跑 on-policy 阶段，是很常见的做法。本文只覆盖第一阶段，突破性能平台期则是顺理成章的下一步。

决定成败的两个选择

第一，让训练目标和想要的行为对齐。在这里，这意味着每次工具调用都保留教师的推理过程，而不是压缩成最终答案，因为推理本身就是解题的一部分（结果部分量化了这一差距）；同时用 agent 在服务时使用的 chat 模板来渲染每一条目标。

第二，诚实评估。要在模型没见过的数据上测，因为泄漏的基准会虚高分数；对比对象也不能只有那个未训练的基座模型——学生必然能赢它。要把学生和教师、以及一个独立的前沿模型放在一起比，这样数字才能说明学生离它的蒸馏来源有多近。

清理资源

实时推理端点只要在运行就持续计费，所以拿到结果后，要拆掉为部署而搭的端点。由于学生是以适配器推理组件的形式叠在基座推理组件之上提供服务的，拆除时必须按依赖顺序来：先拆适配器组件，再拆基座组件，最后是端点和它的配置。配套的 kd_serve 辅助工具会替你完成这些，它从结构上定位适配器，所以不管组件具体叫什么名字都能清理干净：

import kd_serve

# 先删除适配器 IC，再删除基础 IC，最后删除端点和它的配置

kd_serve.teardown_endpoint(endpoint_name, region=region)

训练作业本身不用清理。Serverless 训练会自动完成算力的准备、运行和释放，作业跑完不会继续计费。注册的模型包及其模型组也不产生算力费用，可以留作血缘记录，方便以后重新部署。唯一持续产生费用的是 S3 里的数据（编码后的轨迹和输出产物），只要保留就会一直收存储费。不再需要的数据及时删掉，或者转到更便宜的存储类型。

结论

本文介绍了如何用序列级知识蒸馏（sequence-level knowledge distillation，SeqKD）把一个 agentic 购物助手蒸馏成更小、更便宜的学生模型。具体做法是：先用 Bedrock 上的前沿教师模型生成高质量的单轮、多步轨迹，再用 ShoppingBench 自带的评分器筛选，只保留真正完成任务的样本；把每一步编码成聊天格式的消息，保留教师模型的推理过程和工具调用；借助 SageMaker AI 的模型定制功能，在 serverless 基础设施上微调学生模型；用 MLflow 跟踪训练；用 SageMaker AI 的模型评估做质量门禁检查；最后把结果部署在推理端点后面，由端点负责执行工具调用循环。

收益很明显：4B 的学生模型基本完整继承了前沿教师模型的任务质量。由于 SeqKD 只需要教师模型输出的文本，即使教师是通过 API 访问的闭源前沿模型也能用；学生模型接手后，就不必每一步都按前沿模型的价格付费了。

SeqKD 是很好的第一步，但也有实际局限。学生模型的规模要和任务匹配；评估要用留出测试集，并且对标强参考基线，不能只跟未训练的基座模型比；遇到最难的那部分问题、模仿学不会时，可以在 SeqKD 之后接上基于策略的方法（on-policy methods，本文未涉及），让学生从自己的输出中学习。

想自己动手试，可以参考配套代码仓库和 SageMaker AI 文档。

关于作者

Giuseppe Zappia 是 AWS 的首席生成式 AI（GenAI）专家解决方案架构师，主要帮助大型企业设计并在 AWS 上部署生成式 AI 方案。他有 20 多年全栈软件工程师经验，过去 7 年在 AWS 专注 AI 领域。

Ankita Agarwal 是 AWS 的软件开发工程师，负责 Amazon SageMaker AI 的分布式训练和强化学习相关工作。她拥有南加州大学计算机工程硕士学位。工作之余喜欢旅行。

Amin Dashti 是 AWS 的资深数据科学家和研究员，专注后训练与模型定制：包括强化学习、微调以及知识蒸馏，用于适配大模型，并把它们的能力压缩进更小、可部署的模型。他有 8 年以上经验，构建并部署过覆盖计算机视觉、自然语言处理和金融系统统计推断的机器学习系统。他拥有理论物理学博士学位，这也影响了他研究模型行为和评估的方式。

Michael Oguike 是 Amazon SageMaker AI 的产品经理，热衷于用技术和 AI 解决实际问题。在 AWS，他帮助各行各业的客户大规模构建、训练和部署 AI/ML 模型。加入 AWS 之前，Michael 曾负责海上油气井及设施的设计与运营。工作之余，他喜欢通过书籍和播客探索行为科学与心理学。

基于前沿模型（frontier models，指当前能力最强的顶尖大模型）搭建的智能体助手，运行时要在多步工具调用循环里反复推理。每一步都按前沿模型的价格付费，放到生产规模上很难长期撑住。本文介绍如何用序列级知识蒸馏（sequence-level knowledge distillation，SeqKD）把前沿教师模型（teacher）的智能体行为迁移到一个更小、成本更低的学生模型（student）上，并在 Amazon SageMaker AI 上跑起来。

查看原文