企业官网建设流程全解析

1. 为什么在 InternLM 上选 XTuner 做低成本微调

先说我遇到的最典型的场景：手上有一批垂直行业的问答数据，几百到几千条不等，想让 InternLM 这类开源大模型说话更像这个领域的专家，但手里的卡只有一张 24GB 甚至 16GB 显存的消费级显卡，租云卡也不想一天烧掉几百块。这个前提下，"低成本微调"不是一句营销话术，它对应三个非常具体的约束：显存要压得住、训练时间要可控、产出的权重能直接部署。XTuner 大模型微调实战之所以值得单独拿出来讲，就是因为这套工具链恰好把这三件事串起来了——配置文件驱动、原生支持 LoRA/QLoRA、一条命令完成训练到合并。

我先把结论摆在这里：在单卡或双卡的小规模场景下，用 XTuner 对 InternLM2 系列做 QLoRA 微调，是目前门槛最低、出错率最低的一条路。它的价值不在于"功能最多"，而在于"默认配置就是能跑通的"。全参微调听起来更"正统"，但 7B 模型全参至少要 4 张 A100 级别的卡才谈得上舒服，光是权重、梯度、优化器状态三份拷贝就吃掉 80GB 以上显存，这对绝大多数个人开发者和中小团队来说是直接劝退的门槛。QLoRA 把基座权重压到 4bit，只训练插进去的低秩矩阵，显存需求能压到原来的十分之一左右，效果损失在垂直领域问答这种任务上，实测差异远小于数据质量带来的差异。

这篇文章适合三类人看：一是手里有数据但没跑过大模型微调的新手，照着做能出第一个可用模型；二是跑过全参微调、被显存和成本折磨过的工程师，想换成性价比更高的方案；三是做应用落地、需要评估"微调到底值不值"的产品侧同学，里面关于数据量和效果上限的部分可以直接参考。

1.1 从"能不能跑起来"倒推方案选型

选微调方案，我的习惯是先算显存，再看效果，最后才看工具好不好用。顺序不能反，因为显存不够的话，后面全是空谈。

大模型训练时显存主要被四块吃掉：模型权重、梯度、优化器状态、激活值。以 7B 模型、fp16 精度为例，权重 14GB，梯度 14GB，Adam 优化器要存一阶动量和二阶动量共两份 fp32，约 56GB，再加上前向传播中间产生的激活值（跟 batch size 和序列长度正相关，通常几 GB 到十几 GB），加起来 90GB 起步。这就是为什么全参微调的门槛那么高。

LoRA 的思路很聪明：冻结原来的权重不动，在旁边挂两个小矩阵 A 和 B，前向时把B @ A加到原权重上。因为原权重不需要梯度，梯度和优化器状态就只剩这两个小矩阵的量。7B 模型在 rank=16 的情况下，LoRA 参数大概在千万量级，占原模型的千分之几，这部分的开销几乎可以忽略。但权重本身还是 fp16 的 14GB，激活值也还在。

QLoRA 在 LoRA 基础上再进一步，把冻结的基座权重直接量化成 4bit 存储（计算时反量化回 bf16）。14GB 瞬间变成 4GB 左右，这才是把门槛从"一张专业卡"拉到"一张游戏卡"的关键一步。所以低成本微调的标准组合就是：4bit 基座 + LoRA 适配器 + 梯度检查点 + 小 batch 配梯度累积。

1.2 LoRA 与 QLoRA 到底省在哪：一笔显存账

我习惯在动手前先估一遍，估算是防止白跑一晚上的最好办法。下面这张表是我按 InternLM2 系列常见规格整理的粗略量级，实际会因序列长度、框架版本有浮动：

省下来的显存代价是什么？量化本身有精度损失，但 4bit NF4 量化对基座能力的影响在垂直任务上基本感知不到，因为微调的目标是"改说话方式、补领域知识"，不是"重建语言能力"。真正的代价是速度——每次前向都要做反量化，训练吞吐大概比 fp16 LoRA 低两成。这个交换我认为完全值得，因为省下来的是"能不能跑"的问题，而慢两成只是"多等两小时"的问题。

还有一个容易被忽略的点：gradient_checkpointing。它把前向的中间激活值丢掉，反向传播时重新算一遍，显存能再省 30% 到 50%，代价是训练速度慢 20% 到 30%。在显存吃紧的时候，这个开关是必须开的，XTuner 的默认配置里一般已经打开了。

1.3 XTuner 的配置文件驱动模式适合谁

XTuner 最舒服的设计是把所有东西塞进一个 Python 配置文件里：模型路径、数据路径、batch size、学习率、LoRA 的 rank 和 alpha、优化器、学习率调度、日志间隔、保存间隔，全在一个文件里。训练命令就一行，不用记一堆命令行参数。

这种模式的好处是可复现。你把 config 文件丢进 git，三个月后回来还能一模一样地重跑。坏处是初次接触时不知道从哪下手——配置文件动辄两三百行，看着头大。我的建议是别从零写，直接抄官方模板改三个地方：模型路径、数据路径、输出目录。剩下的先别动，跑通了再说。很多人第一次失败就是因为一上来就大改参数，改出问题又不知道是哪一处引起的。

另外 XTuner 内置了一堆开箱即用的模板，按模型规格和微调方式排列组合，internlm2_7b_qlora_xxx这种命名规则很好认。找到跟你模型规模匹配的那个，复制一份出来改，这是最省时间的路径。

2. 微调前的三件准备工作

动手之前有三件事必须确认清楚，顺序错了后面全是返工。这三件事分别是：硬件和环境是否匹配、数据格式是否符合要求、基座模型和 tokenizer 是否完整。听起来是废话，但我见过太多人卡在这三步中的某一步上折腾一整天。

2.1 硬件与环境的现实评估

先看卡。单卡 24GB（比如 3090、4090、A10）跑 7B 的 QLoRA 是很宽裕的，甚至可以把max_length拉到 4096。单卡 16GB 跑 7B QLoRA 要小心，序列长度别超过 2048，batch size 必须是 1。单卡 8GB 建议直接上 1.8B 模型，7B 就算勉强塞进去，稍微长一点的样本就会 OOM，训练过程会非常痛苦。

再看磁盘。基座模型 7B 的 fp16 权重约 14GB，加上 tokenizer、配置文件，下载下来接近 15GB。训练过程中每个 checkpoint 又是几 GB 到十几 GB（LoRA 的 checkpoint 只有适配器，几百 MB，这点很友好）。合并后的完整权重再占 15GB。预留 100GB 空间是稳妥的。

然后是环境。Python 3.10 是比较稳的选择，PyTorch 版本要和 CUDA 驱动匹配。我踩过的坑是：装完 XTuner 之后发现它依赖的 transformers 版本跟环境里已有的版本冲突，把别的项目搞崩了。所以强烈建议用 conda 建独立环境，不要往系统环境里装。

conda create -n xtuner_env python=3.10 -y conda activate xtuner_env

显卡驱动版本这块，用nvidia-smi看一眼右上角的 CUDA Version，装 PyTorch 时选不高于这个版本的 CUDA 版本就行。

2.2 数据准备：格式比数量更重要

低成本微调里，数据质量对最终效果的贡献远大于任何超参数调整。我一直跟人说：三千条干净数据的效果，好过三万条脏数据。脏数据包括格式错乱、答案自相矛盾、答案过长导致被截断、以及大量"我不知道"式的敷衍回答。

XTuner 支持的对话数据格式主要两种。一种是conversation格式，也就是一组多轮对话：

{"conversation": [{"system": "你是一个专业的设备故障诊断助手", "input": "机器运行时有异响，怎么排查？", "output": "先确认异响的位置..."}]}

另一种是单轮的 alpaca 式，字段是instruction、input、output。垂直问答任务用单轮就够了，多轮反而会拉长序列、增加显存压力。

格式上有几个硬性要求，违反了会直接报错或者静默出错：

• 一行一个 JSON 对象，不能有换行符跨行，这是 JSONL 的基本规则。
• 文件里不能有空行，空行会导致解析时抛异常。
• 每个样本的 output 字段必须非空，否则 loss 计算出 NaN。
• 中文不需要转义，但如果你用脚本生成数据，ensure_ascii=False记得加上，否则中文全变成\uXXXX，虽然能解析，但人工检查时可读性极差。

数据量怎么定？我的经验是：单一任务、风格迁移类，500 到 1000 条就能看到明显效果；知识注入类（要让模型记住具体的产品参数、流程规范），2000 到 5000 条比较稳；再往上收益递减明显，不如把精力花在清洗上。如果数据少于 200 条，微调很容易过拟合，模型会开始复读训练集，不如用提示词工程（prompt engineering）解决。

还有一个必须做的动作：统计 token 长度分布。用 tokenizer 把每条数据编码一遍，算出 95 分位数，max_length设成比这个值稍大一点。设太小会截断答案（最要命的是把 output 截没了，模型只学到前半句就结束），设太大会浪费显存。

from transformers import AutoTokenizer import json tok = AutoTokenizer.from_pretrained("你的模型路径", trust_remote_code=True) lens = [] with open("train.jsonl") as f: for line in f: d = json.loads(line) text = "".join([t["input"] + t["output"] for t in d["conversation"]]) lens.append(len(tok(text).input_ids)) lens.sort() print("median:", lens[len(lens)//2], "p95:", lens[int(len(lens)*0.95)], "max:", lens[-1])

2.3 基座模型与 tokenizer 的确认

模型下载下来之后，先确认目录结构完整。至少要包含config.json、tokenizer.model或tokenizer.json、pytorch_model.bin或者分片的*.safetensors。少一个 tokenizer 文件，训练到中途才会报错，非常浪费时间。

我习惯在配置文件里用绝对路径，而不是相对路径。相对路径在xtuner train启动后，工作目录可能被切换到work_dirs下，导致找不到模型。这个坑我踩过一次，报错信息还不够明确，查了半小时才发现是路径问题。

路径末尾的斜杠也别加，/path/to/model和/path/to/model/在某些拼接逻辑下会出问题。

另外确认一下模型的对话模板。InternLM2 系列有自己的特殊 token 体系，微调时 XTuner 会自动套用对应的模板，你不需要手动拼<|im_start|>这类标记。如果你用的是别的基座，一定要在 config 里确认prompt_template配置对上了，模板错了模型学到的就是一堆乱码。

3. 配置文件逐行拆解与关键参数计算

配置文件是整个微调过程的中枢，看懂它基本上就掌握了 XTuner。这一节我把关键字段拆开讲，重点解释每个数字背后的逻辑，而不是简单告诉你"填这个值"。

3.1 从官方模板继承一份 config

XTuner 的 config 体系基于 mmengine，支持继承。官方模板一般长这样，我以 InternLM2 的 QLoRA 配置为例说明结构（字段名以你本地安装的版本为准，版本间会有调整）：

from mmengine.config import read_base with read_base(): from .internlm2_7b_qlora_alpaca_e3 import * model_name_or_path = '/path/to/internlm2_7b' data_path = '/path/to/train.jsonl' max_length = 2048 batch_size = 1 accumulative_counts = 16 max_epochs = 3 lr = 2e-4 evaluation_inputs = ['介绍一下你的能力', '这个故障怎么处理？']

继承的好处是，基础配置里那些model、tokenizer、train_dataloader、optim_wrapper的复杂结构你都不用管，只覆盖顶层变量就行。XTuner 的模板里这些变量都用大写或者特定命名暴露出来了，覆盖它们就能改变深层配置。

需要改的只有三处：模型路径、数据路径、工作目录。第一次跑通之前，其他参数一个都别动。这份配置能进官方仓库，说明是被验证过的，先跑起来再说优化的事。

如果要改输出位置，在训练命令里加--work-dir参数即可，不用改 config：

xtuner train ./my_config.py --work-dir ./work_dirs/run_001 --deepspeed deepspeed_zero2

3.2 LoRA 参数怎么定

LoRA 有三个核心参数：r（rank）、lora_alpha、lora_dropout。它们在 config 的model字段下，或者在lora子配置里，具体位置看模板。

r是低秩矩阵的秩，决定了适配器的容量。r 越大，能表达的变化越复杂，参数和显存也越多。常见的取值：

我一般从 16 起步。任务简单（比如让模型统一用某个格式回答）用 8 就够；数据量上万、任务跟基座差异很大，再往上加到 32。再大就没必要了，不如考虑全参微调。

lora_alpha是缩放系数，实际生效的缩放是alpha / r。常见做法是让 alpha 等于 2 倍的 r，这样缩放比例是 2。有人喜欢让 alpha 等于 r，缩放比例为 1。这个参数的影响没有 r 大，我一般就用模板默认值，不动它。

lora_dropout是防止过拟合的，数据量小（低于 1000 条）时可以设 0.05 到 0.1；数据量大的时候设 0 更利于收敛。默认通常是 0，我建议保持。

还有一个隐藏的关键点：LoRA 作用在哪些层上。默认一般覆盖 attention 的 q、k、v、o 和 MLP 的 gate、up、down 全部线性层。有人为了省参数只挂在 q、v 上，这样效果会打折扣，不建议。全部挂上的参数量也就千万级，没必要省。

3.3 batch size、梯度累积与学习率的联动

显存有限的时候，batch_size只能设 1，但梯度下降需要一定的有效批量才有稳定的方向。解决办法是梯度累积：连续算 16 次前向反向，把梯度攒着，第 16 次才更新一次参数。

有效批量 =batch_size × accumulative_counts × 显卡数

单卡、batch_size=1、accum=16 的情况下，有效批量是 16。这是比较保守的设置。如果你数据量在几千条这个级别，有效批量 16 到 32 都合适。数据量特别小（几百条），累积次数可以降到 8，让每个 epoch 有更多更新步数，否则一个 epoch 才几十步，模型没学到什么就结束了。

这里有个容易算错的地方：总步数。比如 3000 条数据，batch_size=1、accum=16、单卡，那么一个 epoch 的步数是3000 / 16 ≈ 188步。三个 epoch 就是 564 步。如果save_steps设成 500，那整个训练只会存一次 checkpoint。建议save_steps设在总步数的三分之一到四分之一左右，方便观察中间效果，也方便回滚。

学习率方面，LoRA 的学习率比全参微调高一个数量级。全参常用 1e-5 到 2e-5，LoRA 常用 1e-4 到 3e-4。原因是 LoRA 参数是从零初始化（B 矩阵初始为 0），刚开始梯度很小，需要大一点的学习率推起来。QLoRA 因为量化误差，学习率可以稍微再大一点，2e-4 是个稳妥的起点。

如果训练过程中 loss 出现明显震荡（上下跳动幅度超过 0.3），说明学习率偏大，降到 1e-4。如果 loss 几乎不动，一直卡在 2.5 左右，说明学习率偏小或者数据有问题，先检查数据格式，再考虑调大到 4e-4。

还有一个参数必须提：max_epochs。垂直任务微调 1 到 3 个 epoch 就够了。超过 3 个 epoch，模型开始背训练集，表现为在训练集上回答得完美，在没见过的问法上直接崩。判断方法是训练集 loss 持续下降但验证集 loss 开始上升，这时候就该停了。

4. 完整实操流程：从装环境到跑出第一个模型

这一节是纯操作记录，按顺序走一遍。每一步我都标注了大概耗时和容易出错的位置，你照着做应该能在一个下午内出结果。

4.1 环境搭建与依赖安装

conda create -n xtuner_env python=3.10 -y conda activate xtuner_env # 按你的 CUDA 版本装对应的 torch，下面以常见版本示意 pip install torch torchvision --index-url https://download.pytorch.org/whl/cu118 # 安装 xtuner pip install -U xtuner

装完之后验证一下：

xtuner list-cfg | head -20

能列出配置模板名字就说明装好了。如果报command not found，检查是不是没激活环境，或者pip装的路径和PATH不匹配。

装flash-attn这个可选依赖时容易踩坑，它需要编译，跟 CUDA 版本和 torch 版本强绑定。我的建议是先不装，用默认的 attention 实现也能跑，只是慢一点、显存多一点。等基础流程跑通了，再考虑装它提速。

下载模型这一步，7B 的 fp16 权重十几 GB，网速慢的话要等很久。建议用支持断点续传的方式。下载完成后ls -lh看一眼文件大小，分片文件应该是几个 4GB 到 8GB 的 safetensors，缺片的话训练加载时会报 key 不匹配。

4.2 数据转换与数据集注册

假设你手上是 Excel 或者 CSV，需要转成 JSONL。转换脚本我一般这么写：

import json rows = [] # 假设这里是从 csv 读出来的 [问题, 答案] 列表 with open("train.jsonl", "w", encoding="utf-8") as f: for q, a in rows: q, a = q.strip(), a.strip() if not q or not a or len(a) < 10: continue # 丢掉空答案和过短答案 item = {"conversation": [{"system": "你是一个专业的行业问答助手", "input": q, "output": a}]} f.write(json.dumps(item, ensure_ascii=False) + "\n") print("总条数:", sum(1 for _ in open("train.jsonl")))

几个细节值得强调。第一，system字段建议统一，训练和推理时保持一致，否则模型对 system 的响应会不稳定。第二，过滤掉长度小于 10 的答案，这些通常是"是"、"好的"这类无信息量的回复，留着只会让模型学会敷衍。第三，转换完一定要人工抽检 20 条，肉眼看看有没有乱码、字段错位、答案对错了问题——这一步能省掉后面几小时的困惑。

如果数据需要划分验证集，建议 95/5 或者 90/10。XTuner 的 config 里可以同时配train_dataset和eval_dataset，也可以只配训练集，训练完手动拿几条新问题测。垂直任务数据本来就不多，我一般只留 20 条做人工验证，剩下的全用来训练。

数据集在 config 里通过dataset字段指定，不同版本字段名可能是train_dataset，具体看模板。如果用的是dataset_map_fn之类的映射函数，注意它默认按某种格式解析，格式对不上会静默产出空样本——这是最阴险的坑，表现为训练能跑，但 loss 一直是常数。

4.3 启动训练与过程监控

xtuner train ./my_config.py \ --work-dir ./work_dirs/run_001 \ --deepspeed deepspeed_zero2

单卡训练的话其实可以不加--deepspeed，但加上也没坏处，Zero-2 会把优化器状态分片，多卡时是必需的，单卡时开销可以忽略。启动后前几分钟会看到加载模型、构建数据集的日志。

正常跑起来之后，日志里会周期性打印：

Epoch 1/3, Iter 20/188, Loss: 1.8234, LR: 0.000200

看 loss 是判断训练是否正常最直接的手段。健康的曲线是前 50 步快速从 2.5 左右掉到 1.5，然后缓慢下降到 0.8 到 1.0 之间趋于平稳。如果前 100 步 loss 一直贴着 2.5 不动，基本可以确定是数据格式问题，停下来检查。

训练过程中可以另开一个终端nvidia-smi看显存。稳定在某个值附近波动是正常的，如果缓慢上涨然后 OOM，多半是显存碎片问题，试着把PYTORCH_CUDA_ALLOC_CONF=max_split_size_mb:128加到环境变量里。

checkpoint 会存在work_dirs/run_001/下，命名是iter_XXX.pth。LoRA 的 checkpoint 只有几百 MB，存起来很轻松，所以save_steps可以设小一点，多存几个方便对比。

4.4 权重转换、合并与推理验证

训练结束后，iter_XXX.pth是 XTuner 自己的格式，需要先转成 HuggingFace 格式，再合并到基座模型上。

# 第一步：pth 转 HF 适配器 xtuner convert pth_to_hf ./my_config.py ./work_dirs/run_001/iter_564.pth ./hf_adapter # 第二步：合并适配器与基座 xtuner convert merge /path/to/internlm2_7b ./hf_adapter ./merged_model --max-shard-size 4GB

第一步产出的hf_adapter里就是标准的adapter_model.bin和adapter_config.json，这个目录可以直接用 PEFT 加载，也可以走第二步合并。合并的好处是推理时不需要额外加载适配器，部署简单；坏处是占空间。如果空间紧张，不合并、用 PEFT 动态加载也行。

合并完直接对话测试：

xtuner chat ./merged_model --prompts "机器运行时有异响，怎么排查？" --temperature 0.1

temperature设低一点（0.1 到 0.3），输出的稳定性更好，方便判断模型是不是真的学到了东西。如果输出跟基座模型差不多，说明微调没生效，回去检查数据。如果输出开始复读训练集原句，说明过拟合了，减少 epoch 或者增加数据多样性。

验证一定要用训练集里没有的新问法。我见过有人拿训练集里的原题去问，模型答得一字不差，就以为成功了，实际上只是在背诵。构造 10 到 20 条同义但表述不同的问法，看模型的回答是否保持了同样的业务逻辑，这才是真实效果。

5. 常见问题与排查实录

这一节是我和自己踩过的坑、以及帮别人排查时反复遇到的问题汇总。按发生频率排序，越靠前越常见。

5.1 显存类问题：OOM 的排查顺序

OOM 是最高频的问题，没有之一。排查要有顺序，别一上来就乱改参数。

第一个检查点：max_length是不是设太大了。2048 和 4096 的显存差距接近一倍。先用 1024 跑通，再往上加。

第二个检查点：batch_size是不是大于 1。单卡 16GB 跑 7B，batch_size必须是 1，靠accumulative_counts补有效批量。

第三个检查点：gradient_checkpointing开了没有。这个开关能省 30% 以上显存，代价是慢一点，显存紧张时必须开。

第四个检查点：换更小的模型。7B 在 8GB 卡上硬撑是不明智的，1.8B 的 QLoRA 在 6GB 显存就能跑，先把流程跑通建立信心，再上大模型。

还有一个隐蔽的 OOM 原因：数据和模型不在同一张卡上。多卡环境下如果只指定了一张卡却加载了完整模型，或者CUDA_VISIBLE_DEVICES设错，会出现"明明卡是空的却报 OOM"。跑之前nvidia-smi确认进程占用的卡是不是你预期的那张。

5.2 训练效果类问题：loss 不降和过拟合

loss 卡在 2.5 附近不动，九成是数据没被正确读入。具体表现是每步的 loss 值几乎完全相同。原因通常有两种：dataset_map_fn跟你的数据格式不匹配，解析出空样本；或者data_path指向了错误的文件。排查方法是在 config 里临时加一句打印，或者在 Python 里单独跑一遍数据集的构建逻辑，看看第一条样本长什么样。

loss 降到很低但推理效果差，这是过拟合。判断标准是训练集 loss 低于 0.5 但新问法答得乱七八糟。处理方式是减 epoch、加数据、提高lora_dropout。1 到 3 个 epoch 是安全区，超过 5 个 epoch 基本都会过拟合。

还有一个特殊情况：loss 正常下降，但模型输出开始夹杂奇怪的符号或者中英混杂。这通常是对话模板不匹配导致的。模板里的特殊 token 跟基座模型训练时用的不一致，模型会把它们当成普通文本学习。解决办法是确认 config 里的prompt_template字段跟模型规格匹配，用错模板（比如拿 Chat 版模板配 Base 模型）就会出现这种症状。

5.3 数据与格式类问题速查

我把常见的报错和对应原因整理成一张表，出问题先来这里对照：

数据加载阻塞这个坑值得单独说。默认num_workers设得小，GPU 一直在等数据，利用率上不去。日志里会看到 GPU 利用率在 0 到 100 之间反复跳。把num_workers调到 4 或者 8（根据 CPU 核数），吞吐能提升明显。但也别设太大，超过 CPU 核数反而会拖慢。

5.4 几条不写在文档里的经验

第一条：先用 100 条数据跑通全流程，再用全量数据跑。这个习惯帮我省了无数次时间。100 条数据跑 10 步就能验证环境、配置、格式是不是全对，成本几分钟。直接上全量数据，跑到一半发现格式错了，白等两小时。

第二条：checkpoint 宁可多存。LoRA 的 checkpoint 才几百 MB，存 10 个也就几 GB。存少了，发现第 3 个 epoch 效果最好却回不去，只能重跑。

第三条：评估要固定一批测试题。每次微调都拿同样 20 条问题去问，横向对比不同配置的效果才有意义。凭感觉判断"好像好了一点"非常不可靠，人对生成文本的质量判断波动很大。

第四条：合并后的模型可以再用量化工具压缩。如果最终是要部署到显存受限的机器上，合并完再用 4bit 量化，7B 模型能压到 4GB 左右，推理速度也更快。但要注意，量化推理和 QLoRA 训练叠加可能有精度累积损失，部署前一定要在真实测试集上验一遍效果。

6. 关于成本与效果的几句实话

低成本微调这件事，工具层面已经把门槛降得很低了，真正决定成败的是数据和对任务的拆解。我见过花一周调参效果平平的，也见过半天微调效果惊艳的，差别全在数据质量上。有那时间研究 rank 从 16 改成 32 能提升多少，不如把训练集里那几十条答非所问的样本挑出来删掉。

另外提醒一句期望管理：微调不是万能的。它能改风格、补知识、对齐格式，但它不能让一个 7B 模型具备 70B 模型的推理能力。如果你的需求是复杂逻辑推理，先考虑提示词工程和检索增强，别指望微调能解决。微调最擅长的场景是"模型本来就会说话，只是说得不像我们这行的"——把这句话想明白，很多方案选择就清楚了。

按我自己的经验，从零到跑出第一个可用的垂直问答模型，熟练之后一个下午够用，第一次做留出两天比较现实。卡住的地方通常不是技术本身，而是数据准备和环境配置这些琐碎环节。把这两块摸熟了，后面每次微调都是一条命令的事。