用LLM训练LLM的3个方法

我们刚刚跨越了AI的一个奇怪门槛。模型现在足够好，可以训练其他模型，而硬件栈只是勉强跟上。

1、前后对比：究竟发生了什么变化

几年前，训练一个大模型意味着一件事。你收集数据集，编写训练循环，然后祈祷你的集群不会崩溃。

现在的图景不同了。你有一个大的教师模型、合成数据流水线、跨数十或数百个GPU的分布式训练，以及必须跟上已经能写代码和推理的模型的评估系统。

有趣的部分不是炒作。而是正在固化的工程模式。

现在有三件事特别突出。

• LLM正在大规模用于训练其他LLM。
• 70B级别的模型现在是分布式训练的"合理"目标。
• 计算机视觉落后于生成式文本，这影响了你应该如何投资工程时间。

让我们以实际有用的方式拆解这些内容，如果你真的在部署模型的话。

2、LLM训练其他LLM：到底在发生什么

"LLM训练LLM"听起来像科幻小说。在实践中，它主要是数据生成和蒸馏。

核心模式是这样的。你有一个昂贵的大教师模型和一个更小、更便宜的学生模型。

教师在这个过程中不更新权重。它只是生成监督信号。

学生从教师的输出学习，而不是直接从原始人类数据学习。有时它也看到原始数据，有时不。

这以几种具体方式表现出来。

• 合成指令数据生成。
• 偏好建模和奖励建模。
• 自我对弈或自我纠正风格的训练。

如果你在流水线中使用过类似"GPT作为数据标注器"的东西，你已经在做这件事的微缩版本。

现在的区别在于规模和结构。

3、合成指令数据：你的新无限数据集

最容易理解的是合成指令微调。你从一个擅长下一个token预测的基础模型开始，想让它遵循指令。

传统上，你会收集人工编写的指令-响应对。这很慢、很贵，而且偏向于你的标注团队理解的任何东西。

现在你可以这样做。

• 使用强LLM作为生成器来创建指令和候选答案。
• 可选地使用相同或另一个LLM作为评审者来评分或过滤这些答案。
• 在这个策划的合成数据集上训练一个更小的模型。

代码中，核心循环看起来几乎无聊。

def generate_synthetic_pairs(teacher, prompts, critic=None, k=3):
    pairs = []
    for p in prompts:
        candidates = [teacher.generate(p) for _ in range(k)]
        if critic:
            scored = [(c, critic.score(p, c)) for c in candidates]
            best = max(scored, key=lambda x: x[1])[0]
        else:
            best = candidates[0]
        pairs.append({"instruction": p, "response": best})
    return pairs

这不是理论上的。今天大多数开源指令微调模型都严重依赖于大模型生成的合成数据。

实际效果是：

• 数据集创建变成了计算问题，而不是人工配置问题。
• 你可以通过生成领域特定的合成语料来为细分领域定制模型。
• 数据质量现在是教师质量、采样策略和过滤的函数，而不仅仅是原始人工策划。

风险是你最终陷入"模型近亲繁殖"循环。学生模型学习教师的怪癖，而不是底层任务。

你通过混合真实数据、使用多个教师、专注于基于真实世界任务的评估来缓解这个问题。

4、偏好学习：LLM作为裁判

用LLM训练LLM的第二大用途是偏好建模。你希望你的模型不仅正确，而且与人类偏好对齐。

人类偏好数据很贵。所以人们这样做：

• 使用强LLM作为裁判来标注两个答案中哪个更好。
• 在这些判断上训练奖励模型。
• 使用该奖励模型来微调或引导策略模型。

这个模式类似于RLHF，但标注步骤部分自动化了。教师模型成为循环中的"人类"。

用伪代码来说，标注步骤很简单。

def label_pair(judge, prompt, answer_a, answer_b):
    query = f"Prompt: {prompt}\nA: {answer_a}\nB: {answer_b}\nWhich is better, A or B?"
    verdict = judge.generate(query)
    return "A" if "A" in verdict else "B"

你永远不会原样部署它。你会用安全过滤器、一致性检查包装它，也许用多个裁判。

重要的是，监督信号不再受限于人类带宽。你可以将其扩展到数百万次比较。

这让你能比纯人类数据更快地迭代奖励模型。它也提出了明显的对齐和偏见问题，因为你的裁判不是中立的。

从工程角度来看，你应该将"LLM作为裁判"的标签视为有噪声的。使用噪声标签学习的技术，对包含多少合成偏好数据进行消融实验，并在真实人类标注的评估上测量泛化能力。

5、自我改进循环：有趣的地方

第三种模式是模型自我改进。不是以神奇的方式，而是以流水线的方式。

典型循环是这样的。

• 学生模型回答问题或解决任务。
• 教师模型批评或纠正这些答案。
• 纠正后的输出成为学生的训练数据。

你可以用思维链、工具使用或多智能体设置添加更多结构。但核心思想是"模型提议，更强的模型处置"。

这对于基础事实昂贵或难以计算的任务很有用。例如，数学推理、代码生成或多步骤规划。

风险是反馈循环。如果你的教师有系统性错误，你的学生会继承并放大它们。

所以你用外部检查来锚定这些循环。代码的单元测试、数学的符号求解器，或推理的人工抽查。

工程要点很简单。将LLM视为训练流水线中的组件，而不仅仅是你部署的端点。

6、训练一个72B参数模型真正需要什么

第二大主题是72B级别模型的训练运行。表面上它是"又一个大模型"。在实践中，它要么让基础设施工作，要么让其爆炸。

在这个规模上，你无法将模型放在单个GPU上。你需要某种组合：

• 数据并行。
• 张量或模型并行。
• 流水线并行。
• 优化器分片。

如果你使用过DeepSpeed、Megatron-LM或PyTorch FSDP等框架，你已经见过这些旋钮。

一个最小的心理模型是这样的。

• 数据并行：每个副本看到不同的批次，梯度被平均。
• 张量并行：一层被分割到多个设备上，每个设备持有权重的一部分。
• 流水线并行：不同层位于不同设备上，微批次像装配线一样流动。

在72B参数下，你通常使用所有三种。加上混合精度和激活检查点等技巧。

一个简化的PyTorch FSDP设置可能像这样。

import torch
import torch.distributed as dist
from torch.distributed.fsdp import FullyShardedDataParallel as FSDP

def init():
    dist.init_process_group("nccl")
    torch.cuda.set_device(dist.get_rank())

def build_model():
    model = My72BModel()
    return FSDP(model, use_orig_params=True)

def train_step(model, batch, optim, scaler):
    with torch.cuda.amp.autocast():
        loss = model(**batch)
    scaler.scale(loss).backward()
    scaler.step(optim)
    scaler.update()
    optim.zero_grad()

真正的工程工作不在上面的10行代码中。而在于确保系统的其余部分能跟上。

7、隐藏的痛点：数据、网络和可观察性

一旦你超出少数几个GPU，瓶颈就转移了。你开始调试集群而不是模型。

三件事通常先伤害到你。

数据流水线。如果你的输入流水线无法让GPU保持忙碌，你昂贵的硬件就在空闲。你需要在实际测试过的规模下进行分片、本地缓存和预取。

网络。梯度和参数的全归约操作如果不小心会饱和你的互连。拓扑感知放置、通信与计算重叠，以及使用正确的集合算法都很重要。

可观察性。在72B规模下，"运行10小时后崩溃了"是一个非常昂贵的错误报告。你需要每个rank的日志记录、内存、通信时间和步长时间的度量，以及将它们关联的方法。

对于许多团队来说，实际的做法是从小开始。让你的流水线在7B模型上坚如磐石，然后扩展。

如果你的7B运行有噪声，你的72B运行将是灾难性的。故障模式相同，只是更昂贵。

8、为什么计算机视觉落后于生成式文本

第三个主题是计算机视觉进展感觉比生成式文本慢。如果你习惯了LLM的节奏，视觉可能感觉停滞不前。

有几个结构性原因。

文本天然分词且可压缩。语言模型可以从互联网规模语料的下一个token预测中学到很多。

图像是具有强局部结构的高维数组。你要么大幅降采样，要么付出巨大的计算成本。

监督也不同。文本是自监督的，下一个token总是可用的标签。视觉任务如检测或分割需要标签，或者你需要非常聪明的自监督目标。

我们确实有强大的视觉骨干和模型。ConvNets、Vision Transformers、CLIP风格的对比模型，以及用于生成的扩散模型。

但是LLM经历的"一个模型统治一切"的时刻在视觉领域还没有到来。你仍然需要针对检测、分割、跟踪和生成任务的专门模型。

从工程角度来看，这很重要。你不能简单地"插入一个视觉LLM"来解决一切问题。

9、为什么这对你的路线图很重要

如果你在决定在哪里投资工程时间，文本和视觉之间的差距应该影响你的选择。

LLM现在是通用工具。你可以将它们用于数据标注、合成数据生成、代码生成，以及作为ML流水线中的组件。

视觉更分散。你通常需要特定任务的架构和数据集。

所以一个实用的策略是这样的。

使用LLM尽可能自动化你的流水线。文档、测试生成、数据清理，甚至帮助编写训练脚本。

在有明确ROI和数据的地方使用视觉模型。例如，质量检查、OCR加上布局理解，或使用CLIP风格嵌入的检索。

并密切关注多模态模型。文本加图像加代码是许多有趣工作发生的地方，但它还不像纯文本那样开箱即用。

10、今天就可以偷学的实用模式

你不需要72B集群来从这些趋势中受益。你可以从小规模采用这些模式。

几个具体的行动。

• 使用强托管LLM作为教师为你的内部小模型生成合成数据。
• 使用LLM作为裁判来引导偏好数据，然后用少量人工标签进行细化。
• 将你的训练流水线视为系统而非脚本，尽早投资于日志记录和度量。
• 对于视觉任务，将CLIP风格嵌入与LLM配对来构建搜索或分析工作流，而不是从头开始训练单一的视觉模型。

你可以用开源模型、云GPU和标准工具完成所有这些。关键是将模型视为组件，而不是单体。

11、最后的思考

"LLM训练其他LLM"这个标题听起来像营销。下面的现实更有趣也更有用。

我们正在悄悄地从以人类为中心的监督转向以模型为中心的监督。我们正在构建训练流水线，其中模型生成、评判和优化训练其他模型的数据。

与此同时，硬件和软件栈只是勉强为非超大规模团队提供70B级别的模型支持。如果你理解分布式训练并能保持集群运行，你就有杠杆。

在视觉领域，故事不同。进展是真实的，但它不像文本那样统一或通用。

如果你是工程师，机会是明确的。学习如何连接模型，而不仅仅是调用它们。

将LLM视为基础设施而不仅仅是API的团队，将拥有下一波实用AI系统。

原文链接：The End of Hand-Curated Datasets? Inside LLMs Training LLMs at Scale

汇智网翻译整理，转载请标明出处