最近关于“35B干赢万亿参数大模型”的讨论让不少人在大模型选型上重新掂量参数规模。尤其当这背后还加上“上交大AI”和“自我迭代”这组关键词之后很多人开始关注350亿参数级别的模型凭什么能和万亿参数模型正面比划它又是怎么做到自我出题、自我训练、持续变强的从目前公开讨论的信息来看这次热度来自上海交大团队一套围绕“自生成数据自我迭代”的方法核心不是参数数量本身而是给模型搭了一个能不断产出题目、校验答案、重新训练并回归测试的闭环。这篇文章就按我个人理解的落地路径聊聊这个方向该怎么看、怎么复现、以及最容易被忽略的坑。适合谁看正在做大模型评测、微调、数据合成或者在小规模算力下研究模型能力上限的开发者。先说结论35B模型在特定任务上超过更大的模型不是神话但它有非常强的条件边界真正值得借鉴的是那套“生成数据—校验答案—再训练—回归测试”的闭环方法。1. 先统一口径35B和万亿参数放在同一个天平上到底在比什么1.1 参数规模之外的三个变量很多人看到35B干赢万亿参数第一反应是参数越少越强。这个结论太粗糙。做对比实验的人都知道模型规模只是能力的一个维度评测结果还会被其他三个变量影响。第一个变量是稀疏激活。万亿参数模型不一定是稠密模型。很多千亿、万亿级别模型采用MoE结构推理时只激活其中的一部分专家实际激活参数可能只有几十B。35B稠密模型在单次推理时用到的参数量不见得比万亿MoE模型少太多。如果评测任务恰好落在激活专家容易覆盖的范围内35B拿到相近甚至更高的分数并不奇怪。这不能说明小模型全面碾压大模型只能说明同一道题上两者调用的能力量级接近。第二个变量是推理配置。同样是35B模型用FP16推理和4bit量化推理处理长上下文时的效果完全不同。大模型也可能被压缩部署输出质量会受影响。如果小模型用更高精度、大模型被量化后做对比结论就失去参考价值。我看到很多类似讨论时会先问一句两者的精度、上下文长度、采样参数是否一致。第三个变量是任务类型。数学、代码、逻辑推理、结构化输出这类可验证任务适合用模型生成题目后自动校验答案通过迭代快速提升。开放聊天、创意写作、情感理解这类主观任务很难用自动验证器判断好坏小模型想通过自我生成数据来超越大模型就难得多。所以标题里能“干赢”的任务往往属于前者不是所有场景都适用。1.2 “干赢”是评测结论不是能力全等另一个容易忽略的点是评测口径。同一个模型在5000道题的公开榜单上差1分和在一个私有小测试集上差10分可信度完全不同。遇到类似标题时我一般会先看四件事评测集是否公开和训练数据有没有重叠。是否允许多次采样或多数投票。打分的自动化规则是否对某一方有利。结果是否重复跑过多次方差有多大。比如数学题评测如果允许模型生成8次答案再投票很多模型的分数会明显上涨。这不代表模型本身变强了而是采样策略带来的提升。35B模型如果在这个配置下超过一个没有做任何推理时增强的万亿模型你可以说前者的方法值得学但不能说小模型全面替代大模型。所以把这层拆掉之后再去看“上交大AI开始给自己造题”这件事焦点会清晰很多真正有价值的是数据生成和自我迭代的机制而不是参数数量的胜负。2. “自己造题”到底在做什么合成数据如何补足人工标注2.1 为什么需要模型自己出题大模型训练通常不是只跑一次预训练就结束。在预训练之后还要经过指令微调、对齐、评测、针对性优化等阶段。很多能力提升依赖高质量的指令数据但人工标注指令数据的成本非常高覆盖面也有限。找一群人写几万条包含详细解题过程的数学题速度慢而且题型容易趋同。模型能自己生成题目本质是把人员从“逐条写题”变成“做审核”用更少的标注成本换更大的数据量。具体思路可以这样理解先给模型一小批高质量种子题让它改写场景、替换变量、增加约束条件生成一批相似但不重复的新题。这不是让模型凭空编造全部知识而是利用模型在预训练阶段已经学到的语言和推理模式把已有题目做结构化扩展。生成出来的题并不能直接进入训练。数学题需要有确定答案代码题需要能跑通多选题需要保证选项唯一。所以完整的流程一定是“生成—校验—过滤—抽检”而不是把生成结果一股脑塞进训练集。2.2 从原始生成到可训练数据中间至少要过四道关我建议把“造题”拆成四个步骤第一是去重。模型生成题目时非常容易套模板只是换数字。可以用规则统计题目文本和答案的重复度把n-gram重复率高的样本剔除。第二是答案校验。数学题用验证器重算代码题用编译器执行选择题检查是否只有一个正确项。自动校验能覆盖大部分低级错误。第三是难度分布检查。如果生成的题集中在一个难度档位训练后模型会出现偏科。需要按通过率、答案分布或人工抽样的方式看难度是否分散。第四是格式清洗。模型生成的JSON、Markdown、代码块可能不完整训练前要做一轮格式化清洗否则会污染指令微调数据。这里给一个很简单的流程伪代码实际使用时要按自己的数据格式替换# 示例流程不代表上交大项目源码 seed_questions load_from_jsonl(seed_questions.jsonl) valid_training_data [] for seed in seed_questions: variants generator.generate(seedseed, n8) for item in variants: if is_duplicate(item, valid_training_data): continue if not verify_answer(item): continue if not check_format(item): continue if not sample_check(item): continue valid_training_data.append(item) save_to_jsonl(valid_training_data, filtered_train.jsonl)看起来代码很简单但真正影响效果的不是生成数量而是校验逻辑。你宁可生成1000条、过滤后保留200条也别保留1000条带错答案的数据。错题对训练的伤害比缺失数据更大。2.3 不是任意模型都适合当“出题老师”还有一个常见误区以为自我迭代就是用当前模型直接出题再拿出的题训练自己无限变强。实际操作里出题模型和训练模型可能是同一个也可能不同。如果模型本身指令能力弱生成10道题只有2道格式正确那这套流程的成本很高。更稳妥的做法是先用一个能力更强的模型或人工数据做种子让当前模型生成变体再用规则或小型验证模型过滤。等到当前模型经过几轮迭代后生成质量提升再把生成比例逐渐拉高。这里要注意“自我”两个字。它说的是数据来源来自模型自身不代表完全不需要人工。哪怕全流程自动化也至少要有人维护种子题、校验规则和评测集。否则模型会越来越倾向于输出它自己熟悉的那套表达外部泛化能力不升反降。3. 自我迭代闭环从一轮训练到持续改进最怕没有反馈3.1 一轮标准迭代拆成五步如果把“自我迭代”落到实处我习惯按五步走固定外部评测集。这个评测集不能来自当前模型生成的数据也不能和训练集高度重叠否则后面所有结论都会失真。用当前模型生成候选题并完成去重、答案校验和格式清洗。把通过校验的新增数据与原始训练数据合并做一轮微调或全参训练。跑外部评测集记录分数、错误样例和资源占用。对比本轮和上一轮的指标决定继续迭代还是停止。第一步最容易被忽略。很多人一上来就让模型造题然后把造出的题同时用于训练和评测结果训练集和评测集高度相似分数看起来涨得很快实际上模型只是记住了题型。我建议每轮迭代前先把评测集单独放在一个目录并在数据合并时显式过滤掉评测集样本。如果条件允许可以设置一个LLM相似度或n-gram重复率阈值当新生成数据与评测集的重复率超过阈值时直接丢弃。3.2 收益递减第三轮开始要盯增长曲线自我迭代不会一直保持高收益。第一轮往往提升最明显因为模型新接触了一批覆盖更广的题目到第三轮、第四轮新生成题的同质化会变高分数增长会放缓甚至出现波动。我判断是否继续迭代时主要看三个指标外部评测集得分是否连续提升。新生成数据的校验通过率是否稳定。答错的样例是否仍在重复出错。如果连续两轮外部得分涨幅低于可接受阈值同时校验通过率也没有明显变化就可以停一轮。继续跑下去算力成本和数据管理成本都会快速上升收益却很小。这里要特别注意方差。如果评测集只有几百道题模型随机采样差异会导致分数上下波动。最好用固定随机种子并跑多次取平均。否则你可能把波动当成提升继续投入大量算力去优化一个并不存在的差距。3.3 自我强化偏差越训练越像自己最后可能困在原地这是自我迭代方向上最需要警惕的问题。模型生成的数据来自它自身的输出分布如果每一轮训练都只学习自己生成的数据模型会逐渐强化自己的表达习惯、错误模式和思考方式。短期看相关任务分数会涨长期看多样性会丢失。缓解手段也比较明确保留原始人工数据训练时按比例混合。引入外部开源数据或更强模型生成的数据。每轮强制加入一定比例的“反例”也就是人工标注的错误答案让模型学会区分正确和错误。持续用与模型无关的外部基准做回归测试。一个稳定可用的闭环不应该只有“当前模型自己生成数据”这一条输入。它可以是以当前模型为主外部数据和人工审核为辅的多元数据流。4. 小团队复现这个思路先从7B、14B模型和干净日志开始4.1 先想清楚你要迭代的是“能力”还是“答题技巧”很多人在看到35B干赢万亿模型后想立刻在自己的业务里复现。复现前先想清楚你要提高的是模型做某类任务的真实能力还是只是让它在一套固定题上拿高分如果是后者现在很多方法论都可以做到比如把评测题改成训练数据格式或者加入相似题训练。但这样做的代价是换一个数据集后分数可能掉很多。如果是前者就需要在训练数据中保留多样性和不确定性并且有足够多的外部验证。数学、代码、SQL生成、结构化抽取这类任务答案可自动验证适合自我迭代。主观问答、情感支持、创意写作这类任务使用自动生成数据很容易让表达变得模板化不太适合直接照搬这套闭环。4.2 算力不够时先从更小的模型跑通闭环35B模型听起来不算大但实际部署和训练都是成本。35B稠密模型权重用FP16存储大致需要70GB显存。推理时还要加上KV Cache和激活值单张24GB显卡通常放不下需要多卡或量化。如果要微调还要加上优化器状态和梯度开销会更明显。如果只有单机单卡我更建议先用7B或14B模型把整条流程跑通。如果在本地用35B模型做数据生成还要关注推理时的首token时延TTFT。TTFT高不代表模型能力差通常和显存带宽、上下文长度、输入长度有关。但它会直接影响你造题环节的吞吐量所以环境压测时要一起统计。流程跑通的意思是模型能生成合格的候选题。过滤、校验、清洗脚本能稳定执行。训练任务能完成。外部评测能输出可对比的分数。迭代三到四轮后能看出收益变化和趋势。如果你一开始就用35B去调数据生成、过滤和评测脚本调试成本会高很多。小模型确实能力有限但它足以暴露流程里的问题。等流程稳定后再换到更大的模型成功概率更高。4.3 先搭三样基础设施数据版本、评测脚本、训练日志自我迭代最坑的不是模型训不动而是你根本说不清当前结果是用哪一批数据、哪个版本模型、哪一组参数跑出来的。迭代到第三轮数据文件可能已经堆满目录然后你会发现A结果和B结果没法对比。我建议不管多小的团队先搭三样东西数据版本记录。每次合并数据时记录种子题数量、生成题数量、过滤后数量、数据文件路径。评测脚本。用固定的评测集、固定的提示模板、固定的随机种子和采样参数跑完输出JSON结果。训练日志。记录模型路径、LoRA配置、学习率、batch size、训练时间和loss曲线。这三样东西不需要做成复杂的平台一个CSV表格都能凑合。关键是养成习惯每次训练前先看一眼数据版本和评测脚本版本。可以用一个简单的表来管理基础设施作用最小做法数据版本回答“这批数据从哪来、过滤条件是什么”文件名带日期和过滤条件比如 train_20250601_dedup_verify.jsonl评测脚本回答“这个分数是怎么来的”固定评测集、固定提示模板、固定随机种子训练日志回答“这轮模型和上一轮有什么区别”记录模型路径、数据文件、训练参数、loss4.4 参数调整顺序先动数据再动训练最后动模型如果第一轮迭代效果不好别急着调大batch size或改LoRA rank。先回看数据质量。数据层常见的调整包括提高去重阈值、增加答案校验的严格程度、增加种子题多样性、调整生成温度和候选数量。很多时候分数不涨是因为生成题和种子题太像模型没有看到新的思维方式而不是训练参数不对。训练层再调整学习率、batch、训练轮数。对LoRA微调来说学习率过高会导致生成数据里的错误被快速放大学习率太低又学不到新东西。我习惯每次只改一个参数记录对比再跑外部评测。模型层指的是切换更大的基座、改模型结构、换更强的生成模型。这些成本最高放最后考虑。5. 验证方法和排查链路别把运气当成提升5.1 每一轮迭代要看哪些输出只看一个评测总分远远不够。我每次跑完一轮至少会保留五类信息外部评测集的总分和分项分数。训练集的loss曲线。新生成数据的校验通过率。生成样本的重复率和平均长度。评测中答错的典型样例。后续版本做完后我会先打开错误样例看一遍。如果错误类型没有变化只是总分数涨了0.2分那可能只是采样噪声如果错误样例里的推理过程明显更完整哪怕分数暂时没涨这个迭代方向也值得继续。5.2 常见问题排查顺序这里给一套我常用的排查顺序按优先级从高到低先看数据生成日志。生成的候选题是不是正常温度是不是太低去重阈值是不是太严格导致有效样本太少再看数据清洗结果。过滤后的样本数量和通过率是否合理有没有大量错题漏进来然后看训练日志。loss是不是下降是否出现loss震荡或过拟合最后看评测脚本。确认评测集、提示模板、采样参数和上一轮一致。注意不要一报错就改模型参数。报错不一定是模型问题很可能是路径、权限、依赖版本、输入格式或评测脚本的问题。5.3 评测集泄漏看起来提升其实是记忆自我迭代里最容易出现“看起来提升其实没有”的场景就是评测集泄漏。泄漏不一定是故意把评测集放进训练集也可能是生成的候选题和评测题在文本结构上太接近。模型在训练阶段看到了大量相似的题测试时自然能答得更好。我建议每次训练前用n-gram或字符串相似度对比新增数据和评测集的重复率。如果出现明显的高重复样本就要检查生成时的种子题来源和清洗逻辑。这里也解释一个现象为什么有些模型在某个榜单上突然涨了很多分换一个榜单打回原形。大概率不是模型变强了而是数据分布已经提前覆盖了那套榜单。5.4 什么时候该停下这个闭环不是所有项目都值得一直自我迭代。出现以下情况我建议先停一轮新生成数据的校验通过率持续下降。外部评测集得分连续两轮没有提升。生成的题越来越同质化即使加大温度也差不多。训练时间和算力成本明显上升但错误样例改进不明显。停下来后先回头做数据诊断而不是继续加算力。很多时候问题出在种子题范围太窄、验证器规则太宽松或者评测集本身太小。把这些解决后再继续比盲目跑到第七轮更有用。这类工作真正值得借鉴的地方不是35B和万亿参数之间的数字对比而是数据、评测、训练被放进同一个闭环里让每一轮结果都能反馈到下一轮。想要复现这个方向的团队我建议先把单任务、小模型、干净日志这套流程跑稳再加入更大的模型和更复杂的自动验证器。踩过几次之后你会发现很多问题不是工具能力不够而是数据版本、评测口径和生成数据的校验没有提前处理好。