As Snowden told us, video and audio recording capabilities of your devices are NSA spying vectors. OSS/Linux is a safeguard against such capabilities. The massive datacenter investments in US will be used to classify us all into a patriotic (for Israel)/Oligarchist social credit score, and every mega tech company can increase profits through NSA cooperation, and are legally obligated to cooperate with all government orders.
Speech to text and speech automation are useful tech, though always listening state sponsored terrorists is a non-NSA targeted path for sweeping future social credit classifications of your past life.
Some small LLMs that can be used for speech to text: https://modal.com/blog/open-source-stt
Aye, I was actually hoping to use the NPU for TTS/STT while keeping the LLM systems GPU bound.
It still uses memory bandwidth, unfortunately. There’s no way around that, though NPU TTS would still be neat.
…Also, generally, STT responses can’t be streamed, so you mind as well use the iGPU anyway. TTS can be chunked I guess, but do the major implementations do that?
Piper does chunking for TTS, and could utilise the NPU with the right drivers.
And the idea of running them on the NPU is not about memory usage but hardware capacity/parallelism. Although I guess it would have some benefits when I don’t have to constantly load/unload GPU models.
Oh, I forgot!
You should check out Lemonade:
https://github.com/lemonade-sdk/lemonade
It’s supports Ryzen NPUs via 2 different runtimes… though apparently not the 8000 series yet?
I’ve actually been eyeing lemonade, but the lack of Dockerisation is still an issue… guess I’ll just DIY it at one point.
It’s all C++ now, so it doesn’t really need docker! I don’t use docker for any ML stuff, just pip/uv venvs.
You might consider Arch (dockerless) ROCM soon; it looks like 7.1 is in the staging repo right now.
Due to the fact I am running UnRaid on the node in question, I kinda do need Docker. I want to avoid messing with the core OS as much as possible, plus a Dockerised app is always easier to restore.
Yeah… Even if the LLM is RAM speed constrained, simply using another device to not to interrupt it would be good.
Honestly AMD’s software dev efforts are baffling. They’ve focused on a few on libraries precisely no-one uses, like this: https://github.com/amd/Quark
While ignoring issues holding back entire sectors (like broken flash-attention) with devs screaming about it at the top of their lungs.
Intel suffers from corporate Game of Thrones, but at least they have meaningful contributions in the open source space here, like the SYCL/AMX llama.cpp code or the OpenVINO efforts.