1. 先把问题问对LLaMA 3 微调到底在解决什么1.1 通用权重落到业务里必然出现的三处错位LLaMA 3 微调这件事我前前后后在不同规模的项目里做过七八轮从单卡 24G 的个人实验到八卡集群的团队任务都趟过。开头先说一句可能不太中听的话绝大多数人第一次做 LLaMA 3 微调失败的原因不在训练脚本而在于一开始就没想清楚自己要解决的是哪一类问题。通用权重直接拿来用落到具体业务里通常会撞上三种错位。第一种是表达风格的错位。基座模型见过海量文本说话方式偏向通用助手回答四平八稳、爱铺垫、爱总结。但很多业务场景要的是另一种腔调——工单回复要短、要带编号、要先给结论客服话术要克制、不能承诺、不能给建议超出范围。这类需求用提示词能压住七成剩下三成怎么调提示词都会在长对话里漂移这就是微调的靶心。第二种是输出结构的错位。你要模型稳定吐出一段固定字段的 JSON、一张表格、一段带特定标记的文本通用模型能吐但格式合规率大概在 70% 到 85% 之间浮动而且字段名时常自己发明。业务侧一旦要程序解析这个合规率就不能接受。微调最擅长的恰恰是这种格式服从性训练几百条高质量样本就能把合规率拉到 98% 以上。第三种是领域知识的错位。这一条最容易踩坑。很多人以为微调能把一批文档灌进模型于是拿几千条问答去做监督微调结果模型学会的是那批问答的问答腔调而不是里面的事实。要模型记住事实检索增强才是正路微调负责的是怎么用这些事实说话。这两者的分工搞混后面所有工作都是白费。1.2 微调、检索增强、提示工程三者的边界怎么划我给自己的判断标准很朴素按成本从低到高排能靠提示词解决的绝不上微调能靠检索解决的绝不上微调剩下那些模型会做但做得不像的活才交给微调。具体拆开看如果需求是模型不知道某个新信息那属于知识注入检索增强的成本和可维护性都远优于微调而且数据更新时不用重训。如果需求是模型知道但答得不符合我们的话术规范、格式规范、推理路径这才是监督微调的主场。如果需求是我们希望模型更倾向于某一种价值判断或拒答策略那属于对齐层面的事偏好优化类方法比纯监督微调更对症但门槛也更高一般项目不必一上来就走到那一步。一句实话我见过太多项目本来写两百字提示词加一个 JSON Schema 校验就能解决的问题硬是拉了三个人做了两周微调最后效果还不如前者稳定。先把手上的提示词方案压到极限再决定要不要动权重。还有一个常被忽略的判断维度是数据可得性。微调的上限几乎完全由数据质量决定如果你手里连三百条像样的标注样本都凑不出来那不管用多花哨的技术方案出来的东西都是自娱自乐。反过来如果你有一个已经在跑的业务系统每天自然产生几百条真实交互记录那微调的启动成本其实非常低——清洗一批、标注一批就能开跑。1.3 什么样的项目适合从 LLaMA 3 起步选 LLaMA 3 系列而不是别的开源权重理由基本是三条。生态成熟度是第一条周边工具链——训练框架、量化工具、推理服务、评测脚本——对它的支持最全遇到问题能搜到答案的概率最高这对第一次做微调的人非常重要。第二条是尺寸梯度友好8B 这个档位刚好卡在单卡能折腾、效果又不算玩具的区间做原型验证的门槛很低。第三条是对话模板规范清晰角色标记、结束标记定义得干净做数据拼接时不容易出错。不过也要提醒一句LLaMA 3 系列的许可证有它自己的约束条款商用前必须自己逐条读完尤其注意用户规模相关的条款和署名要求。这一条我不展开但每次立项我都会把它作为前置检查项列在第一行。2. 三条技术路线的取舍全参、LoRA、QLoRA2.1 先把显存账算清楚再谈方案方案选型这件事本质上是一道显存算术题。很多人卡在这里不是因为不懂原理而是没把账算明白跑到一半 OOM 才发现选错了路。我把三类方案的实际显存构成列一下以 8B 参数模型为例都是量级估算不是精确值。方案权重占用优化器状态梯度激活值seq 2048batch 1单卡可行区间全参微调bf16 混合精度约 16 GB约 64 GBfp32 双矩约 16 GB8 GB 以上单卡基本不可行需多卡分片LoRAbf16 主干冻结约 16 GB可训练参数极少不足 0.2 GB同左6 至 8 GB40 GB 舒适24 GB 需压缩序列QLoRA4bit 量化主干约 5 GB不足 0.2 GB同左5 至 7 GB24 GB 宽裕16 GB 需降 batch这张表里最容易被低估的是激活值。它跟序列长度基本是线性关系跟 batch 线性跟层数线性但开不开梯度检查点差别巨大——开了之后大致能压到原来的三分之一到四分之一代价是训练速度掉两成左右。所以你在 24G 卡上想跑 8B 的 LoRA第一件事不是降 rank而是确认梯度检查点有没有打开。再说全参微调。它的显存大头不在权重而在优化器状态。Adam 系列要为每个参数存一阶矩和二阶矩加上 fp32 的主权重副本一个 8B 模型光这部分就是六七十 GB。这意味着单卡绝对跑不动必须上分片策略把优化器状态、梯度、参数切到多张卡上。八卡 40G 跑 8B 全参微调是比较舒服的配置四卡勉强两卡就得靠 CPU 卸载速度会难看到让你怀疑人生。我的实际选择习惯是这样原型阶段一律 QLoRA验证数据格式、验证任务可行性、验证评测方案全在单卡上搞定速度快、试错便宜。等验证通过、数据规模上来了、效果确实卡在瓶颈上了再考虑转 LoRA 全精度或者全参。直接上全参的人十个里有八个在第三天就放弃不是因为效果不好是因为调不动。2.2 LoRA 的秩和注入模块该怎么定LoRA 的原理不复杂冻结原权重在旁边挂一对低秩矩阵做增量训练时只更新这对小矩阵。它的参数量是r × (d_in d_out)其中 r 是秩。以隐藏维度 4096 的 8B 模型为例如果只注入注意力的四个投影矩阵r 取 16那么每层大约是4 × 16 × 8192 ≈ 52 万参数32 层加起来约 1700 万只占全模型的 0.2% 左右。如果按现在比较主流的做法把 MLP 的三个矩阵也一起注入也就是常说的 all-linear参数量会涨到原来的三倍多大约 5000 万到 6000 万占比升到 0.7% 上下。这个量级依然很小但对效果的提升是实打实的——尤其是涉及格式服从、术语替换这类改写行为的任务MLP 层的参与很关键。关于秩怎么取我给的经验值是只改风格、改话术、改格式r 取 8 到 16 足够再大只是徒增过拟合风险。要注入较复杂的领域推理路径r 取 32 到 64同时把 alpha 设成 r 的两倍。数据量少于 500 条r 反而要往小里取8 甚至 4因为低秩本身就是一种正则。alpha这个参数的作用是缩放实际生效的缩放系数是alpha / r。社区里常见的做法是alpha 2r这样缩放系数恒为 2改 r 的时候不用重新调学习率。也有人用alpha r效果差别不大但如果你的 loss 一直震荡把 alpha 调小一点往往比调学习率更直接。一个少有人提的细节lora_dropout在多轮短样本上建议设 0.05 到 0.1但在长样本、少样本的场景下反而要设成 0因为 dropout 会让长序列里的关键标记被随机丢掉学不扎实。2.3 量化配置里最容易被忽略的两个参数QLoRA 这块配置项看着多真正影响结果的其实就两个。第一个是量化类型。4bit 量化有几种不同的数据分布假设其中按正态分布分位切分的那一种NF4对正态分布的权重最友好也是实践中最稳的选择。另一种FP4在数值范围上更均匀但在大模型权重上表现通常略逊。计算时的数据类型一定要选 bf16选 fp16 会在反向传播时频繁溢出直接给你一片 NaN。第二个是双重量化。它对显存的影响不大大概能省下每参数 0.4 bit 左右的量化常数开销8B 模型上差不多省半 G但代价是额外的计算步骤。我的经验是显存吃紧就开不吃紧就关别为了配置更全而开。还有一个坑要单独说量化训练完之后adapter 是挂在量化权重上的。这意味着你不能直接把 adapter 拿去和一个全精度权重合并——数值基准不一样。正确做法是要么在量化状态下做推理性能有损失要么在训练结束后把 adapter 合并回一份全精度权重再重新量化。这一步很多人第一次做会直接懵因为它不报错只是效果莫名其妙地差一截。3. 数据工程这一步决定上限3.1 对话模板必须和基座严格对齐这是我在实际项目里见过最多、也最冤枉的一类失败训练配置全对loss 曲线也漂亮最后生成的时候模型开始在回答末尾自己续写user: 还有别的问题吗。根因是对话模板没对齐。LLaMA 3 系列用的是它自己的一套特殊标记体系角色信息包在特定的头标记里一轮结束有专用的结束符。你在构造训练样本时如果用了一套模板去拼 prompt推理时又用另一套模板去拼模型看到的输入分布和训练时就不是同一个东西它自然会按训练时见到的模式往下续写。我自己的做法是训练和推理共用同一个模板函数绝不手写字符串拼接。现在主流的分词器都带模板方法直接调用它生成 token id训练时存的就是 id 序列推理时也走同一条路径。这样从根上杜绝了不一致。# 训练侧统一走模板不要手拼字符串 messages [ {role: system, content: 你是一名工单处理助手回答不超过三句话。}, {role: user, content: sample[query]}, {role: assistant, content: sample[answer]}, ] input_ids tokenizer.apply_chat_template( messages, tokenizeTrue, add_generation_promptFalse, )这里还有一个衍生问题结束符有没有被正确加入。有些数据集在清洗时把末尾的空格或换行去掉了导致模板拼出来的序列里结束标记位置不对模型学不会什么时候该停。表现就是推理时话痨停不下来。检查方法很简单随便打一条样本的 id 序列出来解码看一眼末尾是不是干净的结束标记一眼就能看出来。3.2 数据量与配比的经验值数据量这件事网上流传的数字跨度极大从几百到几十万都有。我给一个从实际项目里总结出来的参考区间目标任务建议样本量说明固定输出格式、字段抽取300 至 800 条关键在格式一致性不在数量特定话术风格迁移1000 至 3000 条需要覆盖多种场景变体领域问答风格对齐3000 至 10000 条需要足够的问题多样性复杂推理路径模仿10000 条以上边际收益递减明显需配评测但要强调的是这些数字的前提是样本质量过关。我做过一个对照实验同样是 1500 条样本一批是从业务系统里直接导出的原始日志另一批是人工逐条改写过的。结果人工改写那批在第 2 轮就超过了原始批训练 5 轮的效果。质量差距带来的收益远大于数量差距。配比方面最容易被忽略的是通用数据的保留。全用业务数据训模型会迅速丧失通用能力表现是问它一个跟业务无关的问题它非要用业务话术来答或者干脆答非所问。我的做法是掺入 5% 到 10% 的通用指令数据比例不用高但必须有。这个比例太高会稀释业务特征太低起不到锚定作用8% 左右是我试下来比较稳的位置。3.3 清洗、去重与难度分层数据清洗这块我有一套固定的检查顺序基本能拦住 90% 的脏数据。第一步是精确去重和近似去重。精确去重用哈希就行近似去重我用 n-gram 重叠率阈值设在 0.8 左右。重复样本的危害不只是浪费算力更严重的是会让模型对某几句话产生过强的概率偏好生成时反复吐出同样的句子。第二步是长度分布检查。把样本的 token 长度画个直方图看长尾。如果有一批样本长度是全模型序列上限的两倍以上那训练时它们会被截断截断的位置如果正好在答案中间模型学到的就是半截话。这类样本要么改写要么直接丢掉。第三步是答案质量筛选。我一般会过一遍这几条答案是否为空或者只有标点答案是否和问题高度重复说明是复制粘贴答案是否包含明显的占位符残留、内部编号、时间戳这类不该出现在最终输出里的东西。最后这条特别重要模型对这类噪声模式的学习能力惊人地强你数据里有一百条带内部编号的答案它就敢在推理时给你编一个编号出来。第四步是难度分层。把所有样本按答案长度和推理步骤粗分成简单、中等、困难三档然后按 4:4:2 的比例配。全用简单样本训模型会变得只会答短问题全用困难样本它会过度啰嗦简单问题也要绕一大圈。分层配比能让模型学会看菜下饭。有个反直觉的观察我在几个项目里都发现把最难的 10% 样本去掉评测分数反而上升。原因大概率是那批样本本身的标注质量最差模型学到的是错误的推理路径。所以别迷信困难样本更有价值先确认它的标注是对的。4. 完整实操从零跑通一次 LoRA 微调4.1 环境与依赖版本锁定环境这块最大的坑是版本漂移。同一份代码今天能跑下周重装环境就报错原因通常是某个底层库的小版本变了。所以我现在的做法是锁死版本号并且在项目根目录放一份环境导出文件。关键的几个依赖关系要注意注意力加速库的版本必须和深度学习框架版本匹配否则会静默回退到普通注意力实现你会发现训练速度莫名其妙慢了一倍但没有任何报错。量化库的版本必须和参数高效微调库匹配否则量化层加载时会报键名不匹配。# 建议锁版本不要用 latest pip install torch2.3.1 --index-url https://download.pytorch.org/whl/cu121 pip install transformers4.43.3 peft0.11.1 accelerate0.33.0 pip install bitsandbytes0.43.3 datasets2.20.0多卡训练时改用启动器脚本不要手写分布式初始化容易漏参数。单机八卡的标准启动方式是这样accelerate launch --num_processes 8 --mixed_precision bf16 train_sft.py还有一个环境变量值得单独提显存碎片。PyTorch 的缓存分配器在长序列训练时容易碎片化明明算下来够用的显存却报 OOM。加一个环境变量开启可扩展分段能明显缓解export PYTORCH_CUDA_ALLOC_CONFexpandable_segments:True4.2 训练配置逐项拆解下面这份配置是我在 8B 模型、单卡 24G、QLoRA 场景下调试出来的可用组合逐项说明为什么这么设。model: name_or_path: /models/llama3-8b-instruct quantization_bit: 4 quantization_type: nf4 compute_dtype: bf16 double_quant: true method: stage: sft finetuning_type: lora lora_rank: 16 lora_alpha: 32 lora_dropout: 0.05 lora_target: all data: cutoff_len: 2048 train_on_prompt: false preprocess_on_fly: true mix_general_ratio: 0.08 train: per_device_batch_size: 1 gradient_accumulation_steps: 16 learning_rate: 1.0e-4 lr_scheduler: cosine warmup_ratio: 0.1 num_epochs: 3 gradient_checkpointing: true logging_steps: 5 save_steps: 200cutoff_len 为什么是 2048。我先统计了全量样本的长度分布95 分位在 1600 左右取 2048 留出余量。设太长纯属浪费显存设太短会截断关键内容。这个值必须从数据里统计出来不能照抄别人的配置。train_on_prompt 为什么设 false。这个参数控制 loss 是不是只在回答部分计算。设成 false 意味着只在助手回复的 token 上算损失用户输入和系统提示不参与。这样做的好处是梯度信号更集中坏处是训练样本的有效 token 变少需要相应增加样本量。per_device_batch_size 设 1、梯度累积设 16。这是显存受限下的折中。单卡 24G 跑 8B 的 4bit 量化序列 2048batch 设 2 会 OOM。梯度累积 16 步后等效 batch 是 16这个量级对 LoRA 来说刚好——太小梯度噪声大、loss 抖太大收敛慢。学习率 1e-4。LoRA 的学习率要比全参微调高一个量级因为可训练参数少、更新幅度天然受限。我试过 5e-5 和 2e-4前者收敛太慢三轮下来 loss 才降了 0.3后者在前 50 步就出现明显震荡最终效果也不如 1e-4 稳。训练步数估算。假设有 5000 条样本3 轮等效 batch 16那么总步数约5000 × 3 ÷ 16 ≈ 937步。这个量级是健康的。如果算出来只有几十步说明要么数据太少要么 batch 太大两种情况都需要调整——步数太少模型根本来不及收敛。4.3 训练曲线与日志怎么读训练启动后我盯的是三个东西不是只看 loss。第一是 loss 的下降形态。健康的曲线是前 30 步快速下降从 2.0 附近掉到 1.2 左右然后缓慢平滑下降全程有波动但幅度不大。如果前 10 步 loss 纹丝不动大概率是数据没进模型或者学习率太小如果 loss 掉到 0.3 以下还继续掉多半是过拟合了赶紧看验证集。第二是梯度范数。很多框架会记录这个值。正常情况下它应该在 0.1 到 2 之间波动。如果持续大于 10说明学习率偏大或者数据里有异常样本如果是 0说明梯度断了检查一下是不是所有参数都被冻结了。第三是吞吐。每秒处理多少 token这个数字能帮你判断硬件有没有被充分利用。8B 模型 4bit 量化训练单卡 A100 级别的卡大概在每秒 3000 到 5000 token消费级 24G 卡在 1200 到 2000 token。如果你的数字只有几百那多半是注意力实现没走加速路径或者数据加载成了瓶颈。# 训练过程中定期抽查生成效果别等训完才看 def spot_check(model, tokenizer, prompts, step): model.eval() for p in prompts[:3]: ids tokenizer.apply_chat_template( [{role: user, content: p}], add_generation_promptTrue, return_tensorspt, ).to(model.device) out model.generate(ids, max_new_tokens200, do_sampleFalse) text tokenizer.decode(out[0][ids.shape[1]:], skip_special_tokensTrue) print(f[step {step}] {p[:30]} - {text[:120]}) model.train()这个抽查环节我强烈建议每个保存点都跑一次成本极低但能提前发现问题。我遇到过一次 loss 曲线完美、但生成结果全是重复片段的情况就是因为训练数据里有一批样本的答案本身就是重复句式光看 loss 完全发现不了。5. 合并、导出与效果验证5.1 合并权重的两条路径训练产出的 adapter 只有几十兆要落地成服务必须做一个决定是合并成完整权重还是保留 adapter 单独加载。合并成完整权重的好处是推理链路简单直接扔给任何推理框架都能跑还能顺手做量化。代价是每次更新 adapter 都要重新合并、重新量化迭代周期长。合并的操作本身很简单from peft import PeftModel from transformers import AutoModelForCausalLM, AutoTokenizer base AutoModelForCausalLM.from_pretrained( /models/llama3-8b-instruct, torch_dtypebfloat16, device_mapcpu, ) model PeftModel.from_pretrained(base, ./output/checkpoint-800) merged model.merge_and_unload() merged.save_pretrained(./merged, safe_serializationTrue) AutoTokenizer.from_pretrained(./output/checkpoint-800).save_pretrained(./merged)注意这里要在 CPU 上合并。如果在 GPU 上做bf16 权重加上临时副本很容易把显存吃满尤其是 8B 以上的模型。保留 adapter 单独加载适合多租户场景——一份基座权重挂多个不同业务的 adapter切换时只换那几十兆。主流推理服务框架现在都支持动态加载多个 adapter显存占用增加很小。这条路的代价是推理时多一层矩阵加法延迟会略微上升大概 3% 到 8%具体看秩的大小。一个容易忽略的点合并后的权重再做 4bit 量化用于部署和训练时的量化是两回事。训练时的量化是为了省显存部署时的量化是为了省显存加提吞吐两者用的算法、校准数据都可能不同。部署量化一定要用一批真实业务输入做校准别拿通用语料凑数否则精度掉得莫名其妙。5.2 评测集怎么设计才不骗自己评测这一环我看到的最普遍问题是只用训练同分布的数据做测试。这样测出来的分数往往漂亮得不像话上线就崩。我现在的评测集固定分三块。第一块是同分布测试集。从训练数据里留出 5% 到 10%不参与训练。这块的作用是确认模型确实学到了东西如果这块分数不涨说明训练配置有问题。但它的分数只能作为下限参考不能当真实效果。第二块是真实场景集。从业务系统里另外抽一批没标注过的真实输入人工评估输出质量。这块最能反映上线后的表现因为真实输入的分布永远比训练数据更野——有错别字、有口语、有半截话、有多意图混杂。我一般会抽 100 到 200 条按可用、需修改、不可用三档打分。第三块是通用能力回归集。这块最容易被省掉但它防的是灾难性遗忘。挑 50 到 100 条和业务完全无关的通用问题对比微调前后基座模型的回答质量。如果发现明显退化就回去调通用数据的掺入比例。评测块样本量评估方式合格线同分布测试集200 至 500自动指标加人工抽检明显优于基座真实场景集100 至 200三档人工打分可用率不低于 85%通用回归集50 至 100与基座对比退化不超过 10%还有一点评测要用固定的解码参数。温度、top_p、重复惩罚这些训练前后必须保持一致否则你测的不是模型差异是采样差异。我习惯在评测时用贪心解码把随机性彻底去掉这样结果可复现。6. 踩坑实录与速查表6.1 loss 异常的归因路径loss 出问题是最常见的求助场景我整理了一张速查表按现象查原因比盲目调参快得多。现象最可能原因排查方法处理方式loss 全程不动参数全冻结或数据未加载打印可训练参数数量检查注入模块名是否匹配loss 前几步就 NaNfp16 溢出看是否用了 fp16切 bf16加梯度裁剪loss 降到 1.0 后横盘学习率过小或数据重复抽样看数据多样性提学习率补充样本loss 降到 0.3 以下过拟合看验证集 loss 是否回升减轮数加 dropoutloss 剧烈震荡学习率过大或 batch 过小看梯度范数是否超 10降学习率加累积步数训练 loss 低但生成差模板不一致或过拟合对比训练与推理的输入构造统一模板重训这里面我认为最值得展开的是训练 loss 低但生成差。这个现象背后有两种完全不同的原因处理方式相反。一种是过拟合模型把训练样本背下来了遇到稍微不同的输入就崩。表现是同分布测试集分数极高真实场景集分数极低。解法是减轮数、加 dropout、减秩、补数据。另一种是模板不一致模型学的是 A 分布的输入到输出的映射你推理时喂的是 B 分布的输入。表现是同分布测试集分数也很低因为连测试集都用了错误的模板。解法是统一模板函数。这两种情况的区分方法很简单跑一遍同分布测试集就知道了。6.2 生成质量问题的六种典型表现训练跑通了生成效果不对通常落在这六种表现里。输出带角色前缀。比如回答开头自己加一个assistant。这是模板没对齐的典型症状模型在模仿训练时见到的格式因为它不确定自己该不该带这个标记。检查训练样本里角色标记的位置以及推理时是不是用了生成提示。回答突然中断。大概率是序列被截断了。检查 cutoff_len 是不是小于样本实际长度以及推理时的最大生成长度是不是设得太小。反复重复同一句。三个可能训练数据里有大量重复样本结束标记没学好模型不知道何时停解码时重复惩罚设得太低。按这个顺序排查通常第一个就能命中。答非所问。如果训练 loss 正常那多半是数据里的问题和答案配对错了。我就遇到过一批数据在清洗时错位了一行导致所有问答整体偏移loss 曲线完全正常但输出全是胡话。这种错误只能靠人工抽检发现所以训练前抽 20 条肉眼过一遍是必须做的功课。只会一种句式。数据多样性不足。所有答案都是首先……其次……最后……的结构模型就只会这一种。解法是刻意在数据里加入不同长度、不同结构的答案。通用能力明显退化。通用数据掺入比例太低或者训练轮数太多。前者加数据后者减轮数。6.3 我个人的避坑清单最后分享几条我认为最值钱的经验都是踩过坑之后才明白的。先跑通再优化。第一次训练用 100 条样本、1 轮、r 取 8目标是确认整条链路能跑通、能出结果、能合并、能推理。这一步花两小时能省掉后面两天的排查。我见过太多人一上来就上全量数据、上大秩、上多卡结果某个环节出错根本不知道是哪一层的问题。固定随机种子。训练、数据打乱、评测采样全部固定种子。这样你改一个参数效果变化才能归因到那个参数上。不固定种子做对比实验等于在噪声里找信号。保存检查点要密。每 200 步存一次并且每个检查点都做一次生成抽查。我最惨的一次是训了三轮最后发现第 2 轮的效果最好但没保存中间检查点只能重训。别迷信大秩。我做过一组对照r 从 8 一路试到 128效果在 32 附近就到顶了再往上纯属浪费显存还更容易过拟合。任务越简单最优秩越小。上线前一定要做压力测试。训练集里没有的超长输入、纯符号输入、中英混杂输入、多轮追问都要单独测一遍。模型的崩溃往往发生在这些边缘情况上而不是在你精心准备的评测集里。记录每一次实验。参数、数据版本、评测分数一条一条记下来。做到第十次实验的时候你会感谢前九次的自己——因为人真的记不住哪次改了什么。这套流程我在几个不同规模的团队里都推过最慢的一次是两周跑通第一版可用模型最快的一次是三天。差距不在技术能力而在数据准备得干不干净、评测方案想得清不清楚。模型本身反而是最容易的那一环脚本跑起来就完事了。
