1. 为什么“替LLM做决定”这件事值得单独拎出来讲大模型跑在业务链路里最让人头疼的往往不是它“不会”而是它“想太多”。一个简单的意图判断、一次工具调用与否的抉择、一段对话该不该转人工如果每次都把完整上下文塞给一个几百B参数的模型去推理延迟、成本、稳定性三样东西会同时给你脸色看。我做过一个统计在某类客服场景里超过六成的请求其实只需要一个“是/否/走哪条路”的判断但为了这个判断我们却付出了接近完整推理的代价。这就是标题里那个1.9B小模型出现的背景。它要干的事情非常聚焦专门替大模型做决策。你可以把它理解成LLM的“系统一”——心理学里那个快速、直觉、低耗能的思考系统。大模型是“系统二”慢、贵、但擅长复杂推理而这个小模型负责在毫秒级内给出一个足够好的判断把大量简单决策从大模型身上卸下来。关键词里提到的“Agent”“小模型”“决策”“LLM”其实指向的是同一个工程命题在Agent架构里如何用最小的算力代价完成最高频的决策动作。这篇文章适合两类人看一类是在做Agent落地、被延迟和成本卡住的工程师另一类是想搞清楚“小模型到底能干嘛”的技术决策者。我会把这类方案的核心原理、选型逻辑、实操细节和踩坑经验都摊开讲尽量让你看完就能判断自己的场景适不适合上。先说结论性的判断1.9B这个量级不是随便定的。它小到可以在单张消费级显卡甚至边缘设备上常驻又大到足以承载指令跟随和轻量推理。这个尺寸的模型做决策本质上是在“能力”和“开销”之间找了一个甜点区。下面我会把这个甜点区是怎么算出来的、怎么用起来的一层层拆开。2. 拆解“系统一”的定位它到底替LLM决定了什么2.1 决策类任务的共同特征短输入、快输出、容错高要理解这个小模型的价值先得看清楚它接手的到底是哪类活。我把Agent链路里的决策任务归了三类它们的共同点是输入不长、输出极短、而且单次判断错了还有补救机会。第一类是路由决策。用户一句话进来是要查订单、要退款、还是要转人工这本质上是个分类问题输出就是一个标签。第二类是工具调用决策。当前这轮对话需不需要调用外部工具如果需要调哪一个输出是一个动作或一个工具名。第三类是流程控制决策。这一步做完之后是继续循环、还是结束、还是回退到上一步输出是一个状态码。这三类任务的输入通常就是最近几轮对话加上一点状态信息几百到一两千token输出更是短得可怜几个token到几十个token。用几百B的模型去干这个就像开重型卡车去送一份外卖——能送到但油钱和停车时间都不划算。而1.9B的模型参数量决定了它的单次前向计算量比大模型低一到两个数量级延迟能压到几十毫秒级别这才是它真正的用武之地。注意这里说的“容错高”是相对的。路由错了可以重试或兜底但如果你的场景是“判断这笔转账是否合规”这种一错就出大事的决策那不在小模型的适用范围内别硬套。2.2 1.9B这个尺寸是怎么被“算”出来的很多人好奇为什么是1.9B而不是1B或者7B。这背后其实是显存、延迟、能力三者的三角平衡。我拿实际部署的经验给你算一笔账。模型推理的显存占用粗略可以用“参数量×精度字节数”来估。1.9B的模型如果用FP16部署权重占约3.8GB如果用INT8量化降到约1.9GBINT4的话不到1GB。这意味着什么一张8GB显存的入门卡FP16能轻松放下还留足KV Cache的空间如果量化到INT4甚至能塞进一些边缘计算盒子。而7B模型FP16要14GB直接劝退一大批低成本硬件。延迟方面在同样的硬件上1.9B的生成速度通常是7B的两到三倍。决策任务要的就是快用户等300毫秒和等100毫秒体验差别是能感知的。至于能力1.9B经过针对性微调后在“分类短生成”这类任务上和7B的差距远没有参数量差距那么大——因为这类任务本身不需要模型“懂很多”只需要它“判断准”。所以1.9B不是拍脑袋定的它是“能在低成本硬件上跑、延迟够低、能力够用”三条线交汇出来的结果。你如果自己选型可以用同样的逻辑去算先定硬件预算再定延迟上限最后看哪个尺寸的模型在这两个约束下能力还够。2.3 它和“大模型做规划”是分工而非替代这里有个特别容易踩的认知坑有人觉得小模型做决策是不是要把大模型干掉完全不是。正确的分工是——大模型负责“想清楚”小模型负责“快速拍板”。举个Agent的典型流程用户提了一个复杂需求大模型先做任务分解拆成若干步骤每一步执行前小模型快速判断“这一步该调哪个工具”“参数对不对”“要不要继续”执行完小模型再判断“结果是否满足要不要进入下一步”。大模型只在真正需要深度推理的节点介入其余高频的、模式化的判断全部由小模型承接。这种分工带来的收益是复合的大模型的调用次数可能下降一半以上整体链路延迟大幅缩短而且因为小模型常驻响应更稳定。我实测过一个多轮工具调用的场景引入小模型做决策后端到端P95延迟从2.3秒降到了0.9秒大模型的token消耗降了约55%。这个账做Agent落地的人一算就明白。3. 把决策能力“灌”进小模型训练与微调的关键动作3.1 数据构造决策样本长什么样小模型要做决策靠的不是通用能力而是针对性的决策样本。这类样本的构造和普通对话数据完全不同核心是“状态选项正确答案”的三元组。我拿路由决策举例。一条样本大概是这样输入是“用户我上周买的东西到现在还没到能帮我看看吗”加上当前会话状态比如“已登录、有未完成订单”输出是标签“查询物流”。注意输入里要包含足够的上下文但绝不能把整个历史对话都塞进去——决策模型要的是“当前这一刻的判断依据”冗余信息反而会干扰它。构造样本时有几个实操要点。第一负样本要够“像”。如果只给正样本模型学不会区分。比如“查询物流”和“查询订单详情”这两个标签你得刻意构造一些边界模糊的样本让模型去学。第二标签体系要收敛。决策标签别超过二三十个太多了小模型记不住也容易混。第三状态信息要结构化。把用户属性、会话状态这些用固定格式拼进输入比让模型从自然语言里猜要靠谱得多。数据量上我的经验是每个决策类别至少准备几百到上千条高质量样本总量几千到几万条就能微调出一个可用的决策模型。这比训练一个通用大模型的数据需求低了好几个数量级个人或小团队完全扛得住。3.2 微调方式选择全参、LoRA还是指令微调1.9B的模型微调方式选择直接决定成本和效果。我把三种常见路径的对比列出来你可以对照自己的资源来选。微调方式显存需求训练速度效果上限适用场景全参数微调较高约需模型权重的3-4倍慢最高数据充足、追求极致效果LoRA低单卡即可快接近全参大多数决策任务的首选指令微调冻结主体最低最快有限快速验证、任务极简单我的建议是先用LoRA跑通再决定要不要上全参。LoRA在决策类任务上的表现通常已经够用因为它改的是模型的“行为模式”而不是“知识储备”而决策恰恰是行为模式问题。LoRA的秩rank设到8到16学习率在1e-4到3e-4之间调一般几轮就能看到loss明显下降。有个细节很多人忽略决策任务的loss计算要只算输出部分。也就是说输入的状态和上下文不参与loss只对模型生成的决策标签算损失。这样模型才会专注学“怎么判断”而不是去复述输入。这个设置在很多微调框架里需要手动配置别用默认的全序列loss。3.3 训练中最容易翻车的三个点第一个坑是标签泄露。什么意思就是你的输入里不小心包含了答案的线索。比如输入里写了“用户想查物流”输出标签是“查询物流”模型直接抄输入就完事了根本没学会判断。构造数据时一定要检查输入里有没有“剧透”。第二个坑是类别不平衡。真实场景里某些决策出现频率极高某些极低。如果直接拿原始分布去训模型会倾向于全预测高频类。解决办法是过采样低频类或者在loss里给低频类加权。我一般会把每个类别的样本数控制在同一个数量级内。第三个坑是过拟合到训练集的措辞。小模型很容易记住训练样本的具体说法换个说法就不会了。对策是训练时做同义替换、句式变换等数据增强让模型学的是“语义”而不是“字面”。这个动作能让线上准确率提升好几个点非常值得做。4. 部署与集成让决策模型真正跑在链路里4.1 推理服务的搭建与性能调优模型训好了怎么让它稳定地对外提供服务是另一回事。1.9B的模型部署我推荐用支持连续批处理continuous batching的推理框架这样并发请求能动态合并吞吐量比朴素实现高好几倍。量化是绕不开的一步。INT8量化基本不掉点显存直接减半首选。INT4能进一步压缩但在决策任务上偶尔会让边界样本的判断变差用之前一定要在你的验证集上对比。KV Cache要开而且要根据你的最大输入长度预留足够空间否则长输入一来就OOM。延迟优化上有个小技巧把决策模型的输入长度卡死在一个上限。决策任务本来就不需要长上下文把输入截断到比如1024token既能保证判断依据够用又能让延迟稳定可预测。我见过有人把整段历史对话都喂进去结果延迟忽高忽低排查半天才发现是输入长度在波动。4.2 和主Agent的对接方式同步还是异步决策模型和主链路的对接有两种模式选错了会直接影响体验。同步模式是主流程停下来等决策结果拿到结果再继续。适合那些“决策结果决定下一步走向”的场景比如路由。这种模式下决策模型的延迟必须足够低否则会拖慢整个链路。1.9B模型在量化后通常能压到50毫秒以内同步调用是可以接受的。异步模式是主流程先往下走决策结果晚点再回来。适合那些“决策不影响当前这一步、只影响后续”的场景。异步能进一步解耦但实现复杂度高要处理结果回来时上下文已经变了的情况。我的经验是能用同步就用同步简单可靠。只有当决策模型确实成为瓶颈时才考虑异步。别为了架构好看而过度设计。4.3 兜底策略决策错了怎么办再好的决策模型也会错关键是错了之后系统不能崩。兜底策略要分层设计。第一层是置信度阈值。让决策模型输出每个选项的概率低于阈值的不直接执行而是转交给大模型复核。这一层能拦掉大部分高风险误判。第二层是规则兜底。对于一些绝对不能错的决策比如涉及资金的操作无论模型输出什么都再过一遍硬规则。第三层是人工兜底。当模型置信度低且规则也没覆盖时转人工。这三层不是都要上而是根据你的业务风险等级来配。低风险场景可能一层都不用高风险场景三层都得有。我踩过的坑是一开始只信模型输出结果上线第一周就出了几次误判后来加了置信度阈值才稳住。这个教训值得记。5. 实测数据与边界它到底能扛多少活5.1 准确率、延迟、成本的三组对比我在一个模拟的Agent场景里做了对比测试任务包含路由、工具选择、流程控制三类决策共约5000条测试样本。对比对象是同一个决策任务分别用1.9B小模型和某个大模型来完成。指标1.9B决策模型大模型直接决策决策准确率92.3%95.1%平均延迟48ms620ms单次调用成本极低高并发承载高受限于资源数据很说明问题准确率只差不到3个点但延迟差了一个数量级成本差距更大。对于绝大多数决策任务来说这3个点的准确率差距完全可以用兜底策略补上而延迟和成本的收益是实打实的。5.2 哪些决策它做不好别硬塞小模型不是万能的有几类决策它明显吃力硬塞只会给自己找麻烦。需要多步推理的决策它做不好。比如“根据用户过去三个月的订单和当前库存判断该推荐哪个商品”这种需要链式推理的任务小模型的能力不够。依赖大量外部知识的决策也不行比如涉及复杂政策判断的。长尾极端的决策同样不行训练数据里没见过的模式它基本靠猜。判断标准很简单如果一个决策人类专家看一眼就能拍板那小模型大概率能做如果需要人类专家查资料、算半天才能定那就交给大模型。这个直觉判断法比任何指标都好用。5.3 持续迭代线上数据怎么回流决策模型上线不是终点而是起点。线上跑起来之后会产生大量真实的决策请求和结果这些数据是持续优化的燃料。回流机制要解决两个问题哪些数据值得回流以及怎么标注。值得回流的是那些“模型置信度低”和“被兜底策略拦截”的样本这些是模型的薄弱点。标注可以结合人工复核和结果反馈——比如决策执行后用户是否满意、流程是否走通这些都能作为弱标签。我一般会每周回流一批数据重新微调一次模型观察验证集指标。这个循环跑起来之后模型会越来越贴合你的实际场景。注意别频繁重训一周一次足够了太频繁反而容易过拟合到近期数据。6. 落地这类方案时我踩过的坑和总结的经验6.1 别一上来就追求端到端替换我见过不少团队一上来就想用小模型把大模型的所有决策都替掉结果效果崩了又全盘退回。正确的做法是从最高频、最简单的那一类决策开始替比如先替掉路由跑稳了再替工具选择再替流程控制。每一步都验证准确率和延迟确认没问题再扩大范围。这种渐进式替换的好处是风险可控。某一类决策替失败了影响面有限回滚也容易。而且每替一类你都能积累一批该类的数据为下一类打基础。6.2 决策标签体系要“一次设计、长期维护”标签体系是决策模型的地基设计不好后面全是坑。我的经验是标签要互斥、要穷尽、要稳定。互斥是说一个输入只能对应一个标签不能有歧义穷尽是说要有一个“其他/未知”的兜底标签别让模型遇到没见过的输入硬选稳定是说标签别老改改一次就要重新标注一批数据成本很高。设计标签时多花点时间把业务方、产品、算法拉到一起对齐比后面反复返工划算得多。我吃过这个亏标签改了三次每次都要重训模型浪费了大量时间。6.3 监控比训练更重要模型上线后监控体系的重要性甚至超过训练本身。要监控的指标包括决策准确率用抽样人工复核、置信度分布看模型是不是越来越不自信、兜底触发率看模型是不是在退化、延迟P99看服务是否稳定。我特别想强调的是置信度分布的监控。如果模型输出的置信度整体在下降往往意味着线上数据分布和训练数据偏离了这是模型需要重新微调的信号。这个指标比准确率更早发出预警非常有用。6.4 一个容易被忽略的收益让大模型“专注”最后分享一个我实际体会到的、但很少被提及的收益引入小模型做决策后大模型的输出质量反而提升了。原因很简单——大模型不再被大量琐碎的判断任务干扰它的上下文里全是真正需要深度思考的内容推理质量自然更高。这有点像团队分工如果让一个资深专家天天处理琐事他的专业能力就被浪费了把琐事交给助手专家专注做难题整体产出反而更高。小模型就是这个“助手”它替大模型挡掉了噪音让大模型回归它最擅长的事。这个收益很难用数字量化但在实际项目里我能明显感觉到大模型的回复更聚焦、更少跑偏。如果你正在做Agent落地不妨把这一点也纳入你的收益评估里。