把 Python 从推理链路里拿掉：Google 开源 XSE，凭什么在推荐模型上快 2–5 倍？

当所有人都在盯着大模型发布时，生产环境里大量的推理流量其实来自排序、推荐、嵌入和视觉模型。Google 开源的 XLA Serving Engine（XSE）瞄准的正是这块“沉默的大多数”：训练用 Python，服务用 C++，请求路径上没有 Python 解释器。官方称它已在内部承载超过每秒 600 万次查询（QPS），覆盖 Search、Ads、YouTube Shorts 等服务。项目 11 月 5 日在 Google 开源博客发布，本周因媒体报道再度受到关注。

一、“Train in Python, Serve in C++”是怎么实现的

1. 导出：用 xla_saved_model.save() 通过 jax.export 把模型函数降级为 StableHLO 字节码，权重存为 Orbax checkpoint；PyTorch 模型可经 torchax 转成 JAX 函数后走同一路径。
2. 打包：得到自包含目录（XLA SavedModel），含计算图、权重、目标平台、动态批处理规则、前后处理阶段、预热请求，以及可选的 AOT 可执行文件。
3. 运行：C++ 运行时基于 PJRT/IFRT 加载并编译 StableHLO，通过 gRPC 提供服务，可跑在 CPU、NVIDIA GPU 或 Cloud TPU 上。

与转 ONNX/TensorRT 不同，它不换图格式，自定义调用、Pallas 内核、分片标注理论上都能保留。

二、官方基准：快在哪里

基准使用 DLRM-DCNv2 推荐模型，单块 Cloud TPU v6e-1，服务端固定 8 个 CPU 核，要求 p99 ≤ 20 ms。对比“多进程、动态批处理的优化版 Python 服务”：

• 每请求 1 个样本：30,100 vs 6,100 examples/s，约 5.0×
• 每请求 16 个样本：83,400 vs 42,400，约 2.0×
• 每请求 128 个样本：92,400 vs 81,000，仅 1.14×

对比最朴素的单进程 Python，差距 8–36 倍。内存上 XSE 约 8.4 GiB，8 进程 Python 为 31.9 GiB（约 4 倍）。

三、三个瓶颈：GIL、设备调用、嵌入查表

• GIL：单个 Python 进程只能用到约 1.6–1.8 个核；多进程可绕开，代价是内存翻倍和 IPC 复杂度。
• 逐次设备调用开销：不批处理时吞吐被限制在每秒约 2,000–2,800 次调用；XSE 内置 C++ 批调度器合并请求。
• 嵌入查表：C++ 实现比 NumPy 每核快约 1.4 倍。

此外，在 80% 峰值的泊松负载下，XSE 的 p99 波动约 5%，多进程 Python 可达 5 倍波动，原因是 GIL 与 GC 暂停。

四、它不是什么

XSE 不是大模型服务引擎：不做连续批处理，也不管理分页 KV Cache。长文本生成仍应使用 vLLM 或 SGLang。它适合推荐、排序、视觉编码器、BERT/T5 类分类重排，以及只解码几个 token 的任务。

对开发者意味着什么

• 在线小请求场景收益最大：单条/小批、延迟敏感、高 QPS 时迁移价值明显；调用方本就发 128 条大批量时，差距只剩约 14%。
• 部署契约变简单：模型、批处理、预热、AOT 都在一个 bundle 里，镜像无需完整 Python/JAX 环境。
• 生态绑定要权衡：路径以 JAX/XLA 为中心，PyTorch 需经 torchax；已有 TensorRT/ONNX Runtime 流水线的团队应先自测。
• 对数字保持审慎：“2–5×”是 Google 自测——单一硬件切片、回环 gRPC、均匀随机稀疏 ID，Python 基线限定为标准 Python 加 NumPy，未测 Python 3.13/3.14 无 GIL 版本。基准代码已开源，可复现。

结语

XSE 的意义在于提醒我们：推理优化的主战场不只有大模型。对仍承载大部分业务流量的推荐与排序系统，去掉解释器、把批处理和预处理下沉到 C++，是确定的工程红利；红利多大，还得用自己的流量去测。