文章目录面壁智能ForgeStencil技术解析双Agent如何打通Stencil自动研究与真实应用部署一、引言二、Stencil是什么为什么它既规则又难优化2.1 从一个网格点看科学计算2.2 旧自动化为什么停在代码生成三、双Agent架构一个研究算子一个负责落地3.1 完整数据流3.2 知识库不是一堆最佳Kernel四、自动研究从Profile到可验证的新策略4.1 Kernel Agent的闭环4.2 App Agent的六项直接接入门4.3 Amdahl定律是部署前的止损线五、自动部署怎样防止Agent虚报加速5.1 Patch模式保留上游来源5.2 “fdtd金标准”的五条硬约束5.3 为什么报告几何平均六、公开结果100个应用的数字应该怎样读6.1 端到端分布6.2 算子级与跨代结果七、工程实践复现算子与真实应用7.1 环境要求7.2 一分钟算子检查7.3 复现haccmk端到端结果7.4 上线自己的应用前检查八、横向对比与边界九、总结面壁智能ForgeStencil技术解析双Agent如何打通Stencil自动研究与真实应用部署一、引言亲爱的朋友们创作不容易若对您有帮助的话请点赞收藏加关注哦您的关注是我持续创作的动力谢谢大家有问题请私信或联系邮箱jasonai.fngmail.com高性能计算里最昂贵的工作往往不是写出一个能运行的 CUDA Kernel而是证明它在真实软件中更快且没有改变科学结果。研究者要找热点、分析访存与占用率、设计分块和融合策略、反复 Profile再把新算子嵌回气象、流体、医学成像或油气软件单个微基准快十倍落进完整程序后也可能因为数据转换和同步开销只剩 1.01 倍。2026 年 8 月 4 日面壁智能联合 OpenBMB 开源 ForgeStencil。它面向 Stencil模板计算优化使用 Kernel Agent 和 App Agent 两个智能体前者执行“计划—编码—剖析”的自动研究后者完成热点定位、专用算子锻造、正确性验证和真实应用集成。项目采用 Apache-2.0 许可证公开 CUDA 算子、Agent 循环、100 个应用复现包、测量 Harness 与结果注册表。官方报告显示ForgeStencil 在 100 个端到端验证应用上取得中位 1.41×、几何平均 2.05× 的加速。真正值得研究的并非某个夸张峰值而是它如何约束智能体只有真实上游程序、程序内单开关、应用自带正确性检查、交错计时和全标准算例几何平均全部满足结果才允许标记为端到端验证。二、Stencil是什么为什么它既规则又难优化2.1 从一个网格点看科学计算Stencil 是规则网格上的邻域计算。三维 7 点 Stencil 会用当前点和上下、左右、前后六个邻居更新输出u(i,j,k) c0·u(i,j,k) cx·[u(i-1,j,k) u(i1,j,k)] cy·[u(i,j-1,k) u(i,j1,k)] cz·[u(i,j,k-1) u(i,j,k1)]类似模式出现在有限差分、扩散方程、地震波、电磁场、气象和流体模拟中。计算表达式规则却高度受显存带宽、缓存复用、线程块形状、Halo、寄存器压力和 Kernel 启动影响。优化手段目标常见副作用空间分块/Tiling提高邻域数据复用Shared Memory 与同步开销上升时间分块一次加载完成多个时间步Halo扩大、寄存器和边界逻辑复杂Kernel融合减少中间写回和启动次数寄存器压力可能降低占用率布局重排合并访存、改善缓存局部性与上下游布局不兼容时转换成本更高向量化与低精度提升带宽利用率对齐、数值误差与可移植性风险架构特化利用特定GPU代际特性跨A100/H100/B200需要分别回归2.2 旧自动化为什么停在代码生成Halide、Devito 等 DSL 能从人类定义的算法和调度生成高性能代码AN5D、EBISU、DRStencil 等自动调优器在预设搜索空间中选择参数。它们解决了大量手工编码问题但优化策略、真实应用热点和集成工作通常仍由人负责。ForgeStencil 试图补上两段让 Agent 根据 Profile 发现策略而不是只枚举固定 Tile让另一个 Agent 把策略集成到真实上游应用并通过程序自己的结果和计时判断成败。这也是项目将自身称作“自动研究 自动部署”闭环的原因。三、双Agent架构一个研究算子一个负责落地3.1 完整数据流┌──────────────── Kernel Agent ────────────────┐ │ Plan ─► Code ─► Compile ─► Correctness ─► Profile │ ▲ │ │ └──────── 性能证据 / 失败原因 / 新假设 ───┘ └──────────────────────┬──────────────────────┘ │ 优化算子与技术记录 ▼ kernel/ 算子知识库 │ ▼ ┌───────────────── App Agent ──────────────────┐ │ 拉取真实上游 ─► 定位热点 ─► 匹配/锻造算子 │ │ └────► 注入USE_OURS开关 ─► 集成Patch │ └──────────────────────┬──────────────────────┘ │ ▼ 端到端验证Harness 原始/优化交错运行 · 自带校验 · 自带计时 │ ▼ integration_registry.json / 可复现结果Kernel Agent 的循环脚本和优化规则位于agents/默认可由 Claude Code 或兼容的 Agent CLI 驱动。它每轮提出单一变化、编译、检查正确性、测量并保留有效版本。针对 H100、B200 的 Backend Brief 会把已测到的瓶颈注入提示使 Agent 从实际 Roofline 和硬件限制出发而不是重复通用 CUDA 建议。App Agent 使用算子库作为知识库先判断真实应用算子能否直接替换。若 Shape、语义、精度、布局或性能门任一不满足就进入自动研究分支目标可能变成“把物理项与 Stencil 融成一个新 Kernel”而不是勉强串两个 Kernel 造成回退。3.2 知识库不是一堆最佳Kernel算子库同时保存源代码、适用 Shape、精度、GPU 架构分支、Profile 结果和失败经验。A100 上有效的配置不一定适合 B200某个布局在算子微基准中极快若真实应用上下游使用另一布局转换流量可能吃掉全部收益。组件作用kernel/优化CUDA Kernel与A100/H100/B200运行时分派tools/run.py编译算子、与可用Baseline比较、做NumPy正确性检查agents/双Agent循环、集成状态机和优化纪律operator_bench/真实应用算子的代理微基准只能报告算子级结果applications/100个来源记录、拉取脚本、集成Patch和配置harness/构建、交错测量、正确性与端到端判定results/结果注册表和跨GPU代际原始测量这里最重要的分类是operator_bench只能说明被替换算子快了多少不能称为端到端只有harness在真实程序中跑完整标准测例才能写入e2e_validatedtrue。四、自动研究从Profile到可验证的新策略4.1 Kernel Agent的闭环建立Baseline │ ▼ 查看Kernel时间、DRAM带宽、Occupancy、寄存器与启动开销 │ ▼ 提出一个可证伪假设 例如跨步复用不足应采用K方向深预取 │ ▼ 只实现这一项变化 ─► 正确性失败回退并记录 │通过 ▼ 多轮稳健测量 ─► 性能回退回退并记录 │提升 ▼ 提交有效版本进入下一轮“每轮只改一项”让性能变化有因果解释正确性 Gate 和零回退规则阻止 Agent 为追求数字积累不可控修改连续无进展后再搜索外部资料避免一开始就复制与当前瓶颈无关的技巧。4.2 App Agent的六项直接接入门条件必须回答的问题Shape匹配邻域模式是否与库内 star、box、diamond 等完全一致语义匹配是否纯加权邻域和不含非线性物理项或方向性Gather精度匹配f16/f32/f64 是否与可用Kernel一致布局兼容Padding、Ghost和内存顺序是否与上下游一致优化版可用对应架构变体是否能编译、运行并通过正确性端到端不退化集成后是否至少不低于应用原优化路径容差2%需要拆分算子就进入研究因为“优化 Stencil 单独 Physics Kernel”会增加中间 Buffer 往返和二次读取。新研究目标通常是把两者融合成一个应用专用 Kernel直接消费原布局。4.3 Amdahl定律是部署前的止损线若 Stencil 占完整程序时间比例为f算子加速为S_kernel理论端到端加速是S_e2e 1 / ((1 - f) f / S_kernel)defprojected_speedup(operator_fraction:float,kernel_speedup:float)-float:ifnot0operator_fraction1:raiseValueError(operator_fraction must be within [0, 1])ifkernel_speedup0:raiseValueError(kernel_speedup must be positive)return1/((1-operator_fraction)operator_fraction/kernel_speedup)forfractionin(0.2,0.5,0.8):print(fraction,projected_speedup(fraction,5.0))一个 Kernel 即使快 5 倍若只占程序 20%端到端理论值也只有约 1.19 倍。ForgeStencil 要求f_app来自真实 Profile 或有来源的估计并把“算子实测”“端到端投影”“端到端实测”分开记录。五、自动部署怎样防止Agent虚报加速5.1 Patch模式保留上游来源ForgeStencil 不在仓库内打包第三方应用源码而是为每个应用保存applications/app/ ├── PROVENANCE.md # 上游URL、版本/哈希与结果 ├── vendor.sh # 从原始位置拉取源码 ├── patches/integration.patch # 注入优化路径的差异 └── e2e/ ├── manifest.json # 构建、测例、计时与校验规则 └── build.sh kernel/app_ours.cuh # ForgeStencil生成的专用算子这既减少许可证混用也使复现者能核对真实上游字节。原始路径与优化路径位于同一个程序通过USE_OURS类开关切换而不是各写一个迷你程序再对比。5.2 “fdtd金标准”的五条硬约束Gate约束防止的造假或误判真实程序Baseline是命名对应的上游Driver/Main用相似Demo冒充工业应用真实测例运行程序自带标准初始化、时间步和诊断只挑有利的小尺寸循环同程序开关Orig/Ours只有一个内部开关不同两套程序存在隐藏差异程序自检使用内置检查或同程序末态Diff只比较几个采样点程序自计时交错多轮运行并读取程序计时器冷启动、节点漂移和选择性计时任一条件失败Harness 会把结果标记为未验证或受阻不能写成端到端成果。对原项目已有 GPU 版本的应用必须优先与它自己的 GPU 路径同架构比较拿第三方框架实现替代原项目 Baseline只能说明另一个问题。5.3 为什么报告几何平均不同标准算例加速比是乘法比率算术平均容易被一个极大值拉高。几何平均对比率更合适Geomean (S1 × S2 × ... × Sn)^(1/n)项目还要求原始和优化路径交错运行多轮取中位降低 GPU 温度、时钟和共享节点负载的顺序偏差。这里的可复现是指 Patch、输入、测量产物和结果可以重跑LLM Agent 每次探索路径本身并不保证逐位一致。六、公开结果100个应用的数字应该怎样读6.1 端到端分布指标官方结果验证应用数100中位端到端加速1.41×几何平均2.05×完整区间0.998×97.7×至少1.05×89%至少1.20×73%至少1.50×43%至少3×21%至少10×7%中位数 1.41× 比 97.7× 峰值更有代表性。极大提升通常来自上游存在大量小 Kernel、Host 同步或可融合结构例如pathfinder97.7×面对高度调优的厂商或手写代码常见结果只有 1.01.5×。接近 1.0× 不一定是失败也可能说明原实现已接近硬件极限。6.2 算子级与跨代结果访存受限算子在 A100 上达到官方峰值 DRAM 带宽 2039 GB/s 的 74%85%。在 32 个同精度、同类别算子形状上ForgeStencil 相对每个 Shape 的最佳适用公开 Baseline 几何平均约 2.16×。算子库提供sm_80、sm_90、sm_100运行时分派。A100 到 H100 时许多 Kernel 仍保持 77%90% DRAM 利用到 B200 后带宽增长快于访存发射能力部分 Kernel 掉到 44%65%促使 Agent 研究更深预取等代际特化策略。必须注意100 个完整应用的端到端包统一在 A100 上验证H100/B200 的完整端到端复测仍在路线图中。“支持三代架构”不能改写成“100 个应用已在三代 GPU 全部验证”。七、工程实践复现算子与真实应用7.1 环境要求官方要求 NVIDIA GPU参考验证环境为 A100-SXM4-80GB使用 CUDA 12.x、C17 Host 编译器、Python 3.9、NumPy 与 CuPy。运行 Agent 还需要 Claude Code 或兼容 Agent CLI 及相应模型凭据。gitclone https://github.com/OpenBMB/ForgeStencil.gitcdForgeStencil python-cimport numpy, cupy; print(deps OK)7.2 一分钟算子检查python tools/run.py--stencilstar_1--shape256--gpu0该命令编译项目算子并用 NumPy 参考检查正确性。Halide、Devito 或其他 Baseline 缺失时会显示null不影响先验证自有 Kernel要复现对比结论再按各自许可证拉取 Baseline。7.3 复现haccmk端到端结果cdapplications/haccmk ./vendor.shgitapply patches/integration.patch python../../harness/run_e2e.py--apphaccmk--gpuauto复现前应使用空闲 GPU并尽可能锁定时钟共享云节点上的绝对毫秒数和加速比会波动。审计重点不是输出是否恰好等于 README而是来源哈希、构建路径、正确性、开关差异、逐轮原始时间和汇总算法是否一致。7.4 上线自己的应用前检查检查项通过条件来源上游URL、提交、许可证与文件哈希齐全Baseline使用应用自己的最强生产GPU路径正确性全标准测例通过应用自检或可信末态比较数值容差容差来自应用语义不由Agent临时放宽性能热身、交错、多轮中位、GPU状态可追溯回归新Kernel在所有已集成应用中退化不超过门槛安全Agent无生产凭据生成Patch必须进入代码评审科学计算的正确性不能完全交给 LLM。即使自动研究阶段无人干预进入生产仓库前仍应做专家评审、编译器矩阵测试、消毒器检查和长时间数值稳定性验证。八、横向对比与边界方案搜索对象能否发现新策略真实应用部署结果可审计性Halide/Devito人定义算法与Schedule/DSL主要由人设计需要人工集成编译链和生成代码可复现AN5D/EBISU/DRStencil固定参数与变换空间限定在搜索空间内通常停留在算子层微基准较容易复现通用Coding Agent任意代码修改可以提出新方案能改项目但缺专用测量协议取决于用户提示与测试ForgeStencilProfile驱动策略、Kernel与应用Patch是双Agent迭代内置热点到真实程序Harness单开关、来源、正确性与计时规则公开ForgeStencil 的优势是把“会写 CUDA 的 Agent”变成“受测量纪律约束的优化系统”。它的边界也很明确当前聚焦 NVIDIA CUDA 和 Stencil 类问题端到端验证主要基于 A100正确性上限受原应用自检强度限制Agent 路径非确定超大加速常代表 Baseline 结构性空间不是每个 Kernel 都有同等优势。此外项目名称中的“自动部署”指把优化 Patch 集成并验证到真实开源软件不等于直接发布到企业生产集群。生产发布仍涉及安全审计、编译器和驱动兼容、回滚、SLA 与领域专家签字。九、总结维度核心结论研究闭环Kernel Agent用Plan、Code、Correctness和Profile逐轮发现并验证优化策略部署闭环App Agent定位热点、判断匹配、锻造专用算子并生成真实上游Patch结果口径100个A100端到端验证应用中位1.41×、几何平均2.05×峰值不是典型值可信机制真实程序、标准测例、单开关、自带校验、交错计时和几何平均共同防止虚报跨代能力算子库支持A100/H100/B200分派但100应用在H100/B200的端到端复测尚未完成现实边界自动集成不等于无人审批上线数值语义、安全和长期回归仍需人类负责ForgeStencil 展示了 AI for Science 的一个务实方向不是让模型写一段看起来聪明的 CUDA而是让每一个性能主张都带着来源、正确性和可复现测量。双 Agent 提供探索宽度严格 Harness 提供证据边界后者才是系统从代码生成演示走向工程研究平台的关键。参考资料ForgeStencil 官方仓库ForgeStencil 中文说明Kernel Agent 与 App Agent 运行说明跨GPU代际Re-forge研究端到端应用复现包Halide 官方网站Devito 官方网站 【面壁智能ForgeStencil技术解析】双Agent如何打通Stencil自动研究与真实应用部署
文章目录面壁智能ForgeStencil技术解析双Agent如何打通Stencil自动研究与真实应用部署一、引言二、Stencil是什么为什么它既规则又难优化2.1 从一个网格点看科学计算2.2 旧自动化为什么停在代码生成三、双Agent架构一个研究算子一个负责落地3.1 完整数据流3.2 知识库不是一堆最佳Kernel四、自动研究从Profile到可验证的新策略4.1 Kernel Agent的闭环4.2 App Agent的六项直接接入门4.3 Amdahl定律是部署前的止损线五、自动部署怎样防止Agent虚报加速5.1 Patch模式保留上游来源5.2 “fdtd金标准”的五条硬约束5.3 为什么报告几何平均六、公开结果100个应用的数字应该怎样读6.1 端到端分布6.2 算子级与跨代结果七、工程实践复现算子与真实应用7.1 环境要求7.2 一分钟算子检查7.3 复现haccmk端到端结果7.4 上线自己的应用前检查八、横向对比与边界九、总结面壁智能ForgeStencil技术解析双Agent如何打通Stencil自动研究与真实应用部署一、引言亲爱的朋友们创作不容易若对您有帮助的话请点赞收藏加关注哦您的关注是我持续创作的动力谢谢大家有问题请私信或联系邮箱jasonai.fngmail.com高性能计算里最昂贵的工作往往不是写出一个能运行的 CUDA Kernel而是证明它在真实软件中更快且没有改变科学结果。研究者要找热点、分析访存与占用率、设计分块和融合策略、反复 Profile再把新算子嵌回气象、流体、医学成像或油气软件单个微基准快十倍落进完整程序后也可能因为数据转换和同步开销只剩 1.01 倍。2026 年 8 月 4 日面壁智能联合 OpenBMB 开源 ForgeStencil。它面向 Stencil模板计算优化使用 Kernel Agent 和 App Agent 两个智能体前者执行“计划—编码—剖析”的自动研究后者完成热点定位、专用算子锻造、正确性验证和真实应用集成。项目采用 Apache-2.0 许可证公开 CUDA 算子、Agent 循环、100 个应用复现包、测量 Harness 与结果注册表。官方报告显示ForgeStencil 在 100 个端到端验证应用上取得中位 1.41×、几何平均 2.05× 的加速。真正值得研究的并非某个夸张峰值而是它如何约束智能体只有真实上游程序、程序内单开关、应用自带正确性检查、交错计时和全标准算例几何平均全部满足结果才允许标记为端到端验证。二、Stencil是什么为什么它既规则又难优化2.1 从一个网格点看科学计算Stencil 是规则网格上的邻域计算。三维 7 点 Stencil 会用当前点和上下、左右、前后六个邻居更新输出u(i,j,k) c0·u(i,j,k) cx·[u(i-1,j,k) u(i1,j,k)] cy·[u(i,j-1,k) u(i,j1,k)] cz·[u(i,j,k-1) u(i,j,k1)]类似模式出现在有限差分、扩散方程、地震波、电磁场、气象和流体模拟中。计算表达式规则却高度受显存带宽、缓存复用、线程块形状、Halo、寄存器压力和 Kernel 启动影响。优化手段目标常见副作用空间分块/Tiling提高邻域数据复用Shared Memory 与同步开销上升时间分块一次加载完成多个时间步Halo扩大、寄存器和边界逻辑复杂Kernel融合减少中间写回和启动次数寄存器压力可能降低占用率布局重排合并访存、改善缓存局部性与上下游布局不兼容时转换成本更高向量化与低精度提升带宽利用率对齐、数值误差与可移植性风险架构特化利用特定GPU代际特性跨A100/H100/B200需要分别回归2.2 旧自动化为什么停在代码生成Halide、Devito 等 DSL 能从人类定义的算法和调度生成高性能代码AN5D、EBISU、DRStencil 等自动调优器在预设搜索空间中选择参数。它们解决了大量手工编码问题但优化策略、真实应用热点和集成工作通常仍由人负责。ForgeStencil 试图补上两段让 Agent 根据 Profile 发现策略而不是只枚举固定 Tile让另一个 Agent 把策略集成到真实上游应用并通过程序自己的结果和计时判断成败。这也是项目将自身称作“自动研究 自动部署”闭环的原因。三、双Agent架构一个研究算子一个负责落地3.1 完整数据流┌──────────────── Kernel Agent ────────────────┐ │ Plan ─► Code ─► Compile ─► Correctness ─► Profile │ ▲ │ │ └──────── 性能证据 / 失败原因 / 新假设 ───┘ └──────────────────────┬──────────────────────┘ │ 优化算子与技术记录 ▼ kernel/ 算子知识库 │ ▼ ┌───────────────── App Agent ──────────────────┐ │ 拉取真实上游 ─► 定位热点 ─► 匹配/锻造算子 │ │ └────► 注入USE_OURS开关 ─► 集成Patch │ └──────────────────────┬──────────────────────┘ │ ▼ 端到端验证Harness 原始/优化交错运行 · 自带校验 · 自带计时 │ ▼ integration_registry.json / 可复现结果Kernel Agent 的循环脚本和优化规则位于agents/默认可由 Claude Code 或兼容的 Agent CLI 驱动。它每轮提出单一变化、编译、检查正确性、测量并保留有效版本。针对 H100、B200 的 Backend Brief 会把已测到的瓶颈注入提示使 Agent 从实际 Roofline 和硬件限制出发而不是重复通用 CUDA 建议。App Agent 使用算子库作为知识库先判断真实应用算子能否直接替换。若 Shape、语义、精度、布局或性能门任一不满足就进入自动研究分支目标可能变成“把物理项与 Stencil 融成一个新 Kernel”而不是勉强串两个 Kernel 造成回退。3.2 知识库不是一堆最佳Kernel算子库同时保存源代码、适用 Shape、精度、GPU 架构分支、Profile 结果和失败经验。A100 上有效的配置不一定适合 B200某个布局在算子微基准中极快若真实应用上下游使用另一布局转换流量可能吃掉全部收益。组件作用kernel/优化CUDA Kernel与A100/H100/B200运行时分派tools/run.py编译算子、与可用Baseline比较、做NumPy正确性检查agents/双Agent循环、集成状态机和优化纪律operator_bench/真实应用算子的代理微基准只能报告算子级结果applications/100个来源记录、拉取脚本、集成Patch和配置harness/构建、交错测量、正确性与端到端判定results/结果注册表和跨GPU代际原始测量这里最重要的分类是operator_bench只能说明被替换算子快了多少不能称为端到端只有harness在真实程序中跑完整标准测例才能写入e2e_validatedtrue。四、自动研究从Profile到可验证的新策略4.1 Kernel Agent的闭环建立Baseline │ ▼ 查看Kernel时间、DRAM带宽、Occupancy、寄存器与启动开销 │ ▼ 提出一个可证伪假设 例如跨步复用不足应采用K方向深预取 │ ▼ 只实现这一项变化 ─► 正确性失败回退并记录 │通过 ▼ 多轮稳健测量 ─► 性能回退回退并记录 │提升 ▼ 提交有效版本进入下一轮“每轮只改一项”让性能变化有因果解释正确性 Gate 和零回退规则阻止 Agent 为追求数字积累不可控修改连续无进展后再搜索外部资料避免一开始就复制与当前瓶颈无关的技巧。4.2 App Agent的六项直接接入门条件必须回答的问题Shape匹配邻域模式是否与库内 star、box、diamond 等完全一致语义匹配是否纯加权邻域和不含非线性物理项或方向性Gather精度匹配f16/f32/f64 是否与可用Kernel一致布局兼容Padding、Ghost和内存顺序是否与上下游一致优化版可用对应架构变体是否能编译、运行并通过正确性端到端不退化集成后是否至少不低于应用原优化路径容差2%需要拆分算子就进入研究因为“优化 Stencil 单独 Physics Kernel”会增加中间 Buffer 往返和二次读取。新研究目标通常是把两者融合成一个应用专用 Kernel直接消费原布局。4.3 Amdahl定律是部署前的止损线若 Stencil 占完整程序时间比例为f算子加速为S_kernel理论端到端加速是S_e2e 1 / ((1 - f) f / S_kernel)defprojected_speedup(operator_fraction:float,kernel_speedup:float)-float:ifnot0operator_fraction1:raiseValueError(operator_fraction must be within [0, 1])ifkernel_speedup0:raiseValueError(kernel_speedup must be positive)return1/((1-operator_fraction)operator_fraction/kernel_speedup)forfractionin(0.2,0.5,0.8):print(fraction,projected_speedup(fraction,5.0))一个 Kernel 即使快 5 倍若只占程序 20%端到端理论值也只有约 1.19 倍。ForgeStencil 要求f_app来自真实 Profile 或有来源的估计并把“算子实测”“端到端投影”“端到端实测”分开记录。五、自动部署怎样防止Agent虚报加速5.1 Patch模式保留上游来源ForgeStencil 不在仓库内打包第三方应用源码而是为每个应用保存applications/app/ ├── PROVENANCE.md # 上游URL、版本/哈希与结果 ├── vendor.sh # 从原始位置拉取源码 ├── patches/integration.patch # 注入优化路径的差异 └── e2e/ ├── manifest.json # 构建、测例、计时与校验规则 └── build.sh kernel/app_ours.cuh # ForgeStencil生成的专用算子这既减少许可证混用也使复现者能核对真实上游字节。原始路径与优化路径位于同一个程序通过USE_OURS类开关切换而不是各写一个迷你程序再对比。5.2 “fdtd金标准”的五条硬约束Gate约束防止的造假或误判真实程序Baseline是命名对应的上游Driver/Main用相似Demo冒充工业应用真实测例运行程序自带标准初始化、时间步和诊断只挑有利的小尺寸循环同程序开关Orig/Ours只有一个内部开关不同两套程序存在隐藏差异程序自检使用内置检查或同程序末态Diff只比较几个采样点程序自计时交错多轮运行并读取程序计时器冷启动、节点漂移和选择性计时任一条件失败Harness 会把结果标记为未验证或受阻不能写成端到端成果。对原项目已有 GPU 版本的应用必须优先与它自己的 GPU 路径同架构比较拿第三方框架实现替代原项目 Baseline只能说明另一个问题。5.3 为什么报告几何平均不同标准算例加速比是乘法比率算术平均容易被一个极大值拉高。几何平均对比率更合适Geomean (S1 × S2 × ... × Sn)^(1/n)项目还要求原始和优化路径交错运行多轮取中位降低 GPU 温度、时钟和共享节点负载的顺序偏差。这里的可复现是指 Patch、输入、测量产物和结果可以重跑LLM Agent 每次探索路径本身并不保证逐位一致。六、公开结果100个应用的数字应该怎样读6.1 端到端分布指标官方结果验证应用数100中位端到端加速1.41×几何平均2.05×完整区间0.998×97.7×至少1.05×89%至少1.20×73%至少1.50×43%至少3×21%至少10×7%中位数 1.41× 比 97.7× 峰值更有代表性。极大提升通常来自上游存在大量小 Kernel、Host 同步或可融合结构例如pathfinder97.7×面对高度调优的厂商或手写代码常见结果只有 1.01.5×。接近 1.0× 不一定是失败也可能说明原实现已接近硬件极限。6.2 算子级与跨代结果访存受限算子在 A100 上达到官方峰值 DRAM 带宽 2039 GB/s 的 74%85%。在 32 个同精度、同类别算子形状上ForgeStencil 相对每个 Shape 的最佳适用公开 Baseline 几何平均约 2.16×。算子库提供sm_80、sm_90、sm_100运行时分派。A100 到 H100 时许多 Kernel 仍保持 77%90% DRAM 利用到 B200 后带宽增长快于访存发射能力部分 Kernel 掉到 44%65%促使 Agent 研究更深预取等代际特化策略。必须注意100 个完整应用的端到端包统一在 A100 上验证H100/B200 的完整端到端复测仍在路线图中。“支持三代架构”不能改写成“100 个应用已在三代 GPU 全部验证”。七、工程实践复现算子与真实应用7.1 环境要求官方要求 NVIDIA GPU参考验证环境为 A100-SXM4-80GB使用 CUDA 12.x、C17 Host 编译器、Python 3.9、NumPy 与 CuPy。运行 Agent 还需要 Claude Code 或兼容 Agent CLI 及相应模型凭据。gitclone https://github.com/OpenBMB/ForgeStencil.gitcdForgeStencil python-cimport numpy, cupy; print(deps OK)7.2 一分钟算子检查python tools/run.py--stencilstar_1--shape256--gpu0该命令编译项目算子并用 NumPy 参考检查正确性。Halide、Devito 或其他 Baseline 缺失时会显示null不影响先验证自有 Kernel要复现对比结论再按各自许可证拉取 Baseline。7.3 复现haccmk端到端结果cdapplications/haccmk ./vendor.shgitapply patches/integration.patch python../../harness/run_e2e.py--apphaccmk--gpuauto复现前应使用空闲 GPU并尽可能锁定时钟共享云节点上的绝对毫秒数和加速比会波动。审计重点不是输出是否恰好等于 README而是来源哈希、构建路径、正确性、开关差异、逐轮原始时间和汇总算法是否一致。7.4 上线自己的应用前检查检查项通过条件来源上游URL、提交、许可证与文件哈希齐全Baseline使用应用自己的最强生产GPU路径正确性全标准测例通过应用自检或可信末态比较数值容差容差来自应用语义不由Agent临时放宽性能热身、交错、多轮中位、GPU状态可追溯回归新Kernel在所有已集成应用中退化不超过门槛安全Agent无生产凭据生成Patch必须进入代码评审科学计算的正确性不能完全交给 LLM。即使自动研究阶段无人干预进入生产仓库前仍应做专家评审、编译器矩阵测试、消毒器检查和长时间数值稳定性验证。八、横向对比与边界方案搜索对象能否发现新策略真实应用部署结果可审计性Halide/Devito人定义算法与Schedule/DSL主要由人设计需要人工集成编译链和生成代码可复现AN5D/EBISU/DRStencil固定参数与变换空间限定在搜索空间内通常停留在算子层微基准较容易复现通用Coding Agent任意代码修改可以提出新方案能改项目但缺专用测量协议取决于用户提示与测试ForgeStencilProfile驱动策略、Kernel与应用Patch是双Agent迭代内置热点到真实程序Harness单开关、来源、正确性与计时规则公开ForgeStencil 的优势是把“会写 CUDA 的 Agent”变成“受测量纪律约束的优化系统”。它的边界也很明确当前聚焦 NVIDIA CUDA 和 Stencil 类问题端到端验证主要基于 A100正确性上限受原应用自检强度限制Agent 路径非确定超大加速常代表 Baseline 结构性空间不是每个 Kernel 都有同等优势。此外项目名称中的“自动部署”指把优化 Patch 集成并验证到真实开源软件不等于直接发布到企业生产集群。生产发布仍涉及安全审计、编译器和驱动兼容、回滚、SLA 与领域专家签字。九、总结维度核心结论研究闭环Kernel Agent用Plan、Code、Correctness和Profile逐轮发现并验证优化策略部署闭环App Agent定位热点、判断匹配、锻造专用算子并生成真实上游Patch结果口径100个A100端到端验证应用中位1.41×、几何平均2.05×峰值不是典型值可信机制真实程序、标准测例、单开关、自带校验、交错计时和几何平均共同防止虚报跨代能力算子库支持A100/H100/B200分派但100应用在H100/B200的端到端复测尚未完成现实边界自动集成不等于无人审批上线数值语义、安全和长期回归仍需人类负责ForgeStencil 展示了 AI for Science 的一个务实方向不是让模型写一段看起来聪明的 CUDA而是让每一个性能主张都带着来源、正确性和可复现测量。双 Agent 提供探索宽度严格 Harness 提供证据边界后者才是系统从代码生成演示走向工程研究平台的关键。参考资料ForgeStencil 官方仓库ForgeStencil 中文说明Kernel Agent 与 App Agent 运行说明跨GPU代际Re-forge研究端到端应用复现包Halide 官方网站Devito 官方网站