「把决策模型从 API 里抢回来」：Laya 爆火背后，本地决策正在重写 AI 成本账

过去两年，AI 应用的「决策」几乎默认是生成式 LLM 的活儿：给提示词、等 token 逐字吐出来、再写一堆正则去解析结果。这套模式有一本隐形的账——按 token 计费、自回归延迟、还有随时可能出现的幻觉。而 Laya 的出现，把这本账摊开算了算：一个 421M 参数、非自回归、单次前向传播输出三类 typed decisions 的开源决策引擎，在单张 T4 上把单问延迟压到 33ms 量级，一次调用输出 token 为零，权重以 Apache 2.0 完全开源、可自托管。社区里「把决策模型从 API 里抢回来」的说法由此而来。

这篇文章不打算复述 Laya 的营销卖点，而是基于仓库源码与实测数据，把三本账算清楚：本地决策的成本账、自托管的隐私与合规账，以及这场本地化运动对生成式 API 生态的真实影响。

为什么「决策」值得从 API 里抢回来

先看生成式方案做决策的成本结构，问题就出在它的三个固有环节上。

第一是计费口径。生成式 API 按输入 + 输出 token 双向计费，而判别式任务（路由、分类、打分、判定）的答案其实只有几十个字节——但你必须为模型「思考过程」里吐出的成百上千个 token 付钱。第二是延迟。自回归解码是逐 token 生成的，一次决策的 p50 延迟动辄两三百毫秒，且无法并行。第三是幻觉。当答案不是从有限选项中选出来的，而是「编」出来的，每一次解析失败都意味着额外的重试成本。

Laya 的回应很直接：不做生成，只做决策。打开仓库的推理实现 rl_agent_api.py，system_one(state, questions)返回的 usage 结构里写着"output_tokens": 0——整次决策没有任何文本生成环节。它的序列构造在 rl_common.py 的build_sequence中定义得很清楚：

[CLS] <type> question: <instructions> [SEP] [MASK] opt0 [MASK] opt1 ... [SEP] state [SEP]

每个候选选项前放置一个[MASK]标记，DecisionModel由预训练双向编码器（英文版为 ModernBERT-large，28 层、1024 维）+ 从头训练的决策头组成：决策头对各个 marker 位置打分，再对该问题的选项做 softmax。答案空间在请求时定义，新 schema 无需重新训练。选项数、指令、状态一次性编码进单次前向传播，全部问题在同一次 forward 中回答完毕——这就是「一次前向出决策」的源码级含义。

社区对这套设计的解读是「System 1 / System 2 协同」：生成式 LLM 负责开放推理（System 2），Laya 负责高频结构化判断（System 1），两者不打架，反而互补。但关键差别在于：System 1 的负载，本就不该按生成式 API 的定价模型收费。

本地决策的成本账：毫秒、吞吐与 token 归零

成本账要从实测数字说起，仓库 README.md 和 eval/results.md 给出了同一套基准（Tesla T4、所有 checkpoint 回答同一批问题）：

单卡吞吐实测 103–332 问/秒。仓库内 eval/results.json 的独立复测与之吻合：1 问 p50 38.4 ms、p95 42.1 ms；10 问整批 156 ms；50 问整批 721 ms。也就是说，一个日活百万级的工单分诊、邮件路由或内容审核负载，一张 T4 就能扛下来——而这张卡可以是你自己的机器，也可以是任意一家云厂商的竞价实例。

对比项的账更直观。README 中披露的第三方实测（TypeSafe Jev 的基准来自社区独立测试，非本仓库测量）显示：Jev 单问 p50 延迟 236–276 ms，Laya 带路由的Router().predict()为 32.8 ms，约快7.8 倍；校准误差 ECE 从 Jev 的 0.246 降到 Laya 的 0.081（约 3 倍改善）；权重侧 Jev 是闭源 API（单价 0.042 美元/百万 token），Laya 是 Apache 2.0 开源权重、自托管成本为 0。当每次决策的输出 token 归零、输入只需编码一次时，按「百万 token」计费的商业模式对这类负载天然失真——这正是「把决策从 API 里抢回来」这句话的经济学根基。

任务的可靠性同样有据可查。下图是 eval/reliability_eval_in.png 呈现的任务内评估可靠性曲线（置信度与准确率的对齐情况），对应 23,024 道题的整体成绩：准确率 0.753、ECE 0.030、50% 覆盖率下准确率达 0.947——高置信度输出基本可信，这是它可以放心接入生产链路的前提。

值得一提的是端侧这条线：社区已有 Laya 移植 Apple Silicon 的报道（laya-mlx 版本以每秒 60 步的速度运行贪吃蛇实验），结合仓库Router(preload=True)在 CPU 上 193–464 ms 的单问延迟数据，「本地决策」不止意味着自托管服务器，也意味着真正的端侧部署——游戏 NPC、机器人、离线设备这些低延迟场景正是社区文章反复强调的主战场。

自托管的第二本账：隐私与合规

成本之外，把决策模型留在自己手里还有一笔更难量化的账：数据不出域。

工单、邮件、用户会话、内部系统状态，这些恰恰是判别式决策的典型输入，也是最敏感的业务数据。过去把它们整体发给第三方 API，等于把用户行为、财务信息、内部架构全部暴露在外部链路里。自托管 Laya 后，整个推理闭环都在自己的网络边界内完成——输入编码、单次前向、输出结构化答案，全程无外部调用。

仓库对「本地数据管道」的处理体现了这种工程自觉。email_utils.py 专门实现了一套邮件清洗逻辑：在送入模型之前，先剥离引用回复（quoted history）、签名档与法律免责声明，再折叠空白、截断长度——因为 Jev 风格的模型在冗长、嘈杂的状态文本上会掉准确率，而英文 checkpoint 的max_len只有 512 token。这意味着数据清洗、脱敏、裁剪这些合规前置工作，全部可以在本地代码层完成，再进入推理。

多语言支持同样不需要借助外部翻译 API。README.md 说明Router基于 Unicode 脚本检测在亚毫秒级（纯 Python、<0.5 ms）完成语言识别，把输入路由到对应的 checkpoint：英文走 ModernBERT-large，100+ 语言走 mmBERT-base（multilingual/rl_agent_config.json 显示其词表达 256,000、上下文 1,024，编码器支持 RoPE 扩展到 8,192 token）。如果你已有自建的语言识别模型，还可以通过lang_guess参数接管路由判断（支持语言代码或可调用对象），完全不依赖外部服务。

零样本场景的可靠性边界，仓库也如实标注了。eval/reliability_eval_zs.png 展示的是 2,400 道零样本题的可靠性曲线：整体准确率 0.651、ECE 0.204，明显比任务内（ECE 0.030）更松散。这提醒工程团队：隐私与合规的红利来自自托管，但能力边界来自微调与校准——零样本泛化不是它的强项。

微调与校准：把「抢回来」变成「更好用」

把模型从 API 里抢回来只是第一步，让它比 API 更准才是关键。仓库给出的微调路径是完整且诚实的闭环。

在 typed-decisions 基准（400 个案例、2,000 个决策、四个工作流）上，基础英文 checkpoint 的零样本准确率只有 0.362——低于多数类基线 0.461；而基于同一基准训练集微调出的laya-typed-decisions（ModernBERT-large 底座）把准确率拉到0.766，不仅超过 TypeSafe Jev 的 0.727，还越过了 teacher 自一致天花板 0.735。README 的结论写得很直白：Laya 是一个「快速特化的底座，而非零样本决策引擎」。微调闭环可以在 Kaggle 免费的 2×T4 上完整跑通（数据构建、训练、温度拟合、评估、推送 Hub 一条龙）。

校准是这套体系里容易被忽略但至关重要的工程细节。仓库承认模型出厂是「过度自信」的：重拟合每个（问题类型 × 选项数）分桶的温度后，英文 checkpoint 的 ECE 从 0.466 降到 0.081，多语言版从 0.314 降到 0.106。对应的温度参数就存在 rl_agent_config.json 的temperature_by_options里：choice:3-5 → 1.76、noul:2 → 1.98、score:3-5 → 1.25、choice:11+ → 0.10——选项越多温度压得越低，防止长选项列表上的分布过度平滑。rl_common.py 中的temp_bucket实现了这套分桶逻辑，推理时由 rl_agent_api.py 按桶套用温度再算 softmax。

这种「诚实概率」是有训练机制背书的：RLCD 使用严格适当评分规则（log + spherical，序数 score 题追加 ranked probability score），proper_reward的实现注释写着「只有报出诚实概率才能最大化期望奖励」，更新方式为带组均值基线的 REINFORCE（GRPO 风格），多轮会话则用 TD(λ=1.0) 在对话前缀切片上传播奖励。社区实践进一步印证了它的可特化性：多篇实战文章记录了 LoRA 微调（如 r=8、lora_alpha=32）构造中文决策数据、ONNX 量化部署（INT8）、vLLM/Ollama 接入的完整流程——一个 421M 参数、支持 LoRA 与量化的模型，在消费级 GPU 甚至 CPU 上都能完成「微调 + 部署」的本地闭环。

仓库同样列出了诚实的局限：高基数选项是短板（77 个标签的 Banking77 上 0.425，远低于 Jev 的 0.870，因为选项共享head_max_lentoken 预算，每个标签只能分到 3–4 个 token）；noul存在跟随选项标签而非状态的倾向；act_probability目前没有可用信号。这些边界恰恰是工程选型时最该读的部分——「把决策抢回来」的前提，是知道哪些决策该抢、哪些暂时抢不了。

这场「本地化」运动会反噬生成式 API 生态吗

最后一个问题：当判别式决策大规模迁回本地，生成式 API 生态会被反噬吗？

我的判断是：不会反噬，但会重新划界。Laya 的设计哲学从根上就决定了它不是生成式模型的替代品——它「永不生成文本」，也就永远无法覆盖开放生成、长程推理、创意写作这些真正需要 System 2 的场景。它的价值主张精确落在高频、低延迟、高可控、高敏感的判别式负载上：路由、排序、工具选择、意图识别、工单分诊、内容安全。这恰好是当前生成式 API 用量中占比极大、却性价比最差的一块。

真正的冲击发生在定价模型层面。当「决策」这件事有了开源的、可自托管的、token 成本趋近于零的实现，按 token 计费的 API 在这类负载上就失去了定价权。供应商的应对方向不外乎两条：把计费口径从 token 迁移到「每次决策」的结果计价，或者把资源聚焦到生成式任务的高价值区段。而对应用开发者而言，这意味着一套新的成本结构：生成式 API 负责"想"，本地决策引擎负责"定"，中间用 Router 之类的路由层做衔接——这也是社区对 Laya 的主流定位：与生成式 LLM 形成 System 1 / System 2 协同架构。

更深远的变化在于，决策能力正在从「租用」变成「基础设施」。开源权重、自托管、可微调、可量化、有诚实概率输出、有明确标注的边界——这套组合让决策引擎可以像数据库一样被部署、被审计、被定制，成为应用自己的技术栈的一部分，而不是每次调用都向外付费的黑盒。当决策成为基础设施，成本账、隐私账、生态账就同时被改写了。

这或许才是 Laya 爆火背后真正的信号：AI 成本账的重写，不是靠更便宜的 API，而是靠把不该外包的环节拿回来。