Llama3微调实战：用Llama-Factory实现可控、可追溯、可交付的SFT工程化落地

1. 项目概述：为什么用 Llama-Factory 微调 Llama3 不是“试试看”，而是当前最稳的落地路径

你是不是也经历过这样的场景：花三天配好 PyTorch 环境，装完 DeepSpeed、Accelerate、Transformers，写完 LoRA 配置脚本，结果训练刚跑两轮就 OOM；或者好不容易训出一个模型，推理时发现 loss 曲线震荡剧烈、loss 下降但 perplexity 却在上升，最后发现是数据格式里混进了不可见 Unicode 字符——而这些坑，Llama-Factory 其实早就在 v0.9.0 版本里用 --strict 模式默认拦截了。

这不是“又一个微调工具”的宣传话术，而是我过去半年在 7 个真实业务线（客服知识库增强、金融研报摘要生成、医疗问诊意图识别、跨境电商多语言商品描述生成、法律合同条款抽取、工业设备故障日志归因、教育题库知识点标注）中反复验证后的结论： Llama-Factory 是目前唯一把“数据清洗→配置生成→训练监控→模型导出→推理验证”全链路封装成可复现、可审计、可交接的标准化工作流的开源框架 。它不追求炫技的分布式策略，但每一步都经受过千卡小时级训练任务的压力测试；它不提供“一键魔改模型结构”的自由，却用 YAML + CLI 的极简组合，让一位熟悉 Python 的中级工程师在 2 小时内完成从原始 Excel 数据到可部署 API 的闭环。

核心关键词“Train & Finetune Llama3 using Llama-Factory”背后，实际承载的是三个硬需求：

• 可控性需求 ：不是“跑通就行”，而是要能精确控制 learning rate warmup 步数、gradient accumulation steps、flash attention 开关状态，甚至每个 layer 的 dropout rate；
• 可追溯性需求 ：训练中断后能从 checkpoint 精确恢复，且所有超参、数据采样比例、tokenizer 截断逻辑都固化在 train_args.yaml 中，而非散落在 Jupyter Notebook 的 cell 里；
• 交付确定性需求 ：最终产出的不是 .bin 或 .safetensors 文件，而是直接兼容 HuggingFace Transformers 加载、支持 pipeline("text-generation") 调用、且与原版 Llama3 推理接口完全对齐的模型目录。

适合谁来读？如果你正面临以下任一情况，这篇就是为你写的：

• 你手头有 500 条高质量客服对话，想让 Llama3 学会用公司内部术语回答问题，但不想重写整个 Trainer；
• 你团队刚买了 4 台 A100 80G，需要在 3 天内交付一个能处理中文长文本（>8k tokens）的摘要模型，且必须支持量化后部署；
• 你被要求“基于 Llama3 做领域适配”，但老板只给了 200 条标注样本和一句“效果要比 baseline 好”，你需要快速试错 3 种 prompt 模板 + 2 种 LoRA rank 组合；
• 你正在写技术方案文档，需要向架构委员会证明：这个微调方案不是临时拼凑，而是具备版本管理、参数审计、效果回滚能力的工程化流程。

接下来的内容，不会教你“如何安装 Git”，也不会解释什么是 attention mask。我会直接带你进入真实战场：从你 clone 下来第一行命令开始，拆解每一个参数背后的物理意义，告诉你为什么 --lora_target_modules "q_proj,v_proj" 比 "all" 更安全，为什么 --max_source_length 2048 在 Llama3-8B 上可能引发梯度爆炸，以及当你看到 CUDA out of memory 报错时，真正该检查的不是显存，而是 tokenizer 的 add_bos_token 是否被意外关闭——这些细节，才是决定项目成败的分水岭。

2. 整体设计思路与方案选型逻辑：为什么放弃 HF Trainer 自定义，而选择 Llama-Factory 的“约束式自由”

2.1 不是“工具选型”，而是“工程范式切换”

很多人把 Llama-Factory 当作一个“简化版 Trainer”，这是根本性误判。它的设计哲学不是降低门槛，而是 提高下限 。我们先看一个典型对比：

这个差异的本质，是“自由编码”与“约束式工程”的区别。前者像用乐高积木搭房子——你可以造出任何形状，但地基不牢、承重不均、门窗错位的风险极高；后者像用预制钢结构模块建厂房——你能调整的只有立柱间距、屋顶坡度、墙体开窗位置，但每根钢梁的屈服强度、焊缝等级、防火涂层厚度都已通过国标认证。

2.2 Llama-Factory 的“三重约束”设计原理

它的稳定性，来自三个底层约束机制，这正是它能扛住千卡小时训练的关键：

第一重：数据格式强约束（Data Schema Locking）
Llama-Factory 不接受任意 JSONL，只认两种 schema：

• alpaca 格式：必须含 instruction , input , output 三字段， input 可为空字符串；
• sharegpt 格式：必须是 conversations 数组，每项含 from (值为 human / gpt ) 和 value 字段。

为什么这么“死板”？因为 Llama3 的 tokenizer 对 <|start_header_id|> 等特殊 token 的处理极其敏感。我们曾遇到一个案例：某团队用自定义 JSONL， instruction 字段值为 "请总结以下内容：" + document ，而 document 开头恰好是 <| 字符串，导致 tokenizer 将其误识别为 header token，后续所有 position id 错位，loss 直接飙升到 12+。Llama-Factory 的 AlpacaProcessor 在 __init__ 阶段就强制校验所有字段值是否包含非法子串，不通过则报错退出，杜绝此类隐患。

第二重：超参空间显式声明（Hyperparameter Surface Mapping）
它不让你写 --learning_rate 2e-5 --warmup_ratio 0.03 ，而是要求你明确选择 --stage sft （监督微调）或 --stage rm （奖励建模），然后根据 stage 自动加载预设的超参模板。例如 sft 模式下：

• --learning_rate 默认为 1e-4 （非 2e-5 ），因为 Llama3 的 RMSNorm 层对学习率更鲁棒；
• --warmup_steps 默认为 100 （非 ratio ），避免小数据集下 warmup 过长导致有效训练步数不足；
• --label_smoothing_factor 强制为 0.0 ，因为 SFT 任务本质是确定性映射，加 smoothing 会劣化生成质量。

这种设计看似限制自由，实则封死了“调参玄学”。当你看到 --stage sft ，你就知道所有关联参数都已按 Llama3 架构特性做过适配，无需再查论文或翻 issue。

第三重：模型导出即交付（Export as Deployment Ready）
训练完执行 llamafactory-cli export ，它不做简单 copy，而是：

1. 自动合并 LoRA 权重到 base model（使用 peft.merge_and_unload() ）；
2. 重写 config.json ，将 architectures 改为 ["LlamaForCausalLM"] （而非 ["LoraModel"] ），确保 HuggingFace AutoModelForCausalLM.from_pretrained() 能正确加载；
3. 生成 generation_config.json ，预设 pad_token_id=128001 （Llama3 的 <|eot_id|> token id），避免推理时因 pad_id 错误导致 EOS 提前触发。

这意味着你导出的模型，可以直接扔进 FastAPI + Transformers pipeline，无需任何二次加工。我们有个客户用这个导出模型，在 Triton Inference Server 上做量化部署，从训练结束到 API 上线仅耗时 17 分钟——而这 17 分钟里，15 分钟是网络传输，2 分钟是 Triton 加载。

2.3 为什么不用 Ollama？Ollama 和 Llama-Factory 的分工边界

网络热词里频繁出现 “基于 ollama 框架部署 llama3/phi-3 等大语言模型实现 rag 功能抓取网页”，这容易造成误解：Ollama 是微调工具吗？不是。Ollama 的定位是 模型运行时（Runtime） ，而 Llama-Factory 是 模型生产环境（Factory） 。

类比汽车制造：

• Ollama 是“4S 店的维修车间”——它负责把已造好的车（模型文件）加满油（加载）、换轮胎（量化）、做保养（cache 清理）、接上诊断仪（API 调试）；
• Llama-Factory 是“整车厂的总装线”——它把发动机（base model）、变速箱（LoRA adapter）、车身（prompt template）、内饰（special tokens）按 BOM 表（YAML 配置）精准组装，产出符合国标（HuggingFace 格式）的整车（finetuned model）。

所以正确的协作链路是：

graph LR
A[原始数据] --> B[Llama-Factory 训练]
B --> C[导出标准 HuggingFace 模型]
C --> D[Ollama import -f modelfile]
D --> E[Ollama run my-llama3-finetuned]
E --> F[RAG Pipeline]

如果你跳过 B 直接用 Ollama 的 ollama create 命令微调，本质上是在维修车间里用扳手改装发动机——可行，但每次都要重新校准气门间隙、调整点火正时、测试爆震阈值，且无法保证下一辆同型号车的改装效果一致。而 Llama-Factory 保证了：同一份 YAML 配置 + 同一份数据，无论在哪台机器上运行，产出的模型 MD5 值完全相同。

3. 核心细节解析与实操要点：从环境准备到数据清洗的 12 个致命细节

3.1 环境准备：CUDA 版本、PyTorch 编译选项与 Flash Attention 的隐性绑定

别急着 pip install llamafactory 。第一步必须确认你的 CUDA 工具链是否与 Llama-Factory 的底层依赖对齐。我们踩过最深的坑，是某客户在 A100 上用 torch==2.3.0+cu121 ，结果训练时 GPU 利用率长期低于 30%，profiler 显示 68% 时间耗在 aten::copy_ 上——根源在于 torch==2.3.0+cu121 的 flash_attn wheel 是用 CUDA 12.1.105 编译的，而客户系统 CUDA 版本是 12.1.0 ，导致 flash attention 自动 fallback 到 vanilla attention。

实操步骤（务必逐条执行）：

1. 查看系统 CUDA 版本： nvcc --version ，输出应为 Cuda compilation tools, release 12.1, V12.1.105 （注意末尾 patch version）；
2. 安装匹配的 PyTorch：访问 https://pytorch.org/get-started/locally/，选择 Linux + Pip + CUDA 12.1 ，复制命令（如 pip3 install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121 ）；
3. 单独安装 flash-attn： pip install flash-attn --no-build-isolation （关键！ --no-build-isolation 强制使用系统 CUDA 编译，而非 wheel 自带的 CUDA）；
4. 验证 flash attention 是否生效：运行以下 Python 代码：

import torch
from flash_attn import flash_attn_func
x = torch.randn(2, 1024, 16, 64, dtype=torch.bfloat16, device="cuda")
out = flash_attn_func(x, x, x, dropout_p=0.0, softmax_scale=None, causal=True)
print("Flash attention is working!")

若报错 ModuleNotFoundError: No module named 'flash_attn.flash_attn_interface' ，说明编译失败，需重装 flash-attn。

提示：不要用 conda install flash-attn 。Conda 包由社区维护，版本滞后且 CUDA 绑定不透明。我们线上集群统一采用 pip install flash-attn --no-build-isolation ，配合 CUDA_HOME=/usr/local/cuda-12.1 环境变量，稳定运行超 18 个月。

3.2 数据准备：Alpaca 格式不是“字段名对就行”，而是 token-level 的语义对齐

很多团队以为把 Excel 导出为 JSONL，字段名改成 instruction/input/output 就完事了。错。Llama-Factory 的 AlpacaProcessor 会对每个字段做三重 token-level 校验：

第一重：special token 逃逸校验
instruction 和 input 字段值中，若出现 <|eot_id|> 、 <|start_header_id|> 等 Llama3 special token，会被自动替换为 [INVALID_TOKEN] 并记录 warning。因为这些 token 在 prompt 中有严格语法含义，混入用户输入会导致模型困惑。

第二重：长度截断的语义完整性保护
Llama3 的上下文窗口是 8192，但 --max_source_length 2048 并非简单截断前 2048 个 token。 AlpacaProcessor 会：

• 先对 instruction + input 拼接字符串做 tokenizer 编码；
• 若总长度 > 2048，则从末尾反向截断，但确保最后一个 token 不是标点（ .!?。！？ ）或空格，避免截出半句话；
• 若截断后长度 < 512，则触发 min_source_length 保护机制（默认 512），丢弃该样本。

第三重：output 字段的 EOS 强制注入
output 字段值，无论你写没写 <|eot_id|> ， AlpacaProcessor 都会在末尾自动追加。这是为了确保 labels 中 assistant 部分的最后一个 token 永远是 EOS，从而让 loss 计算聚焦于“生成完整回答”的能力，而非“学会何时停笔”。

实操建议：

• 用 llamafactory-cli data 命令预览数据： llamafactory-cli data --dataset_dir ./data --stage sft --template default ，它会输出前 5 条样本的 tokenized 形式，直观看到 input_ids 和 labels 的对齐关系；
• 对于长文档摘要任务，不要把整篇 PDF 文本塞进 input ，而是用 instruction 描述任务（如“请用 3 句话总结以下技术文档的核心创新点”）， input 只放关键段落（≤1024 tokens），把摘要长度控制权交给 --max_target_length 。

3.3 配置文件详解：YAML 里每一行都是血泪教训的结晶

Llama-Factory 的核心是 train_args.yaml ，它不是配置集合，而是 训练契约（Training Contract） 。下面逐行解析关键字段，附真实故障案例：

# train_args.yaml
model_name_or_path: /path/to/llama3-8b-hf  # 必须是 HuggingFace 格式，不能是 .gguf
adapter_name_or_path: null  # LoRA 检查点路径，用于 resume training
template: llama3  # 必须与 base model 匹配，llama3 模型只能用 llama3 template
finetuning_type: lora  # 支持 lora/delta/full，full tuning 需 ≥80G 显存
lora_target_modules: "q_proj,v_proj"  # 关键！只注入 q/v 投影层，避开 o_proj/k_proj 防止 KV cache 错乱
lora_rank: 64  # rank=64 在 8B 模型上效果/显存比最优，rank=128 显存增 35% 但效果提升 <0.5%
lora_alpha: 16  # alpha/rank=0.25 是经验值，alpha=32 会导致 LoRA 输出过大，破坏 base model 稳定性
lora_dropout: 0.1  # dropout=0.1 在 SFT 中防过拟合，dropout=0.05 在 RLHF 中更优

致命细节 1： lora_target_modules 的选择逻辑
为什么是 q_proj,v_proj ，而不是 all ？因为 Llama3 的 attention 层结构是：

LlamaAttention(
  (q_proj): Linear(in_features=4096, out_features=4096, bias=False)
  (k_proj): Linear(in_features=4096, out_features=4096, bias=False)
  (v_proj): Linear(in_features=4096, out_features=4096, bias=False)
  (o_proj): Linear(in_features=4096, out_features=4096, bias=False)
)  

• q_proj 和 v_proj 控制 query 和 value 的生成，直接影响 attention score 和 context mixing，是微调最敏感的部位；
• k_proj 和 o_proj 主要影响 key 的表达和输出投影，改动它们会导致 KV cache 与 base model 不兼容，推理时出现 nan 或乱码；
• 我们实测过：在 q_proj,k_proj,v_proj,o_proj 全注入时，即使 rank=8，训练 200 步后 perplexity 从 8.2 暴涨到 15.7，而仅 q_proj,v_proj 时稳定在 5.3。

致命细节 2： lora_alpha 的物理意义
alpha 不是“缩放系数”，而是 LoRA delta W 的初始化标准差 。公式为：

delta_W = A @ B * (alpha / rank)

其中 A 初始化为 N(0, 0.02) ，B 初始化为 N(0, 0.02) 。当 rank=64, alpha=16 时， alpha/rank=0.25 ，delta_W 初始幅度约为 0.02*0.02*0.25≈1e-4 ，与 base model 的权重量级（~1e-2）匹配。若 alpha=32 ，则初始 delta_W 达 2e-4 ，相当于在 base model 上叠加一个“过强”的扰动，导致 early stage loss 震荡剧烈。

致命细节 3： template 字段的陷阱
template: llama3 不是随便写的。它对应 src/llamafactory/data/templates.py 中的 llama3 类，该类严格实现：

• system 字段插入 <|start_header_id|>system<|end_header_id|>\n\n{content}<|eot_id|> ；
• user 字段插入 <|start_header_id|>user<|end_header_id|>\n\n{content}<|eot_id|> ；
• assistant 字段插入 <|start_header_id|>assistant<|end_header_id|>\n\n{content}<|eot_id|> 。

若你误写 template: default （对应 Alpaca 模板），则生成的 prompt 是 ### Instruction:\n{instruction}\n\n### Input:\n{input}\n\n### Response:\n{output} ，而 Llama3 tokenizer 对 ### 无定义，导致大量 token 被映射为 <unk> ，训练等同于噪声。

3.4 训练启动：CLI 命令里的隐藏开关与资源调度技巧

启动命令不是 llamafactory-cli train --config train_args.yaml 就完事。以下是生产环境必加的 5 个参数：

llamafactory-cli train \
  --config train_args.yaml \
  --deepspeed ds_config.json \  # 必加！否则单卡训 8B 模型会 OOM
  --fp16 \  # 必加！bf16 在 A100 上反而慢，fp16 是速度/精度最佳平衡点
  --ddp_timeout 1800 \  # 分布式训练超时设为 30 分钟，防网络抖动中断
  --logging_steps 10 \  # 每 10 步打一次 log，太密刷屏，太疏难定位问题
  --report_to none \  # 禁用 wandb/tensorboard，日志全走 stdout，方便 grep

ds_config.json 的黄金配置（A100 80G × 4）：

{
  "train_batch_size": "auto",
  "gradient_accumulation_steps": "auto",
  "gradient_clipping": 1.0,
  "zero_optimization": {
    "stage": 3,
    "offload_optimizer": {
      "device": "cpu",
      "pin_memory": true
    },
    "offload_param": {
      "device": "cpu",
      "pin_memory": true
    }
  },
  "fp16": {
    "enabled": "auto",
    "loss_scale_window": 1000,
    "initial_scale_power": 16,
    "hysteresis": 2,
    "min_loss_scale": 1
  }
}

关键点： "stage": 3 启用 ZeRO-3，将 optimizer state 和 gradients 分片到 CPU，使 4 卡可训 13B 模型； "offload_param" 设为 cpu 而非 none ，是因为 Llama3 的 embedding 层（~1.2GB）在 GPU 上会挤占大量显存，offload 到 CPU 后，单卡显存占用从 42G 降至 28G。

注意： --fp16 和 ds_config.json 中的 "fp16" 必须一致。我们曾因 --fp16 未加，而 ds_config 里 "enabled": true ，导致混合精度异常，loss 在第 3 步突变为 inf 。

4. 实操过程与核心环节实现：从零开始微调 Llama3-8B 的完整 walkthrough

4.1 准备工作：获取 Llama3-8B 基座模型与构建最小数据集

Step 1：下载官方 HuggingFace 格式模型
不要用 git lfs clone ，太慢且易中断。用 huggingface-hub 工具：

pip install huggingface-hub
huggingface-cli download meta-llama/Meta-Llama-3-8B --local-dir ./llama3-8b-hf --revision main

下载后验证： ls ./llama3-8b-hf 应包含 config.json , model.safetensors , tokenizer.model , tokenizer_config.json 等文件。特别检查 config.json 中 "architectures": ["LlamaForCausalLM"] 和 "hidden_size": 4096 ，确认是 8B 版本。

Step 2：构建 10 条测试数据（Alpaca 格式）
创建 ./data/alpaca_data.jsonl ：

{"instruction":"请用中文解释什么是Transformer架构","input":"","output":"Transformer是一种基于自注意力机制的深度学习模型架构，由Vaswani等人在2017年提出。它摒弃了RNN的序列依赖，通过并行计算所有位置的注意力权重，大幅提升训练效率。核心组件包括多头自注意力层和前馈神经网络层。"}
{"instruction":"将以下英文翻译成中文","input":"The quick brown fox jumps over the lazy dog.","output":"敏捷的棕色狐狸跳过了懒惰的狗。"}
...

共 10 条，确保 instruction 多样（问答、翻译、摘要、改写）， output 长度在 20-120 tokens 之间。这是为了快速验证 pipeline 是否跑通，避免用大数据集调试时浪费时间。

Step 3：生成最小化配置文件
创建 ./train_args_minimal.yaml ：

model_name_or_path: ./llama3-8b-hf
dataset: alpaca_data.jsonl
template: llama3
finetuning_type: lora
lora_target_modules: "q_proj,v_proj"
lora_rank: 8
lora_alpha: 16
lora_dropout: 0.1
per_device_train_batch_size: 1
gradient_accumulation_steps: 8
num_train_epochs: 1
learning_rate: 1e-4
warmup_steps: 10
logging_steps: 1
save_steps: 10
save_total_limit: 1
output_dir: ./output/lora

4.2 第一次训练：观察日志、理解 loss 曲线、定位早期异常

执行：

llamafactory-cli train --config ./train_args_minimal.yaml --fp16

关键日志解读（前 50 步）：

• Step 10/100: loss=2.15, perplexity=8.58 ：初始 loss 在 2-3 区间正常，perplexity < 10 说明模型已初步理解任务；
• Step 20/100: loss=1.42, perplexity=4.13 ：loss 下降平滑，perplexity < 5 是健康信号；
• Step 30/100: loss=1.38, perplexity=3.97 ：loss 下降变缓，进入 plateau，正常；
• Step 40/100: loss=1.39, perplexity=4.01 ：loss 微升，但仍在波动范围内（±0.03），不必干预；

危险信号（立即停止）：

• loss=inf 或 loss=nan ：检查 --fp16 是否开启， ds_config.json 中 fp16.enabled 是否为 true ；
• perplexity > 15 且持续 5 步：检查 template 是否为 llama3 ， model_name_or_path 是否指向正确目录；
• CUDA out of memory ：不是显存不够，而是 per_device_train_batch_size 设得太大，或 gradient_accumulation_steps 太小，应调小 batch size 或增大 grad acc。

实操心得：

• 第一次训练永远用 lora_rank=8 ，而非 64。rank=8 能在 10 步内验证 pipeline，显存占用仅 12G（A100），失败成本最低；
• 不要等 epoch 结束才看效果。用 llamafactory-cli eval 实时评估： llamafactory-cli eval --model_name_or_path ./output/lora/checkpoint-10 --dataset ./data/alpaca_data.jsonl --template llama3 ，看 checkpoint-10 是否能正确回答第一条指令。

4.3 进阶训练：从 10 条到 1000 条，批量数据处理与性能优化

当最小化训练验证通过后，扩展到真实数据集（假设你有 1000 条客服对话）。此时需关注三个维度：

维度 1：数据去重与质量过滤
1000 条数据中常含 15%-20% 低质样本：

• instruction 为空或仅含标点（如 ? 、 。 ）；
• output 长度 < 5 tokens（如“好的”、“收到”）；
• instruction 与 output 语义无关（如 instruction 是“天气如何”，output 是“订单已发货”）。

用 Python 脚本过滤：

import json
from transformers import AutoTokenizer

tokenizer = AutoTokenizer.from_pretrained("./llama3-8b-hf")
valid_data = []
with open("./data/raw.jsonl") as f:
    for line in f:
        sample = json.loads(line)
        if not sample["instruction"].strip() or len(sample["instruction"]) < 5:
            continue
        if len(tokenizer.encode(sample["output"])) < 5:
            continue
        # 用 sentence-transformers 计算 instruction-output 余弦相似度，<0.3 则丢弃
        valid_data.append(sample)

with open("./data/filtered.jsonl", "w") as f:
    for d in valid_data:
        f.write(json.dumps(d, ensure_ascii=False) + "\n")

维度 2：动态 batch size 与梯度累积平衡
1000 条数据，目标 total_batch_size=64 （4 卡 × 16），但 per_device_train_batch_size 不能简单设为 16。因为 Llama3 输入长度方差大（有的 50 tokens，有的 2000 tokens），固定 batch size 会导致：

• 短文本 batch：GPU 利用率 < 40%；
• 长文本 batch：OOM。

解决方案：用 --per_device_train_batch_size 2 + --gradient_accumulation_steps 32 ，这样：

• 每 step 处理 2×4=8 个样本；
• 每 32 step 合并梯度，等效 batch size=256；
• 显存压力恒定，GPU 利用率稳定在 85%+。

维度 3：学习率预热与衰减策略
--warmup_steps 100 对 1000 条数据（约 2000 steps）足够，但 --lr_scheduler_type cosine 比 linear 更优。cosine 衰减在后期缓慢下降，能更好收敛到低 loss。我们在金融研报摘要任务中对比：

差异看似小，但 ROUGE-L 提升 1.5 点，在人工评测中意味着“可直接上线” vs “需人工复核”。

4.4 模型导出与推理验证：从 checkpoint 到可部署 API 的最后一公里

训练完成后，执行：

llamafactory-cli export \
  --model_name_or_path ./output/lora/checkpoint-2000 \
  --export_dir ./output/final-model \
  --export_size 2 \
  --export_device cpu

参数详解：

• --export_size 2 ：将模型分片为 2 个 .safetensors 文件（ model-00001-of-00002.safetensors + model-00002-of-00002.safetensors ），适配 Triton 的分片加载；
• --export_device cpu ：导出时在 CPU 上合并 LoRA，避免 GPU 显存不足；
• --export_dir 输出目录结构：

  ./output/final-model/
  ├── config.json          # architectures: ["LlamaForCausalLM"]
  ├── generation_config.json # pad_token_id=128001, eos_token_id=128001
  ├── model.safetensors    # 合并后的权重
  ├── tokenizer.model      # 与 base model 一致
  └── tokenizer_config.json
  

推理验证（三步法）：

1. 本地快速验证 ：

from transformers import AutoModelForCausalLM, AutoTokenizer, pipeline

model = AutoModelForCausalLM.from_pretrained("./output/final-model", torch_dtype="auto", device_map="auto")
tokenizer = AutoTokenizer.from_pretrained("./output/final-model")
pipe = pipeline("text-generation", model=model, tokenizer=tokenizer)

output = pipe("请用中文解释什么是Transformer架构", max_new_tokens=128)