MLIR与TVM（张量虚拟机）的对比与互操作一个让我熬夜到凌晨三点的bug去年做AI加速器后端的时候，遇到一个诡异的性能问题。同一个ResNet-50模型，用TVM编译跑在自研NPU上，推理延迟比预期高了40%。我翻遍了TVM的调度日志，发现算子融合做得很好，内存分配也没问题。直到我dump出TVM生成的LLVM IR，再用MLIR的mlir-opt工具跑了一遍规范化，才发现问题出在TVM的Relay IR到LLVM IR的降级过程中——一个本应被消除的reshape操作被保留了下来，导致后续的内存访问模式被打乱。这个经历让我意识到，MLIR和TVM虽然目标相似（都是解决深度学习编译的中间表示问题），但它们的哲学、设计取舍和适用场景有本质差异。更关键的是，它们不是非此即彼的关系——在实际工程中，我们经常需要让两者协同工作。TVM的Relay IR：为张量计算而生TVM的Relay IR是典型的“领域专用中间表示”。它的设计围绕一个核心假设：所有计算都是张量操作。这意味着Relay的每个节点天然携带形状信息、数据类型、布局（如NHWC vs NCHW）等张量元数据。// Relay IR片段：一个简单的卷积+ReLU fn (%x: Tensor[(1, 3, 224, 224), float32]) { %w = var("weight") %conv = nn.conv2d(%x, %w, padding=[1,1], strides=[2,2]) %relu =
MLIR与TVM（张量虚拟机）的对比与互操作一个让我熬夜到凌晨三点的bug去年做AI加速器后端的时候，遇到一个诡异的性能问题。同一个ResNet-50模型，用TVM编译跑在自研NPU上，推理延迟比预期高了40%。我翻遍了TVM的调度日志，发现算子融合做得很好，内存分配也没问题。直到我dump出TVM生成的LLVM IR，再用MLIR的mlir-opt工具跑了一遍规范化，才发现问题出在TVM的Relay IR到LLVM IR的降级过程中——一个本应被消除的reshape操作被保留了下来，导致后续的内存访问模式被打乱。这个经历让我意识到，MLIR和TVM虽然目标相似（都是解决深度学习编译的中间表示问题），但它们的哲学、设计取舍和适用场景有本质差异。更关键的是，它们不是非此即彼的关系——在实际工程中，我们经常需要让两者协同工作。TVM的Relay IR：为张量计算而生TVM的Relay IR是典型的“领域专用中间表示”。它的设计围绕一个核心假设：所有计算都是张量操作。这意味着Relay的每个节点天然携带形状信息、数据类型、布局（如NHWC vs NCHW）等张量元数据。// Relay IR片段：一个简单的卷积+ReLU fn (%x: Tensor[(1, 3, 224, 224), float32]) { %w = var("weight") %conv = nn.conv2d(%x, %w, padding=[1,1], strides=[2,2]) %relu =
