在开源大模型圈子里，每隔几天就会冒出一个“新王”。前阵子Jev刚火起来的时候，我也跟风折腾了一番，确实在复杂推理任务上有点东西。但等我真正把Laya跑起来，尤其是在System 1决策这类需要快速响应的场景里实测之后，我的结论很明确：Laya的工程化完成度和实用性价比，已经明显压过Jev一头。这也就是为什么Laya能在GitHub上冲到17K Star。这篇帖子不写虚的，我把从零开始安装Laya、理解它的System 1决策原理，再到用LLaMA-Factory做垂直微调的完整过程，全部拆开揉碎讲清楚。不管你是刚入门想跑通第一个模型，还是已经在做微调但效果不理想，这篇都能给你一个可以直接抄作业的路线。

1. Laya与Jev的定位差异：为什么System 1场景我选Laya

1.1 Jev模型的“强”与“重”

先说Jev。Jev在开源社区走红，靠的是它在数学推理、代码生成这类System 2慢思考任务上的表现。它的模型架构在推理链上做得比较深，擅长把复杂问题分解成多步逻辑链，这也让它在很多benchmark上拿到了不错的分数。

但问题也出在这里。Jev把大量计算资源花在了“深度推理”上，导致它在单次请求的响应延迟上偏高。如果你只是拿它做离线批量推理，这倒无所谓；可一旦要接到实时决策链路里，比如交易风控、智能客服的实时应答、或者Agent工具调用的即时路由，这个延迟就会被放大得很明显。我实测过，在同样一张A100上跑相同体量的请求，Jev的端到端响应时间比Laya要慢不少，尤其是在上下文比较短、需要快速返回结果的场景下，体感差距非常大。

所以Jev不是不强，而是它的强项不在System 1。选型这件事，从来不是看谁“更强”，而是看谁“更合适”。

1.2 Laya的System 1决策优势

System 1这个概念，最早是心理学家卡尼曼提出来的，指代人类那种快速、直觉、不经过深度思考的判断方式。对应到AI模型上，System 1决策指的就是模型在极短时间内的模式识别和条件反射式输出，它不需要长篇的思维链，而是基于训练时内化的经验直接给出结果。

Laya的设计目标，明显就是奔着System 1场景去的。它的架构做了一些针对性的精简，在保持推理质量不滑坡的前提下，大幅压缩了前向传播的计算路径。反映到实际使用中，就是响应速度快、显存占用低、单机并发能力强。我把它接在内部的一个标注系统里做预过滤，原来用Jev跑一条规则判断要1.5秒，换成Laya之后降到了400毫秒以内，准确率几乎没有下降。

另外，Laya的17K Star不是刷出来的，它的社区活跃度、文档完善度、以及周边生态的适配程度，都做得比较扎实。尤其是对LLaMA-Factory和Ollama的支持，几乎是开箱即用。这一点对于做工程落地的朋友来说，节省的可不只是几个小时的时间。

1.3 选型建议：什么场景该用谁

我在多个项目里对比过这两个模型，总结下来的选型逻辑是这样的：

• 如果你的任务是深度推理、多步逻辑、复杂代码生成，Jev仍然有价值，它的慢思考能力确实强。
• 如果你的任务是实时决策、意图识别、快速分类、内容预过滤、或者跑在资源有限的边缘设备上，Laya是更务实的选择。
• 如果你是做研究对比，两个都值得部署，但主力生产环境建议优先考虑Laya。

这里还要提醒一句：模型选型不是一锤子买卖。Laya虽然基础能力已经不错，但真要落地到垂直领域，比如医疗、法律、金融，还是需要做针对性微调。接下来我就详细讲讲，怎么从零开始把Laya装起来，并且用微调把它调成你专属的决策引擎。

2. 环境准备与Laya安装：从硬件到跑通推理

2.1 硬件选型与依赖安装

先说硬件。Laya的底座模型分为好几个尺寸，我建议你根据手里的卡来选：

• 如果你的显存是8GB到12GB（比如RTX 3080Ti、RTX 4070Ti），选择7B或8B量级的版本，配合4bit量化可以跑起来。
• 如果显存是16GB到24GB（比如RTX 4090、A5000），可以跑完整的14B模型，或者8B模型的高精度版本。
• 如果手上有A100 40GB或80GB，那几乎可以随意玩，包括后续微调都从容很多。

我自己的主力环境是两张4090，平时推理用单卡就够，微调时才上双卡并行。操作系统我建议直接用Ubuntu 22.04 LTS，CUDA版本12.x，PyTorch官方预编译版本就可以。

依赖这块，核心就是transformers、accelerate、datasets这几个包。建议用虚拟环境隔离安装，避免把系统环境搞乱。我用的是conda，创建环境之后直接pip安装。版本上以官方推荐的为准，不建议追新，因为大模型生态里版本兼容是老大难问题。

conda create -n laya python=3.12 conda activate laya pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu124 pip install transformers accelerate datasets pip install huggingface_hub

实测下来，这种安装方式最稳定，基本不会遇到wheel冲突的破事。

2.2 下载Laya模型与基础推理验证

模型下载这块，Laya官方提供了Hugging Face和ModelScope两种渠道。国内访问Hugging Face有时候不太痛快，我一般优先用ModelScope，速度稳定很多。

下载的方式有两种。一种是直接用huggingface_hub的snapshot_download把整个仓库拉下来，这种方式适合要跑微调、需要完整模型文件的场景。

from huggingface_hub import snapshot_download snapshot_download(repo_id="your_namespace/Laya-8B-Chat", local_dir="./Laya-8B-Chat")

另一种是直接用transformers的from_pretrained加载权重，它会自动处理下载和缓存。这种方式适合只做推理验证的场景。

模型文件下完之后，不要急着接业务，先跑一段简单的对话验证一下。这样可以确认权重文件没有下完整、transformers版本是否兼容、以及显存是否能正常分配。

from transformers import AutoModelForCausalLM, AutoTokenizer import torch model = AutoModelForCausalLM.from_pretrained( "./Laya-8B-Chat", torch_dtype=torch.float16, device_map="auto" ) tokenizer = AutoTokenizer.from_pretrained("./Laya-8B-Chat") prompt = "判断这条用户评论的情感倾向，只输出正向或负向：'快递慢得离谱，客服也不理人。'" inputs = tokenizer(prompt, return_tensors="pt").to("cuda") outputs = model.generate(**inputs, max_new_tokens=32, do_sample=False) print(tokenizer.decode(outputs[0], skip_special_tokens=True))

第一次跑的时候，如果显存不够，会直接报CUDA out of memory错误。这时候别急着加卡，先试试load_in_4bit=True参数：

from transformers import BitsAndBytesConfig bnb_config = BitsAndBytesConfig(load_in_4bit=True, bnb_4bit_compute_dtype=torch.float16) model = AutoModelForCausalLM.from_pretrained("./Laya-8B-Chat", quantization_config=bnb_config, device_map="auto")

这个操作能把显存占用压下来一大截，对资源有限的朋友非常友好。

2.3 第一次跑通后的性能基线记录

我习惯在一开始就记录性能基线，这样微调前后才有对比依据。主要记录几个指标：单次请求延迟、首token延迟、显存峰值占用、以及简单任务上的准确率。

用前面那段情感分类的代码跑100条测试数据，Laya 8B在4090上的表现是：平均单次推理耗时约420ms，首token延迟约150ms，显存峰值约14GB（fp16）、6.2GB（4bit量化），分类准确率91.5%。

对比之前用Jev跑同样数据：平均单次推理耗时约1.4秒，准确率93.2%。准确率高了不到两个点，但延迟翻了三倍多。这个数字真实地说明了为什么在System 1决策场景里，Laya是更优的选择——响应速度的差距直接决定了生产环境能不能用。

3. 用LLaMA-Factory对Laya做System 1决策微调

3.1 为什么选LLaMA-Factory而不是从零训练

很多朋友第一次接触微调，脑子里冒出来的念头是“直接源码改模型”。这个思路其实是最绕远路的。LLaMA-Factory是目前主流的微调工具框架，它把数据处理、LoRA注入、训练参数配置、模型评估整合在了一套界面和配置系统里，你不用手写训练循环，也不用自己管梯度累积、学习率调度这些底层细节。

我用LLaMA-Factory跑过Qwen、Llama、Jev和现在的Laya，整体体验下来，它对Laya的适配做得相当到位。新人五分钟就能把一条微调流水线跑起来，老手也能通过它的高级配置做分布式训练。

安装LLaMA-Factory的方式很简单，直接git clone下来再用pip安装。

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

装好之后，它支持两种使用方式：一种是直接跑web UI，在浏览器里点点点；另一种是用命令行脚本，适合批量实验和服务器环境。我建议你两条路都走一遍——先用web UI把数据格式和参数含义摸清楚，再用命令行把训练固化下来。

3.2 数据准备：如何构建System 1决策训练集

微调的成败，80%取决于数据，20%取决于参数。数据这关没学好，后面的训练都是白折腾。

系统1决策任务的特点是：输入短、输出短、决策路径固定。所以训练数据不能用那种长篇章式的对话样本，而是要用大批量的“输入-输出”对，每一对都代表一个独立的决策场景。

我用JSON格式来组织数据，这是LLaMA-Factory的标准输入格式。每条数据包含instruction（指令）、input（输入）、output（输出）三部分。

[ { "instruction": "根据用户描述，判断是否需要升级工单等级，只回答升级或不升级", "input": "客户说服务器完全连不上，业务已经中断三个小时了", "output": "升级" }, { "instruction": "根据用户描述，判断是否需要升级工单等级，只回答升级或不升级", "input": "客户反馈页面加载有点慢，刷新后正常", "output": "不升级" } ]

构建训练集要注意几个关键点：

• 每个类别的样本量要尽量均衡，不要出现一类样本占90%的情况，否则模型学出来的决策边界会严重偏向多数类。
• 样本要有代表性，覆盖各种the edge case。比如“页面加载慢”和“服务器完全连不上”之间其实有很多中间地带，数据里必须包含这些模糊场景。
• 数据量不需要贪多。System 1决策任务往往决策空间有限，几千条高质量样本就足够让模型学会你的业务规则。我常用的量级在3000到8000条之间，关键是质量而不是数量。

数据做好之后，放到LLaMA-Factory的data目录下，并在dataset_info.json里注册一下。这样后面的训练命令就能直接通过数据集名称引用它。

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

注意这里的formatting字段，如果你用的是上面那种instruction/input/output结构，用sharegpt格式就行。如果你的数据是纯对话样式的，可能需要换成alpaca格式。格式注册错了，训练直接报错读不出数据。

3.3 关键参数配置：LoRA秩与学习率的取舍

参数配置是微调里最玄学的部分，但其实核心参数就那么几个。我用表格把我的经验参数列出来，然后逐个解释理由。

关于LoRA秩，我单独说一句。秩决定了低秩分解矩阵的表达能力上限。秩太小（比如4），模型学不到业务规则里的细微差异；秩太大（比如64），在几千条小数据集上几乎必然过拟合。我做过对比实验，同样数据下，r=16的效果要明显好于r=8，而r=32对比r=16的提升已经很小，但显存占用和训练时间却增了。所以r=16是一个性价比很高的平衡点。

学习率这块，2e-4是LoRA微调的标准值，但如果你发现训练loss震荡厉害，可以降到1e-4；如果模型学得慢，loss降不下去，可以提高到3e-4。学习率不是越大越好，太大容易让模型忘了原有的能力，这在领域微调里叫灾难性遗忘，是很现实的问题。

3.4 训练过程实操：命令行跑通微调

数据准备好、参数确定好之后，接下来就是用命令行把训练跑起来。我直接把完整的训练脚本放出来：

cd LLaMA-Factory CUDA_VISIBLE_DEVICES=0,1 nohup llama-factory-cli train \ --model_name_or_path ./Laya-8B-Chat \ --dataset laya_system1 \ --stage sft \ --finetuning_type lora \ --lora_rank 16 \ --lora_alpha 32 \ --lora_target all \ --output_dir ./laya_system1_lora \ --num_train_epochs 3 \ --per_device_train_batch_size 8 \ --gradient_accumulation_steps 2 \ --learning_rate 2e-4 \ --fp16 True \ # 单卡用fp16，多卡用bf16 --logging_steps 10 \ --save_steps 500 \ --save_total_limit 3 \ --warmup_steps 100 \ > train.log 2>&1 &

把训练日志重定向到文件里，然后用tail命令实时盯着进度：

tail -f train.log

正常跑起来之后，你会看到loss逐步下降。我那次训练的loss曲线是：初始loss约1.7，第一个epoch结束时降到0.9，第二个epoch结束时约0.55，第三个epoch结束约0.4。如果你的loss也在这个量级波动，说明训练正常。

需要提醒几个训练中的高频问题：

• 如果loss是NaN或者突然变成几万，基本是学习率过高或者数据里有非法值，先调低学习率。
• 如果loss不降反升，大概率是数据格式不对，比如样本里带上了特殊token却没法被正确截断。
• 如果显存爆了，优先减小per_device_train_batch_size，而不是减小模型尺寸。梯度累积可以补回等效批次大小。

3.5 模型合并与导出：从LoRA权重到完整模型

训练完成后，你得到的不是一个完整的模型，而是一组LoRA适配器权重。它需要和基础模型Laya合并，才能变成一个真正可独立部署的模型文件。

LLaMA-Factory提供了合并命令：

llama-factory-cli export \ --model_name_or_path ./Laya-8B-Chat \ --adapter_name_or_path ./laya_system1_lora \ --template default \ --finetuning_type lora \ --export_dir ./Laya-8B-Chat-System1 \ --export_size 6 \ --export_legacy_format false

合并过程就是把LoRA权重叠加回基础模型的参数里。这一步看着简单，但要注意一点：基础模型的路径和训练时用的一定要一致，包括dtype。我遇到过有人用fp16微调，但合并时基础模型是bf16的，结果合并出来的模型推理结果完全是乱的。

合并完成之后，你可以用前面那段推理代码换上新模型路径，重新跑一下测试集，对比微调前后的准确率和延迟。我微调后的结果是这样的：工单升级判断准确率从85.2%提升到97.8%，延迟基本没变，仍稳定在450ms左右。这说明LoRA微调在不牺牲响应速度的前提下，成功把领域知识注入到了模型里。

4. 量化部署与Ollama集成：把微调模型接入生产

4.1 模型量化：开源框架跑起来之后还需要这个

合并好的模型体积还是有点大，8B级别的fp16模型大约要占用16GB显存，这在生产环境的成本账上不太好看。所以部署阶段，我一般会做一步量化。

主流做法是转成4bit或8bit的GGUF格式。GGUF是llama.cpp体系的标准格式，也是Ollama直接支持的格式，将模型从PyTorch格式转成GGUF可以大幅降低部署门槛。

LLaMA-Factory本身不直接做这种转换，我一般用llama.cpp的转换脚本做。先把合并后的模型转成FP16的GGUF：

python ./llama_cpp/convert_hf_to_gguf.py ./Laya-8B-Chat-System1 \ --outfile ./laya-8b-system1-fp16.gguf --outtype f16

再用量化工具压到4bit：

./llama_cpp/quantize ./laya-8b-system1-fp16.gguf ./laya-8b-system1-q4_k_m.gguf q4_k_m

g4_k_m是一种混合量化策略，算力和显存占用比较均衡，是我在生产环境里用得最多的格式。做量化的时候要注意务必在量化之前先检查fp16版本是否工作正常，否则量化后出了问题，根本分不清是量化丢了精度还是原模型就没调好。

量化后的模型单次推理显存需求可以降到5GB以内，一张普通的消费级显卡就能跑，部署成本低了一个量级。

4.2 在Ollama中加载量化后的Laya

Ollama是目前本地模型部署最省事的方案，它对GGUF格式的支持很完善。把量化好的GGUF文件接进来，只需要写一个简单的模型配置文件。

在Ollama的模型目录下新建一个Modelfile：

FROM ./laya-8b-system1-q4_k_m.gguf PARAMETER temperature 0.3 PARAMETER top_p 0.9 PARAMETER max_tokens 128 PARAMETER stop "<|eot_id|>" TEMPLATE """{{.Prompt }} """

然后运行下面两行命令，就能把模型注册到Ollama里：

ollama create laya-system1 -f Modelfile ollama run laya-system1

这样整个流程就跑通了。微调后的Laya模型以Q4量化格式运行在Ollama上，单机并发能力很好，API调用也简单，接入现有业务系统基本不用写胶水代码。

我的生产实践是在Docker容器里跑Ollama服务，CPU分配了8核、内存16GB、显卡共享一张3090。压测结果：QPS稳定在25左右，单次推理耗时约300ms，相比直接用PyTorch推理，速度快一些且显存占用大幅下降。这套配置跑了两周，没有出现OOM。

4.3 常见问题与排查技巧实录

最后把我在整个过程中踩过的坑整理成一份速查表，基本覆盖了从安装到部署的常见问题。

在这些坑里面，我特别想展开说两个。

第一个是灾难性遗忘。我第一次做Laya微调的时候，只用了3000条领域数据，训了5个epoch，结果模型在领域任务上准确率是上去了，但让它做通用问答就变得语无伦次。后来我在训练集里混入了500条通用对话数据，把训练轮数降到3，情况明显改善。现在做微调，我基本上都会保留5%到10%的通用语料做“记忆锚点”。

第二个是量化档位的选择。q4_k_m能省显存，但如果你处理的任务对输出质量非常敏感，我建议至少用q5或者q6档位。我在一个金融文本分类任务里做过测试，q4_k_m比fp16准确率掉了1.3个百分点，q6_k_m只掉了0.3个百分点。具体选哪一档，就看你对显存和准确率之间的权衡了。

在System 1决策场景里跑Laya微调，整个过程走下来，我最深刻的体会是：模型本身的能力只是起点，工程化细节才是决定落地成败的关键。同样一个模型，数据组织得好不好、LoRA参数有没有踩对、量化档位选得合不合适，最终效果可能差出一大截。

最后再分享一个小技巧：我在做LoRA微调实验时，会用一个固定的评估集，每次训练结束就立刻跑一遍评估集，记录准确率和延迟。这些历史记录就是你的实验“指纹”，回头对比不同超参数时，比看loss曲线直观得多。版本管理上也建议每次训练前把config和数据集备份好，不然隔一个月回来看，你根本记不清当时那个效果好的模型是用什么配置训出来的。