【面壁智能ForgeStencil技术解析】双Agent如何打通Stencil自动研究与真实应用部署

面壁智能ForgeStencil技术解析：双Agent如何打通Stencil自动研究与真实应用部署

一、引言

亲爱的朋友们，创作不容易，若对您有帮助的话，请点赞收藏加关注哦，您的关注是我持续创作的动力，谢谢大家！有问题请私信或联系邮箱：jasonai.fn@gmail.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(i+1,j,k)] + cy·[u(i,j-1,k) + u(i,j+1,k)] + cz·[u(i,j,k-1) + u(i,j,k+1)]

类似模式出现在有限差分、扩散方程、地震波、电磁场、气象和流体模拟中。计算表达式规则，却高度受显存带宽、缓存复用、线程块形状、Halo、寄存器压力和 Kernel 启动影响。

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；某个布局在算子微基准中极快，若真实应用上下游使用另一布局，转换流量可能吃掉全部收益。

这里最重要的分类是：operator_bench只能说明被替换算子快了多少，不能称为端到端；只有harness在真实程序中跑完整标准测例，才能写入e2e_validated=true。

四、自动研究：从Profile到可验证的新策略

4.1 Kernel Agent的闭环

建立Baseline │ ▼ 查看Kernel时间、DRAM带宽、Occupancy、寄存器与启动开销 │ ▼ 提出一个可证伪假设 例如：跨步复用不足，应采用K方向深预取 │ ▼ 只实现这一项变化 ─► 正确性失败？回退并记录 │通过 ▼ 多轮稳健测量 ─► 性能回退？回退并记录 │提升 ▼ 提交有效版本，进入下一轮

“每轮只改一项”让性能变化有因果解释；正确性 Gate 和零回退规则阻止 Agent 为追求数字积累不可控修改；连续无进展后再搜索外部资料，避免一开始就复制与当前瓶颈无关的技巧。

4.2 App Agent的六项直接接入门

需要拆分算子就进入研究，因为“优化 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:ifnot0<=operator_fraction<=1:raiseValueError("operator_fraction must be within [0, 1]")ifkernel_speedup<=0: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金标准”的五条硬约束

任一条件失败，Harness 会把结果标记为未验证或受阻，不能写成端到端成果。对原项目已有 GPU 版本的应用，必须优先与它自己的 GPU 路径同架构比较；拿第三方框架实现替代原项目 Baseline，只能说明另一个问题。

5.3 为什么报告几何平均

不同标准算例加速比是乘法比率，算术平均容易被一个极大值拉高。几何平均对比率更合适：

Geomean = (S1 × S2 × ... × Sn)^(1/n)

项目还要求原始和优化路径交错运行多轮取中位，降低 GPU 温度、时钟和共享节点负载的顺序偏差。这里的可复现是指 Patch、输入、测量产物和结果可以重跑；LLM Agent 每次探索路径本身并不保证逐位一致。

六、公开结果：100个应用的数字应该怎样读

6.1 端到端分布

中位数 1.41× 比 97.7× 峰值更有代表性。极大提升通常来自上游存在大量小 Kernel、Host 同步或可融合结构，例如pathfinder97.7×；面对高度调优的厂商或手写代码，常见结果只有 1.0～1.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、C++17 Host 编译器、Python 3.9+、NumPy 与 CuPy。运行 Agent 还需要 Claude Code 或兼容 Agent CLI 及相应模型凭据。

gitclone https://github.com/OpenBMB/ForgeStencil.gitcdForgeStencil python-c"import 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 上线自己的应用前检查

科学计算的正确性不能完全交给 LLM。即使自动研究阶段无人干预，进入生产仓库前仍应做专家评审、编译器矩阵测试、消毒器检查和长时间数值稳定性验证。

八、横向对比与边界

ForgeStencil 的优势是把“会写 CUDA 的 Agent”变成“受测量纪律约束的优化系统”。它的边界也很明确：当前聚焦 NVIDIA CUDA 和 Stencil 类问题；端到端验证主要基于 A100；正确性上限受原应用自检强度限制；Agent 路径非确定；超大加速常代表 Baseline 结构性空间，不是每个 Kernel 都有同等优势。

此外，项目名称中的“自动部署”指把优化 Patch 集成并验证到真实开源软件，不等于直接发布到企业生产集群。生产发布仍涉及安全审计、编译器和驱动兼容、回滚、SLA 与领域专家签字。

九、总结

ForgeStencil 展示了 AI for Science 的一个务实方向：不是让模型写一段看起来聪明的 CUDA，而是让每一个性能主张都带着来源、正确性和可复现测量。双 Agent 提供探索宽度，严格 Harness 提供证据边界；后者才是系统从代码生成演示走向工程研究平台的关键。

参考资料：

1. ForgeStencil 官方仓库
2. ForgeStencil 中文说明
3. Kernel Agent 与 App Agent 运行说明
4. 跨GPU代际Re-forge研究
5. 端到端应用复现包
6. Halide 官方网站
7. Devito 官方网站