我最早看到“35B干赢万亿参数大模型上交大AI开始给自己造题还能自我迭代了”这个标题时第一反应是这到底是营销话术还是行业真的开始换打法了放在两年前参数规模几乎等于模型能力的代名词。谁训练了更大的模型谁就掌握了更多“智能”。但这两年越来越多的研究开始指向一个反直觉的结论在特定任务、特定成本约束下一个 35B 参数的模型确实有可能在效果上逼近甚至超过一个万亿参数模型。关键不在“少参数”而在它怎么设计数据、怎么构造问题、怎么持续迭代。“自己给自己造题”这个说法听起来像玄学实际上去对应了大模型技术里一个很接地气但极其重要的工程方向合成数据、自指令生成、自我对弈、以及模型自我迭代。这个概念不是某个团队独有而是从 Self-Instruct、Self-Play 一路延伸下来的方法论。只是在过去它更多被用在强化学习和机器人控制里而现在它成了大模型训练的新主线之一。这篇文章我想从技术演变的逻辑、可落地的工程路径、以及最容易踩坑的地方三个层面展开聊聊这类“小参数 自我迭代”方案的真实价值以及它到底适合谁、不适合谁。1. 参数规模的神话为什么会开始松动1.1 万亿参数的吸引力与代价万亿参数模型之所以让人兴奋是因为它确实打开了很多原本做不了的事。更大的参数量意味着更强的记忆能力、更复杂的模式拟合能力以及更好的跨任务泛化潜力。我们过去看到的很多“智能涌现”都建立在足够大的模型规模之上。但万亿参数并不等于零成本。训练一个万亿参数模型需要成千上万张 GPU、数月时间、海量数据清洗治理以及一个能处理分布式训练崩溃的工程团队。更麻烦的是推理成本即便是 16-bit 或 8-bit 部署每次请求都要经过数千亿甚至万亿参数的前向传播延迟、显存、带宽、能耗都随之上涨。更隐蔽的问题是参数规模的边际收益正在递减。当模型已经具备基本语言能力和推理能力后继续增加参数量真正提升的往往不是“核心智能”而是对训练数据中细节模式的记忆和复述。换句话说大模型可能不是更聪明而是记得更多。1.2 小模型跑赢大模型靠的不是魔法而是任务收敛“35B 干赢万亿参数”如果属实最可能出现的场景是垂直任务、特定基准或受限领域。这不是说小模型在通用能力上已经全面碾压大模型而是说小模型在一个定义清晰的评价体系里通过更聚焦的数据分布做到了更高的“任务命中率”。我理解这背后的原理很像考试万亿参数模型像一个博览群书但没针对这张卷子专门复习的人35B 模型则像一个只研究考纲和真题集的人。如果考试范围固定、评分规则明确后者完全可能考出更高分数。但它换一张卷子、换一个开放性问题可能又会被前者拉开差距。所以这里要先彻底丢掉“单挑”的心态。小模型跑赢大模型赢的是一个场景、一套评估标准、一类数据分布而不是全维度能力。1.3 “干赢”不等于全面超越标题里“干赢”这个词很有煽动力但落到工程上我们必须追问几个问题用的是哪个评测基准是公开榜单还是自己构建的业务测试集评测任务是什么是推理、编程、数学、客服还是多轮对话成本口径是什么训练成本、推理成本、延迟、吞吐还是端到端运维成本评测是单次结果还是多次采样后的稳定性如果这些条件不写清楚“35B 干赢万亿参数”就只是一个无法被验证的判断。我更愿意把它理解成在算力和数据双重约束下小而精的模型配合自我迭代数据流水线可以在某些任务上实现“以弱胜强”。注意看见类似标题时第一步不是相信结论而是找出它的评测边界。没有边界的能力对比本质上没有工程参考价值。2. “自己给自己造题”到底是什么机制2.1 从 Self-Instruct 到合成数据流水线“自己给自己造题”如果用技术语言翻译就是让模型基于自身已学会的知识生成新的指令、输入、输出或思维链再通过筛选和打分把这些数据投入下一轮训练。这个方法的前身是 Self-Instruct。它的核心思想很简单先用少量人工种子指令让模型生成更多指令和回答然后过滤低质量内容再用这份扩展后的数据微调模型。这样循环几轮模型就能在指令跟随能力上逐渐变强。后来这个方法被扩展到多个方向生成思维链数据让模型学会逐步推理生成偏好对用于 DPO 或 RLHF 训练生成问题分解路径提升 Agent 的任务规划能力让两个不同模型互相出题、互相评价形成对抗式进化。这些做法本质上都是“自问自答 外部筛选”的组合。2.2 模型不再只是学习者也变成出题人传统训练流程里人类负责设计问题模型负责学习答案。人类是出题人模型是解题人。自我迭代思路把角色改变了模型先当出题人自己生成问题再当解题人自己给出回答然后让评审模块打分最后把高分样本作为新训练数据。这个循环的最大价值是突破了人工数据生产的瓶颈。人工写指令、标注答案、构造思维链成本高且天花板低。模型生成方案虽然会夹杂噪声但胜在规模和多样性。当然太依赖模型自产数据也有风险。如果出题人本身只会做一类题它生成的题目就会越来越单一。怎么办要靠外部信号来对冲人工规则、知识库、代码执行结果、真实用户反馈、独立的打分模型。这些外部信号相当于给“自问自答”加了一个裁判避免模型自嗨。2.3 迭代闭环生成、筛选、训练、评估、再来一轮一个完整的自我迭代闭环至少包含以下几个环节采样一组高质量种子任务或种子数据由当前模型生成候选答案、候选题目或候选思维链使用规则过滤、模型打分、人工抽查等方式筛选把筛选后的数据拼入训练集做一轮 SFT、DPO 或 RLHF在固定的验证集和业务评测集上对比新旧版本如果效果提升保存新版本进入下一轮如果没提升回退并调整数据生成策略。这个流程并不神秘真正难的是每个环节的“质量门槛”怎么设。生成多少条过滤阈值是多少打分的 prompt 怎么设计人工抽查比例是多少不同任务的答案对错怎么判断这些参数直接决定迭代会不会退化。2.4 为什么这条路对小模型尤其友好小模型参数少训练相对快单次实验成本低这使它天然适合高频迭代。你可以今天跑一轮生成明天微调出新版本后天在评测集上看结果。万亿参数模型跑整套循环可能要按周计算35B 模型则可以按天甚至按小时计算。另一个原因是小模型在面对“自己生成的数据”时更容易被数据分布拉向目标方向。大模型的世界知识已经非常丰富合成数据带来的边际影响有限小模型则像一块海绵改进空间大吸收快。很多“小模型自我迭代后能力大增”的实验本质上是把模型从不熟悉某个任务分布迭代成熟悉这个任务分布。理解了这一点再看“35B 干赢万亿参数”就不难明白真正赢的不是参数而是训练循环的迭代速度和数据分布的对齐程度。3. 小模型自我迭代的工程落地先跑通一条最小链路3.1 前置条件你需要什么如果想把这类方法用到自己的项目里不需要一开始就构建复杂的多模型对抗系统。先准备以下基础能力一个基础模型可以是 7B、14B、35B也可以是开源社区任意一个可微调的模型训练环境单卡或几卡 GPU能跑 SFT / DPO 即可评估集至少 100 到 500 条与业务目标强相关的评测样本数据过滤脚本规则去重、长度过滤、关键词过滤、格式校验一个打分方案可以是规则、脚本执行、代码运行结果也可以是一个更强的模型作为 judge版本管理每个迭代周期保存模型 checkpoint、训练数据、评测结果便于回滚。如果连评估集都没有先别急着做自我迭代。否则你无法判断模型是进步了还是退化了。3.2 最小闭环的六个环节我建议的落地顺序是先跑通静态训练用现有数据微调一版模型确认训练流程可复现。构造种子任务从真实用户问题、业务日志、历史工单里抽取 100 到 1000 条问题。让模型生成答案用当前模型对种子任务生成多个候选答案。筛选和过滤去除空内容、重复内容、格式错误并用规则或打分模型筛掉明显差的回答。增量微调把筛选后的数据合并到训练集再做一轮 SFT 或 DPO。跑评测在固定验证集上对比新旧版本记录每个指标。只要这六步能走通就已经具备最基本的“自我造题 自我迭代”能力了。后续才需要考虑更复杂的事情比如多轮迭代、多模型互相生成、动态评测集等。3.3 关键参数与配置理解这里的参数不是单纯的大模型学习率而是整条数据流水线里最容易影响结果的部分。生成温度如果想让模型生成多样性的候选答案temperature 可以设置在 0.7 到 1.0 之间如果只想生成稳定答案用 0.2 到 0.4。自我迭代早期建议温度稍高增加数据多样性。top_p / top_k可以按默认值设置但要注意和 temperature 配合避免生成过于碎片化。最大长度不要设置过长否则容易生成大量废话增加过滤成本。按任务实际输出长度设置即可。筛选阈值如果用打分模型建议先在小样本上人工校一遍打分结果确认阈值合理而不是直接套用 70 分。微调轮数SFT 阶段 1 到 3 个 epoch 通常就够太多反而容易过拟合。学习率建议比正常微调略低因为合成数据往往多样性不足过大的学习率会加速对单一分布的拟合。以上这些不是固定值但理解它们的意义比记住数字更重要。3.4 一个通用伪代码结构以下是一个简化版的流程示意用于说明代码组织方式不是可直接运行的完整项目。# self_iteration_pipeline.py # 这是一个最小闭环的伪代码结构 seed_tasks load_seed_tasks(data/seed.jsonl) base_model load_model(base_model_path) for round_idx in range(3): current_model base_model if round_idx 0 else latest_model # 1. 生成候选答案 generated [] for task in seed_tasks: samples current_model.generate( task[instruction], temperature0.8, num_return_sequences3, ) generated.extend(samples) # 2. 过滤 filtered [] for sample in generated: if pass_rule_filter(sample): score judge_model.score(sample) if score threshold: filtered.append(sample) # 3. 拼接训练集 train_data seed_tasks filtered # 4. 微调 latest_model sft_train( base_modelcurrent_model, train_datatrain_data, epochs2, ) # 5. 评估 metrics evaluate(latest_model, eval_set) print(fround {round_idx}: {metrics}) if not metrics_improved(metrics): latest_model rollback_to_best_model() break这段代码最重要的一行是rollback_to_best_model()。自我迭代不是只能前进它完全可能倒退。保留历史 checkpoint、自动回滚是长期迭代的安全底线。3.5 如何判断一轮迭代是否值得继续判断标准不能只看单一指标提升。我建议同时观察目标指标是否提升比如准确率、通过率、人工好评率该指标是否稳定多次运行是否有较大方差失败案例变化是否有原本正确但现在错误的情况生成多样性是否下降模型是不是开始只输出一种安全但重复的答案长尾场景是否变差越是高价值场景越需要单独监控。如果目标指标提升但多样性大幅下降或者长尾场景变差这种提升是不可持续的。建议每一轮迭代后至少人工查看 50 条新生成的数据和 50 条评测失败数据不要只看平均数。4. 不能忽略的坑模型崩溃、奖励黑客、评估过拟合4.1 model collapse吃自己数据的代价模型反复使用自己生成的数据训练会出现一个非常经典的退化现象生成结果的多样性逐代降低错误会被固化极端情况下模型会开始重复输出固定句式。很多人叫它“模型崩溃”。这不是危言耸听。当一轮迭代中的高质量数据被下一轮模型吸收后下一轮模型生成的数据会离人类真实数据越来越远。如果没有外部新鲜数据注入几轮之后模型可能变成一个“自说自话”的复读机。应对方法也很直接每一轮都保留一部分原始人工数据每一轮都注入新的真实用户反馈或新爬取的数据控制合成数据占比不要让它完全盖过真实数据对生成数据做去重和多样性检测相似度过高的直接丢弃。4.2 奖励黑客与自我打分的盲区如果用模型自己或另一个大模型作为打分器筛选数据很容易出现“奖励黑客”。比如打分模型可能偏好更长的回答而不是更准确的回答可能偏好看起来很有逻辑但实际错误的内容也可能被某些固定表达影响比如“首先、其次、最后”这类连接词。我在实际工作中看到过一种情况模型学会了在答案里加入“根据以上分析我们可以得出结论”结果打分模型的分数明显变高但业务方拿到答案后觉得根本没法用。要降低这个风险需要为打分模型设计更具体的评分标准比如答案是否直接回答了问题而不是铺垫过多是否包含事实错误格式是否符合业务要求是否有步骤、有依据但克制如果任务有标准答案是否必须用代码执行结果或规则判断。打分只是筛选手段不是最终裁判。4.3 评估集污染比过拟合更隐蔽自我迭代还有一个隐蔽风险评估集被污染。如果模型生成的数据被加入训练集而训练集和评估集来自同一个数据源评估分数自然会被虚高。更麻烦的是模型完全可能“背下”评估集的答案而不是学会任务本身。要避免这个问题评估集必须与训练集完全隔离而且要定期更新。我不建议长期使用同一套固定测试题。比较稳妥的做法是建立训练集、验证集、测试集三层隔离测试集只用于最终评估不参与任何训练或筛选从真实业务中持续抽取新样本替换已污染的测试题目对新版本模型做盲测评审人员不知道哪份答案是哪个版本生成的。4.4 排查链路先看输入、再看环境、最后看数据分布如果迭代后模型效果没有提升甚至变差了不要急着调参。按下面顺序排查输入侧种子任务是否太简单生成数据是否大量重复过滤阈值是否过于宽松或严格环境侧训练脚本是否误用了旧 checkpoint学习率、批次大小、随机种子是否发生变化依赖版本是否不一致评估侧评估集是否被污染是否换过评估 prompt是否用了不同采样温度数据分布侧合成数据与真实数据的比例是否合理新数据是否集中在少数模式上模型是否开始产生同质化输出大多数“迭代后变差”的问题都不是模型能力下降了而是某个环节的数据分布发生了偏移。5. 这类方法适合谁不适合谁5.1 适合的场景垂直领域任务如客服、法律咨询、医疗问答、代码修复、数据分析。任务边界越清晰自我迭代越容易收敛。已有真实反馈积累的团队每天有大量用户反馈、工单、日志可以回流合成数据和真实数据可以交替使用。算力有限但希望持续优化效果的团队小模型迭代快、成本低适合在固定算力预算内追求“够用且稳定”。Agent / 工具调用场景可以通过代码执行结果判断模型输出是否正确天然适合自动筛选。比如模型生成 SQL、Python 代码、JSON 配置结果能不能跑就是最硬的标签。5.2 不适合的场景开放性极强的通用对话任务边界模糊评判标准多样自我迭代很容易变成“自我偏见放大”。冷启动阶段没有评估集和真实反馈如果连第一个版本的打分逻辑都没建立盲目迭代只会放大随机噪声。追求全方位能力的团队如果希望模型同时成为编程高手、写作专家、翻译专家、Agent 规划大师小模型自我迭代的样本效率可能不够。对生成内容安全性要求极高的场景模型自己生成数据容易引入偏见、违规内容和错误事实必须要有强人工审核。5.3 长期迭代前需要补齐的工程能力如果你打算把这个思路用到长期项目里还需要补齐几块工程能力数据版本管理记录每一轮生成数据的来源、过滤条件、处理脚本和采样参数自动评估平台至少能跑回归评测支持看 diff、看失败 case模型发布流水线能快速回滚到上一版避免坏模型在线残留监控告警关注生成多样性、输出长度、拒绝率、用户反馈率等指标人工审核闭环对高影响样本和低置信度结果保留人工复核通道。这几块能力比任何单轮训练技巧都重要。只有它们稳定了自我迭代才能从“实验”变成“生产系统”。5.4 如果团队资源有限建议从哪个方向开始资源有限的情况下我会更建议从“评估集 真实反馈回流”开始而不是直接做大规模合成数据。先把 200 条真实业务问题做成固定评测集。让现有模型在这些问题上跑一版成绩。然后让模型对每个问题生成多个答案再用规则过滤 人工打分挑出一批优于原答案的数据。最后用这少数高质量数据做一次微调。这样一轮下来一般就能看到相对明显的效果提升。先别做多轮迭代。先做一轮确认整个流程的每一环都能被量化。等流程稳定了再慢慢增加轮次和数据规模。6. 回到主线参数数量不是终点迭代能力才是6.1 “35B 干赢万亿参数”背后真正值得记住的框架如果要从“35B 干赢万亿参数”这个标题里提炼出一个可复用的框架我的答案是能力 基础模型参数 × 数据质量 × 任务收敛度 × 迭代速度参数只是其中一项。数据质量决定了模型能在什么方向上成长任务收敛度决定了最终效果能不能被量化和优化迭代速度决定了你能不能快速试错。所以当你再看到一个“小模型干赢大模型”的标题时不要只盯着参数对比可以尝试拆解它用什么数据训练它用什么标准筛选数据它如何评估效果它迭代了几轮每一轮的数据和模型版本是否可追溯这些问题拆完标题的神秘感就消失了大半。6.2 模型发布只是起点持续自我迭代才是长期护城河过去我们习惯了“训练一次发布模型然后等下一个大版本”。但自我迭代思路带来的是一个更连续的开发模式模型上线后持续收集反馈每周或每月跑一轮数据生成、筛选、微调、评估、发布。模型不再是一个静态产物而是一套持续进化的系统。这种模式对团队带来的改变不只是技术上的还有组织上的。它要求算法、数据、工程、评测、甚至业务方坐在一起持续定义“什么样才是好的答案”而不是把模型发布出去就万事大吉。6.3 下一步行动建议如果你认同这个方向可以先做三件事建立一个真实业务评测集无论有多少条先让模型有“及格线”用规则和代码执行结果而不是模型主观打分先做一轮自动筛选保存好第一版模型和第一批数据作为后续所有迭代的对照基线。自我迭代不是一个可以一蹴而就的功能它更像一套训练“模型如何更好地学习”的工程体系。35B 能不能干赢万亿参数最终取决于你怎么出题、怎么判分、怎么迭代。参数规模是入场券但迭代能力才是真正拉开差距的地方。