Yay fun to see it make its way to HN :) It turns out that my original checkpoint runs _way_ faster than I expected (100 tok/s) on MacBook Air M1 with -O3 when compiling, so I am now training a bigger 44M model, which should still running interactively. Maybe the 7B Llama model is within reach... :thinking_emoji:
Llama2.c: Inference llama 2 in one file of pure C
31–40 of 173 posts
Re: Llama2.c: Inference llama 2 in one file of pure C
#32Earlier quoted context omitted.
You don't have to do the loading/discarding explicitly. You could just mmap the entire network and let the os handle that.
Didn't llama.cpp need to convert the weights file to a new format to support that? The way they're stored in the official file isn't efficient for operating on directly.
Re: Llama2.c: Inference llama 2 in one file of pure C
#33Sounds like what Llama.cpp used to be.
I'm not sure what you mean by "used to be", the llama.cpp github repository was committed to just 4 hours ago. This project cites llama.cpp as inspiration, but seems much-simplified. It only supports llama-2, only supports fp-32, and only runs on one CPU thread.
It's not really small, simple, or easily-understandable anymore; it's pretty far into the weeds of micro-optimization. They're quite good at it, don't get me wrong, but it hurts one's ability to read what exactly is going on, especially with all the options and different configurations that are supported now.
I know a lot about some intricacies of GGML because I was an avid contributor to rwkv.cpp for a few weeks, but I still don't understand llama.cpp. It's just on a completely different level.
Re: Llama2.c: Inference llama 2 in one file of pure C
#34https://ggerganov.com/llama2.c/
Via his Twitter with ongoing thread: https://twitter.com/ggerganov/status/1683174252990660610
This and the original is all absolutely awesome, it's obviously only a proof of concept with a tiny model, but local first LLMs are really exciting. I particularly love the idea of being able to build webapps with local inference.
With optimisation, research into ways to make smaller models, partial downloads, and then the opportunity to use WebGPU we potentially have the start of an exciting new way to build privet local LLM based apps.
It's never going to be up to the same capabilities of hosted LLMs on massive clusters of top end GPUs, but there are so many use cases that this sort of thing will enable.
Re: Llama2.c: Inference llama 2 in one file of pure C
#35Yay fun to see it make its way to HN :) It turns out that my original checkpoint runs _way_ faster than I expected (100 tok/s) on MacBook Air M1 with -O3 when compiling, so I am now training a bigger 44M model, which should still running interactively. Maybe the 7B Llama model is within reach... :thinking_emoji:
Re: Llama2.c: Inference llama 2 in one file of pure C
#36To run a neural network, how much memory does one need? Is it enought to load the first two layers from disk, calculate the activations for all nodes, discard the first layer, load the third layer from disk, calculate all the activations for all nodes, discard the second layer etc? Then memory needs to be big enough to hold to 2 layers?
I think for O(N^2) transformer inference you need to cache all the activations.
Re: Llama2.c: Inference llama 2 in one file of pure C
#37Re: Llama2.c: Inference llama 2 in one file of pure C
#38More details from Andrej here: https://twitter.com/karpathy/status/1683143097604243456?s=46...
Re: Llama2.c: Inference llama 2 in one file of pure C
#39Earlier quoted context omitted.
You don't have to do the loading/discarding explicitly. You could just mmap the entire network and let the os handle that.
Didn't llama.cpp need to convert the weights file to a new format to support that? The way they're stored in the official file isn't efficient for operating on directly.
Re: Llama2.c: Inference llama 2 in one file of pure C
#40As someone who doesn’t work with languages like C, what’s the appeal of “in one file” or “header only”? Is it about dependency management?
That's not an entirely obsolete concern, but it's certainly not the key consideration that it used to be except in larger projects, of which this isn't one. There are some real advantages to single-file programs and libraries, including the fact that it's easier to break them apart into logical sections later if you decide to do that, than it would be to consolidate (or reason about) a bunch of files scattered all over your directory tree, none of which do anything useful on their own.