一、引言

在推理业务里，算子性能基本决定了整网的吞吐和时延。现在常见的做法，是围绕“某个模型 + 某种部署形态”，拿一次 nsys 抓一段 trace，看下热点 kernel 和瓶颈。这种方式能解决眼前的问题，但不太好复用。问题主要有几个：

• 每次都是临时脚本和配置，很难沉淀；
• 只能看到当前这一小撮 shape / 配置的表现；
• 一旦换了硬件、换了后端版本，就很难和历史数据对起来。
• 算子层作为引擎的支持层，不能把性能验证放在引擎整网验证的后面，这些性能测试的工作需要做在前面。

这个小项目想做的事情很简单：把“算子性能验证”变成一套固定流程，有统一的测试骨架、固定的计时方式、固定的写库格式。不同算子、不同后端、不同硬件的结果都能放到同一套数据里，方便后面做对比和回归。初次的代码提交的 PR 见：https://console.cloud.baidu-int.com/devops/icode/repos/baidu/hac-aiacc/aiak_ds_tool/reviews/118739725/files/base...latest

下面按照：现状问题 → 设计和实现 → 使用方式 → 总结，来展开。

二、现状与问题

从推理引擎的视角看，现在我们在算子性能上主要有这几类问题。

1. 视角过于依赖具体模型

   • 在某个模型上做 nsys 分析，只能覆盖到这一小段 shape 和配置；
   • 很难回答一个实际常问的问题：在更大的参数空间里，这个算子实现大概是什么水平。

2. 跨硬件、跨后端的数据难以对齐

   • 算子实现散落在 PyTorch、FlashAttention、FlashInfer、TRT-LLM、DeepGEMM 等各种库里，接口千奇百怪；
   • 评测脚本大多是临时写的，每次遇到新的测试需求，就要新建一个脚本测试，不利于多人合作&共享结果，以及长期维护。比如下图，虽然有组织地在维护，但是还是之后编写的同学才好跑测试，没法解耦。

   

3. 结果不易复现，缺少系统沉淀

   • 没有统一的写库和去重机制，历史结果要么在日志里，要么在 Excel 里，要么在个人脚本里；
   • 换新硬件、升级后端时，很难在已有基线的基础上快速判断，是变快了还是变慢了。

综合起来，现在算子层的调优和验收还是比较靠人。经验多的人能玩得转，新人很难接手，工程资产也堆不起来，简单来说，就是不构成体系。

三、具体工作与设计

下面把这套东西简称为「算子测试库」。

**核心思路：**在一个统一骨架下，用配置驱动算子功能 / 性能测试，然后按约定写入 SQLite，方便后续脚本化分析和画图。

3.1 整体目标