这次我们来看一个反常识的方向35B 参数模型居然能在部分任务上干赢万亿参数大模型。这个项目来自上海交通大学团队核心思路不是堆参数而是让模型“自己给自己造题”再通过迭代训练持续变强。说白了这是一套“数据自举 模型自进化”的训练范式。模型不再只依赖人类标注或者通用语料而是能自己生成训练样本、自己做筛选、自己评估效果再拿这些数据继续训练。这个过程循环往复模型能力就能滚动提升。这篇文章不聊玄学直接拆三件事“35B 干赢万亿模型”到底是怎么做到的核心机制是什么。如果你想在自己环境里复现类似能力需要准备什么硬件、怎么部署模型、怎么验证效果。自我造题和自我迭代的流程怎么设计测试时最容易踩哪些坑。如果你想做垂直领域大模型、模型微调、数据工程或者单纯好奇“小模型怎么弯道超车”这篇建议收藏。1. 核心能力速览先给一版快速参考让你在往下读之前就知道这套方案的重点。能力项说明技术方向大模型自我造题合成数据生成 自我迭代训练核心卖点35B 参数模型在部分评测或任务上超过万亿参数模型关键机制模型自己生成训练题、自动筛选、迭代训练、效果评估与传统训练差异不依赖大规模人工标注核心是高质量数据自举对模型架构要求没有严格限制稠密模型和 MoE 模型都可以套用显存需求取决于具体模型规模35B 有一定压力需按量化方案测试是否支持 CPU可以推理但训练和自迭代不适合 CPU是否支持批量任务支持造题、筛选、评测都可以做成批量流水线是否支持 API部署后可通过 API 调用模型推理能力适合场景垂直领域模型增强、数据飞轮构建、评测集生成、小模型能力提升使用边界合成数据存在版权与事实性风险需人工审核和合规评估这几点里最值得关注的是“自我造题”和“自我迭代”两个机制。它们相当于把数据工程和训练流程做成一个闭环模型越用越强而不是训完就固定。2. 这套能力的本质参数不是唯一变量先说清楚一点35B 干赢万亿参数模型并不是说小模型在一切任务上都碾压大模型。更合理的理解是在特定任务、特定评测集、特定知识范围内小模型通过更高质量的训练数据达到了超过大模型的局部效果。2.1 为什么参数变小反而能赢大模型参数多但训练数据如果不够聚焦能力是“广而浅”的。35B 模型如果针对某个领域做定向数据增强就能在局部任务上做到“窄而深”。参数规模决定了模型容量的上限但数据质量决定了模型实际能力的下限。35B 之所以能赢是因为它的有效数据密度更高。2.2 “自我造题”解决了什么问题传统训练流程里数据是人工标注的成本高、数量有限而且覆盖面不稳定。自我造题相当于让模型自己生成题目和答案然后用自动化方式做一轮筛选。这里的核心难点不是“生成”而是“质量过滤”。模型会生成大量低质量、重复、有幻觉的样本。如果不过滤直接拿来做训练模型能力反而会下降。所以整套流程必须配合严格的评分机制、去重机制和事实性校验机制。2.3 “自我迭代”怎么闭环自我迭代的结构可以理解为一个循环当前模型生成一批题目和答案。用规则或更强的模型做质量筛。把通过筛选的数据合并到训练集。继续微调或继续训练得到新模型。用评测集对比新旧模型效果。保留效果更好的版本进入下一轮。这就是一个典型的 self-play 思路。模型每次迭代都基于上一轮结果做增量提升相当于给自己出考卷再自己复习再考试。3. 适用场景与使用边界这种方案不是万能的。下面把适合和不适合的情况分开说。3.1 适合谁用垂直领域模型训练团队比如法律、医疗、金融、农业等专业领域公开数据少人工标注贵适合用自我造题补充数据。做模型微调的个人开发者如果数据不够可以先用模型生成一批候选样本再做人工筛选能大幅降低标注成本。做评测集构建的团队用模型自动生成评测题比纯人工编写效率高。研究自进化、主动学习、课程学习的同学这套流程本身就是很好的研究对象。3.2 不适合什么场景通用能力全面超越大模型别指望 35B 在所有任务上都打赢万亿模型这不现实。对事实性要求极低的场景都不行比如创意写作、闲聊合成数据影响不大但涉及事实和专业知识时必须有人工审核。没有评测集的项目如果连衡量模型好坏的标准都没有自我迭代就是空转。3.3 版权、隐私与合规边界自我造题过程中模型生成的样本可能和训练语料高度相似存在版权风险。作者名、真实人名、隐私信息、受版权保护的文本片段都需要在数据进入训练集前做过滤。另外如果涉及人脸、声音、特定人物必须获得明确授权涉及真实用户数据必须脱敏。使用这套方案处理公开语料时也不要绕过任何平台的内容使用限制。4. 环境准备与前置条件下面给出一套通用环境准备思路。文章里没有绑定具体项目文件路径所以这里按“通用本地部署”方式展开实际路径和模型名称需要按你手头的项目调整。4.1 硬件建议35B 参数模型如果做纯推理显存压力不小。可以重点看这几种方案全精度加载 35BFP16显存需求大约在 70GB 左右实际以模型结构为准。4bit 量化后显存需求会显著下降部分情况可以压缩到 20GB 至 30GB 区间。MoE 架构的 35B 模型实际激活参数可能只有 3B 左右显存需求比稠密模型更友好但前提是框架支持 MoE 推理优化。CPU 推理可以跑但速度慢只建议做功能验证不建议做批量训练。显存不够的优先顺序是量化 换小模型 CPU 推理。4.2 软件环境检查清单检查项建议操作系统Linux / Windows / macOS 均可训练建议 LinuxPython3.10 及以上CUDA建议 CUDA 11.8 或以上需匹配显卡驱动PyTorch2.x 版本推理框架vLLM、Ollama、Transformers 均可显存工具NVIDIA-SMI、nvitop磁盘空间模型文件、训练数据、日志需要预留足够空间4.3 理解 TTFT网络热词里有一个问题为什么 qwen3.6 35b a3b 的 TTFT 比较高。这个现象本质上和 MoE 架构有关。MoE 模型的参数量很大但每次推理只激活部分参数。TTFTTime To First Token决定的是“从输入到输出第一个 token 的等待时间”。影响 TTFT 的因素包括Prefill 阶段的计算量。模型总参数量带来的内存读取开销。显存带宽和显存容量。输入长度越长prefill 时间越长。所以你会发现MoE 模型虽然生成速度不慢但首 token 延迟不一定比同规模稠密模型低。部署时如果直接用默认参数TTFT 高是正常现象可以通过限制输入长度、换推理后端、开启前缀缓存等方式优化。4.4 数据目录设计建议把项目目录拆成下面几层便于后续批量迭代project/ ├── models/ # 模型文件 ├── data/ │ ├── raw/ # 原始语料 │ ├── generated/ # 模型生成的题目和答案 │ ├── filtered/ # 过滤后的候选数据 │ └── train/ # 最终训练集 ├── evaluate/ # 评测集与评测脚本 ├── logs/ # 训练和推理日志 └── outputs/ # 模型输出结果这种目录结构的好处是每一轮迭代的数据都能追溯来源出问题可以回滚。5. 安装部署与启动方式自我迭代是一个流程但第一步永远是把基础模型跑起来。下面以本地部署模型为例给出通用步骤。5.1 使用 Ollama 快速验证Ollama 是做本机推理最省事的方式之一。先安装 Ollama然后拉取一个 35B 级别的开源模型# 拉取模型具体模型名需要按实际版本调整 ollama pull qwen3:35b启动服务ollama serve然后就可以用命令行测一下ollama run qwen3:35b 请写一个关于模型自我迭代的测试题这种方式适合快速验证模型有没有部署成功但如果你要跑批量造题和持续迭代建议用 vLLM。5.2 使用 vLLM 部署 API 服务vLLM 的吞吐表现比 Transformers 直接推理好很多。安装依赖pip install vllm启动服务的示例命令python -m vllm.entrypoints.openai.api_server \ --model /path/to/your/model \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.9 \ --host 127.0.0.1 \ --port 8000实际路径、并行度、显存利用率需要按你本机情况调整。启动成功后会出现一个 OpenAI 兼容的接口地址。如果你不希望服务暴露到外网把 host 固定为 127.0.0.1 就行。5.3 使用 Transformers 做训练环境验证如果你准备做微调环境可以这样配置pip install torch transformers accelerate peft datasets训练时的通用配置可以写成 YAMLmodel_name_or_path: /path/to/your/model output_dir: ./outputs/checkpoints per_device_train_batch_size: 1 gradient_accumulation_steps: 8 learning_rate: 5e-6 num_train_epochs: 1 logging_steps: 10 save_steps: 500这个配置只是模板实际需要根据显存和数据集大小调整。6. 功能测试与效果验证部署完模型之后下一步就是验证“自我造题 自我迭代”的能力。下面给出一套通用测试流程你可以按自己的任务替换输入内容。6.1 测试基础推理能力先确认模型本身正常工作。输入示例请判断以下结论是否正确大模型参数量越大在所有任务上的效果一定越好。请给出理由。预期结果模型应该指出结论过于绝对并说明数据质量、训练方法、评估维度等因素都会影响效果。判断标准输出逻辑是否连贯。是否能区分“参数规模”和“实际效果”的关系。是否存在明显幻觉。6.2 测试自我造题能力这是整套流程的关键。操作步骤准备一个主题比如“模型评估指标”。让模型围绕主题生成 10 道选择题。检查题目是否有重复。检查答案是否有明显错误。检查难度是否合理。提示词模板请围绕“大模型评估指标”生成10道中等难度的单选题格式如下 题目[题目内容] A. [选项] B. [选项] C. [选项] D. [选项] 答案[正确选项] 解析[简要解释]预期结果模型能生成结构完整的题目但可能出现答案错误、题目重复、选项不平衡等问题。判断成功标准题目格式是否规整。事实性错误比例是否低于人工容忍线。去重后是否还有足够的有效样本。如果答案错误率过高说明这个模型当前不适合直接生成训练数据需要换更强的模型或者加人工审核。6.3 测试数据筛选逻辑造题只是第一步质量过滤才是核心。推荐组合方案规则过滤检查格式、长度、重复度。模型评分用大模型对候选题目打分。人工抽检随机抽样 10% 到 20% 的题目验证质量。去重对相似题目做向量去重或关键词去重。示例评分 prompt请对下面这道题进行评分维度包括 - 正确性0-5 - 清晰度0-5 - 区分度0-5 - 难度合理性0-5 题目内容 [题目内容] 请输出一个 JSON {correctness: 0, clarity: 0, discrimination: 0, difficulty: 0}6.4 测试自我迭代闭环自我迭代测试建议用“两轮对比”的方式用原始模型生成一批数据。筛选后微调获得新模型。用同一批评测题对比新旧模型效果。记录准确率、输出质量、失败案例。对比记录表格迭代轮次样本数评分通过率评测准确率失败案例数原始模型0-基准分数-第 1 轮100070%提升/下降记录典型错误第 2 轮200075%继续对比记录典型错误判断成功的标准不是“准确率一定上升”而是“在评测集上保持稳定而不是过拟合到某类题目”。6.5 失败排查现象可能原因排查方向题目大量重复模型陷入了固定模式提升 temperature、增加惩罚项答案错误率很高模型本身知识不足换更强模型、限制领域范围微调后效果下降数据质量差或过拟合降低学习率、增加数据过滤迭代两轮后无提升数据多样性不足更换提示词模板、引入外部知识7. 接口 API 与批量任务自我造题和筛选最好都做成批量任务。下面给出接口调用和批量任务设计的通用思路。7.1 API 调用示例假设你的服务跑在本地 8000 端口可以用 curl 做一次简单验证curl http://127.0.0.1:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: your-model-name, messages: [{role: user, content: 请出一道关于过拟合的单选题}], temperature: 0.7, max_tokens: 512 }如果是 Python可以这样写import requests url http://127.0.0.1:8000/v1/chat/completions payload { model: your-model-name, messages: [ {role: user, content: 请出一道关于过拟合的单选题} ], temperature: 0.7, max_tokens: 512 } response requests.post(url, jsonpayload, timeout120) print(response.json()[choices][0][message][content])注意模型名、端口、请求路径要按你实际启动的服务调整。7.2 批量造题流水线批量任务建议按这个流程设计准备一个主题列表文件。每个主题批量发送请求生成多道题。每道题单独存储附带主题、生成时间、模型版本。统一做格式校验。统一做评分和去重。把通过的数据写入训练集。Python 批量请求示例import requests from concurrent.futures import ThreadPoolExecutor url http://127.0.0.1:8000/v1/chat/completions topics [过拟合, 梯度消失, 注意力机制, 数据增强, 正则化] def generate_question(topic): payload { model: your-model-name, messages: [ {role: user, content: f围绕主题{topic}生成一道中等难度单选题并给出答案和解析。} ], temperature: 0.7, max_tokens: 512 } resp requests.post(url, jsonpayload, timeout120) return {topic: topic, content: resp.json()[choices][0][message][content]} with ThreadPoolExecutor(max_workers4) as executor: results list(executor.map(generate_question, topics)) for r in results: print(r[topic], r[content][:50])批量任务的注意事项控制并发数避免把显存打满。每个请求要设置超时。失败请求要记录日志不能静默跳过。输出结果按 JSON 格式存储方便后续过滤和筛选。7.3 数据筛选批量任务筛选比生成更需要小心。建议用独立脚本处理import json def filter_questions(data_path): with open(data_path, r, encodingutf-8) as f: items json.load(f) valid [] seen set() for item in items: content item[content] # 格式检查 if 答案 not in content or 解析 not in content: continue # 简单去重 if content in seen: continue seen.add(content) valid.append(item) return valid这只是一个基础过滤实际项目还需要加入模型评分、事实校验等环节。8. 资源占用与性能观察8.1 显存占用观察方法如果你用的是 NVIDIA 显卡启动模型后可以用 nvidia-smi 观察显存占用nvidia-smi更推荐用 nvitop 看实时变化pip install nvitop nvitop观察重点模型加载后的静态显存占用。生成过程中显存的峰值变化。批量请求并发时的显存增长曲线。是否出现显存溢出 OOM。8.2 CPU 推理 vs GPU 推理CPU 推理可以跑通流程但速度差距很大。比如 GPU 上几秒完成的任务CPU 上可能需要几十秒甚至更久。建议功能验证可以用 CPU。批量生成和迭代训练必须用 GPU。如果显存不够优先做量化而不是直接上 CPU。8.3 影响性能的关键参数输入长度越长prefill 时间越长。输出长度越长单次生成耗时越长。并发数越高越容易碰显存上限。采样参数temperature 和 top_p 不影响速度但会影响效果。量化等级4bit 比 16bit 省显存但可能影响输出质量。8.4 降低资源占用的几个办法使用 4bit 量化。限制 max_tokens。减小并发数。使用 vLLM 的 Continuous Batching 特性。开启前缀缓存。定时清理显存碎片。8.5 TTFT 高的处理思路回到前面提到的 MoE 模型 TTFT 问题。如果部署后遇到首 token 延迟过高从这几个方向排查输入长度是否太长。是否做了显存不足导致的 swap。推理框架是否支持 prefill 优化。是否开启了前缀复用。显卡带宽是否成为瓶颈。如果这些优化后还是高那大概率是模型本身的默认行为需要调整使用策略。9. 常见问题与排查方法问题现象可能原因排查方式解决方案服务启动失败依赖版本冲突或 CUDA 版本不匹配查看启动日志确认 CUDA 和 PyTorch 版本按项目要求重装依赖模型加载后显存溢出显存不足或量化未生效查看 nvidia-smi 显存占用换 4bit 量化、减小张量并行数API 调用超时输入过长或推理速度慢观察服务日志和响应时间限制 max_tokens、降低并发生成题目格式不规整模型指令跟随能力弱检查 prompt 是否清晰增加格式示例、换更强模型题目大量重复采样随机性不足检查 temperature 设置提高 temperature、增加重复惩罚微调后评测下降数据质量差或过拟合对比训练集和评测集分布加强过滤、降低学习率TTFT 过高MoE 架构 prefill 开销大排查输入长度和显存带宽限制输入长度、开启前缀缓存批量任务卡住并发过高或单条请求超时查看任务日志降低并发、增加超时时间输出包含隐私信息训练语料或生成数据未脱敏检查生成结果样本增加敏感信息过滤层10. 最佳实践与使用建议自我造题、自我迭代这套流程看起来自动但每个环节都需要控制。第一第一次尝试时用小参数、少数据跑通流程。第一步不要直接上 35B 全量微调先用几百条数据验证流程是否通畅。流程跑通后再放大规模。第二始终保留一份基线模型。每一轮迭代的模型都要和基线版本做对比指标上升才保留新版本。不能出现“迭代了 3 轮分数反而比原始模型低”的情况。第三训练数据必须分层管理。原始语料、模型生成数据、过滤后数据、最终训练集每层都要有独立目录。出了问题才能回溯是哪批数据导致的。第四模型生成的题目不等于高质量训练数据。哪怕评分很高也要定期做人工抽检。自动评分可能被模型自身的偏好带偏。第五批量任务必须有日志和断点继续能力。如果 100 个批量任务跑到第 60 个挂掉重新全部跑一遍就是巨大浪费。建议把已完成的结果增量写入磁盘。第六接口服务只监听内网地址。部署 API 服务时把 host 固定为 127.0.0.1 或者内网 IP不要默认暴露到公网。如果确实需要远程访问做好鉴权和控制访问范围。第七涉及真实人物、版权素材、用户数据时必须确认授权和合规。无论技术多强这一点都不能省。第八商用前要对模型输出做人工复核。特别是法律、医疗、金融等领域错误输出的代价极高。11. 总结与下一步35B 干赢万亿参数模型最重要的启示不是“参数不重要”而是“数据质量可以改变能力曲线”。自我造题解决的是数据供给问题自我迭代解决的是能力滚动提升的问题两者配合起来相当于给模型装了一个数据飞轮。如果你想快速验证这套思路建议按以下顺序动手先部署一个 35B 级别模型确认推理正常。用“自我造题”生成一批测试题做格式和去重检查。搭一个最小筛选流水线把质量过滤跑通。用 500 到 1000 条筛选后数据做一轮微调。和基线模型做一次完整对比记录准确率、失败案例和显存占用。最容易踩的坑有两个一是生成数据不筛选直接训练导致模型变笨二是没有评测集就做迭代最后无法判断是变好了还是变差了。等这套小闭环跑通以后你可以继续扩展的方向包括垂直领域评测集自动构建、多模型协同生成与投票筛选、迭代训练与强化学习结合以及更完善的数据版权和安全合规审查机制。先把第一步跑起来剩下的问题会在运行中看得更清楚。