企业官网建设流程全解析

我从一个实际的部署场景说起：早前在做一个本地Agent服务，大量请求要在大模型和小模型之间做路由判断，每次判断都要经过通用大模型走完整推理链，延迟动不动就上800毫秒，一个月下来API账单也压得人头疼。后来换成社区里那个17K Star的开源项目Laya，把System 1决策这类"条件反射级别"的判断任务单独拆出来，延迟直接被砍到几十毫秒，整个Agent链路才真正跑得顺。

这篇文章就把这套完整流程写出来，覆盖Laya的定位、安装部署、微调前的底座选择、System 1决策数据集的构建思路，以及基于LLaMA-Factory做LoRA微调的全过程。适合正在做Agent调度、自动化工作流、本地私有决策服务的人参考，无论你是第一次接触这类模型，还是已经跑过不少微调任务，都可以直接照着我下面的步骤走。

1. 这个17K Star的项目到底解决了什么问题

先别急着敲命令，搞清楚Laya为什么能火到17K Star，比急着装环境更重要。我见过太多人把模型下载下来跑了个demo就搁置了，本质上是没理解这个项目的定位。

1.1 System 1决策和System 2推理，是两种完全不同的需求

认知科学里经常提到双系统理论：System 1是快思考，直觉、条件反射、几乎不消耗认知资源；System 2是慢思考，逻辑推演、深度分析、需要大量计算。放到大模型应用里，这个区分尤其明显。

很多Agent系统在跑的时候，真正高频的调用并不是"帮我写一篇行业分析报告"这种深度任务，而是一连串毫秒级的判断：这个客户问题该走售前流程还是售后流程？这句话表达的是确认意图还是拒绝意图？当前用户的操作上下文应该选择哪条工具调用分支？这些任务的特点是结构固定、语义范围有限、不要求创造性，但要求极低的延迟和极高的稳定性。

拿通用大模型做这些事，等于让一个研究员每天干八千次"是或否"的判断题，慢且贵。之前我用的那个System 1方案，在单机本地跑还是有可观的推理耗时波动，稍微并发一上来就排队，更麻烦的是它需要联网校验密钥，一旦网络抖动，整个决策链路都会卡住。

1.2 Laya的定位：决策前置层，不是通用对话模型

Laya这个项目的核心思路，是把"决策"这件事从通用大模型里剥离出来，做成一个独立的、可本地部署的前置服务。它不追求博学多才，而是专注在意图分类、分支路由、行为选择这类System 1场景，输出格式可以严格对齐到JSON或固定的枚举值。

这带来几个实际好处。第一，推理路径短，响应延迟稳定在很低的水平；第二，模型权重量级可控，单张消费级显卡甚至纯CPU都能跑；第三，它开源可自托管，数据不出内网，对于金融、医疗、企业内部系统这类注重隐私的场景，是决定性的优势；第四，权重可以自己微调，这一点太重要了，后面我会详细展开。

1.3 为什么不继续用曾经的System 1方案

很多人听到"爆打老方案"会觉得是营销话术，但实际对比过的感受非常深。老方案的推理延迟确实不错，但它有几个致命短板：闭源、配置繁琐、密钥管理让人头大、高峰期还会限流。而且它不支持本地微调，你只能靠提示词工程去约束输出格式，这在复杂业务规则下非常痛苦——提示词稍微长一点，延迟就上去了，格式稍微偏一点，下游解析就炸了。

Laya直接绕开了这些问题：模型权重自己拿，LoRA自己训练，服务自己用Ollama或者llama.cpp拉起来，整个链路没有黑盒。对于工程团队来说，"可控"比"某个指标强一点"重要得多。

2. 安装部署：两条路我都走过，建议你这样选

Laya的部署方式不唯一，我先说结论：只想快速跑通效果，用Ollama；要做服务集成、精细控制并发和量化策略，用llama.cpp。两条路我都实际跑过，下面把关键步骤和坑都列出来。

2.1 环境准备：先确认你的硬件底线

在动手之前，先摸清自己的家底。部署Laya的原始权重其实门槛不高，但不同运行方式对资源的要求差异很大。

我用的测试机是单张RTX 4090 24GB，内存32GB。实际上，如果你只是跑Laya的量化版本做推理，8GB显存的显卡就够用；如果要微调，那需要单独考虑，这个后面专门讲。先把基础软件装上：

# 以Ubuntu 22.04为例 sudo apt update && sudo apt install -y git curl wget python3-pip # Ollama安装，一条命令搞定 curl -fsSL https://ollama.ai/install.sh | sh # 验证 ollama --version

这里有个容易忽略的点：ollama默认会把模型放在用户目录下，如果你的系统盘空间不大，建议提前设置模型存储路径，不然几十GB的模型文件分分钟把根目录塞满。

# 设置ollama模型存储位置到独立数据盘 export OLLAMA_MODELS=/data/ollama/models # 如果要长期使用，写入到环境变量文件里 echo 'export OLLAMA_MODELS=/data/ollama/models' >> ~/.bashrc

2.2 路线A：Ollama拉起Laya，最快看到效果

Ollama的优势是封装完善，拉取模型、起服务、调用API都是标准化的。用Ollama把Laya跑起来之后，它默认监听的11434端口会提供一个和通用模型接口一致的API，方便得很。

假设你已经找到了对应的模型标识，拉起服务的流程是这样的：

# 拉取Laya模型，这里以laya:latest为例 ollama pull laya:latest # 先直接试一句话看看输出 ollama run laya:latest "用户说：我要退款。请判断意图类型，输出JSON。" # 如果要让服务常驻，供外部API调用 ollama serve

这里我强烈建议根据你的场景写一个Modelfile，把推理参数固定下来。System 1决策最怕模型自由发挥，温度必须压低，上下文长度也要控制好，否则延迟会明显上升。

# Modelfile FROM laya:latest # 决策场景：低温度，高确定性 PARAMETER temperature 0.1 PARAMETER top_p 0.9 PARAMETER num_ctx 2048

保存为Modelfile后执行：

ollama create laya-decision -f Modelfile ollama run laya-decision "用户说：我要退款。请判断意图类型，输出JSON。"

2.3 路线B：llama.cpp编译部署，适合精细控制

如果你的应用场景需要更细的并发控制，或者想把模型集成进已有的C++/Python服务进程里，llama.cpp是更可靠的选择。它的社区维护活络，量化格式也全。

# 克隆llama.cpp并编译 git clone https://github.com/ggerganov/llama.cpp cd llama.cpp cmake -B build -DCMAKE_BUILD_TYPE=Release cmake --build build --config Release -j # 把模型权重转成GGUF格式（如果拿到的是原始权重） python3 convert_hf_to_gguf.py /path/to/laya-model --outfile laya-q8_0.gguf --outtype q8_0 # 启动server模式，指定端口 ./build/bin/llama-server -m laya-q8_0.gguf --port 8080 --host 127.0.0.1 -c 2048 --temp 0.1

llama.cpp的server模式自带一个OpenAI兼容的API接口，下游调用非常顺畅。这个方案在吞吐量和稳定性上比Ollama稍微强一点，代价是配置和理解成本更高。

2.4 部署完先别跑业务，做一个延迟与格式压测

不管用哪条路线，部署完成后的第一件事不是接业务，而是做一次简单的压测，把延迟基线和输出格式稳定性摸清楚。下面这段Python脚本可以用起来：

import json import time import requests url = "http://localhost:11434/api/generate" prompt = "用户说：我要改收货地址。请判断意图类型，输出JSON。" payload = { "model": "laya-decision", "prompt": prompt, "stream": False, "options": {"temperature": 0.1} } times = [] ok_format = 0 total = 50 for _ in range(total): start = time.time() resp = requests.post(url, json=payload) elapsed = (time.time() - start) * 1000 times.append(elapsed) try: result = json.loads(resp.json()["response"]) ok_format += 1 except json.JSONDecodeError: pass print(f"平均延迟: {sum(times)/len(times):.0f} ms") print(f"格式合规率: {ok_format/total*100:.0f}%")

我自己的要求是：平均延迟在80ms以内，格式合规率不低于95%。如果这两项不达标，先不要进入微调环节，优先排查是不是端口配置、量化等级或者上下文长度的问题。

3. 微调前的三个关键决策：基座、框架、量化

Laya本身是一个开箱即用的模型，但如果你想让它贴合自己的业务决策规则，微调是最好的路径。不过一上来就开训，十有八九要翻车。我在微调前踩过不少坑，总结下来就三个关键决策：选基座、选框架、定量化方案。

3.1 基座模型：为什么绕不开Qwen系

Laya的权重虽然可以直接用，但做LoRA微调时，社区主流的做法是回到通用基座模型上进行训练，再把训练好的LoRA适配层迁移到实际部署中。这个路径绕不开Qwen系列，原因很简单：中文能力强、社区生态活跃、在LLaMA-Factory里支持得最完善。

选7B还是14B，取决于你的决策任务复杂度。我自己的测试结论是：纯意图分类、工具路由这类结构化程度高的任务，7B和14B的效果差距不大，但7B的推理延迟明显更友好；如果决策任务需要阅读理解一段上下文再做判断，14B会更稳。至于3B这种小模型，适合极轻量的场景，比如单纯的开关判断，再复杂的规则就吃力了。

在拉取基座的时候，我建议用指令微调版本，别用Base版本。System 1决策本质上是"听懂指令并输出结构化结果"，Instruct版本本身已经学会了人类偏好的输出模式，在这个基础上做LoRA微调，收敛快、效果好。

3.2 微调框架：LLaMA-Factory为什么是主流选择

微调框架的生态，LLaMA-Factory现在基本算事实标准了。它支持LoRA、QLoRA、全量微调等多种方案，内置了多种数据集格式解析，还带WebUI，对不习惯纯命令行操作的人非常友好。

选LLaMA-Factory有几个实际考量：一是数据集注册机制清晰，改一个JSON文件就能挂载新数据；二是训练指标可视化做得到位，loss曲线、学习率变化一目了然；三是导出和适配做得好，训练完的LoRA权重可以一键合并回基座，还能直接转成Ollama能吃的GGUF格式。

对比之下，其他框架各有各的别扭：有的只支持自家模型格式，有的数据集格式要求严格，有的社区不活跃出了问题没人答。LLaMA-Factory的Github仓库活跃度很高，遇到报错基本能搜到解决方案，这对实战来说太重要了。

3.3 显存预算：LoRA加4bit量化是性价比之王

微调Laya这类决策模型，显存是主要约束条件。全量微调7B模型，24GB显存勉强够用，但要处理长上下文就比较紧张。LoRA加4bit量化（QLoRA）是我最推荐的方案：效果接近全量微调，显存占用却只有三分之一左右。

大致的显存估算可以参考：7B模型用4bit量化加载，基础占用约5GB，加上LoRA层参数量、梯度、优化器状态和激活值，推荐至少12GB显存。如果你只有8GB显存，可以把LoRA的秩降低、减少batch size，或者换成3B基座。

我个人经验：优先保证能跑通，再考虑效果调优。先小batch跑一个极短的训练，确认显存不会爆掉，再逐步加大参数量。

4. System 1决策数据集：别急着爬数据，先把Schema定好

数据集是微调的命脉。很多人一上来就到处找现成的意图分类数据集，结果拿回来发现和业务场景完全对不上。决策任务的微调，最好的数据来源是你自己系统中的历史日志。在整理数据之前，先把Schema定好，这比数据量重要得多。

4.1 决策数据的灵魂：输入状态加候选动作，输出决策值

System 1决策任务的数据长什么样？它和普通对话数据有本质区别。普通对话数据是开放式的你问我答，决策数据则是结构化的"状态到动作"映射。

一条标准的决策训练样本应该包含三个部分：当前的状态描述（用户输入、上下文摘要、可用的动作列表），期望的决策输出（选哪个动作、判断什么意图、输出什么结构化字段）。这个结构越固定，模型学得越快，推理时也越稳定。

我踩过的坑是：早期想当然地构造了开放式数据，让模型自己写判断理由。结果训练出来的模型输出又臭又长，延迟直接翻倍。后来改成严格的JSON输出约束，才把问题解决掉。

4.2 用Alpaca格式组织数据，LLaMA-Factory直接认

LLaMA-Factory支持的数据格式有好几种，用下来最顺手的是Alpaca三列格式。每条样本就是instruction、input、output三个字段，清晰直接。

下面是一个实际可用的决策样本示例，场景是电商客服系统的意图判断：

{ "instruction": "你是一个客服意图判断器。仅输出JSON，格式为{\"intent\": \"\"}，intent只能是：退款、改地址、催发货、咨询、投诉、其他。不要输出任何解释。", "input": "用户说：你们到底发不发啊，都三天了一点消息没有，再不发货我就退货了！", "output": "{\"intent\": \"催发货\"}" }

注意看这里有几个细节。第一，指令必须把输出格式完全锁死，连字段名都写明白，不给模型任何自由发挥空间；第二，输入文本要尽量贴近线上真实数据，不要人工润色得太干净，带点口语化、带点情绪反而更真实；第三，输出必须严格遵循格式。

4.3 数据量：300到1000条足够，重点是类别均衡

很多人的误区是数据越多越好，动辄想攒几万条。对于System 1决策任务，我认为300到1000条高质量样本就够用了。原因是决策任务的模式有限，模型基座本身已经具备语言理解能力，你只是在教它"什么样的输入对应什么样的输出结构"，不需要太多样本也能学会。

真正要花心思的是类别均衡。假设你有八个意图类别，其中"咨询"类占了80%，训练出来的模型对"咨询"特别敏感，碰到其他类别的输入也往"咨询"里塞，准确率惨不忍睹。

我的处理办法是：统计每个类别的样本数量，以最少的类别为基准做下采样，或者对少数类做轻微的重复采样。目标是最多类别样本数不超过最少类别的三倍。

4.4 清洗与质检：低质量数据比少量数据更可怕

数据质量的把控，我用了一套很笨但很可靠的办法。第一步，把历史日志里的长对话截断到两三轮以内，只保留和决策直接相关的信息；第二步，用脚本去重，完全相同的输入只留一条，避免模型过度拟合重复模式；第三步，人工抽检200条，看标签是否合理。

还有一个我后来才意识到的问题：如果输入文本里含有大量HTML标签、特殊符号、或者超长的商品描述，模型在微调时会把注意力浪费在这些噪音上。对于决策任务，我会对输入做一次清理，把和决策无关的冗余信息摘掉，只保留核心内容。

5. LLaMA-Factory微调实战：从安装到LoRA训练全流程

数据集准备好之后，就可以进入正式的训练环节了。我以LLaMA-Factory为例，把从安装到训练、导出、重新部署的完整链路写出来，你可以直接照着敲。

5.1 安装LLaMA-Factory并挂载自己的数据集

LLaMA-Factory的安装很标准，用conda建一个干净的环境最稳妥，避免和其他项目的Python依赖打架。

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

数据集的挂载很简单：把你的数据文件（比如叫decision_data.json）放进LLaMA-Factory的data目录，然后在data/dataset_info.json里注册一份。注册格式是：

{ "decision_data": { "file_name": "decision_data.json", "formatting": "alpaca", "columns": { "prompt": "instruction", "query": "input", "response": "output" } } }

5.2 LoRA参数配置：先跑通再调优

训练参数我分两步走：第一步用保守参数跑通流程，第二步再针对效果调优。下面是常见的LoRA训练启动命令，用LLaMA-Factory可以直接命令行执行：

llamafactory-cli train \ --model_name_or_path Qwen/Qwen2.5-7B-Instruct \ --dataset decision_data \ --template qwen \ --finetuning_type lora \ --output_dir ./lora-decision \ --num_train_epochs 3 \ --per_device_train_batch_size 2 \ --gradient_accumulation_steps 8 \ --learning_rate 2e-4 \ --lr_scheduler_type cosine \ --lora_rank 16 \ --lora_alpha 32 \ --lora_dropout 0.05 \ --logging_steps 10 \ --save_steps 100 \ --quantization_bit 4

解释几个关键参数。lora_rank 16是最常见的默认值，它决定了低秩矩阵的维度，越大则模型适应能力越强，但显存占用和过拟合风险也越高。lora_alpha 32是缩放系数，一般设为rank的两倍。learning_rate 2e-4对于LoRA来说是标准范围，太低收敛慢，太高容易训坏底座。

第一次训练建议epoch设3就够了，决策任务数据量少，训练几轮模型就能很好拟合。观察loss曲线，如果在第2个epoch以后loss还在明显下降，可以适当增加epoch；如果loss已经走平甚至回升，说明开始过拟合了。

5.3 训练过程中的监控与常见报错

训练一旦跑起来，重点看两个指标：loss值和显存占用。loss应该平稳下降，最终收敛在一个较低水平；显存占用如果超过了显卡上限，会直接OOM中断。

我遇到的几个高频问题这里一并列出来：

• 报错CUDA out of memory：先把per_device_train_batch_size降到1，gradient_accumulation_steps提到16或32，等效batch不变但显存压力大幅降低。
• 报错KeyError: 'instruction'：几乎都是dataset_info.json的columns字段和实际数据字段名对不上，仔细检查大小写。
• loss不降或者震荡：大概率是学习率太高或者数据里有大量冲突标签，先调低学习率到1e-4，再检查数据。

5.4 合并LoRA权重并转回Ollama可用的GGUF

训练完成后，LoRA适配层只是独立文件，要部署必须把它合并回基座模型。LLaMA-Factory也提供了现成的导出命令：

llamafactory-cli export \ --model_name_or_path Qwen/Qwen2.5-7B-Instruct \ --adapter_name_or_path ./lora-decision \ --template qwen \ --finetuning_type lora \ --export_dir ./merged-decision-model \ --export_size 4 \ --export_legacy_format false

合并完成后，如果要接入Ollama，需要把Hugging Face格式的模型转成GGUF。最省事的方式是用ollama直接导入，新版ollama已经支持从Hugging Face模型直接创建：

# 在ollama中创建自定义模型 ollama create laya-ft -f Modelfile # Modelfile内容指向合并后的模型路径 # FROM ./merged-decision-model

ollama create会自动处理模型转换和量化。转换完成后再用我前面写的压测脚本跑一遍，对比微调前后的延迟和格式合规率，心里就有底了。

6. 实测效果与调优：微调后的System 1决策模型要怎么调

模型训练完、部署完，只是开始。真正的工程考验在测试阶段。我这里分享一套我在实际项目里用的效果评估和调优方法，以及遇到的几个典型问题。

6.1 用混淆矩阵评估决策准确率，别只看整体准确率

决策任务最常见的评估误区是只看整体准确率。假设你的任务里"其他"类别占了七成，模型啥也不干全输出"其他"，准确率也有70%，看起来好看，实际一点用没有。

我习惯把测试集按类别切好，单独计算每个类别的准确率和召回率，并画一个混淆矩阵。重点关注哪些类别经常被混淆。比如"退款"和"投诉"经常混在一起，是因为用户说"再不给退我就投诉"，这种情况就要回头检查训练数据里这类边界样本够不够，或者考虑合并类别。

下面是我微调前后的一组典型效果对比：

格式合规率的大幅提升，是我觉得最有价值的部分。微调前模型偶尔会输出多余的解释文字，导致JSON解析直接抛异常；微调后输出结构稳定了，下游解析逻辑也省心了很多。

6.2 微调后的常见怪病：过拟合、温度失控、上下文污染

实操中我遇到几个很典型的"怪病"，在这里集中说一下。

第一个是过拟合导致的"背题"现象。训练样本里如果某几个句式出现特别频繁，模型会把句式当成决策依据，而不是理解语义。表现就是：换一种表达方式，同样意思的话，它反而不认识了。解决办法是数据增强，把每条样本改写几个同义版本，同时严格控制重复数据。

第二个是温度设置失控。很多人微调完部署时，沿用通用对话模型的Temperature设置，比如0.7甚至更高，结果决策输出飘忽不定，同一个输入两次调用给不同结果。决策模型温度一定要低，我固定用0.1，最多不超过0.2。

第三个是上下文污染。决策模型只需要看当前状态，不需要长篇历史对话。如果系统把前面十轮对话全塞进上下文，模型不仅变慢，还容易被无关信息干扰。解决方法是把上下文裁剪到和目标判断最相关的几轮，多余信息宁可丢掉。

6.3 把微调后的决策模型真正嵌入Agent工作流

最后聊一下整个链路打通后的架构感受。我现在的Agent系统不再把所有请求都丢给大模型了，而是先用Laya微调出来的决策模型做意图判断和分支路由，只有真正需要深度推理的请求才升级到通用大模型。

这个架构调整完之后，整体系统吞吐量翻了接近三倍，单次请求平均成本下降了一大截，而且决策部分因为是本地私有部署，完全没有网络波动风险。之前最担心的"密钥过期""限流"这类问题，也彻底不存在了。

我个人在实际操作中最深的体会是：System 1决策模型的价值，不在于它本身多聪明，而在于它让整个系统有了清晰的分层。快速判断交给轻量模型，深度思考交给重型模型，各司其职，整个系统才又稳又快。另外再分享一个小技巧：当你的决策任务范围变化时，不要推翻整个模型重新训练，只需要在原有LoRA基础上叠加一个小规模增量数据集，用较小的学习率继续训练一两轮，就能快速适配新规则，成本极低。