如果你最近在搞Agent、自动化决策或者工具调用路由这类东西应该已经感觉到圈子里最近的一个明显风向大家不再盲目追求“什么事都丢给大模型做长思考链”而是把决策拆成快慢两条链路该快的快该慢的慢。Jev在这个话题下一直是常客斯坦福那边有人拿它构建数据系统也有人把它嵌进Codex的Agent里做路由决策。但我自己实际跑了一阵子之后反而被一个叫Laya的开源项目勾住了。17K Star主打System 1决策宣传点很直接安装、微调、部署一条龙专门做低延迟决策。花了一个周末从零开始走完这套流程说实话在不少决策子任务上它的体验确实能“爆打”Jev——不是全面碾压而是在延迟、成本、可控性这几个关键维度上Laya更对我的胃口。这篇文章就把我整个操作链路由完整分享出来包括环境准备、安装、数据整理、微调、部署以及踩过的坑给想做同类事情的人一个能直接抄的作业。1. Laya凭什么敢说“爆打Jev”先看两个模型的定位差异1.1 心理学概念的工程化System 1决策到底在解决什么System 1和System 2最早是心理学里对人类认知模式的划分一个形容“快思考”一个形容“慢思考”。放到大模型应用里这个类比非常贴切System 2对应那种会做长推理、斟酌半天才给出答案的模型适合数学题、复杂代码、多步规划System 1则对应“看一眼就能给判断”的能力适合意图分类、工具选择、路由判断、关键字段抽取、内容初筛这类任务。关键在于这类决策任务其实占了线上请求的大头。一个Agent从接收用户问题到执行动作中间可能要做三四次判断该用哪个工具、传给哪个下游、要不要追问。这些判断如果全部交给带思维链的大推理模型延迟和成本都会迅速失控。我之前在项目里试过把路由判断交给Jev质量确实可以但单次调用动不动就是几百毫秒高峰期token费用看得肉疼。这也是System 1模型被单独做出来的原因——它不追求“想得深”只追求“想得快、想得准”。1.2 Jev的强项与软肋Jev走的是典型的闭源API路线官网申请密钥之后用在线接口调用还集成了不少Agent工作流比如有人把它用在Codex的辅助决策里。这种方式最大的优点是省心服务质量稳定数据集也打磨得不错斯坦福教授拿它搭建数据系统就是个例子说明它的水平是经过真实生产环境验证的。但软肋也很明显第一数据要送到厂商那边隐私要求高的场景直接劝退第二按token付费决策量大一个月的账单非常难看第三自定义微调基本只能走厂商托管路线用户拿不到完整权重想要在私有环境或者离线环境部署是不可能的。对于只做一次性调用的人来说无所谓但如果你想把决策模型嵌进自己的产品里这三条条条都是硬伤。1.3 Laya的开源路线如何补上System 1的空缺Laya能拿到17K Star我觉得本质上是“大家确实需要这么一个东西”。它定位很明确完全开源、本地可部署、能微调、显存要求不高、专门优化System 1类决策任务。从社区反馈看很多人跟我一样不是不需要决策模型而是不想被闭源API绑死。所以“爆打Jev”这个说法准确理解是在特定决策赛道上Laya以更低的综合成本跑出了不输Jev的效果。它不追求在所有任务上碾压而是在“快决策”这个细分场景里做到了更开放、更可控。如果你有几十万条决策记录想要微调一个真正属于自己的路由模型Laya是比Jev更合适的起点。2. 安装前必须补齐的环境基础Python/Git/GPU三件套2.1 用虚拟环境隔离Python版本很多人拿到项目第一件事就是pip install结果装到一半发现系统Python里已经有一堆其他包版本冲突直接把人整崩溃。我的建议是项目开始之前就建好虚拟环境最省力的是Anaconda或者Minicondaconda create -n laya python3.11 -y conda activate layaLaya对Python版本的要求大概是3.10到3.12之间我用的3.11没有问题。之所以强调要虚拟环境是因为PyTorch、transformers这些依赖对版本非常敏感全局环境只要有一个包的版本不对你的训练可能就会在某个深夜报出一堆莫名其妙的ModuleNotFoundError。每换一个项目就建一个干净环境看起来多花两分钟实际省下的是后面几小时的排错时间。2.2 Git配置别只停在“装完”有些人电脑上装了Git就觉得万事大吉真正clone仓库或者推送代码的时候才发现根本没配置身份信息。先把这两行做了git config --global user.name 你的用户名 git config --global user.email 你的邮箱另外Windows用户建议装上Git后把core.autocrlf设为input避免跨平台换行符问题git config --global core.autocrlf input这块不配置好最大的坑是clone下来没什么事但你自己的数据文件送入训练脚本时可能莫名其妙多出\r字符数据加载报错的时候你很难第一时间想到是换行符在捣鬼。2.3 GPU显存预算先算账再动工不论安装还是微调显存都是第一道门槛。以7B量级的模型为例大致对应关系如下微调方式基础模型精度7B级别所需显存适合场景全参微调FP1660GB以上不推荐单卡基本跑不动LoRA微调FP16约24GB一张4090级显卡的舒适区LoRA微调4bit量化约12GB3060 12G这种入门卡也能跑估算逻辑很简单模型权重占了基础、LoRA存的是少量适配器参数、优化器状态和中间激活值另外计算。全参微调之所以要那么多显存是因为梯度也要按全量参数存。LoRA只更新一小部分参数显存压力瞬间降了一个量级。所以如果你只有一块16G显存的卡老老实实走量化版LoRA就行。3. Laya安装实战从拉取仓库到跑通第一个决策3.1 拉取仓库与依赖安装环境就绪后直接进入正题。假装你已经建好并进入了laya这个虚拟环境git clone https://github.com/你的目标仓库地址/laya.git cd laya pip install -r requirements.txt仓库地址我不写死因为这个项目仓库和HuggingFace上的模型可能后续会调整你直接在GitHub上搜Laya、关注度最高的那个仓库就是。依赖安装过程里最容易出问题的就是Python版本和PyTorch版本的匹配。如果你装了CUDA版PyTorch装之前先确认一下你的显卡驱动版本然后在PyTorch官网找到对应命令安装。这一步别偷懒直接pip install torch这种通用命令很可能会装上CPU版训练速度直接慢十倍以上。3.2 权重获取的两种路径代码clone下来只是第一步模型权重一般放在HuggingFace或者ModelScope上需要单独下载。如果直接下载速度不理想建议优先用ModelScope国内访问稳定很多。下载完成后把模型目录解压放好比如统一放在项目的model目录下。如果你有离线环境部署的需求办法也很简单在一台能联网的机器上下好整个模型目录打包拷到目标机器上只要目录结构完整代码读取不会有任何问题。这个细节对大企业项目特别实用因为生产服务器往往不直接连外网离线部署能力本身就是开源模型的优势之一。3.3 第一次System 1决策调用温度设0依赖和权重都就绪后先做一次简单的决策调用验证。以工具选择为例给定用户意图和候选工具列表要求模型输出一个工具ID。可以写这样一个推理脚本from transformers import AutoModelForCausalLM, AutoTokenizer model_path model/Laya-base tokenizer AutoTokenizer.from_pretrained(model_path) model AutoModelForCausalLM.from_pretrained(model_path, trust_remote_codeTrue).cuda() prompt 请根据用户意图从候选工具中选择最合适的一个只输出工具ID。 用户意图我要把刚才那段录音转成文字 候选工具 1. speech_to_text 2. translate 3. text_summary 输出 inputs tokenizer(prompt, return_tensorspt).to(cuda) out model.generate(**inputs, max_new_tokens16, temperature0.0, do_sampleFalse) print(tokenizer.decode(out[0], skip_special_tokensTrue))两个关键点一是temperature一定要设0System 1决策场景要的是确定性输出随机性在这种地方是灾难二是max_new_tokens不要给大决策答案通常就几个字懒模型才能快。我第一次跑的时候给的是64个token结果模型有时候会把理由也一起输出解析起来要多写不少代码。后面我统一压到16反而又准又稳。如果这一步能稳定输出正确工具ID说明Laya已经跑通了接下来才能考虑微调。4. 微调前的三张关键底牌数据设计、框架选型、参数预算4.1 什么数据适合喂给System 1模型很多人一上来就到处找微调数据集其实最适合System 1决策模型的数据就是你自己业务里的决策日志。这类数据有两个特征输入是场景描述候选集合输出是唯一确定的决策结果不要求长推理。举个例子一条典型训练样本长这样{ instruction: 根据用户意图从候选工具中选择最合适的一个只输出工具ID。, input: 用户意图把明天上午的会议时间同步给同事\n候选工具calendar_book, calendar_query, email_send, output: calendar_book }注意千万不要把带思维链的数据混进去。我见过有人拿推理类数据去微调决策模型结果模型学会了输出大段分析和步骤单次响应时间从200毫秒涨到2秒完全违背了System 1的初衷。决策数据就要干净利落输入短、输出更短。4.2 主流微调框架怎么选我为什么一直推LLaMA-Factory现在做模型微调的框架不少主流的几个我简单列过使用感受框架上手难度灵活性功能完整度我的建议原生transformers脚本高高低全靠自己写不建议新手FIRM之类轻量封装中中中可以了解LLaMA-Factory低中高UICLI齐全首选LLaMA-Factory最讨喜的地方是开箱即用内置了LoRA、QLoRA、全参微调等多种方案数据格式转换都是现成的训练日志和评估工具也齐全。你不需要从零写一个训练循环只需要把自己的数据转成它支持的格式配好参数就能跑。我后来所有微调任务包括公司内部几个垂直模型都是在这上面做的。没特殊需求的话直接用它省钱省到头。4.3 LoRA参数与显存的对应关系LoRA本质上是用两个低秩矩阵去近似权重的更新量所以参数选择直接决定训练成本和效果参数我的经验值说明r8-16太小学不住太大学不过来alpha32一般是r的2倍左右lora_dropout0.05防过拟合别太大target_modules全部关键投影矩阵让LoRA覆盖更多参数组合经验原则是数据量少就选r8数据量大且任务复杂就用r16起步。alpha通常设为r的两倍比如r16时alpha32这个组合在大多数场景下都不会出大错。显存方面FP16权重的7B模型LoRA训练大概需要24G显存如果只是4bit量化版12G的显卡也能勉强跑起来。参数不要贪大LoRA的意义是用小成本把模型“调”成你要的样子不是把模型塞满知识。5. 端到端微调实战把Laya改造成你的“决策专用脑”5.1 从业务日志到Alpaca格式LLaMA-Factory支持Alpaca格式核心是instruction、input、output三个字段。假设你手里有一份原始的决策日志里面记录着每次请求的query、候选工具列表和最终选中的工具ID可以用一个简单的Python脚本批量转换import json raw json.load(open(decision_logs.json)) examples [] for log in raw: examples.append({ instruction: 根据用户意图从候选工具中选择最合适的一个只输出工具ID。, input: 用户意图 log[query] \n候选工具 json.dumps(log[tools], ensure_asciiFalse), output: log[selected_tool] }) with open(laya_decision.json, w, encodingutf-8) as f: json.dump(examples, f, ensure_asciiFalse, indent2)转换好的文件放到LLaMA-Factory的data目录下然后在dataset_info.json里登记一下加载的时候就能按名字直接用了。我个人的习惯是留出5%到10%的样本不进入训练集作为最后的验证集专门用来测模型的泛化能力。5.2 训练命令逐参数拆解数据和框架准备好之后就是训练这个核心动作。我用的是LLaMA-Factory的命令行接口整个训练命令如下llamafactory-cli train \ --model_name_or_path model/Laya-base \ --dataset laya_decision \ --template qwen \ --finetuning_type lora \ --lora_rank 16 \ --lora_alpha 32 \ --lora_dropout 0.05 \ --target_modules q_proj,k_proj,v_proj,o_proj,gate_proj,up_proj,down_proj \ --output_dir lora_laya \ --per_device_train_batch_size 4 \ --gradient_accumulation_steps 4 \ --learning_rate 2e-4 \ --num_train_epochs 3 \ --lr_scheduler_type cosine \ --warmup_ratio 0.05 \ --fp16几个容易出错的点说明一下template参数要和底座模型匹配我用的Laya是基于Qwen架构微调过的所以填qwen。batch_size要根据显存调整如果你的显存不够先把per_device_train_batch_size降到2或者用gradient_accumulation_steps把等效batch补回来。learning_rate用2e-4是LoRA场景的标准做法太大容易训飞。训练多少个epoch不是越多越好我见过很多人跑50个epoch然后模型只会背答案3轮左右在决策任务上通常足够。5.3 训练后的验收标准别只盯着loss训练结束后我建议先看三样东西训练loss、验证集准确率、以及完全不训练的“陌生样本”表现。Loss下降说明模型在拟合训练集但拟合不等于泛化。之前我帮朋友调一个工具路由模型训练效果看起来很好loss降到0.3以下但拿全新场景一测准确率只有六成多原因就是训练集太单一模型只会背固定的几种工具组合。我自己常用的验收方式是分两步第一步用LLaMA-Factory自带的eval工具跑验证集准确率第二步手写几条业务中最常见的、但训练集里没有的原样组合直接测模型输出。两条都过了再去谈部署上线不然微调就是自欺欺人。6. 合参、量化与System 1决策部署6.1 LoRA合回底座并导出微调产物只是一组LoRA适配器真正的部署需要把适配器合并回底座模型导出成一个独立可用的模型目录。LLaMA-Factory做这件事非常省事llamafactory-cli export \ --model_name_or_path model/Laya-base \ --adapter_name_or_path lora_laya \ --template qwen \ --finetuning_type lora \ --export_dir model/Laya-decision \ --export_size 4 \ --export_legacy_format falseexport_size这里是指导出参数的精度4就是4bit量化。如果你对延迟极其敏感比如单次决策必须在100毫秒内完成那就用4bit导出体积小、推理快。如果你的机器显存充裕需要更稳定的精度可以导出成FP16准确率更高但显存占用也更大。6.2 在线服务的延迟调优部署方案我推荐两个吞吐优先用vLLM部署简单优先用Ollama。两者对比方案延迟表现部署复杂度适用场景vLLM高吞吐批量推理强中等需要一点配置生产环境高并发Ollama单请求延迟低极简内网工具、小规模服务System 1决策场景里有个细节经常被忽略模型本身的推理时间只占一部分真正拖慢响应的是请求排队和解析逻辑。所以除了选对推理框架还要在接口层做优化比如把输入的prompt模板固化成字符串不要在每层请求里重复拼接把temperature锁死在0保证输出稳定max_tokens压到16到32避免产生大量无关输出。这些加起来对延迟的优化效果往往比换一个更大的GPU还明显。6.3 一个可上线的决策调用实战样例我习惯把决策服务封装成一个简单的HTTP接口方便上游Agent调用。下面是基于vLLM的一个最小实现思路from vllm import LLM, SamplingParams llm LLM(modelmodel/Laya-decision, tensor_parallel_size1) params SamplingParams(temperature0.0, max_tokens16) def make_decision(user_intent, tool_list): prompt ( 根据用户意图从候选工具中选择最合适的一个只输出工具ID。\n f用户意图{user_intent}\n f候选工具{tool_list}\n输出 ) outputs llm.generate([prompt], params) result outputs[0].outputs[0].text.strip() return result接口层可以再包一层FastAPI逻辑就是收到请求后调用make_decision拿到结果后做一次白名单校验确保输出确实落在候选工具ID集合里如果不在就返回一个默认兜底值。这个兜底设计很重要System 1决策模型哪怕再准也会有极端输入导致乱输出绝不能让它把工具路由调用到一个不存在的ID上。7. 我踩过的坑与最后的实话7.1 三个让我浪费过时间的坑第一个坑是tokenizer版本不匹配。模型和tokenizer分别从不同地方下载版本没对齐推理时输出一堆乱码当时我还以为是模型坏了排查了半天才发现是tokenizer和模型权重版本不一致。后来我每次下载权重都强制检查配置文件里的版本号。第二个坑是训练数据里混进了带长推理的样本导致模型开始“话痨”输出稳定在几百token。这事发生在我调一个客服意图分类模型的时候本来几轮的决策微调模型却学会了把判断理由也说出来。后来我写了一个数据清洗脚本把output长度超过20个字符的样本全部踢掉才把问题解决。第三个坑是评估时用聊天模板不一致。同一个模型训练时用qwen模板评估时却用了默认模板结果准确率看起来低了十几个点。后来我固定了一套模板训练、评估、部署全程使用同一个才得到真实可信的结果。7.2 什么任务不该用System 1决策模型Laya的强项是快决策但“快”是有代价的。多步数学推理、复杂逻辑判断题、需要详细解释结果的场景系统还是交给系统2模型的比较好。另外如果你对结果的错误率是零容忍的比如医疗诊断、金融风控里那种不允许模型直接拍板的环节System 1模型只能作为初筛不能当作最终答案。我这段时间用下来的真实感受是Laya的价值不在于替换掉所有模型而是帮你把系统里那些大量重复、高频低难度的决策从“贵而慢”变成“便宜且稳定”。线性规划的比喻可能不太恰当反正就是别拿大炮打蚊子也别指望一把小刀能砍树。明白自己的场景需要什么选对工具微调好它比盲目追新模型重要得多。
Laya实战：基于System 1决策的低延迟模型微调与部署
如果你最近在搞Agent、自动化决策或者工具调用路由这类东西应该已经感觉到圈子里最近的一个明显风向大家不再盲目追求“什么事都丢给大模型做长思考链”而是把决策拆成快慢两条链路该快的快该慢的慢。Jev在这个话题下一直是常客斯坦福那边有人拿它构建数据系统也有人把它嵌进Codex的Agent里做路由决策。但我自己实际跑了一阵子之后反而被一个叫Laya的开源项目勾住了。17K Star主打System 1决策宣传点很直接安装、微调、部署一条龙专门做低延迟决策。花了一个周末从零开始走完这套流程说实话在不少决策子任务上它的体验确实能“爆打”Jev——不是全面碾压而是在延迟、成本、可控性这几个关键维度上Laya更对我的胃口。这篇文章就把我整个操作链路由完整分享出来包括环境准备、安装、数据整理、微调、部署以及踩过的坑给想做同类事情的人一个能直接抄的作业。1. Laya凭什么敢说“爆打Jev”先看两个模型的定位差异1.1 心理学概念的工程化System 1决策到底在解决什么System 1和System 2最早是心理学里对人类认知模式的划分一个形容“快思考”一个形容“慢思考”。放到大模型应用里这个类比非常贴切System 2对应那种会做长推理、斟酌半天才给出答案的模型适合数学题、复杂代码、多步规划System 1则对应“看一眼就能给判断”的能力适合意图分类、工具选择、路由判断、关键字段抽取、内容初筛这类任务。关键在于这类决策任务其实占了线上请求的大头。一个Agent从接收用户问题到执行动作中间可能要做三四次判断该用哪个工具、传给哪个下游、要不要追问。这些判断如果全部交给带思维链的大推理模型延迟和成本都会迅速失控。我之前在项目里试过把路由判断交给Jev质量确实可以但单次调用动不动就是几百毫秒高峰期token费用看得肉疼。这也是System 1模型被单独做出来的原因——它不追求“想得深”只追求“想得快、想得准”。1.2 Jev的强项与软肋Jev走的是典型的闭源API路线官网申请密钥之后用在线接口调用还集成了不少Agent工作流比如有人把它用在Codex的辅助决策里。这种方式最大的优点是省心服务质量稳定数据集也打磨得不错斯坦福教授拿它搭建数据系统就是个例子说明它的水平是经过真实生产环境验证的。但软肋也很明显第一数据要送到厂商那边隐私要求高的场景直接劝退第二按token付费决策量大一个月的账单非常难看第三自定义微调基本只能走厂商托管路线用户拿不到完整权重想要在私有环境或者离线环境部署是不可能的。对于只做一次性调用的人来说无所谓但如果你想把决策模型嵌进自己的产品里这三条条条都是硬伤。1.3 Laya的开源路线如何补上System 1的空缺Laya能拿到17K Star我觉得本质上是“大家确实需要这么一个东西”。它定位很明确完全开源、本地可部署、能微调、显存要求不高、专门优化System 1类决策任务。从社区反馈看很多人跟我一样不是不需要决策模型而是不想被闭源API绑死。所以“爆打Jev”这个说法准确理解是在特定决策赛道上Laya以更低的综合成本跑出了不输Jev的效果。它不追求在所有任务上碾压而是在“快决策”这个细分场景里做到了更开放、更可控。如果你有几十万条决策记录想要微调一个真正属于自己的路由模型Laya是比Jev更合适的起点。2. 安装前必须补齐的环境基础Python/Git/GPU三件套2.1 用虚拟环境隔离Python版本很多人拿到项目第一件事就是pip install结果装到一半发现系统Python里已经有一堆其他包版本冲突直接把人整崩溃。我的建议是项目开始之前就建好虚拟环境最省力的是Anaconda或者Minicondaconda create -n laya python3.11 -y conda activate layaLaya对Python版本的要求大概是3.10到3.12之间我用的3.11没有问题。之所以强调要虚拟环境是因为PyTorch、transformers这些依赖对版本非常敏感全局环境只要有一个包的版本不对你的训练可能就会在某个深夜报出一堆莫名其妙的ModuleNotFoundError。每换一个项目就建一个干净环境看起来多花两分钟实际省下的是后面几小时的排错时间。2.2 Git配置别只停在“装完”有些人电脑上装了Git就觉得万事大吉真正clone仓库或者推送代码的时候才发现根本没配置身份信息。先把这两行做了git config --global user.name 你的用户名 git config --global user.email 你的邮箱另外Windows用户建议装上Git后把core.autocrlf设为input避免跨平台换行符问题git config --global core.autocrlf input这块不配置好最大的坑是clone下来没什么事但你自己的数据文件送入训练脚本时可能莫名其妙多出\r字符数据加载报错的时候你很难第一时间想到是换行符在捣鬼。2.3 GPU显存预算先算账再动工不论安装还是微调显存都是第一道门槛。以7B量级的模型为例大致对应关系如下微调方式基础模型精度7B级别所需显存适合场景全参微调FP1660GB以上不推荐单卡基本跑不动LoRA微调FP16约24GB一张4090级显卡的舒适区LoRA微调4bit量化约12GB3060 12G这种入门卡也能跑估算逻辑很简单模型权重占了基础、LoRA存的是少量适配器参数、优化器状态和中间激活值另外计算。全参微调之所以要那么多显存是因为梯度也要按全量参数存。LoRA只更新一小部分参数显存压力瞬间降了一个量级。所以如果你只有一块16G显存的卡老老实实走量化版LoRA就行。3. Laya安装实战从拉取仓库到跑通第一个决策3.1 拉取仓库与依赖安装环境就绪后直接进入正题。假装你已经建好并进入了laya这个虚拟环境git clone https://github.com/你的目标仓库地址/laya.git cd laya pip install -r requirements.txt仓库地址我不写死因为这个项目仓库和HuggingFace上的模型可能后续会调整你直接在GitHub上搜Laya、关注度最高的那个仓库就是。依赖安装过程里最容易出问题的就是Python版本和PyTorch版本的匹配。如果你装了CUDA版PyTorch装之前先确认一下你的显卡驱动版本然后在PyTorch官网找到对应命令安装。这一步别偷懒直接pip install torch这种通用命令很可能会装上CPU版训练速度直接慢十倍以上。3.2 权重获取的两种路径代码clone下来只是第一步模型权重一般放在HuggingFace或者ModelScope上需要单独下载。如果直接下载速度不理想建议优先用ModelScope国内访问稳定很多。下载完成后把模型目录解压放好比如统一放在项目的model目录下。如果你有离线环境部署的需求办法也很简单在一台能联网的机器上下好整个模型目录打包拷到目标机器上只要目录结构完整代码读取不会有任何问题。这个细节对大企业项目特别实用因为生产服务器往往不直接连外网离线部署能力本身就是开源模型的优势之一。3.3 第一次System 1决策调用温度设0依赖和权重都就绪后先做一次简单的决策调用验证。以工具选择为例给定用户意图和候选工具列表要求模型输出一个工具ID。可以写这样一个推理脚本from transformers import AutoModelForCausalLM, AutoTokenizer model_path model/Laya-base tokenizer AutoTokenizer.from_pretrained(model_path) model AutoModelForCausalLM.from_pretrained(model_path, trust_remote_codeTrue).cuda() prompt 请根据用户意图从候选工具中选择最合适的一个只输出工具ID。 用户意图我要把刚才那段录音转成文字 候选工具 1. speech_to_text 2. translate 3. text_summary 输出 inputs tokenizer(prompt, return_tensorspt).to(cuda) out model.generate(**inputs, max_new_tokens16, temperature0.0, do_sampleFalse) print(tokenizer.decode(out[0], skip_special_tokensTrue))两个关键点一是temperature一定要设0System 1决策场景要的是确定性输出随机性在这种地方是灾难二是max_new_tokens不要给大决策答案通常就几个字懒模型才能快。我第一次跑的时候给的是64个token结果模型有时候会把理由也一起输出解析起来要多写不少代码。后面我统一压到16反而又准又稳。如果这一步能稳定输出正确工具ID说明Laya已经跑通了接下来才能考虑微调。4. 微调前的三张关键底牌数据设计、框架选型、参数预算4.1 什么数据适合喂给System 1模型很多人一上来就到处找微调数据集其实最适合System 1决策模型的数据就是你自己业务里的决策日志。这类数据有两个特征输入是场景描述候选集合输出是唯一确定的决策结果不要求长推理。举个例子一条典型训练样本长这样{ instruction: 根据用户意图从候选工具中选择最合适的一个只输出工具ID。, input: 用户意图把明天上午的会议时间同步给同事\n候选工具calendar_book, calendar_query, email_send, output: calendar_book }注意千万不要把带思维链的数据混进去。我见过有人拿推理类数据去微调决策模型结果模型学会了输出大段分析和步骤单次响应时间从200毫秒涨到2秒完全违背了System 1的初衷。决策数据就要干净利落输入短、输出更短。4.2 主流微调框架怎么选我为什么一直推LLaMA-Factory现在做模型微调的框架不少主流的几个我简单列过使用感受框架上手难度灵活性功能完整度我的建议原生transformers脚本高高低全靠自己写不建议新手FIRM之类轻量封装中中中可以了解LLaMA-Factory低中高UICLI齐全首选LLaMA-Factory最讨喜的地方是开箱即用内置了LoRA、QLoRA、全参微调等多种方案数据格式转换都是现成的训练日志和评估工具也齐全。你不需要从零写一个训练循环只需要把自己的数据转成它支持的格式配好参数就能跑。我后来所有微调任务包括公司内部几个垂直模型都是在这上面做的。没特殊需求的话直接用它省钱省到头。4.3 LoRA参数与显存的对应关系LoRA本质上是用两个低秩矩阵去近似权重的更新量所以参数选择直接决定训练成本和效果参数我的经验值说明r8-16太小学不住太大学不过来alpha32一般是r的2倍左右lora_dropout0.05防过拟合别太大target_modules全部关键投影矩阵让LoRA覆盖更多参数组合经验原则是数据量少就选r8数据量大且任务复杂就用r16起步。alpha通常设为r的两倍比如r16时alpha32这个组合在大多数场景下都不会出大错。显存方面FP16权重的7B模型LoRA训练大概需要24G显存如果只是4bit量化版12G的显卡也能勉强跑起来。参数不要贪大LoRA的意义是用小成本把模型“调”成你要的样子不是把模型塞满知识。5. 端到端微调实战把Laya改造成你的“决策专用脑”5.1 从业务日志到Alpaca格式LLaMA-Factory支持Alpaca格式核心是instruction、input、output三个字段。假设你手里有一份原始的决策日志里面记录着每次请求的query、候选工具列表和最终选中的工具ID可以用一个简单的Python脚本批量转换import json raw json.load(open(decision_logs.json)) examples [] for log in raw: examples.append({ instruction: 根据用户意图从候选工具中选择最合适的一个只输出工具ID。, input: 用户意图 log[query] \n候选工具 json.dumps(log[tools], ensure_asciiFalse), output: log[selected_tool] }) with open(laya_decision.json, w, encodingutf-8) as f: json.dump(examples, f, ensure_asciiFalse, indent2)转换好的文件放到LLaMA-Factory的data目录下然后在dataset_info.json里登记一下加载的时候就能按名字直接用了。我个人的习惯是留出5%到10%的样本不进入训练集作为最后的验证集专门用来测模型的泛化能力。5.2 训练命令逐参数拆解数据和框架准备好之后就是训练这个核心动作。我用的是LLaMA-Factory的命令行接口整个训练命令如下llamafactory-cli train \ --model_name_or_path model/Laya-base \ --dataset laya_decision \ --template qwen \ --finetuning_type lora \ --lora_rank 16 \ --lora_alpha 32 \ --lora_dropout 0.05 \ --target_modules q_proj,k_proj,v_proj,o_proj,gate_proj,up_proj,down_proj \ --output_dir lora_laya \ --per_device_train_batch_size 4 \ --gradient_accumulation_steps 4 \ --learning_rate 2e-4 \ --num_train_epochs 3 \ --lr_scheduler_type cosine \ --warmup_ratio 0.05 \ --fp16几个容易出错的点说明一下template参数要和底座模型匹配我用的Laya是基于Qwen架构微调过的所以填qwen。batch_size要根据显存调整如果你的显存不够先把per_device_train_batch_size降到2或者用gradient_accumulation_steps把等效batch补回来。learning_rate用2e-4是LoRA场景的标准做法太大容易训飞。训练多少个epoch不是越多越好我见过很多人跑50个epoch然后模型只会背答案3轮左右在决策任务上通常足够。5.3 训练后的验收标准别只盯着loss训练结束后我建议先看三样东西训练loss、验证集准确率、以及完全不训练的“陌生样本”表现。Loss下降说明模型在拟合训练集但拟合不等于泛化。之前我帮朋友调一个工具路由模型训练效果看起来很好loss降到0.3以下但拿全新场景一测准确率只有六成多原因就是训练集太单一模型只会背固定的几种工具组合。我自己常用的验收方式是分两步第一步用LLaMA-Factory自带的eval工具跑验证集准确率第二步手写几条业务中最常见的、但训练集里没有的原样组合直接测模型输出。两条都过了再去谈部署上线不然微调就是自欺欺人。6. 合参、量化与System 1决策部署6.1 LoRA合回底座并导出微调产物只是一组LoRA适配器真正的部署需要把适配器合并回底座模型导出成一个独立可用的模型目录。LLaMA-Factory做这件事非常省事llamafactory-cli export \ --model_name_or_path model/Laya-base \ --adapter_name_or_path lora_laya \ --template qwen \ --finetuning_type lora \ --export_dir model/Laya-decision \ --export_size 4 \ --export_legacy_format falseexport_size这里是指导出参数的精度4就是4bit量化。如果你对延迟极其敏感比如单次决策必须在100毫秒内完成那就用4bit导出体积小、推理快。如果你的机器显存充裕需要更稳定的精度可以导出成FP16准确率更高但显存占用也更大。6.2 在线服务的延迟调优部署方案我推荐两个吞吐优先用vLLM部署简单优先用Ollama。两者对比方案延迟表现部署复杂度适用场景vLLM高吞吐批量推理强中等需要一点配置生产环境高并发Ollama单请求延迟低极简内网工具、小规模服务System 1决策场景里有个细节经常被忽略模型本身的推理时间只占一部分真正拖慢响应的是请求排队和解析逻辑。所以除了选对推理框架还要在接口层做优化比如把输入的prompt模板固化成字符串不要在每层请求里重复拼接把temperature锁死在0保证输出稳定max_tokens压到16到32避免产生大量无关输出。这些加起来对延迟的优化效果往往比换一个更大的GPU还明显。6.3 一个可上线的决策调用实战样例我习惯把决策服务封装成一个简单的HTTP接口方便上游Agent调用。下面是基于vLLM的一个最小实现思路from vllm import LLM, SamplingParams llm LLM(modelmodel/Laya-decision, tensor_parallel_size1) params SamplingParams(temperature0.0, max_tokens16) def make_decision(user_intent, tool_list): prompt ( 根据用户意图从候选工具中选择最合适的一个只输出工具ID。\n f用户意图{user_intent}\n f候选工具{tool_list}\n输出 ) outputs llm.generate([prompt], params) result outputs[0].outputs[0].text.strip() return result接口层可以再包一层FastAPI逻辑就是收到请求后调用make_decision拿到结果后做一次白名单校验确保输出确实落在候选工具ID集合里如果不在就返回一个默认兜底值。这个兜底设计很重要System 1决策模型哪怕再准也会有极端输入导致乱输出绝不能让它把工具路由调用到一个不存在的ID上。7. 我踩过的坑与最后的实话7.1 三个让我浪费过时间的坑第一个坑是tokenizer版本不匹配。模型和tokenizer分别从不同地方下载版本没对齐推理时输出一堆乱码当时我还以为是模型坏了排查了半天才发现是tokenizer和模型权重版本不一致。后来我每次下载权重都强制检查配置文件里的版本号。第二个坑是训练数据里混进了带长推理的样本导致模型开始“话痨”输出稳定在几百token。这事发生在我调一个客服意图分类模型的时候本来几轮的决策微调模型却学会了把判断理由也说出来。后来我写了一个数据清洗脚本把output长度超过20个字符的样本全部踢掉才把问题解决。第三个坑是评估时用聊天模板不一致。同一个模型训练时用qwen模板评估时却用了默认模板结果准确率看起来低了十几个点。后来我固定了一套模板训练、评估、部署全程使用同一个才得到真实可信的结果。7.2 什么任务不该用System 1决策模型Laya的强项是快决策但“快”是有代价的。多步数学推理、复杂逻辑判断题、需要详细解释结果的场景系统还是交给系统2模型的比较好。另外如果你对结果的错误率是零容忍的比如医疗诊断、金融风控里那种不允许模型直接拍板的环节System 1模型只能作为初筛不能当作最终答案。我这段时间用下来的真实感受是Laya的价值不在于替换掉所有模型而是帮你把系统里那些大量重复、高频低难度的决策从“贵而慢”变成“便宜且稳定”。线性规划的比喻可能不太恰当反正就是别拿大炮打蚊子也别指望一把小刀能砍树。明白自己的场景需要什么选对工具微调好它比盲目追新模型重要得多。
