1. 项目缘起为什么我们需要一个面向编译器的张量框架基准测试在AI工程和系统研发的一线我们经常面临一个尴尬的局面当一个新的AI编码助手比如GitHub Copilot、Cursor、Claude Code或者各种开源模型发布时大家都会兴奋地用它来写一些“Hello World”或者LeetCode题目看看它能不能生成正确的冒泡排序。然而一旦我们把这些工具带到真实的、复杂的生产环境中——比如为一个全新的、基于编译器的张量计算框架编写算子或优化代码——它们的表现往往就变得难以预测甚至令人失望。这就是“TensorBench”这个想法诞生的背景。我所在的团队在过去几年里一直在深度参与一个自研的、基于MLIR多级中间表示的深度学习编译器项目。这个框架的核心思想是将用户定义的高层张量操作通过多级中间表示和一系列优化Pass最终编译成针对特定硬件如CPU、GPU、AI加速器的高效代码。在这个过程中开发者需要编写的不是简单的Python脚本而是涉及IR中间表示构建、模式匹配、图变换、内存布局优化等复杂概念的C/Python混合代码。我们尝试让团队成员使用各种AI编码助手来加速开发结果却五花八门有的助手生成的代码语法正确但语义完全错误把卷积算子的维度搞反有的能写出看似合理的MLIR片段却忽略了关键的属性设置导致编译失败还有的甚至无法理解“张量”、“Stride”、“MemRef”这些在我们日常对话里高频出现的专业术语。于是一个念头变得清晰起来市面上缺少一个能真正衡量AI编码助手在“硬核”系统软件领域——特别是编译器与张量计算交叉领域——能力的基准测试。现有的基准大多面向通用编程或Web开发而像TensorFlow、PyTorch内部那样复杂的、基于编译器的张量操作实现对代码生成模型提出了截然不同的挑战。这不仅仅是语法正确性问题更是对领域知识、API熟悉度、甚至对底层计算语义理解能力的综合考验。“TensorBench”的目标就是填补这个空白。它不是一个简单的代码补全测试而是一个系统的评测套件专门用于评估和比较不同AI编码代理Coding Agents在为一个真实的、编译器驱动的张量框架进行开发时的综合能力。这对于框架开发者、AI工具评测者乃至整个开源社区选择和使用合适的编码辅助工具都具有实实在在的参考价值。2. TensorBench的核心设计哲学超越语法正确性设计一个基准测试尤其是面向特定领域的基准首先要明确“考什么”和“怎么考”。对于TensorBench我们摒弃了仅以“代码能否通过编译”或“输出是否符合预期”作为单一标准的简单思路。在一个编译器框架中一段能编译通过的代码完全可能因为一个细微的属性设置错误导致运行时性能下降几个数量级或者产生完全错误的结果。因此TensorBench的设计围绕以下几个核心维度展开这些维度共同构成了评估一个AI编码代理是否“真正有用”的标尺2.1 领域知识理解度这是基础也是门槛。模型是否理解张量计算的基本概念例如数据排布Layout能否区分NCHW和NHWC是否知道在某些硬件上特定的排布能带来显著的性能提升数据类型DType是否清楚bf16和fp16在精度和范围上的区别是否知道某些算子如整数卷积对输入数据类型有特定要求广播Broadcasting与维度Shape语义能否正确推断并应用广播规则能否处理动态形状Dynamic Shape的情况在TensorBench的任务中我们会设计一些场景要求模型根据自然语言描述或简化的数学定义生成对应的张量操作。例如“请实现一个函数计算两个四维张量在特定轴上的批矩阵乘法batched matmul并支持自动广播。” 模型不仅需要生成正确的循环或调用正确的库函数更需要理解“批矩阵乘法”的数学定义及其在内存中的实现方式。2.2 编译器框架API的熟练度每个编译器框架都有其独特的抽象和API。以MLIR为例开发者需要操作OpBuilder来创建操作Operation设置各种Attribute和Type并通过PatternRewriter进行图变换。API调用准确性模型生成的代码是否使用了正确的API参数顺序是否正确例如创建memref.load操作时索引参数的列表是否正确传递。惯用法Idiom识别框架中常见的代码模式是什么例如如何优雅地遍历一个张量的所有元素如何创建一个新的、具有相同类型但不同形状的MemRef模型能否生成符合社区最佳实践的、地道的代码而不是虽然功能正确但显得笨拙或低效的代码。TensorBench会包含一系列针对特定框架初期以类MLIR框架为原型的“填空”或“补全”任务评估模型对API用法的掌握程度。2.3 语义正确性与边界条件处理这是区分“玩具代码”和“生产级代码”的关键。编译器领域的代码对正确性的要求极为严苛。内存安全生成的代码是否存在越界访问是否正确处理了空张量或零尺寸维度数值稳定性在实现如softmax、layer normalization等算子时是否考虑了数值溢出问题例如使用max减法技巧特殊值处理如何处理NaN、Infinity对于归约操作如sum、mean空输入的返回值应该是什么TensorBench的任务会故意包含一些边界案例观察AI代理是能主动识别并妥善处理还是生成存在潜在风险的代码。例如要求“实现一个计算张量均值的函数”一个成熟的代理应该考虑到除零错误并可能生成带有条件判断的代码。2.4 优化意识与性能感知在编译器上下文中代码的性能往往和正确性同等重要。AI代理是否具备初步的优化意识局部性优化生成的循环顺序是否有利于缓存利用是否避免了不必要的内存搬运。向量化/并行化机会识别代码结构是否便于后续的自动向量化或线程并行例如循环边界是否是编译期常量循环体是否是无副件的。中间表示IR的“友好性”生成的IR是否干净、规范便于后续优化Pass进行分析和变换还是充满了冗余和难以分析的复杂结构。这部分评估相对高级TensorBench可能会提供一些性能对比的基线或者设计一些任务其中“性能更优的实现”在代码模式上有可识别的特征例如使用特定的内置算子组合来代替手写循环。2.5 交互与调试能力真实的开发过程是交互式的。AI编码代理不应只是一个单次代码生成器更应是一个可以对话、可以理解错误信息、并据此进行修正的伙伴。理解编译错误当生成的代码导致编译器报错时代理能否正确解析错误信息如“未定义的类型”、“操作数不匹配”并给出准确的修正建议响应增量修改要求用户提出“将这里的数据类型从fp32改为bf16并相应调整缩放因子”时代理能否进行连贯的、影响范围正确的修改TensorBench计划设计一个“多轮交互”评测轨道模拟真实的调试场景。初始阶段给出一个有缺陷或不完整的代码片段以及编译器的错误输出评估代理在后续轮次中定位和修复问题的能力。3. TensorBench的评测任务体系构建基于上述设计哲学我们构建了一个多层次、多任务类型的评测体系。TensorBench不是一个单一的“试卷”而是一个“题库”可以根据评测目标灵活组合任务。3.1 任务类型一代码生成从零开始这是最直接的任务类型。给定一个自然语言或形式化描述的需求要求生成完整的函数或算子实现。示例任务实现一个2D平均池化Average Pooling算子。输入描述 “输入张量input形状为[N, C, H, W]数据类型为float32。池化窗口大小为[kH, kW]步幅为[sH, sW]填充为[padH, padW]假设为‘SAME’填充模式。请计算输出张量output其中每个输出元素是输入窗口内元素的平均值。”评估点正确推导输出形状模型是否知道output_height (H 2*padH - kH) / sH 1并处理整数除法正确实现嵌套循环循环边界是否正确内存访问索引计算是否正确考虑填充正确处理填充在“SAME”填充下输入窗口可能越界模型是选择忽略越界部分即有效窗口面积可能小于kH*kW还是实现了复杂的填充值引入这体现了对算子语义细节的理解深度。数值处理累加和是否使用float中间变量最后除法是否使用float除法是否考虑了除零保护尽管在kH, kW0时不会发生但体现防御性编程思想生成代码的评估我们将同时从多个角度评估生成的代码编译通过率最基本的门槛。运行时正确率使用随机生成的输入数据与一个经过验证的参考实现如NumPy实现进行结果对比计算数值误差。代码质量通过静态分析工具检查是否有明显的性能陷阱如循环内重复计算、或潜在的内存安全问题。领域知识契合度人工评审代码是否使用了框架推荐的API或模式。3.2 任务类型二代码补全与填空这类任务模拟了日常开发中最常见的场景——在现有代码基础上进行完善。示例任务补全一个矩阵乘法融合ReLU激活的优化模式。给出上下文 一段MLIR的PatternRewrite代码框架其中已经定义了匹配matmul操作的模式并获取了其操作数。给出任务 “请补全重写逻辑如果该matmul操作的结果立即被一个relu操作消费则将这两个操作融合为一个新的、自定义的matmul_relu操作。注意需要创建新的操作、转移所有原始属性、并处理操作数链接。”评估点API使用的精确性是否正确使用PatternRewriter的replaceOp或createOp方法IR构建的完整性是否记得设置新操作的所有必要属性如转置标志、数据类型操作数链接的正确性是否将原matmul的操作数正确连接到新的matmul_relu操作上模式匹配的严谨性生成的代码是否考虑了relu可能不是唯一消费者的情况虽然任务已简化但代码是否留有清晰的扩展接口也能看出设计意识。3.3 任务类型三错误诊断与修复模拟调试过程评估AI代理的“排错”能力。示例任务诊断并修复一个导致编译失败的IR片段。给出代码 一段存在错误的MLIR代码例如一个memref.store操作试图将一个f32值存储到一个i32类型的MemRef中。给出编译器错误信息error: memref.store op type mismatch: storing a value of type f32 into a memref of element type i32。评估点错误定位代理能否准确指出错误发生在哪一行、哪一个操作根因分析能否理解错误的核心是类型不匹配修复方案提出的修复方案是否合理是建议修改存储值的类型例如插入一个arith.truncf或arith.fptosi转换还是修改MemRef的类型哪种方案更符合上下文的语义修复的完整性修复方案是否只解决了当前错误还是能考虑到相关的连锁反应例如如果修改了MemRef类型其他使用该MemRef的操作是否需要同步调整3.4 任务类型四文档与注释生成良好的文档是可持续开发的基础。此任务评估代理能否根据代码生成清晰的注释或API文档。示例任务为一段实现张量转置Transpose的复杂IR生成函数头注释。给出代码 一个实现了支持任意维度排列的通用转置操作的函数。评估点摘要准确性生成的单行摘要是否准确概括了函数功能参数描述是否清晰说明了每个参数的意义如permutation数组的定义副作用说明是否注明了该操作是否原地in-place是否分配了新内存示例是否提供了简单的调用示例这对于理解如何使用复杂API至关重要。4. 实施TensorBench从数据集构建到自动化评测有了清晰的任务设计下一步就是将其工程化构建一个可运行、可扩展、公平的评测系统。4.1 数据集构建与质量控制数据是基准的基石。我们采用“众包专家校验”的方式构建任务。来源真实项目代码从开源编译器框架如MLIR、TVM的测试用例、教程和核心算子实现中提取代码片段并将其“转化”为任务。例如将一个完整的算子实现隐去核心循环部分作为填空任务。合成任务根据张量计算和编译器领域的常见模式系统性地合成任务确保覆盖不同的操作类型元素级、规约、卷积、矩阵运算、数据类型和复杂度。社区贡献设计模板邀请领域开发者提交他们工作中遇到的、认为适合考验AI的典型编码场景。质量校验每个任务都必须有标准答案或验证脚本。对于代码生成任务验证脚本需要能编译、运行并通过一系列测试用例。设立“陷阱题”故意在任务描述中留下模糊之处或提供存在常见错误的初始代码观察AI代理是盲目执行还是能提出澄清性问题在多轮交互模式下或识别出潜在问题。所有任务需经过至少两位领域专家的交叉评审确保其技术正确性、代表性和评估目标的明确性。4.2 评测流水线设计评测需要全自动化以确保结果的可复现性和公平性。我们设计了一个基于容器的评测流水线任务描述 初始代码/上下文 - AI编码代理 - 生成代码/补丁/回答 - 安全沙箱执行 - 多维度评估 - 综合评分环境隔离每个任务都在一个干净的Docker容器中执行预装好特定的编译器框架如MLIR项目和必要的依赖。这保证了评测环境的一致性并隔离了潜在的安全风险。代理接口我们定义一个统一的API接口任何AI编码代理无论是本地运行的模型、还是云端服务只要实现该接口就能接入TensorBench进行评测。接口通常包括generate_code(prompt, context)suggest_fix(code, error_message)等。安全沙箱生成的代码首先会在资源受限的沙箱中进行编译。编译失败会直接记录错误。编译成功的代码会使用验证脚本在沙箱中运行。沙箱限制网络访问、内存和CPU时间防止恶意或错误代码对主机系统造成影响。多维度评估器编译检查器记录编译是否成功以及警告信息。运行时验证器执行测试用例比对输出与预期结果的误差对于浮点计算使用相对误差或ULP误差容忍度。静态分析器使用Clang-Tidy、自定义的MLIR验证规则等检查代码风格、潜在bug和性能反模式。人工评估接口对于代码质量、文档清晰度等难以完全量化的维度提供便捷的界面供专家进行评分和评论。4.3 评分机制与排行榜单一的分数没有意义。TensorBench会提供一个多维度的评分卡和排行榜。分轨道评分针对“代码生成”、“代码补全”、“错误修复”、“文档生成”等不同任务类型分别计算得分。综合能力分根据任务难度加权计算一个总体得分。细粒度指标通过率编译通过且运行时测试用例全部通过的任务比例。首次正确率在代码生成任务中首次提交即完全正确的比例。平均修复轮次在错误修复任务中需要多少次交互才能完全修复问题。代码效率分基于静态分析结果和在可能的情况下微基准测试的性能数据。代码风格分符合框架约定俗成的编码规范的程度。排行榜允许不同AI代理提交结果并按照上述指标进行排名。同时提供任务级别的详细报告让使用者能清楚知道某个代理在哪些方面强在哪些方面弱。5. 实战挑战与避坑指南构建基准测试中的“坑”在具体实施TensorBench的过程中我们遇到了不少挑战也积累了一些经验教训。这些“坑”对于任何想从事类似领域特定基准测试的团队都有参考价值。5.1 任务描述中的模糊性与偏见最初我们的一些任务描述过于简略或包含了隐含的假设。例如“实现一个矩阵乘法”。这立刻引发了问题支持转置吗支持批量吗数据类型是什么内存布局是行优先还是列优先不同的AI代理基于其训练数据的不同可能会做出不同的、但都“合理”的假设导致结果无法公平比较。解决方案我们制定了严格的任务描述规范。每个任务描述必须明确函数签名包括完整的输入/输出参数、类型、以及它们是张量、标量还是其他结构体。数学定义用公式或伪代码清晰定义操作语义。对于有歧义的操作如池化的填充模式必须明确指定。边界条件与特殊值明确说明期望的行为例如空输入、NaN输入该如何处理。非功能性要求如果重要例如“请尽量生成向量化友好的循环结构”。5.2 验证脚本的“过度拟合”风险验证脚本是判断对错的“金标准”。但这里有一个陷阱如果验证脚本本身编写得过于宽松或者只测试了少数几种情况那么生成的代码即使有潜在bug也可能通过测试。反之如果验证脚本过于严格例如对浮点比较使用了过小的容差一些数值上合理但实现细节不同的正确代码也可能被误判。解决方案全面的测试用例为每个任务生成多样化的测试输入包括典型值、边界值如零、极大值、极小值、随机值。对于数值计算使用高精度的参考实现如Python的decimal库或双精度计算作为对比基准。合理的比较容差对于浮点数使用相对误差relative error或ULPUnits in the Last Place误差进行对比并设置一个符合该操作数值特性的合理阈值。模糊测试Fuzzing在验证阶段引入模糊测试用大量随机输入去“冲击”生成的代码以发现那些在特定测试用例下隐藏的崩溃或错误。5.3 评估AI代理交互能力的复杂性评测多轮交互能力比评测单次生成要复杂得多。我们需要模拟一个“用户”。这个用户应该如何回应AI代理的提问或建议如果AI代理请求澄清我们应该提供多少信息这直接影响到评测的公平性。解决方案我们设计了一个标准化的“对话策略”。澄清请求如果AI代理提出的问题是任务描述中已明确包含的信息则标准“用户”会直接引用任务描述中的相关部分进行回复。如果问题涉及未明确的合理假设“用户”会根据一个预设的知识库给出中立、准确的回答例如“框架默认使用行优先内存布局”。错误修复迭代当AI代理提交一个修复方案但未完全解决问题时“用户”会提供编译器或测试失败产生的新错误信息。我们设定一个最大交互轮次例如5轮超过则视为任务失败。记录对话历史整个交互过程被完整记录作为评估的一部分。我们可以分析AI代理提问的质量、修复路径的效率等。5.4 基础设施与性能开销运行一个完整的基准测试尤其是涉及编译和运行C代码是计算密集型的。评测成百上千个任务对多个AI代理进行测试需要可观的计算资源。解决方案容器化与缓存充分利用Docker层缓存将编译器工具链等基础环境预先构建好。对于相同的任务和AI代理缓存评测结果。分布式执行设计评测系统可以分布式地在多台机器上并行执行任务。分层评测设计一个“快速筛选”阶段只运行一小部分核心任务对AI代理进行初步排名。详细的、耗时的全量测试只对表现优异的代理或用于最终报告时进行。6. TensorBench的潜在影响与未来展望构建TensorBench不仅仅是为了给AI编码工具排个名次。它的价值体现在多个层面对于AI模型研究者与开发者TensorBench提供了一个聚焦于系统软件和编译器领域的、高质量的评估数据集和标准化的评测平台。它可以帮助他们诊断模型弱点清晰地看到自己的模型在领域知识、API使用、复杂逻辑推理等方面的具体不足。指导训练数据构建了解哪些类型的代码或知识是模型欠缺的从而有针对性地扩充训练数据例如增加更多MLIR代码、编译器原理注释等。推动能力边界激励大家开发更能理解复杂系统、进行深层推理的代码生成模型。对于编译器与框架开发者TensorBench可以降低入门门槛一个强大的、精通本框架的AI编码助手可以极大减少新贡献者的学习成本帮助他们快速上手为框架贡献代码。提高开发效率自动化生成样板代码、测试用例、甚至某些模式化的优化转换让核心开发者能更专注于高层次的架构和创新。改善文档与教程利用AI辅助生成更准确、更丰富的API文档和示例代码。对于广大开发者TensorBench的排行榜和详细报告可以作为一个实用的选型指南。当需要为一个新的编译器相关项目选择AI编程伙伴时你可以清楚地看到哪个工具在“MLIR代码补全”上表现最好哪个在“张量算子调试”上更胜一筹。未来的扩展方向支持更多框架从以MLIR为原型的任务扩展到TVM、Halide、XLA等其他主流张量编译器/DSL。任务复杂度升级引入涉及多级优化、循环变换、自动调度等更高级编译器技术的任务。集成到开发流程将TensorBench任务作为持续集成CI的一部分监控AI辅助工具在项目代码库上的表现变化。探索“合作编程”评测不仅评测AI生成完整代码的能力也评测它在结对编程Pair Programming场景中理解人类意图、提供即时建议的能力。构建TensorBench的过程本身就是一次对“AI如何赋能复杂系统开发”的深度探索。它迫使我们去量化那些原本被认为很“玄学”的开发者体验和效率提升。这个基准测试的最终目的不是要证明哪个AI是最聪明的而是要推动整个生态向前发展让机器能更好地理解人类的创造意图特别是在创造那些驱动AI自身发展的底层系统时。这条路还很长但每一步扎实的评测和改进都让我们离这个目标更近一点。