1.1 工具定位与核心能力：统一训练、微调、评估与推理入口
我最早接触大模型微调的时候，项目里散落着好几套脚本，训练用一套、评估用另一套、推理部署还得再拼一套，光是把环境对齐就够折腾半天。后来同事丢给我一个仓库地址，说“试试这个”，那是我第一次认识 Llama-Factory。用下来的直觉感受是，它想做的事情很明确：把训练、微调、评估、推理这些环节收进同一个入口，省掉在不同工具之间来回搬数据的麻烦。
从功能覆盖上看，它支持全量微调、LoRA、QLoRA 这类常见方案，模型侧也能对接 LLaMA、Qwen、Baichuan、ChatGLM 等一批开源权重，切换模型时配置文件改几个字段就行。我更看重的是它对数据格式和训练模板的抽象，不同模型各自有一套对话模板，工具帮忙做了映射，使用者不必为每个模型重写预处理逻辑。这一点在实际项目里能省下不少排查时间。
站在团队协作的角度，统一入口还有一层隐性价值：新人接手时只需要理解一套命令行和一套配置结构，学习成本明显低很多。我现在的习惯是先用 WebUI 跑通一个小实验，再把同样的参数固化进 YAML，交给脚本去跑，整个流程从探索到复现都落在同一个工具生态里。
1.2 环境安装与快速验证：依赖配置、模型获取与WebUI/CLI启动
安装这件事，我踩过几次坑之后总结了一条朴素的经验：先把 Python 和 PyTorch 的版本对齐，再去装 Llama-Factory 本体，顺序反过来容易反复卸载重装。官方文档里给的依赖清单比较细，torch、transformers、datasets、accelerate、peft 这些是绕不开的，显卡驱动和 CUDA 版本也要提前确认，尤其是用 QLoRA 的时候对 bitsandbytes 有额外要求。
模型获取部分，我一般直接从 Hugging Face 拉权重，网络条件一般的话就提前用镜像或者本地缓存路径。模型目录结构最好保持原样，配置文件里指向模型根目录即可，别自己去改 tokenizer 相关的文件名。有一次我手动重命名了 tokenizer_config.json，导致模板匹配失败，排查了快一个小时才反应过来，这种低级错误挺磨人的。
启动验证我推荐先跑 WebUI，llamafactory-cli webui 一行命令就能拉起界面，加载模型、选数据集、点开始训练，整个链路能不能跑通一眼就能看出来。CLI 方式更适合接入自动化流水线，llamafactory-cli train examples/train_lora/llama3_lora_sft.yaml 这种写法我平时用得最多。我的习惯是两个入口都验证一遍，WebUI 确认依赖没问题，CLI 确认参数能复现，两边都过了心里才踏实。
1.3 llama-factory 自定义数据集格式：Alpaca、ShareGPT与对话数据字段映射
数据格式这块，我觉得是新手最容易卡住的地方。Llama-Factory 官方主推两种结构：Alpaca 格式和 ShareGPT 格式。Alpaca 比较扁平，一条样本就是 instruction、input、output 三个字段，适合指令微调这类任务，字段含义直观，自己写脚本生成也方便。
ShareGPT 格式则面向多轮对话，核心是 conversations 数组，里面每条消息带 from 和 value 两个键，from 通常取 human、gpt、system 这些值。我第一次用 ShareGPT 数据时没注意角色映射，把 assistant 写成了 gpt，工具照样能读进去，但训练出来的模型回复风格很奇怪，后来对着文档把角色名改回来才正常。这类细节文档里写了，只是容易被跳过。
字段映射的灵活性也值得说一句。Llama-Factory 允许在 dataset_info.json 里用 columns 字段做重命名，比如你的原始数据里叫 query 和 answer，可以映射成 instruction 和 output，不用改原始文件。我手上有一批历史数据字段名五花八门，就是靠这层映射统一进来的。多轮数据我一般直接转成 ShareGPT，单轮任务用 Alpaca 更省事，两种格式在同一个项目里混用也没问题，注册时分开写就行。
1.4 数据注册与预处理检查：dataset_info、模板匹配、截断与样本质量校验
数据准备好之后，还得在 dataset_info.json 里注册一下，工具才知道去哪里读、按什么格式解析。这个文件放在 data 目录下，每条数据集配一个名字，写明 file_name 和 formatting，Alpaca 用 alpaca，ShareGPT 用 sharegpt，多轮数据再补上角色映射的 tags 配置。我见过有人把注册名和文件名写成一样的，结果路径解析失败，其实两者没有强制关系，起个语义清晰的名字反而更好维护。
模板匹配是另一个需要留意的地方。不同基座模型有各自的对话模板，比如 Llama 3 用 llama3，Qwen 用 qwen，训练时 template 参数要和模型对上。模板不匹配的典型表现是 loss 下降很慢，或者推理时输出里混进奇怪的标记。我的做法是先拿几十条样本跑一个 epoch，看看输出格式对不对，再放全量数据。
截断和样本质量校验属于预处理阶段的基本功。cutoff_len 设得太小会把长样本截掉一半，设得太大又浪费显存，我一般根据数据长度分布取 95 分位附近的值。样本质量方面，我会写个小脚本统计空 output、超长 instruction、重复样本的比例，脏数据进训练集带来的影响很难在后期弥补。这套检查流程跑顺之后，后面换数据集基本就是复制粘贴改几个路径的事。
2.1 llama-factory LoRA微调教程：目标模块、rank、alpha、dropout与学习率设置
说到 LoRA 的参数，我头一回配的时候也是一头雾水，名字都认识，放到一起就不知道该调哪个。折腾过几个项目之后，我慢慢形成了一个自己的默认组合。目标模块这块，我一般先按模型架构选 all，让它自动覆盖注意力层的 q、k、v、o 投影，Llama 系和 Qwen 系基本都能这么干。只有显存特别紧张或者只想做轻量适配时，我才会手动指定到 q_proj、v_proj 这两个最常用的模块。
rank 和 alpha 是成对出现的，我的经验是 rank 别一上来就拉满，8 到 16 对大多数垂直领域任务已经够用，rank 太大反而容易把模型带偏。alpha 通常取 rank 的两倍，比如 rank 16 就配 alpha 32，这是我试下来比较稳的比例。dropout 我一般设在 0.05 附近，数据量少的时候会往上提到 0.1，算是给过拟合加一道保险。
学习率这个字段值得单独拿出来说。LoRA 微调的学习率比全量微调要高一个量级，我常用的区间是 1e-4 到 2e-4，一开始用 5e-5 跑，loss 掉得跟蜗牛爬一样，换了 1e-4 之后曲线明显健康多了。我有个小习惯，第一次跑新数据时会把学习率调小一点看前几百步的趋势，趋势对了再放大，这样不容易一上来就把模型训崩。
2.2 自定义数据集训练配置：YAML、命令行与WebUI参数组织
配置的组织方式，我现在的偏好很明确：探索阶段用 WebUI，定稿之后全部转成 YAML。WebUI 的好处是参数都在眼前，勾选模型、数据集、模板，调几个滑杆就能点训练，特别适合快速试错。我经常在 WebUI 里连着跑三四个小实验，看看哪个 rank 或者学习率组合的 loss 曲线更顺眼。
YAML 则是另一个层面的东西，它承载的是可复现性。我通常会把 WebUI 里调好的参数手动搬进一个 .yaml 文件，模型路径、数据集名、template、cutoff_len、per_device_train_batch_size、gradient_accumulation_steps 逐项写清楚。写完之后用 llamafactory-cli train xxx.yaml 跑一遍，确认结果和 WebUI 一致，这个文件就可以进版本库了。团队里谁要复现，直接拉下来跑就行。
命令行参数我一般只在临时调试时用，参数一多敲起来太累，还容易漏。有一点我踩过坑：YAML 里字段名和命令行参数名不完全一样，写的时候对着官方示例抄最稳妥，别凭记忆拼。配置文件里路径建议写绝对路径，相对路径在不同工作目录下跑出来的结果可能完全不同，这种坑排查起来很浪费时间。
2.3 训练监控与问题排查：日志、显存占用、loss曲线与过拟合识别
训练一旦跑起来，我盯得最紧的是两样东西：显存占用和 loss 曲线。显存这块，启动后先看 nvidia-smi，确认占用在一个合理区间，留出百分之十几的余量比较安全。如果一启动就 OOM，我会按顺序往下调：先把 batch size 减半，不行就开 gradient_checkpointing，再不行上 QLoRA 的 4bit 量化。这套组合拳基本能救回大多数显存问题。
日志我会重点看几个信号：loss 是不是在稳定下降、grad_norm 有没有突然飙升、学习率调度是否符合预期。loss 突然变成 nan，多半是学习率太高或者数据里有异常样本，我会先降学习率再抽查数据。loss 降得很慢，就要回头检查 template 是否匹配，这个前面章节提过，实战里依然是最常见的坑之一。
过拟合的识别我主要看训练后期 loss 和验证集表现的分叉。训练 loss 一路往下、验证 loss 开始抬头，这就是典型信号。我一般的应对是把 epoch 数砍掉，或者加大 dropout、减小 rank。数据量小于一千条的时候，我会更保守一些，宁可欠拟合也不要过拟合，因为欠拟合还能靠继续训练补，过拟合了就得从头调。
2.4 模型评估、Adapter合并与推理部署：指标验证、导出与上线检查
训练结束不等于任务完成，评估这一步我从来不敢跳过。Llama-Factory 自带评估入口，可以接一些通用指标，不过我更常用的是自己准备一个小测试集，几十条到上百条样本，人工看输出质量。自动指标能反映趋势，真正决定能不能上线的还是实际回复靠不靠谱。我会让模型跑一批典型问题，逐条看它有没有答偏、有没有胡编。
Adapter 合并有两种思路，一种是训练完直接导出 LoRA adapter，推理时加载基座加 adapter；另一种是 merge 成一个完整权重。前者灵活，一个基座可以挂多个 adapter；后者部署简单，推理速度也稳。llamafactory-cli export 这个命令我用了很多次，配置里指定基座路径和 adapter 路径，选好输出目录就能合并。合并后我会拿测试集再跑一遍，确认输出和合并前一致，这一步是上线前的必要检查。
推理部署阶段我会关注三件事：加载速度、首 token 延迟、显存峰值。合并后的模型用 vLLM 或者原生 transformers 起服务都行，我一般先用原生方式验证正确性，再切到 vLLM 压性能。上线前还会做一轮回归测试，把之前评估用的样本再跑一遍，确认没有退化。这套流程走下来心里才有底。
2.5 进阶扩展与最佳实践：多数据集混合、继续训练与微调方法对比
多数据集混合是我最近用得比较多的技巧。手上有一批通用指令数据和一批垂直领域数据，我会在 dataset_info 里把两个都注册上，训练配置里用 dataset: a,b 这种方式并列，再通过 interleave 或者采样比例控制混合节奏。好处是模型既保留通用能力，又能学到领域知识，不至于微调完变成一个只会答专业题的偏科生。
继续训练的场景也挺常见。第一轮训完发现效果不够，我会在已有 adapter 的基础上接着训，配置里把 adapter_name_or_path 指过去，学习率调低一个量级，epoch 数也减少。这样比重头训省时间，也更不容易破坏已经学到的内容。我一般会保留每一轮的 adapter，方便回滚对比。
微调方法的对比，我的粗浅体会是这样的：全量微调效果上限高，对显存和数据量要求也高；LoRA 性价比最好，适合大多数个人和中小团队场景；QLoRA 在 LoRA 基础上再做量化，显存门槛进一步降低，代价是训练速度慢一些。选哪种方法，我的判断标准很朴素——先看手上有什么卡，再看数据有多少，最后看效果要求。这三者一摆，答案基本就出来了。方法没有绝对好坏，跑通、跑稳、能复现，对我来说就是好方法。
