wasi-nn VS wagi

I really like the post that they mention (https://www.secondstate.io/articles/fast-llm-inference/). The reasons for avoiding python all resonate with me. I'm excited to play with WASI-NN (https://github.com/WebAssembly/wasi-nn) and that rust code is very readable to load up a GGUL model.

Mmm…

The wasm-nn that this relies on (https://github.com/WebAssembly/wasi-nn) is a proposal that relies of arbitrary plugin backends sending arbitrarily chunks to some vendor implementation. The api is literally like set input, compute, set output.

…and that is totally non portable.

The reason this works, is because it’s relying on the abstraction already implemented in llama.cpp that allows it to take a gguf model and map it to multiple hardware targets,which you can see has been lifted here: https://github.com/WasmEdge/WasmEdge/tree/master/plugins/was...

So..

> Developers can refer to this project to write their machine learning application in a high-level language using the bindings, compile it to WebAssembly, and run it with a WebAssembly runtime that supports the wasi-nn proposal, such as WasmEdge.

Is total rubbish; no, you can’t.

This isn’t portable.

It’s not sandboxed.

If you have a wasm binary you might be able to run it if the version of the runtime you’re using happens to implement the specific ggml backend you need, which it probably doesn’t… because there’s literally no requirement for it to do so.

There’s a lot of “so portable” talk in this article which really seems misplaced.

in machine learning (https://github.com/WebAssembly/wasi-nn)

WAGI and WCGI are the WASM based spiritual successors.

https://github.com/deislabs/wagi

https://wasmer.io/posts/announcing-wcgi

Compile a CGI program in any language to WASI, then use https://github.com/deislabs/wagi to run it.

Yeah of course! They've got STDIN/STDOUT/STDERR and I've built a Virtual Filesystem. But if you're using WASI binaries locally they don't have that restriction.

You might be interested in WAGI: https://github.com/deislabs/wagi

And to catch up on WASI: https://xeiaso.net/talks/unix-philosophy-logical-extreme-was...

As I'm sure you've heard, WASM has been growing in popularity and use over the past few years. And with the creation of WASI (Web Assembly System Interface) and WAGI (Web Assembly Gateway Interface), WASM is starting to venture outside of running just in the browser. And in the case of WAGI, if you've been programming since the earlier days of the internet, it might feel very similar to CGI programming (and that's because it's based on CGI1.1!) WAGI provides a way for developers to define handlers for HTTP requests and route them to specific functions inside of, or entire, WASM modules. It does so by piping the headers of the incoming request to os.Args[1:], piping the body of the incoming request to os.Stdin, and writing the response to os.Stdout. (To learn more about configuring, routing, compiling, and deploying WAGI routes, as well as the limitations of WAGI routes, please consult the WAGI docs and the TinyGo WASM docs)

What do you think of WAGI [1], which is basically CGI for WASM modules.

[1]: https://github.com/deislabs/wagi/blob/main/docs/writing_modu...

as serverless functions (https://github.com/deislabs/wagi)

I'm experimenting with WASM & Rust but with a different framework named wagi, there's a great video by Rainer Stropek & Stefan Baumgartner that gives a little introduction to it [0]

[0]: https://www.youtube.com/watch?v=9NDwHBjLlhQ

[1]: https://github.com/deislabs/wagi

Krustlet and WAGI are two such projects.

It does support it, the runtime we are currently using enables that -- see https://github.com/deislabs/wagi/blob/main/docs/writing_modu...

Good point on the docs, I will open an issue and add some information about it, thanks!