News for hackers. Stuff that matters.
Re:ExecuTorch: Enabling On-Device interference for embedded ... by shoumikhin on Tuesday October 17, 2023 @04:49PM (#37921396)
Hey guys, we are ExecuTorch team, we're excited about launching this! Please ask us anything :)
Re:ExecuTorch: Enabling On-Device interference for embedded ... by mlmandude on Tuesday October 17, 2023 @05:37PM (#37921951)
It looks like executorch is for edge devices (phones / IoT / etc).

I'm currently doing inference on GPUs for libtorch and have a few concerns: (1) It seems like libtorch/torchscript are on a path to getting deprecated and (2) libtorch/torchscript pull in enormously bloated libraries. Should I be looking at executorch? I currently don't see an nvidia backend / integration with tensor rt in https://github.com/pytorch/executorch/tree/main/backends , but seems like it might be possible. Is this something you are thinking about?

Re:ExecuTorch: Enabling On-Device interference for embedded ... by iseeyuan on Tuesday October 17, 2023 @06:56PM (#37922665)
Yes ExecuTorch is currently targeted at Edge devices. The runtime is written in C++ with 50KB binary size (without kernels) and should run in most of platforms. You are right that we have not integrated to Nvidia backend yet. Have you tried torch.compile() in PyTorch 2.0? It would do the Nvidia optimization for you without Torchscript. If you have specific binary size or edge specific request, feel free to file issues in https://github.com/pytorch/executorch/issues
Re:ExecuTorch: Enabling On-Device interference for embedded ... by fooblaster on Tuesday October 17, 2023 @10:04PM (#37924076)
torch.compile only works with python from what I understand. Many people need a native way to run GPU models, but don't want the bloat of full libtorch.
Re:ExecuTorch: Enabling On-Device interference for embedded ... by nothrowaways on Tuesday October 17, 2023 @06:06PM (#37922253)
Nice tool with ugly name
Re:ExecuTorch: Enabling On-Device interference for embedded ... by BudaDude on Tuesday October 17, 2023 @06:13PM (#37922321)
It's one of those names that sound better said aloud than spelled out. Excited to see where this goes though!
Re:ExecuTorch: Enabling On-Device interference for embedded ... by modeless on Tuesday October 17, 2023 @07:29PM (#37922937)
Looks cool! Does the Vulkan backend work on PC? MLC-LLM proves it can work well and it would be cool to have a cross platform, minimal runtime, GPU-agnostic backend for PC too, not just mobile.
Re:ExecuTorch: Enabling On-Device interference for embedded ... by ssjia on Wednesday October 18, 2023 @11:27AM (#37930050)
The Vulkan backend does work on PC, as the only requirement is that Vulkan drivers are present. However, it was developed with mobile use-cases in mind and we haven't validated/optimized performance for PC.

As an aside, the Vulkan backend is tied to TorchScript at the moment, so it is not yet compatible with ExecuTorch. However, we are also planning to introduce a Vulkan delegate for ExecuTorch which will enable GPU delegation through ExecuTorch.

Re:ExecuTorch: Enabling On-Device interference for embedded ... by suyash on Wednesday October 18, 2023 @05:39AM (#37926557)
Is it possible to execute a light weight language model, perhaps this https://github.com/facebookresearch/llama using ExecuTorch to run on smartphone in real time for a chatbot app ? Please share some guidance.
Re:ExecuTorch: Enabling On-Device interference for embedded ... by alex_hirner on Wednesday October 18, 2023 @10:07AM (#37928892)
We like Rust for its build tooling and safe concurrency primitives. Thus we are eyeballing with candle [1].

OTOH, writing platform specific backends is a huge undertaking. Do you think backends such as MPS may become a shared effort?

[1] https://github.com/huggingface/candle [2] https://github.com/huggingface/candle/issues/313

Re:ExecuTorch: Enabling On-Device interference for embedded ... by whobair on Friday October 20, 2023 @08:40AM (#37955263)
hey - this might be a rather specific use case, but our applications need to run "real-time" and allocation-free - are there any guarantees on that from your side? assuming fixed shapes, pre-allocating everything for the forward pass should probably be possible in theory, but i guess that wasn't really a relevant factor in the design of it all