用 LLama-Factory 微调个性化 AI 角色

这里有几处配置比较值得保留：lora_target: q_proj,v_proj 一般够用，改动集中在注意力层，不容易把底座能力弄坏；double_quantization 能再省一点显存；device_map: auto 对多卡和不同机器环境都省心，不用手工拆层。

启动训练也不复杂：

python src/train_bash.py --config train_lora.yaml

如果不想碰命令行，LLama-Factory 的 WebUI 也能把这些步骤做完。上传数据、选模型、填参数、点开始，够直接。

训练时别完全放手

很多微调翻车，不是因为框架不行，而是训练过程没人盯。LLama-Factory 内置了训练监控，可以实时看 loss、学习率、GPU 利用率和日志输出。这个功能不花哨，但很值钱。因为一旦 loss 不动，或者显存被吃爆，通常不是等到训练完才发现，而是跑到一半就已经不对了。

如果 loss 卡住，优先看学习率和数据质量；显存紧张，就降 batch size，或者开梯度检查点。训练后也能做一些自动评估，像 BLEU、ROUGE 或自定义指标都能接上。它们不能完整衡量'角色感'，但足够帮你筛掉明显失败的版本。

合并权重和部署

训练完成后，LoRA 权重有两种用法。

一种是推理时动态加载 base model 和 LoRA，省空间，也方便保留多个版本。另一种是把 LoRA 合并回基础模型，生成一个完整权重包，后面部署更干净。对于长期运行的服务，后者通常更省心。

合并之后，可以配合 vLLM 或 Text Generation Inference（TGI）部署，前端通过 API 调用模型即可。大致链路可以理解成这样：

用户输入 -> 前端界面（网页/App） -> API 网关 -> 推理引擎（vLLM/TGI） -> 微调后模型

旁边再加一层状态或记忆管理模块，用来维护上下文一致性，比如用户前面说过什么、当前角色处于什么情绪。真正承载人格的，还是微调出来的模型本身。

这套流程解决了什么

LLama-Factory 真正帮忙的地方，基本都很现实。

模型切换不用重写适配代码，改 model_name_or_path 就能换底座；QLoRA 把单卡微调门槛压下来了，消费级显卡也能跑；WebUI 让训练入口没那么硬核，非训练工程师也能参与；监控和评估把黑箱感降了不少，至少不会到最后才发现结果完全跑偏。

实操上我会注意几件事

• 数据质量比数量重要。角色类任务尤其明显，少量高质量样本通常比一大堆泛化数据更有效。
• LoRA rank 不要一上来就拉太高。简单角色可以从 32 开始，表达更复杂的，再试 64 或 128。
• epoch 不宜太多。2 到 5 轮通常够了，训练太久容易过拟合，模型会开始背答案，不再像那个角色。
• 合并前记得备份 base model。这个步骤一旦做完，回头对比和重新实验都会更麻烦。
• 数据和输出都要过一遍安全检查，尤其是带情绪、陪伴或对话类角色，敏感内容最好提前过滤。
• 每次训练都保留配置、数据版本和日志，不然后面很难判断到底是数据变了，还是参数变了。

结尾

如果目标是把一个基础大模型做成能稳定输出特定性格的角色，LLama-Factory 算是一个比较顺手的入口。它不负责替你设计角色，但把训练这件最麻烦的事压平了不少。

后面不管是做游戏 NPC、情感陪伴，还是教育辅导，这套思路都能继续复用。DoRA、AdaLoRA、IA³ 这些新方法也在往更轻量的方向走，工具链只会越来越成熟。真正难的，反而不是'能不能训练'，而是你到底想让这个角色成为什么样。