当一个大模型只有 35B 总参数、约 3B 激活参数却能在数学推理、代码生成等任务上对标万亿参数模型甚至在某些评测集上反超时很多人第一反应是模型架构又有了新突破。但在上海交大相关研究中真正的胜负手并不只是单一架构改进而是一条数据闭环让 AI 自己出题、自己评估、自己筛选再把高质量数据喂回模型进行多轮迭代。这种“自我造题、自我迭代”的训练范式正在重新定义小模型的上限也让“35B 干赢万亿参数大模型”从口号变成了可复现的方法论。接下来的内容会先拆解“35B 为什么能和万亿模型同台竞技”再讲清楚“自我造题”和“自我迭代”的数据闭环给出一套可以在本地复现的最小工程流程最后补上推理侧 TTFT 偏高的排查思路和几个最常见的坑。这篇文章适合正在做大模型微调、数据合成、推理服务部署的工程师也适合准备把大模型压缩到有限算力环境里的技术选型负责人。1. 先搞清楚35B模型凭什么和万亿参数模型同台竞技1.1 参数总量、激活参数与推理成本要分开算在大模型领域“35B 干赢万亿”听起来像以弱胜强但这里有一个容易混淆的地方35B 总参数的模型不一定是稠密 35B 模型。更常见的是 MoE 架构比如 35B 总参数、约 3B 激活参数。MoE 的全称是 Mixture of Experts它把模型内部拆成多个专家子网络每个 token 只激活其中的一部分专家而不是让所有参数都参与计算。所以对比模型能力时需要同时看两个数字总参数量决定模型容量和理论上限也决定权重文件占用磁盘和显存的大小。激活参数量决定每个 token 前向计算需要的计算量直接影响推理吞吐和时延。万亿参数模型如果是稠密结构前向计算时所有参数都要参与训练和推理成本都非常高。而 35B-A3B 这种结构的模型虽然也要把全部权重放进显存但每次生成只激活约 3B 参数单 token 计算量远低于万亿稠密模型。这也是小模型可以在推理成本可控的前提下去挑战更大模型的原因之一。1.2 为什么小参数模型能反超大模型数据质量排在模型规模前面参数规模决定表达能力的上限但训练出来的模型能解决什么问题更取决于训练数据的质量和覆盖度。如果一个大模型在训练时吃到的领域数据非常稀疏或者训练轮次不够它的能力可能并没有完全发挥出来。反过来一个小模型如果吃到了高度聚焦、经过验证的高质量数据完全可以在数学推理、代码生成这类结构化任务上做到专项领先。这里的“结构化任务”特别适合用合成数据提升数学题的步骤可以被规则验证代码可以用编译器验证逻辑推理可以被穷举或反例检查。因为验证成本低模型生成的数据可以自动过滤掉错误样本只保留正确且高质量的部分再用于下一轮训练。1.3 这项研究真正的价值把模型变强的方式从“堆参数量”转向“堆数据效率”堆万亿参数的路径对绝大多数团队都不现实。训练成本、硬件投入、推理延迟、部署难度都会指数级上升。而“自我造题、自我迭代”的思路核心是用一个小模型加上验证器在有限算力下持续生产高质量训练数据再把这些数据喂回模型形成“模型变强 - 数据变好 - 模型再变强”的正向循环。从工程角度看这个循环的每一环都可以独立优化生成模型的采样策略、验证器的严格程度、数据筛选的去重策略、训练的超参数配置。只要闭环本身是稳定的模型规模反而变成了一个可以灵活选择的因素。对比维度万亿稠密模型35B-A3B 这类 MoE 模型训练成本极高需要大规模集群中等单机多卡可尝试推理成本极高显存和算力压力大较低激活参数少领域数据定制成本高迭代慢适合自我迭代式快速定制适用场景通用底座、复杂长程任务专项任务、私有化部署、边缘场景2. “自我造题”到底是什么从种子数据到合成数据闭环2.1 三个常用技术名词的底层逻辑在开源社区和论文里这类方法有多个名字Self-Instruct、Self-Play、Self-Refine。它们的底层逻辑是一致的让模型基于少量种子数据生成更多数据再用某种方式验证和筛选把高质量数据放回训练集。Self-Instruct 强调“模型自己生成指令和答案”适合文本指令数据扩展。Self-Play 强调“模型和自己对弈”在数学、棋类、对抗博弈中更常见。Self-Refine 强调“模型自己生成、自己评价、自己修正”适合错误分析和改写。在实际工程里这三者经常混合使用。比如先让模型生成 100 道数学题并写出推导过程再用另一个模型或规则验证器判断推导是否正确错误答案打回重写或者直接丢弃。2.2 一条可落地的最小数据闭环先给出一条可实现的闭环流程后续章节会围绕它展开。def build_synthetic_dataset(seed_questions, generator, verifier, n_samples4, temperature0.7, max_attempts3): samples [] for question in seed_questions: for _ in range(n_samples): for attempt in range(max_attempts): prompt build_prompt(question) response generator.generate(prompt, temperaturetemperature, top_p0.9, max_tokens1024) if verifier.check(question, response): samples.append({ instruction: question, output: response, source: self-instruct, round: current_round, }) break # 超过 max_attempts 则丢弃 return samples这个流程的四个关键点是种子问题要尽量覆盖目标领域避免生成数据塌缩到同一类题型。采样温度不能太高否则生成内容发散也不能太低否则多样性不足。验证器是闭环的核心规则、编译器、符号计算器、更强模型都可以。每一轮新模型训练完后可以重新生成下一轮数据形成迭代。这里要注意如果原始材料没有给出明确版本和官方流程落地前要先确认生成模型、验证器、训练框架之间的版本兼容性。2.3 数据生成中的关键参数和质量控制合成数据的质量主要由采样参数和验证策略决定。参数常见设置影响temperature0.3 到 0.9越高多样性越高但错误率也越高top_p0.8 到 0.95控制采样候选范围max_tokens512 到 2048太短答不完太长浪费算力n_samples2 到 8每条种子问题生成多少候选答案max_attempts2 到 5生成失败后最多重试几次质量控制除了验证答案正确性还需要做格式统一和去重。格式统一可以要求模型按“思路-步骤-最终答案”的模板输出方便后续解析。去重可以用 MinHash 或者基于嵌入向量的相似度计算防止同质化数据在训练集中反复出现。3. 用开源工具复现一个“自我迭代”训练实验3.1 环境准备和依赖选择这里按常见项目组合来准备用于演示思路。实际项目要结合自己的包名、路径和版本调整。Python 3.10 或 3.11PyTorch 2.x需要与 CUDA 版本匹配LLaMA-Factory用于 SFT 和 LoRA 训练vLLM用于推理服务和 TTFT 测试模型一个支持 MoE 的底座模型例如 Qwen 系列的 MoE 版本安装依赖时建议先创建虚拟环境再安装 PyTorch。如果使用国内镜像可以配置 pip 的 index-url避免下载超时。python -m venv venv source venv/bin/activate pip install torch --index-url https://download.pytorch.org/whl/cu121 pip install vllm pip install llamafactory安装完成后先用一个简单脚本确认模型可以加载from vllm import LLM llm LLM(model/models/your-moe-model, tensor_parallel_size2) print(llm.generate(11))3.2 种子数据准备与题目生成种子数据不需要很多几百到几千条都行。关键是覆盖目标任务的题型分布。以数学任务为例可以准备包含不同难度、不同知识点的题目存成 JSONL 文件。{instruction: 求解方程 3x 5 20并给出完整推导过程。, output: } {instruction: 计算 2^10 除以 17 的余数要求说明每一步计算。, output: }注意这里的 output 为空是为了让生成模型自己补全。实际生成脚本会用 system prompt 和 instruction 拼出完整 prompt再调用 vLLM 生成答案。3.3 训练配置LoRA/全参、学习率、上下文长度在 LLaMA-Factory 中SFT 训练通过 YAML 文件配置。以下是一个常见示例模型路径和数据集路径需要根据实际环境替换。model_name_or_path: /models/your-moe-model template: qwen stage: sft finetuning_type: lora dataset: round1.jsonl cutoff_len: 4096 learning_rate: 2.0e-4 num_train_epochs: 3 per_device_train_batch_size: 4 gradient_accumulation_steps: 8 lr_scheduler_type: cosine optim: adamw_torch output_dir: output/round1 lora_rank: 64 lora_alpha: 128这里有几个参数需要重点关注cutoff_len如果数学推导很长建议不低于 4096否则答案会被截断。per_device_train_batch_size 和 gradient_accumulation_steps两者相乘得到全局 batch size会影响训练稳定性。lora_rankLoRA 的秩控制微调参数量。任务复杂时适当增大。训练启动命令一般是这样llamafactory-cli train configs/round1.yaml训练结束后把 LoRA 权重和底座模型合并或者直接加载 adapter用于下一轮数据生成。3.4 多轮迭代训练的执行顺序第一轮训练完成后把合并或导出后的模型作为新的生成器重新执行数据生成、验证、筛选、训练流程。命令顺序可以用脚本统一维护。# 第一轮 python data_loop.py --round 1 --model /models/your-moe-model --seed data/seed.jsonl --output data/round1.jsonl llamafactory-cli train configs/round1.yaml # 第二轮 python data_loop.py --round 2 --model output/round1/merged --seed data/seed.jsonl --output data/round2.jsonl llamafactory-cli train configs/round2.yaml每一轮的训练数据建议保留历史真实数据再按一定比例混入新的合成数据避免模型分布漂移。3.5 评测不要只看准确率还要看推理耗时和鲁棒性自我迭代最怕一件事模型在训练集和评测集上分数很高但一到真实场景就崩。所以评测要多维度看。可以用 lm-evaluation-harness 跑常见任务lm_eval --model vllm \ --model_args pretrained/models/output/round1,tensor_parallel_size2 \ --tasks gsm8k,hendrycks_math \ --batch_size auto \ --output_path eval/round1除了准确率还要看输出格式是否符合预期。很多模型在评测集上得分高是因为评测题和训练题高度同源换一个新题就会暴露推理过程冗余、中间步骤跳步、最终答案错误等问题。建议保留一组从未参与生成的“留出题库”每一轮都用同一组题做回归测试。4. 推理侧的事实35B MoE 为什么 TTFT 可能更高4.1 TTFT 是什么为什么用户很敏感TTFT 是 Time To First Token 的缩写指从请求发起到模型返回第一个 token 的时间。用户感知的“首字等待”主要就是它。对于交互式应用比如 AI 助手、对话机器人TTFT 过高会让用户觉得系统卡顿。一个常见的现象是MoE 模型虽然激活参数量少后续生成 token 的速度也不慢但 TTFT 可能反而比同量级的稠密模型更高。这个现象在一些开源模型的问答里经常被提到需要从推理机制里找原因。4.2 MoE 架构下 TTFT 偏高的常见原因TTFT 对应的计算阶段是 prefill也就是一次性处理完整 prompt 并生成 KV cache 的阶段。MoE 架构在 prefill 阶段会引入几类额外开销路由计算每个 token 都要经过 router决定激活哪些专家这个计算虽然轻量但在 token 数量很大时会累积。专家参数读取虽然只激活少量专家但不同 token 可能激活不同专家gating 之后需要从显存读取对应专家参数。如果专家权重没有被完整放入显存或者跨卡分布不均就可能出现等待。通信开销当模型使用 expert parallel 时token 需要路由到对应的 GPU 上执行专家计算跨设备通信会显著增加 prefill 时间。批处理排队并发请求到达时如果框架没有及时把请求组 batch或者 batch 内 prompt 长度差异过大长 prompt 会拖慢整个 batch 的 prefill。4.3 排查 TTFT 问题的一般步骤先确认瓶颈在 prefill 本身还是排队导致的再逐项检查。现象常见原因检查方式解决方向首 token 慢后续 token 正常prefill 阶段 token 太多统计平均 prompt 长度观察 prefill time限制输入长度使用 chunked prefill并发升高后 TTFT 明显上升请求排队或 batch 过大查看框架 queue 长度和 GPU util控制并发调大 max_num_seqs使用动态批处理MoE 模型 TTFT 高专家参数分布不均或跨卡通信检查 tensor_parallel_size 和 expert parallel 配置增大并行度确保专家权重完整驻留显存TTFT 和响应速度同时恶化显存不足或权重换入换出nvidia-smi 观察显存占用减小 batch size或在更小模型上验证在 vLLM 中测试 TTFT 可以用一段简单脚本打印每个请求的首 token 延迟而不要只看平均生成速度。5. 三个必须避开的坑数据污染、模型坍缩和评估失真5.1 模型自己出题也可能产出重复或错误数据现象是生成脚本跑了一整天得到上万条数据但去重后发现有效样本只有几百条或者数据看起来格式正确答案却错误。原因通常是采样温度设置太高、验证器太弱、种子问题太少。检查方式可以是按 instruction 文本做精确去重统计重复率。随机抽样 50 条生成结果人工检查正确率。用验证器分别统计首轮通过率和最终通过率。解决方案是提高验证器强度、增加种子问题多样性、降低 temperature并对通过数据进行进一步清洗。要注意验证器不是摆设。规则验证器最怕模型写“绕弯答案”例如先给错误答案再在解释里悄悄改口。因此设计验证器时最好要求模型在最终输出中给出一个可机读的答案标记用正则或符号计算器单独抽取并校验。5.2 多轮迭代后模型坍缩现象是第一轮训练后效果提升明显第二轮提升变小第三轮分数反而下降或者生成数据的多样性明显下降。原因是模型不断用自己生成的数据训练概率分布逐渐收窄模型开始输出模板化答案遇到新题型时能力减弱。这是典型的“模型坍缩”。对策是每轮保留一部分原始真实数据不要只依赖合成数据同时在生成阶段刻意提高 temperature扩大采样空间还可以用另一个不同规模的模型做生成器增加数据多样性。5.3 测试集泄漏与评估集污染现象是模型在本地评测集上得分很高上线后表现明显偏差。最常见的原因是生成数据时模型见过评测题或相似题评测结果虚高。防止方法包括建立独立的留出题集任何生成脚本都不得读取。对合成数据做和评测集的重叠检测删除重复或高相似样本。每一轮评估都使用同一组 hidden test不把测试集加入训练提示语。可以将这些坑整理成一张速查表方便团队评审时逐项对齐。问题现象检查方式处理建议数据重复去重后有效样本少统计重复率增加种子数据、降低 temperature模型坍缩多轮迭代后分数下降对比每轮生成多样性保留真实数据、混合生成器评估失真评测高但线上差检测测试集重叠独立 hidden set、去重、隔离测试集6. 从“35B干赢万亿”到大模型工程实践的可复用清单6.1 环境检查清单在做自我迭代实验前先逐项确认环境。Python 版本和 PyTorch 版本匹配。CUDA 驱动和 PyTorch 的 CUDA 版本一致。模型权重能正常加载至少能生成一句完整回复。验证器能跑通单条样例。训练脚本能在 1 个 epoch 上跑完确认数据和配置没有格式错误。数据生成脚本的输出路径和训练脚本的 dataset 路径一致。6.2 数据迭代发布前的检查清单每一轮训练数据回流前建议按以下清单走一遍。数据量是否达到预期格式是否符合训练框架要求。是否完成去重和格式清洗。是否用验证器随机抽检过正确率。是否保留了真实种子数据避免全量合成数据。是否检查过合成数据与评测集的重复。是否记录了本轮数据生成时用的模型版本和采样参数方便回滚。6.3 小模型项目的落地建议与扩展方向35B 干赢万亿参数大模型并不代表参数量不重要而是说明在约束条件下数据策略和训练策略可以带来更大的边际收益。实际项目选型时建议把模型规模、推理时延、数据迭代速度和场景复杂度放在一起权衡。下一步可以扩展的方向包括用奖励模型替代规则验证器扩大可验证任务的类型。在生成阶段引入多模型投票提高答案稳定性。使用树搜索生成中间步骤把推理路径变成训练数据。对合成数据做课程学习按难度从低到高组织训练。把 TTFT 与数据生成速度纳入同一套监控避免训练迭代拖垮推理服务。如果只做一件事建议先搭建一条“10 条种子问题 - 生成 100 条数据 - 微调 - 评测”的最小闭环跑通后再逐步扩大数据量和模型规模。这个闭环跑通一次比看再多参数对比都有用。