这次我们来看一个很有意思的技术现象35B 参数的模型在特定能力上打赢了万亿参数的大模型。你可能第一反应是标题党但来自上海交通大学团队的这项研究核心并不是“小模型硬刚大模型”的玄学而是把数据生产、训练、评估和推理四个环节全部串成了一个可以自动运转的闭环——AI 自己给自己造题然后不断地自我迭代。如果只看“35B 干赢万亿参数”很容易误读成“参数量不重要了”。更准确的理解是模型不再只依赖静态数据集和固定训练过程而是能主动生成新的训练数据通过自动验证筛选出高质量样本再继续训练、评估、生成新数据形成数据飞轮。这个方向对做本地部署、垂直场景微调、数据稀缺任务的人很有参考价值因为它的核心不是烧显卡堆算力而是用更聪明的数据策略和训练循环去逼近超大模型的效果。这篇文章会从技术原理拆开讲给出一套可以在自己环境里验证的“自我造题 自我迭代”实验路线包含数据生成、训练、评估、批量任务队列和常见问题排查适合正在做大模型微调、想降低数据标注成本、或者想理解自训练机制的读者。1. 核心能力速览能力项说明研究方向小参数模型通过自动生成训练数据与自我迭代逼近或超越超大参数模型核心技术点自我造题Self-questioning、数据飞轮、迭代式训练、奖励信号验证模型规模以 35B 级模型为例对比目标为万亿参数级模型适用任务数学推理、代码生成、逻辑问答等可自动验证答案正确性的任务训练方式微调SFT 强化学习或偏好优化循环迭代推理策略可结合推理时计算扩展如多候选采样、结果验证提升效果硬件需求需要按实际模型版本测试35B 级全参数训练需要多卡LoRA/QLoRA 可降低门槛批量能力支持批量造题、批量过滤、批量评估适合搭建自动化数据流水线接口/开源情况以官方发布为准文中不假设具体可用接口适合场景垂直领域小模型、数据稀缺任务、高质量推理数据自动生产、模型自训练闭环搭建2. 为什么 35B 能赢万亿参数技术原理拆解2.1 先分清“能力峰值”和“通用能力”“35B 干赢万亿参数”并不是说 35B 在所有任务上全面碾压万亿模型。更合理的解读是在特定任务的能力峰值上35B 通过更好的数据分布、更充分的迭代训练达到了超过规模更大的模型的表现。这里面有一个关键前提任务结果可以用规则或工具自动验证。数学题、代码执行、逻辑判断这类任务对错是确定的模型造完题之后可以自动检查答案是否正确。这就让“自我造题”有了可靠的质量门槛——造出来的题质量差直接过滤掉不会污染训练集。如果你的任务是开放域写作、主观审美、情感对话这类很难自动验证的领域这套方法的直接效果会弱很多因为缺少自动奖励信号数据质量只能靠人工或 proxy 模型兜底。2.2 给自己造题把数据生产自动化传统微调流程是“人工标注 → 训练 → 评估”。数据量大标注成本高而且数据分布容易固定模型很快吃透。自我造题的本质是让模型自己生成新的问题、候选答案和解析再用一套自动规则去筛选。造题不是简单地让模型“再出一个类似的问题”。有效做法通常包括从已有真实样本出发做题目改写、条件变化、难度提升。让模型生成完整解题过程不只给答案。用执行器或规则引擎验证答案保留验证通过的样本。对生成结果做去重、难度分布控制避免数据退化。这一步解决了高质量数据来源的问题尤其是数学、代码、逻辑这类有明确对错边界的任务自动验证成本很低。2.3 自我迭代训练-评估-再造题的飞轮自我迭代不是“训练一次就结束”而是反复执行以下循环第一步用当前版本模型生成一批新题目。第二步自动验证、过滤、去重得到新增训练数据。第三步混入原始训练数据做一轮微调或强化学习。第四步在固定评估集上测试观察核心指标是否提升。第五步如果提升用新模型进入下一轮如果下降回滚并调整数据生成策略。这个循环的关键是每一轮都要守住评估集的独立性。如果造题分布和评估集过度重合会出现“刷题式提升”——训练数据里全是评估集同分布题目真实泛化能力其实没有提升。另外一个容易踩的坑是数据漂移。模型一轮轮迭代生成的新题会越来越集中在模型擅长或熟悉的方向导致数据多样性下降。解决办法是在每一轮保留一定比例的原始数据并主动控制新题的难度和主题分布。3. 适用场景与使用边界这套“自我造题 自我迭代”技术路线适合以下场景数学推理和逻辑问答答案可自动验证造题质量有保障迭代效果最明显。代码生成与修复通过编译和执行测试用例来判断正确性自动验证成本低。垂直领域数据稀缺任务手工标注成本高用初始模型生成候选数据再人工抽查能大幅降低起步成本。小模型能力增强在无法部署超大模型的环境中用小模型加数据飞轮逼近大模型效果。自动化数据流水线团队有大模型 API 但不希望所有请求都走外部时可先用离线造题生成数据再训练本地小模型。不适合的场景也要说清楚开放域创作、审美评分、主观偏好任务缺少客观奖励信号自动迭代容易走偏。长尾真实世界知识问答模型自己造题只能基于已有知识无法补足真实世界新信息需要用检索或真实语料兜底。对事实准确性要求极高的场景自动生成数据存在幻觉风险需要额外的事实核查环节。使用边界和合规提醒如果通过模型生成数据的方案涉及受版权保护的文本、代码或图像必须确认是否有权使用这些素材。涉及真实用户数据时需要脱敏、去标识化并遵守数据保护要求。不要用该技术批量生成虚假信息、误导性内容也不要在未授权情况下分析或生成他人隐私数据。自动生成数据训练出的模型在上线前需要做效果复核和抽样人工审查。4. 本地验证环境准备如果你想把“自我造题 自我迭代”跑通不一定要从 35B 级模型开始。更稳妥的做法是先拿一个 7B 或 14B 模型做小规模验证跑通完整闭环后再放大。下面是一份通用环境检查清单项目建议操作系统Linux 优先Windows 可配 WSL2GPU至少 1 张 24GB 显存显卡具体取决于模型量化和训练方式CUDA / 驱动根据 PyTorch 版本安装对应 CUDA先用nvidia-smi确认驱动Python3.10 或 3.11模型推理框架vLLM 或 Transformers用于批量推理和生成训练框架PyTorch Hugging Face Transformers / TRL / LLaMA-Factory评估工具自己维护固定评估集可用数学推理或代码执行评测脚本磁盘7B 模型约 14GB14B 约 28GB35B 约 70GB视精度而定另需预留数据生成与训练缓存空间端口如果启动 API 服务注意 7860、8000、8080 等常见端口占用检查环境的通用命令nvidia-smi python --version python -c import torch; print(torch.__version__, torch.cuda.is_available()) python -c from transformers import AutoModelForCausalLM; print(ok)如果显存不足优先考虑 LoRA 或 QLoRA 低秩微调而不是全参数训练。5. 一条可复现的“自我造题 迭代”实验路线下面这套流程是通用模板目的是验证“造题 → 数据过滤 → 微调 → 评估 → 迭代”是否成立。具体路径和参数需要按你实际使用的模型和任务调整。5.1 用当前模型当“出题老师”造题阶段的核心是给模型一个清晰的任务描述。以数学推理题为例提示词可以这样组织你是一名数学出题老师。请根据下面的示例题目生成一道新的题目要求 1. 题型与示例相似但数值和条件必须变化。 2. 难度接近或略高于示例。 3. 必须给出完整解题步骤和最终答案。 4. 不需要多余的解释直接输出 JSON。 示例题目 {example} 输出格式 {question: 题目内容, answer: 最终答案, solution: 解题步骤}如果你的模型对 JSON 输出不稳定可以在后处理里用正则或解析库提取字段并设置最大重试次数。5.2 自动过滤与去重生成结果不能直接进训练集需要经过过滤规则题目文本和示例完全相同或相似度过高删除。知识库中已有相同题目删除。答案缺失或解题步骤为空删除。通过执行验证的数据如果没有自动执行器则用规则做初步校验再抽样人工检查。控制每轮新题的难度分布避免全部集中在简单题或难题。这个过滤逻辑可以用一个简单的 Python 脚本实现import json import re from difflib import SequenceMatcher def filter_generated_samples(raw_list, existing_questions, similarity_threshold0.85): seen set(existing_questions) result [] for item in raw_list: q item.get(question, ).strip() a item.get(answer, ).strip() s item.get(solution, ).strip() if not q or not a or not s: continue if q in seen: continue if any(SequenceMatcher(None, q, e).ratio() similarity_threshold for e in seen): continue # 这里可以接入执行器或规则验证答案 result.append(item) seen.add(q) return result samples json.loads(open(generated.jsonl).read()) filtered filter_generated_samples(samples, existing_questions[...]) print(f原始 {len(samples)} 条过滤后 {len(filtered)} 条)5.3 SFT 策略优化训练循环每一轮迭代建议先做一小轮监督微调SFT让模型学会新数据的解题格式如果资源充足再加偏好优化或规则驱动的强化学习。训练脚本可以走 Hugging Face TRL 或 LLaMA-Factory这里给出通用模板# 通用训练命令实际脚本需按项目替换模型路径与数据路径 python train_script.py \ --model_name_or_path ./base_model \ --train_data ./data/round_1_train.jsonl \ --output_dir ./checkpoints/round_1 \ --num_train_epochs 1 \ --per_device_train_batch_size 1 \ --gradient_accumulation_steps 8 \ --learning_rate 2e-5 \ --use_peft True \ --lora_r 16如果训练数据包含多个轮次的旧数据建议每一轮都混入上一轮的少量代表性样本防止灾难性遗忘。5.4 固定评估集与迭代评估评估集是迭代是否有效的裁判。最好准备两部分一个固定的公开基准集用来对比每轮提升。一个从目标应用场景抽出的真实样本集用来判断实际效果。评估脚本的通用逻辑如下import json def evaluate_model(model, tokenizer, eval_questions): correct 0 total len(eval_questions) for sample in eval_questions: prompt sample[question] predict model_generate(model, tokenizer, prompt) if check_answer(predict, sample[answer]): # 执行器或规则判断 correct 1 return correct / total round_scores [] # 每轮训练完记录准确率 round_scores.append({round: 1, score: 0.62})判断迭代是否有效的标准不是“分数必须一直涨”而是看前几轮是否快速提升、之后是否进入平台期。如果第二轮就开始下降或不变说明造题策略或过滤逻辑出了问题不应该继续无脑训练。6. 批量造题与任务队列设计自我造题不是一条条手动调用而是批量任务。建议把整个流程拆成多个阶段每个阶段一个目录project/ ├── prompts/ # 造题提示词模板 ├── raw_generated/ # 模型生成的原始数据 ├── filtered/ # 过滤后的训练数据 ├── checkpoints/ # 每轮模型权重 ├── eval_set/ # 固定评估集 ├── logs/ # 任务日志 └── scripts/ ├── generate.py ├── filter.py ├── train.sh └── evaluate.py批量生成数据时可以用 vLLM 的离线批量推理或自建任务队列。以下是一个简单的按文件批量处理的 Python 示例import json import os from concurrent.futures import ThreadPoolExecutor def generate_batch(input_file, output_file, model_api_url, max_workers8): tasks [] with open(input_file, r, encodingutf-8) as f: for line in f: tasks.append(json.loads(line)) def call_model(sample): # 这里替换为你实际使用的推理接口 response requests.post(model_api_url, json{...}, timeout120) return response.json() results [] with ThreadPoolExecutor(max_workersmax_workers) as pool: for r in pool.map(call_model, tasks): results.append(r) # 每完成一批写一次临时结果避免进程中断丢数据 with open(output_file .partial, w, encodingutf-8) as f: for item in results: f.write(json.dumps(item, ensure_asciiFalse) \n) os.replace(output_file .partial, output_file)批量任务设计时要注意三点每个任务要写幂等记录失败后能重跑。输出文件用临时文件加os.replace避免写到一半崩溃导致文件损坏。并发数不要盲目调高先测试显存和接口的承受能力再逐步增加。7. 资源占用与性能观察资源占用不能凭空给出具体数字要看实际模型和推理框架。但有几个通用观察方法可以参考用nvidia-smi -l 1或watch -n 1 nvidia-smi观察显存和 GPU 利用率。批量推理阶段最关注“吞吐量”也就是每秒能生成多少 token而不是单条响应速度。训练阶段最关注“显存峰值”和“GPU 利用率”如果 GPU 利用率长期低于 80%要检查数据加载和 batch size 是否合理。造题阶段每生成一条数据都要消耗一次推理成本比训练本身更容易被忽略。估算时要按“token 生成量 × 推理时长”计。降低显存和资源占用的常用手段训练用 LoRA 或 QLoRA只训练低秩适配器。推理用 vLLM 或带量化减少 KV cache 和权重显存。长文本输入做截断控制最大生成长度。造题时关闭不需要的随机采样参数固定max_tokens避免单条生成过长。批量任务按批次入库不要一次性把所有数据都读入内存。性能观察的核心指标是“单位算力换多少有效训练数据”。如果造题经过滤后保留率很低比如 1000 条生成只有几十条合格你应该先改进提示词和过滤规则而不是加更多卡。8. 常见问题与排查方法问题现象可能原因排查方式解决方案启动或推理时报 CUDA 错误驱动 / PyTorch 版本不匹配运行nvidia-smi和python -c import torch按 PyTorch 官方要求重装匹配版本的 CUDA 与 PyTorch模型无法加载权重文件缺失或路径错误检查模型目录和 transformers 报错信息补全模型权重或改用本地缓存路径训练 Loss 不下降数据噪声大 / 学习率过高 / 数据量过少检查训练集数据质量降低学习率清理异常样本降低学习率增加数据量生成题目大量重复解码参数单一 / 提示词约束不足观察生成样本的相似度调整 temperature增加禁止重复指令做去重过滤迭代两轮后评估分数下降数据分布集中评估集漂移检查新数据与评估集的相似度回退到上一轮 checkpoint保留原始数据比例控制新题难度分布显存不足batch size 过大 / 输入过长查看nvidia-smi峰值显存降低 batch size开启梯度累积启用 LoRA批量任务卡住单条生成超时 / 死锁查看任务日志和接口超时设置加超时重试拆小批次API 调用失败接口地址错误或服务未启动curl 测试接口健康检查确认端口和路径查看服务日志自动验证答案不准确规则太严格或太宽松抽样人工审查验证结果调整验证规则增加人工抽检比例生成结果格式非法模型输出不稳定查看原始输出日志后处理增加纠错重新生成失败样本9. 最佳实践与使用建议第一次做自我迭代实验务必先小规模验证。不要一上来就训练一个 35B 模型跑十个轮次。推荐从 7B 模型、单轮迭代开始跑通“造题 → 过滤 → 训练 → 评估”闭环确认收益后再放大。保留固定评估集是底线。每一轮训练后都在完全相同的评估集上跑同一套评测脚本这样对比才有意义。如果评估集不够稳定很容易把随机波动当成模型提升。每一轮模型 checkpoint 都要保留。一旦发现后续迭代效果变差可以快速回滚到上一轮而不是从头再训练。尽可能把自动验证做严格。在数学、代码这类任务上优先用执行器或规则验证而不是让模型自己判断答案对不对如果做不到就加一版小模型做成对标注再人工抽查。生产环境接入时必须考虑合规。确认训练语料、生成数据来源和使用范围不采集未授权数据不生成和传播可能造成误导的内容。发布模型或提供服务前还要做一轮效果复核和内容安全测试。10. 总结与下一步这项研究最值得尝试的点不是“35B 模型有多大”而是“35B 模型如何用自我造题和数据飞轮把能力抬到接近万亿模型的水平”。它真正改变了模型训练的投入方式从“堆参数、堆数据”转向“高效生成数据、自动验证、小步快跑迭代”。如果你想验证这个方向可以从三个功能开始一是让模型批量造题并自动过滤二是在固定评估集上做一轮微调对比三是跑两到三个迭代轮次观察准确率是否进入平台期。最容易踩的坑是造题数据多样性和评估集漂移这两个问题会直接让迭代失效。后续可以继续扩展的方向包括接入代码执行器实现更强的自动验证引入外部知识库给造题过程补充真实信息或者把多轮对话数据也纳入自我迭代范围。建议先在小模型上把整套流程调稳再迁移到更大规模的 35B 级模型上。