ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

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

Laya 基准测试深度解读:从 51 语言覆盖、工作流精度到 GPU 快速路径的完整实测图谱 人工智能NLP强化学习【免费下载链接】layaNon-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 Colabtyped-decisions、MASSIVE14 语言、XNLI15 语言、英文套件、延迟、选项顺序鲁棒性、校准修复research/results/t4_colab_benchmark.jsonCPU sweepMASSIVE intent 覆盖全部 51 种语言其 typed-decisions 部分part_b只覆盖英文检查点research/results/cpu_51_language_sweep.jsonApplications七类工作流主题 存在 Jev 数据的公开数据集三个检查点全跑laya 0.2.1CPU每任务 400 例种子 132026-09-19research/results/app_benchmark_results.json运行脚本与复现入口集中在 research/scripts/bench_local.py跑 51 语言 CPU sweepbench_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.0clamp_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.jsonissue #208已提交复跑·原始温度复跑·按服务方式macro accuracy0.22690.22690.2269macro ECE0.73310.73310.5709macro F10.20530.20530.2053mean confidenceen0.99890.99890.9582ECEen0.17890.17890.1382原始温度列精确复现了已提交文件说明唯一变量就是钳制choice:11是它唯一改动的桶而本次 sweep 每个问题都是 20 选项钳制作用于全部 5,100 例且在全部 51 语言中降低 ECE。acc_at_50_coverage唯一使用置信度值的排序质量列从 macro 0.3004 → 0.3020、en0.94 → 0.98说明更平坦的分布选出了略好的一半而非更差的一半。头条数字与 Jev 的一次对照LayaJev已发布typed-decisions2,000 决策0.7660.727AG News4 标签0.9530.910DAIR Emotion6 标签0.6000.480温度拟合后 ECE0.0810.246p50 延迟1 个问题T432.8 ms236–276 ms需要保持审慎的口径Jev 数字均为第三方发布、从未在本仓库测量无 TypeSafe API 访问权限样本量与提示词不同只能作为参考而 Laya 侧全部为本仓库实测。语言覆盖全部 51 种 MASSIVE 语言MASSIVE intent20 选项随机基线 0.050layalaya-multilingualmacro accuracy0.22690.3661macro ECE越低越好0.73310.3869突破 3× 随机基线的语言数23 / 5145 / 51逐语言明细按路由收益排序完整 51 行见 BENCHMARKS.md路由收益最大的语言是th0.400、ko0.340、he0.340、ur/hi0.330、ar0.290而英文检查点仅在en0.820等少数语言占优fr−0.050、mn−0.030、pt−0.020、am−0.010上多语言检查点反而更好。km高棉语是最极端案例laya 准确率0.000、置信度 0.952。英文 vs 其余语言任务layalaya-multilingualMASSIVE intent — 英文0.7830.657MASSIVE intent — 其他语言0.3060.451MASSIVE scenario — 英文0.6030.560MASSIVE scenario — 其他语言0.2810.439XNLI — 英文0.8600.843XNLI — 其他语言0.5210.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 的训练混合中主题layalaya-multilinguallaya-typed-decisions数据Email spam0.9930.9930.958在训练中Phishing0.9800.9930.940在训练中LLM guardrailsjailbreak0.7080.7550.762held outModerationtoxicity0.5300.5250.530held outRAG passage relevance0.6250.6570.625在训练中Support triage10 路队列0.5020.5220.505在训练中Model routingdomain0.6390.1230.659held out强项email spam 0.993 与 phishing 0.993两者 ECE 约 0.01——接近生产级但两者都在训练混合中。弱项held-out 有毒聊天上的 moderation 只有 0.530macro-F1 0.400在平衡切分上仅略高于随机demo Space 有 Moderation 页手工挑选的例子可用真实流量不行。Guardrails 0.708–0.762 是诚实的越狱检测数字在两个无关数据集上一致deepset prompt-injections 单独测得 0.698。存在 Jev 数据的公开数据集数据集layalaya-multilinguallaya-typed-decisionsJev已发布AG News4 标签0.9500.9300.9530.910DAIR Emotion6 标签0.5950.5300.6000.480banking7777 标签0.4250.4250.4920.870banking77 是唯一明确的失利且是架构性的一个 choice 问题的所有选项共享固定head_max_len预算77 个标签平均每个只有约 4 个 token选项文本变得不可区分。两个检查点都恰好得 0.425这正是「预算上限」而非「能力差距」的表现——把 choice 问题控制在约 20 个选项以内。Jev 支持最多 255 个选项在 50 选项的单提示场景下更合适。typed-decisions400 例、2,000 个决策模型accuracysoft accBrierECEscore MAElaya-typed-decisions0.7660.4710.0610.2130.242laya0.3610.3320.3160.1750.694laya-multilingual0.3520.3280.4630.3140.760Jev 1.13.0已发布0.7270.5800.1480.1440.391teacher ceiling0.735————多数类基线0.461————随机猜测0.318————四个工作流上的laya-typed-decisionsagent 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每次调用的问题数layalaya-multilingual139.5 ms32.8 ms584.5 ms40.1 ms10158.6 ms72.3 ms50771.3 ms337.4 ms批量吞吐达103–332 questions/sJev 独立测得 236–276 ms p50即单问题 Laya 约快6–7×。校准拟合温度是最高价值的修复出厂状态温度重拟合laya0.4660.081laya-multilingual0.3140.106两个检查点出厂即过度自信laya-multilingual出厂时完全没有拟合温度。在 held-out 数据上按问题类型, 选项数为每个桶重拟合一个温度就能把 ECE 压到 Jev 实测 0.246 之下——这是可用修复中收益最高的一项。加载时温度会按上文所述被钳制到[0.5, 5]原始值可从agent.temperature_raw检查laya/agent.py钳制只是防止加载失败并不建立校准置信度。选项顺序鲁棒性选项被打乱时答案改变的比例Jev 实测为 0.13套件layalaya-multilingualmassive_intent.en0.1500.230en.emotion0.0400.090xnli.en0.0000.015在 20 选项下两者都不如 Jev 稳定——训练时更激进的选项顺序洗牌值得修复。其他硬件实测GB10、笔记本 CPU、Intel Arc以下为路由部署laya 0.3.5的贡献测量经一个小型 HTTP 服务器包装Agent.system_one每个数字都包含一次 HTTP 往返。NVIDIA GB10DGX Spark, aarch64CUDAtyped-decisions检查点1024 ctx默认 dtypetorch 2.14.0cu130GPU 与常驻 73 GB SGLang 服务器及 whisper 服务器共享每个问题为 3 选项choice预热后每行 40 次调用/health环回往返 0.6 ms网络不在数字内。每次调用的问题数p50p951100.2 ms169.3 ms5137.7 ms162.4 ms10159.3 ms243.0 ms50443.1 ms464.6 ms每增加一个问题约7.0 msT4 约 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。笔记本 CPURyzen 9 6900HX仅 avx2WSL2把 inter-op 线程钉到 1。system_one每次调用只跑一次前向inter-op 并行没有可重叠的工作。3 问题 HTTP 调用、繁忙主机上torch 默认10 vCPU 上 10 intra-op / 5 inter-opp50 达9,396 mstorch.set_num_threads(8)torch.set_num_interop_threads(1)降至783 ms无代码改动即快 12 倍。inter-op 钉死后较安静主机上单问题进程内intra-op 线程p50p951910 ms1,023 ms4374 ms552 ms8329 ms378 ms10每个 vCPU388 ms708 ms最优设置是物理核心数加一点而非每个 vCPU 一线程——SMT 兄弟核会争抢。Intel Arc B390torch 2.14.0xpuenglish检查点421M, ModernBERT-large进程内agent.predict()一个 2 选项choice约 90 token5 次预热后每行 40 次调用XPU 行用默认 bf16 autocastXPU autocast 仅支持 bf16/fp16CPU 行 fp32 并按上述建议钉线程intra-op 8、inter-op 1同一笔记本上测得CPU 行跨会话稳定p95 在 p50 的约 10% 内。每次调用的问题数CPU p50XPU p50XPU p95加速p501288.2 ms29.7 ms30.4 ms9.7×3730.6 ms45.4 ms46.8 ms16.1×102608.7 ms96.9 ms102.5 ms26.9×CPU 随问题数近似线性288.2 → 2608.7 ms10 倍问题 9.1 倍耗时XPU 亚线性29.7 → 96.9 ms3.3 倍因此加速从约 10× 扩大到约 27×XPU p95 每行都保持在 p50 的约 6% 内。单问题下 Arc B390 略快于 T4 的 32.8 ms p50。路由任务上的校准方向相反laya_router 的 180 个请求零样本、一个 3 层choice上几乎每个被测配置都是欠自信少数例外为 0.010.06且是准确率最低的那批。P(chosen)所选选项的概率非基于熵的confidence字段低于准确率根检查点 示例引导层级描述时 −0.180.562 vs 0.744typed-decisions−0.190.501 vs 0.694。这是单一任务、单一标签集不推翻上文报告的过度自信但说明错校准方向取决于任务——无论哪种方向在自己的数据上拟合温度都是正确修复。服务器 CPUAMD EPYC 9R144 核Linuxresearch/scripts/bench_latency.py 在 AWSm7a.xlarge4 物理核无 SMT、16 GiB RAM以 v0.3.20 原样进程内运行OMP_NUM_THREADS4、devicecpu、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 问题51050冷加载english580 ms3,072 ms6,244 ms35,969 ms4.4 smultilingual193 ms912 ms1,842 ms11,157 ms2.5 styped-decisions584 ms2,819 ms6,031 ms35,653 ms0.5 sp50 值每行 p95 都在 p50 的 2% 内。10 问题以内english与typed-decisions每问题约 600 ms、multilingual约 185 ms50 问题时三个检查点的单问题成本上升 15–20%。CPU 上批量问题几乎不省时与 GB10 相反。冷加载依赖 OS 文件缓存该列只能视为近似整个脚本峰值内存最多同时加载 5 个检查点为 9.3 GiB最大 RSS。限制直说typed-decisions 零样本接近随机——0.766 属于微调检查点且在该基准自身的训练切分上。moderation 在 held-out 数据上撑不住0.530macro-F1 0.400。choice问题保持在约 20 个选项以内。两个检查点出厂都过度自信——在自己的数据上拟合温度。序数score是最弱的原语SST-5 0.372。laya在英文之外崩溃laya-multilingual在英文上较弱——请路由。GPU 快速路径TileLang同一答案、更高的吞吐pip install laya[fast]laya.load(..., fastTrue)用融合 TileLang。同一答案三路前向的数值对比benchmarks/parity_fast.py 用固定确定性集合5 个预设 × 12 段文本 × 6 种语言 60 个状态最多 8 个问题分别以出厂 bf16-autocast 前向、快速路径、fp32 参考前向作答三条路径的每个逐选项概率都写入 benchmarks/results/parity_*.json无 GPU 也可复核。检查点类型nmax |p_fast − p_stock|max |p_fast − p_fp32|max |p_stock − p_fp32|argmax faststockfastfp32layachoice480.0310.0220.02447/4847/48layanoul1800.0760.0430.058180/180180/180layascore600.0150.0110.01759/6060/60laya-multilingualchoice480.0490.0150.03947/4847/48laya-multilingualnoul1800.0370.0450.045180/180179/180laya-multilingualscore600.0100.0090.00959/6059/60快速路径在每一行都贴近 fp32 参考——至多0.046而同行的出厂路径为 0.058——且没有一行离出厂路径超过0.076。两条 bf16 路径的残差流都保持 fp32彼此只差 bf16 累加顺序少数 argmax 分歧都发生在近并列选项上且每次快速路径都与 fp32 一致。唯一例外laya-multilingual的noul上出厂 bf16 路径比快速路径更贴近 fp320.0446 vs 0.0455所以该表并不说明快速路径永远离 fp32 不更远。数据集准确率/ECEAG News、dair-ai emotion各 1,000 例在噪声内完全相同——见benchmarks/bench_fast.py --eval 1000。fp16比 bf16 更贴近 fp32快速路径在调用accelerate()时的 autocast dtype 下运行因此设为 fp16agent.dtype torch.float16即获得 fp16 内核与 fp16 权重两种 dtype 下残差流与所有累加都保持 fp32。同一固定集合、parity_fast.py --dtype fp16 | bf16RTX 4070 Ti SUPER逐选项概率在 benchmarks/results/parity_*_rtx4070.json检查点类型nmax |p_fast − p_fp32| bf16max |p_fast − p_fp32| fp16argmax fastfp32, bf16fp16layachoice480.0220.00447/4848/48layanoul1800.0430.005180/180180/180layascore600.0110.00360/6060/60laya-multilingualchoice480.0150.00247/4848/48laya-multilingualnoul1800.0450.009179/180180/180laya-multilingualscore600.0090.00159/6060/60laya-typed-decisionschoice480.0190.00247/4847/48laya-typed-decisionsnoul1800.0230.005180/180180/180laya-typed-decisionsscore600.0090.00160/6060/60fp16 下快速路径比 bf16 贴近 fp32 3–10 倍且每个 argmax 都与 fp16 出厂路径一致864/864对 fp16 出厂路径最多移动 0.009。唯一一处 fp16 与 fp32 的分歧是laya-typed-decisions的一个 choicefp32 下前两个选项只差 0.001fp16 出厂路径同样翻转。agent.predict()延迟在两个 dtype 间无一致差异下表每个 case、两个检查点、出厂与快速路径 alikefp16 与 bf16 都在 10% 内每项单次 50 次迭代。端到端延迟ms含分词检查点场景stockfast加速layaModernBERT-large1 问题72 tok17.74.63.8×3 问题72 tok18.96.62.9×30 问题72 tok43.235.71.2×30 问题512 tok327.5232.11.4×laya-multilingualmmBERT-base1 问题72 tok14.12.85.1×3 问题72 tok15.03.93.9×30 问题72 tok22.217.81.2×30 问题966 tok320.7187.61.7×laya-multilingualAG News 评估循环每样本 1 问题14.93.24.7×小请求在出厂路径上是启动开销主导每次调用约 200 个 Python 内核启动CUDA graph 消除了它大批次是 GEMM 主导融合内核约 80 TFLOPS、与 cuBLAS 相当增益来自融合 epilogue 与滑动窗口 attentionL1024 时比带稠密 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 集、记录版本与预算参数是让任何数字可复现的前提。赞分享人工智能NLP强化学习【免费下载链接】layaNon-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点击查看免费下载相关推荐DeepOpen Laya 基准测试全景51 语言、六大应用工作流、延迟与校准的完整实测解读DeepOpen Laya 基准测试全景51 语言、六大应用工作流、延迟与校准的完整实测解读 本指南以仓库根目录的 BENCHMARKS.md https:/Laya基准测试全解读51种语言横评它比TypeSafe Jev强在哪里Laya基准测试全解读51种语言横评它比TypeSafe Jev强在哪里 Laya 是一个多语言、非自回归的 System 1 决策引擎 ——它不生成文本人工智能NLP强化学习Laya vs TypeSafe Jev硬核对比51种语言基准测试数据全公开7倍速度差从何而来Laya vs TypeSafe Jev硬核对比51种语言基准测试数据全公开7倍速度差从何而来 Laya 仓库 hf_mirrors/convaiinn人工智能机器学习强化学习NLP内容安全创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表