wasi-nn VS wasmer

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)

This is awesome. I'd love to have upstream support in Wasmer ( https://wasmer.io )

WebAssembly is extremely portable. WebAssembly runs on: all major web browsers, V8 runtimes like Node.js, and independent Wasm runtimes like Wasmtime, Lucet, and Wasmer.

Unfortunately cosmopolitan wouldn't work for dockerc. Cosmopolitan works as long as you only use it but container runtimes require additional features. Also containers contain arbitrary executables so not sure how that would work either...

As for WASM, this is already possible using container2wasm[0] and wasmer[1]'s ability to generate static binaries.

[0]: https://github.com/ktock/container2wasm

[1]: https://wasmer.io/

I could not find any guide how to add WASM container capability to Docker running on Colima. This guide provides a few Colima templates for exactly this, which adds WasmEdge, Wasmtime and Wasmer runtime types.

Just suggested as well Wasmer on Twitter! https://github.com/wasmerio/wasmer

Looking forward to seeing the results :)

The Biome team has been incredibly fast on solving the challenge and achieving 95% compatibility with Prettier [1]

Just as a note, as it was not mentioned in the article, Wasmer [2] also participated with a $2,500 bounty to compile Biome to WASIX [3], and it has been awesome to see how their team has been working to achieve this as well... hopefully we'll get Biome running in Wasmer soon!

Keep up the great work!!

[1] https://github.com/biomejs/biome/issues/720

[2] https://wasmer.io/

[3] https://wasix.org/

It's funny how WebAssembly can help overcome most of the issues mentioned on the blogpost (packaging, configuration, portability) if addressed properly.

That's the main reason Wasmer [1] was created :)

[1] https://wasmer.io

Thanks for the mention to Wasmer.

I'll put here a link in case is useful for future readers: https://wasmer.io/