紫微斗数排盘引擎源码解析：从农历转换到四化映射的规则链
2026/9/14 15:31:27
如果你手里有一个开源大模型，想让它老老实实回答业务里的具体问题，那八成会遇到同一个尴尬：它什么都懂，就是不按你的规矩来。我最近把一套叫 llmfit 的微调流程完整梳理了一遍，核心思路很简单——让大语言模型真正“fit”到你的数据和场景里。这篇文章不聊空泛的概念，只讲我在实际落地中用到的数据准备、LoRA 训练、模型导出、效果验证这些环节，适合那些想自己做垂直领域模型，又不想一上来就整一堆复杂平台的工程师。
llmfit 这个名字是我整理这套流水线时起的叫法，它不是某个固定框架，而是一套组合方案：把开源基座模型、指令微调、低资源训练、部署验证这些环节串起来，最终产出一个能用、可复现、不依赖大算力的私有模型。下面我按自己实操的顺序，把整个链路拆开来讲。
1. 项目整体设计与思路拆解
1.1 为什么不能直接把通用模型丢进业务
先聊一个经常被忽略的问题：通用大模型在聊天、写代码、翻译这些场景确实很强，但一进到具体业务就开始露馅。
我早期做过一个客服知识库项目，直接把一个开源 7B 模型接进了对话服务。日常问题还好，一旦问“退款大概几天到账”“你们对公账户开户需要什么材料”这种带内部规则的问题，模型就开始自由发挥了，甚至会把网上搜到的通用答案混进来，完全没有我们自己的政策依据。
原因其实不复杂：通用模型的训练目标是“像人一样自然说话”，而不是“完成某个业务动作”。它脑子里装的是互联网级别的通识，不是你们公司的规则、术语和流程。想让它按你的规矩来，最直接的办法就是用你自己的数据再训练一段，让模型“适配”你的业务场景。
这正是 llmfit 要解决的核心问题：把通用大模型“拟合”到你的任务分布上，而不是换个更大的通用模型去赌它碰巧知道。
1.2 llmfit 是什么：一套面向适配的微调流水线
开始做这个项目之前，我一度想找一个现成的微调平台，后来发现要么太重，要么和自己的数据链路对不上。所以我干脆整理了一套自己的流程，名字就叫 llmfit。
这套流水线不固定绑定某个具体工具，核心是几个松耦合的阶段：
- 基座模型选型：根据场景和显存预算确定 7B、13B 还是更大的模型
- 数据准备：清洗、去重、构建指令格式，生成训练和验证集
- 训练环节：用 LoRA/QLoRA 做参数高效微调，训练过程可监控、可断点恢复
- 模型导出：把 adapter 合并回基座模型，导出为正常可部署的权重
- 效果验证：用业务测试集评估，而不是只看训练 loss
我把这些步骤固化成了几个脚本和一个简单的 Makefile，换数据、换基座模型、换参数都只要改配置。后来同事问我用的什么框架，我说这叫 llmfit，意思是“让大模型 fit 你的场景”。
这套东西适合谁？适合你只有一个 GPU、想快速做一个垂直领域模型、又想把整个流程掌控在自己手里的团队。它不一定适合要做千亿级模型预训练的大厂，但对大多数中小项目来说，已经完全够了。
1.3 技术选型：为什么 LoRA 而不是全参微调
先放一个我当时的对比表，帮各位理解为什么最终选了 LoRA 路线。
| 方案 | 显存需求（7B 模型） | 成本 | 效果 | 迭代速度 |
|---|---|---|---|---|
| 全参数微调 | 80GB+，基本得 A100/H100 | 很高 | 上限最高，但容易灾难性遗忘 | 慢，每次都要全量训练 |
| LoRA | 14GB 左右（fp16 加载） | 中等 | 接近全参微调，尤其指令类任务 | 快，只训练少量参数 |
| QLoRA | 6GB-8GB（4bit 加载） | 低 | 比 LoRA 略低，但可接受 | 最快，普通消费卡就能跑 |
全参数微调不是不好，是贵。一个 7B 模型，全量微调光优化器状态就把显存吃满了，还要担心遗忘问题：旧能力刷一下就没了。LoRA 的做法是冻结原来的模型，只在注意力层的权重旁边加了一组低秩可训练矩阵，训练时只更新这部分，参数量通常不到原来的 1%。
我印象最深的一次，用 QLoRA 在单张 4090 上训 7B 模型，显存峰值不到 12GB，一个晚上跑完 3 个 epoch。这换全参数微调连门都进不去。所以 llmfit 默认采用 LoRA/QLoRA 路线，不是因为它最花哨，而是因为它最适合“业务适配”这个目标：快、便宜、可反复迭代。
2. 核心细节解析与实操要点
2.1 数据是项目的上限，训练只是逼近上限
这句话我在不同场合说过很多遍：微调效果不好，80% 的问题出在数据上，而不是模型上。
llmfit 的数据准备我一般分三步走。第一步是清洗，把原始语料里的 HTML 残留、大量重复句子、明显乱码都过滤掉。第二步是去重，尤其是从网上爬的数据，重复率可能高得吓人，我见过一个客服语料里同一句话出现几百次的。第三步才是构建指令格式。
指令微调常见的有两种格式：一种是 Alpaca 风格，适合单轮问答；另一种是 ShareGPT 风格，适合多轮对话。Alpaca 格式每条样本长这样：
{ "instruction": "把下面这句话翻译成中文", "input": "Large language models are amazing.", "output": "大型语言模型非常棒。" }多轮对话则要带上 user/assistant 的角色标记。不管是哪种格式，最关键的一点是：格式必须全量统一，不能这 1000 条用 Alpaca，那 1000 条用 ShareGPT，模型会被格式搞晕。
还有一个我踩过的坑：数据的领域分布。刚开始我把目标场景的数据堆到 100%，训练之后模型确实能回答业务问题了，但通用能力明显下降，问个“1+1 等于几”反而支支吾吾。后来我改成 90% 目标业务样本 + 10% 通用问答样本，保持基础能力不再下滑。这个比例不用特别精确，但一定要在数据集里留出那个“保底”的部分。
2.2 训练参数选型：这些参数背后是有逻辑的
llmfit 的训练参数配置，我用一张表给出最常见的起点：
| 参数 | 推荐值 | 说明 |
|---|---|---|
| lora_rank | 8 或 16 | 低秩矩阵的秩，不是越大越好 |
| lora_alpha | rank 的 2 倍 | 控制 LoRA 更新的缩放比例 |
| learning_rate | 2e-4 左右 | LoRA 微调通常比全参微调高 1 个数量级 |
| batch_size | 1-4 | 取决于显存 |
| gradient_accumulation_steps | 4-8 | 模拟更大的 batch |
| max_seq_len | 1024 或 2048 | 根据业务样本长度设置 |
| num_epochs | 3 | 样本量越少，epoch 可以适当增加 |
| warmup_ratio | 0.03 | 帮助稳定训练 |
| lr_scheduler_type | cosine | 收敛更平滑 |
很多人不理解 lora_rank 该设多少。我一开始习惯把 rank 拉到 32、64，觉得参数多效果一定好，结果不仅训得慢，效果也没有明显提升。后来查资料了解到，LoRA 的本质是在低维空间里做“增量学习”，rank 太大反而会导致增量空间过大，模型学到不必要的噪声。
learning_rate 这个参数也值得多说两句。全参微调时常用 1e-5 左右，但 LoRA 只更新一层薄薄的适配矩阵，学习率太低根本推不动，常见范围在 1e-4 到 3e-4 之间。我一般从 2e-4 起步，数据量小就设低一点，数据量大可以放开一点。
2.3 显存优化三板斧：QLoRA、梯度检查点和序列截断
很多读者可能没有 A100，能用的就是一张 3090 或者 4090，显存 24GB 以下。这种情况，llmfit 的默认配置几乎都能扛住。
第一板斧是 QLoRA。简单说就是在加载基座模型时，把权重量化成 4bit，参数精度降了，但显存占用大幅下降。配合 bitsandbytes 库，一个 7B 模型从 fp16 的大约 14GB 压缩到不到 5GB。我实测 7B QLoRA + batch_size=1 + max_seq_len=1024，在 8GB 显存的卡上也能勉强跑起来，24GB 的卡则游刃有余。
第二板斧是 gradient checkpointing。这招用时间换显存：不保留每一层的中间激活值，而是反向传播时重新算一遍。开启后训练会慢一些，但显存能省下三分之一甚至更多。方法很简单，在 TrainingArguments 里设置gradient_checkpointing=True即可。
第三板斧是序列截断。很多业务样本其实没那么长，但如果你设置 max_seq_len=4096，模型会为每条样本都预留很长的空间，显存自然爆。我一般会根据数据集的长度分布来定，比如 95% 的样本不足 1024 字符，就设成 1024，既省显存又加速。
注意：不要为了省显存把 batch_size 设成 1，再把 gradient_accumulation_steps 调到 16 以上。累积步数过高会让模型收敛变慢，而且 loss 曲线会非常抖。
3. 实操过程：从零跑通一套 llmfit 流水线
3.1 环境搭建与依赖安装
这个环节最容易劝退新手，但实际就两件事：装好 PyTorch，装好 Hugging Face 相关库。
我的推荐环境是 Python 3.10 + CUDA 12.1，Linux 优先。Windows 不是不行，但 bitsandbytes 在 Windows 上的坑太多，我自己就在这上面浪费过两天时间。如果你是个人电脑 Windows 环境，建议用 WSL 或者直接租一台云 GPU 实例。
依赖安装用 pip 一条命令：
pip install torch transformers peft bitsandbytes accelerate datasets sentencepiece版本上不用追新，能稳定跑通即可。我当时用 transformers 4.36 和 peft 0.7，后来升级到更高版本也没有破坏性变化。
装完之后记得跑一个极简测试：加载一个 7B 模型并推理一句话，先确认环境没问题，再往下走。这个检查花不了几分钟，但能避免后面训练跑到一半才发现 CUDA/显存/库版本不匹配的问题。
3.2 数据加载与预处理
数据准备好了之后，我们把它变成一个训练集。llmfit 的预处理脚本，核心就做三件事：读原始 JSONL、拼接 prompt 文本、tokenize 并设置 label。
先说指令拼接。Alpaca 格式的处理逻辑很简单：
def format_sample(sample): if sample["input"]: prompt = f"### 指令：\n{sample['instruction']}\n\n### 输入：\n{sample['input']}\n\n### 回答：\n" else: prompt = f"### 指令：\n{sample['instruction']}\n\n### 回答：\n" return prompt + sample["output"] + tokenizer.eos_token注意，这里的 eos_token 一定要加在回答后面。它告诉模型“一句话说完了”，不然训练时模型会一直学不到终止生成的信号。
tokenize 的时候，还有一个非常关键的动作：label 一定要把 prompt 部分遮掉。什么叫遮掉？就是把 prompt 对应的 token 位置在 label 里设为 -100，这样计算损失时会自动忽略这些位置，模型只学“怎么回答”，而不是学着把问题再复述一遍。我第一次做的时候忘了这一步，训练出来的模型变“复读机”，回答之前先把你问题重复一遍。
3.3 训练配置与启动
核心训练代码用 transformers 的 Trainer，加上 peft 的 LoraConfig，代码量其实不大。下面这段是 llmfit 训练部分的核心骨架。
from transformers import ( AutoModelForCausalLM, AutoTokenizer, TrainingArguments, Trainer, ) from peft import LoraConfig, get_peft_model from datasets import load_dataset model_path = "meta-llama/Llama-2-7b-chat-hf" tokenizer = AutoTokenizer.from_pretrained(model_path) tokenizer.pad_token = tokenizer.eos_token model = AutoModelForCausalLM.from_pretrained( model_path, load_in_4bit=True, device_map="auto", ) lora_config = LoraConfig( r=8, lora_alpha=16, target_modules=["q_proj", "v_proj"], lora_dropout=0.05, bias="none", task_type="CAUSAL_LM", ) model = get_peft_model(model, lora_config) training_args = TrainingArguments( output_dir="./llmfit_checkpoints", per_device_train_batch_size=2, gradient_accumulation_steps=4, learning_rate=2e-4, num_train_epochs=3, logging_steps=10, save_steps=200, save_total_limit=2, fp16=True, gradient_checkpointing=True, warmup_ratio=0.03, lr_scheduler_type="cosine", ) dataset = load_dataset("json", data_files="train.jsonl", split="train") # 这里要再套一个预处理函数，参考 3.2 的格式拼接和 tokenize trainer = Trainer( model=model, args=training_args, train_dataset=dataset, ) trainer.train()训练过程中我一般盯着 logging 里的 loss，只要它是稳步下降的，就不用过多干预。如果 loss 出现突然飙升，马上停下来看数据和参数，而不是等它自己恢复。
3.4 模型合并与导出
训练完之后，peft 保存的是 adapter 权重，体积很小，通常几十 MB。但业务部署时不可能每次加载都在基座模型上加 adapter，所以要把 adapter 合并回原模型。
from peft import PeftModel model = PeftModel.from_pretrained(base_model, "./llmfit_checkpoints/checkpoint-500") merged_model = model.merge_and_unload() merged_model.save_pretrained("./llmfit_final") tokenizer.save_pretrained("./llmfit_final")合并这一步很少有人会出问题，但有一个建议：合并后再用同一批测试样本跑一遍推理，确认输出正常。我遇到过一种情况，训练时效果不错，合并导出后输出完全乱掉，后来发现是合并时的 base model 加载精度不一致导致的。所以“训练通过”不等于“导出可用”，一定要复测。
导出之后的模型，如果要在 CPU 或者边缘设备上跑，可以考虑转成 GGUF 格式。这个后续单独写，不展开。
3.5 部署与效果验证
合并后的模型就是一个标准 Hugging Face 格式的文件夹，部署方式很多。最简单的是用 vLLM 起一个 OpenAI 兼容的 API：
python -m vllm.entrypoints.openai.api_server \ --model ./llmfit_final \ --port 8000 \ --gpu-memory-utilization 0.9然后我用一个包含 30 条业务问题的测试集去调接口，把输出记录下来。下面这种表格式对比是我最常用的评估方式：
| 测试问题 | 预期回答要点 | 模型实际输出 | 是否通过 |
|---|---|---|---|
| 退款什么时候到账？ | 1-3 个工作日、原路退回 | 回复了到账时间，但没提原路退回 | 部分通过 |
| 怎么开发票？ | 在 App 内申请、电子发票发送至邮箱 | 基本准确 | 通过 |
如果通过率太低，我不会急着调 prompt，而是回到训练数据里看这类问题的样本量和质量。因为模型训练完之后，靠推理参数来补救是有限的。
4. 常见问题与排查技巧实录
4.1 显存不足：CUDA out of memory
这是新手遇到最多的错误。我的习惯是按顺序排查：
- 把 per_device_train_batch_size 降到 1，这是最直接有效的
- 开启 gradient checkpointing，显存会立刻松一大截
- 检查 max_seq_len 是否过长，比如 1024 改成 640，前提是业务样本没那么多长文本
- 确认已经用 load_in_4bit=True 做量化加载
- 清理其他占用显存的服务，比如同时开着的模型推理进程
有一次我在 16GB 显存上跑 7B 全量加载，怎么调都溢出，最后发现是另一个 Python 进程占着 6GB 显存。把多余进程杀掉之后，训练立刻恢复正常。所以先看 nvidia-smi，再动配置。
4.2 损失不下降或异常波动
训练 loss 一直不降，或者从一开始就抖动乱跳，最常见的两个原因都在数据上。
一个是数据格式不统一。比如有的样本 instruction 里有 input，有的没有，但你的格式化函数没有处理这种情况，模型学到的是“一会儿要看输入，一会儿不看”，自然学不明白。另一个是 label 没有正确设置 mask，把 prompt 也一起算进了 loss，模型的重心被带偏了。
还有一个小细节容易被忽略：tokenizer 的 pad_token。很多模型没有设置 pad_token，如果不手动设成 eos_token，DataCollator 在 padding 时会报错，或者生成奇怪的 loss。处理方法就是在加载之后加一行：
tokenizer.pad_token = tokenizer.eos_token4.3 生成结果重复、乱答
训练完的模型如果总是重复一句话，或者回答内容和业务毫不相关，我一般从三个方向排查。
第一，训练数据里是否混入了大量低质量、高度相似的内容。重复数据会让模型产生很强的“惯性”，输出越来越单一。第二，训练轮次是否过多。LoRA 参数少，但不是不会过拟合，训练集 loss 很低，验证集效果反而变差，就是典型的过拟合信号。第三，推理参数是不是太激进了。可以试着把 repetition_penalty 调到 1.1，把 max_new_tokens 控制在合理范围，不要一次性生成 1024 个 token。
实际排查中，推理参数的问题最容易被忽略。因为训练时模型是逐步生成的，没有采样参数限制，但部署时如果 temperature 设得太高，输出就会发散。
4.4 部署后效果和训练时不一致
训练时代码里跑得好好的，部署到 vLLM 之后输出变差了，这也是我踩过的坑。
最大原因是采样参数不一致。transformers 的 generate 默认是贪心解码，vLLM 默认的 temperature 是 1.0，top_p 也是 1.0，直接把随机性拉满。解决方法是把部署端的采样参数显式固定，例如 temperature=0.1、top_p=0.9，并且让测试用同一套参数。
还有精度问题。训练时用 fp16，部署到某些推理框架时可能被转成 int8 或 int4，导致效果轻微下降。这通常是量化导致的。如果业务对效果要求很高，就不要对最终模型做激进量化；如果必须压缩体积，就要用更多测试样本去验证量化后的效果。
5. 实战经验总结与后续扩展建议
5.1 小步快跑，先用 mini 集跑通全流程
我强烈建议第一次跑 llmfit 时，不要直接上全量数据、长训练周期。我自己的习惯是先抽 200 条到 500 条样本，把数据、训练、导出、部署这条链路完整跑通。这样有几个好处：快速发现数据格式错误，快速验证显存和训练参数是否合理，避免全量训练跑了三个小时才发现基础代码有 bug。
我当时第一次跑全量，因为没做 mini 验证，训练了 4 个小时后才发现格式化函数把 input 字段丢了，导致所有样本都忽略了用户输入。后来改成先跑 mini 集，卡在 15 分钟以内解决问题，整个项目效率提升非常大。
5.2 一定要有一个业务评测集
用训练 loss 来判断模型好坏并不可靠。我见过 loss 降到 0.3，但实际业务回答完全不能用的案例。所以 llmfit 流水线里我固定保留一个评测集：20 到 50 条真实业务问题，带预期答案要点。每次训练完，跑一遍评测集，记录通过率。
对于生成类任务，我用两种方式评估：一是关键词/规则判断，比如期望回答里必须包含“1-3 个工作日”；二是让一个更强的大模型当裁判，对回答打分。人工抽样复查也不能省，尤其刚上线那几天，一定要有人肉眼盯日志。
5.3 llmfit 后续还能怎么扩展
这套流程跑通之后，后面的扩展空间其实很大。比如遇到知识经常更新的场景，可以直接在外面挂一个 RAG 检索，把实时资料检索出来再喂给模型，不需要频繁重训；如果想让模型学会“更符合人类偏好”的回复，还可以在 LoRA 微调之后加一步 DPO 训练；如果有多条业务线，可以给每条线各训练一个 adapter，部署时按业务动态切换，这样比维护多个独立模型省很多资源。
我现在最常用的做法，还是把 llmfit 当作一个基础底座：数据住里丢，adapter 往外出，谁要什么能力就单独适配，互不干扰。最后分享一个小技巧：每次训练的 adapter 记得带上数据版本和参数备注，命名类似adapter_customer_v2_r8，不然过一个星期回来看，你可能连自己都分不清哪个 adapter 对应哪次实验。这个习惯帮我省了非常多返工的时间。