Laya 基准测试深度解读：从 51 语言覆盖、工作流精度到 GPU 快速路径的完整实测图谱-平芜编程栈

人工智能
NLP
强化学习

【免费下载链接】laya

Non-autoregressive System 1 decision engine. Typed choice, score and yes/no decisions over any text in a single forward pass, in 100+ languages, with a router that picks the right checkpoint per request.

项目地址：https://gitcode.com/gh_mirrors/lay/laya

点击查看免费下载

本文是对 BENCHMARKS.md 的完整解读与仓库源码级佐证。Laya 是一个非自回归（System 1）决策引擎，用一次前向传播对任意文本做出choice（分类）、score（序数评分）和noul（是否判定）三类有类型决策，并通过 Router 按请求语言/脚本挑选英文或多语言检查点。读完本文，你将掌握：Laya 三个检查点在多语言、应用工作流、延迟与校准上的真实测量口径；温度钳制、批处理、线程绑定等影响结果的配置细节；以及 TileLang GPU 快速路径的数值一致性与加速数据，并能依据这些表为自己的任务选择检查点、设置置信度阈值或复跑基准。

阅读约定：除明确标注为「第三方发布」的 Jev 数据外，本文所有数字均来自本仓库实测。BENCHMARKS.md 中的每次运行都让每个检查点回答字节完全一致的问题（固定随机种子），因此不同检查点之间可直接对比。

基准运行总览：三套主跑

BENCHMARKS.md 开头给出三套已提交的基准运行，对应仓库research/results/下的结果文件：

运行	内容	结果文件
T4 Colab	typed-decisions、MASSIVE（14 语言）、XNLI（15 语言）、英文套件、延迟、选项顺序鲁棒性、校准修复	research/results/t4_colab_benchmark.json
CPU sweep	MASSIVE intent 覆盖全部 51 种语言；其 typed-decisions 部分（`part_b`）只覆盖英文检查点	research/results/cpu_51_language_sweep.json
Applications	七类工作流主题 + 存在 Jev 数据的公开数据集，三个检查点全跑（laya 0.2.1，CPU，每任务 400 例，种子 13，2026-09-19）	`research/results/app_benchmark_results.json`

运行脚本与复现入口集中在 research/scripts/：bench_local.py跑 51 语言 CPU sweep，bench_apps.py覆盖应用工作流，bench_latency.py测量路由与推理速度；T4 上的 Colab 笔记本由 research/scripts/build_benchmark_nb.py 生成。若想在自己的部署上对比，docs/benchmarks.md 建议每次运行都记录检查点版本、Laya 与库版本、设备、问题数、选项数与 token 预算，并保留同样的 held-out 数据集，否则结果无法与已发布表格对齐。

一个必须知道的前提：CPU sweep 的校准列早于温度钳制

CPU sweep 中 51 语言的 ECE 与平均置信度列是在 #42 引入温度钳制（[0.5, 5]）之前产出的，因此当前包对这些受影响桶会报告不同的置信度。准确率列不受影响——温度缩放的 softmax 在任意正温度下 argmax 相同。

钳制的实现可在 laya/common.py 看到：TEMP_MIN = 0.5、TEMP_MAX = 5.0，clamp_temperature把温度限制在[0.5, 5]，非数值/非有限输入回退到中性值1.0。源码注释解释了为什么下限不能更低：已发布的choice:11+桶温度为0.1006，会把 logits 放大约 10 倍，使 0.24 的顶部概率被发布为 0.99——置信度门控会被告知一枚硬币投掷是确定性事件，所以「过硬的锐化」被拒绝应用。加载时原始值仍保留在agent.temperature_raw与agent.temperature_by_options_raw（见 laya/agent.py），仅应用钳制后的值；桶级温度仍优先于按类型温度，即使该桶走回退。

同一 51 语言、5,100 例在钳制后按两种状态复跑（research/results/cpu_51_language_sweep_clamped.json，issue #208）：

已提交	复跑·原始温度	复跑·按服务方式
macro accuracy	0.2269	0.2269	0.2269
macro ECE	0.7331	0.7331	0.5709
macro F1	0.2053	0.2053	0.2053
mean confidence（`en`）	0.9989	0.9989	0.9582
ECE（`en`）	0.1789	0.1789	0.1382

原始温度列精确复现了已提交文件，说明唯一变量就是钳制；choice:11+是它唯一改动的桶，而本次 sweep 每个问题都是 20 选项，钳制作用于全部 5,100 例，且在全部 51 语言中降低 ECE。acc_at_50_coverage（唯一使用置信度值的排序质量列）从 macro 0.3004 → 0.3020、en0.94 → 0.98，说明更平坦的分布选出了略好的一半，而非更差的一半。

头条数字：与 Jev 的一次对照

Laya	Jev（已发布）
typed-decisions（2,000 决策）	0.766	0.727
AG News（4 标签）	0.953	0.910
DAIR Emotion（6 标签）	0.600	0.480
温度拟合后 ECE	0.081	0.246
p50 延迟，1 个问题（T4）	32.8 ms	236–276 ms

需要保持审慎的口径：Jev 数字均为第三方发布、从未在本仓库测量（无 TypeSafe API 访问权限），样本量与提示词不同，只能作为参考；而 Laya 侧全部为本仓库实测。

语言覆盖：全部 51 种 MASSIVE 语言

MASSIVE intent，20 选项（随机基线 = 0.050）

laya	laya-multilingual
macro accuracy	0.2269	0.3661
macro ECE（越低越好）	0.7331	0.3869
突破 3× 随机基线的语言数	23 / 51	45 / 51

逐语言明细按路由收益排序（完整 51 行见 BENCHMARKS.md）：路由收益最大的语言是th（+0.400）、ko（+0.340）、he（+0.340）、ur/hi（+0.330）、ar（+0.290）；而英文检查点仅在en（0.820）等少数语言占优，fr（−0.050）、mn（−0.030）、pt（−0.020）、am（−0.010）上多语言检查点反而更好。km（高棉语）是最极端案例：laya 准确率0.000、置信度 0.952。

英文 vs 其余语言

任务	laya	laya-multilingual
MASSIVE intent — 英文	0.783	0.657
MASSIVE intent — 其他语言	0.306	0.451
MASSIVE scenario — 英文	0.603	0.560
MASSIVE scenario — 其他语言	0.281	0.439
XNLI — 英文	0.860	0.843
XNLI — 其他语言	0.521	0.731

结论是路由必须发生在前向传播之前：英文检查点在英文之外不是优雅退化，而是崩溃且保持高置信度（高棉语 0.000 准确率 + 0.952 置信度；其平均置信度在任何准确率水平都从不低于 0.885），因此置信度门控无法拦截它——这正是 laya/router.py 中 Router 在 <0.5 ms 纯 Python 内做语言检测、再把请求派发给正确检查点的原因。

上图四个面板分别展示：每个检查点能读取哪些语言（横轴为准确率，纵轴为 51 种语言，并标注随机基线）、单张 T4 上的延迟对比（含 Jev 参考区间）、同一公开数据集上与 Jev 的准确率对比，以及「出厂状态 vs 温度拟合后」的 ECE 变化。

应用工作流：七个真实标注主题

每个主题均为真实标注数据、400 例、三个检查点全跑。held out表示该数据源不在 Laya 的训练混合中：

主题	laya	laya-multilingual	laya-typed-decisions	数据
Email spam	0.993	0.993	0.958	在训练中
Phishing	0.980	0.993	0.940	在训练中
LLM guardrails（jailbreak）	0.708	0.755	0.762	held out
Moderation（toxicity）	0.530	0.525	0.530	held out
RAG passage relevance	0.625	0.657	0.625	在训练中
Support triage（10 路队列）	0.502	0.522	0.505	在训练中
Model routing（domain）	0.639	0.123	0.659	held out

强项：email spam 0.993 与 phishing 0.993，两者 ECE 约 0.01——接近生产级，但两者都在训练混合中。
弱项：held-out 有毒聊天上的 moderation 只有 0.530（macro-F1 0.400），在平衡切分上仅略高于随机；demo Space 有 Moderation 页，手工挑选的例子可用，真实流量不行。Guardrails 0.708–0.762 是诚实的越狱检测数字，在两个无关数据集上一致（deepset prompt-injections 单独测得 0.698）。

存在 Jev 数据的公开数据集

数据集	laya	laya-multilingual	laya-typed-decisions	Jev（已发布）
AG News（4 标签）	0.950	0.930	0.953	0.910
DAIR Emotion（6 标签）	0.595	0.530	0.600	0.480
banking77（77 标签）	0.425	0.425	0.492	0.870

banking77 是唯一明确的失利，且是架构性的：一个 choice 问题的所有选项共享固定head_max_len预算，77 个标签平均每个只有约 4 个 token，选项文本变得不可区分。两个检查点都恰好得 0.425，这正是「预算上限」而非「能力差距」的表现——把 choice 问题控制在约 20 个选项以内。Jev 支持最多 255 个选项，在 50+ 选项的单提示场景下更合适。

typed-decisions：400 例、2,000 个决策

模型	accuracy	soft acc	Brier	ECE	score MAE
`laya-typed-decisions`	0.766	0.471	0.061	0.213	0.242
`laya`	0.361	0.332	0.316	0.175	0.694
`laya-multilingual`	0.352	0.328	0.463	0.314	0.760
Jev 1.13.0（已发布）	0.727	0.580	0.148	0.144	0.391
teacher ceiling	0.735	—	—	—	—
多数类基线	0.461	—	—	—	—
随机猜测	0.318	—	—	—	—

四个工作流上的laya-typed-decisions：agent trace observability 0.730、customer service 0.764、invoice processing 0.804、security incidents 0.766。

关键限定：两个基础检查点在零样本下低于多数类基线（0.362 和 0.352 对 0.461），该基准上的全部能力来自微调。0.766 属于在该基准自身训练切分上微调出的检查点，不能外推到任意新域。

速度与校准（Tesla T4）

每次调用的问题数	laya	laya-multilingual
1	39.5 ms	32.8 ms
5	84.5 ms	40.1 ms
10	158.6 ms	72.3 ms
50	771.3 ms	337.4 ms

批量吞吐达103–332 questions/s；Jev 独立测得 236–276 ms p50，即单问题 Laya 约快6–7×。

校准：拟合温度是最高价值的修复

出厂状态	温度重拟合
`laya`	0.466	0.081
`laya-multilingual`	0.314	0.106

两个检查点出厂即过度自信，laya-multilingual出厂时完全没有拟合温度。在 held-out 数据上按（问题类型, 选项数）为每个桶重拟合一个温度，就能把 ECE 压到 Jev 实测 0.246 之下——这是可用修复中收益最高的一项。加载时温度会按上文所述被钳制到[0.5, 5]，原始值可从agent.temperature_raw检查（laya/agent.py）；钳制只是防止加载失败，并不建立校准置信度。

选项顺序鲁棒性

选项被打乱时答案改变的比例（Jev 实测为 0.13）：

套件	laya	laya-multilingual
massive_intent.en	0.150	0.230
en.emotion	0.040	0.090
xnli.en	0.000	0.015

在 20 选项下两者都不如 Jev 稳定——训练时更激进的选项顺序洗牌值得修复。

其他硬件实测：GB10、笔记本 CPU、Intel Arc

以下为路由部署（laya 0.3.5）的贡献测量，经一个小型 HTTP 服务器包装Agent.system_one，每个数字都包含一次 HTTP 往返。

NVIDIA GB10（DGX Spark, aarch64）CUDA

typed-decisions检查点（1024 ctx，默认 dtype，torch 2.14.0+cu130），GPU 与常驻 73 GB SGLang 服务器及 whisper 服务器共享；每个问题为 3 选项choice，预热后每行 40 次调用；/health环回往返 0.6 ms，网络不在数字内。

每次调用的问题数	p50	p95
1	100.2 ms	169.3 ms
5	137.7 ms	162.4 ms
10	159.3 ms	243.0 ms
50	443.1 ms	464.6 ms

每增加一个问题约7.0 ms（T4 约 14.9 ms 的一半），但单问题比 T4 的 39.5 ms更慢——每次调用约 93 ms 是 GPU 无法消除的固定开销（尚未定位去向）。在 GB10 上，把问题批量进一次调用才是提速点。另：laya_router 的 180 个标注请求上，CUDA 与 CPU 准确率逐措辞一致（0.700 vs 0.694、0.656 vs 0.656、0.611 vs 0.606），属后端浮点噪声而非行为差异。

aarch64 无 root 环境注意：Triton 首次 CUDA 调用会用gccJIT 编译 CUDA shim，缺少python3-dev时报Python.h: No such file or directory；可用apt-get download libpython3.12-dev python3.12-dev取头文件，dpkg-deb -x解包后把CPATH指向其下的usr/include与usr/include/python3.12。

笔记本 CPU（Ryzen 9 6900HX，仅 avx2，WSL2）

把 inter-op 线程钉到 1。system_one每次调用只跑一次前向，inter-op 并行没有可重叠的工作。3 问题 HTTP 调用、繁忙主机上，torch 默认（10 vCPU 上 10 intra-op / 5 inter-op）p50 达9,396 ms；torch.set_num_threads(8)+torch.set_num_interop_threads(1)降至783 ms，无代码改动即快 12 倍。inter-op 钉死后，较安静主机上单问题进程内：

intra-op 线程	p50	p95
1	910 ms	1,023 ms
4	374 ms	552 ms
8	329 ms	378 ms
10（每个 vCPU）	388 ms	708 ms

最优设置是物理核心数加一点，而非每个 vCPU 一线程——SMT 兄弟核会争抢。

Intel Arc B390（torch 2.14.0+xpu）

english检查点（421M, ModernBERT-large），进程内agent.predict()，一个 2 选项choice（约 90 token），5 次预热后每行 40 次调用；XPU 行用默认 bf16 + autocast（XPU autocast 仅支持 bf16/fp16），CPU 行 fp32 并按上述建议钉线程（intra-op 8、inter-op 1）；同一笔记本上测得，CPU 行跨会话稳定（p95 在 p50 的约 10% 内）。

每次调用的问题数	CPU p50	XPU p50	XPU p95	加速（p50）
1	288.2 ms	29.7 ms	30.4 ms	9.7×
3	730.6 ms	45.4 ms	46.8 ms	16.1×
10	2608.7 ms	96.9 ms	102.5 ms	26.9×

CPU 随问题数近似线性（288.2 → 2608.7 ms，10 倍问题 9.1 倍耗时），XPU 亚线性（29.7 → 96.9 ms，3.3 倍），因此加速从约 10× 扩大到约 27×；XPU p95 每行都保持在 p50 的约 6% 内。单问题下 Arc B390 略快于 T4 的 32.8 ms p50。

路由任务上的校准方向相反

laya_router 的 180 个请求（零样本、一个 3 层choice）上，几乎每个被测配置都是欠自信（少数例外为 +0.01～+0.06，且是准确率最低的那批）。P(chosen)（所选选项的概率，非基于熵的confidence字段）低于准确率：根检查点 + 示例引导层级描述时 −0.18（0.562 vs 0.744），typed-decisions−0.19（0.501 vs 0.694）。这是单一任务、单一标签集，不推翻上文报告的过度自信；但说明错校准方向取决于任务——无论哪种方向，在自己的数据上拟合温度都是正确修复。

服务器 CPU：AMD EPYC 9R14，4 核，Linux

research/scripts/bench_latency.py 在 AWSm7a.xlarge（4 物理核无 SMT、16 GiB RAM）以 v0.3.20 原样进程内运行：OMP_NUM_THREADS=4、device="cpu"、fp32、torch 2.14.0、transformers 5.17.0、Python 3.14.4、检查点 revision55cf4c4；问题在 3 选项choice与noul间交替，每行 2 次预热后 10 次计时。原始结果：research/results/latency_cpu_m7a_xlarge_20260924.json。

检查点	1 问题	5	10	50	冷加载
english	580 ms	3,072 ms	6,244 ms	35,969 ms	4.4 s
multilingual	193 ms	912 ms	1,842 ms	11,157 ms	2.5 s
typed-decisions	584 ms	2,819 ms	6,031 ms	35,653 ms	0.5 s

p50 值；每行 p95 都在 p50 的 2% 内。10 问题以内，english与typed-decisions每问题约 600 ms、multilingual约 185 ms；50 问题时三个检查点的单问题成本上升 15–20%。CPU 上批量问题几乎不省时（与 GB10 相反）。冷加载依赖 OS 文件缓存，该列只能视为近似；整个脚本峰值内存（最多同时加载 5 个检查点）为 9.3 GiB（最大 RSS）。

限制，直说

typed-decisions 零样本接近随机——0.766 属于微调检查点，且在该基准自身的训练切分上。
moderation 在 held-out 数据上撑不住（0.530，macro-F1 0.400）。
choice问题保持在约 20 个选项以内。
两个检查点出厂都过度自信——在自己的数据上拟合温度。
序数score是最弱的原语（SST-5 0.372）。
laya在英文之外崩溃；laya-multilingual在英文上较弱——请路由。

GPU 快速路径（TileLang）：同一答案、更高的吞吐

pip install laya[fast]+laya.load(..., fast=True)用融合 TileLang。

同一答案：三路前向的数值对比

benchmarks/parity_fast.py 用固定确定性集合（5 个预设 × 12 段文本 × 6 种语言 = 60 个状态，最多 8 个问题）分别以出厂 bf16-autocast 前向、快速路径、fp32 参考前向作答；三条路径的每个逐选项概率都写入 benchmarks/results/parity_*.json，无 GPU 也可复核。

检查点	类型	n	max \|p_fast − p_stock\|	max \|p_fast − p_fp32\|	max \|p_stock − p_fp32\|	argmax fast=stock	fast=fp32
laya	choice	48	0.031	0.022	0.024	47/48	47/48
laya	noul	180	0.076	0.043	0.058	180/180	180/180
laya	score	60	0.015	0.011	0.017	59/60	60/60
laya-multilingual	choice	48	0.049	0.015	0.039	47/48	47/48
laya-multilingual	noul	180	0.037	0.045	0.045	180/180	179/180
laya-multilingual	score	60	0.010	0.009	0.009	59/60	59/60

快速路径在每一行都贴近 fp32 参考——至多0.046，而同行的出厂路径为 0.058——且没有一行离出厂路径超过0.076。两条 bf16 路径的残差流都保持 fp32，彼此只差 bf16 累加顺序；少数 argmax 分歧都发生在近并列选项上，且每次快速路径都与 fp32 一致。唯一例外：laya-multilingual的noul上，出厂 bf16 路径比快速路径更贴近 fp32（0.0446 vs 0.0455），所以该表并不说明快速路径永远离 fp32 不更远。数据集准确率/ECE（AG News、dair-ai emotion，各 1,000 例）在噪声内完全相同——见benchmarks/bench_fast.py --eval 1000。

fp16：比 bf16 更贴近 fp32

快速路径在调用accelerate()时的 autocast dtype 下运行，因此设为 fp16（agent.dtype = torch.float16）即获得 fp16 内核与 fp16 权重；两种 dtype 下残差流与所有累加都保持 fp32。同一固定集合、parity_fast.py --dtype fp16 | bf16（RTX 4070 Ti SUPER），逐选项概率在 benchmarks/results/parity_*_rtx4070.json：

检查点	类型	n	max \|p_fast − p_fp32\| bf16	max \|p_fast − p_fp32\| fp16	argmax fast=fp32, bf16	fp16
laya	choice	48	0.022	0.004	47/48	48/48
laya	noul	180	0.043	0.005	180/180	180/180
laya	score	60	0.011	0.003	60/60	60/60
laya-multilingual	choice	48	0.015	0.002	47/48	48/48
laya-multilingual	noul	180	0.045	0.009	179/180	180/180
laya-multilingual	score	60	0.009	0.001	59/60	60/60
laya-typed-decisions	choice	48	0.019	0.002	47/48	47/48
laya-typed-decisions	noul	180	0.023	0.005	180/180	180/180
laya-typed-decisions	score	60	0.009	0.001	60/60	60/60

fp16 下快速路径比 bf16 贴近 fp32 3–10 倍，且每个 argmax 都与 fp16 出厂路径一致（864/864；对 fp16 出厂路径最多移动 0.009）。唯一一处 fp16 与 fp32 的分歧是laya-typed-decisions的一个 choice：fp32 下前两个选项只差 0.001，fp16 出厂路径同样翻转。agent.predict()延迟在两个 dtype 间无一致差异：下表每个 case、两个检查点、出厂与快速路径 alike，fp16 与 bf16 都在 10% 内（每项单次 50 次迭代）。

端到端延迟（ms，含分词）

检查点	场景	stock	fast	加速
laya（ModernBERT-large）	1 问题，72 tok	17.7	4.6	3.8×
3 问题，72 tok	18.9	6.6	2.9×
30 问题，72 tok	43.2	35.7	1.2×
30 问题，512 tok	327.5	232.1	1.4×
laya-multilingual（mmBERT-base）	1 问题，72 tok	14.1	2.8	5.1×
3 问题，72 tok	15.0	3.9	3.9×
30 问题，72 tok	22.2	17.8	1.2×
30 问题，966 tok	320.7	187.6	1.7×
laya-multilingual，AG News 评估循环	每样本 1 问题	14.9	3.2	4.7×

小请求在出厂路径上是启动开销主导（每次调用约 200 个 Python 内核启动），CUDA graph 消除了它；大批次是 GEMM 主导，融合内核约 80 TFLOPS、与 cuBLAS 相当，增益来自融合 epilogue 与滑动窗口 attention（L=1024 时比带稠密 mask 的 SDPA 快 16×）。首次使用新长度桶会编译内核（几秒，磁盘缓存）；≤256 token 的输入共享一个动态形状内核、永不重编译。

上图汇总了 Laya 与 Jev 在公开数据集准确率、各工作流、英文 vs 其余语言、T4 延迟、校准、51 语言路由后的逐语言表现以及预加载收益上的完整对比。

把基准读对：三条实用准则

准确率必须连同基线与数据切分一起读。typed-decisions 的 0.766 属于微调检查点；两个基础检查点在该基准上低于 0.461 的多数类基线。该结果支持「对相似任务微调」，并不证明未训练检查点或新域有 0.766。
置信度与准确率分开读。ECE 度量报告概率与观测正确率的匹配程度，越低越好；51 语言 sweep 的原始 ECE 列早于 #42 温度钳制，比较当前置信度请用 research/results/cpu_51_language_sweep_clamped.json。一套件上的低 ECE 也不构成另一任务/选项数的安全阈值。
在你自己数据上复测。选项顺序、措辞、布尔词标签、noul标签跟随、长文档（>4,000 token 前文后可靠性下降）都会改变结果；docs/benchmarks.md 列出了每个限制应在自己数据上验证的清单。部署前保留与已发布运行同口径的 held-out 集、记录版本与预算参数，是让任何数字可复现的前提。