Laya 在 CPU 上多快：延迟、线程设置与部署规模（4 核实测）

没有 GPU 能不能跑 Laya？能。而且上游项目现在公开的 CPU 实测已经足够回答：到底多快、每多问一个问题要多花多少时间、哪些设置最关键。本文解读这些数据，帮你在买硬件之前先估算 CPU 部署的规模。

下面所有数字都来自上游的 Laya BENCHMARKS.md，每个数字都对应它的测试硬件和条件。

先说结论

在 4 核服务器 CPU 上，laya-multilingual 回答一个问题约 193 ms；英文和 typed-decisions checkpoint 约 580 ms。
在 CPU 上，耗时几乎随问题数线性增长。把多个问题合并成一次调用几乎不省时间，这和 GPU 不一样。
线程设置的影响可能比模型本身还大。 在一台笔记本上，只改了 torch 的默认线程设置，调用就快了约 12 倍。
冷启动要几秒，同时加载多个 checkpoint 可能占用约 9 GiB 内存，所以部署服务时要预加载。

服务器 CPU 实测

测试环境：AWS m7a.xlarge（AMD EPYC 9R14，4 个物理核，无超线程，16 GiB 内存），Laya v0.3.20，fp32，OMP_NUM_THREADS=4，进程内调用。每次调用交替使用一个 3 选项的 choice 和一个 noul 问题。表中是 p50，每一行的 p95 与 p50 相差都在 2% 以内。

checkpoint	1 个问题	5 个	10 个	50 个	冷启动
`laya`（英文）	580 ms	3,072 ms	6,244 ms	35,969 ms	4.4 s
`laya-multilingual`	193 ms	912 ms	1,842 ms	11,157 ms	2.5 s
`laya-typed-decisions`	584 ms	2,819 ms	6,031 ms	35,653 ms	0.5 s

有两点值得注意。

多语言 checkpoint 在 CPU 上快约 3 倍。 它基于 mmBERT-base（3.22 亿参数），而不是 ModernBERT-large（4.21 亿参数）。上游没有拆解剩下的差距来自哪里，所以请把"3 倍"当作这台机器上的实测结果，而不是通用规律。

p95 和 p50 几乎一样。 在空闲的服务器上，CPU 延迟非常稳定。我们的理解是，这让容量规划比共享 GPU 更简单。

为什么在 CPU 上合并提问没用

10 个问题以内，英文和 typed-decisions checkpoint 每多一个问题约多 600 ms，多语言 checkpoint 约多 185 ms。到 50 个问题时，每个问题的成本还会再上升 15%–20%。也就是说，一次调用问 10 个问题，和分 10 次调用花的时间差不多。

GPU 的表现不同：

硬件	1 个问题	50 个问题	每多一个问题
Tesla T4，`laya`	39.5 ms	771.3 ms	约 15 ms
NVIDIA GB10，`laya-typed-decisions`（经 HTTP）	100.2 ms	443.1 ms	约 7 ms
EPYC 4 核 CPU，`laya`	580 ms	35,969 ms	10 个以内约 600 ms，之后更多

在 GB10 上，每次调用大约有 93 ms 是固定开销，所以把问题合并进一次调用才是提速的关键。CPU 上几乎没有可摊薄的固定开销，设计思路反而更简单：只问真正需要的问题。

线程设置：最容易拿到的 12 倍

上游还公开了一组笔记本实测（Ryzen 9 6900HX，WSL2），值得最先照做。在繁忙的机器上使用 torch 默认线程设置（10 个 vCPU 上 10 个 intra-op、5 个 inter-op 线程），一次经 HTTP 的三问题调用 p50 是 9,396 ms。只加两行设置就降到 783 ms，快了约 12 倍，代码逻辑完全不用改：

import torch

torch.set_num_threads(8)          # 约等于物理核数
torch.set_num_interop_threads(1)  # 每次调用只有一次前向计算，没有可并行的部分

同一台笔记本上，进程内回答一个问题：1 线程 910 ms，4 线程 374 ms，8 线程 329 ms，用满所有 vCPU 反而变慢到 388 ms。上游的建议是：线程数设为物理核数再多一点点，而不是每个 vCPU 一个线程，因为超线程的兄弟核会互相争抢。如果你用的是自托管服务，LAYA_THREADS 控制的就是这个设置。

冷启动与内存

在这台 EPYC 机器上，英文 checkpoint 冷启动 4.4 秒，多语言 2.5 秒。这些数字受系统文件缓存影响，只能作为参考。实际部署时有两点：

预加载要服务的 checkpoint（Router(preload=True)），不要等第一个请求来了再加载。
预留内存。 基准脚本同时加载最多五个 checkpoint 时，峰值内存为 9.3 GiB。只服务较少的 checkpoint 应该会少一些，但上游没有给出单个 checkpoint 的数字，请在自己的机器上实测。

什么时候用 CPU 就够了？

下表是我们根据上面数据做的解读，不是实测结果，并假设每次调用只问一个问题：

你的场景	CPU 够用吗？
后台任务、队列、夜间批量分类	够。延迟不敏感，成本更重要。
非英文文本的实时路由或工单分流	通常够。`laya-multilingual` 约 0.2 秒，很多界面都能接受。
每个请求要问好几个问题的英文实时决策	勉强。英文 checkpoint 问 5 个问题约 3 秒。
高吞吐、低延迟服务	用 GPU。T4 回答一个问题只要 32.8–39.5 ms。

以上都是单进程、进程内的数字。真实部署还会有 HTTP、排队和并发的影响，所以上线前请用自己的硬件和问题实测。上游的测试脚本是 research/scripts/bench_latency.py。

数据来源

Laya BENCHMARKS.md：服务器 CPU、笔记本 CPU、T4 和 GB10 部分
EPYC 原始结果