streaming-llm VS openWakeWord

Just quickly glanced through the question but you might be interested in the attention sink for example where they use the fact that earlier tokens are overly attended to in general --> paper: https://arxiv.org/abs/2309.17453

That is a great question. I wish I had a mathematical explanation for it, but I can only provide some intuitive "yeah but then again"... Fwiw, there was a paper recently that indeed showed that the first few tokens of any sequence, starting with the special '[START]' token does hold special information (they call it the Attention Sink) compared to all other tokens. Here is a link to that paper:https://arxiv.org/abs/2309.17453

Oh yes, that's absolutely true - faster is better for everyone. It's just that this particular breakpoint would put realtime transcription on a $17 device with an amazing support ecosystem. It's wild.

That being said, even with this distillation there's still the aspect that Whisper isn't really designed for streaming. It's fairly simplistic and always deals with 30 second windows. I was expecting there to have been some sort of useful transform you could do to the model to avoid quite so much reprocessing per frame, but other than https://github.com/mit-han-lab/streaming-llm (which I'm not even sure directly helps) I haven't noticed anything out there.

See https://github.com/mit-han-lab/streaming-llm and others. There's good reason to believe that attention networks learn how to update their own weights (Forget the paper) based on their input. The attention mechanism can act like a delta to update weights as the data propagates through the layers. The issue is getting the token embeddings to be more than just the 50k or so that we use for the english language so you can explore the full space, which is what the attention sink mechanism is trying to do.

📚Research Paper: https://arxiv.org/pdf/2309.17453.pdf 💻 Code: https://github.com/mit-han-lab/streaming-llm

The authors just uploaded a FAQ sections, which may clarify some of the confusions: https://github.com/mit-han-lab/streaming-llm/blob/main/READM...

Deploying Large Language Models (LLMs) in streaming applications such as multi-round dialogue, where long interactions are expected, is urgently needed but poses two major challenges. Firstly, during the decoding stage, caching previous tokens' Key and Value states (KV) consumes extensive memory. Secondly, popular LLMs cannot generalize to longer texts than the training sequence length. Window attention, where only the most recent KVs are cached, is a natural approach -- but we show that it fails when the text length surpasses the cache size. We observe an interesting phenomenon, namely attention sink, that keeping the KV of initial tokens will largely recover the performance of window attention. In this paper, we first demonstrate that the emergence of attention sink is due to the strong attention scores towards initial tokens as a "sink'' even if they are not semantically important. Based on the above analysis, we introduce StreamingLLM, an efficient framework that enables LLMs trained with a finite length attention window to generalize to infinite sequence lengths without any fine-tuning. We show that StreamingLLM can enable Llama-2, MPT, Falcon, and Pythia to perform stable and efficient language modeling with up to 4 million tokens and more. In addition, we discover that adding a placeholder token as a dedicated attention sink during pre-training can further improve streaming deployment. In streaming settings, StreamingLLM outperforms the sliding window recomputation baseline by up to 22.2x speedup. Code and datasets are provided in the link.

https://github.com/dscripka/openWakeWord

Balancing wake reliability vs false wake activation is a tricky balance. OWW is decent but could certainly be better.

It's used with Home Assistant now so I expect the training data and implementation overall to get significantly better fairly soon.

There's also OpenWakeWord[0]. The models are readily available in tflite and ONNX formats and are impressively "light" in terms of compute requirements and performance.

It should be possible.

[0] - https://github.com/dscripka/openWakeWord

hey, quick question. do you mind if I use your stft function in the speech preprocessing library I've been working on? we've been trying to add support for doing mel spectrograms to build a runner for openwakeword, but progress is pretty slow because I've been soloing something I really don't have the right background for(I've never directly studied or worked with signal processing)

potentially build another runner for open wakeword

here's what's on the pipeline next: - finish mel-spectrogram implementation - publish initial version on crates - move python caching rust side - finish implementing in the precise rust port - potentially build another runner for (open wakeword)[https://github.com/dscripka/openWakeWord] - build an android app that supports user-defined wakewords and has some popular defaults to load. ps not a voice assistant, just the thing that activates the voice assistant.