聊到LLaMA-Factory微调网上的教程其实已经不少但大多数是“照抄命令跑通一次”的路子真正把数据、参数、评估串起来讲透的很少。这篇帖子的定位是我自己沉淀后的“个人重制版”不打算给你一份万能模板命令而是把LLaMA-Factory微调入门路上最容易出问题的地方掰开揉碎告诉你每一步背后的原因和我的判断方式。内容比较适合第一次接触SFT的读者也适合那种已经跑通训练但效果不佳、想回头找症结的人。我反复折腾过好几版微调方案踩过数据格式返工、学习率起飞、损失下降但回答崩坏这些典型坑。下面写的都是我可以直接复现的经验步骤和参数都是实操验证过的你拿着能省不少试错时间。1. 为什么我会把微调教程重制成“判断路径”而不是“照抄命令”1.1 官方文档能让你启动但不会告诉你什么时候该停LLaMA-Factory本身的文档和示例写得足够简洁克隆仓库、装依赖、填数据集配置一条命令就能把LoRA训练跑起来。但真到了业务落地你会发现“能启动”和“能完成一次有效训练”之间有一段不小的距离。官方示例默认使用的是通用数据集参数也是偏向演示性质它不会告诉你你手上的业务问答数据该放多少条、类别不平衡会不会导致模型偏科、loss降到多少才算正常、训练多久就应该停。我最早跑完一次7B规模的LoRA训练命令执行成功日志里没有红色报错看起来一切都很正常。但等我拿真实问题去问微调后的模型它把训练集里的标准答案复读了一遍换个问法就露馅。这时候我才意识到微调不是一个“执行成功”就结束的事而是一连串需要判断和取舍的过程。所以我重制这份入门内容的第一个目标是把那些“文档默认你知道、实际上你根本不了解”的地方补上。比如模型加载路径和tokenizer的一致性、数据集中字段怎么映射到框架里、训练集和验证集的分配方式这些细节决定着你训练的是个有效模型还是一堆噪声。1.2 “能跑通”与“能用在项目里”是两回事很多人入门的标志是“命令不报错”但这个标准其实很低。我后来复盘发现跑通和可用之间至少隔了三道门槛。第一道门槛是数据。训练集的质量直接决定模型的上限。同样是500条数据有人拿出来模型立刻学会某种说话风格有人拿出来模型越训越乱。差别往往不在模型参数而在数据字段是否干净、指令与输入是否拆得合理、输出是否有多余的格式错乱。第二道门槛是参数。LoRA rank、学习率、epoch、序列长度这些参数没有绝对正确的答案只有适合当前数据量和硬件条件的组合。很多人习惯照搬教程里的参数但场景不同最优参数也不同硬套会造成过拟合或者训练不足。第三道门槛是评估。训练结束后大多数人的做法是拿着几个例子问一问感觉还行就收工。但模型口语化地说“还行”并不意味着任务正确率达到要求。没有评估集、没有对比基线、没有bad case分析你很难判断这次训练到底是变好了还是变差了更没法在下一轮优化时找准方向。这三道门槛是我重点重制的内容。我希望读者看完后不是只会粘命令而是能形成一套属于自己的微调判断框架。1.3 重制版的内容组织逻辑这版教程我按实际工作流的顺序来组织而不是按官方手册的功能菜单去排列。第一部分是环境准备。这部分不啰嗦但必须覆盖显存估算、依赖安装、模型文件确认等前置项。第二部分是数据。我会拆解SFT阶段常见的JSON结构讲清楚instruction和input的区别、history怎么填、system提示词什么时候该用。第三部分是训练。我会给一条可以直接套用的LoRA训练命令并逐个参数说明取舍逻辑重点讲学习率、batch size和max_length之间如何平衡。第四部分是评估。这是大多数人最欠缺的一环。我会讲怎么构建小规模评测集、怎么判断过拟合、怎么有效分析bad case。第五部分是导出和部署。训练产物如何合并回底座模型导出后如何校验部署时该保留LoRA adapter还是合并权重。最后是我实际踩过的一些坑以及我建议直接绕开的弯路。整体结构就是这条从数据到上线的主线中间穿插原理和判断方法。2. 环境准备显存、依赖和底座模型的下载顺序2.1 先按显存倒推训练方式别拿到模型就开训第一次做LLaMA-Factory微调的人最容易犯的错是先把底座模型下载到本地再折腾依赖最后发现显存不够。我建议反过来先搞清楚自己手里GPU的显存大小再决定训练方式和模型规模。表格里是我个人常用的起步参考训练方式7B级模型参考显存实际体验LoRA 半精度约16GB24GB用起来更宽裕16GB要压低batch或序列长度LoRA 基座量化约8-12GB消费级显卡可尝试但精度略受影响全参数微调40GB以上单卡基本不够建议多卡或更大显存我自己的经验是如果只有单卡16GB优先选择LoRA配合短序列max_length设在512到1024之间batch_size设为1到2梯度累积别省这样整体负担小很多。如果显存到了24GBLoRA训练7B级模型就很轻松了甚至可以稍微放宽序列长度。这里的核心逻辑是微调不只是把模型加载进显存训练过程中还要保存梯度、优化器状态和中间激活值。显存估算必须留出安全余量不然跑到一半OOM前面的时间全白费。所以我建议训练前先跑一条短训练命令确认峰值显存再上完整数据。2.2 依赖安装的顺序决定你后面省不省事LLaMA-Factory的环境依赖不算复杂但版本错位会引发很多莫名其妙的问题。我最推荐的顺序是先确认底层计算环境再装深度学习框架最后装LLaMA-Factory相关依赖。第一步创建独立的环境管理会话避免污染其他项目环境。第二步按驱动版本确定CUDA版本再安装对应版本的PyTorch。这里最怕的是驱动新、PyTorch旧或者反过来。装完PyTorch后先验证一下GPU计算环境是否可用python -c import torch; print(torch.__version__, torch.cuda.is_available())这一步能正常输出模型计算可用性再继续往下走。第三步安装transformers、datasets、accelerate、peft、trl这些组件。版本上我不建议全装最新版优先看LLaMA-Factory当前版本要求的依赖范围。装完之后跑一下仓库自带的启动脚本或简单训练示例确认环境整体没有冲突。这类依赖问题有个共性报错信息往往不直接指向根因。有时报“缺少某个算子”实际上是对应框架版本不匹配。所以环境准备阶段花十分钟验证计算环境可用性比训练到一半排查报错划算得多。2.3 模型文件下载优先从可访问的镜像渠道获取底座模型文件通常包含多个分片权重、配置文件和tokenizer文件单靠浏览器一个个下载很不现实。我用的是LLaMA-Factory里支持的两个主流模型下载渠道一个偏海外一个偏国内镜像。国内网络环境下我更推荐直接用国内镜像站的方式速度明显更快。下载完成后不要直接开训花两分钟检查文件完整性确认模型权重文件的文件名和分片数量与发布说明一致。确认目录下包含config.json、tokenizer文件等基础文件。如果下载平台提供了校验值最好做一次比对。我遇到过的问题是把完整权重放在了更深的嵌套目录里启动时路径没写对框架自动重新下载或者报错。模型的本地路径填到能直接看到config.json那一层不要多套一层目录。2.4 开训前的环境自查清单为了减少无效训练我每次开新项目都会先过一遍精简检查计算环境可用GPU驱动和深度学习框架版本匹配。底座模型路径正确能看到config.json。内存空间足够因为训练过程会写临时文件。数据集格式已按预期准备完毕框架读取时没有字段缺失。输出目录可以被写入并且不会和已有训练产物重名覆盖。这套检查听起来没什么技术含量但能拦住绝大多数低级失败。尤其是输出目录的处理不少人反复训练时之前的结果还在新结果直接覆盖想对比都找不到历史版本。我建议每次训练都使用独立的输出目录比如带上日期或实验代号。3. 数据是微调的唯一真相格式、清洗和采样3.1 先看懂SFT数据的组织方式LLaMA-Factory在SFT阶段读取的数据以JSON格式为主。常见的数据字段包括system、instruction、input和output部分场景还会用到history来记录多轮历史对话。理解这些字段之间的关系是准备数据的起点。system可以理解为全局人格设定或任务背景比如“你是一个耐心的客服助手”这条信息会在多轮对话中一直影响模型。instruction是当前这一轮的具体指令告诉模型要做什么。input是被处理的对象属于辅助输入内容。output是期望模型生成的答案。history是可选字段用来承载多轮上下文。在实际数据里很多人的困惑是instruction和input如何划分。我个人的处理习惯是能放进指令里的信息尽量放指令input只放真正独立的内容。举例子来说“把下面这段文字总结成三点”是instruction“文字内容”是input这样职责清晰模型也更容易学到正确的输入输出关系。dataset_info.json里需要把自定义数据集路径注册进去。配置时重点确认数据集的columns映射是否写对比如instruction对应数据里的哪个字段、output对应哪个字段。字段名不一致会导致训练时把空值当输入loss也可能照常下降但模型根本学不到东西。3.2 从原始业务资料到训练数据的处理流程我建议所有准备数据的人都建立一个固定流程不要用临时脚本堆数据。下面是我在实践中反复使用的六步流程每一步都有明确的产出。第一步收集原始语料。把问答记录、文档片段、客服对话等所有潜在数据源放到统一目录。第二步清洗噪声。清除乱码、HTML标签、多余的换行符、不可见字符。清洗的目标是把数据变成规整的文本。第三步脱敏处理。涉及隐私的信息要替换掉比如把具体的姓名、手机号、地址等替换成占位符。这不只是合规问题也是为了避免模型在生成时复述出这些信息。第四步整理成问答对。把一段对话、一篇资料拆成instruction、input、output的结构。拆分的核心原则是每一条数据都要有明确的任务目标和标准答案。第五步检查字段对齐。所有条目结构应一致不要出现一部分数据有history、另一部分没有的情况。第六步抽样人工检查。随机抽10条至20条从指令清晰度、答案准确性、格式一致性三个角度打分。人工检查通过后再送入训练。有的读者可能觉得自己数据量很大人工检查浪费时间。我的经验是如果数据质量本身不错人工检查一轮花不了太久但能避免模型学到大量脏数据的副作用。3.3 质量控制的五个观察点数据清洗完成后不要急着开训。我会用一套固定的观察点再扫一遍数据。第一个观察点是重复率。如果数据里存在大量近似重复的句子模型会对这部分内容过度记忆降低泛化能力。我一般会先做一遍文本去重尤其是模板痕迹明显的自动生成数据。第二个观察点是类别平衡。如果业务任务里85%的样本是“订单查询”只有15%是“退货处理”训练出来的模型在退货处理上的表现会明显偏差。我会对类别做统计必要时通过扩充少数类别或欠采样多数类别来调整比例。第三个观察点是长度分布。max_length是训练时的重要参数如果数据里大量条目远超设定长度截断后会把答案后半截切掉模型学不到完整输出。我会看训练数据的长度分布按覆盖大多数条目的长度设置max_length。第四个观察点是答案质量。有些输出包含“我不知道”这类模糊表达或者干脆是错误答案。这种数据要人工清理不能只靠脚本过滤。第五个观察点是格式一致性。例如所有答案是否统一包含标点、是否统一换行、是否统一保留特定行业术语。格式一致性对模型生成风格的影响比很多人想象的大。3.4 数据量级多少条才算够“微调到底需要多少数据”可能是入门阶段被问最多的问题。我的回答是取决于你想让模型发生什么变化。如果目标是改变说话风格、让模型适应某种角色设定那么几百条高质量数据往往就够了。风格迁移的本质是让模型学分布偏好不需要覆盖所有知识。如果目标是注入新的业务知识比如让模型熟悉产品操作手册里的具体流程那么几千条起步比较合理并且每条都要有清晰的标准答案。如果是复杂推理任务对数据质量的要求会更高数量反而其次几百条经过精心构造的推导例子能发挥的价值往往大于几万条粗糙数据。在真正投入全部数据训练之前我建议先用少量数据跑通整个流程比如抽50到100条出来做一次短训练。这能提前发现字段映射、参数设置和代码层面的问题避免等全部数据准备好后再翻车。花少量时间和算力跑一次完整链路比直接大训练到最后再排查要高效得多。4. 第一条LoRA训练命令、参数与日志判断4.1 为什么第一个实验选LoRA而不是全参数微调入门阶段我几乎都建议先做LoRA。训练成本低、实验周期短、迭代速度快而且不会把底座权重改得面目全非。我把LoRA理解为在原始权重旁边挂了一组低秩矩阵训练时只更新这组附加矩阵原始模型参数保持冻结。这样显存占用比全参数微调小很多训练速度更快切换不同任务也方便——不同任务的LoRA可以分别保存推理时按需加载。LoRA还有一个隐性优势它天然带有一定的正则化效果。因为可训练参数很少模型不容易在小型数据上急速过拟合容错空间比全参数微调大。对入门阶段的调试来说这是非常友好的特性。4.2 一条可以直接跑通的训练命令示例下面这条命令来自我实际跑过的7B级模型LoRA训练数据量约3000条单卡24GB显存整体开销可控。你可以直接复制后按路径替换。llamafactory-cli train \ --model_name_or_path /models/your-base-model \ --stage sft \ --finetuning_type lora \ --dataset my_training_data \ --template llama \ --output_dir ./output/lora-demo \ --learning_rate 2e-4 \ --num_train_epochs 3.0 \ --per_device_train_batch_size 2 \ --gradient_accumulation_steps 8 \ --lora_rank 8 \ --lora_target q_proj,v_proj \ --max_length 1024 \ --save_steps 200 \ --logging_steps 20 \ --eval_steps 200 \ --do_train true \ --do_eval true \ --val_size 0.05这里有几个关键点需要说明。--model_name_or_path要指向包含config.json的完整底座模型路径不要多包一层目录。--dataset对应的是dataset_info.json里注册的自定义数据集名称不是文件路径本身。--template要跟底座模型匹配写错的话对话格式会乱掉模型输出可能前言不搭后语。--per_device_train_batch_size设为2是因为24GB显存下更稳妥。如果你显存不足16GB可以换成1同时提高梯度累积步数来保持整体批量大小。--val_size是训练集中切出来做验证的比例这里设5%一方面够用来观察验证损失另一方面不至于减少太多训练数据。4.3 关键参数的取舍逻辑为什么学习率是2e-4因为LoRA只更新少量附加参数它比全参数微调承受得起更大的学习率。全参数微调常用1e-5而LoRA常用1e-4到2e-4。如果学习率超过5e-4就很容易出现损失暴增或灾难性遗忘。第一次训练时我建议先保持2e-4跑完再看效果。--lora_rank 8是一个性价比很高的选择。rank越大可训练参数量越多模型表达能力越强但显存和过拟合风险也会上升。对大多数业务场景rank 8到16足够用。有些任务觉得模型学不进去我一般先检查数据和训练时长而不是急着调高rank。--max_length 1024代表输入和输出拼起来的最大长度。长度越长单条数据占用的显存越高训练速度越慢。如果数据里大部分是短问答1024完全够用。如果业务场景需要输出长文本可以调到2048但要同步降低batch size。--gradient_accumulation_steps 8配合--per_device_train_batch_size 2相当于每8个小步完成一次参数更新整体批量大小约等于16。批量太小时噪声大批量太大时单次更新计算时间拉长。16是一个比较稳的起步值。下面用表格总结我常用参数的调整方向参数起步值调整信号调整方向learning_rate2e-4loss震荡或上升降到1e-4num_train_epochs3.0验证loss回升减少到2lora_rank8学不进去增加到16max_length1024长输出被截断增加到1536或2048per_device_train_batch_size2显存OOM降到14.4 训练日志怎么读才不会被数字骗了训练过程中每20步打印一次日志里面有几项需要关注。最关键的是loss。刚开始几百步loss通常会快速下降这个阶段说明模型正在快速吸收主要模式。随后下降速度变缓进入一个平台期这很正常不代表训练卡住了。验证集上的loss如果整体保持下降但末端略微回升往往是过拟合信号。如果验证loss上升得很明显我一般会提前终止训练而不是等它跑完预设轮次。有些读者担心loss没降到某个数值就不算成功这个想法可以放一放。不同数据、不同任务loss的合理范围差异很大重要的是loss与验证集表现组合起来看。训练日志里还会打印当前步数、学习率和梯度范数。梯度范数偶尔异常不一定要干预但持续飘忽或出现特别大的数值时我会优先检查学习率和数据里是否有异常长文本。5. 训练完不等于完成评估、过拟合与bad case排查5.1 一个很常见的怪象loss很低回答却很烂我见过不少人在第一次微调后困惑训练损失明明降得很低可模型在实际回答时表现得像失忆。问题往往出在三个方面。第一个方面是数据泄露。训练集和评测集没有区分好模型在训练时已经把评测问题背下来了评测时自然表现得好。这种做法得出的漂亮结果没有说服力。第二个方面是过拟合训练集。模型记住了训练集的标准答案但稍微换个问法就不会了。通俗来说它不是学会了做这道题而是背下了这道题的答案和它的某个变体。第三个方面是评测方式本身有偏差。只挑自己觉得模型应该答对的几个问题去问没有覆盖多轮、长文本、对抗性输入等真实场景结果自然显得不错。我后来给自己定了一条规矩训练完先用训练集样本测试确认模型能学进去再用独立验证集或评测集测试确认泛化能力最后在没有见过的随机业务样例上做一轮盲测。三层测试都过了才算达到可以对比版本的门槛。5.2 小规模评测集与评分维度的搭建做完整评测不需要投入巨大成本一个足够好的小评测集用50到100条数据就能支撑日常迭代。关键是这些数据要独立于训练集并且覆盖真实业务里的高频场景。我的评测集来源有两种。一种是从历史对话记录里随机抽出来的真实样例这些数据必须和训练数据没有重叠。另一种是按照业务场景编写的模拟问题用来测试特定能力比如多轮记忆、边界拒绝、格式遵循。评分维度可以按任务复杂度拉一个简单表格维度说明评分回答准确性是否输出正确内容1-5指令遵循是否严格按要求的格式输出1-5多轮一致性上下文多轮时是否保持连贯1-5语气风格是否符合设定角色或语气1-5拒答表现遇到无法回答的内容时是否得体1-5每次训练后我会对评测集跑一批通用提示词把所有输出记录下来按表格评分。不用每轮都精读所有数据但要保证每一轮都能分维度对比。5.3 过拟合不好发现教你三个检测信号过拟合有一些可以主动检测的信号。第一个信号是验证集loss先降后升。训练日志里如果验证loss在某一轮开始持续升高基本可以判断后续轮次会让模型越来越偏离理想状态。第二个信号是复读训练数据。你拿一条训练集里的问题去问模型不是给出近似答案而是几乎逐字复刻标准答案这就是记忆力过强、理解力不足的表现。第三个信号是通用能力衰退。微调前模型能回答的常识问题微调后反而答不好说明训练指令冲掉了原有能力分布。检测方式很简单准备一组和业务无关的通用问题在微调前和微调后分别回答对比。通用能力降幅过大时我会降低epoch数、减小学习率或者检查数据里是否多条数据都偏向同一模式。5.4 迭代方向数据优先再谈参数当评估结果不理想第一反应别急着调参。调参确实有用但很多时候问题的根源在数据。如果模型回答不准确先看标准答案是否本身就有错误或歧义。正确答案有问题模型再怎么练也是错。如果模型风格不对检查数据集里的输出风格是否统一或者数据里混杂了大量不符合目标的文本。如果模型在某些类别上明显落后回到类别平衡统计那里给少数类别补充数据。在确认数据层面无大问题后再考虑调整参数。过拟合优先减少epoch和降低学习率欠拟合优先增加数据量或适度提高学习率。这样把“数据问题”和“参数问题”分开排查迭代效率会高很多。6. 导出合并与落地部署微调模型真正可用的一步6.1 LoRA训练实际改了什么从原理上看LoRA训练时原始权重没有被修改训练产物是一组加在特定层上的低秩增量矩阵。推理时如果你不合并也可以临时把这些增量加载进去效果一样。合并的意思是把原始权重和增量矩阵相加生成一个新的融合权重文件。为什么需要合并主要是因为部署时越简单越不容易出错。如果推理框架原生支持加载adapter当然可以保留LoRA形式但很多部署环境希望的是一个独立完整的模型目录直接当成普通底座模型来加载。每次合并前我都会保留原始权重和原始LoRA产物确认合并路径无误避免覆盖重要文件。6.2 导出合并命令与必要校验LLaMA-Factory提供的导出命令思路很清晰。指定底模路径、LoRA产物路径、模板类型然后输出到新目录llamafactory-cli export \ --model_name_or_path /models/your-base-model \ --adapter_name_or_path ./output/lora-demo \ --template llama \ --finetuning_type lora \ --export_dir ./output/merged-model导出完成后我会做三层校验。第一层是文件完整性新目录里应该有和底座模型一致的文件结构。第二层是加载验证用加载函数尝试加载新目录看看能不能正常跑通一次简单推理。第三层是A/B对比合并模型调用一次典型业务问题再回头看LoRA训练时输出的该问题答案确认两者基本一致。有一次我合并后没有校验直接部署上线结果模型输出里混入了奇怪的模板前缀。排查好久才发现是模板参数没有对齐。所以这类校验步骤最好不要跳过。6.3 部署形式合并模型与保留adapter的取舍部署时我会按场景做选择。如果任务比较固定只有一个微调版本要上线合并成完整模型最省心。后续直接把它当作普通底座模型接入常见的推理服务即可。如果同一底座同时有多个任务适配比如一个负责客服一个负责内容生成那保留多个adapter文件更灵活推理时按需切换。但保留adapter形式对推理框架有一定要求它需要支持动态注入LoRA权重。如果团队现有部署链路不支持就老老实实合并后再上。我个人的习惯是凡是进入了正式服务流程尽量用合并后的完整模型如果是实验验证阶段才保留adapter形式。6.4 训练产物的保存习惯训练过程中输出目录会按save_steps保存多个checkpoint。很多人训练完只保留最后一份这种做法容易吃亏。我推荐的保存习惯是保留每个关键checkpoint下对应loss最低或验证loss最低的那份。记录每一项实验的学习率、epoch、数据版本、备注信息。合并模型时在目录名里带上版本号或日期方便回滚。checkpoint文件占空间较大不需要无限保存。常规做法是保留最优的一个或两个其余在确认不需要后清理。清理前务必确认最优checkpoint已经导出合并成功。7. 那些我花过学费的弯路建议你直接绕开7.1 数据格式错一个字段损失函数照样降得很顺我第一次微调时把自定义数据的字段映射写错了。结果框架把input字段读成了空值模型训练时相当于只看了半句话和答案。最迷惑的是训练全程loss正常下降输出目录里也有checkpoint一切看起来都“成功”了。直到评估阶段发现模型压根没学会指令回头查数据映射才发现问题。这个问题让人防不胜防的原因在于字段映射错误几乎不会导致训练失败它会悄悄污染学习信号。我从那以后给自己立了条规矩正式训练前先读几行数据用打印方式确认每条记录的字段是否正确落到预期位置有必要的话先跑一条极短训练看训练loss曲线是否明显下降。7.2 学习率从2e-4调到6e-4模型只会“激动”不会回答有段时间我觉得模型学得太慢把LoRA学习率从2e-4直接提到6e-4。结果训练前期损失下降得非常快我一度以为找到了更优解。等验证阶段测试模型回答变得碎片化甚至出现了重复输出和车轱辘话。这是因为过大学习率让低秩增量矩阵一下跳得太远破坏了原有模型参数分布的合理性。微调不是越快越好而是在速度和可靠性之间找平衡点。吃过这次亏后我再调学习率都按1.5倍以内去微调并且每次调整都会搭配一次短验证不直接跑完整训练。7.3 盲目堆GPU数量不如先检查单卡吞吐多卡训练能缩短时间但前提是代码和数据加载逻辑正确。我有一次试图把训练扩展到多卡结果发现速度并没有随GPU数量线性提升。仔细排查后发现大部分时间花在数据读取和预处理上GPU资源大量空闲。对入门项目来说先用单卡跑通整个流程比盲目分布式更重要。如果确实需要加快速度可以先把数据预处理的耗时压下去比如缓存处理结果、减少重复读取、使用更快的磁盘。GPU数量增加不会帮忙解决数据读取瓶颈只会让瓶颈更加明显。7.4 调参前先做实验记录不然等于白调调参不可怕可怕的是调完之后不记得之前是怎么调的。我见过很多新手跑完一轮训练发现效果不好随机改几个参数再来一轮最后训练了好几个版本却分不清哪个是哪个。我的建议是准备一张简单的Markdown实验表或者用Excel记录至少包含实验日期、数据版本、数据集条数、学习率、epoch、rank、max_length、训练loss、验证loss、评测结果和备注。刚开始可能觉得麻烦但等你要复盘或向别人请教时这份表格的价值就体现出来了。我在后续项目里一直坚持这个习惯后来返工找问题的时间大幅缩短。很多困惑其实不是模型造成的而是实验缺乏可复现的上下文。做LLaMA-Factory微调入门真正的手感不是靠别人一句两句能点透的得自己走完从数据准备到评估对比的完整闭环。我自己的体会是先别急着追求复杂技巧把最基础的LoRA流程反复跑顺几遍学会读日志、看损失、做评估再往SFT、多轮数据、分布式训练这些方向扩展会轻松很多。如果你一开始只能记住一条建议那就是先用少量数据跑通再扩量。我到现在依然保持这个习惯任何新实验都用最小数据集验证可行性确认链路没问题之后才上完整数据。这条路可能看起来多花了一些时间但它省下的混乱和返工时间远比你想的多。