about Nexfort compile cache

[Shiroha-Key]

使用Nexfort加速diffusers的UNet2DConditionModel。
onediff 1.2.1.dev14
onediffx 1.2.1.dev18+g6b53a83b.d20240815
nexfort 0.1.dev262

第一次生成图像时的autotune过程时间很长 ，在20～40分钟左右，使用O2模式。

我已经正确设置了这里提到的两个环境变量，但我不太清楚第一个变量发挥的作用。

这里是autotune时的一部分代码，会有一些错误报告，但最后仍能完成。但为何会有一些很夸张大的尺寸？（例如AUTOTUNE nexfort_geglu(36864x640, 640x2560, 640x2560, 2560, 2560)的36864x640
https://gist.github.com/Shiroha-Key/d929c7c3b6401829276e620cd3363a35

报错我在#1057 见到了一样的，在我添加"inductor.optimize_linear_epilogue": False错误不再出现。

总的来说。。他真的很长 且我每次启动服务生成第一张图时都要经历一次。

所以我想问现在基于现在的情况，是什么问题导致了autotune过程这么慢？有没有能够加速过程的方法？或者更好的 离线编译存储结果 在线时加载？我没有找到Nexfort与这些相关的api。

[clackhan]

这里是autotune时的一部分代码，会有一些错误报告，但最后仍能完成

nexfort已经在修复，相关代码正在加紧合并中

是什么问题导致了autotune过程这么慢？有没有能够加速过程的方法？

autotune是为了变编译过程中为某个op选择最快的实现，比如说 matmul(x, y)，x.size为(400, 600)，y的size为(600, 1000)，autotune尝试使用不同的配置执行这个op，从中选择最快的配置，所以autotune过程会比较慢，暂时没有比较好的加速方式。

或者更好的 离线编译存储结果 在线时加载？

目前新版nexfort已经支持编译缓存，尝试更新一下 nexfort，然后设置下面两个环境变量：

export NEXFORT_GRAPH_CACHE=1
export TORCHINDUCTOR_CACHE_DIR=~/torchinductor

这两个环境变量的作用是：
NEXFORT_GRAPH_CACHE=1是指打开编译缓存设置
TORCHINDUCTOR_CACHE_DIR是指编译缓存的位置

为何会有一些很夸张大的尺寸？（例如AUTOTUNE nexfort_geglu(36864x640, 640x2560, 640x2560, 2560, 2560)的36864x640

这个与具体的模型和生图尺寸有关系

[Shiroha-Key]

感谢 原来是dev264刚更新上的 我说环境变量怎么没有起作用:3

[Shiroha-Key]

请问nexfort的动态尺寸dynamic还有在支持吗？
我测了一下 还是会重编译。
Should have no compilation for these new input shape
The nexfort backend encounters an exception when dynamically switching resolution to 960x720.

[strint]

请问nexfort的动态尺寸dynamic还有在支持吗？ 我测了一下 还是会重编译。 Should have no compilation for these new input shape The nexfort backend encounters an exception when dynamically switching resolution to 960x720.

当前是的。现在推荐使用预热的方式，把常用的分辨率都请求一遍，做下预热就会有缓存。