WAMR 对 wasi_ephemeral_nn 模块的支持现状与实现分析

Wasm Micro Runtime（WAMR）作为高效的WebAssembly运行时，其模块化设计允许开发者扩展WASI标准接口。近期社区关注到部分Rust编译的Wasm模块依赖wasi_ephemeral_nn而非标准wasi_nn模块的现象，这引发了关于WAMR兼容性设计的讨论。

背景：ephemeral与标准模块的区别

在WASI规范演进过程中，ephemeral前缀通常表示临时性实验接口。wasi_ephemeral_nn是神经网络推理API的过渡实现，其函数签名与标准版存在命名差异但功能相似。这种设计允许开发者在不影响稳定接口的情况下进行快速迭代。

WAMR的现状实现

当前WAMR主分支仅实现了标准wasi_nn模块，其底层通过wasm_native.c注册模块名称为"wasi_nn"。当运行依赖wasi_ephemeral_nn的模块时，会出现函数链接失败的错误提示，这是因为运行时无法匹配模块名称导致的。

技术实现方案

通过分析Rust的wasi-nn生成代码可知，ephemeral版本主要差异在于：

1. 模块命名空间不同
2. 相同的函数接口但使用不同的模块前缀

解决方案可通过以下方式实现：

1. 在CMake构建系统中新增WAMR_BUILD_WASI_EPHEMERAL_NN编译选项
2. 添加条件编译宏WASM_ENABLE_WASI_EPHEMERAL
3. 复用现有wasi_nn的函数实现，仅修改模块注册逻辑

工程化建议

对于需要同时支持两种模块的项目，建议：

1. 保持功能实现代码的单一性
2. 通过宏控制不同模块名的注册
3. 确保ephemeral模块的启用依赖于标准NN模块的编译开关

这种设计既满足向后兼容需求，又符合WASI规范的演进路径，为开发者提供灵活的过渡方案。未来随着WASI-NN规范的稳定，可逐步将实现统一到标准接口。