30 AI-Native 研发基础设施洞察
- 章节编号:30
- 所属层:X 横向(支撑 C/S/R 全栈研发;落实 15 ADR-033、18 ADR-066)
- 关联 ADR:ADR-095(AI-Native 平台总体:私有模型+RAG+Agent CI)、ADR-096(仿真/ISS/FPGA farm)、ADR-097(KernelBench 式内部基准与 harness)、ADR-098(研发效能度量与技能沉淀)
- 上游依赖:15(LLM 编译器开发)、17/18(Agent kernel/spec)、24(compile farm)、Demo ISS/FPGA 路线
学习目标
- 前置知识:读过 15 章（LLM 辅助编译器开发）与 17/18 章（Agent kernel / tuning spec）概览;知道 MLIR pass / lit 测试 / kernel autotune 是什么;对「CI（持续集成）」「回归测试」「roofline（屋脊线）」有基本概念。无需 LLM 训练背景——本章从「研发效能与验证闭环」而非「模型内部」切入。
- 学完产出:① 能说清 AI-Native 研发四件套——私有代码模型、RAG（检索增强）、Agent CI、仿真 farm——各自解决研发流程里的哪一环,以及为什么缺了 farm 的 Agent 不可量产;② 能把「LLM 生成一个 kernel → CI farm 验证 → 迭代」这条闭环在时间轴上拆开算一遍,理解「正确性门禁」为什么是硬约束而非可选项;③ 能对比「自动优化（Agent+profiler loop）」与「人工内联/手调」在 ROI（投入产出比）上的分界线,判断哪些 kernel 值得交给 Agent、哪些留给人;④ 能对照 §3.1 横评表,说清 KernelAgent、AutoKernel、mlirAgent 三条路线各自代表的机制,并识别其中拼接可疑的 claim;⑤ 能读懂本章 ADR 候选(ADR-095~098),把「引入 AI 研发工具」翻译成「farm 队列预算 + harness 覆盖 + skills 沉淀」的可执行输入。
- 阅读姿势:盯住一条主线——「AI 能生成代码,但只有 farm 能证明代码是对的;研发效能的瓶颈从『写得快』转移到『验得起』」。无论是 kernel 生成、pass 开发还是 BSP 改写,Agent 产出的每一行都必须过同一道正确性门禁;farm 的队列吞吐与回归时间预算,才是这套系统真正的天花板。读表格时不要只看「成果百分比」,要问「它的验证闭环是什么、这个数字是在什么硬件上、由谁复现的」。
1. 范围与目标
定义 私有代码模型、RAG、Agent CI、仿真 farm、内部基准 如何支撑编译器、算子、BSP 与系统软件研发。本章是 研发效能层,非产品 runtime。
核心问题
- Agent 如何参与 MLIR pass / kernel / tuning spec 开发(15/17/18)?
- ISS/FPGA farm 与 24 compile cloud 如何统一?
- 对标 KernelBench、mlirAgent、AutoKernel、Jetson BSP Skills?
- RAG 知识库 范围(ISA/IREE/内部 ADR)?
- 如何度量 AI-Native 提效?
2. 需求洞察(组织驱动)
| 研发任务 | AI-Native 诉求 |
|---|---|
| 新 MLIR pass | LLM 生成样板+lit(15) |
| P0 kernel | Agent+ISS 验证(17) |
| tuning spec | L2 Agent(18 ADR-066) |
| BSP DTS | Agent 对照 hw-spec(10) |
| Bug 归因 | RAG+telemetry(29) |
硬性指标:Agent 产出 100% 过 CI harness 才可 merge;farm ISS 队列 ≤30min MR。
3. 技术现状与趋势(2025–2026)
3.1 业界 AI-for-Systems 深度对比(2025–2026)
表中「成果」列多为各团队自报或论文口径,未经我们独立复现;凡未在 自研 DSA ISS 上重跑的数字一律视为「待核」,只作路线参考,不作验收承诺。
| 系统 | 机构/时间 | 机制 | 验证闭环 | 成果(公开) | 优势 | 劣势 | 我们映射 |
|---|---|---|---|---|---|---|---|
| KernelAgent | PyTorch 2025 | 多 Agent+硬件 profiler | KernelBench 250 100% | H100 89% roofline（待核） | 硬件 grounded | GPU only | ISS profiler→spec |
| KernelFalcon | PyTorch 2025 | Deep agent+并行 worker 早停 | 执行验证五阶段 | 250 题全过（待核） | 并行探索 | GPU Triton | 并行 ISS worker |
| AutoKernel | arXiv 2026（编号待核） | Amdahl+keep/revert | 五阶段 harness | 180+ 模型（待核） | 简单 loop 有效 | PyTorch 中心 | π0 子图 Amdahl |
| KernelEvolve | Meta 2025 | 图搜索+RAG HW KB | fitness | 异构 ads | proprietary HW | 闭源 | DSA spec RAG |
| Reasoning Compiler | arXiv 2025 | LLM+MCTS tile/pass | rollout perf | 超启发式 | 序列决策 | 研究阶段 | L2 spec MCTS |
| mlirAgent | UCB 2025 | IR fingerprint+KG | binary size/evolve | pass 开发（成果口径见下方拆分） | pass 开发 | LLM IR transform 失败 | pass 样板 only |
| Google Magellan | Google 2025 | 编译器自动调优/进化 | 编译产物度量 | LLVM 内联 8.78%（待核,归属 Magellan） | 生产级编译器 | 闭源 | 内联启发式参考 |
| GPU Kernel Scientist | arXiv 2025 | 进化+timing feedback | HIP on MI300 | 竞赛级 | 少文档 HW | AMD 向 | ISS timing loop |
| Xe-Forge | Intel 2026 | 多阶段 LLM+GRF 约束 | Triton autotune | Intel GPU | shape-aware | Intel only | roofline→grid |
| KernelBench | Stanford | 250 GPU 题 | 编译+数值 | 行业基准 | 标准 | GPU | 内部 π0 dispatch |
| Cursor/Copilot | 2024–26 | IDE 补全 | 人审 | 普及 | 低门槛 | 无 farm | 日常 |
| Jetson BSP Skills | NVIDIA 2026 | Agent 改 BSP | 板级 boot | JetPack | BSP 垂直 | 闭源 | DTS/hw-spec Agent |
拼接勘误(重要):此前把「mlirAgent」与「LLVM 内联 8.78%」并置属于归属可疑——「LLVM 内联 8.78%」这一成果多见于 Google Magellan(编译器自动调优)相关报道,而 UCB 的 mlirAgent 主线是 MLIR pass 开发且明确报告了 LLM 直接做 IR transform 失败的教训。本表已拆成两行,并对未独立复现的数字统一标「待核」。KernelAgent 89% roofline、AutoKernel 180+ 模型、KernelFalcon 250 题全过 同属外部自报口径,一律「待核」。
3.1a 范式对比:哪种 Agent 适合我们?
| 范式 | 代表 | 优势 | 劣势 | 适用层 |
|---|---|---|---|---|
| Profiler-grounded loop | KernelAgent, AutoKernel | 真硬件信号;Amdahl 优先 | 需 farm | 17 kernel, 18 spec |
| Parallel explore+early exit | KernelFalcon | 吞吐高 | GPU 资源 | 18 L2 worker pool |
| LLM+MCTS 序列搜索 | Reasoning Compiler | pass/tile 序列 | 成本高 | 18 L2 研究 |
| Evolution on heuristics | Google Magellan | LLVM 内联 8.78%（待核） | 非 kernel | 15 pass 开发参考 |
| IDE copilot only | Copilot | 快 | 无 correctness | 禁止 standalone merge |
结论:我们 禁止 无 farm 的 Agent merge;L0/L1 启发式量产 + L2 profiler loop 研发(18 ADR-066)。
3.1b 仿真/CI 平台对比
| 平台 | 用途 | 优势 | 劣势 | 关系 |
|---|---|---|---|---|
| Isaac Sim | sim2real | 物理/视觉 | 不验 DSA kernel | 规模化阶段 31 章 |
| ISS/cycle-approx | 编译 CI | bit-exact | 无物理 | M1 主 farm |
| FPGA HIL | RTOS+岛 | 真实时序 | 贵 | M4+ |
| GitHub Actions | 轻 CI | 简单 | 无 ISS 规模 | M1 辅助 |
3.1c LLM 辅助 kernel 生成的正确性门禁(为什么 farm 不可省)
LLM 生成 kernel 有一个反直觉的性质:「看起来对」和「数值上对」是两码事。一个 GEMM tiling 改错了循环边界、一个 attention kernel 漏了 mask、一个流匹配去噪 loop 把步数固化写错——这些错误编译能过、跑也能出结果,只是结果悄悄错了。在具身场景里,kernel 数值偏差会一路传播到 rollout 成功率,而 rollout 是随机的,单看一次可能「碰巧成功」,掩盖了 kernel 的系统性错误。因此 Agent 生成的每一个 kernel 必须过一道多级正确性门禁,缺一不可:
四级门禁的分工:门禁 0 只挡语法/IR 非法;门禁 1 是核心——用参考实现(PyTorch eager 或黄金 kernel)在同一输入上比对数值,allclose 或 ULP(最后一位单位)阈值内才算对;门禁 2 才谈性能,数值对了再看 ISS 周期数是否达 roofline 预算;门禁 3 用 rollout mock 兜底,防止「单 kernel 数值微差、端到端却掉成功率」的组合效应。任一级失败都把信号回写给 Agent 迭代重试——这正是「profiler-grounded loop」相比「裸 LLM 补全」的本质区别:Agent 不是「写完就交」,而是「在 farm 的真实信号里收敛」。这也解释了 §3.8 的判断——farm 是 moat(护城河):谁的门禁跑得起、跑得快,谁的 Agent 才敢量产。
3.2 AI-Native 平台架构(候选)
┌─────────────────────────────────────────────────────────────┐
│ IDE / Chat (Cursor, internal bot) │
├─────────────────────────────────────────────────────────────┤
│ Agent Orchestrator (OpenHands / 自研) │
│ · tools: compile, iss-run, lit, git, farm-submit │
├─────────────────────────────────────────────────────────────┤
│ Private Code Model + RAG │
│ · ISA manual, IREE docs, ADR, pass templates, tuning specs │
├─────────────────────────────────────────────────────────────┤
│ CI / Farm (24 ADR-083 + 096) │
│ · ISS · cycle-approx · FPGA · silicon nightly │
└─────────────────────────────────────────────────────────────┘
3.3 RAG 知识库(ADR-095)
| 集合 | 内容 | 更新 |
|---|---|---|
| hw-isa | 07/08 手册、intrinsics | tape-out |
| compiler | 15/16 pass 模板、lit | 每 MR |
| tuning | 18 spec 库、playbook | 每 spec PR |
| insight-adr | 本目录 ADR | 选型后 |
| 禁止入 RAG | 客户私有权重、未公开 NDA | — |
3.4 Agent CI 工作流(示例)
- 工程师: "为 π0 flow loop 添加 fusion pass"
- Agent: RAG → 生成 pass + lit → farm ISS → 失败则迭代
- PR: 人审 + CI green → merge
与 18 L2 区别:L2 专注 tuning spec;Agent CI 覆盖 更广编译器/BSP。
3.5 仿真 Farm(ADR-096)
| 后端 | 用途 | 阶段 |
|---|---|---|
| ISS | 默认 MR;bit-exact | M1+ |
| cycle-approx | autotune 精筛 | M2+ |
| FPGA | HIL、RTOS 岛 | M4+ |
| silicon | nightly;telemetry 回写 | tape-out |
统一队列:24 compile farm 共用 farm API。
3.5a farm 队列与回归时间预算(排队论视角)
「farm ISS 队列 ≤30min MR」这条硬指标不是拍脑袋——它是队列吞吐和回归深度共同约束下的产物。farm 是一个典型的排队系统:MR(合并请求)按到达率 λ 涌入,farm 按服务率 μ 消化,一旦 λ 逼近 μ,排队延迟会非线性爆炸(M/M/c 队列的经典结论:利用率 90% 时排队时间是 50% 时的近 10 倍)。而每个 MR 的服务时长又由回归深度决定:跑全量 harness 慢但稳,跑增量子集快但可能漏回归。下图刻画这套预算的三方博弈:
预算的三个杠杆:① 提 μ(扩 worker 池)——最直接但最贵,ISS 是 CPU 密集型,cycle-approx 更甚;② 分层回归——MR 门禁只跑「受影响 dispatch 的增量子集」(快),把全量 250+ dispatch 留给 nightly(慢但零漏报),用 §3.6 的依赖图判断「哪些 dispatch 受本次改动影响」;③ 削 λ 峰值——Agent 自动 MR 容易在深夜批量涌入,须与工程师 MR 错峰或降优先级,避免 Agent 把人挤出队列。这套预算直接落到 §3.7 的度量指标「ISS farm MR 等待 p95 ≤30min」——它不是 farm 的性能上限,而是研发流程能接受的等待上限,超了工程师就会绕过 CI 本地 hack,门禁形同虚设。
3.6 Internal KernelBench(ADR-097)
- 50–100 dispatch 从 21 P0 抽取
- harness: 数值 + ISS timing + rollout mock
- Agent/kernel 回归 必过
3.7 研发效能度量(ADR-098)
| 指标 | 目标 |
|---|---|
| pass/kernel Agent 首稿 merge 率 | 跟踪 |
| ISS farm MR 等待 | p95 ≤30min |
| 18 L2 spec 采纳率 | ≥50% 长尾 |
| 文档/skills | Hermes/Cursor skills 沉淀 |
3.8 趋势
- 2025–2026 Agent 爆发:KernelAgent/AutoKernel/Reasoning Compiler——共性是 profiler+ harness,非裸 LLM。
- mlirAgent 教训:LLM 不能替代 pass——Agent 写 样板+单测,人审架构。
- farm 是 moat:无 ISS/硅 feedback 的 Agent 不可量产。
- Internal KernelBench 复制 Stanford 方法论,但 ground π0/OpenVLA dispatch。
- Jetson BSP Skills 证明 垂直 Agent(BSP)与 水平 Agent(compiler)需 分 skills。
- 归属分野:编译器启发式自动调优(Google Magellan 式,LLVM 内联提升「待核」)与 kernel 从头生成(KernelAgent 式)是两条独立技术线,勿混为一谈——前者优化既有 pass 的参数,后者产出新代码,验证闭环与风险截然不同。
4. 候选方案
| 候选 | 小结 |
|---|---|
| A. 私有模型 + RAG + OpenHands 式 Agent + 统一 farm | 建议方案 |
| B. 仅 Copilot 无 farm 闭环 | 不足 |
| C. 全外包标注团队 | 非 AI-Native 闭环 |
6. 结论与 ADR
- AI-Native = 私有模型 + RAG + Agent CI + ISS/FPGA farm 四件套。
- 18 L2 / 15 pass / 17 kernel 共用 farm 与 harness。
- Internal KernelBench 回归 Agent 产出。
- 对标 KernelAgent + mlirAgent + Jetson BSP Skills;ground 在 自研 DSA ISS;外部成果数字一律「待核」,不作承诺。
- ADR-095 AI-Native 平台:私有 code model;RAG 五集合;Agent orchestrator;人审+CI 强制。
- ADR-096 仿真 farm:ISS 默认;cycle-approx/FPGA/silicon 阶梯;与 24 compile cloud 统一 API。
- ADR-097 内部基准:OpenVLA/π0/GR00T DiT dispatch 集;Agent 产出必过;衔接 KernelBench 方法论。
- ADR-098 效能与技能:度量 Agent merge 率/farm 延迟;skills 文档化重复 workflow。
深入思考
每题先给题干,再折叠一份图文并茂的参考答案。建议先合上答案自己想 3 分钟,再展开对照。
思考题 1:LLM 辅 助 kernel 生成为何非要 CI farm 验证
有人主张:私有代码模型已经很强,让它直接生成 kernel、工程师肉眼 review 一下就 merge,能省下建 farm 的巨大成本。结合 §3.1c 正确性门禁 与 §3.8「farm 是 moat」,论证为什么「肉眼审 + 无 farm」在 kernel 场景是危险的,并把「一个错 kernel 溜进主干」的代价算一遍,说明门禁 1(数值 bit-exact)为什么是不可谈判的那一级。
展开参考答案（含正确性门禁风险图 + 算一遍）
结论:kernel 的错误绝大多数是「编译能过、能跑、结果悄悄错」的数值错误,肉眼审代码看不出来、单跑一次可能碰巧对;只有 farm 用参考实现做 bit-exact 数值比对,才能系统性地挡住它。省掉 farm 省的是「验证成本」,赔上的是「错 kernel 混入主干后,在下游 rollout 里以随机成功率的形式间歇性发作」的排查成本,后者可能是前者的几十倍。
用具体数字算一遍(数量级估算,量化「省 farm」的隐藏代价):
- 过 farm 的成本:一次 MR 的 ISS 数值+timing 门禁,假设 farm p95 ≤30min(§3.7),即约 0.5 机时,自动化零人工介入。
- 不过 farm、错 kernel 进主干的成本:该 kernel 数值偏差 → 下游 rollout 成功率从 90% 悄悄掉到 82%。由于 rollout 本身随机,团队起初以为是「模型没训好」或「数据噪声」,先花 ~2 人天 查 模型、查数据集、查调度,最后才回溯到 kernel——排查约 2–3 人天 ≈ 40–60 人时。
- 对比:0.5 机时(自动) vs 40–60 人时(工程师排查)——差约两个数量级。而且这还没算「错误期间下游所有基于该主干的实验结果全部作废重跑」的连带成本。
- 为什么门禁 1 不可谈判:门禁 0(编译)挡不住数值错,门禁 2/3(timing、rollout)是「性能/端到端」层、太靠后且带随机性;只有门禁 1 用确定性的参考实现 bit-exact 比对,能在 merge 前把「悄悄错」变成「当场红」。这就是 §3.8「无 farm feedback 的 Agent 不可量产」的量化根据。
回链:详见 §3.1c 四级正确性门禁图(门禁 1 数值 bit-exact 为核心)、§2「Agent 产出 100% 过 CI harness 才可 merge」硬指标,以及 §6.3 ADR-097「Agent 产出必过」。
思考题 2:自动优化(Agent+profiler loop)vs 人工内联的 ROI 分界
Agent profiler loop 能自动搜索 tiling/融合/内联,但它要吃 farm 算力、要跑很多轮;资深工程师手写内联往往一次到位。结合 §3.1a 范式对比 与 §3.5a farm 预算,分析:在「kernel 出现频次」「优化收益天花板」「farm 成本」三个维度上,什么样的 kernel 值得交给 Agent 自动优化、什么样的留给人工?把两条路线的 ROI 算一遍,给出一条可操作的分界线。
展开参考答案（含 ROI 分界图 + 对比表）
结论:Agent 自动优化的成本是「farm 机时 × 迭代轮数」且可无人值守规模化;人工内联的成本是「稀缺的资深工程师人时」且不可规模化。因此分界线是:高频复用、收益可累积、但单点收益不高的「长尾 kernel」交给 Agent(摊薄 farm 成本、解放人力);低频但收益天花板极高、需要架构洞察的「热点核心 kernel」留给人工(人的一次深思胜过 Agent 千百轮盲搜)。
用具体数字算一遍(数量级估算):
| 维度 | Agent 自动优化 | 人工内联 |
|---|---|---|
| 单次成本 | farm 机时:比如 50 轮 × 每轮 ISS ~10min ≈ 8 farm 机时,零人工 | 资深工程师 ~1 人天 深挖 + 手调 |
| 可规模化性 | 高:100 个长尾 kernel 可并行跑,人只审结果 | 低:工程师是串行稀缺资源,100 个 kernel 排队排到天荒地老 |
| 收益天花板 | 中:擅长参数搜索(tile/融合选择),难有架构级突破 | 高:能重构数据流、换算法,拿到 Agent 摸不到的天花板 |
| 适用 | 高频、长尾、参数型收益 的 kernel | 低频、热点、需洞察 的核心 kernel |
一条可操作的分界线:设某 kernel 在 dispatch 集里的调用权重为 w(占总算力比),Agent 摸到的收益上限约 g_a、人工约 g_m(通常 g_m > g_a)。
- 若 w 小但 kernel 数量多(长尾):单个交给人工不划算(1 人天摊到 w 很小的收益上),但 一批交给 Agent 可摊薄 farm 成本、批量收割 → 走 Agent。
- 若 w 大(热点核心,如主 GEMM / attention):即使 kernel 数量少,g_m 相比 g_a 多出的那几个百分点乘以大 w,收益足以覆盖 1 人天 → 走人工,Agent 只做初筛/兜底。
- 对应 §3.1a:profiler-grounded loop 用在「17 kernel / 18 spec」的长尾量产,而 §3.8「L0/L1 启发式量产 + L2 profiler loop 研发」正是这条分界的制度化——别让 Agent 去啃需要架构洞察的硬骨头,也别让工程师去手搓能自动化的长尾。
回链:详见 §3.1a 范式对比(Profiler-grounded loop 适用层)、§3.5a farm 预算(Agent MR 与工程师 MR 错峰),以及 §3.8 趋势 1「共性是 profiler+harness」。
思考题 3:farm 队列与回归时间预算怎么定
「ISS farm MR 等待 p95 ≤30min」这条指标一旦破线,工程师就会本地 hack 绕过 CI。结合 §3.5a 排队论视角 与 §3.6 Internal KernelBench,分析:当 MR 到达率上涨(Agent 自动 MR 涌入)导致队列逼近饱和时,你有哪三个杠杆可拉?把「全量回归 vs 增量回归」的时间账算一遍,说明为什么「分层回归」通常是第一顺位、扩 worker 是最后手段。
展开参考答案（含队列饱和三杠杆图 + 算一遍）
结论:队列逼近饱和时排队时间会非线性爆炸,三个杠杆是「削峰(降 λ)、分层回归(降单 MR 服务时长)、扩 worker(升 μ)」。分层回归是第一顺位——它几乎零边际成本地把 MR 门禁的服务时长砍到零头,把全量回归推到 nightly;扩 worker 是最后手段,因为 ISS/cycle-approx 是 CPU 密集型,扩容线性烧钱且有上限。
用具体数字算一遍(数量级估算,对比全量 vs 增量回归):
- 全量回归成本:Internal KernelBench 有 50–100 dispatch(§3.6),假设取 100,每个 dispatch 跑「数值+ISS timing+rollout mock」约 ~1min,单 MR 全量 ≈ 100min。这远超 30min 预算,单 MR 就破线。
- 增量回归成本:一次 kernel/pass 改动通常只影响 少数 dispatch——用依赖图算出「受影响集」,比如 5 个 dispatch,单 MR 增量 ≈ 5min。比全量快 20 倍,轻松落进 30min 预算。
- 分层的代价与兜底:增量回归可能漏掉「间接受影响」的 dispatch,所以把 全量 100 dispatch 留给 nightly——夜间无人排队、λ 低,跑满 100min 也不影响白天预算,且能兜住增量漏报。
- 为什么扩 worker 是最后手段:排队论上,worker 数 c 提 μ 是线性的,但 ISS 是 CPU 密集型,扩 c 意味着线性增加机器成本,且当 λ 因 Agent 大量涌入而暴涨时,单纯扩 c 追不上;而分层回归把「单 MR 服务时长」从 100min 砍到 5min,等价于把 μ 放大 20 倍且几乎零成本——所以先分层、再削峰、最后才谈扩容。
回链:详见 §3.5a farm 预算三杠杆(分层回归 / 削峰 / 扩 worker)、§3.6 Internal KernelBench(50–100 dispatch、harness 三件),以及 §3.7 度量指标「ISS farm MR 等待 p95 ≤30min」。
附:信息来源
区分公开/估计;外部成果数字凡未在自研 DSA ISS 独立复现者标「待核」。参考时间 2026-06。
- Reasoning Compiler:arXiv:2506.01374。[公开]
- AutoKernel:arXiv:2603.21331(编号待核)。[公开,成果待核]
- KernelAgent / KernelFalcon(H100 89% roofline、KernelBench 250 全过):PyTorch 团队 2025 报道。[公开,数字待核]
- mlirAgent(UCB 2025;MLIR pass 开发;报告 LLM 直接 IR transform 失败):[公开]
- Google Magellan / LLVM 内联 8.78%:Google 编译器自动调优相关报道;归属 Magellan 而非 mlirAgent。[公开,数字待核]
- KernelBench:Stanford 250 GPU 题基准。[公开]
- Jetson BSP Skills:NVIDIA 2026。[公开]
- 15 ADR-033;18 ADR-066;24 ADR-083;Demo plan。[内部/公开]