1. 一个1.9B小模型凭什么替大模型做决定第一次看到“1.9B小模型专门替LLM做决定”这个说法我脑子里蹦出来的不是技术架构而是一个很日常的画面公司里有个经验丰富的老总什么事都找他拍板但他时间贵、响应慢、还容易累。于是给他配了一个反应极快的助理专门处理那些“该不该做、先做哪个、要不要继续”的判断老总只负责最终执行。这个1.9B的小模型干的就是助理的活。这个项目的核心思路用一句话概括就是把LLM的“决策”和“执行”拆开让一个小模型专门负责决策大模型只负责它最擅长的生成和推理。这里的“决策”不是指复杂的逻辑推理而是指Agent在运行过程中那些高频、轻量、但必须快速做出的选择——比如当前该调用哪个工具、要不要继续追问用户、检索结果够不够用、下一步该走哪个分支。这些判断如果每次都丢给几十B甚至上百B的大模型延迟和成本都会很难看。我实测过类似的Agent流程一个简单的多轮工具调用任务如果每一步决策都走大模型端到端延迟轻松突破8到12秒token消耗也高得离谱。而把决策层换成1.9B这个量级的模型后决策部分的延迟能压到200毫秒以内整体响应速度提升非常明显。这就是“系统一”这个说法的由来——它对应的是心理学里那种快速、直觉、低能耗的思考模式而大模型更像是慢速、深思熟虑的“系统二”。这个内容适合谁看如果你正在做Agent应用被延迟和成本折磨过如果你在探索小模型的能力边界想知道1.9B能干什么或者你只是好奇“小模型替大模型做决定”这件事到底靠不靠谱那这篇内容应该能给你一些可以直接参考的东西。下面我会从设计思路、核心细节、实操过程到问题排查把这件事拆开讲透。2. 整体设计思路与方案选型拆解2.1 为什么要把决策和执行分开Agent的经典架构里决策和执行往往是揉在一起的。一个典型的ReAct循环大模型既要理解用户意图又要判断下一步动作还要生成具体的工具调用参数最后还要消化工具返回结果。这一整套下来大模型其实在做三件不同性质的事意图理解、动作决策、内容生成。这三件事对模型能力的要求完全不同。意图理解和内容生成确实需要大模型的泛化能力和语言理解深度但动作决策这件事本质上是一个分类问题或者排序问题。给定当前上下文从有限的候选动作里选一个最合适的。这种任务的输入输出空间相对封闭不需要模型有太强的开放域知识1.9B的模型完全有能力胜任。我试过用更小的模型做类似的事只要任务定义清晰、训练数据到位效果并不比大模型差多少但速度和成本优势是碾压性的。把决策剥离出来还有一个好处决策逻辑可以独立迭代。以前你想调整Agent的行为策略得重新写prompt、重新调大模型牵一发动全身。现在决策层是一个独立的小模型你可以针对特定场景做微调用少量标注数据就能让它在某个垂直领域表现更好而不影响大模型的生成能力。这种解耦带来的灵活性在实际项目里价值很大。2.2 1.9B这个尺寸是怎么选出来的模型尺寸的选择从来不是拍脑袋决定的它是在延迟、成本、效果三者之间找平衡点。我梳理了一下常见的几个档位你可以直观感受一下差异模型尺寸决策延迟单次部署成本适合场景0.5B以下50ms以内极低固定规则明确的简单分支1B-3B100-300ms低多工具选择、意图分类、流程控制7B-13B500ms-1.5s中等需要一定推理能力的决策30B以上2s以上高复杂规划、开放域决策1.9B落在一个很舒服的位置。它比0.5B那种“只能做固定规则”的模型有更强的语义理解能力能处理稍微复杂一点的上下文又比7B以上的模型快得多单次决策延迟可以控制在200毫秒左右。对于Agent场景来说决策往往是串行发生的每一步省几百毫秒十步下来就是好几秒的差距。还有一个容易被忽略的点1.9B的模型可以在消费级显卡上跑。这意味着你不需要昂贵的推理集群一张24G显存的卡就能同时承载决策模型和一部分生成任务。对于中小团队或者个人开发者来说这个门槛是实实在在的友好。我自己的测试环境就是单卡决策模型常驻显存大模型按需调用整体资源利用率比全走大模型高出一大截。2.3 “系统一”和“系统二”的协作机制这个架构里小模型和大模型不是替代关系而是协作关系。小模型负责“快思考”大模型负责“慢思考”两者通过一个明确的接口通信。具体来说小模型的输出不是自然语言而是结构化的决策指令比如{ action: call_tool, tool_name: search, confidence: 0.87, reason: 用户问题需要外部信息 }大模型收到这个指令后只负责执行对应的动作比如生成搜索查询、组织回答内容。它不需要再判断“我该不该搜索”这个判断已经被小模型做完了。这种分工带来的一个直接好处是大模型的prompt可以大幅简化。以前你要在prompt里写一大堆“什么时候该搜索、什么时候该直接回答”的规则现在这些规则被固化在小模型的权重里大模型的prompt只需要专注于“怎么把事做好”。我实际跑下来这种协作机制在工具调用场景下特别有效。小模型判断“需要调用哪个工具”的准确率在训练数据覆盖的场景里能做到90%以上而大模型因为prompt里规则太多导致的“选择困难”问题反而被规避掉了。3. 核心细节解析与实操要点3.1 决策模型的任务定义与数据构造要让1.9B的模型替大模型做决定第一件事是把“决定”这件事定义清楚。你不能笼统地说“让模型判断下一步做什么”这样模型学不到东西。我的做法是把决策拆成几个独立的分类任务每个任务单独定义输入输出。常见的决策任务包括是否调用工具二分类、调用哪个工具多分类、是否需要追问用户二分类、检索结果是否充分二分类、当前分支是否继续二分类。每个任务的数据格式都是“上下文候选选项正确答案”上下文包括用户输入、对话历史、当前工具返回结果等。数据构造是这里面最耗精力的环节。我的经验是不要试图用大模型自动生成全部训练数据那样会引入很多噪声。比较靠谱的做法是先用规则或者人工标注一批高质量种子数据大概几百到一千条然后用大模型做数据增强但增强后的数据要经过一轮筛选把明显不合理的样本剔掉。我试过纯自动生成的数据训练出来的模型在边界case上表现很不稳定后来加了人工校验环节效果才稳下来。注意决策模型的训练数据一定要覆盖“负样本”。比如“不需要调用工具”的样本很多人容易忽略导致模型倾向于过度调用工具。我踩过这个坑模型在简单问候场景下也去调搜索体验很差。3.2 输入输出的格式设计小模型的输入不是越长越好。1.9B的模型上下文窗口有限而且输入越长决策延迟越高。我的做法是只给决策模型它真正需要的信息把无关的历史对话、冗长的工具返回结果都截断或摘要。具体来说输入通常包含三部分当前用户意图的简短描述可以用大模型先做一次意图提取、当前可用的动作列表、最近一轮的工具返回结果摘要。这样输入长度可以控制在512个token以内决策延迟稳定在200毫秒以下。输出格式必须是严格结构化的我一般用JSON Schema约束。这样做的好处是即使模型输出有轻微偏差后处理也能兜住。比如模型输出了{action: search}但缺少tool_name字段后处理逻辑可以根据action自动补全默认工具。这种“模型规则”的混合方式比纯靠模型输出稳定得多。# 决策模型输出解析的简化示例 import json def parse_decision(raw_output, available_tools): try: decision json.loads(raw_output) except json.JSONDecodeError: return {action: fallback, reason: parse_error} if decision.get(action) call_tool: tool decision.get(tool_name) if tool not in available_tools: return {action: fallback, reason: invalid_tool} return decision3.3 训练策略与微调技巧1.9B的模型做决策不需要从头预训练基于一个已有的小模型做指令微调就够了。我用的方法是LoRA微调只训练一小部分参数显存占用低训练速度快而且不容易过拟合。全量微调我也试过效果提升有限但训练成本高了好几倍不划算。训练数据量方面每个决策任务大概需要2000到5000条样本才能达到比较稳定的效果。如果任务比较简单1000条左右也能跑出可用的结果。关键是数据质量要均匀不能某个类别的样本特别多否则模型会偏向预测多数类。我一般会做类别平衡让每个类别的样本数量大致相当。学习率设置上LoRA微调我通常用1e-4到3e-4之间训练3到5个epoch。太小的学习率收敛慢太大的话模型容易在训练集上过拟合验证集表现反而下降。我习惯在训练过程中每半个epoch存一次checkpoint最后在验证集上挑最好的那个。提示训练决策模型时验证集一定要包含“分布外”的样本比如训练时没见过的工具组合、没出现过的用户表达方式。这样才能真实反映模型的泛化能力避免上线后遇到新情况就崩。4. 实操过程与核心环节实现4.1 环境准备与模型部署先说一下我的测试环境配置供你参考。显卡是一张24G显存的消费级卡操作系统是常见的Linux发行版Python环境3.10。决策模型用1.9B的基础模型加LoRA权重合并后导出用常见的推理框架加载。大模型走API调用不占本地显存。部署决策模型时我建议常驻显存不要每次决策都重新加载。1.9B的模型加载一次大概占用4到5G显存FP16精度如果显存紧张可以用INT8量化占用能降到2.5G左右延迟增加不多。我实测INT8量化后决策准确率下降不到1个百分点但显存省了一半性价比很高。推理框架的选择上我试过几种常见的方案最后选了一个对小模型优化比较好的。关键是要支持动态批处理因为Agent的决策请求往往是零散到来的动态批处理能把多个请求合并推理吞吐量提升明显。如果没有动态批处理每个请求单独跑一次GPU利用率会很低。4.2 决策流程的完整实现整个决策流程我拆成了几个明确的步骤下面按顺序说。第一步是上下文预处理。用户输入进来后先用一个轻量级的规则或小模型做意图提取把冗长的自然语言压缩成简短的意图描述。比如用户说“帮我查一下明天北京的天气然后推荐穿什么衣服”意图提取后变成“查询天气穿搭建议”。这一步的目的是减少决策模型的输入长度同时保留关键信息。第二步是决策模型推理。把预处理后的上下文、可用动作列表、最近工具返回结果一起喂给决策模型得到结构化的决策指令。这里要注意动作列表要动态生成根据当前Agent状态决定哪些工具可用。比如已经调用过搜索了搜索工具就可以从候选列表里移除避免重复调用。第三步是决策结果校验。模型输出的决策指令不能直接执行要先过一遍校验逻辑。校验包括动作是否在可用列表里、参数是否完整、是否与上一步决策冲突。如果校验不通过走兜底逻辑比如默认选择“直接回答”或者“追问用户”。第四步是执行与反馈。大模型根据决策指令执行对应动作执行结果作为下一轮决策的输入。这样就形成了一个闭环决策、执行、反馈、再决策。# 决策循环的简化伪代码 def agent_loop(user_input, max_steps10): context preprocess(user_input) for step in range(max_steps): available_actions get_available_actions(context) decision decision_model.predict(context, available_actions) decision validate_decision(decision, available_actions) if decision[action] final_answer: return generate_answer(context) result execute_action(decision, context) context update_context(context, decision, result) return fallback_response()4.3 参数调优与性能实测决策模型的几个关键参数需要根据实际场景调。温度系数我一般设0.1到0.3之间决策任务不需要创造性低温度能让输出更稳定。最大输出长度设64个token就够了决策指令本身很短设太长反而浪费。置信度阈值是个重要参数模型输出的置信度低于阈值时可以触发兜底逻辑或者转交给大模型做二次判断。我实测了一组数据对比纯大模型决策和1.9B小模型决策的表现指标纯大模型决策1.9B小模型决策单次决策延迟1.2-2.5s150-250ms决策准确率92%89%每千次决策成本较高极低并发能力受限于API本地可并发准确率差了3个百分点但延迟和成本的优势太大了。而且那3个百分点的差距很大一部分是边界case实际用户体验上感知不明显。我的做法是高置信度决策直接执行低置信度决策转交大模型复核。这样综合准确率能拉到91%以上同时大部分请求还是走快速路径。提示置信度阈值不要设得太高否则大量请求都会转交大模型失去了小模型的意义。我一般从0.7开始试根据实际转交比例调整目标是让80%以上的决策走快速路径。5. 常见问题与排查技巧实录5.1 决策模型输出格式错误怎么办这是最常见的问题。小模型在遇到训练时没见过的输入模式时可能会输出不符合JSON Schema的内容。我的处理方式是三层防护第一层是训练时加入格式约束样本让模型学会按格式输出第二层是推理时用约束解码强制模型只能输出合法token第三层是后处理解析解析失败时走兜底逻辑。约束解码是最有效的一层。很多推理框架都支持JSON Schema约束你只需要把输出的schema传进去框架会在解码时屏蔽不合法的token。我用了约束解码之后格式错误率从5%左右降到了0.1%以下。如果框架不支持约束解码那就只能靠后处理兜底但兜底逻辑要设计得足够健壮不能因为解析失败就整个流程崩掉。5.2 模型在某些场景下总是选错动作这种情况通常是训练数据覆盖不足导致的。我遇到过一个典型问题模型在“用户表达模糊”的场景下总是倾向于调用搜索工具而不是追问用户。排查后发现训练数据里“追问用户”的样本太少而且大多是明确表达模糊的情况没有覆盖“看似明确但实际有歧义”的样本。解决办法是针对性补充数据。我构造了一批“表面明确、实际有歧义”的样本标注为“追问用户”重新训练后这个问题就解决了。这里的关键是你要能定位到模型在哪个场景下表现不好然后有针对性地补数据而不是盲目增加数据量。我一般会用一个小的验证集做错误分析把错误样本按场景分类看哪类错误最集中。5.3 决策延迟波动大怎么排查延迟波动通常来自几个方面输入长度变化、批处理竞争、显存不足导致的换页。我排查延迟问题的顺序是先看输入长度分布如果某些请求的输入特别长延迟自然会高再看GPU利用率和批处理队列如果队列积压延迟会飙升最后看显存占用如果接近上限系统会频繁换页延迟会剧烈波动。我遇到过一次延迟从200毫秒突然涨到800毫秒的情况排查后发现是某个工具返回的结果特别长没有做截断直接喂给了决策模型。加了结果摘要和截断逻辑后延迟就稳定了。所以输入长度控制是保证延迟稳定的关键一定要在预处理阶段就把输入压缩到合理范围。5.4 常见问题速查表问题现象可能原因排查方向解决思路输出格式错误训练数据格式样本不足检查训练集格式分布补充格式约束样本约束解码动作选择偏差类别样本不均衡统计各类别样本数量做类别平衡补充少数类样本延迟波动大输入长度不稳定统计输入token分布加截断和摘要逻辑置信度普遍偏低训练不充分或数据噪声看验证集准确率增加训练轮次清洗数据重复调用同一工具上下文更新逻辑有误检查工具可用列表生成调用后及时移除已用工具5.5 几个我踩过的坑第一个坑是过度依赖模型置信度。一开始我完全按置信度阈值来分流结果发现模型在某些场景下置信度虚高明明选错了但置信度有0.9。后来我加了一个规则校验层对高风险动作做额外检查才把这个问题压住。第二个坑是忽略了大模型和小模型的上下文一致性。小模型做决策时看到的上下文和大模型执行时看到的上下文如果不一致会出现决策和执行脱节的情况。比如小模型判断“检索结果充分”但大模型拿到的检索结果被截断了生成的内容就不完整。解决办法是统一上下文管理决策和执行共享同一份上下文快照。第三个坑是训练数据泄露。我在构造数据时不小心把验证集的样本混进了训练集导致验证准确率虚高上线后效果差很多。后来我严格做了数据隔离训练集和验证集按时间或来源划分确保没有重叠。6. 这套方案还能怎么扩展这个1.9B决策模型的路子我觉得最有意思的地方是它打开了一个思路不是所有事情都需要大模型来做。Agent流程里有很多环节其实都可以拆出来用更小的模型专门处理。比如意图识别、实体抽取、结果排序这些任务用1B左右的模型都能做得不错而且速度和成本优势明显。我接下来想试的一个方向是多决策模型协同。不同场景用不同的决策模型比如工具调用用一个模型对话流程控制用另一个模型每个模型都针对自己的任务做专门优化。这样每个模型都可以更小、更快整体效果可能比单个通用决策模型更好。另一个方向是决策模型和大模型的联合微调。现在两者是分开训练的如果能把决策模型的输出作为大模型训练信号的一部分让大模型学会更好地配合决策模型整体效果可能会有提升。这个想法还在验证阶段有结果了再分享。最后分享一个实操小技巧决策模型的版本管理很重要。每次更新决策模型都要保留旧版本方便回滚。我一般用A/B测试的方式新模型先跑10%的流量对比决策准确率和用户反馈确认没问题再全量。这个流程看起来麻烦但能避免很多线上事故。