从自我造题到自我迭代：35B模型如何用数据飞轮逼近万亿参数

最近“35B 干赢万亿参数大模型”这个话题在 AI 社区里讨论度很高，核心点倒不只是“小模型打败大模型”这个结果，而是背后的训练思路变了：模型开始给自己造题，再靠着自我迭代一步步变强。很多同学看到这类新闻第一反应是“这又是营销号标题党吧”，但深入研究后会发现，这其实是数据驱动范式下很扎实的一条技术路线。

这篇文章我想从一个工程开发者的视角，把这个话题拆开来看：先讲清楚“自我造题 + 自我迭代”到底是怎么工作的，再给出一套简化的可运行代码闭环，最后聊一聊 35B 规模模型在部署和推理阶段可能遇到的工程问题，包括很多人关心的 TTFT（Time To First Token，首 token 延迟）偏高问题。

无论你是准备入门大模型训练，还是已经在做模型微调和本地部署，这篇文章都可以给你一个比较完整的参考。

1. 从“拼参数”到“拼数据”：一个 35B 模型的新故事

1.1 为什么 35B 模型能叫板万亿参数

过去两年，大模型的军备竞赛几乎等于参数竞赛：从百亿到千亿，再到万亿，模型越大，似乎能力就越强。这种“大力出奇迹”的思路在早期非常有效，因为它直接提升了模型的容量、记忆能力和泛化表现。

但随着模型规模增长，边际收益开始下降。一个万亿参数模型的训练成本极高，推理成本也不低，不是所有团队都有能力玩得起。更重要的是，参数规模只是能力的一个维度，数据质量和训练范式往往对最终效果影响更大。

最近上海交通大学相关研究团队探索的方向，就是在这个背景下出现的。通过让 35B 规模的模型自己生成题目、自己作答、自我筛选高质量数据，并在训练过程中不断迭代，模型在部分任务上的表现可以逼近甚至超过规模大得多的模型。

乍一听很玄，但背后的逻辑并不复杂：模型的能力上限，除了取决于参数容量，还取决于它见过多少高质量、高覆盖度的数据。如果能让模型不断发现自己的盲区，并针对性地补齐，那么在一个相对较小的模型上，也能激发出相当强的能力。

1.2 这套路线的关键词：自我造题、自我迭代、闭环评估

要理解这种训练方式，先要抓住几个关键词。

自我造题（Self-Question Generation）不是由人类标注员去写训练题，而是让模型根据已有知识、已有数据和任务目标，自己生成新的问题或任务。这个过程可以不断扩展数据覆盖范围，尤其是那些原始语料中没有充分覆盖的“长尾场景”。

自我迭代（Self-Training / Iterative Training）模型生成新数据后，经过筛选、修正，再拿这些数据继续训练出一个新版本。新版本再次生成数据、再次训练，循环往复。每一轮迭代，模型都在用自己的能力“向上爬”。

闭环评估（Closed-loop Evaluation）如果模型自己出题又自己回答，很容易“自说自话”——出的题越来越简单，给出的答案看似流畅但其实是错误的，这就是典型的模型退化。所以必须引入一个评估机制，例如规则校验、验证器模型，或者由更强的模型打分，来确保每一轮留下的数据是真正高质量、有价值的。

从工程角度看，这其实就是一个“数据飞轮”：生成 → 评估 → 筛选 → 训练 → 再生成。关键在于每一环都要可控、可度量。

2. 核心原理拆解：模型如何“给自己造题”

2.1 自我造题的本质是数据增强

我们可以把自我造题看成一种更高级的数据增强。传统的 NLP 数据增强做的是同义词替换、回译、随机删除等操作，本质上是把已有数据做轻微扰动。而自我造题是让模型基于“任务意图”和“已知答案”反向生成问题，生成的内容在语义上更丰富。

比如，我们希望模型掌握“Python 异常处理”这个知识点，传统方式需要人工找几千道笔试题目。而自我造题的做法是：

1. 给模型一段关于异常处理的资料，或者一个相关的简单问答对。
2. 让模型根据资料生成多个角度的问题。
3. 再让模型回答自己生成的问题。
4. 用验证器判断答案是否正确、逻辑是否通顺。

这个过程可以批量执行，而且生成问题的角度往往比人工设计更发散，能覆盖更多边界场景。

2.2 质量过滤是整个流程的灵魂

自我造题最大的风险，不是生成不了题目，而是生成的题目质量太差。如果模型生成的题目本身就是错误诱导型的，或者答案存在事实幻觉，那么把这些数据拿去训练，模型只能越训越差。

所以一个严格的训练闭环必须包含质量过滤层。常见的做法有：

在真实项目中，这些方法通常是组合使用的。先用规则过滤掉低质量样本，再抽样交给强模型或人工评估，形成一套“机器初筛 + 人为抽检”的机制。

2.3 迭代训练：一轮、两轮、三轮……直到收敛

迭代训练的过程可以这样理解：

• 第 0 轮：用已有的种子数据训练一个基础模型。
• 第 1 轮：用基础模型生成一批新题，经过筛选后加入训练集，训练出 v1 版本。
• 第 2 轮：用 v1 版本生成新题，重点去覆盖上一轮模型答错的题目，训练出 v2 版本。
• 第 N 轮：直到模型在验证集上的提升不再明显，或者达到预先设定的数据量上限。

每一轮迭代中，需要重点记录模型在哪些问题上得分低、在哪些问题上得分高。下一轮造题时，应该让模型多生成那些让它“翻车”的题目类型，形成一种针对性的补强训练。

这和人类备考很像：刷第一遍题时发现薄弱点，然后重点做错题，再做第二遍题，分数自然就上去了。

3. 为什么要用 35B 而不是 7B 或万亿参数

3.1 参数规模和能力的“甜点区间”

7B 模型成本低、速度快，但复杂推理能力往往不足。当模型能力不够时，它“自己给自己造题”就容易产生一种虚假繁荣：题目简单、答案套路化、评估得分虚高，但放到真实场景下很快就露馅。

万亿参数模型能力最强，但训练和推理成本太高，普通团队很难持续做多轮迭代。而且模型太大时，单次推理耗时明显增加，生成一批数据的成本也会被放大很多倍。

35B 处于一个比较合适的“甜点区间”：参数量足够支撑复杂的推理和生成任务，又不会像千亿、万亿模型那样让训练和部署成本失控。多轮迭代所产生的算力消耗，是很多高校实验室和中小团队可以承受的。

3.2 算力成本与部署成本

从部署角度看，35B 模型经过 4bit 量化后，显存需求大概在 20GB 左右，普通消费级显卡勉强能跑。如果是 FP16 精度，大概需要 70GB 显存，需要专业显卡或多卡环境。

相比万亿参数模型动辄需要数十张甚至上百张高端 GPU 才能部署，35B 模型显然更适合做实验迭代和私有化部署。这种成本优势，让“多轮自我迭代”成为可能。

3.3 与知识蒸馏、强化学习的联系与区别

很多人会把这种“自我造题 + 自我迭代”和知识蒸馏、强化学习混淆，这里简单区分一下：

知识蒸馏通常用一个强大的教师模型生成数据，训练一个小学生模型。核心是“学生从教师那里学知识”，教师本身不参与迭代。

强化学习（RLHF/RLVR）模型生成结果后，通过奖励模型或规则函数计算奖励，再用策略梯度等方法更新模型。自我迭代可以看作一种简化的策略优化，只不过它的“奖励信号”更多体现在数据筛选上，而不一定是端到端的梯度更新。

自我迭代训练教师和学生可以是同一个模型，上一轮的模型生成数据，训练出下一轮的模型，然后再由新模型去生成数据。整个过程更像“自己当自己的老师”，而不是依赖一个固定的大模型。

这种范式的优势是：模型的最终能力不完全依赖于某个外部教师模型的强弱，只要数据筛选机制足够可靠，模型就能持续进步。

4. 实战：搭建一个轻量级“自我造题 + 自我迭代”训练闭环

理论讲再多，不如动手跑一遍。下面我用一套示例代码演示：如何用很简单的流程，实现一个迷你版的“自我造题 + 自我迭代”闭环。

需要注意的是，真实的大模型训练远比这个复杂，下面的代码是为了展示核心流程，帮助你理解框架，不能直接用于生产级训练。

4.1 环境准备

建议使用 Python 3.10 或更高版本，并创建一个独立的虚拟环境。

python -m venv venv source venv/bin/activate # Windows 下使用 venv\Scripts\activate

安装需要的依赖：

pip install torch transformers datasets accelerate

版本说明：torch建议安装当前官方稳定版，transformers和datasets也建议使用较新版本。如果你的机器有 GPU，请安装对应 CUDA 版本的 PyTorch，具体命令参考 PyTorch 官网。

4.2 项目结构

self_train_demo/ ├── config.yaml ├── scripts/ │ ├── generate_questions.py │ ├── generate_answers.py │ ├── filter_samples.py │ └── train_loop.py └── data/ ├── seed.jsonl ├── round1/ └── round2/

config.yaml用来保存迭代轮数、模型路径、最大生成长度等参数，避免把超参数硬编码在代码里。

# config.yaml model_name: "Qwen/Qwen2.5-7B-Instruct" # 示例模型，可按实际环境调整 max_new_tokens: 512 temperature: 0.7 filter_min_length: 50 iterations: 3

说明：示例中使用的是 7B 模型，主要是为了演示流程。实际复现“35B 自我迭代”思路时，可以把model_name换成一个 35B 规模的开源模型。

4.3 第一轮：生成训练题目

我们先准备一小批种子数据，作为模型生成题目的起点。

{"topic": "Python 异常处理", "context": "try/except/finally 的基本用法"} {"topic": "SQL 索引失效", "context": "索引列上使用函数导致索引失效"} {"topic": "大模型推理优化", "context": "KV Cache 与首 token 延迟的关系"}

生成题目的脚本如下：

# scripts/generate_questions.py import json import random seed_file = "data/seed.jsonl" output_file = "data/round1/questions.jsonl" question_templates = [ "请结合具体示例，解释{topic}的核心原理。", "在{topic}中，最常见的坑是什么？如何排查和解决？", "如果要给初学者讲清楚{topic}，你会怎么组织讲解思路？", "针对{topic}，你能设计一个进阶练习题吗？", ] def load_seed(file_path): with open(file_path, "r", encoding="utf-8") as f: return [json.loads(line) for line in f if line.strip()] def generate_question(item, template): return template.format(topic=item["topic"]) def main(): seed_data = load_seed(seed_file) with open(output_file, "w", encoding="utf-8") as f: for item in seed_data: for template in question_templates: question = generate_question(item, template) record = { "topic": item["topic"], "context": item.get("context", ""), "question": question, } f.write(json.dumps(record, ensure_ascii=False) + "\n") print(f"生成题目完成，共 {len(seed_data) * len(question_templates)} 条，输出到 {output_file}") if __name__ == "__main__": main()

这段代码的作用是：读取种子数据中的主题，结合预定义的模板生成多个角度的问题。这里使用模板是为了演示路径，实际项目中可以让模型基于context自由生成问题，生成方式会灵活得多。

4.4 第二轮：模型回答题目

有了题目之后，下一步是让模型自己作答。我们用 Transformers 的pipeline或底层 API 加载模型。

# scripts/generate_answers.py import json import torch from transformers import AutoModelForCausalLM, AutoTokenizer question_file = "data/round1/questions.jsonl" answer_file = "data/round1/answers.jsonl" model_name = "Qwen/Qwen2.5-7B-Instruct" def load_questions(file_path): with open(file_path, "r", encoding="utf-8") as f: return [json.loads(line) for line in f if line.strip()] def main(): tokenizer = AutoTokenizer.from_pretrained(model_name) model = AutoModelForCausalLM.from_pretrained( model_name, torch_dtype=torch.float16, device_map="auto", ) questions = load_questions(question_file) with open(answer_file, "w", encoding="utf-8") as f: for idx, item in enumerate(questions): messages = [ {"role": "system", "content": "你是一个严谨的技术助手，请用清晰、准确的语言回答问题。"}, {"role": "user", "content": item["question"]}, ] text = tokenizer.apply_chat_template( messages, tokenize=False, add_generation_prompt=True, ) inputs = tokenizer(text, return_tensors="pt").to(model.device) outputs = model.generate( **inputs, max_new_tokens=512, do_sample=True, temperature=0.7, ) answer = tokenizer.decode(outputs[0][inputs["input_ids"].shape[1]:], skip_special_tokens=True) record = { "id": idx, "topic": item["topic"], "question": item["question"], "answer": answer.strip(), } f.write(json.dumps(record, ensure_ascii=False) + "\n") print(f"[{idx + 1}/{len(questions)}] 生成完成") print(f"答案生成完毕，输出到 {answer_file}") if __name__ == "__main__": main()

这段代码里需要注意几个地方：

• apply_chat_template会按照模型自身的对话格式拼接消息，不同模型的模板不同，用这个方法最稳妥。
• max_new_tokens控制生成的最大 token 数，避免模型无限输出。
• do_sample和temperature控制生成的随机性。自我造题阶段需要一定的随机性，才能让题目更多样。

4.5 第三轮：质量过滤

生成答案之后，不能直接拿去训练，必须过滤。下面是一个简化版过滤脚本。

# scripts/filter_samples.py import json answer_file = "data/round1/answers.jsonl" filtered_file = "data/round1/filtered.jsonl" MIN_LENGTH = 50 def is_high_quality(record): answer = record["answer"] # 1. 长度过滤：太短说明回答不完整 if len(answer) < MIN_LENGTH: return False # 2. 关键词过滤：判断回答是否覆盖了主题相关内容 topic_keywords = { "Python 异常处理": ["try", "except", "finally", "异常"], "SQL 索引失效": ["索引", "查询", "优化"], "大模型推理优化": ["KV", "缓存", "推理", "延迟"], } topic = record["topic"] keywords = topic_keywords.get(topic, []) if keywords: if not any(keyword.lower() in answer.lower() for keyword in keywords): return False # 3. 简单去重：过滤重复内容 if "不知道" in answer or "我不确定" in answer: return False return True def main(): passed = 0 with open(answer_file, "r", encoding="utf-8") as fin, \ open(filtered_file, "w", encoding="utf-8") as fout: for line in fin: if not line.strip(): continue record = json.loads(line) if is_high_quality(record): fout.write(json.dumps(record, ensure_ascii=False) + "\n") passed += 1 print(f"过滤完成，保留 {passed} 条高质量样本，输出到 {filtered_file}") if __name__ == "__main__": main()

真实项目里，这种规则过滤只能作为第一道防线。更好的做法是训练一个小型验证器模型，或者调用一个强模型对回答进行打分。打分提示词可以参考下面这种写法：

请对以下回答进行评分，评分标准包括： 1. 正确性：是否有事实错误 2. 完整性：是否覆盖问题核心 3. 清晰度：是否容易理解 请输出 1-5 分，并给出简短理由。

用这种提示词调用强模型，可以得到一个相对可靠的“数据质量分”，再根据分数阈值决定是否保留样本。

4.6 第四轮：微调与下一轮迭代

过滤后的数据需要转成训练集，然后对模型做一次有监督微调。

# scripts/train_loop.py import json from datasets import Dataset from transformers import ( AutoModelForCausalLM, AutoTokenizer, Trainer, TrainingArguments, ) filtered_file = "data/round1/filtered.jsonl" output_dir = "models/round1" def load_filtered_data(file_path): samples = [] with open(file_path, "r", encoding="utf-8") as f: for line in f: if not line.strip(): continue record = json.loads(line) samples.append({ "question": record["question"], "answer": record["answer"], }) return samples def build_dataset(samples, tokenizer): texts = [] for sample in samples: messages = [ {"role": "user", "content": sample["question"]}, {"role": "assistant", "content": sample["answer"]}, ] text = tokenizer.apply_chat_template(messages, tokenize=False) texts.append(text) encodings = tokenizer( texts, truncation=True, padding=True, max_length=1024, return_tensors="pt", ) encodings["labels"] = encodings["input_ids"].clone() return Dataset.from_dict(encodings) def main(): tokenizer = AutoTokenizer.from_pretrained("Qwen/Qwen2.5-7B-Instruct") model = AutoModelForCausalLM.from_pretrained( "Qwen/Qwen2.5-7B-Instruct", torch_dtype="auto", device_map="auto", ) samples = load_filtered_data(filtered_file) dataset = build_dataset(samples, tokenizer) training_args = TrainingArguments( output_dir=output_dir, num_train_epochs=3, per_device_train_batch_size=1, gradient_accumulation_steps=4, save_strategy="epoch", logging_steps=10, fp16=True, report_to="none", ) trainer = Trainer( model=model, args=training_args, train_dataset=dataset, ) trainer.train() trainer.save_model(output_dir) tokenizer.save_pretrained(output_dir) print(f"第一轮微调完成，模型保存到 {output_dir}") if __name__ == "__main__": main()

训练完成后，把output_dir作为下一轮的model_name，重新执行“生成题目 → 生成答案 → 过滤 → 微调”的流程，就实现了自我迭代。

4.7 运行与验证

运行顺序如下：

cd self_train_demo python scripts/generate_questions.py python scripts/generate_answers.py python scripts/filter_samples.py python scripts/train_loop.py

每轮迭代结束后，建议在固定验证集上评测模型效果，观察指标是否仍在提升。如果连续两轮指标没有明显变化，说明训练已经趋于收敛，继续迭代的意义不大，应该考虑调整数据生成策略或模型容量。

5. 从训练回到部署：35B 规模模型的本地落地经验

训练只是一个环节，对一个 35B 规模模型来说，部署和推理同样值得关注。模型做自我迭代时，每轮都要生成大量数据，如果推理速度太慢，整个实验周期会被大幅拉长。

5.1 显存与内存估算思路

35B 模型以 FP16 精度加载时，光权重就需要大约 70GB 显存。如果做 4bit 量化，权重可压缩到 20GB 左右，配合少量 KV Cache，单张 24GB 显存的消费级显卡有机会跑起来。

估算公式可以简化成：

模型权重显存 ≈ 参数量 × 每个参数的字节数 FP16：35B × 2 字节 ≈ 70GB INT8：35B × 1 字节 ≈ 35GB INT4：35B × 0.5 字节 ≈ 17.5GB

这个估算只是权重大小，实际推理还需要额外的 KV Cache、激活值、CUDA context 等内存，所以最终显存需求通常会更高。部署前建议预留 20%-30% 的余量。

5.2 Ollama 部署示例

如果你只想快速把模型跑起来体验效果，用 Ollama 是一条捷径。Ollama 支持从模型仓库拉取量化后的模型，一条命令就能启动本地服务。

ollama pull qwen2.5:35b ollama run qwen2.5:35b

启动后可以调用本地 API：

curl http://localhost:11434/api/generate -d '{ "model": "qwen2.5:35b", "prompt": "请用通俗易懂的话解释一下什么是 KV Cache。", "stream": false }'

提示：不同版本的 Ollama 对模型命名、API 参数略有差异，具体以你安装的版本为准。

5.3 为什么 MoE 架构的 35B 模型 TTFT 可能偏高

很多人在讨论“为什么 Qwen 3.6 35B A3B 的 TTFT 比较高”这类问题。这里先说结论：TTFT 高不一定代表模型变笨了，而是推理流程中存在额外的计算开销。

TTFT 指的是从用户发起请求到模型生成第一个 token 之间的耗时。影响 TTFT 的主要因素有：

MoE（Mixture of Experts，混合专家）模型虽然总参数量很大，但每个 token 只激活一部分专家，推理时真正参与计算的参数并不多。比如 35B A3B，意思是总参数 35B，激活参数只有 3B，理论上推理速度应该比同规模稠密模型快。

但实际情况是：MoE 模型在 prefill 阶段需要把所有专家加载进显存，路由网络要计算每个 token 与每个专家的匹配概率。如果推理框架没有针对 MoE 做优化，或者硬件无法同时容纳所有专家，那么 TTFT 反而不低。

5.4 推理优化方向

想让 35B 模型在实际项目中跑得更顺畅，可以考虑以下优化方向：

• 使用 vLLM、TensorRT-LLM 等推理框架，它们对 KV Cache 和 MoE 路由做了深度优化。
• 启用前缀缓存（prefix caching），当多个请求共享相同系统提示词时，可以复用 prefill 结果。
• 减少输入长度，控制 context 大小，LLM 处理 long context 时 TTFT 会线性增长。
• 做量化部署，INT8/INT4 可以降低显存带宽压力，但会带来一定精度损失。
• 使用多卡并行或异步调度，提升整体吞吐。

6. 常见问题与排查思路

在实际实践过程中，最容易踩到的坑主要集中在数据生成、训练稳定性、部署推理三个环节。

这里想重点提醒一个容易被忽略的坑：多轮迭代后模型能力退化，这是一个真实存在的风险。由于每一轮训练数据都是由上一轮模型生成的，如果某一步过滤不严，错误信息就会在后续迭代中不断放大，最终导致模型产生“自我崩溃”（self-collapse）现象。预防措施是保留一部分原始种子数据，每一轮混合一定比例的人类高质量数据，同时每轮迭代都在固定 benchmark 上做回归测试。

7. 最佳实践与工程建议

7.1 数据版权与合法授权

自我造题虽然能自动生成大量数据，但生成过程中模型可能会隐式引用训练语料中的内容。在实际项目中要特别注意：

• 不要使用未经授权爬取的书籍、论文、商业文档。
• 对于种子数据，要确保来源有合法授权。
• 生成的数据如果要对外发布或商用，建议做一轮敏感信息识别和版权审查。

7.2 验证器与奖励模型

不要完全相信模型自己生成的答案。一个严谨的训练闭环应该包含多层验证：

• 第一层：规则校验，如格式、长度、关键词。
• 第二层：模型互评，使用另一个模型对生成结果打分。
• 第三层：人工抽检，随机抽取 5%-10% 的样本进行人工审核。

人工抽检虽然成本高，但它能发现验证器模型的盲区，也能帮助我们持续改进自动过滤规则。

7.3 训练日志与版本管理

多轮迭代训练会产生多个版本的模型和数据集，如果不做版本管理，很容易出现“不知道某个数据是哪一轮生成的”“这个模型是用哪个数据集训练的”这种混乱情况。

建议为每一轮迭代建立独立目录，并记录：

• 迭代轮次编号。
• 种子数据来源。
• 生成数据的提示词和采样参数。
• 过滤规则和保留数量。
• 训练超参数。
• 验证集评测结果。

这些信息可以写在一个 CSV 或 Markdown 文件里，也可以直接作为模型目录下的 README 保存。

7.4 安全边界与权限控制

如果模型最终要接入业务系统，不能忽略安全边界：

• 用户输入要经过内容安全过滤，防止恶意 prompt 注入。
• 模型输出也要做合规检查，不能把未经审核的内容直接展示给用户。
• 训练和标注过程中，涉及用户数据的部分要脱敏处理。
• 部署到公网前，确认服务具备认证、限流、审计能力。

8. 从学术亮点到工程能力

“35B 干赢万亿参数”听起来很惊艳，但真正的价值不在于参数数量的对比，而在于它验证了一条新的能力提升路径：高质量数据的自主生产能力 + 闭环迭代机制。

以前我们想提高模型能力，第一反应是加参数、加数据、加算力。现在我们看到，在模型参数不变甚至更小的情况下，通过让模型自己出题、自己纠错、自己迭代，也能走出一条持续进化的路。

如果你是做应用开发的，可以从数据生成与质量过滤入手，把这套思路用在垂直领域的数据增强上。如果你是做算法研究的，可以进一步探索验证器设计、迭代收敛条件、以及如何防止自我崩溃。如果你只是对大模型感兴趣，先把文章里的简化实战跑一遍，你就对“自我迭代”不再感到神秘了。

模型的成长，本质上也是一次次与自己的薄弱点较量的过程。对 35B 如此，对开发者亦然。