两 B 决策模型开源跑本地：小模型的适用边界要先划清
一、它替代的是链路上的一步，不是整个脑子
据公开报道，有厂商的智能体团队开源了一款两 B 规模的决策模型，权重放在公开仓库，可以在本地 CPU 或 GPU 上运行。模型名、参数规模与可得性在这里只是背景转述，不是本文的判断依据；参数大小也不该成为选型理由。本文处理的是这一类东西牵出的工程问题：当”要不要调用大模型”这一步被单独拿出来做成一个小模型，边界要怎么划、判错了怎么算账、跑在本地要付哪些看不见的钱。
这一步在链路里的位置很具体：用户的一句话进来，系统要决定走哪条支路——查不查库、调哪个工具、要不要转给大模型、要不要停下来等人点头。把它叫”决策模型”，意思是它不承担写出最终答案的责任，只承担分流的责任。这个定位决定了它的能力要求比生成模型低一档，也决定了它的错误会被下游放大或者掩盖。
适合交给它的四类判定：意图分类（这句是查询、修改、取消还是闲聊）、工具选择（从有限工具表里挑一个并给出关键参数）、检索必要性（先判要不要查库，再决定上下文怎么拼）、人工确认必要性（涉及对外发送、结构变更、金额变动的要升级到人）。这四类有共同结构：输入短、候选集封闭、答案可事后校验、判错后容易在下一跳被发现。
不该交给它的三类：多约束规划（要在时间、预算、依赖顺序之间反复权衡，错一步整条计划失效）、跨文件推理（要同时持有分散在多个位置的细节）、需要世界知识的问答（知识面与更新速度都撑不住）。这三类的共同点是判定本身就需要被判定任务所需的推理能力，用小模型做只是把瓶颈挪了个位置，还额外增加了错分。
一条我们内部常用的粗判据：一项判定如果能让新入职的同事在不查资料的情况下几秒内做完，它就有进小模型射程的资格；如果需要翻资料才能做，那就是大模型的活。
二、三层结构：规则先挡一层，小模型判一层，大模型兜底
单靠小模型分流是不稳的，它必须待在分层结构里，而且每一层要有明确的分流量目标和明确的失败去向。
| 层 | 承接内容 | 分流量目标 | 判错或不确定时的去向 |
|---|---|---|---|
| 规则层 | 固定格式指令、明确的关键词与意图词表、工具白名单、历史高置信命中的缓存复用 | 消化掉最确定的那一部分，不占模型预算 | 规则不命中才落到小模型 |
| 小模型层 | 意图分类、工具选择、检索必要性、人工确认必要性 | 承接多数简单的单轮请求，把大模型留给真难题 | 置信度低于阈值或输出不合法时升级大模型 |
| 大模型层 | 规划、跨文件推理、世界知识问答、对客户的承诺文本 | 只处理真正需要推理的部分 | 命中高危动作时转人工确认 |
规则层常被跳过，后果是小模型去判本来该由字面匹配判的东西，既慢又不稳定。规则层的纪律是只做确定性判定，不做”大概像”；一旦规则里开始出现模糊匹配，就说明该内容往下放。
分流量目标要按任务分布定，不追求统一数字。交付给客户时，我们会要求先跑两周的影子流量（判定结果只记录不生效），拿到真实分布之后，再决定每层的承接面和阈值；没有分布就设阈值，等于在猜。
三、判错是双向代价，阈值要按代价设
这一步和小模型化最容易被忽略的地方在于：错误有两个方向，代价完全不对称。
该升级没升级，下游拿大模型的答案就错了，代价落在正确性和客户信任上；不该升级全升级，答案是对的，代价落在账单和延迟上，等于花大模型的钱干规则的活。所以阈值不是一个全局置信度，而是按判定头分别设，并且按错误代价设。
- 高代价方向（漏升级会导致答错、对外发出错误内容）的判定头，阈值设得偏保守，允许过度升级，宁可多花钱。
- 低代价方向（分错支路但下游可纠正）的判定头，阈值可以激进，允许一定比例的错分。
- 每个判定头单独留错例样本库，每次模型或提示变动后先在错例集上回归，再看全量指标；只看平均分看不出代价结构。
- 阈值调整要有记录：谁调的、依据哪批错例、调之前的升级率与判错率是多少，供事后复盘和交接。
错例样本还有一个作用：它能告诉你任务分布已经变了。当新增错例集中在某一类输入上，通常是业务口径或者上游提示词改了，而不是模型退化了。
四、显存与吞吐这笔账要算到能落地
本地跑一个小模型，最容易的说法是”这点量随便跑”。我们的做法是把账写成式子，让客户提供真实分布代进去。
- 权重体积按参数量乘以每参数字节数估：半精度两字节、int8 一字节、int4 约半字节。量化档位不同，卡的占用差得很明显。
- 并发上来后先到瓶颈的往往不是权重，而是 KV 缓存。它随并发数与上下文长度线性增长，所以小模型也要限定注入长度，不能因为模型小就放开拼上下文。
- 判定任务的延迟预算通常以百毫秒计，且要盯尾延迟而不是平均延迟；一次判定拖住整条对话，用户感知的是”卡”。
- CPU 兜底路径要单独量：确认在声明的并发数与输入长度下，尾延迟仍能满足判定预算再上线；量不出来就别接线上。
- 并发数不等于”最大能开多少”，而是”在尾延迟约束内能稳定开多少”，两者差好几倍。
- 两 B 这个量级一般不需要张量并行与流水线并行；如果算完发现需要，通常说明选型走偏了，应该回到分层结构而不是加卡。
这套算式的价值不在于得出一个精确数字，而在于把”能不能跑”变成一个可以核对的过程，客户和我们自己都有话可说。
五、本地部署的隐性成本与许可证落点
数据不出域、单次调用单价低、冷启动行为可控，这是本地跑的三条明面上的收益。真正的坑在下面这张表，我们把它作为交付核对项，逐条填负责人。
| 科目 | 必须核的问题 | 典型漏法 |
|---|---|---|
| 机器折旧 | 这台卡除了判定还兼什么职，占用率多少 | 只算新增卡，把共用机器的成本当作免费 |
| 运维人力 | 谁负责升级、回滚、监控、值班 | 按”模型小所以省事”估工时 |
| 更新通道 | 权重从哪来、怎么校验、多久一次 | 手工下载覆盖，出问题时无法回退 |
| 故障兜底 | 判定服务不可用时是降级到大模型还是全停 | 只设计了正常路径，没设计挂掉路径 |
| 评测口径维护 | 判据与错例集归谁长期维护 | 换模型时评测一起被换掉，前后不可比 |
| 许可证与商用条款 | 权重条款、商标与署名要求、修改与再分发义务、上游依赖清单 | 只看开源二字，没读条款差异 |
许可证这一项要落在文件上而不是记忆里：把权重条款、商标要求、修改与再分发义务、上游依赖各自的条款抄成一页，写明商用场景下允许做什么、要求声明什么，由谁复核、多久复核一次。不同开源模型的条款差别比想象中大，把上一个模型的结论套到下一个模型上是常见事故来源。
六、上线后的观测与退路
观测至少五项：各层分流量比例、小模型到大模型的升级率、判错率、被挡掉那部分请求的实际复杂度分布、端到端成本与尾延迟。其中最容易被忽略的是第三项之后的一半：被小模型挡掉的那部分，实际是不是简单任务。
验证方法是周期性用大模型重放抽样。把小模型判成简单、直接走完的样本留一批，隔一段时间用大模型重跑一遍同样的判定，比对一致率。一致率下滑说明任务分布已经漂出小模型的边界，处理顺序是先收紧阈值（宁可多升级），再回看是哪一类输入新增的，最后决定是加规则还是换模型。
升级率本身也有两种异常形态：骤降往往不是模型变强，而是输入分布变了导致过度自信；骤升则是成本失控，通常是规则层失效或者上游提示词改坏了。两者都该报警，而不只是记账。
退出方案必须在上线前写好，因为小模型会有不再维护的那一天。我们的固定做法是先建影子链路：同一份流量并跑新旧两个判定模型，新模型只记录不生效，比对各判定头的一致率与错例分布，达标后再切换；切换期间保留旧的判据与私有评测集，保证评测口径不断。这条纪律对洹拓的每个接入方都适用——决策模型是可以替换的零件，判据和历史账本不能跟着一起换掉。