几位做训练框架和推理优化的朋友最近都在讨论同一个现象深度学习编译器Deep Learning Compiler的前端环节出现的问题往往最难排查而且耗时最长。传统上大家把注意力放在算子的 Kernel 优化、后端调度、内存复用这些“技术含量更高”的部分但真正把项目拖入泥潭的却常常是 AST 变换、算子语义映射、Shape 推导、属性解析这些“看起来简单”的前端代码。于是当一篇名为 “Demystifying Deep Learning Compiler Front End Bugs: An LLM-Aided Empirical Study” 的研究出现时很多人开始重新审视编译器前端的 Bug 类型和修复模式。这篇文章不是把这本论文复述一遍而是站在工程视角把“深度学习编译器前端 Bug”这个概念拆开讲清楚重点说三件事前端到底在做什么、Bug 为什么这么多、以及如何用 LLM 辅助做 Bug 分析与实证研究。文中会给出可运行的示例代码、分析工作流和工程建议适合编译器初学者、AI Infra 开发者和准备做相关实证研究的同学收藏。1. 深度学习编译器前端它到底在做什么1.1 从一个最小计算图说起在理解前端 Bug 之前先把“前端”的职责范围界定清楚。深度学习编译器的整体框架通常分成三层模型定义PyTorch / TensorFlow / ONNX ↓ 前端Front End ↓ IR / 计算图 中端Optimizer / Pass ↓ IR 变换与优化 后端Back End / Codegen ↓ 目标设备指令CPU / GPU / NPU前端要做的事情是“把用户写的模型表示成一个编译器能看懂、能分析的中间表示IR”。这里说的“模型”可以是 PyTorch 的nn.Module也可以是 ONNX 文件、TensorFlow SavedModel甚至是一段自定义 DSL 代码。用一个最简单的加法计算图来理解# 用户视角 import torch import torch.nn as nn class AddModel(nn.Module): def forward(self, x, y): return torch.add(x, y)编译器前端需要把这个AddModel转换成类似下面的 IRfunc.func main(%x: tensor?xf32, %y: tensor?xf32) - tensor?xf32 { %0 tosa.add(%x, %y) : (tensor?xf32, tensor?xf32) - tensor?xf32 return %0 : tensor?xf32 }这个转换过程涉及大量机械但容易出错的步骤参数检查、算子映射、属性提取、类型推断、Shape 推导、子图切分等。任何一个环节处理不好都会静默产生错误结果或者直接编译报错。1.2 前端为什么要单独划分出来可以把深度学习编译器前端看成“翻译官”。它负责把描述性模型描述你要算什么翻译成可执行/可优化的计算图描述怎么算。这里有一个关键差异用户模型里没有显式的执行顺序、内存布局、算子融合标记而 IR 必须包含这些信息才能支撑后续优化与代码生成。因此前端需要做算子语义映射把torch.add、tf.nn.relu、ONNXReshape等高层算子映射到编译器内部算子集。Shape/Type 推导根据输入张量的 shape 和 dtype 推导中间结果的信息。属性解析与合法化把用户层的属性如transpose、keepdim、padding解析成 IR 中可操作的结构化属性。控制流转换把 Python 的if、for、while转换为 IR 的scf.if、scf.for、scf.while等结构。边界情况对齐处理标量提升、维度广播、空张量、动态 shape 等边界场景。这些任务听起来不复杂但组合起来非常容易出错。尤其是边界情况和算子组合场景任何一个分支没覆盖到就可能导致编译错误或结果错误。1.3 常见的前端框架实际接触到的深度学习编译器前端主要有这几类框架前端输入IR 风格特点TVMRelay / TorchScript / ONNXRelay IR / TIR生态成熟前端模块较多社区问题丰富MLIRStableHLO / TOSA / LinalgMLIR 方言体系模块化强方言多前后端边界清晰XLAHLOHLO IR主要服务 TensorFlow/JAX对数组语义有强假设GlowCaffe2 / ONNXGlow IR偏移动端早期 C 实现IREEStableHLO / TOSAMLIR 方言基于 MLIR面向部署场景这些前端各有偏向但共性问题是一致的要么算子映射不完整要么 Dialect 之间转换丢属性要么 shape 推导不保守。2. 前端 Bug 的常见类型与根因分析2.1 为什么前端 Bug 容易被低估很多开发者的直觉是前端只是“转换程序”把 A 转成 B逻辑简单出 Bug 概率不高。但实际工程中前端 Bug 率并不低原因有三点输入组合爆炸同一个算子在不同框架里有不同的语义约束。PyTorch 的reshape和 ONNX 的Reshape在输入顺序上就不同PyTorch 是(tensor, shape)ONNX 是(data, shape)属性位置也可能不同。语义边界模糊tensor?xf32这种动态 shape 在编译期无法确定大小。前端要决定是报错、保守展开、还是沿用动态尺寸。不同框架选择不同产生大量边界行为差异。需要同时维护多套结构一个算子模型可能要转成 TOSA、Linalg、StableHLO 三种方言还得处理各方言之间的转换 Pass。三层转换意味着三层出错可能性。2.2 前端 Bug 的典型分类结合常见深度学习编译器 issue前端 Bug 大致可以分成下面几类算子映射错误Op Mapping把一个框架算子映射到 IR 算子时参数顺序、属性名、默认值处理错误。典型例子torch.mean的dim传成axis或keepdim解析错误。Shape 推导错误Shape Inference因为输入 shape 分布不均、负维度、动态维度处理不对导致中间 shape 推到错误值。典型现象算子输出 shape 与预期不一致。类型推导错误Type Inference把f32推成f64或者把整数算子的输出类型推断错误。常见于混合精度、量化模型。属性解析错误Attribute ParseIR 里的属性被丢、被默认值覆盖、或者类型不匹配。典型现象某个pad少了一维。控制流转换错误Control Flowif、for转换成 IR 结构时条件变量错误捕获或循环边界错误。方言转换错误Dialect Lowering从高层方言降到低层方言时语义被“简化”过头。典型例子tosa.add转成linalg.generic时广播语义出错。这些 Bug 的共性特征是错误往往不是崩溃而是静默错误结果。比如 Shape 推断错一位后续 Pass 不会报错最后生成出来的 Kernel 结果错误且极难定位。2.3 一个前端 Bug 的“生命周期”视角前端 Bug 在不同阶段表现不同建模阶段模型加载失败报“XXX not supported” 转换阶段Pass 输出 IR 非法报“failed to verify” 优化阶段优化 Pass 产生错误输出结果错误 运行阶段代码生成正常但数值结果错误从实证研究角度开发者一般更关注“转换失败”和“结果错误”两类。它们可以明确归因到前端代码也能用测试用例复现。3. LLM 辅助实证研究研究设计思路3.1 为什么要引入 LLM“实证研究”四个字的关键在于“系统化地收集、归类、分析真实数据”而不是靠个人经验总结。传统做法是人工读 issue 标题、正文、代码片段然后打标签分类。但深度学习编译器的 Bug issue 通常很长包含 Traceback、IR 片段、复现步骤、环境信息人工阅读成本很高。LLM 能够承担三类工作批量分类给 LLM 一段 issue 描述让它判断属于哪类 Bug。关键信息抽取提取算子名称、报错信息、IR 类型、复现环境。语义聚类与模式发现把近义词、同算子不同框架的 issue 聚合起来发现高频模式。这对于“用更少人力摸清一个复杂系统的 bug 分布”非常有价值。3.2 研究问题拆解一篇文章/项目要研究前端 Bug通常会拆解为几个具体问题RQ1深度学习编译器前端 Bug 的整体分布如何哪些模块、哪些算子最多RQ2不同前端TVM / MLIR / XLA的 Bug 模式有什么差异RQ3前端 Bug 从出现到修复的周期有多长常见修复方式是什么RQ4LLM 辅助分类的准确率有多高在哪些类别上容易出错LLM 在这个流程里主要负责 RQ1和RQ4 的分类工作人工负责抽样验证、修正 prompt、校准标签。3.3 整体方法论流程从工程实现角度LLM 辅助实证研究流程可以分七步1. 数据收集抓取 GitHub issues / commit / PR 2. 数据清洗去重、过滤无意义 issue、统一语言 3. Prompt 设计定义分类体系写成结构化提示词 4. 批量分类调用 LLM API 对每条 issue 打标签 5. 人工抽样随机抽样 N 条人工校验 LLM 分类结果 6. 统计分析统计类别分布、修复周期、模块热度 7. 结果撰写用表格和图表呈现研究发现下面给出每一步的具体代码和配置。4. LLM 辅助前端 Bug 分析的可运行示例4.1 环境准备本文示例以 Python 3.10 和 OpenAI Python SDK 为例。如果你使用其他 LLM 厂商的 API只需替换base_url和模型名。需要安装以下依赖pip install openai pandas numpy python-dotenv项目结构建议如下dl_compiler_bug_study/ ├── collect_issues.py # 数据收集脚本 ├── classify_bugs.py # LLM 分类脚本 ├── analyze_results.py # 统计分析脚本 ├── prompts.py # 分类 Prompt ├── data/ │ ├── raw_issues.json # 原始 issue 数据 │ └── classified.json # 分类后数据 └── .env # LLM API 配置在.env中填入你的 API 配置LLM_API_KEYsk-xxxx LLM_BASE_URLhttps://api.openai.com/v1 LLM_MODELgpt-4o-mini4.2 模拟数据集构造为了便于复现先模拟一批前端 Bug issue 数据。真实场景下这一步应通过 GitHub REST API 抓取 issue。模拟数据集中在torch.add、torch.mean、tosa.reshape等算子映射和 shape 推导问题。# collect_issues.py import json import random random.seed(42) mock_issues [ { id: 1001, title: torch.mean keepdim attribute lost during ONNX import, body: When importing ONNX Reshape, the shape tensor is passed as second input, but the converter reads it as attribute. Output shape becomes wrong., repo: tvm, module: frontend/onnx, status: closed, }, { id: 1002, title: Shape inference fails for dynamic reshape in StableHLO, body: If the input shape is dynamic (?x?x3), tosa.reshape cannot infer the output shape. It falls back to rank-0 and produces invalid IR., repo: mlir, module: stablehlo, status: open, }, { id: 1003, title: Attribute axis vs dim mismatch in torch.add conversion, body: torch.add with dim parameter produces dim attribute in IR, but downstream pass expects axis. The conversion from torch frontend should normalize attribute names., repo: tvm, module: frontend/pytorch, status: closed, }, { id: 1004, title: Type inference wrong for integer division in XLA HLO, body: When converting torch.floor_divide to HLO, the result type is inferred as f32 instead of i64. The generated kernel returns wrong values., repo: xla, module: frontend/torch, status: open, }, { id: 1005, title: scf.for loop induction variable capture bug, body: When translating a Python for loop with external variable mutation, the induction variable is not captured correctly in scf.for. Causes wrong trip count., repo: mlir, module: frontend/python, status: closed, }, { id: 1006, title: tosa.pad attribute missing padding values, body: The ONNX Pad operator expects padding as input tensor, but the converter creates a tosa.pad without padding attribute. Crashes in verify step., repo: iree, module: frontend/onnx, status: closed, }, { id: 1007, title: Broadcast semantics wrong when converting add to linalg.generic, body: Two tensors of shapes (2,3) and (3,) are broadcast to (2,3), but the generated linalg.generic does not handle the implicit broadcast correctly., repo: mlir, module: tosa-to-linalg, status: open, }, { id: 1008, title: op set version mismatch in ONNX frontend, body: Model uses ONNX op set 18, converter only supports op set 13. The error message is unclear, no fallback to newer parser., repo: tvm, module: frontend/onnx, status: closed, }, ] with open(data/raw_issues.json, w, encodingutf-8) as f: json.dump(mock_issues, f, ensure_asciiFalse, indent2) print(fSaved {len(mock_issues)} mock issues to data/raw_issues.json)4.3 设计分类 Prompt分类 Prompt 是关键步骤。Prompt 需要给出清晰的定义、示例和输出格式。下面给出一个适合前端 Bug 分类的 Prompt 模板# prompts.py BUG_CLASSIFICATION_PROMPT 你是一名深度学习编译器专家。请对下面的 Bug 报告进行分类。 分类体系如下 1. op_mapping: 算子映射错误涉及高层算子在转换到 IR 时参数、属性、语义处理错误 2. shape_inference: Shape 推导错误涉及输出 shape、动态维度、维度合法性判断错误 3. type_inference: 类型推导错误涉及 dtype 推导、混合精度、整数/浮点类型错误 4. attribute_parse: 属性解析错误涉及属性名、属性值、默认值、attribute 丢失等 5. control_flow: 控制流转换错误涉及 if/for/while 到 IR 结构的转换 6. dialect_lowering: 方言转换错误涉及不同 Dialect 之间 lowering 时语义被改变 7. other: 其他类型 请严格按以下 JSON 格式输出不要输出额外内容 {category: 分类标签, reason: 一句话说明分类理由, confidence: 高/中/低} Bug 報告 Title: {title} Body: {body} Repo: {repo} 4.4 执行 LLM 批量分类接下来编写 LLM 分类脚本。为了减少 API 调用成本可以加入简单的缓存机制如果data/classified.json已有该 issue ID则跳过。# classify_bugs.py import json import os import time from openai import OpenAI from dotenv import load_dotenv from prompts import BUG_CLASSIFICATION_PROMPT load_dotenv() client OpenAI( api_keyos.getenv(LLM_API_KEY), base_urlos.getenv(LLM_BASE_URL), ) MODEL os.getenv(LLM_MODEL, gpt-4o-mini) def classify_issue(issue: dict) - dict: user_content BUG_CLASSIFICATION_PROMPT.format( titleissue[title], bodyissue[body][:2000], repoissue[repo], ) try: resp client.chat.completions.create( modelMODEL, messages[ {role: system, content: 你只输出 JSON不输出其他内容。}, {role: user, content: user_content}, ], temperature0.2, max_tokens300, response_format{type: json_object}, ) result json.loads(resp.choices[0].message.content) return { id: issue[id], title: issue[title], repo: issue[repo], module: issue[module], status: issue[status], predicted_category: result.get(category, other), reason: result.get(reason, ), confidence: result.get(confidence, 低), } except Exception as e: print(fError classifying issue {issue[id]}: {e}) return { id: issue[id], title: issue[title], repo: issue[repo], module: issue[module], status: issue[status], predicted_category: other, reason: fLLM 调用失败: {e}, confidence: 低, } def main(): with open(data/raw_issues.json, r, encodingutf-8) as f: issues json.load(f) classified [] try: with open(data/classified.json, r, encodingutf-8) as f: classified json.load(f) except FileNotFoundError: pass classified_ids {item[id] for item in classified} for issue in issues: if issue[id] in classified_ids: continue result classify_issue(issue) classified.append(result) print(f[{result[id]}] - {result[predicted_category]} ({result[confidence]})) time.sleep(0.5) # 控制请求速率 with open(data/classified.json, w, encodingutf-8) as f: json.dump(classified, f, ensure_asciiFalse, indent2) print(fClassification done. Total: {len(classified)}) if __name__ __main__: main()运行python classify_bugs.py4.5 统计分析与结果展示分类完成后需要做统计。下面脚本可以输出各类别数量、各模块分布、各仓库分布并保存为 CSV 便于后续画图。# analyze_results.py import json from collections import Counter import pandas as pd with open(data/classified.json, r, encodingutf-8) as f: data json.load(f) df pd.DataFrame(data) print( 类别分布 ) print(df[predicted_category].value_counts().to_string()) print(\n 仓库分布 ) print(df[repo].value_counts().to_string()) print(\n 前端模块分布 ) print(df[module].value_counts().to_string()) print(\n 类别 x 仓库 交叉表 ) cross pd.crosstab(df[predicted_category], df[repo]) print(cross.to_string()) # 保存统计结果 df.to_csv(data/analysis_result.csv, indexFalse, encodingutf-8-sig)预期输出示例基于模拟数据 类别分布 shape_inference 3 op_mapping 2 attribute_parse 1 dialect_lowering 1 control_flow 1 type_inference 1这个统计结果给研究者一个直观画像哪类前端问题最多、哪些前端模块最容易出问题。4.6 人工抽检验证LLM 分类不能直接全信。通常需要人工抽样 10% 到 20% 的样本做一致性校验。可以用下面代码随机抽样本# analyze_results.py 追加 N_SAMPLE 3 # 实际项目建议至少 30 条 sample df.sample(nN_SAMPLE, random_state42) for _, row in sample.iterrows(): print(fID: {row[id]}) print(fTitle: {row[title]}) print(fLLM 分类: {row[predicted_category]}) print(f理由: {row[reason]}) print(人工分类: ___) print(- * 50)人工分类完成后可以计算准确率。如果准确率低于 80%需要调整 Prompt 或把分类体系合并得更粗粒度。5. 前端 Bug 排查实战手写一个 Shape 推导问题LLM 辅助分类是宏观层面的工作。落到工程排查前端 Bug 的调试往往需要自己动手。这一节用一个简化的 shape 推导示例讲清楚排查思路。5.1 场景描述假设要实现一个简单的前端 shape 推导模块输入(batch, height, width, in_channel)经过一个conv2d核大小为k步长stride填充padding。输出 shape 计算方式是out_h floor((height 2 * padding - k) / stride) 1 out_w floor((width 2 * padding - k) / stride) 1这个公式本身简单但实际 Bug 往往出在“把padding当成了单边还是双边”“k是元组还是标量”“height和width是否被传反”这些问题上。5.2 错误示例下面这段代码模拟一个常见前端 Bug把padding当成单边值结果 shape 比预期大。def conv_output_shape(input_shape, kernel_size, stride, padding): 错误示例padding 被当成单边 padding实际上应该乘以 2。 _, h, w, _ input_shape k_h, k_w kernel_size out_h (h padding - k_h) // stride 1 out_w (w padding - k_w) // stride 1 return out_h, out_w # 期望输入: (1, 32, 32, 3) # kernel: 3x3, stride1, padding1 # 预期输出: (32, 32) print(conv_output_shape((1, 32, 32, 3), (3, 3), 1, 1))输出是(30, 30)而不是预期的(32, 32)。问题就在于公式中padding应该写成2 * paddingdef conv_output_shape_correct(input_shape, kernel_size, stride, padding): _, h, w, _ input_shape k_h, k_w kernel_size out_h (h 2 * padding - k_h) // stride 1 out_w (w 2 * padding - k_w) // stride 1 return out_h, out_w print(conv_output_shape_correct((1, 32, 32, 3), (3, 3), 1, 1)) # (32, 32)这类 Bug 在真实编译器里会表现为“算子输出 shape 偏小但编译能通过”只有做验证时才发现结果不对。排查时应该重点检查padding 参数是元组还是标量不同框架的 padding 语义PyTorch 的 padding 是双边TensorFlow 的paddingSAME是自动推断动态维度是否被当作 0 处理。5.3 使用 IR dump 定位问题在真实编译器如 MLIR/TVM中排查前端 Bug 的第一操作通常是 dump IR。MLIR 中可以用mlir-opt --mlir-print-ir-after-all input.mlirTVM 中可以用print(mod.script()) # Relay IR print(mod[main].script())通过对比前端转换前后的 IR能快速发现属性丢失、shape 错误、类型错误等问题。这个习惯应该从第一天就养成。6. 常见问题与排查思路在实际分析和排查前端 Bug 时以下问题出现频率最高。问题现象常见原因解决思路转换时报 “xxx expected but got xxx”属性名/类型不匹配查看算子文档对比高层框架属性名与 IR 属性名IR 通过验证但最终数值结果错误Shape 推导或类型推导静默错误使用 IR dump 对照检查中间 shape 和 dtype动态 shape 模型无法导入前端不支持动态维度固定维度先跑通再逐步放开动态维同一个模型在两个框架里结果不一致广播语义不同或 padding 语义不同检查各框架算子的默认语义写单算子测试LLM 分类结果人工验证准确率低Prompt 分类体系不清晰或样本描述太短增加 few-shot 示例减少类别数量Issue 抓取不完整缺少复现代码GitHub API 没有抓 comments/linked PR收集comments_url、timeline_url6.1 前端 Bug 排查 Checklist拿到能复现的最小模型/代码剥离环境依赖。先确认高层框架自身输出正确排除上游问题。dump 转换前 IR 和转换后 IR逐段对比。检查 shape、dtype、属性名、默认值。对单算子写一次性测试缩小问题范围。检查目标后端如 CUDA / LLVM是否对特定 shape 有额外限制。修复后补充回归测试保证同一个算子多种参数组合不回归。6.2 LLM 辅助分类时容易踩的坑让 LLM 直接判断“严重程度”不可靠应该先分类再单独做 severity 标注。中文和英文 issue 混合时Prompt 中应明确语言风格避免分类不一致。如果 Issue 包含大段 IR 片段应当先截断或让 LLM 只读取前 1500 字符。不要直接用 LLM 输出作为最终结果始终保留人工抽检验证。7. 最佳实践与工程建议7.1 前端模块的开发规范深度学习编译器前端开发中有几条值得长期遵守的规范第一算子映射表必须显式声明。不要在每个算子转换函数里硬编码属性名。建议单独维护一个映射表例如OP_ATTR_MAP { torch.mean: { dim: axes, keepdim: keep_dims, }, onnx.Reshape: { shape: new_shape, }, }这样属性名变更时只需改一处不容易出现“这个算子改了、那个算子没改”的问题。第二Shape 推导必须写单元测试。Shape 推导函数不应当只测试正常用例必须覆盖标量输入零维张量负维度动态维度广播维度padding 为元组时kernel 为元组时。这些边界情况是前端 Bug 的高发区。第三所有 IR 变换必须支持 dump。前端的每一步 Pass 都应该有“可读、可差量化”的输出。调试时通过 diff 两个版本的 IR能极大缩短定位时间。7.2 LLM 辅助实证研究的方法建议如果你也想做一个类似的实证研究下面几条经验值得参考先定分类体系再收集数据。没有清晰的分类维度LLM 分类结果很难稳定。建议先人工读 50 条 issue形成初步类别再交给 LLM。Prompt 中给足 few-shot 示例。每个类别给 1 个正例和 1 个反例比只写定义准确率高很多。分层抽样做人工验证。不要随机抽而是每个类别都抽一些样本这样能发现 LLM 在某个特定类别上的系统性误判。保存所有中间结果。LLM 输出的 reason、confidence、原始 issue 文本都要保存便于分析误差来源。不要忽略 issue 的修复 commit。通过关联 PR 和 commit可以分析 Bug 修复模式这是很多实证研究的重要部分。7.3 用 LLM 辅助排查的工程实践LLM 在排障环节也有实用价值但适合做“建议”不适合直接做“结论”。建议的工作流是先让 LLM 根据报错信息生成候选诊断方向再从 IR dump 中提取关键信息让 LLM 对比预期与实际的差异人工验证 LLM 定位到的接口名、属性名是否真实存在修复后跑一次回归测试确认没有影响其他算子。这种人类负责验证、LLM 负责扩展思路的分工是目前最稳定可靠的人机协作模式。8. 总结与后续学习建议围绕“深度学习编译器前端 Bug 实证研究”这个方向本文梳理了前端的基本职责、Bug 的典型分类、LLM 辅助分析的工作流以及排查实战方法。动手实践时最值得记住的三点前端 Bug 不只是“转换报错”更多是静默错误的结果错误排查时必须通过 IR dump 逐层对比。LLM 是非常有效的辅助分析工具但分类结果必须人工抽检Prompt 要提供清晰的分类体系和 few-shot 示例。Shape 推导、属性解析、算子语义映射是前端 Bug 最密集的模块写代码时要有意识地加强边界情况测试。如果对编译器前端的整体设计还不够熟悉建议先读 MLIR 官方的 Toy Tutorial弄明白 dialect 和 pass 的核心概念再回来读 TVM 的 Relay 前端代码或 IREE 的 StableHLO 转换代码。有了 IR 层面的直觉后再尝试把本文的 LLM 分类流程套用到真实 GitHub issue 上你会很快发现这套方法能帮你节省大量人工分类的时间。一个可以立刻开始的练习打开任意一个深度学习编译器的 GitHub 仓库抓取最近 100 个带frontend标签的 issue用本文的分类 Prompt 跑一遍再随机抽 20 条人工验证一下准确率。做完这个练习你对前端 Bug 的分布、语言特征和修复模式的理解会比读十篇综述都深刻。