Inference at the edge #205

you are a bamf

I can only second @chidiwilliams here, that I am incredibly grateful for the work that @ggerganov has done with both Whisper.cpp and LLaMa.cpp. I believe it has really put the power of these models into the hands of users, and that the future is in on-device and at the edge. We have been very inspired by the work and wanted to make it even more user-friendly with WhisperScript) so that even non-programmers can benefit from the advancements in this tech. Thanks for the work and looking forward to learning even more from you!

We now also have a Windows version available, if anyone is looking for a simple, clean UI to run Whisper on their Windows desktop: Windows WhisperScript UI

oiste ggeganov , no eres nada bueno , te envie emails un monton para ser amigos , yo quiero ser amigo tuyo para aprender cosas y tu no me añadiste de amigo , y asi como voy a aprender a ser un super programador de inteligencia artificial como tu si no quieres ser mi amigo? ni me añades al whatsapp ni al facebook ni en ningun lado..no contestaste mis correos electronicos que hice una interfaz tui para llama-server en python , y yo quiero ser tu amigo y hablar contigo y aprender cosas y tu no me ayudas!!! tenemos que hacer otro invento para enviar datos por audio , pero con rayos laser o algo asi mas moderno , viste como ahora ya investigaron para hacer un wifi mucho mas rapido por laser , pero nosotros tenemos que hacer uno por morse , se puede hacer usando raspberrys , yo se como se hace , raspberry puede generar audio modulado en fm al tener gpio y podemos transmitir datos a alta velocidad y largas distancias solo usando un simple transistor y una antena pequeña , seria transmitir fm de radio comercial , pero en una banda vacia que no use la fm , pero usar la modulacion fm para transmitir los datos y asi mejoramos tu programa y las raspberrys puedes ser nodos de comunicacion en caso de desastre mundial , aunque la gente no tenga internet , entiendes?? tu hazme amigo mio yque aprendemos cosas juntas. mandame correos a mail.snaj@gmail.com y somos amigos , te invito a unas cervezas...HASTA LUEGO!!

The Corp™'s firewall of cash blocked it but if we work back from the edge we should be able to get through and get some of that sweet sweet compute. If attention is all it needs it's definitely got it now ( but I jest ⚖️ )

I guess it depends on the end goal but in my mind it would be some sort of DMZ at first and then everyone is invited in and accessible through P2P Mesh style. Very much like the internet runs but more open to get the purest prima materia. Money, copyright and individual rights/freedoms are the biggest obstacles I guess. Apparently the transformers are driven by attention which is probably good. I like to pretend they would ultimately use creativity to overcome formality but 𝘸𝘩𝘰 knows.

+1 for Flan, but for the FLAN-T5 XXL version =)
One can compare them here.

Flan-T5-XXL is also a great model, but I'm not convinced that it's better. Here is another HF space that offers direct side-by-side comparison.

so the int4 here requires only 6GB ram? It seems to me that the tokenizer's vocabulary has mixed zh and en subwords.

Yes chatGLM was finetuned over 1 trillion tokens of Chinese and English dialogue corpus as well as extensive RLHF in both languages. The base model, GLM-130B, was already impressive and largely overlooked prior to instruct finetuning.

and if we look at the HF code here it is using SentencePiece tokenizer
with

PRETRAINED_POSITIONAL_EMBEDDINGS_SIZES = {
    "THUDM/chatglm-6b": 2048,
}

hence I have understood well, it should be easy to port it to GGML, isn't it?

Looking forward to your results, a lot of people are waiting for the ggml version of chatGLM

It's an interesting model but licensed solely for non-commercial research purposes. Personally, I think it would be really nice to have a capable and truly open source model like FLAN-UL2 20B available in llama.cpp.

I agree - CTranslate2 seems to be very efficient and the authors have done a great job. Their faster-whisper implementation actually outperforms significantly whisper.cpp.

Thank you @Const-me - much appreciated as always!
I will soon be looking into finalizing the 4-bit ggml branch and will definitely look into integrating the proposed changes

The pinecone embeddings plugin was just a proof of concept. The author was trying to show that plugins can work with local models.

Pretty much nobody running llama has a need for Pincone, yes. But the proof that we can do plugins just like chatGPT can is cool and we should make more which are actually useful.

@MarkSchmidty Wait, do you mean that the plugins themselves could work completely outside the chatgpt service and have the cloud environment and API hosted locally? If that's true, then that is indeed awesome. I thought it was just a interface to the openai API? Now I'm confused.

I'm not against cloud services per-se and there are many which I like and use, what I am against is the tricks and attempts to lock users in their ecosystems, and as so many 'cloud service' providers aggresively move towards forced SaaS-models, hearing the word 'cloud' makes me slightly cringe already. I do understand why its happening, it makes very good business sense but it doesnt make it any less scummy. If this really is something that works towards truly "Open" AI , and not a underhanded attempt to sell their services then fantastic! You'd have to excuse my cynicism when it comes to the 'cloud' topic, as not all of them are bad actors.

The llama-retrieval-plugin does not contact or use OpenAI's servers in any way. It connects your locally running llama.cpp with one of a selection of vector database providers, including a local redis vector database option. Vector databases don't really have use cases for personal use. The reason this plugin was used for the proof of concept is because it's the only plugin OpenAI open sourced (so far).

Now that we know how these plugins work broadly and how to adapt them for local models, we should be able to reverse engineer more useful plugins like web browser, code interpreter, Zapier, etc. to keep up with ChatGPT's latest improvements while not giving anything to OpenAI.

really?

The be clear, most of the speed is coming from moving fewer bits between CPU and RAM due to smaller models. RAM bandwidth is the bottleneck for efficient CPU inference. Quantization, reducing bits per parameter, is just one way to reduce the memory footprint of a model. Other methods, such as pruning, remove entire parameters with little effect on quality. These can even be combined-- and we've yet to explore that. It's quite likely we can get nearly 50% more model size and 50% higher speeds without any additional optimizations to the inference code.

@MarkSchmidty You are right at the theoretical level that the CPU<->RAM connection and the sequential nature of CPU computation are the ultimate bottlenecks. I'm not claiming to be a mathematician nor to completely understand the intricancies of the calculations themselves, but I do understand optimization. And in that regard, while you are not wrong in saying that most of the speed comes from having to deal with less data, it's also a bit misleading as the importance of fast and optimized code cannot be understated. To be able to go even near the absolute limit of performance of the hardware. Anyone telling otherwise, I dare them to make a equally performing CPU implementation in something like .NET or Python. Exactly because having to move so much data and performs tons of calculations all the inefficiencies in code add up, and add up fast. And save from hand-optimizing in pure assembly, C is pretty much the best you can do to be as close to the bare metal as possible and utilising the cycles & bandwidth efficiently and not wasting them. @ggerganov has simply done an amazing job in making a lean and efficient codebase. It's true that there might not be much more performance to gain by optimizing the inference code since it is already well optimized, but then again I could be wrong. Modern processors rely heavily on branch prediction and caching and there still can be performance to gain by reducing cache misses and wrong branch predictions. Unfortunately the whole area of it is pretty much black magic / art and without an expert background in processor design it is very hard to optimize for at that very lowest silicon level.

the importance of fast and optimized code cannot be understated.

I didn't mean to imply otherwise. Georgi deserves all the credit. It's definitely possible there are memory handling optimizations which could improve performance on the code side. But it would likely take a processor design expert to identify them, and there are very few of those in the world. Currently there's some obvious low hanging fruit on the model size end of things (sparsity, pruning, 3bit, etc.).

did anyone test this yet? seems like an easy thing to try.

I believe more in giving power to everyone, rather than to a dictatorial cloud.

Although I say this like a rant, the facts prove that it is easier to get up from the clouds than to get down from the clouds. With the improvement of computing power, what we lack is not large servers, but private and controllable edge software.

Having the ability to "cheat" and run models I shouldn't be able to due to your efficient programming is simply a miracle.

what do you think it is that happened that people might consider that they “shouldn’t be able” to run large models on small hardware?

i’m old, in the 90s we did everything in under 64k …

It seems the problem is two-pronged:

• From the individual end, the “Conspicuous Consumption” syndrome causes people to consider their upper-middle-end builds as a baseline, rather than considering the baseline as a baseline. When these people go on to be software developers, we get today's loss of accessibility.
• From the corporate end, it's ironically a lot more comfortable if software requires a lot of resources. If you "have" to drop $10,000 on hardware to run a piece of software, then suddenly paying $700/mo for a corporate support plan becomes more reasonable by comparison. Or you could just pay Amazon $700/mo for their specially licensed GPU cluster, which then looks like an amazing deal! Creating the synthetic need for excessive hardware raises opportunity costs, which is profitable.