我们刚刚跨越了AI的一个奇怪门槛。模型现在足够好可以训练其他模型而硬件栈只是勉强跟上。1、前后对比究竟发生了什么变化几年前训练一个大模型意味着一件事。你收集数据集编写训练循环然后祈祷你的集群不会崩溃。现在的图景不同了。你有一个大的教师模型、合成数据流水线、跨数十或数百个GPU的分布式训练以及必须跟上已经能写代码和推理的模型的评估系统。有趣的部分不是炒作。而是正在固化的工程模式。现在有三件事特别突出。LLM正在大规模用于训练其他LLM。70B级别的模型现在是分布式训练的合理目标。计算机视觉落后于生成式文本这影响了你应该如何投资工程时间。让我们以实际有用的方式拆解这些内容如果你真的在部署模型的话。2、LLM训练其他LLM到底在发生什么LLM训练LLM听起来像科幻小说。在实践中它主要是数据生成和蒸馏。核心模式是这样的。你有一个昂贵的大教师模型和一个更小、更便宜的学生模型。教师在这个过程中不更新权重。它只是生成监督信号。学生从教师的输出学习而不是直接从原始人类数据学习。有时它也看到原始数据有时不。这以几种具体方式表现出来。合成指令数据生成。偏好建模和奖励建模。自我对弈或自我纠正风格的训练。如果你在流水线中使用过类似GPT作为数据标注器的东西你已经在做这件事的微缩版本。现在的区别在于规模和结构。3、合成指令数据你的新无限数据集最容易理解的是合成指令微调。你从一个擅长下一个token预测的基础模型开始想让它遵循指令。传统上你会收集人工编写的指令-响应对。这很慢、很贵而且偏向于你的标注团队理解的任何东西。现在你可以这样做。使用强LLM作为生成器来创建指令和候选答案。可选地使用相同或另一个LLM作为评审者来评分或过滤这些答案。在这个策划的合成数据集上训练一个更小的模型。代码中核心循环看起来几乎无聊。def generate_synthetic_pairs(teacher, prompts, criticNone, k3): 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, keylambda 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 fPrompt: {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_paramsTrue) 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系统。原文链接用LLM训练LLM的3个方法 - 汇智网
用LLM训练LLM的3个方法
发布时间：2026/5/19 11:56:17
我们刚刚跨越了AI的一个奇怪门槛。模型现在足够好可以训练其他模型而硬件栈只是勉强跟上。1、前后对比究竟发生了什么变化几年前训练一个大模型意味着一件事。你收集数据集编写训练循环然后祈祷你的集群不会崩溃。现在的图景不同了。你有一个大的教师模型、合成数据流水线、跨数十或数百个GPU的分布式训练以及必须跟上已经能写代码和推理的模型的评估系统。有趣的部分不是炒作。而是正在固化的工程模式。现在有三件事特别突出。LLM正在大规模用于训练其他LLM。70B级别的模型现在是分布式训练的合理目标。计算机视觉落后于生成式文本这影响了你应该如何投资工程时间。让我们以实际有用的方式拆解这些内容如果你真的在部署模型的话。2、LLM训练其他LLM到底在发生什么LLM训练LLM听起来像科幻小说。在实践中它主要是数据生成和蒸馏。核心模式是这样的。你有一个昂贵的大教师模型和一个更小、更便宜的学生模型。教师在这个过程中不更新权重。它只是生成监督信号。学生从教师的输出学习而不是直接从原始人类数据学习。有时它也看到原始数据有时不。这以几种具体方式表现出来。合成指令数据生成。偏好建模和奖励建模。自我对弈或自我纠正风格的训练。如果你在流水线中使用过类似GPT作为数据标注器的东西你已经在做这件事的微缩版本。现在的区别在于规模和结构。3、合成指令数据你的新无限数据集最容易理解的是合成指令微调。你从一个擅长下一个token预测的基础模型开始想让它遵循指令。传统上你会收集人工编写的指令-响应对。这很慢、很贵而且偏向于你的标注团队理解的任何东西。现在你可以这样做。使用强LLM作为生成器来创建指令和候选答案。可选地使用相同或另一个LLM作为评审者来评分或过滤这些答案。在这个策划的合成数据集上训练一个更小的模型。代码中核心循环看起来几乎无聊。def generate_synthetic_pairs(teacher, prompts, criticNone, k3): 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, keylambda 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 fPrompt: {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_paramsTrue) 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系统。原文链接用LLM训练LLM的3个方法 - 汇智网
