大模型蒸馏实战：用小模型逼近闭源模型能力的工程流程

这两天 AI 社区里流传最多的一份文档，是一篇 116 页的论文，主题不是某个新模型发布，而是“蒸馏”。论文标题直接点到了 Claude、GPT 这些闭源大模型，配合“女娲造人 skill”“蒸馏自己”“Claude Code 本地部署”这些讨论，很多人都在问：是不是真的可以拿闭源模型当老师，蒸馏出一个自己的小模型？是不是能放在本地跑？要不要先学会 Claude Code？

先说结论：模型蒸馏本身不是新概念，Hinton 早在 2015 年就把“知识蒸馏”讲明白了，它的核心是用大模型（老师）的输出，去教一个小模型（学生）达到接近的效果。但这篇 116 页的论文之所以引起讨论，是因为它把蒸馏讲得更像一套可操作的工程流程：怎么生成数据、怎么清洗、怎么用软标签训练、怎么评估学生的能力，而不是停在公式和概念层面。

这篇文章我会从工程角度拆解蒸馏这件事。先讲核心能力和适用边界，再给出一套可以在本地跑通的蒸馏实验流程，包括环境准备、数据生成、软标签训练、显存观察、API 调用和批量任务示例。如果你关心的是“我能不能拿一个开源小模型，学出更好的效果”，这篇文章可以直接收藏。

有一点要先说明：论文标题里提到的模型名称，是否对应某个已经公开的具体版本，需要以实际发布的官方信息为准。我更建议把注意力放在蒸馏方法论上，因为方法本身是可以迁移的。

1. 核心能力速览

能力项	说明
项目类型	论文 / 技术方法论，围绕大模型知识蒸馏，属于 AI 模型压缩与能力迁移方向
核心技术	知识蒸馏、软标签、温度系数、数据增强、小模型微调
主要功能	用大模型生成高质量数据，训练小模型；降低推理成本；提升小模型专项能力
推荐硬件	常见做法是准备一块 8G 及以上显存的 GPU；纯 CPU 可以做数据生成，但训练小模型会偏慢
显存占用	取决于学生模型规模和 batch size，实际占用需按本机测试为准
支持平台	通用 Python 环境，Windows / Linux / macOS 均可；训练密集任务推荐 Linux 服务器
启动方式	非一键包，需要命令行或脚本启动，可分为数据生成、训练、评估三个阶段
是否支持 API	需要调用模型 API 生成蒸馏数据时，可复用 OpenAI / Claude / 其他兼容接口
是否支持批量任务	支持，建议用脚本 + 多线程或队列方式批量生成数据，并增加失败重试
适合场景	小模型专项能力提升、推理成本压缩、离线部署、垂直场景定制、教学实验

这里要强调一句：蒸馏闭源模型的结果能用多少，取决于数据质量、学生模型容量和合规边界。工具链可以跑通，但不代表可以随意拿某个闭源模型的输出去训练商用模型。

2. 蒸馏的适用场景与使用边界

2.1 适合谁

蒸馏适合三类人。

第一类是有垂直场景需求的开发者。你不想每次都调用大模型 API，希望模型能在没有网络的服务器上跑，延迟低、成本低。这时候用一个 1B 到 7B 的开源小模型，配合蒸馏数据和微调，可以接近大模型在特定任务上的表现。

第二类是做模型部署和成本优化的工程师。同一个任务，直接用闭源模型接口按 token 计费，量大了成本很高。如果蒸馏出的小模型能在本机或私有云上顶住 80% 的请求，整体预算能降下来。

第三类是研究和小白学习者。蒸馏是一套理解大模型能力边界的好实验。你可以亲手做一个“老师模型 + 学生模型”的蒸馏流程，观察温度系数、数据量、学生模型规模对最终效果的影响。

2.2 不适合谁

如果你以为“读完这篇论文就能把 Claude 完全复制到本地”，那大概率会失望。原因有三点：

• 闭源模型的权重不公开，你只能拿到输出样例，拿不到完整的内部表示。
• 蒸馏出来的学生模型效果高度依赖任务范围和训练数据覆盖度，无法做到全能力复制。
• 很多模型的官方服务条款对输出数据再训练有限制，商用前必须确认授权。

2.3 版权、隐私与合规边界

这是蒸馏实践中最容易被忽视的部分。

使用公开 API 生成训练数据，首先要检查该 API 的服务条款是否允许将输出用于模型训练。不同模型商的政策不完全一样，有的明确禁止，有的需要额外授权。尤其是涉及人脸、声音、版权文字和私有数据时，必须确认是否有合法授权。

不要把蒸馏思路用于绕过付费限制、破解访问控制、模拟他人身份、生成违规内容。技术讨论归技术讨论，实际使用时要在合法合规的测试环境里验证，不要上来就拿线上真实数据跑蒸馏。

3. 模型蒸馏的基础原理与论文阅读思路

3.1 什么是知识蒸馏

知识蒸馏的核心思想是迁移能力。

训练一个学生模型时，我们不只用真实标签，还使用老师模型输出的概率分布。老师模型在某个输入上不会只说“答案是 A”，而是会输出“A 的概率 0.7，B 的概率 0.2，C 的概率 0.1”，这就是软标签。软标签里包含的信息比硬标签更多：比如对某个问题，B 和 C 可能非常接近，这种相似性就是老师带出来的隐藏知识。

为了让软标签更“软”，蒸馏里还会引入温度系数 T。温度越高，输出的概率分布越平滑，小模型更容易学到类别之间的相似关系。训练时，学生模型同时对齐真实标签和老师模型的软标签，目标函数通常是真实标签的交叉熵加上软标签的 KL 散度。

3.2 116 页论文该怎么读

拿到一份 116 页的蒸馏论文，不要从头逐字啃。先按下面这个顺序看：

1. 摘要和结论：判断论文主要贡献是什么，是提出了新的蒸馏框架，还是某类任务的蒸馏实践。
2. 实验设置：看用了什么老师模型、什么学生模型、什么数据集。
3. 数据生成部分：看作者是如何组织输入输出，如何处理错误输出。这一部分往往是工程落地价值最高的。
4. 训练细节：学习率、batch size、训练步数、是否用了 LoRA。
5. 评估方法：看学生模型最终是用什么指标评价的。

从标题信息看，这份论文很可能覆盖了从数据到训练再到评估的完整流程，所以上述读法会比逐页阅读更快定位关键内容。

3.3 蒸馏时的关键变量

亲手做蒸馏实验时，至少要盯住四个变量：

• 数据量：蒸馏数据太少，学生模型学不到稳定规律；数据太多，成本高。建议先从小批量开始观察收益曲线。
• 温度系数 T：经典初始化是 1.0，但实际任务里可能需要调整到 2.0 到 5.0，要看预测分布的平滑程度。
• 学生模型容量：不是容量越大越好，容量过大容易过拟合老师输出里的噪声，容量过小表达能力不足。
• 数据质量：老师模型虽然强，但也会犯错。直接拿原始输出训练，会把错误也学进去。这一步要做数据清洗和结果过滤。

4. 环境准备与前置条件

下面是一套可落地的本地蒸馏实验环境，你可以根据实际设备裁剪。

4.1 基础环境

建议使用 Python 3.10 或以上版本，配合 conda 或 venv 创建独立环境，避免依赖冲突。

conda create -n distill python=3.10 -y conda activate distill

4.2 安装训练依赖

小模型微调和蒸馏可以用 Hugging Face Transformers + PyTorch 完成。

pip install torch transformers datasets accelerate peft bitsandbytes

如果显存紧张，可以额外安装flash-attn或使用bitsandbytes的 4bit / 8bit 量化加载学生模型。

4.3 安装 API 调用依赖

如果你需要调用闭源模型生成蒸馏数据，需要安装openai或对应模型服务的 Python SDK。

pip install openai requests

注意：接口地址、模型名、密钥都要按你实际使用的服务商说明填写。不同服务的base_url可能不同，不要照搬。

4.4 GPU 检查

训练前先确认 CUDA 和显卡驱动可用。

import torch print(torch.__version__) print(torch.cuda.is_available()) print(torch.cuda.get_device_name(0) if torch.cuda.is_available() else "CPU only")

如果torch.cuda.is_available()返回 False，优先排查驱动版本和 PyTorch 是否匹配当前 CUDA 版本。常见做法是安装对应 CUDA 版本的 PyTorch，而不仅仅是系统里装过 CUDA。

4.5 端口与进程

蒸馏实验不像 WebUI 服务那样依赖端口，但如果你用 Jupyter Notebook 或启动本地 API 服务，要注意端口占用。启动失败时优先检查端口是否被其他进程占用：

lsof -i:7860

如果端口被占用，换一个端口运行即可。

5. 蒸馏实验完整流程

这一部分从零开始，演示一个完整的蒸馏实验。目的不是跑出论文级别的数据，而是把“蒸馏”变成可以亲手验证的流程。

整个流程分为四个阶段：数据生成、数据处理、训练学生模型、评估效果。

5.1 准备种子任务集

先准备一组任务。这里以文本问答为例，种子数据不需要很大，50 条就足够做第一轮实验。每条数据包含instruction和input。

保存为seed_data.jsonl：

{"instruction": "用一句话解释什么是数据库索引", "input": ""} {"instruction": "写一个 Python 函数判断字符串是否是回文", "input": ""} {"instruction": "把下面这句话翻译成英文：今天天气很好", "input": ""}

这组种子数据是蒸馏的起点。关键是任务范围要明确，不要一开始就铺一个泛到不行的“AGI 数据集”。

5.2 用老师模型生成蒸馏数据

接下来调用大模型 API，为每条种子任务生成高质量输出。这一环节要注意三点：温度不要太高，建议 0.7 以内；增加角色提示让模型输出“适合教学”的答案；保留原始输出，后续清洗用。

import openai import json client = openai.OpenAI( api_key="YOUR_API_KEY", base_url="YOUR_API_BASE_URL" ) def generate_answer(instruction, input_text=""): response = client.chat.completions.create( model="YOUR_TEACHER_MODEL", messages=[ { "role": "system", "content": "你是一个高质量教学助手。请给出准确、清晰、结构完整的回答。" }, { "role": "user", "content": f"任务：{instruction}\n输入：{input_text}" } ], temperature=0.6, max_tokens=1024 ) return response.choices[0].message.content with open("seed_data.jsonl", "r", encoding="utf-8") as f: lines = f.readlines() results = [] for idx, line in enumerate(lines): item = json.loads(line) answer = generate_answer(item["instruction"], item.get("input", "")) results.append({ "instruction": item["instruction"], "input": item.get("input", ""), "output": answer }) print(f"[{idx + 1}/{len(lines)}] generated") with open("distill_data_raw.jsonl", "w", encoding="utf-8") as f: for r in results: f.write(json.dumps(r, ensure_ascii=False) + "\n")

说明：上面的YOUR_API_KEY、YOUR_API_BASE_URL、YOUR_TEACHER_MODEL是占位符，必须替换成你自己有权限访问的服务配置。不要使用不明来源的代理接口。

5.3 清洗蒸馏数据

老师模型的输出不全是可用的。常见的清洗手段包括：

• 删除空输出和明显截断的输出。
• 删除包含敏感、隐私、版权风险的内容。
• 对同一问题生成多次，选择稳定的答案。
• 长度过短或过长的数据做人工抽查。
• 在商用前，至少对 10% 到 20% 的数据做人工抽验。

清洗脚本示例：

import json def clean_output(text: str) -> str: if not text: return None text = text.strip() if len(text) < 10: return None return text results_clean = [] with open("distill_data_raw.jsonl", "r", encoding="utf-8") as f: for line in f: item = json.loads(line) output = clean_output(item.get("output", "")) if output is None: continue results_clean.append({ "instruction": item["instruction"], "input": item.get("input", ""), "output": output }) with open("distill_data_clean.jsonl", "w", encoding="utf-8") as f: for r in results_clean: f.write(json.dumps(r, ensure_ascii=False) + "\n") print(f"clean data count: {len(results_clean)}")

这一步绝不能省。数据质量直接决定学生模型最终效果，垃圾进垃圾出。

5.4 训练学生模型

学生模型建议从开源小模型起步，比如 Qwen、Llama、Gemma 的 0.5B 到 3B 版本。不要一上来就选 7B 以上，先跑通流程，再升级模型规模。

下面是一个用 Hugging FaceTrainer微调的简化脚本。实际训练时，你需要根据学生模型类型完善分词器填充逻辑和模板。

import torch from transformers import ( AutoTokenizer, AutoModelForCausalLM, Trainer, TrainingArguments ) model_name = "Qwen/Qwen2.5-0.5B-Instruct" tokenizer = AutoTokenizer.from_pretrained(model_name) model = AutoModelForCausalLM.from_pretrained( model_name, torch_dtype=torch.bfloat16 if torch.cuda.is_available() else torch.float32, device_map="auto" ) train_texts = [] with open("distill_data_clean.jsonl", "r", encoding="utf-8") as f: for line in f: item = json.loads(line) text = f"任务：{item['instruction']}\n输入：{item['input']}\n回答：{item['output']}" train_texts.append(text) train_prompts = tokenizer( train_texts, truncation=True, padding="max_length", max_length=512, return_tensors="pt" ) args = TrainingArguments( output_dir="./student_model", per_device_train_batch_size=2, gradient_accumulation_steps=4, num_train_epochs=3, learning_rate=5e-5, fp16=False, bf16=torch.cuda.is_available(), save_steps=500, logging_steps=10, report_to="none" ) trainer = Trainer( model=model, args=args, train_dataset=train_prompts.dataset ) trainer.train() trainer.save_model("./student_model_final")

这里给的是 CausalLM 的通用写法。跑之前要确认数据集格式和分词器能正确处理，尤其是padding和truncation设置。

5.5 软标签蒸馏方式

如果你不想只做普通微调，而是真正做经典的知识蒸馏，就需要让老师模型输出软标签。做法通常是取老师模型最后一层 logits，除以温度 T，再做 softmax，得到概率分布，然后与学生模型的 logits 计算 KL 散度。

伪代码流程：

import torch import torch.nn.functional as F T = 2.0 teacher_logits = get_teacher_logits(input_ids) # 具体实现按模型接口调整 student_logits = get_student_logits(input_ids) teacher_probs = F.softmax(teacher_logits / T, dim=-1) student_probs_log = F.log_softmax(student_logits / T, dim=-1) loss = F.kl_div( student_probs_log, teacher_probs, reduction="batchmean" ) * (T * T)

这里T * T是蒸馏论文里的常见缩放，为了平衡温度带来的梯度尺度变化。如果你想更省资源，也可以用老师输出文本作为目标做序列生成蒸馏，也就是把蒸馏数据当普通训练语料来微调。两种方式的核心差别在于：是否保留概率分布信息。

5.6 评估学生模型

训练完成后要评估，不能只看 loss 下降。评估可以从三个维度做：

• 任务正确率：准备一批老师模型没见过的测试问题，看学生模型能否答对。
• 输出稳定性：多次采样，看结果是否稳定、是否频繁出现截断或重复。
• 与老师模型对比：把学生输出和老师输出放一起，人工或让评估模型打分。

下面是一个简易评估脚本，调用本地学生模型回答测试问题：

from transformers import pipeline pipe = pipeline( "text-generation", model="./student_model_final", tokenizer="./student_model_final" ) test_question = "写一个 Python 函数判断字符串是否是回文" result = pipe( f"任务：{test_question}\n输入：\n回答：", max_new_tokens=256, do_sample=True, temperature=0.3 ) print(result[0]["generated_text"])

注意：pipeline对模型输出格式要求较高，如果结果异常，先检查学生模型是否真正完成了保存。

6. 接口 API 调用与批量任务

蒸馏实验真正进入工程化阶段，会遇到两个问题：一是大量数据生成，二是批量微调任务。这两块都需要脚本化和队列化。

6.1 批量生成数据

建议把待生成的图片或文本输入放在一个目录里，脚本遍历目录，逐条调用 API 生成数据，并输出到指定目录。

目录结构示例：

data/ input/ 001.jsonl 002.jsonl output/ raw/ cleaned/ logs/ generate_001.log

批量任务脚本需要重点处理两类问题：超时和部分失败。API 调用往往会因为网络超时、限流、上下文过长而失败，所以要对单条任务做 try-except，并把失败任务单独落盘。

import openai import json import time import os client = openai.OpenAI(api_key="YOUR_API_KEY", base_url="YOUR_API_BASE_URL") def process_one(instruction: str, input_text: str) -> str: resp = client.chat.completions.create( model="YOUR_TEACHER_MODEL", messages=[ {"role": "system", "content": "你是一个高质量教学助手。"}, {"role": "user", "content": f"任务：{instruction}\n输入：{input_text}"} ], temperature=0.6, max_tokens=1024, timeout=60 ) return resp.choices[0].message.content def wait_and_retry(instruction: str, input_text: str, retries: int = 3): for attempt in range(retries): try: return process_one(instruction, input_text) except Exception as e: print(f"attempt {attempt + 1} failed: {e}") time.sleep(5) raise RuntimeError("retry exhausted") input_dir = "./data/input" output_dir = "./data/output/raw" os.makedirs(output_dir, exist_ok=True) for filename in os.listdir(input_dir): if not filename.endswith(".jsonl"): continue with open(os.path.join(input_dir, filename), "r", encoding="utf-8") as f: items = [json.loads(line) for line in f] outputs = [] for item in items: ans = wait_and_retry(item["instruction"], item.get("input", "")) outputs.append({"instruction": item["instruction"], "input": item.get("input", ""), "output": ans}) out_path = os.path.join(output_dir, filename) with open(out_path, "w", encoding="utf-8") as f: for o in outputs: f.write(json.dumps(o, ensure_ascii=False) + "\n") print(f"processing {filename} done, count={len(outputs)}")

6.2 批量训练任务

训练阶段如果要实验多个学生模型或多种超参数，不要手动一次次跑。建议写一个参数列表，循环启动训练脚本，每次把输出目录分开。

python train_student.py --model Qwen/Qwen2.5-0.5B-Instruct --data distill_data_clean.jsonl --output ./experiments/exp1 python train_student.py --model Qwen/Qwen2.5-0.5B-Instruct --data distill_data_clean.jsonl --output ./experiments/exp2 --epochs 5

在train_student.py内部，把--epochs、--learning_rate、--batch_size都做成参数传入，方便自动化批量实验。

6.3 失败重试和日志

批量任务卡住是常见坑。建议：

• 每条任务写入日志，记录开始时间、结束时间、耗时。
• 失败任务单独放在failed目录，下次只重跑失败任务。
• 单条任务设置超时时间，避免一个错误请求卡住整个队列。
• 大批量任务先跑 10 条观察稳定性，再放全量。

7. 资源占用与性能观察

蒸馏实验的资源占用主要体现在两个阶段：数据生成阶段和模型训练阶段。

7.1 数据生成阶段

如果调用云端 API，本机资源占用很小，主要消耗是网络带宽和 token 配额。如果只是整理和处理数据，CPU 就能扛住。

7.2 训练阶段

显存占用主要由三部分构成：模型权重、优化器状态、中间激活值。具体数字和模型参数量、batch size、序列长度、是否梯度累积、是否量化相关，不能给出一个通用固定值。

建议观察方式：

nvidia-smi -l 1

训练时可以开另一个终端执行这条命令，实时观察显存变化。如果看到显存接近满载，就调小per_device_train_batch_size，或者开启gradient_accumulation_steps来稳住有效 batch size。

7.3 降低资源占用的方法

显存不足时按顺序尝试这几招：

1. 减小per_device_train_batch_size到 1。
2. 开启gradient_accumulation_steps，比如设为 8。
3. 使用bitsandbytes4bit 量化加载模型。
4. 缩短max_length，比如从 1024 降到 512。
5. 换更小的学生模型，比如从 3B 降到 0.5B。
6. 使用 LoRA 微调，而不是全量微调。

使用 LoRA 时，peft库可以帮上忙：

from peft import LoraConfig, get_peft_model lora_config = LoraConfig( r=8, lora_alpha=16, target_modules=["q_proj", "k_proj", "v_proj", "o_proj"], lora_dropout=0.05, ) model = AutoModelForCausalLM.from_pretrained(...) model = get_peft_model(model, lora_config) model.print_trainable_parameters()

注意：target_modules会因模型结构不同而变化，需要查看实际模型的模块名，不能直接套用到所有模型。

7.4 端口冲突和进程残留

如果你还会启动本地 API 或 Jupyter，训练中断后要检查是否有残留进程占用显存。推荐用：

nvidia-smi

查看占用显存的进程 PID，然后按需结束。

kill -9 PID

结束进程前确认不影响其他任务。

8. 常见问题与排查方法

问题现象	可能原因	排查方式	解决方案
API 调用报 key 错误	API Key 配置错误或权限不足	检查环境变量和代码里的 key	重新配置正确的 key，确认账号有模型访问权限
数据生成超时	网络不稳定或 max_tokens 过长	查看日志里的 timeout 信息	缩短单次 max_tokens，增加重试次数，降低并发
训练时显存不足 OOM	batch size 过大或模型过大	nvidia-smi 观察显存占用	调小 batch size，开启梯度累积，使用量化或 LoRA
torch.cuda.is_available() 返回 False	PyTorch 与 CUDA 驱动不匹配	检查torch.version.cuda和nvidia-smi	安装匹配的 PyTorch CUDA 版本
学生模型输出重复或乱码	数据格式问题或温度设置不合适	查看生成 prompt 和采样参数	降低 temperature，增加训练轮次，检查 tokenizer 填充
训练 loss 下降但效果差	数据分布和评测任务分布不一致	检查训练集合测试集分布	增加任务多样性，扩充数据，清洗低质量输出
批量任务中途卡住	单条请求卡死或没有超时控制	检查日志最后一条耗时	给请求加 timeout，失败任务单独落盘，重跑失败项
模型输出包含截断内容	max_tokens 设置太小	查看输出末尾是否不完整	调大 max_tokens，或清洗时截掉不完整样本
端口被占用	已有服务占用端口	使用lsof -i:端口号查看	更换端口或停止占用进程

9. 蒸馏工程化的最佳实践

9.1 先小后大，先测后量

第一次跑蒸馏，不要直接准备十万条数据。先用 50 条种子数据，生成 200 到 500 条蒸馏数据，训练一个小模型，跑通评估流程。确定流程没问题后，再扩大到完整数据集。

9.2 保留最小可运行配置

把一整套能跑通的最小配置记录下来，包括：

• 学生模型名称。
• 数据文件格式。
• 训练脚本参数。
• 评估 prompt。
• API 调用限额。

下次换任务时，基于这套配置做增量修改。

9.3 分目录管理数据

输入数据、原始输出、清洗后数据、训练日志、模型权重要分目录存放。命名规则要包含日期和实验标识，例如20250107_qwen05_exp1。这样版本对比和回溯都会容易很多。

9.4 批量任务必须加日志和重试

大批量数据生成时，不要只打印进度条。每条任务记录日志，失败任务单独落盘。正确做法是：任务完成后，统计成功数、失败数和平均耗时。只有达到预期才进入训练阶段。

9.5 接口服务限制访问范围

如果你把蒸馏数据生成做成一个 HTTP 接口，要限制访问范围，不要暴露到公网。建议在127.0.0.1监听，并给接口加上基础鉴权。

9.6 涉及人脸、声音、版权素材必须确认授权

这一点放到任何环节都不能忘。蒸馏过程中如果涉及用户数据、人脸照片、语音、版权文本，必须确认这些数据有再训练和再发布的授权。否则即使技术跑通，风险也不会消失。

9.7 商用前做效果复核

学生模型上线前，至少要人工抽验一批输出结果。不能只看离线指标，要看真实业务场景里的表现。特别要关注输出里是否有偏见、有害内容、版权内容和个人信息。

10. 总结与下一步

这篇 116 页论文最值得关注的地方，是把模型蒸馏从理论推到了工程流程。哪怕你没有完整读完，也可以抓住一条主线：老师模型生成数据、清洗数据、微调学生模型、评估效果。这套流程拿到任何小模型上都能跑通。

最先要验证的功能，不是直接蒸馏某个闭源模型，而是先从开源模型开始做一轮最小实验。用 Qwen 0.5B 做学生，用你本地能访问到的模型接口当老师，生成 200 条数据，微调训练，测试 5 到 10 个问题，观察效果有没有提升。这个过程会一次性验证你的环境、数据格式、训练脚本和评估流程是否可靠。

最容易踩的坑有两个：一个是数据质量差，没清洗就直接训练；另一个是显存不足时报错就放弃，完全没想过调 batch size 或换 LoRA。这两个坑都是工程问题，不是算法问题，提前安排好就能避开。

后续可以继续扩展的方向，建议按这个顺序来：先把基础蒸馏流程跑通，再尝试用软标签做真正的概率蒸馏；接着引入 LoRA 降低训练成本；然后尝试多任务蒸馏，看看一份数据能否让学生模型同时学会代码、翻译和问答；最后再把蒸馏好的模型封装成 API 服务，接进自己的工具链。

如果你想跟最近社区里那些讨论对齐，比如 Claude Code 本地部署、用 skill 蒸馏自己的知识、把一本书蒸馏进知识库，本质上都要回到同一件事：数据组织和模型微调。先把这里的基础实验跑一遍，再去做那些复杂场景，会顺很多。建议收藏备用，后续需要时直接按流程操作。