模型组备赛这些年越来越卷，但很多人一开始根本不知道“模型组要干什么”。刷榜刷数据、跑分调参、熬夜等训练日志……如果你准备参加人工智能模型组比赛，这篇内容把从选赛道到最终提交的全过程拆给你看，包括硬件准备、数据清洗、基线选型、微调策略、推理加速和典型翻车现场排查。适合第一次带队参赛的团队负责人，也适合想从应用组转模型组、对训练全流程还没建立体系感的个人开发者参考。
1. 备赛前期：赛道定位和团队分工
1.1 模型组到底比什么
先明确一件事：模型组不是做产品Demo，也不是包装Agent流程，它比拼的是“你能否在一个有限的算力和时间预算内，把开源基座模型调成一个在多个专业评测集上表现更强的模型”。换句话说，应用组看花的程度，模型组看准的程度。提交物通常是适配后的模型权重、微调代码、数据配方说明和评测报告，部分赛题还要求你提交推理部署方案或推理延迟指标。这一点决定了整个备赛周期的时间分配：数据工程至少占四成，训练和调参占四成，推理和评测占两成，而不是把大部分时间砸在写Prompt或接API上。
1.2 先判断自己适不适合冲模型组
如果团队里所有人都没跑过一次完整微调实验，建议先别急着报模型组。不是门槛高到够不着，而是试错成本很现实：一次LoRA微调动辄几小时到十几个小时，基座模型全参数微调更要以天为单位。你需要在资源受限的情况下反复试错，数据处理的Bug、训练Loss不下降、评测脚本报错，这些问题每一个都能消耗掉一整天。适合模型组的团队，至少要满足三个条件：有人懂Python和PyTorch，有人愿意啃论文和模型文档，有人能忍受看训练曲线看到后半夜。如果暂时不具备，先报应用组积累经验问题不大，但如果你目标明确就是来模型组长经验的，那这一步必须自己心里有底。
1.3 团队分工和节奏规划
我见过最拖后腿的分工方式，是全员一起调参、一起处理数据，结果大家都等在同一台机器前面，训练一跑起来反而没事干。比较靠谱的分工是：一人负责数据和评测集分析，负责搞清楚测试集考什么、哪类题占比重、模型的短板在哪个能力域；一人负责基线跑通和训练脚本，包括数据加载、格式转换、LoRA配置和训练恢复机制；一人负责推理验证和提交物整理，比如写推理脚本、统计指标、做Case分析。三个人并行，数据准备和基线跑通同时进行，通常能省出至少两天时间。
2. 算力规划与数据“军备”：一切效果的前提
2.1 算力预算怎么拆才不浪费
很多团队拿到比赛提供的GPU资源后，第一反应是直接上全参数微调，结果发现显存不够、训练到一半OOM崩溃，最后只能切LoRA重新跑。这里我的建议很直接：先算你手头的显存规模，再决定训练方案。一张24GB显存的显卡，用7B模型做LoRA，序列长度设2048、batch size设4，通常能跑起来；如果换成13B模型又不做梯度累积，大概率要用offload或者降到8位加载，训练速度会明显变慢。团队里如果有人对显存占用没概念，有一个很简单的估算方式：模型权重占用的显存大约是参数量的2倍（以Byte计算），7B模型FP16权重就要约14GB，再加上梯度和优化器状态，全参数微调根本不是单卡能做的事。所以模型组备赛的铁律是：能用LoRA解决的问题不要轻易上全参微调，先保住迭代速度。
2.2 数据清洗的核心逻辑
数据这块我踩过的坑最深。公开赛题一般会给训练集，但训练集本身的质量参差不齐，重复样本、错误标签、格式混乱的情况很常见。第一轮清洗时，我会按这几步走：先做去重，很多比赛训练集里同一道题以不同措辞反复出现，模型跑两三个epoch之后很容易被这些重复样本带偏；再做标签校验，把答案和问题类型对齐，尤其是多选题和判断题，标签颠倒是高频错误；最后做难度分布统计，看看模型在哪个能力域上最容易出错，比如代码类、数学推理类、中文知识类，这个统计结果直接决定后续指令数据的配比。
举个具体例子，某次备赛我们拿到的训练集接近4万条，清洗后剩下约3.2万条，其中重复数据占了接近两成。如果不做这步去重，模型对高频重复题会产生严重过拟合，评测集上一换说法分数立刻掉。清洗之后，我还额外用脚本统计了标签分布：原本“中文知识”类占45%，“代码生成”类只占8%，但赛题评测里代码题占比接近20%。这就不对了，靠原始分布做微调，代码能力一定补不上来。因此需要额外补充外部代码指令数据，把配比调到大约3:2:1的知识、代码和推理比例。
2.3 验证集必须从训练集里单独隔离
很多团队直接用官方给的评测集做验证，边训边测，最后提交前才发现评测集被“污染”了。更稳妥的做法是：从清洗后的训练集里按比例抽出5%~10%的数据做验证集，保证分布一致，且验证集永远不参与训练。我个人习惯用seed固定随机抽样，保证每次抽出的数据可复现，否则不同次训练之间无法公平对比Baseline和实验组。后续做超参选择、判断是否过拟合，全部以这个验证集上的表现为准，而不是以官方评测集为准。
3. 微调方案设计：基座选择、数据配比和超参设置
3.1 基座模型怎么选
模型组一般允许使用开源基座模型，不同赛事指定的范围内会有几个候选模型。选基座不是越大越好，关键看三个因素：显存是否扛得住、局部知识能力是否契合赛题、生态和文档是否完整。如果赛题偏中文知识和推理，Qwen系列通常比通用英文模型更稳；如果偏代码生成，像DeepSeek-Coder或者CodeLlama底子会更好。不过要注意一点：基座模型擅长的领域和你准备微调的数据必须匹配。如果你拿一个英文代码模型硬调中文问答，不是不能调，而是需要更多高质量中文数据才能掰回来，时间和算力成本都会上升。
我曾在一个模拟项目中用13B模型打比赛，初期单卡训练速度慢到难以忍受，后来果断换7B模型加LoRA，虽然能力上限低一点，但迭代速度大幅提升，最终靠多轮快速实验找到了更优的数据配比。模型组比赛比的是“在你现有资源下找到最佳方案”，不是在想象中堆算力。
3.2 LoRA与全参数微调的取舍
先给结论：绝大多数模型组备赛场景，LoRA都是性价比最高的选择。它只训练低秩分解出来的少量参数，显存占用低、训练时间短、可以频繁实验；Needle全参数微调效果上限更高，但对数据量、分布式训练能力和算力要求都高，没有专业团队支撑很容易跑崩。让我用生活化一点的类比：LoRA相当于在原有模型上加一套“外挂记忆”，只动一小部分参数，姿态不变但能快速学会新套路；全参数微调则是把整套反应机制都重塑一遍，效果可能更本质，但你需要承担更长训练时间和更多不稳定性。
在LoRA的配置上，我习惯从rank=16起步。任务较简单、数据量不大时，rank=8可能更快收敛；任务复杂、领域风格差异化明显时，rank=32效果更好。Alpha一般设为rank的2倍，比如rank=16时alpha=32。Dropout设置0.05~0.1，防止过拟合。这个组合在大多数场景下是一个稳开局，后续再根据验证集表现调。
3.3 指令数据的格式和配比
微调数据不是越多越好，关键是“模型要能看清任务边界”。比赛中常见的数据格式有三种：纯问答对、带系统提示词的指令数据、带少量示例的Few-shot数据。我建议统一用对话模板格式组织数据，因为这与基座模型预训练时的格式最接近，指令遵循能力更容易被激活。下面是一个简化版的示例结构：
{ "conversation": [ { "role": "system", "content": "你是一个专业的人工智能助手，请根据用户的问题给出准确、简洁的回答。" }, { "role": "user", "content": "给出以下代码片段的时间复杂度分析：for (int i = 0; i < n; i++) { for (int j = 0; j < n; j++) { sum += a[i][j]; } }" }, { "role": "assistant", "content": "该代码包含两层嵌套循环，外层循环执行n次，内层循环每次也执行n次，因此总操作次数为n^2，时间复杂度为O(n^2)。" } ] }配比上我通常遵循一个原则：**核心能力倾斜，边缘能力保底。**如果赛题评测集中代码题占比20%，训练数据里代码题就不能低于15%；数学推理题如果评测占比低，但这类能力迁移性差，也至少要保10%。数据格式的混乱是另一个高频坑：有的样本是纯文本，有的是数组格式，训练脚本一旦读取类型不一致就报错。所以在进入训练之前，统一封装成一个数据转换脚本，把所有原始数据转成约定的JSON格式，再统计一遍每个字段的非空率和类型合法率，这一步能帮你省下大量排错时间。
3.4 训练超参的推荐起点
超参没有绝对最优，但有几个起点足够安全，之后再根据验证结果小幅调整：
# 我常用的LoRA微调起点配置 --model_name_or_path Qwen/Qwen2-7B --lora_rank 16 --lora_alpha 32 --lora_dropout 0.05 --learning_rate 1e-5 --per_device_train_batch_size 4 --gradient_accumulation_steps 4 --num_train_epochs 3 --max_seq_length 2048 --warmup_ratio 0.03 --weight_decay 0.01实际batch size = per_device_train_batch_size × gradient_accumulation_steps × GPU数量。以单卡24GB、7B模型为例，per_device_train_batch_size=4、梯度累积4步，等效batch size是16，这个规模在多数任务上收敛效果都比较稳。学习率1e-5对LoRA是个常见起点，如果验证集上收敛太慢，可以往2e-5调；如果Loss曲线震荡，就降回5e-6。Epoch别一上来就设5，数据量小的高质量数据集上3轮通常已经足够，超过4轮我就观察验证集是否开始反弹，如果反弹说明过拟合了。
4. 训练过程管理：日志监控、断点恢复和故障排查
4.1 训练日志需要监控的四个关键信号
训练跑起来之后，不是挂在那里等就行了。我一般每隔一段时间扫一眼训练日志，重点看四个信号：Loss下降是否平滑、验证集指标是否同步上升、显存占用是否稳定、训练速度是否突然下降。Loss下降不代表模型真的在变好，如果训练Loss持续下降但验证集指标不动，大概率是数据泄漏或过拟合；显存占用如果持续升高，说明可能有内存泄漏，长时间训练会OOM；训练速度突然变慢，要么是数据加载瓶颈、要么是GPU降频，需要及时干预。
4.2 断点续训不是可选项，是必选项
比赛期间断电、机房维护、显卡被占用的意外我都遇到过。没有断点续训机制，一次十几个小时的训练白跑会让你心态直接崩掉。所以训练脚本里必须做两件事：周期性保存checkpoint，并保存优化器状态和随机种子状态。很多框架自带这个能力，但默认只保存模型权重。我习惯每500步保存一次checkpoint，并开启自动恢复机制，这样即使中断，也最多丢失十几分钟的训练进度。提交前再合成最终权重，做推理评测。
4.3 模型输出质量的人工抽检
自动指标不能完全代表模型效果。每次跑完一轮微调，除了看评测分数，我还会找几十条训练集之外的样本做人工抽检，看模型到底在“做什么”。有些模型指标分数高，但输出内容存在重复、答非所问、编造数据的情况；有些模型分数稳定，但风格机械，让人一眼就觉得“这不是一个好模型”。人工抽检不需要一次看很多，但一定要覆盖不同题型，看几条就基本能判断当前模型是否值得继续调。
5. 评测与迭代：别被单次分数带偏
5.1 评测指标设计要贴近赛题
模型组的评测设计直接影响调参方向。如果赛题官方给了一套评测脚本，那毫无疑问以它为准；如果官方没有明确指标，需要自己设计。我常用的组合是：整体准确率、分区准确率（按题型/领域拆分）、输出格式合法率、过长短句比例。分区准确率尤其重要，因为平均分提升1个点，原因可能是某一类题大爆发，其他类题反而退步。不拆开看，你根本不知道模型是不是“偏科”了。
5.2 对比实验要有相同环境
做对比实验时，环境一致性比什么都重要。数据版本、基座版本、随机种子、推理参数（比如temperature、top_p）全部要固定下来，一次只改一个变量。否则你改了数据配比的同时又把学习率从1e-5改成了2e-5，最后分数变了，你根本说不清是哪个改动生效的。我们团队的做法是，在项目开始时就建一个实验记录文档，每次实验记录：数据集版本、模型版本、超参配置、评测结果、结论。这个文档到后期就是最大的财富，每个提交版本的对错都有迹可循。
5.3 迭代顺序：先数据后超参
如果第一轮微调效果不理想，很多团队的直觉是疯狂调学习率、改batch size，但我的经验是：**先查数据，再动超参。**因为数据问题对效果的影响往往是结构性的，超参怎么调都补不回来。比如某个题型训练数据里几乎没有，你怎么调学习率都没用；数据重复度过高，降低epoch数反而比调学习率更有效。先检查数据配比、清洗质量、样本正确率，确认这些没问题之后，再去动超参。
6. 推理加速与提交策略：最后的临门一脚
6.1 推理吞吐优化
部分模型组比赛会考核推理性能，包括延迟和吞吐量。这个维度的优化不需要把模型换掉，先用vLLM等推理框架做批处理，再把模型量化到INT8或INT4，往往就能获得几倍的吞吐提升。我印象比较深的一次是，模型加载后直接跑推理，单请求延迟能接受，但并发一上来吞吐急剧下降，后来改用vLLM并开启连续批处理，吞吐翻了一倍多，延迟也稳定了下来。如果是提交权重让官方评测，那推理优化可以少花时间；如果是提交系统、实时打分，这部分就是拿分点。
6.2 提交前检查清单
这个清单我打印出来贴了不止一次：checkpoint是否与代码版本匹配、评测脚本是否与官方一致、数据配比和参数是否记录完整、模型输出的格式是否满足要求（比如JSON、代码块、选择题选项）、推理是否在硬件资源约束下能稳定跑完。有一年我们差一点提交了旧的checkpoint，因为训练过程中新输出的权重文件命名和旧文件相近，脚本里引用指向了旧路径，还好评测前做了逐项检查才发现。
6.3 拆掉“最后一版”心理
模型组备赛到最后，很多人会陷入“再调一版肯定更好”的状态，无止境地刷实验。实际上，离提交截止还有12小时的时候，最应该做的事是冻结版本、完整跑通一次提交流程，而不是再开一轮新训练。因为新训练的结果不一定更好，但时间一定不够。我每次到倒计时阶段，都会强制团队做“冻结模型”操作：所有人都停止调参，只用当前最优模型跑提交流程，跑通了再去考虑要不要冒险换新版本。备赛比的不是谁在截止前最后一刻还在训练，而是谁能在有限资源内拿出最稳定的成果。
7. 备赛过程中的隐藏加分项
7.1 记录实验，但也要记录“失败”
很多团队把实验记录写成流水账，不考虑分析。但真正值钱的记录，恰恰是失败实验的分析。比如某次把学习率调到2e-5，训练Loss迅速下降，但验证集上代码类题目分数骤降，为什么？原因是学习率太高，LoRA在代码类任务上快速记住了训练集中的常见模板，但对新代码片段泛化不足。把这个失败原因和推断写进文档，后面就不会重蹈覆辙。失败实验的价值往往高于成功实验，因为它直接划掉了你未来会重复走的错路。
7.2 合理的“外部数据补充”策略
模型组比赛的规则通常允许使用公开预训练数据，但前提是来源合规、不泄漏评测答案。补充外部数据时，优先选择任务格式和赛题高度一致的数据，比如赛题里有代码生成，那外部数据就选代码生成类的指令数据；赛题里有数学推理，就补充数学推理链数据。不要贪多，一次只加一小部分，跑一版看效果，再继续加。我有过一次性塞入大量外部数据导致模型整体能力下降的经历，原因是外部数据风格和赛题差异大，模型反而学偏了。
7.3 合理利用无监督数据做continued pre-training
如果赛题提供大量无监督领域的语料，比如大量技术文档、代码仓库，可以尝试做短时间的continued pre-training，让模型先适应目标领域，再进行指令微调。这个操作不需要很长的训练时长，一般1个epoch甚至更短就能明显提升领域相关度。但要注意，无监督预训练阶段容易导致模型通用能力衰退，所以控制步数和学习率是关键，通常学习率设为指令微调的1/5到1/10，比如2e-6左右。这个技巧不是每个赛题都适用，但如果你发现评测集高度集中在某个垂直领域，值得一试。
8. 从备赛到比赛结束：那些容易被忽略的细节
8.1 赛前环境自检清单
不管比赛是线上提交还是现场评测，赛前必须完整走一遍“提交流程演练”。这包括：模型加载、预处理脚本执行、推理调用、输出格式封装、结果上传。演练过程要专人负责计时，因为线上评测平台有时会有代码执行超时限制，而现场提交还可能涉及硬件驱动、依赖缺失等各种问题。我见过有人在比赛现场花了两个小时装依赖，最后连评测都没跑完，就是因为之前没有在目标环境里做过完整流程演练。
8.2 提交物整理：代码即文档
模型权重是主体，但代码和文档的规范程度也会影响最终评审，尤其是一些需要现场答辩或提交技术报告的赛制。代码部分至少要有清晰的README，说明环境依赖、启动方式、模型结构和训练参数；文档部分要包含数据来源、处理方式、模型选择理由、实验结果对比和最终方案分析。这些都别等到最后一晚再写，训练过程中的实验记录就是技术报告的第一手素材。整理提交物时，我习惯用固定的目录结构：
submission/ ├── README.md ├── requirements.txt ├── src/ │ ├── train.py # 训练及微调脚本 │ ├── inference.py # 推理脚本 │ ├── data_process.py # 数据清洗与转换 │ └── eval.py # 评测脚本 ├── data/ │ ├── train_data.json │ └── val_data.json └── output/ ├── checkpoints/ └── final_model/目录结构一清晰，排查问题时就不会手忙脚乱。很多团队最后提交时连自己模型是哪个版都说不清，就是因为目录和文件名太随意。
8.3 答辩环节的展示思路
如果比赛有答辩或评委提问环节，不要只讲“我们用了什么模型、分数多高”。更有效的展示逻辑是：先说明赛题难点和数据洞察，再讲你为解决难点做了哪些尝试，包括失败的和成功的，最后解释最终方案为什么最优。评委更愿意看到一个能清晰表述决策过程的团队，而不是一个只会说“调参调到最好”的队伍。备赛阶段做过的实验记录，在答辩前就是最好的演讲素材。
我在几次实际备赛中体会最深的一件事是：模型组比赛到最后拼的不只是模型能力，还有团队对有限资源的调度能力，以及在反复失败中沉得住气的心态。没有哪个队是每一步都顺利的，那些最终跑出来的方案，背后都是一堆踩过的坑和不断修正的决策。如果你能接受这种节奏，模型组的备赛过程本身就是一次完整的工程训练，即便最后成绩不如预期，你收获的也是对训练全流程更立体的认知，这笔经验很大程度上比排名更保值。
