企业官网建设流程全解析

最近有个开源项目在 GitHub 上热度涨得特别猛，17K Star 只用了很短时间就到了，名字叫Laya。圈子里很多人把它当Jev的平替甚至上位替代来聊，尤其是做System 1决策场景的人，几乎人手一份。我花了两天时间从安装到微调完整跑了一遍，整体体验确实和以往玩别的模型不太一样，这篇就当是实操记录，想动手的可以直接照着走。

先说清楚这是什么东西、解决什么问题。Laya 是一个面向轻量级本地部署的决策模型，主打低延迟、快响应，非常适合用在那些需要在几百毫秒内给出判断的场景，比如实时风控预筛、客服意图分类、内容初审打标这类“看一眼就能拍板”的任务。它跟 Jev 这类偏通用对话和复杂推理的模型不一样，Laya 更接近“思维速度”这个方向——也就是 System 1。不需要多步思考、不需要链式推理，而是直接用训练好的直觉判断给结果，这种特性决定了它在工程落地时非常香。

适合谁来参考这份教程？一类是刚入行想做模型微调、但被 Jev 的高门槛或授权限制劝退的开发者，另一类是自己手上有业务数据、想把分类或决策能力集成到内部系统的工程师。下面内容从环境搭建讲起，一直走到 LoRA 微调和最终推理验证，全程有命令、有代码、有踩坑记录，照着操作基本能做到今天看、今天跑通。

1. 先搞清楚：Laya 是什么，为什么 System 1 决策值得单独做个教程

1.1 这个项目到底解决了什么问题

常见的通用大模型在回答问题时，默认走的是 System 2 路线：想清楚再回答，先给推理步骤，再给结论。这种做法在复杂分析时很好用，但在业务系统里却是灾难。举个例子，一个在线交易平台需要在 300 毫秒内判断一笔订单是否异常，如果每次都让模型“慢慢想”，先把上下文捋一遍，再输出一大段分析，延迟直接没法看。

Laya 的设计思路就是绕开这一步。它把判断压缩成了一种“反射式”输出：输入一段请求，直接给出类别或标签，没有多余推理痕迹。这种能力恰恰是靠微调训出来的，而不是基座模型天生就有的。所以 Laya 的完整玩法不是“拿来即用”，而是“拿来之后针对自己的业务场景做垂直微调”，把通用能力收敛到特定决策边界上。

我实际测试下来的感受是，原始 Laya 权重在泛化任务上表现中规中矩，但只要你给它喂几百条自己的业务样本做 LoRA 微调，它在那个特定场景下的判断准确率能提升到令人意外的水平，而且推理速度几乎不受影响。这也是为什么教程标题里要把“安装”和“微调”放在一起，缺了后一半，Laya 的威力打不出三成。

1.2 System 1 与 System 2 的边界在哪里

这里稍微展开一下。System 1 和 System 2 是认知科学里的概念，一个代表快思考、直觉判断，一个代表慢思考、逻辑推演。做工程落地时，一定要先分清手里的任务更适合哪条路线。

判断不清楚的话可以这样类比：你开车遇到路口突然蹿出一个人，踩刹车是 System 1；但如果是做一份年度预算报告，逐项核对数据、推演不同方案的收益，那就是 System 2。大模型架构天然更擅长 System 2，因为自回归生成本身就是“一步一步想”的过程。想让模型像 System 1 一样快速反应，就需要通过大量的短输入-短输出样本把这种行为固化下来。

所以在做数据准备时，我强烈建议不要使用那些带思维链的长输出数据集。我见过一些朋友用通用对话数据微调 Laya，结果模型学会了长篇大论，延迟一下子拉上去，完全背离了项目初衷。微调 Laya 的数据原则上就是“问句-短标签”结构，尽量压缩 answer 的长度，最好控制在 10 个 token 以内。

1.3 和 Jev 对比：为什么社区都在聊“爆打 Jev”

我最早看到“爆打 Jev”这个说法是在社区帖子标题里，一开始以为只是标题党，实际对比之后发现确实有客观原因，列个表大家自己感受。

对于内部系统来说，数据不出内网是硬需求。Jev 用起来虽然方便，但数据要过一遍外部接口，很多业务场景根本不敢这么干。Laya 的优势在于它把决策能力变成可以自己掌控的本地资产，加上开源许可宽松，二次开发和商业化都比较省心。

不过说句公道话，“爆打”不是全方位的，Laya 在复杂长文本理解和多轮对话上明显不如 Jev，跨语言能力也只是及格水平。我的判断是：如果你做的是强决策、弱对话的业务场景，Laya 比 Jev 合适得多；反过来则选 Jev 更稳。

2. 安装部署：从零开始把 Laya 跑起来

2.1 环境准备：硬件、Python 和 CUDA 版本

先说硬件门槛。Laya 原始权重在 7B 这个档位，直接用 FP16 推理大概需要 14GB 显存，如果你是 16GB 显存的消费级显卡，刚够跑。做微调的话显存就不太够了，建议走 QLoRA，4bit 量化后训练显存能压到 10GB 以内，具体的微调参数后面会写。

我的测试环境供参考：

• CPU：13 代 i5
• 显卡：RTX 4070 12GB
• 内存：32GB
• 系统：Ubuntu 22.04
• Python：3.10
• CUDA：11.8

装依赖之前先确认 CUDA 环境没问题。命令行执行nvidia-smi，看到驱动版本和 CUDA 版本就 OK。然后创建虚拟环境，避免把系统 Python 弄乱。

python3 -m venv laya-env source laya-env/bin/activate

2.2 下载模型权重与安装依赖

Laya 的权重发布在 Hugging Face 和 ModelScope 上，国内环境优先用 ModelScope，下载速度快很多，不需要额外配置。以 ModelScope 为例：

pip install modelscope modelscope download --model laya-ai/Laya-7B --local_dir ./models/laya-7b

下载完成后目录里应该有config.json、tokenizer.model、pytorch_model-*.bin或 safetensors 文件。这里要注意看下载的文件是 safetensors 还是 bin，后续加载代码里要对上。我下载的时候默认给的是 safetensors，加载时用trust_remote_code=True即可。

依赖包建议一次性装齐：

pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu118 pip install transformers accelerate bitsandbytes peft datasets

需要说明的是 torch 版本必须和 CUDA 匹配。我之前用默认 pip 源装过 CPU 版 torch，结果显存完全用不上，推理慢到无法接受。装完可以用下面这行验证 GPU 是否可用：

import torch print(torch.cuda.is_available(), torch.cuda.get_device_name(0))

输出True NVIDIA GeForce RTX 4070就说明环境没问题。这一部验证过了，后面的坑会少很多。

2.3 首次推理：验证模型是否真正正常

部署之后做的第一件事，不是直接上业务数据，而是用一条最简单的测试跑一遍推理。我习惯用一段很短的控制台代码确认加载和生成链路都没问题：

from transformers import AutoModelForCausalLM, AutoTokenizer model_dir = "./models/laya-7b" tokenizer = AutoTokenizer.from_pretrained(model_dir, trust_remote_code=True) model = AutoModelForCausalLM.from_pretrained( model_dir, torch_dtype="auto", device_map="auto", trust_remote_code=True ) prompt = "这笔订单：金额 8998，收货地址与常用地址不一致，新设备登录。请给出风险等级：" inputs = tokenizer(prompt, return_tensors="pt").to("cuda") output = model.generate(**inputs, max_new_tokens=20) print(tokenizer.decode(output[0], skip_special_tokens=True))

正常情况下输出应该是一个简短结论，比如“高风险”或“中风险”。这里有几个容易踩的坑：

• trust_remote_code=True必须带上，Laya 用了自定义 modeling 文件，不带就会报AutoModel找不到类。
• max_new_tokens不要设置太大，System 1 场景建议 10-50，太大模型容易放飞自我开始讲故事。
• 如果是 12GB 显存跑 7B FP16，首次加载会看到显存占用接近 13GB，属于正常现象，但推理时如果 OOM 了，就改用 4bit 量化加载。

4bit 加载方式如下：

from transformers import BitsAndBytesConfig quant_config = BitsAndBytesConfig( load_in_4bit=True, bnb_4bit_compute_dtype="float16", bnb_4bit_use_double_quant=True, bnb_4bit_quant_type="nf4" ) model = AutoModelForCausalLM.from_pretrained( model_dir, quantization_config=quant_config, device_map="auto", trust_remote_code=True )

这个模式之后做微调也会用到，所以建议从第一次接触开始就直接用 4bit，省得后面重新适应。

3. System 1 决策实战：让 Laya 在真实业务场景里干活

3.1 什么样的业务流程适合交给 Laya

不是所有决策都能用 System 1 解决，我梳理了几个识别标准，满足越多越适合：

• 输入短：单条文本不超过 500 字，不需要跨上下文理解。
• 输出短：结果是一个标签、一个类别、一个分数，不需要解释说明。
• 判断快：业务要求毫秒级响应，不能有长链路思考。
• 边界清：类别集合是固定的，比如“低/中/高”或“正常/异常”。
• 样本足：至少能攒出几百条带标签的历史数据。

满足这些特征的典型场景包括：客服工单自动分类、内容安全预审初筛、供应链异常告警分级、营销活动人群分桶。我在测试时选了客服工单分类来跑，因为这种场景数据好攒、标准明确，适合作为教学样例。

3.2 用 Laya 做快速分类的完整代码

部署通过后，直接写一个适配业务的小服务。下面这段代码用 FastAPI 包一层 HTTP 接口，方便业务系统调用：

from fastapi import FastAPI from pydantic import BaseModel from transformers import AutoModelForCausalLM, AutoTokenizer import torch model_dir = "./models/laya-7b" tokenizer = AutoTokenizer.from_pretrained(model_dir, trust_remote_code=True) model = AutoModelForCausalLM.from_pretrained( model_dir, torch_dtype="auto", device_map="auto", trust_remote_code=True ) model.eval() app = FastAPI() class Item(BaseModel): text: str CATEGORIES = ["售后", "退款", "物流", "咨询", "投诉"] @app.post("/classify") def classify(item: Item): prompt = f"将以下客服会话归类为{'、'.join(CATEGORIES)}之一。\\n会话：{item.text}\\n类别：" inputs = tokenizer(prompt, return_tensors="pt").to("cuda") with torch.no_grad(): output = model.generate(**inputs, max_new_tokens=5, do_sample=False) result = tokenizer.decode(output[0], skip_special_tokens=True) label = result[len(prompt):].strip() return {"label": label}

这里有一个非常关键的调参习惯：System 1 决策不要打开do_sample。采样模式会让模型在几个相似类别之间摇摆，产生不稳定输出。直接把do_sample=False可以保证同一个输入在任何时刻都得到同一个结果，这在业务审计时非常重要——如果你对同一笔订单重复请求返回不同风险等级，客户和风控部门都会很头疼。

另外 max_new_tokens 设为 5，理论上输出一个词足够，给到 5 是留余地。之前我遇到过一个情况，模型输出了类别：退款\n\n这样的换行，不加 strip 的话会把\n带进返回结果，前端再存库就会出现乱数据。所以我习惯于label = result[len(prompt):].strip().split()[0]，只取第一个词作为结论。

3.3 延迟与准确率的平衡经验

跑完一遍之后，我记录了一组关键数据：FP16 模式下平均单次推理延迟大约 260ms，4bit 模式下大约 340ms。对于 System 1 场景来说这两个值都在可接受范围。如果要求压到 100ms 以内，就需要上量化加速或者用小档位模型。

还想提升速度的话，有两条路可以走。第一条是开启torch.compile，实测推理快大概 15%，但首次运行要额外花时间做编译，适合长期服务场景；第二条是把max_new_tokens从 20 压到 5，这个改动对延迟影响很大，因为自回归解码是逐 token 生成的，少生成一个 token 就少一次前向计算。但要注意，输出压缩到 5 个 token 要求你的 prompt 写得足够干净明确，如果 prompt 里信息不足，模型只能瞎猜。

准确率端，我用了一份 2000 条历史客服工单做测试，Laya 原样跑出来的准确率大概是 78%。说实话这个水平直接上线不够硬，主要原因是通用权重对业务术语理解有限。这个问题的解决办法就是第 4 章和第 5 章要讲的微调。

4. 微调前必须要懂的三个核心概念

4.1 基座模型怎么选：直接用 Laya 还是基于 Qwen 微调

这里应该是社区里问得最多的点：是不是需要依托千问（Qwen）模型来进行微调？答案是对的，但也别绕太远。

Laya 官方给出的推荐路线就是基于 Qwen 系列基座做二次微调。因为 Laya 发布的是完整的开源权重，你可以直接用它，但如果你想在 Laya 的 System 1 能力基础上同时补充一些中文长文本理解能力，那基于 Qwen2.5-7B 起步微调会更稳妥。Qwen 的中文韧性很强，做垂直数据拟合时 loss 下降更快，而且社区生态好，LLaMA-Factory 对 Qwen 的支持非常完善。

我的建议是分两种情况：

• 业务纯中文、输入较短、对中文口语容忍度要求高：基于 Qwen2.5-7B 微调，效果一般更好。
• 业务希望保留 Laya 的全部决策特性、且需要和 Laya 社区的权重对齐后续更新：直接在 Laya 权重上 LoRA 微调。

前者适合大多数国内业务，后者适合已经有 Laya 部署基础的朋友。我实际对比过两者在同一份客服分类数据上的表现，Qwen 基座微调后准确率高了约 4 个百分点，但推理延迟也略高一点。你需要根据线上硬件重新权衡。如果你的显存只有 12GB，两个选择都只建议 QLoRA 微调。

4.2 LoRA 与全参微调：资源不够时的正确姿势

大模型微调听起来门槛高，但 LoRA 的出现把这扇门几乎拆了。它的思路是不动原模型全部参数，只训练一小部分新增的低秩矩阵。打个比方，原模型是一本已经写得满满的书，全参微调相当于把整本书重写一遍，LoRA 则只是在书页空白处加批注，成本低、修改可控。

用 LoRA 微调 Laya-7B 时，需要调整的参数范围大概只有总参数量的 0.5% 到 1%。这意味着你可以用一块 12GB 显存显卡，跑完原本需要 40GB+ 的全参微调任务。LoRA 的核心参数有四个：

• r：秩，决定新增矩阵的维度，常用 8/16/32。任务越难，秩适当加大，但不是越大越好，太大会过拟合。
• alpha：缩放系数，一般设为r的两倍。
• target_modules：要对哪些模块插入 LoRA。常见是q_proj, v_proj，更充分可以加k_proj, o_proj, gate_proj, up_proj, down_proj。
• dropout：防止过拟合，建议 0.05。

我用的配置是r=16, alpha=32, target_modules 包含全部线性层。小批量数据下这个配置收敛稳定，也不容易把原模型知识冲掉。

4.3 数据准备：System 1 场景的数据集长什么样

微调效果的 80% 由数据决定。System 1 场景的数据集和通用 SFT 数据集有本质区别，核心在于“短平快”。一份合格的训练集大概长这样：

[ { "instruction": "将以下客服会话归类为售后、退款、物流、咨询、投诉之一。", "input": "我的耳机坏了，想寄回去修一下可以吗", "output": "售后" }, { "instruction": "将以下客服会话归类为售后、退款、物流、咨询、投诉之一。", "input": "这个订单多久能发货？", "output": "物流" } ]

注意 output 必须只保留最核心的标签词，不要写解释，不要写额外上下文。我在实际准备数据时还做了三类增强。

第一是边界样本增强。把容易混淆的样本成对放进去，比如“我想退货”和“我想退款”表面上很像，但业务上一个是商品问题、一个是资金问题，模型要学会区分。第二是噪声输入增强。在部分 input 里加入口语语气词、错别字、停下思考的“呃”等，让模型在真实环境里更稳。第三是负例覆盖。每条类别至少安排 10% 比例的边缘样本，防止模型把某个类别当成默认答案。

数据量建议最少 500 条，最多 5000 条。少于 500 条基本学不到决策边界，多于 5000 条边际收益递减，反而增加过拟合风险。

5. 从安装到微调：动手跑一遍 LLaMA-Factory

5.1 LLaMA-Factory 的安装与配置

现在主流微调工具框架已经非常成熟，LLaMA-Factory工程基本已经跑起来了，它把数据加载、训练、推理、导出都包成了现成模块，几乎不用写底层代码。项目地址在 GitHub 上，直接 clone 之后装依赖就行。

git clone https://github.com/hiyouga/LLaMA-Factory.git cd LLaMA-Factory pip install -e .

注意安装时确保虚拟环境还处于激活状态。装完之后在项目根目录创建一个工作目录data，把前面准备好的 JSON 训练数据放进去，命名为train_data.json。

接着需要改一下数据集注册文件。LLaMA-Factory 默认用data/dataset_info.json来识别数据集。在文件里的datasets列表中追加一项：

{ "laya_system1": { "file_name": "train_data.json", "columns": { "prompt": "instruction", "query": "input", "response": "output" } } }

这里有个细节新手很容易忽略：query字段可以留空，但不是所有数据集都有input。如果你的 JSON 里没有input字段，这里就必须改成"query": ""，LLaMA-Factory 才能正确解析。

5.2 训练参数设置：从模板配置到收敛判断

LLaMA-Factory 提供网页界面和命令行两种方式。我倾向于命令行启动，方便记录日志和批量跑实验。到项目根目录执行：

CUDA_VISIBLE_DEVICES=0 python src/train.py \ --model_name_or_path ./models/laya-7b \ --dataset laya_system1 \ --stage sft \ --finetuning_type lora \ --quantization_bit 4 \ --template qwen \ --output_dir ./output/laya-lora \ --num_train_epochs 3 \ --per_device_train_batch_size 2 \ --gradient_accumulation_steps 8 \ --learning_rate 2e-4 \ --lr_scheduler_type cosine \ --logging_steps 10 \ --save_steps 100 \ --max_length 512 \ --lora_rank 16 \ --lora_alpha 32 \ --lora_dropout 0.05

重点解释几个参数：

• --template qwen：因为前面推荐基于 Qwen tokenizer 路线，或者 Laya 本身也兼容 Qwen 模板，这里用 qwen 模板最稳。如果用默认模板，可能出现对话格式错乱。
• --per_device_train_batch_size 2：7B 模型 4bit 模式下 batch size 不敢给大，12GB 显存给 2 是极限，给 4 大概率 OOM。
• --gradient_accumulation_steps 8：这里是把 batch 等效放大到 16，保证梯度稳定。实际等价 batch size = 2 × 8 = 16。
• --max_length 512：System 1 数据一般很短，512 足够了。设太大只会白白消耗显存。
• --learning_rate 2e-4：LoRA 微调的常见学习率区间是 1e-4 到 5e-4。第一次跑建议 2e-4，训练快且不容易震荡。

训练过程中可以看 loss 曲线。正常情况下第一个 epoch loss 应该从 1.2 左右降到 0.4 以下，后面继续走低但逐渐平缓。如果第二个 epoch 之后 loss 还在明显下降，说明数据复杂度足够；如果 loss 降得很快但同时验证集表现停滞，就要警惕过拟合。

5.3 训练启动与显存监控

执行脚本后建议开另一个终端窗口实时盯显存：

watch -n 0.5 nvidia-smi

显存占用稳定在 9-11GB 是正常的。如果看到CUDA out of memory，优先把per_device_train_batch_size改成 1，再把gradient_accumulation_steps调成 16，两者乘积保持不变。如果还是 OOM，考虑关掉--quantization_bit 4之外的其他功能，或者换更小的模型底座。

训练结束后，输出目录里会有一堆 checkpoint 文件夹，比如checkpoint-100、checkpoint-200。选择一个 loss 最低且验证效果好的 checkpoint 做后续推理。不能用最后一个 checkpoint 就完事，我记得有一次训练到第三个 epoch，过拟合迹象已经很明显，用最后一个 checkpoint 推理时一堆样本被错分到高频类别，反而是 epoch 2 的 checkpoint 表现最好。

5.4 微调后的模型导出与推理验证

训练出来的 LoRA 适配器只是一个小文件，必须和原模型合并或加载后才能形成完整的可用模型。推理验证时可以用 PeftModel 加载：

from peft import PeftModel from transformers import AutoModelForCausalLM, AutoTokenizer base_model = AutoModelForCausalLM.from_pretrained( "./models/laya-7b", torch_dtype="auto", device_map="auto", trust_remote_code=True ) model = PeftModel.from_pretrained(base_model, "./output/laya-lora/checkpoint-200") model.eval()

如果要在生产环境部署，建议直接导出合并后的完整权重。LLaMA-Factory 也提供了导出脚本：

python src/export.py \ --model_name_or_path ./models/laya-7b \ --adapter_name_or_path ./output/laya-lora/checkpoint-200 \ --template qwen \ --finetuning_type lora \ --export_dir ./models/laya-7b-system1

导出后要用一份独立的测试集做盲测。我测试下来效果最明显的变化是：准确率从 78% 提升到了 94%，而且误判集中在“售后”和“退款”这两个本来就很模糊的类别上。如果还想继续优化，就往这个方向补充更多边界数据。

6. 常见问题与排查技巧实录

6.1 显存不足：消费级显卡的极限操作

12GB 显存跑 7B 微调，最危险的就是 OOM。除了前面提到的 batch size 调整，还有一个技巧是用 CPU offload，把一部分参数暂时放到内存。但代价是训练速度急剧下降，30 分钟一个 epoch 变成 2 小时一个 epoch，所以不到万不得已不用。

另一个经验是关掉验证集评估。LLaMA-Factory 支持在训练中定期跑验证，这个功能在消费级显卡上开销很大，大部分人根本用不上。直接不加--val_size参数，把显存全留给训练，验证放到最后统一做。我实测省出来的显存足够把 batch size 从 2 提回 4，训练速度还更快了。

6.2 微调后效果变差怎么办

微调后效果变差一般有三个原因。一是学习率太高，权重被冲得太狠，模型原有的泛化能力被破坏。解决办法是把学习率调到 1e-4 甚至 5e-5，不要一味追求收敛速度。二是训练轮数太多导致过拟合，这个问题前面提过，可以看 checkpoint 在不同阶段的验证表现，选最优的那个。三是数据质量差，比如标签错误、类别分布严重不均衡，这种情况下怎么调参都没用，只能回去清洗数据。

还有一种容易被忽略的情况：你训练的 LoRA 只适配了某一类 prompt 模板，上线后业务侧换了 prompt 写法，效果立刻退化。解决方案是在训练数据里加入至少 3 种不同的 prompt 表述，让模型对 prompt 变化不敏感。

6.3 训练完合并权重时丢失 LoRA 效果

peft库在加载和合并时特别容易出问题。我前后踩过两次坑，一次是合并后模型输出乱码，另一次是合并后效果全无。排查后发现前者是因为 base model 的torch_dtype没指定，自动变成了 fp32；后者是因为 adapter 路径写错了，加载到了另一个 checkpoint。

合并后一定要做三轮全量预测对比：原模型输出 vs LoRA 模型输出 vs 合并后模型输出。三者中后两者应该高度一致，如果不一致，多半是合并过程中量化精度对不上。4bit 模型合并时建议先把 base model 切成 fp16 再合并，可以规避大多数精度问题。

6.4 常见问题速查表

6.5 一点额外心得：千万别忽略日志

最后分享一个我每次跑项目都会做的事：把训练日志完整留存下来。LLaMA-Factory 默认的logging_steps=10只打印在控制台，一旦窗口关了就没法回溯。建议加上--logging_dir ./logs，或者直接把终端输出用tee重定向到文件。等到你后面想对比不同实验的效果、定位某个 checkpoint 是怎么训出来的时候，就会发现这些日志比什么都值钱。按照这套流程走完，从安装到微调，一共也就两三个小时的事。我自己实际跑下来的感受是，Laya 这条路线把 System 1 决策任务的技术门槛拉低了很多，以前这类活要么花大价钱调商业 API，要么自己吭哧吭哧从零训模型，现在一份开源权重加一套成熟工具链就能搞定。如果你正准备做类似的决策分类或者希望在业务里加入更多快判断能力，可以在 Laya 基础上按这份教程试一遍，相信你会有不一样的收获。