企业官网建设流程全解析

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.9GB；INT4的话不到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的模型微调，方式选择直接决定成本和效果。我把三种常见路径的对比列出来，你可以对照自己的资源来选。

我的建议是：先用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小模型和某个大模型来完成。

数据很说明问题：准确率只差不到3个点，但延迟差了一个数量级，成本差距更大。对于绝大多数决策任务来说，这3个点的准确率差距完全可以用兜底策略补上，而延迟和成本的收益是实打实的。

5.2 哪些决策它做不好，别硬塞

小模型不是万能的，有几类决策它明显吃力，硬塞只会给自己找麻烦。

需要多步推理的决策它做不好。比如“根据用户过去三个月的订单和当前库存，判断该推荐哪个商品”，这种需要链式推理的任务，小模型的能力不够。依赖大量外部知识的决策也不行，比如涉及复杂政策判断的。长尾极端的决策同样不行，训练数据里没见过的模式，它基本靠猜。

判断标准很简单：如果一个决策，人类专家看一眼就能拍板，那小模型大概率能做；如果需要人类专家查资料、算半天才能定，那就交给大模型。这个直觉判断法，比任何指标都好用。

5.3 持续迭代：线上数据怎么回流

决策模型上线不是终点，而是起点。线上跑起来之后，会产生大量真实的决策请求和结果，这些数据是持续优化的燃料。

回流机制要解决两个问题：哪些数据值得回流，以及怎么标注。值得回流的是那些“模型置信度低”和“被兜底策略拦截”的样本，这些是模型的薄弱点。标注可以结合人工复核和结果反馈——比如决策执行后用户是否满意、流程是否走通，这些都能作为弱标签。

我一般会每周回流一批数据，重新微调一次模型，观察验证集指标。这个循环跑起来之后，模型会越来越贴合你的实际场景。注意别频繁重训，一周一次足够了，太频繁反而容易过拟合到近期数据。

6. 落地这类方案时我踩过的坑和总结的经验

6.1 别一上来就追求端到端替换

我见过不少团队，一上来就想用小模型把大模型的所有决策都替掉，结果效果崩了，又全盘退回。正确的做法是从最高频、最简单的那一类决策开始替，比如先替掉路由，跑稳了再替工具选择，再替流程控制。每一步都验证准确率和延迟，确认没问题再扩大范围。

这种渐进式替换的好处是风险可控。某一类决策替失败了，影响面有限，回滚也容易。而且每替一类，你都能积累一批该类的数据，为下一类打基础。

6.2 决策标签体系要“一次设计、长期维护”

标签体系是决策模型的地基，设计不好后面全是坑。我的经验是：标签要互斥、要穷尽、要稳定。互斥是说一个输入只能对应一个标签，不能有歧义；穷尽是说要有一个“其他/未知”的兜底标签，别让模型遇到没见过的输入硬选；稳定是说标签别老改，改一次就要重新标注一批数据，成本很高。

设计标签时多花点时间，把业务方、产品、算法拉到一起对齐，比后面反复返工划算得多。我吃过这个亏，标签改了三次，每次都要重训模型，浪费了大量时间。

6.3 监控比训练更重要

模型上线后，监控体系的重要性甚至超过训练本身。要监控的指标包括：决策准确率（用抽样人工复核）、置信度分布（看模型是不是越来越不自信）、兜底触发率（看模型是不是在退化）、延迟P99（看服务是否稳定）。

我特别想强调的是置信度分布的监控。如果模型输出的置信度整体在下降，往往意味着线上数据分布和训练数据偏离了，这是模型需要重新微调的信号。这个指标比准确率更早发出预警，非常有用。

6.4 一个容易被忽略的收益：让大模型“专注”

最后分享一个我实际体会到的、但很少被提及的收益：引入小模型做决策后，大模型的输出质量反而提升了。原因很简单——大模型不再被大量琐碎的判断任务干扰，它的上下文里全是真正需要深度思考的内容，推理质量自然更高。

这有点像团队分工：如果让一个资深专家天天处理琐事，他的专业能力就被浪费了；把琐事交给助手，专家专注做难题，整体产出反而更高。小模型就是这个“助手”，它替大模型挡掉了噪音，让大模型回归它最擅长的事。

这个收益很难用数字量化，但在实际项目里，我能明显感觉到大模型的回复更聚焦、更少跑偏。如果你正在做Agent落地，不妨把这一点也纳入你的收益评估里。