xpu-perf
字节跳动 HPCA 2026 论文成果，提供从芯片底层到业务层全链路的 AI 加速器性能评测基准
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
微信扫码咨询客服
POMOAI — 让开源 AI 即刻运行
字节跳动 HPCA 2026 论文成果，提供从芯片底层到业务层全链路的 AI 加速器性能评测基准
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
想象一下，你的公司要采购一批 AI 推理芯片，市面上有 NVIDIA H100、Intel Gaudi、AMD Instinct、百度昆仑等多种选择。供应商都会拿出漂亮的官方 benchmark 数据，但这些数据往往在「最优条件」下测得——和你真实业务场景可能相差甚远。怎么办？
xpu-perf（Cross-Performance-Utility-Performance Benchmarking）就是来解决这个问题的。它是字节跳动在 HPCA 2026（IEEE 高性能计算体系结构国际研讨会）上发表的工作，提供了一套从芯片底层到业务层全链路打通的 AI 加速器评测方法论。
图1：字节跳动官方 GitHub 组织头像
在 AI 基础设施领域，benchmark 数据的水分是一个公开的秘密。供应商提供的跑分往往存在几个问题： 第一，测试条件与生产环境脱节。 官方评测通常在理想 batch size、理想输入长度下跑，但实际业务中，用户的请求是随机的、异构的，Prefill-Decode 分离部署（PD 分离）、连续批处理（Continuous Batching）等生产级技术会显著改变性能曲线。 第二，层间信息隔离。 芯片厂商的评测报告只关注底层算子性能，AI Infra 引擎层（vLLM、SGLang）的优化能力被忽略，serving 层的调度策略也不被考虑。结果是：底层数据很好看，上线后性能一塌糊涂。 第三，缺乏统一的跨平台评测标准。 NVIDIA 有自己的 Nsight，Intel 有自己的工具，各家评测工具互不兼容，很难横向比较。 xpu-perf 的核心贡献，就是建立了这样一套从「芯片微架构 → 算子库 → AI Infra 引擎 → 业务 trace」的垂直评测体系。论文《Characterizing Cloud-Native LLM Inference at Bytedance and Exposing Optimization Challenges and Opportunities for Future AI Accelerators》已在 HPCA 2026 发表，标志着该方法论获得了学术界认可。
xpu-perf 的仓库包含 6 个子项目，构成了一个层层递进的评测生态：
图2：Intel Gaudi2 加速卡（xpu-perf 支持的硬件后端之一）
这是 xpu-perf 的核心模块，专注于单算子性能评测。micro_perf 的设计理念是：
torch.distributed 实现进程间通信。
Backend 抽象是 micro_perf 的灵魂。基类 Backend 定义了统一的接口规范，不同硬件厂商在 vendor_ops/ 目录下实现各自的算子库。评测时，通过 ProviderRegistry 动态注册算子，实现了「一次编写、到处运行」的插件化架构。基于 micro_perf 的算子评测数据，xpu_sim 提供模型级性能仿真能力。它能快速预估一个 LLM 在特定芯片上推理时的端到端性能和 breakdown 分布，帮助工程师在硬件采购前做成本收益分析。
独立的 LLM 推理请求生成器。用户可以配置请求的到达率、输入输出长度分布、batch size 等参数，生成符合真实业务特征的 trace 文件，用于后续的仿真和实测。
针对具体部署场景的实测工具，支持 vLLM、SGLang 等主流推理框架。用户可以指定模型、部署形态（并行策略、精度）、框架，测量实际的 Prefill/Decode 吞吐和延迟。注意 infer_perf 正在重构中，old 版本已标注为过时。
LLM 训练的评测工程，基于 NVIDIA Megatron-LM，集成了多个 Dockerfile 用于不同训练场景的环境构建。
infer_perf/general_perf/backends/ 下包含了 CPU、GPU、HPU、IPU、SPU 等多种硬件后端，每个后端有独立的编译和运行时 backend 实现。这种多后端设计使 xpu-perf 成为少数能横向对比多种 AI 芯片的统一评测工具。
深入 src/xpu_perf/micro_perf/core/ 目录，可以看到 xpu-perf 的代码架构设计：
图3：Intel Gaudi 加速卡参考设计
core/backend.py（20490 字节）：定义了 Backend 抽象基类，负责初始化硬件环境、加载算子定义、发现并注册 vendor_ops。每个 Backend 实例持有 common_info（系统基本信息，如 device_count、numa_configs）和 backend_info（硬件相关信息）。
core/engine.py：实现了 ComputeEngine 和 XCCLEngine 两种计算引擎。ComputeEngine 处理单设备或单 NUMA 节点的计算任务，XCCLEngine 处理跨设备通信（all-reduce、all-gather 等集合通信操作）。引擎通过 torch.multiprocessing 启动子进程，通过 torch.distributed 初始化多节点通信环境。
core/op.py（11369 字节）：核心的 ProviderRegistry 是算子注册的枢纽。它维护三张映射表：ENGINE_OPS（每个引擎注册了哪些算子）、OP_ENGINE_MAPPING（每个算子归属于哪个引擎）、BASE_IMPL_MAPPING（每个算子的基础实现）。vendor 实现类通过 MRO（方法解析顺序）合并机制，在保留 vendor 自定义逻辑的同时，复用基类的通用实现。
core/perf_engine.py：XpuPerfServer 是 micro_perf 的服务端入口，负责加载配置、初始化 Backend 实例，并通过 PrettyTable 格式化输出系统信息、Backend 信息和环境变量。
xpu-perf 的技术栈非常简洁，以 Python 为主：
pyproject.toml 管理依赖，通过 pip install -e . 以开发模式安装。xpu-perf 是一个纯 Python CLI 工具包，没有 Web UI，也没有 Docker 一键部署。用户需要：
pip install -e . 安装 xpu-perf# 安装
git clone git@github.com:bytedance/xpu-perf.git
pip3 install -e .
cd projects/micro_perf
pip3 install -r ./requirements.txt
# 启动评测服务端
python3 ./server.py --backend GPU --device 0,1,2,3
# 发送评测请求（算子级）
python3 ./client.py --task_dir ./workloads/basic --task add
python3 ./client.py --task_dir ./workloads/xccl_ops --task all_reduce
评测结果默认保存在 reports/ 目录，同时打印到终端。报告包含 latency、throughput、内存带宽利用率等详细指标。
xpu-perf 并不是万能的，使用时需要注意以下几点：
1. infer_perf 正在重构。 旧的 infer_perf（通用小模型和 LLM 测试框架）已标记为过时，新的 infer_perf 尚未成熟。当前推荐使用 micro_perf 做算子级评测、xpu_sim 做仿真，真实场景实测推荐直接用 vLLM/SGLang 的 bench 工具。
2. 硬件依赖较强。 xpu-perf 面向的是有 AI 硬件资源的团队，不是普通开发者。没有 GPU 或其他加速卡，无法运行核心评测功能。
3. 多后端实现不均衡。 从代码结构看，GPU 后端（NVIDIA）支持最完善，HPU（Intel Gaudi）和 IPU（Graphcore）后端也有完整实现，但其他加速器的支持程度参差不齐。
4. 文档门槛较高。 README 主要面向有 AI Infra 经验的工程师，对新手不太友好。核心的设计文档（如 core/op.md）是理解架构的关键。
xpu-perf 的发布标志着大厂开始重视 AI 硬件评测标准化。在字节跳动的业务场景中，这套工具已经在指导芯片选型、发现性能瓶颈、指导优化方向等环节发挥了实际价值。 从技术趋势看，xpu-perf 代表的几个方向值得关注：