端侧决策方案横评：Laya INT8 量化 vs 传统 ONNX 分类器，谁更适合本地部署

【免费下载链接】laya项目地址: https://ai.gitcode.com/hf_mirrors/convaiinnovations/laya

端侧 AI 部署正在经历一轮"范式之争"：同样的工单分诊、意图识别、内容审核需求，一边是工程师们熟悉的传统 ONNX 分类器——训练一个 BERT 分类头、转 ONNX、量化到 INT8、压进几十 MB 的二进制；另一边是 Laya 这类"非自回归 System 1 决策引擎"——不做文本生成，只对结构化问题打分，单次前向传播返回带校准概率的 typed answer。两条路线都能跑在 CPU 与低端 GPU 上，但它们的构建成本、延迟构成、置信度可信度和复杂度天花板完全不同。本文基于 Laya 开源仓库（Apache 2.0）的真实源码、配置与评估数据，结合社区部署实践，对两条路线做一次端侧视角的横评。

两条技术路线：预训练决策引擎 vs 传统分类器

先厘清"传统 ONNX 分类器"这条基线路线。它的标准流程是：收集标注数据 → 在预训练编码器（如 ModernBERT）上加一层分类头做有监督微调 → 导出 ONNX → INT8 量化 → 部署。它的核心特征是标签空间在训练期就被冻结：你训练时定义了 4 个类，线上就只能分这 4 类；想加一个"退款"意图，就得重新标注、重新训练、重新导出。每个业务问题对应一个独立模型，多路意图常常要维护十几个小模型。

Laya 代表的决策引擎路线把"答案空间"从训练期挪到了请求期。看仓库的核心接口 rl_agent_api.py，一次调用接收任意数量的 typed questions，每个问题可以是choice（多选一）、score（序数打分）、noul（布尔判断）三种原语：

result = agent.predict(state, questions) # questions 在请求时动态定义

在 rl_common.py 的build_sequence中可以看到具体实现：每个选项被渲染成[MASK] opt0 [MASK] opt1 ...的标记序列，DecisionModel的决策头在每个选项的[MASK]位置打分，再对"这一个问题"的选项做 softmax——新增一个选项、换一套 criteria，不需要任何重训练。社区文章将这种设计概括为"候选生成与决策分离、cross-encoder 式并行打分"，与仓库源码吻合：状态文本与选项文本拼接进同一个双向编码器，所有问题在一次前向传播内并行回答。

两条路线差异的根源在于"决策"的定义：

• 传统分类器：决策 = 固定标签空间上的 argmax，置信度是 softmax 原始概率（通常未经校准，过度自信是常态）；
• Laya：决策 = 请求期定义的选项集合上的打分，置信度经过 RLCD 强化学习训练与事后温度拟合，是"数学上校准过的概率"。

仓库根目录的 README.md 给出了关键证据：RLCD（Reinforcement Learning for Calibrated Decisions）用严格适当评分规则（log score + spherical score，序数问题再加 ranked probability score）做奖励，策略只有如实上报概率才能最大化期望奖励；推理时按(question type, 选项数)分桶拟合温度，见 rl_agent_config.json 中的temperature_by_options。这意味着 Laya 输出的 0.94 置信度是有统计含义的——"此类输入下 94% 正确"，而传统 ONNX 分类器的 0.94 往往只是分布上的一个峰值。

INT8 量化后的 Laya 与 ONNX 分类器同台实测

端侧部署最关心三件事：延迟、体积、可移植性。先说 Laya 的实测数据——以下均来自仓库官方基准（Tesla T4、同一批逐字节相同的问题）：

本仓库 eval/results.md 中 RL Agent 版本（带 act/escalate 头）在单机实测 1 问 p50 38.4 ms、10 问 156.0 ms——与官方数据一致。也就是说，一次决策的开销与"调用一次小模型分类"处于同一量级，甚至批量后更便宜，因为它把所有问题合并成单次前向传播（collate_items按真实 token 长度打包，见 rl_common.py）。

量化路径上，Laya 与 ONNX 生态完全打通：pip install laya[onnx]提供 ONNX Runtime 推理（README 明确有ONNXAgent），另有laya[fast]的 TileLang GPU fast path；社区微调实战（CSDN 决策引擎部署系列）的结论是 INT8 为端侧量化最优档，这与分类器路线共用同一套 ONNX Runtime / INT8 工具链——两条路线在量化层并不对立，差别在量化对象：传统方案量化的是"冻结了标签的判别头"，Laya 量化的是"请求期动态定义答案空间的全能决策头"。仓库内两个 checkpoint 的配置可直接佐证容量：英文模型 ModernBERT-large 编码器 28 层、hidden 1024（encoder/config.json），INT8 后权重体积对 421M 参数约为 0.4 GB 量级，对 322M 的多语言模型更小；配合 README 给出的 CPU 延迟 193–464 ms（preload 模式下），纯 CPU 端侧完全可承载。

校准能力是两条路线最悬殊的分水岭。仓库在 eval/results.md 给出了任务内 23,024 个问题的整体指标：accuracy 0.753、ECE 0.030、50% 覆盖率下准确率达 0.947。下图是本仓库实测的置信度-准确率校准曲线（任务内）：

作为对比，README 引用第三方对 TypeSafe Jev 的公开实测为 p50 236–276 ms、ECE 0.246，Laya 路由模式单问 32.8 ms、温度拟合后 ECE 0.081——无论是延迟还是校准都拉开一个数量级。而传统分类器在"不做温度缩放"时的 ECE 通常在 0.2 以上，且极少有团队为每个端侧模型做分桶温度拟合。这意味着用 Laya 做置信度门控是可信的：AUROC 0.77（README 实测），可以安全地"低置信度转人工"；而未经校准的分类器做门控，往往在错误样本上给出高置信度，门控形同虚设。

决策复杂度升级时，哪条路线先到天花板

横评的最后一项是"天花板"——业务决策从 4 分类升级到 20 分类、从单意图升级到"意图 + 紧急度 + 风险 + 退款判定"多问题联合时，哪条路线先撑不住。

传统分类器先撞墙。每加一个标签就要重训重导出一个 ONNX 模型，标签之间还互相竞争训练样本；多路任务要么维护 N 个模型（N 份延迟和内存），要么强行合并成一个超大标签空间（样本稀疏、尾部类崩溃）。Laya 的路由模式用Router把多 checkpoint 调度与语言检测解耦（README 实测脚本检测 <0.5 ms、切换成本仅一次首载），多语言场景下英文 checkpoint 对非拉丁语系直接失效（Khmer 准确率 0.000 但置信度 0.952——这正是"未校准置信度"的极端案例），而Router在 45/51 种语言上可用。

但 Laya 的天花板同样清晰，而且仓库 README.md 的 "Honest Limits" 一节写得很坦白：

• 高基数选项是硬伤。head_max_len预算被所有选项平分：默认 256 token 下，77 个标签的 Banking77 每个标签只剩 3–4 token，准确率掉到 0.425（对比 Jev 的 0.870）。解法是调高head_max_len/max_len（README 给出运行时修改agent.cfg的具体方法），或拆成 coarse-to-fine 两级选择——本质上和传统分类器的"层级分类"殊途同归。
• 零样本能力有限。基座 checkpoint 在 typed-decisions 基准上零样本准确率只有 0.362（随机基线 0.318、多数类 0.461），微调后的laya-typed-decisions才达到 0.766（超过教师模型 0.735 的自洽上限）。Laya 是"可快速特化的基座"，不是开箱即用的零样本决策器。下图是本仓库零样本评估的校准曲线——ECE 退化到 0.204，明显偏离对角线：

• 序数打分最弱：score原语在 SST-5 上仅 0.372；noul存在跟随选项标签而非状态的倾向（README 给出现象与 workaround），需要在自己数据上验证。

把三条线放在一起，端侧选型的结论其实很清晰：

• 如果你的决策是长期稳定、标签少、单任务（如一个固定的垃圾邮件二分类），传统 ONNX INT8 分类器依然是最低摩擦的选择——体积小、工具链成熟、没有运行时依赖；
• 如果你的决策是多问题联合、答案空间频繁调整、需要可信概率做门控或路由（工单分诊、Agent 工具选择、多语言意图路由），Laya 的请求期答案空间 + RLCD 校准 + ONNX/TileLang 双推理路径，让"一次部署、多路决策、置信度可信"成为可能，且 Apache 2.0 开源、可完全自托管、无 API 调用成本；
• 两条路线共同的边界在高基数标签：超过 50 个选项的单次决策，双方都需要分层策略——这不是引擎的差异，而是判别式模型在有限 token 预算下的物理约束。

端侧部署的下一个战场不在"谁更快"，而在"谁的概率更可信、谁改决策不改模型"。Laya 在这两个维度上给出了可复现的工程答案，剩下的就是在你自己的数据上做一次温度拟合和校准验证——仓库里从推理到评估的完整代码路径（rl_agent_api.py、rl_common.py、eval/results.json）已经把这条链路铺好了。

【免费下载链接】laya项目地址: https://ai.gitcode.com/hf_mirrors/convaiinnovations/laya