35B干赢万亿参数大模型上交大AI开始给自己造题还能自我迭代了最近在AI圈看到一个很有意思的研究方向一个只有35B参数规模的大模型在某些推理任务上居然能打赢万亿参数级别的超大规模模型。而且这个35B模型不是靠“堆数据、堆算力”硬卷出来的而是通过自己给自己出题、自己做题、再根据做题结果改进自己形成一套“自我迭代”的闭环。这件事如果真的成立它的影响可能比“某个模型又刷了多少分”要大得多。因为它改变的并不是某个具体榜单的排名而是大模型能力提升的底层逻辑高质量训练数据到底还能从哪里来。这篇文章我想从技术角度拆一下为什么“35B干赢万亿参数”这件事值得关注所谓“自己给自己造题、自我迭代”背后的技术机制到底是什么它适合什么任务、不适合什么任务作为普通开发者或研究人员我们能从里面借鉴什么1. 这则消息真正值得关注的点不是参数少是数据生产方式变了先看表面信息。35B是350亿参数万亿参数模型是1000B以上两者之间差了接近30倍参数规模。在深度学习领域参数规模通常和能力上限高度相关所以“小模型在某个任务上打赢大模型”这种事过去并不是完全不存在但多数情况属于“特定任务上的特例”很难被当成一种通用方法。真正值得注意的是它达成这个结果的方式模型自己生成训练题目自己解题再根据解题过程和结果反向优化自身。也就是说训练数据的来源从“人类标注”和“从互联网爬取”变成了“模型自主生成 自动筛选”。这背后有一个更宏观的背景高质量人工标注数据越来越贵互联网公开数据也正在被一遍遍榨干。过去一年大模型竞争的核心之一是“谁能搞到更多高质量数据”几乎所有头部团队都在通过合成数据、数据配比、数据清洗来提升效果。但多数合成数据方案仍然围绕“人工设定规则 → 模型生成 → 人工筛选”的流程模型在里面更多是充当数据生产工具而不是训练的主宰者。“自生成题目 自我迭代”的关键变化在于它把模型从“被数据喂养的对象”变成了“自己设计练习题的考生”。这种思路借鉴了强化学习中很经典的Self-Play自博弈机制但又有明显区别。自博弈往往是在一个定义清晰的游戏环境中比如AlphaGo下围棋胜负规则是确定的。而大模型的推理任务通常没有天然的对错标准所以“如何判断模型自己造出来的题目到底有没有价值”就成了整个方案能不能成立的核心问题。也就是说这套方法一旦被验证有效它可能意味着未来的大模型竞争不再单纯比拼谁手里的GPU多、谁的训练数据全而更比拼谁设计了更好的“自我进化机制”。这才是“35B干赢万亿参数”背后最值得思考的部分。2. 基础概念参数规模、基准评测、自我迭代是什么2.1 参数规模到底代表什么参数规模可以通俗理解成一个模型的“记忆容量”和“计算复杂度”。35B代表模型大约有350亿个参数这些参数在训练过程中被不断调整用来拟合训练数据中的规律。一个万亿参数模型的参数量大约是35B模型的近30倍理论上有更强的表达能力和记忆能力可以记住更多事实、建模更复杂的模式。但参数规模从来不是“越大越好的线性关系”。更大的模型意味着更大的显存占用、更高的推理延迟、更昂贵的部署成本。一个万亿参数模型如果要做推理通常需要多卡甚至一个GPU集群才能跑得动而35B模型优化得好时单张A100/H100或更小的显卡就能在量化后跑起来。这决定了小模型在工程落地上有天然优势部署、更新、微调的成本都低很多。2.2 基准评测与“在特定任务上赢”的区别我们常说的“模型A打赢模型B”在绝大多数情况下是指“在某个基准测试集上分数更高”而不是“所有场景全面碾压”。比如一个模型在数学推理测试集上分数高不代表它在代码生成、法律问答或文学创作上同样厉害。所以“35B干赢万亿参数”更准确的表述应该是在特定评测任务、特定提示词分布下35B模型通过自我迭代后成绩超过了那个超大模型。这个“特定条件”很重要。它说明的不是“小模型完美取代大模型”而是“在受限的推理任务场景中小模型可以通过更多次、更聚焦的自我训练逼近甚至反超大模型”。更关键的是通过多次迭代小模型有机会专门针对某类任务的模式进行优化。而超大模型虽然是“通才”但在特定领域的“专才”比拼中并不一定总能赢过极度过拟合该领域的优化后的27B或35B模型。2.3 自己给自己造题、自我迭代的含义“造题”与“自我迭代”可以拆成三步模型基于自身已经掌握的知识生成一批新的训练题目。这些题目既要覆盖当前能力边界又不能太简单或太难。对生成的题目进行自动验证判断哪些题目是有效的、答案是否正确、哪些题目能真正暴露模型的弱点。用筛选后的题目继续训练模型然后重复这个过程。如果这个循环设计得好模型每轮迭代都会针对上一轮暴露出短板的题目做专项强化类似一个学生只刷自己容易做错的题而不是从头到尾做整套模拟卷。这种“针对性”就是它效率高的来源。从强化学习的角度看这跟Reward Hacking奖励破解恰好是相反的方向。如果验证机制不够严谨模型造题时可能会生成一些“看起来很难、实际可以偷懒”的题目最终骗取高分。这样迭代出来的模型评测分数也许上涨实际能力并没有提升这被称为“过拟合基准测试”。所以验证环节的可靠性决定了这套方法到底是“自我进化”还是“自欺欺人”。3. 传统训练范式和新范式的对比为了更清楚地说明这件事的增量价值可以把传统大模型训练路径和“自生成题目自我迭代”做一个对比。对比维度传统范式只靠人类数据加入合成数据自生成题目自我迭代数据来源人工标注、互联网采集人工设定规则模型生成候选人工筛选模型生成题目自动或半自动验证成本结构标注成本高、数据采集周期长生成便宜但筛选和清洗成本高前期需要研发验证机制后期边际成本低数据质量相对可控依赖标注规范依赖生成模板和筛选规则质量依赖验证器设计风险是奖励破解能力提升方式一次性大规模训练微调阶段有限配比权重调整一次性训练循环迭代每轮针对弱点专项强化对算力的依赖高大模型大数据高仍然依赖大模型生成数据单轮训练要求降低但需要多轮迭代周期适用场景通用能力、开放域问答结构化数据增强、知识增强规则明确的推理任务、数学、代码、逻辑从表格可以看出一件事自生成题目自我迭代真正改变的是“数据供给链路”。传统范式是一次性把数据喂完新范式则是把训练变成了可持续、可循环、可自我修正的过程。需要特别指出的是这并不意味着人工数据不再重要。在验证器设计、初始种子题目、安全对齐等环节人工仍然不可替代。更准确的理解是人工从“直接生产数据”变成了“设计验证规则和初始方向”而模型负责在规则范围内进行规模化探索。4. 自博弈与自生成数据的核心流程拆解下面把“自己造题、自我迭代”的实现流程拆开看清楚每一环的输入、输出和风险。4.1 第一步生成题目模型首先要拥有“造题”的能力。初始阶段研究人员会给模型一些种子题目比如几道数学应用题、几段带逻辑错误的代码、几个需要多步推理的日常问题。模型需要学习这些题目的形式然后生成更多同类题目。这个步骤看似简单真正难的是控制难度分布。如果模型只会生成“11等于几”这类题目迭代再多轮也没有意义如果模型生成超过自身能力的题目又可能连正确答案都给不出来导致训练信号错误。更合理的方法是让模型在生成时设置难度档位以“稍微超出当前能力边界”为目标。这个逻辑和课程学习Curriculum Learning很像先做容易题建立基础再逐步提升难度。但和课程学习不同的是这里的题目不是人工排列好的阶梯而是模型自己动态调整、每一轮都会变化。4.2 第二步验证与筛选这是整套方案最关键的环节。模型生成题目后必须有一套可靠机制来确认题目是否有意义、答案是否正确。常见的验证手段包括规则验证对数学题可以用符号计算或枚举验证对代码题可以直接运行测试用例。模型交叉验证用一个不同的模型或者多次采样生成多个候选答案通过投票或比对来确认正确答案。人工抽检对随机抽样的一部分题目做人工审核确保验证器本身没有系统性偏差。验证环节做得好不好决定了后续迭代是“正向增长”还是“奖励破解”。如果验证器存在漏洞模型很容易在下一轮训练中专门生成那些“能骗过验证器但实际无意义”的题目导致整体能力没有增长甚至退化成一套应试技巧。4.3 第三步迭代训练筛选出的题目会跟原有训练数据混合继续进行增量训练或微调。这里需要特别注意的是不能只把新题直接丢进模型否则可能出现灾难性遗忘——模型可能学会了新题目但忘记了之前掌握的代码、语言等能力。常见的处理方式是在每轮迭代中加入一定比例的历史数据维持模型原有能力同时用新的弱势题目做重点强化。这个过程跟SFT微调、LoRA低秩适配的常见做法很相似区别主要是数据来源变成了“模型自己生成”。4.4 风险模型崩溃与验证失效2010年代中期之后随着生成式AI发展研究者反复发现一个问题当模型训练数据越来越多来自上一个模型生成的内容时模型会逐渐产生“模式坍缩”也就是生成的多样性下降错误被不断固化最终整体能力退化。这在科学文献中常被称为“模型崩溃”Model Collapse。自生成题目自我迭代同样面临这个风险。如果每一轮的题目都来自上一轮模型的输出那么模型的错误模式可能会被不断放大。比如模型在某类逻辑题上一直有隐藏缺陷它自己生成的题目中也不会暴露出这类缺陷于是迭代多轮后模型可能只擅长“自己出的题”面对真实世界的新问题反而更不会。这也是为什么“自动验证”必须有独立于模型的机制。哪怕只是一个很简单的规则校验只要有独立的判断标准就能阻断部分错误积累。同样的道理也解释了为什么很多团队在做这类方法时仍然会保留一部分真实人类数据作为“锚点”防止模型彻底漂移。5. 为什么35B模型反而能做到“以小博大”很多人第一反应是如果这套方法对35B有效那对万亿参数模型不是更有效吗为什么会出现35B反超万亿参数的结果这个问题的答案可以从三个层面来理解。第一训练精度问题。万亿参数模型在通用数据集上训练单条数据对每个参数的影响非常稀释。而35B模型在自我迭代时使用的小批量数据高度聚焦每一轮都针对特定弱点做强化。如果把大模型比作一个面面俱到但每门课都只花几个小时复习的考生那么35B模型就像是把80%时间都投在弱科上的专项补考生。在特定科目上后者完全可能成绩更亮眼。第二成本和频率问题。万亿参数模型的每一次全量训练或大规模微调成本都非常高不可能为了一个数学推理专项任务频繁迭代。但35B模型单次训练成本便宜可以迭代几十甚至上百轮。高频迭代带来的快速反馈是它能在特定任务上不断逼近极限的关键。第三MoE和激活参数的问题。近几年一些模型看起来参数很多但推理时真正“激活”的专家参数可能只占一小部分。也就是说一个标注万亿参数的MoE模型在单次推理时真正参与计算的参数量可能并不比35B Dense模型多多少。这种设计降低了推理成本但也让“参数规模大”不能简单等同于“能力强”。理解了这三点“35B在特定任务上打赢万亿参数”就不再是一个玄幻故事而是资源分配策略和验证机制设计带来的必然结果。它传递的信号是在某些场景下比起“无限堆参数”更聪明的数据筛选和更高效的迭代机制可能是性价比更高的提升路径。6. 这套方法适合什么任务不适合什么任务如果我们要借鉴这个思路首先得清楚边界在哪里。不是所有任务都适合“自我造题、自我迭代”。适合的任务通常具备以下特征有明确的正确性判断标准。比如数学计算、代码执行、逻辑推导。只要有标准答案验证器就能设计得可靠这是整个循环能跑通的前提。题目生成模式相对固定。模型能够通过学习几个种子样例掌握“这类题长什么样”从而持续生成新题。能力图谱可以拆解。比如“解一元二次方程”“写递归函数”“判断三段论是否有效”可以分模块逐个突破。不适合的任务包括开放域写作、创意生成类。一篇散文写得好不好本身没有绝对标准验证器很难设计模型用自己生成的题目来自我迭代很容易陷入“自我感觉良好”实际审美没有提升。涉及复杂价值观判断或安全对齐的场景。法律、医疗、教育、心理咨询等领域机器生成题目自动验证的做法非常危险。即使验证器用了模型交叉验证仍然可能出现系统性偏见。需要实时更新事实的问答场景。模型自己生成的题目无法覆盖最新发生的事件知识类任务仍然依赖外部知识源或检索增强不能靠纯自迭代解决。从材料看这个研究选择的任务大概率落在数学推理或代码生成这类“结果可验证”的领域这也是业内做Self-Play、自博弈探索的最自然选择。如果我们自己尝试复现类似流程建议也从这类任务出发不要一上来就挑战开放域。7. 给开发者的落地参考代码级拆解前面讲了很多原理下面给出一个可以跑的思路框架。这里不绑定任何特定框架而是用伪代码加关键逻辑说明的方式让大家理解完整流程。你可以在自己的项目里用PyTorch、Hugging Face Transformers、vLLM等常见工具链替换实现。7.1 主流程伪代码# 伪代码自生成题目 自我迭代主流程 # 仅供参考具体实现需结合你的模型、数据格式与验证逻辑调整 from typing import List, Dict def generate_questions(model, seed_questions: List[str], num_to_generate: int) - List[str]: 基于少量种子题目让模型生成更多同类题目。 这里通过 prompt 控制风格、难度与题型。 questions [] for seed in seed_questions: prompt f请参考下面的例题生成 10 道难度相近的数学应用题。 每一道题必须能独立求解并且必须有唯一答案。 例题 {seed} 生成的题目 output model.generate(prompt, temperature0.8, max_new_tokens512) parsed parse_output_to_questions(output) questions.extend(parsed) # 控制数量避免生成过多 return questions[:num_to_generate] def verify_questions(questions: List[str], verifier) - List[Dict]: 验证题目是否有效、答案是否唯一、难度是否合适。 验证器可以是符号计算引擎、代码解释器也可以是另一个模型。 verified [] for q in questions: # 尝试用验证器解题 result verifier.solve(q) if result.status ok and result.is_unique(): verified.append({ question: q, answer: result.answer, difficulty: estimate_difficulty(q, result), is_wrong: False }) else: # 如果验证器也解不出来丢弃 continue return verified def iterative_train(model, seed_questions, verifier, iterations3): 核心训练循环 1. 生成新题 2. 验证筛选 3. 和旧数据混合后训练 4. 评估决定是否继续 current_model model history_data list(seed_questions) for round_idx in range(iterations): print(f Round {round_idx 1} ) # Step 1: 生成 new_questions generate_questions(current_model, seed_questions, num_to_generate200) # Step 2: 验证 verified verify_questions(new_questions, verifier) print(f生成 {len(new_questions)} 题验证通过 {len(verified)} 题) # Step 3: 混合训练数据 train_data mix_data(history_data, verified) # Step 4: 增量训练保留原能力 current_model incremental_train( current_model, train_data, lr1e-5, max_steps500, eval_metricaccuracy ) # Step 5: 评估是否达标 score evaluate(current_model, eval_set) print(fRound {round_idx 1} 评估分数: {score:.4f}) # Step 6: 将优秀题目加入历史池后续轮次继续使用 history_data.extend(verified[:20]) return current_model关键逻辑说明generate_questions中 temperature 设置不能太高否则生成题目可能离谱也不能太低否则所有题目高度相似。0.8 左右是一个常见起点。verify_questions是整套流程的守门员。如果验证器太弱后面训练就全不可信。incremental_train通常保留原能力方式为新题数据 30%左右历史数据混合避免灾难性遗忘。每轮迭代只取少量验证通过的优秀题目加入历史池防止历史数据无限膨胀。7.2 不使用框架的“轻量验证器”示例在没有现成验证器的情况下可以用符号库或代码执行器做基础校验。下面用一个 Python 的简单算术题验证为例# 文件路径verifier_demo.py # 一个极简验证器判断一个算术题是否有唯一数字答案 import re def solve_math_expression(question: str): 简易实现从题目中提取数学表达式用安全方式计算。 真实项目应使用更严谨的解析器或符号计算库。 # 仅用于演示实际要处理更复杂的自然语言 expression extract_expression_from_text(question) if not expression: return None # 禁止使用 eval避免任意代码执行 # 建议用 sympy 或 ast 解析 import sympy as sp try: expr sp.sympify(expression) result sp.simplify(expr) if result.is_number: return float(result) except Exception as e: print(解析失败:, e) return None注意即使只是极简验证器也不要用裸eval()去执行模型生成的字符串尤其是在处理代码生成类题目时任意代码执行会引入严重的安全风险。更稳妥的做法是使用 Docker 沙箱或受限子进程。7.3 一个可参考的 Prompt 模板Prompts 是控制生成质量的关键示例你是一名数学训练题设计专家。请根据下面的难度要求生成一道新的数学应用题。 要求 1. 题目要独立可求解不依赖上下文。 2. 必须只有一个正确答案。 3. 难度等级中等比基础题难一点比竞赛题简单。 4. 题目应覆盖多步运算变量设置。 5. 输出格式先给出题目再给出答案答案放在 内。 示例 题目小明有 120 元买 3 支钢笔花去 36 元剩下的钱买笔记本每本 7 元最多能买几本 答案12把这样的 Prompt 传入模型再解析结构化的输出能显著增加验证环节的通过率。很多团队在实际操作中还会在输出 JSON 中带上difficulty、topic、expected_answer字段便于后续过滤。7.4 运行与验证效果迭代训练完成后不能只看训练集分数一定要引入一个独立的、模型没见过的测试集。判断方法从同一分布中留出 10% 题目在迭代过程中不参与训练。每轮迭代结束时跑一次这个留出集看分数是否持续稳步增长。如果训练集分数涨了但留出集分数持平或下降说明模型发生了“过拟合自生成题”而不是“能力提升”。如果多轮迭代后分数不再增长说明模型已经逼近当前数据分布下的能力上限。此时要么增大题目多样性要么提高难度要么改进验证器。7.5 成本评估与算力规划从工程角度规划成本时可以用下面这个思路做粗略测算假设 - 基础模型推理生成每题需 0.5 秒 - 单轮生成 1000 题 - 验证器平均每题 0.2 秒 - 微调 500 步约 20 分钟 - 迭代 10 轮 总时长约为 10 * (1000 * 0.5 1000 * 0.2 20 * 60) 秒 10 * (500 200 1200) 秒 19000 秒 ≈ 5.3 小时 这只是一个最小规模示例。真实项目如果要生成 10 万以上题目单机时间会成倍拉长需要考虑并行化和使用批量推理框架如 vLLM 等。这里涉及的具体数字是近似值实际取决于模型大小、硬件、并发设置。但它能帮我们建立直觉自迭代方法的主要成本不是“训练”而是“反复生成和验证”。8. 常见问题与排查思路在实际复现类似方案时下面这些问题出现频率最高问题现象可能原因排查方式解决方案迭代多轮后评测分数不涨模型生成题目分布太单一验证器通过率过高检查生成题目的多样性统计题目类型覆盖尝试降低temperature或增加种子题目增加种子题目多样性调整难度加入新的验证维度训练集分数涨测试集分数降过拟合自生成题目模型没有真正学会泛化对比训练集和独立测试集分数变化曲线增加历史数据比例加入正则化减少迭代轮数加强题目多样性验证器通过率异常高验证器存在漏洞模型开始“刷题”人工抽检验证结果尝试反例引入独立验证器做交叉验证增加规则校验模型生成题目时语法混乱Prompt 约束不足模型没理解输出格式检查原始输出尝试更严格的 few-shot 示例使用 JSON 格式输出约束配合解析器在后端做格式校验迭代过程中模型能力倒退灾难性遗忘评估历史能力基准在训练数据中混入 20% 到 50% 历史数据或使用 LoRA 等参数高效微调方式生成题目安全事故题目触发了模型违规内容检查 prompt 和安全过滤规则增加安全过滤器和敏感词检测对生成内容做脱敏处理如果只是想在项目里快速验证这套思路最不建议的是一上来就构建复杂验证器。先选择一个规则最简单的任务比如“整数运算应用题”用确定性程序当验证器跑通三到五轮迭代观察评测指标是否上升。流程能跑通、趋势能验证再扩展到代码生成或更复杂的逻辑推理。9. 最佳实践与工程建议这套“自生成题目自我迭代”思想能落地的关键我认为有以下几点第一验证器要独立于模型。理想的验证器是确定性程序、符号计算引擎、编译器或测试用例运行器。它可以不智能但必须稳定、可控。如果验证器本身也是模型一定要做足够的人机交叉验证否则模型“自己出题、自己判卷”风险会成倍增加。第二用“能力图谱”驱动验证。不要只让模型生成“任何题”而是定义目标能力点比如“两个未知数的线性方程”“递归算法设计”“SQL窗口函数”。让模型针对每个能力点分别生成题目这样每轮迭代都能看到不同能力维度的提升也更方便定位瓶颈。第三保留真实数据锚点。无论自迭代效果多好都不要把历史真实标注数据全部丢掉。真实数据相当于“防漂移锚点”既能防止模型走向“自嗨”也能在自迭代失效时回退到安全基线。第四在训练数据中谨慎使用评分过滤。有些团队会把“模型在自生成题目上的得分”作为训练信号这有风险。如果模型在自生成题集上得了99分只能代表它适应了那套题分布不代表它在真实任务中接近满分。更安全的做法是把“训练”和“评估”分开模型的题目生成过程用于训练独立测试集用于评估两者不要混用。第五注意安全边界。在医疗、法律、金融、教育等涉及人身财产安全的领域不能直接让模型自主生成训练题并自动迭代。即使有验证器也可能出现系统性偏差。这类场景应该限制人工审核或者只在离线研究环境中实验不直接进入生产。第六小模型更适合作为自迭代的试验田。一个迭代成本低的小模型可以在几天内跑完几十轮实验团队能快速验证不同验证器策略、不同Prompt模板的效果。等结论稳定后再考虑把有效策略迁移到大模型上避免用大模型的高推理成本和微调成本反复试错。10. 总结与后续关注方向回到最开始的问题35B干赢万亿参数真正值得关注的不是数字上的反转而是它暗示了一条新路——大模型可以通过自我生成数据、自我验证、自我迭代在特定任务上获得超出参数规模的能力。这背后也带出一个值得持续观察的方向未来的大模型研发中“数据生产”和“能力验证”会不会成为比“参数量”更核心的竞争维度如果自生成题目的质量足够高小模型是否可以在更多垂直领域中用远低于大模型的成本逼近甚至超过通用大模型这些问题短期内不会有确定答案但值得跟踪。对普通开发者和研究人员来说我的建议是尽快动手做一个小规模实验。选一个规则验证成本低的任务比如数学应用题或算法题写出一个最小可运行的生成-验证-训练循环跑上三到五轮记录迭代曲线。这个过程中踩过的坑、积累的直觉比看十篇新闻稿都更有价值。迭代方法从来不是万能钥匙。但在“高质量人工数据越来越贵”的趋势下让模型自己成为训练数据的生产者可能是未来很长一段时间里最值得投入的方向之一。