知识蒸馏一直是模型压缩和训练小模型的主流路线但很多团队在实际跑蒸馏的时候会发现一个问题同样的损失函数、同样的网络结构数据质量直接决定蒸馏结果的上限。如果喂给学生的数据本身噪声大、重复多、答案链不完整再好的蒸馏算法也救不回来。PROOF-Gen 这个方向的核心思路就是把“数据”从蒸馏流程里的固定输入变成可生成、可筛选、可纠错的优化环节。它的目标很简单用优化后的数据让蒸馏出来的小模型更接近大模型教师的效果。从项目标题“从优化数据到更好的知识蒸馏”来看它关注的不是蒸馏损失函数的细节调参而是把数据工程和蒸馏训练串成一条完整链路。这篇文章会围绕 PROOF-Gen 的方法论展开讲清楚它要解决什么问题、完整流程怎么拆、每一步怎么落地验证并给出一套可以直接参考的代码实现和排查清单。涉及数据生成、过滤、去重、蒸馏训练、效果评估、资源占用和常见坑位。适合正在做模型蒸馏、合成数据、小模型训练或者想系统了解数据优化链路的算法工程师。1. PROOF-Gen 核心能力速览从项目标题和知识蒸馏领域常见的实现方式来看PROOF-Gen 更接近一个“方法框架训练流程”而不是一个开箱即用的单文件工具。它把知识蒸馏拆成三个关键环节数据生成、数据优化、蒸馏训练并在中间加入质量控制和验证闭环。能力项说明项目类型知识蒸馏与训练数据优化方法框架核心思想通过生成数据、优化数据、筛选数据提升蒸馏训练效果主要技术链路教师模型生成数据 → 规则模型双重过滤 → 去重纠错 → 学生模型蒸馏训练适用场景大模型蒸馏小模型、合成数据训练、推理链数据构建推荐硬件GPU 训练环境具体显存取决于教师和学生模型规模显存占用不确定需按实际模型版本和 batch size 测试启动方式脚本化运行分阶段执行建议配合任务调度器是否支持 API方法论本身不强制数据生成和蒸馏可封装成独立服务是否支持批量任务支持数据生成和过滤天然适合批量并行适合读者模型训练工程师、数据团队、算法研究员需要说明的是PROOF-Gen 的具体版本号、基准测试数字、官方仓库路径目前没有更多公开材料因此本文重点放在方法拆解和可复用实现上。如果你在某个开源仓库或论文里看到它的具体实现建议以官方代码为准本文提供的是通用落地思路。2. 为什么知识蒸馏需要“优化数据”2.1 蒸馏的本质是让学生复制教师的“行为”蒸馏通常分两步先让大模型教师对训练数据生成输出再把输入和教师输出作为监督信号训练小模型学生。最常见的做法是让教师模型生成 soft label 或直接生成文本答案然后最小化学生输出与教师输出的差异。问题在于教师输出并不等于高质量的监督信号。教师模型可能在复杂推理题上给出错误答案。在长文本生成中出现前后矛盾。对同一个问题多次采样得到不同质量的结果有的好有的差。生成大量语义重复的样本导致学生训练数据冗余。如果直接把这些输出全部灌进蒸馏训练学生在学教师的能力的同时也会把教师的错误和噪声一起学进去。2.2 数据优化要解决三个问题从 PROOF-Gen 的方法论角度看数据优化至少要解决三个层面的问题第一是正确性。教师输出的答案或推理链必须经过验证。对于数学、代码、逻辑推理类任务可以用执行验证、规则校验、人工抽检等方式剔除错误样本。第二是多样性。如果训练数据高度相似学生模型只会记住表面模式泛化能力差。数据优化需要做去重和多样性控制确保覆盖足够多的题型和表达方式。第三是可学习性。有些教师输出虽然正确但推理链太长、跳跃性过大学生模型根本学不会。数据优化需要把这类样本拆解、补充中间步骤或者直接过滤掉。2.3 PROOF-Gen 的定位把数据当作可优化的中间产物传统蒸馏流程里数据是静态的模型训练是动态的二者脱节。PROOF-Gen 的思路是把数据也变成动态环节用教师模型生成候选数据用质量模型打分过滤用规则引擎做格式和正确性检查最后把通过验证的数据送入蒸馏训练。这相当于在“教师模型”和“学生模型”之间加了一层数据治理层。它不是某个单一的损失函数改进而是整个蒸馏流程的重组。这也是当前合成数据训练小模型的主流做法先拿大模型造数据再造更好的数据最后用小模型学更好的数据。3. PROOF-Gen 整体流程拆解一次完整的 PROOF-Gen 蒸馏流程可以拆成五个阶段确定任务范围和评估基准。用教师模型生成候选训练数据。对候选数据做质量过滤和优化。用优化后的数据训练学生模型。在评估基准上对比学生模型、教师模型和基线模型的效果。整个流程是闭环的评估结果如果不够好可以回到数据生成阶段调整提示词、采样参数或过滤阈值再重新训练。# 伪代码PROOF-Gen 整体流程 # 实际运行时需要按项目目录和模型路径调整 python stage1_generate.py --seed_data ./data/seeds.jsonl \ --teacher_model path/to/teacher \ --output ./data/raw.jsonl python stage2_optimize.py --input ./data/raw.jsonl \ --output ./data/optimized.jsonl \ --filter_rules ./config/filter_rules.json python stage3_distill.py --train_data ./data/optimized.jsonl \ --student_model path/to/student_base \ --output_dir ./checkpoints/student每个阶段都可以独立运行、独立验证。这也是工程上比较推荐的拆分方式数据生成、数据优化和蒸馏训练对资源的需求不同拆开跑更容易排查问题和做并行调度。4. 环境准备与前置条件4.1 硬件资源PROOF-Gen 的实际资源需求取决于教师模型和学生模型的规模。如果教师模型是 7B 级别生成数据时建议准备 24GB 以上显存的 GPU如果教师模型是 70B 级别则需要多卡推理或量化方案。学生模型蒸馏训练阶段显存需求主要取决于学生模型的参数量、序列长度和 batch size。更稳妥的做法是先小规模跑通再逐步放大先用 1k 条数据、小 batch、短序列验证流程再扩展到全量数据。4.2 软件依赖蒸馏训练通常基于 PyTorch 生态核心依赖如下具体版本号需要按本机 CUDA 版本和模型要求调整# 创建虚拟环境 conda create -n proofgen python3.10 conda activate proofgen # 安装基础依赖 pip install torch transformers datasets accelerate pip install deepspeed # 需要多卡训练时安装 pip install vllm # 需要高性能教师模型推理时选择数据层面建议安装pip install pandas pyarrow jsonlines pip install scikit-learn # 用于文本向量化和去重 pip install nltk # 用于文本清洗和分词4.3 目录规划建议在一开始就按阶段分目录避免数据文件混乱project/ ├── config/ # 过滤规则、采样参数、评估配置 ├── data/ │ ├── seeds/ # 种子问题集 │ ├── raw/ # 教师模型生成结果 │ ├── optimized/ # 优化后的训练数据 │ └── eval/ # 评估集 ├── checkpoints/ # 学生模型检查点 ├── logs/ # 训练和评估日志 ├── scripts/ # 各阶段脚本 └── outputs/ # 评估报告和示例输出这样设计的好处是每个阶段的产物都有明确落点批量任务失败后可以快速定位到具体文件继续处理。5. 数据生成阶段让教师模型产出候选数据5.1 种子问题集数据生成的第一步是准备种子问题集。种子问题不需要多但需要覆盖目标任务的各类题型和难度。比如数学推理任务种子集应该包含简单计算、方程求解、几何推理、多步应用题等不同类型。种子问题的来源可以有三个渠道开源数据集采样。人工编写覆盖边界情况的题目。从已有训练数据中抽样。种子集的质量直接影响生成数据的多样性。如果种子题本身就单一生成出的数据大概率也是单一分布的。5.2 提示词设计教师模型生成数据时提示词决定了输出的格式和质量。PROOF-Gen 这类方法通常要求教师模型输出结构化内容包含问题、推理过程和最终答案便于后续做规则校验。下面是一段生成数学推理数据的提示词示例# 提示词模板用于教师模型生成推理数据 GENERATION_PROMPT 你是一个数据生成引擎。请根据下面的题目和参考答案生成一段完整的解题过程。 要求 1. 推理过程分步骤写出每步只做一个变换。 2. 最终答案放在最后一行格式为答案xxx。 3. 推理过程中不要省略关键步骤。 4. 如果题目有歧义先给出你的理解再开始解题。 题目 {question} 参考答案 {answer} 请生成 在实际使用中可以配合 temperature 参数做多次采样。一般建议 temperature 设置在 0.7 到 1.0 之间采样 3 到 5 次让候选集有足够多样性再进入过滤环节。5.3 批量生成与断点续跑数据生成是耗时最长的阶段。如果使用 vLLM 做批量推理可以显著提升吞吐量。下面是一个基于 vLLM 的批量生成脚本模板# scripts/generate_data.py # 使用 vLLM 批量生成数据支持断点续跑 import json import os from vllm import LLM, SamplingParams def load_seeds(path): with open(path, r, encodingutf-8) as f: seeds [json.loads(line) for line in f if line.strip()] return seeds def build_prompts(seeds): prompts [] for item in seeds: prompt GENERATION_PROMPT.format( questionitem[question], answeritem.get(answer, ) ) prompts.append(prompt) return prompts def main(): seeds load_seeds(data/seeds/seeds.jsonl) prompts build_prompts(seeds) model_path os.environ.get(TEACHER_MODEL, path/to/teacher) llm LLM(modelmodel_path, tensor_parallel_size1) sampling_params SamplingParams( temperature0.8, top_p0.95, max_tokens1024, n3 # 每个 prompt 采样 3 次 ) outputs llm.generate(prompts, sampling_params) # 输出到 raw 目录 os.makedirs(data/raw, exist_okTrue) with open(data/raw/generated.jsonl, w, encodingutf-8) as f: for idx, output in enumerate(outputs): for sample in output.outputs: record { id: fsample_{idx}, prompt: output.prompt, generated_text: sample.text, finish_reason: sample.finish_reason } f.write(json.dumps(record, ensure_asciiFalse) \n) if __name__ __main__: main()批量生成时要注意两个问题输出文件写入。建议按批次写入比如每 1000 条 flush 一次避免进程中断导致全部丢失。去重策略。生成阶段先不去重保留全部候选等到优化阶段再统一做语义去重。6. 数据优化阶段从“生成数据”到“优化数据”这是整个方法的核心阶段。PROOF-Gen 强调的“优化数据”就是在这里实现的。6.1 规则过滤规则过滤是成本最低、最可靠的一层。规则可以覆盖格式、长度、关键词、逻辑一致性等多个维度。常用规则包括规则类型过滤条件示例格式规则输出必须包含“答案”缺少答案标记则丢弃长度规则推理过程长度在 20 到 1000 字之间过短说明过程缺失过长说明冗余完整性规则推理过程中每一步必须有“第x步”标记无法分步则丢弃重复规则与已有样本的重复度阈值重复度高于 0.85 则丢弃规则配置建议独立成 JSON 文件方便调试和复用{ format: { required_markers: [答案], must_not_contain: [抱歉, 我不知道] }, length: { min_chars: 50, max_chars: 2000 }, dedup: { method: minhash, threshold: 0.85 } }6.2 质量打分规则过滤只能处理显性问题。对于答案错误、推理逻辑混乱这类问题需要一个质量打分模型。常见做法是训练一个 reward model 或使用现成的评判模型对候选数据打分。打分维度可以包括推理正确性。步骤完整性。语言流畅度。答案与问题的相关性。下面是打分阶段的代码示例# scripts/score_data.py # 使用评判模型对候选数据打分 import json from transformers import pipeline def score_records(input_path, output_path, scorer): scored [] with open(input_path, r, encodingutf-8) as f: for line in f: record json.loads(line) text record[generated_text] prompt f请评估下面这段解题过程的质量从正确性、完整性、流畅度三个维度打分每个维度 1-5 分最后给出总分。\n\n{text}\n\n评估结果 result scorer(prompt, max_new_tokens128)[0][generated_text] # 解析打分结果此处只做示例实际需要按输出格式解析 record[score_text] result record[quality_score] extract_score(result) scored.append(record) with open(output_path, w, encodingutf-8) as f: for record in scored: f.write(json.dumps(record, ensure_asciiFalse) \n) scorer pipeline(text-generation, modelpath/to/judge_model) score_records(data/raw/generated.jsonl, data/scored/scored.jsonl, scorer)6.3 纠错与重写质量过滤会丢弃一部分样本但更高效的做法是对可修复的样本进行重写。比如推理过程缺少某一步可以提示教师模型补全答案格式不对可以提示教师模型重写。重写虽然增加了计算成本但能保留更多训练样本尤其在种子数据有限的情况下重写比直接丢弃更有价值。6.4 去重与多样性控制去重是数据优化里容易被忽略、但影响很大的环节。如果训练集里存在大量高度相似的样本学生模型容易过拟合到少数模式上。去重可以采用两种方式文本层面去重使用 MinHash 或 SimHash 计算文本相似度过滤相似度高于阈值的样本。语义层面去重使用 embedding 模型将文本转为向量计算向量余弦相似度过滤高相似样本。语义去重的代码示例如下# scripts/dedup.py # 基于 embedding 的语义去重 import json import numpy as np from sentence_transformers import SentenceTransformer from sklearn.metrics.pairwise import cosine_similarity model SentenceTransformer(path/to/embedding_model) def load_records(path): records [] with open(path, r, encodingutf-8) as f: for line in f: records.append(json.loads(line)) return records def dedup(records, threshold0.85): texts [r[generated_text] for r in records] embeddings model.encode(texts, show_progress_barTrue) keep_flags [True] * len(records) for i in range(len(records)): if not keep_flags[i]: continue for j in range(i 1, len(records)): if not keep_flags[j]: continue sim cosine_similarity( embeddings[i].reshape(1, -1), embeddings[j].reshape(1, -1) )[0][0] if sim threshold: keep_flags[j] False return [r for r, keep in zip(records, keep_flags) if keep] records load_records(data/scored/scored.jsonl) deduped dedup(records, threshold0.85) with open(data/optimized/optimized.jsonl, w, encodingutf-8) as f: for record in deduped: f.write(json.dumps(record, ensure_asciiFalse) \n)过滤、打分、去重这三个步骤完成后得到的就是供蒸馏训练使用的“优化数据”。7. 蒸馏训练阶段用优化数据训练学生模型7.1 训练数据格式蒸馏训练的目标是让学生模型模仿教师模型的输出。训练数据应该包含三部分输入、教师生成的推理过程、最终答案。数据格式建议使用对话模板或指令格式与基座模型的训练范式保持一致。{ instruction: 解方程3x 5 20, input: , output: 第1步将常数项移到等号右边得到 3x 20 - 5。\n第2步计算右边得到 3x 15。\n第3步两边同时除以 3得到 x 5。\n答案x 5。 }7.2 蒸馏损失蒸馏训练有两种主流损失方式第一种是序列级蒸馏。直接使用教师生成文本作为目标学生模型做标准的语言建模训练。这种方式实现简单只需要把教师输出当成 ground truth。第二种是** logit 级蒸馏**。让学生模型输出的概率分布逼近教师模型的概率分布通常用 KL 散度作为损失。这种方式需要教师模型和学生模型同时前向计算显存开销更大。PROOF-Gen 这类数据优化方法更常配合序列级蒸馏使用因为序列级蒸馏对数据和计算资源的要求更可控。以下是一个基于 Hugging Face transformers 的蒸馏训练脚本模板# scripts/distill.py # 使用优化数据训练学生模型 import json import torch from transformers import AutoTokenizer, AutoModelForCausalLM, Trainer, TrainingArguments from datasets import Dataset def load_training_data(path): records [] with open(path, r, encodingutf-8) as f: for line in f: records.append(json.loads(line)) return records def build_dataset(records, tokenizer, max_length1024): formatted [] for r in records: # 拼接指令和输出 text f用户{r[instruction]}\n\n助手{r[output]} encoded tokenizer(text, truncationTrue, max_lengthmax_length) formatted.append({ input_ids: encoded[input_ids], attention_mask: encoded[attention_mask], labels: encoded[input_ids] # 语言建模用自身作为标签 }) return Dataset.from_list(formatted) def main(): model_name path/to/student_base tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForCausalLM.from_pretrained(model_name) records load_training_data(data/optimized/optimized.jsonl) dataset build_dataset(records, tokenizer) training_args TrainingArguments( output_dir./checkpoints/student, per_device_train_batch_size2, gradient_accumulation_steps8, learning_rate2e-5, num_train_epochs3, logging_steps50, save_steps500, save_total_limit3, fp16True, report_tonone ) trainer Trainer( modelmodel, argstraining_args, train_datasetdataset ) trainer.train() if __name__ __main__: main()训练阶段要关注两个指标训练损失是否下降和验证集效果是否提升。只关注训练损失下降是不够的因为模型可能过拟合到教师输出的表达模式而没有真正学到推理能力。8. 效果验证如何判断“优化数据”真的有效8.1 验证策略PROOF-Gen 方法是否有效不能只看学生模型有没有跑通训练而要通过对照组验证“优化数据”的增量贡献。建议设计三组对比实验组训练数据目的基线组原始教师输出不过滤验证基础蒸馏效果过滤组只做规则过滤验证规则过滤的贡献优化组完整优化流程验证 PROOF-Gen 全流程贡献三组使用相同的学生初始化模型、相同的训练参数和相同的评估集保证变量唯一。8.2 评估指标评估指标要覆盖两个维度任务效果和数据质量。任务效果指标取决于目标任务数学推理准确率、步骤正确率。代码生成通过率、编译成功率。通用问答BLEU、ROUGE、人工评分。分类任务准确率、F1。数据质量维度需要统计优化前后对比过滤掉的样本占比。优化后数据的总量。训练集多样性指标。教师输出在验证集上的自洽性。8.3 人工抽检自动化指标不能完全替代人工检查。建议每个阶段抽检 50 到 100 条数据重点看推理过程是否前后一致。是否存在“看似合理但实际错误”的步骤。是否存在教师模型典型的幻觉现象。优化后数据是否丢失了某些题型的代表性样本。抽检结果可以直接作为下一轮优化规则调整的依据。9. 资源占用与性能观察9.1 数据生成阶段的资源特征数据生成阶段是计算密集型任务主要占用 GPU 算力显存占用取决于教师模型规模和推理批量大小。如果使用 vLLM 批量推理显存占用会随并发请求数增加。建议先测 1 个并发请求的显存占用再逐步增加并发数找到显存和吞吐的平衡点。9.2 数据优化阶段的资源特征规则过滤CPU 即可速度极快。质量打分需要 GPU打分模型可以是 1B 到 7B 级别的小模型。语义去重embedding 计算可以在 GPU 或 CPU 上完成主要看数据量。百万级数据建议 GPU 加速。9.3 蒸馏训练阶段的资源特征蒸馏训练的显存占用由学生模型参数量、序列长度、batch size、是否使用梯度累积等参数共同决定。建议按下面的顺序逐步调整先用 batch size 1 跑一个 step记录显存占用。逐步增加 batch size直到显存接近上限。如果显存不足优先调低序列长度或开启梯度累积而不是盲目换卡。使用nvidia-smi监控显存# 每隔 5 秒刷新一次显存使用情况 watch -n 5 nvidia-smi训练过程中建议同时关注 GPU 利用率和显存占用两个指标。GPU 利用率低但显存占用高可能是数据加载或日志写入成为瓶颈显存占用高且利用率也高才说明计算资源被有效利用。10. 常见问题与排查方法以下是在 PROOF-Gen 类似流程中常见的问题和排查思路问题现象可能原因排查方式解决方案数据生成阶段进程中断显存不足或进程被杀查看日志和dmesg调低并发数加入断点续跑生成数据大量为空或重复提示词指令不明确或 temperature 过低抽检生成结果优化提示词调高 temperature规则过滤后数据量过少过滤阈值太严格统计各规则过滤占比放宽长尾规则分阶段过滤质量打分结果不稳定打分模型对长文本不敏感对比打分与人工评审换用更强打分模型或多人评审训练损失下降但效果不提升过拟合到教师表达模式查看验证集指标增加数据多样性降低训练轮数蒸馏训练显存溢出batch size 或序列长度过大逐步降低 batch size 测试使用梯度累积或缩短 max_length批量任务卡住某个样本触发死循环或过长输出查看进程栈和日志增加单样本超时和输出长度上限模型输出质量不稳定数据噪声或推理链不完整抽样检查训练数据增加错误答案过滤和重写纠错10.1 数据生成阶段常见错误如果发现生成结果的格式不符合预期先检查提示词是否明确给出了输出格式示例。大模型对“请输出 JSON”和“请按以下格式输出 JSON”的理解差异很大显式的格式约束通常更有效。如果生成结果大量截断检查采样参数中的max_tokens是否足够覆盖推理过程的长度。数学推理的逐步推导往往会超过 512 token建议设置 1024 或以上。10.2 蒸馏训练阶段常见错误训练过程中如果 loss 出现 NaN优先检查学习率是否过大、数据中是否存在异常长文本或空文本。文本预处理阶段要把空样本、超长样本提前剔除。还有一个容易被忽略的问题教师模型使用的 tokenizer 和学生模型可能不同。如果两者 vocabulary 不一致不能直接复用教师生成的 token 序列必须统一以文本形式传递监督信号由学生模型的 tokenizer 重新编码。11. 最佳实践与使用建议11.1 先小规模跑通全流程不要第一次就在全量数据上跑。建议按以下顺序推进准备 100 条种子数据。生成 300 条候选数据。过滤后保留约 100 到 200 条优化数据。用这些数据训练一个小规模学生模型跑 1 到 2 个 epoch。验证评估流程和指标计算是否正确。全流程跑通后再翻倍扩充数据量。这样能快速暴露流程中的问题避免在数据量放大后浪费时间。11.2 数据版本管理优化数据会经历多轮迭代强烈建议做数据版本管理。最简单的做法是给每个版本加时间戳和备注data/optimized/optimized_20250101_v1.jsonl data/optimized/optimized_20250107_v2.jsonl每次过滤规则的调整都记录在 config 目录下保证“哪个版本的数据用了哪套规则”可以追溯。训练效果回退时可以直接切换到之前的数据版本复现。11.3 批量任务设计数据生成和打分都适合做批量任务。工程上建议数据生成任务按种子数据分片每个分片独立生成。打分任务按候选数据分片每个分片独立打分。每个分片的任务加入超时和失败重试。所有任务输出统一写入同一个输出目录文件名带上分片号。# 批量任务示例按分片并行生成数据 for shard in 0 1 2 3 4 5 6 7; do python scripts/generate_shard.py \ --shard $shard \ --total_shards 8 \ --seed_data ./data/seeds/seeds.jsonl \ --output ./data/raw/shard_${shard}.jsonl done wait11.4 合规与授权提醒PROOF-Gen 涉及数据生成和模型训练需要特别注意以下几点种子数据集的来源必须合法合规具有授权或开源许可。教师模型生成的数据如果用于商用需要确认模型的许可条款。如果数据涉及个人隐私、人脸信息、敏感文本必须在生成和训练前完成脱敏处理。不要在未经授权的情况下用专有数据或版权内容大规模生成训练集。教师模型输出的内容可能包含幻觉、偏见或错误信息发布前必须经过复核。11.5 全流程质量看板建议在项目初期就建立一套简单的质量看板用表格记录每轮迭代的关键指标版本种子数生成数过滤后数训练损失评估指标备注v11003001201.8262.4%初版v22008003201.6568.1%加入重写纠错v350020008601.5271.3%加入语义去重有这个看板才能判断数据优化到底是哪个环节带来了提升也才能在效果回退时快速定位变化点。12. 总结与下一步建议PROOF-Gen 这个方向最值得借鉴的地方不是某个特定的模型或损失函数而是把“数据”从静态输入升级为可优化、可验证、可迭代的中间产物。对做知识蒸馏的团队来说先别急着调损失函数把数据生成、过滤、去重这条链路搭建起来效果往往提升得更明显。建议拿到这套方法后最先验证的是规则过滤和语义去重对训练数据质量的直接影响这两个环节成本低、见效快能立刻看到数据集的干净程度变化。最容易踩的坑有两个一是数据生成阶段没有做断点续跑任务中断后前功尽弃二是只盯着训练损失下降忽略了评估集效果导致模型过拟合到教师输出的表面格式。下一步可以在现有流程上扩展三个方向引入更强的质量评判模型替代简单的规则打分。加入教师模型投票机制对同一问题多次采样用多数一致作为正确性信号。把数据优化做成在线闭环每次蒸馏训练结束后用学生模型的失败样本反哺数据生成阶段迭代生成更有针对性的训练数据。如果正在做模型蒸馏或者合成数据训练建议把 PROOF-Gen 的流程先用一个小模型完整跑一遍验证每个环节的产出和成本再考虑放大到生产环境。这篇文章讲到这里核心流程、代码模板、资源观察方法和排查清单都已经覆盖。收藏起来下次做蒸馏任务的时候可以直接对照着搭数据优化链路。