AI Engineer World's Fair 2024
Llamafile: bringing AI to the masses with fast CPU inference
Read the talk
Llamafile: portable models and faster CPU inference
A single executable makes local models easier to distribute; better matrix multiplication and thread coordination make the CPUs people already own more useful.
From a talk by Stephen Hood and Justine Tunney
Before you start: Basic familiarity with language models, CPU and GPU execution, and programming loops will help with the performance discussion.
Turn weights into a program
What if downloading a language model also gave you the program needed to run it? llamafile packages model weights and inference software into a single executable. Mozilla’s access goal starts with that reduction in complexity: running open models should not require assembling an entire software stack, and improving that experience should be within reach of individuals and small open-source teams.
The distribution unit is the same file across supported systems, rather than separate downloads for Windows, macOS, and Linux. It runs without a conventional installation and uses available CPU or GPU hardware. Stephen Hood presents this as broad portability across operating systems and architectures; the practical promise is a portable package, not a guarantee that every possible computer configuration works.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Make existing CPUs useful
Portability matters more if the hardware people already have can run the model usefully. GPUs are expensive, can be difficult to source, and consume substantial electricity. Meanwhile, affordable CPUs are distributed throughout the world. Requiring a GPU for local AI risks excluding that installed base before exploring what better software could accomplish.
llamafile builds on llama.cpp, which established that CPU inference was practical. The project also contributes performance improvements upstream, with many already merged by the time of the talk. Hood reports 30–500% speed increases depending on the CPU, model, and weights. That range should be read in the context of CPU prompt evaluation, rather than as a universal increase in generated tokens per second; the accompanying research scopes it to F16 and Q8_0 weights against llama.cpp.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Run locally, distribute simply
Local execution also changes the privacy boundary. Once the file is on the machine, inference can continue with the network disconnected. Hood describes the supplied experience as making no cloud LLM calls and sending no monitoring, analytics, or user data off the machine. The package includes what is needed both to experiment with a model and to begin building applications around local inference.
The distribution path is correspondingly short: find a model on Hugging Face, filter for the llamafile format, or look through Mozilla’s published files. For model publishers, Hood describes creating a custom llamafile with a single command. The intended result is that both trying a model and sharing one become ordinary file operations instead of installation projects.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Why Mozilla is involved
Mozilla’s rationale reaches back to the browser era. Hood recalls early web users coming close to depending on one company and one product for access to the web. AI raises a related concern: a few influential companies could end up controlling the future of machine intelligence, with consequences for equity, privacy, safety, and users’ ability to choose and control their tools.
Viable open-source alternatives make transparency actionable. Being able to inspect software matters, but so does being able to run it without an expensive hardware purchase or a cloud dependency. Mozilla’s investment in llamafile fits that goal, alongside its invitation to support other people building open-source AI.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Portable executables and distributable GPU support
Justine Tunney’s implementation account begins with making the program run across systems at all. Cosmopolitan supplies the portability foundation. She describes a Unix Sixth Edition shell script placed inside the MS-DOS stub of a Portable Executable: a combination of executable conventions that lets the same packaged program work across six operating systems, including Windows, macOS, Linux, and BSD variants.
CPU portability does not remove the need for GPU support. Once the CPU distribution problem was addressed, GPUs introduced another packaging problem: Tunney describes projects shipping roughly 500 MB of cuBLAS binaries. Beyond the size, she objects to an ostensibly open-source application spending most of its execution time inside a proprietary library.
The response is tinyBLAS, a library intended to make GPU inference easier to distribute. In the Windows deployment described here, the user needs the GPU driver but not an installed GPU SDK. Removing that SDK requirement preserves the idea of a self-contained application while still allowing GPU acceleration. From there, the performance question becomes the operation that dominates much of the computation: matrix multiplication.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Unroll the outer loops
For faster prompt processing, Tunney focuses on how matrix multiplication is organized. Her central optimization is to unroll the outer loops. The distinction matters: simply expanding the innermost loop, as a broad compiler option such as -funroll-loops might encourage, is not the same transformation. In this setting, she argues, computers already handle the inner-loop opportunity well.
| Transformation | Intended effect |
|---|---|
| Unroll the inner loop | Repeat operations within the existing inner computation |
| Unroll the outer loops | Expose more matrix work together in a BLAS-like kernel |
The outer-loop transformation lets the computation concentrate on floating-point arithmetic instead of treating each piece of matrix work in isolation. Tunney describes this as capturing much of the benefit of BLAS for prompt processing, with improvements extending from Raspberry Pi hardware to larger machines. The lesson is about structuring the work to exploit the processor, not merely asking the compiler to unroll more loops.
In the token-generation discussion, Tunney reports a 4× improvement on Intel Alder Lake, without specifying the model or benchmark settings. She then highlights Threadripper and the opportunity to exploit AVX-512. Her comparison with GPU-like performance is qualitative, rather than a measured claim of CPU–GPU parity.
Prompt evaluation deserves attention separately from generation. A chatbot must produce output tokens, but a document task first has to process the input. For summarization, that input may be an entire essay or blog post. Faster prompt evaluation therefore makes the model more useful as a tool for reading and understanding existing text, even before considering how quickly it writes the answer.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Coordinate CPU work like CUDA
The next optimization comes from a programming model. Tunney credits NVIDIA’s success not only to hardware but also to a framework that helps developers organize parallel computation. CUDA’s __syncthreads() is her example: a synchronization point that lets cooperating threads coordinate their progress.
She brings that idea to CPUs with a small synchronization implementation, described as about ten lines, and a lockstep programming model. The aim is to organize CPU workers as cooperating participants in a parallel computation, much as one would organize GPU work. The slide pairs synchronization code with a “50% faster” callout, but does not establish benchmark conditions for treating that number as a general threading result.
The payoff is illustrated by a side-by-side summarization demonstration. Both versions process an essay by Dijkstra, with the new version on the right. As the demonstration progresses, the new version starts producing the summary while the old version remains far behind in processing the input. This is a visible change in time to useful output, not an isolated claim about how quickly the final text streams. The demonstration supplies no measured speed ratio.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Faster quantized models, larger memory budgets
Community work extends the improvements to quantized formats. Tunney credits the contributor associated with inventing K-quants with further optimization. She reports 2× and 4× improvements for quantized formats across x86 and ARM, without assigning either multiplier to a specific architecture or benchmark configuration. The contribution broadens the performance work beyond the earlier matrix and threading changes.
Community feedback also reveals a different benefit of CPU inference: making a large model runnable in the first place. Tunney recounts a user running Mixtral 8x22B on a $350 CPU. That is a processor-price anecdote, not a $350 complete-system configuration or a throughput measurement.
Her own workstation illustrates the memory tradeoff: Tunney describes installing 512 GB of RAM for a cost comparable to a graphics card. More affordable memory capacity gives her room to run larger models while accepting longer waits. Her motivation is access to more capable answers, rather than maximizing speed alone; neither greater model size nor more RAM guarantees a better answer to every task.
Making inference possible and making inference fast are different achievements. CPU memory capacity helps with the first; kernel, synchronization, and quantization improvements help with the second. Together, they create opportunities for individual contributors to change what people can run on their own machines.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Connect local models to private data
The remaining work is not confined to organizations with enormous compute budgets. Hood introduces Mozilla Builders as a way to sponsor, and sometimes co-develop, impactful open-source AI projects. llamafile was its first project; the next is Alex Garcia’s sqlite-vec, which adds vector search to SQLite.
That combination suggests an application beyond a standalone chatbot: a Raspberry Pi 5 running a local open model, connected to personal data through local retrieval, with no network connection. Vector search supplies a way to retrieve relevant data; the local model supplies the language interface. Hood presents this as a proposed private retrieval-augmented generation application, not an end-to-end deployment demonstrated onstage.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Support for the next local AI projects
At the time of the recording, the Mozilla Builders Accelerator offered selected open-source local-AI projects up to US$100,000 in non-dilutive funding. Its focus was AI running at the edge on user devices. The announcement slide names developer productivity, fine tuning, RAG, agents, function calling, evaluation, and generative UI as areas of interest, rather than an exclusive list.
Applicants did not need to be building a company. Hood closed by inviting people with projects or collaboration ideas to contact the speakers and Mozilla staff, with the Builders site serving as the program’s information route. The invitation follows directly from the technical work: portable packaging, better CPU kernels, and local vector search leave substantial room for small teams to expand what users can do privately on their own hardware.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
Source code and documentation for packaging and running language models as single-file executables.
A SQLite extension for adding vector search to applications.
The 2024 accelerator announcement explaining its local-AI focus, funding ceiling, and program structure.
Further reading
A contemporary overview of tinyBLAS, CPU optimization, model packaging, and local API support.
Read the complete timestamped transcript
- 0:00
[upbeat music] So we are here to talk to you about Llama File today and what we've been doing on this project.
- 0:22
So I'll get us started. I'm gonna tell you what Llama File is, how it works. I'm gonna spend a little time talking about why we're building it, why Mozilla specifically is involved, and then I'm gonna hand it over for the fun part to Justine.
- 0:34
Justine's gonna talk about the actual work that she and the open source community have been doing on this project. Lots of insights and tricks and hacks that have made CPU inference go faster than ever before, so that'll be fun.
- 0:48
When we're done, we want you to share the feeling that we have, which is kind of a sense of excitement and empowerment from the knowledge that there are lots of really interesting, juicy, impactful problems still left to be solved in AI, a lot of them.
- 1:02
And the key thing is, it's not just the big folks who can solve these problems. It's individuals and small groups working together in open source. So anyone in this room or anyone listening to this talk can potentially make a big impact in this space.
- 1:19
So what's Llama File? Llama File is an open source project from Mozilla that has the goal of democratizing access to AI. So we do that in a few different ways.
- 1:29
The first is probably how, if you've heard of Llama File, the reason you heard of it is the original magic trick of the project that Justine figured out, which is how to turn weights into programs.
- 1:40
So Llama File is a single file executable that runs without any installation on pretty much every operating system, every CPU architecture, and every GPU architecture.
- 1:54
And that's all. Thank you very much. [laughing] [laughs] That was easy.
- 2:00
Yeah, so by the way, this isn't just one file, like for Windows, right, and a different one for Linux and Mac. It's actually a single file. You can download a Llama File, run it on any computer in the world, and it'll just work, and it'll use the hardware you have, whether that be fancy GPUs or your CPU.
- 2:17
So she'll talk a little more later about how, uh, Justine made that work.
- 2:22
But we're here to talk about another topic too. Most of the talk's actually about this, which is CPU inference speed. Now you might ask, why do we need to worry about CPU inference speed?
- 2:31
We've got these fancy GPUs, right? Well, no disrespect,
- 2:37
almighty Jensen, first of his name, master of market cap. [laughing] Uh, don't strike me down. But I would posit that it is not a universally good thing that we are so dependent in this room on GPUs.
- 2:52
Uh, they are expensive. They're difficult to source. Let's face it, they consume a lot of electricity, which we might wanna think about. But, uh, bigger picture, we have an entire planet of CPUs out there, literally all over the world.
- 3:06
Great hardware, often affordable hardware, and we are at risk of just kind of throwing that all away with this new era of, of AI, and we don't need to do that.
- 3:15
So who here knows llama.cpp? This is an easy question. [laughs] Yeah, right. So ev-- we all know and love this project. We build on top of that project with Llama File, and we contribute our, uh, performance enhances back to it.
- 3:27
Many have been merged in. That project proved that CPUs could do inference perfectly well, and so we have been basically trying to take that performance to the next level.
- 3:37
And as a result of Justine and the community's work, depending on what CPU you're using, what model you're running, what weights, you will see between thirty and five hundred percent speed increases with Llama File, which- Whoo!
- 3:48
... kinda still blows my mind. And I, by the way, I don't think we're anywhere near done. [clapping]
- 3:57
So these things also run locally, by the way. This runs totally on your machine. There's no network access. You could take a pair of scissors and cut the ethernet cord, and it'll work, which is what I asked DALL-E 3 to draw. [laughing]
- 4:09
Okay. I don't think it understood the assignment, but that's all right.
- 4:14
Uh, but seriously, like we're not calling cloud LLMs. There's no monitoring or analytics. No bits leave your machine. It's totally private and local. And everything you need comes in the box.
- 4:25
So whether you wanna just play with a model that you just found on Hugging Face or you wanna start building local, locally running LLM applications on your machine, you got everything you need in the box.
- 4:36
And they're readily available. So, uh, Hugging Face now supports Llama File as a file type, so you can search and filter by Llama File. You could also just search Mozilla on Hugging Face.
- 4:47
You'll find we have a bunch of Llama Files that we've already published. And with a single command, you can create your own. So really, this project is collapsing all the complexity of the open source AI stack down into a single action and a single file.
- 5:02
So why are we involved? Why is Mozilla involved in this? You might be saying, "Don't you folks make browsers?" In fact, we do. We make a damn fine browser, and you should try it out if you haven't lately. [laughing]
- 5:17
But we exist also for a bigger purpose, which is to fight for the web. So I'm gonna ask you a question here. Who here remembers using the original Netscape Navigator?
- 5:26
Don't be shy. No one can see how old you are. [laughing] They can only see how old I am.
- 5:32
A lot of hands, right? So you are my people. You remember the nineties. My CTV,
- 5:40
terrible haircuts. [laughing] Nilly Vanilli, I don't know, whatever. My point is, you remember the early days of the web, and you remember how close we came to one company and one product kinda tr- controlling the whole thing.
- 5:56
And we kinda see that maybe happening again today with AI. No matter what we may think of these companies, the reality is there are some very influential big tech companies that are in a position to maybe control the future of machine intelligence.
- 6:10
And that's itself not a great thing. It's not great for equity. It's not great especially for users' sense of privacy and, uh, safety and agency and control.
- 6:23
And we've had an answer to this for many years. It's called open source. And the answer is right in the name, right? Open source. Transparency is the solution here, and it's important for us to have viable open source alternatives in AI.
- 6:36
And that's why Mozilla is getting involved. That's why we made llamafile and more projects to follow. And, uh, I know many of you in this room are already working on open source AI.
- 6:44
We wanna help support what you're doing. So with that, I'm gonna hand it over to Justine, who's gonna tell you actually the cool part, which is all the things that she and the community have been doing on this project.
- 6:53
Justine. [audience applauding]
- 7:01
Thank you, Steven. Um, so I'm Justine Tunney. I'm the lead developer on llamafile, and as Steven mentioned, I'm gonna talk about some of the cool work we've been doing in the community to help you run the fastest local LLM experience possible.
- 7:17
And in order to do this, we started by first getting it to run on the systems at all. And with Cosmopolitan, what it enables us to do is take your weights in a single file and run it on six OSs.
- 7:32
And there's a really cool hack that makes that possible, which is we basically take a Unix Sixth Edition shell script, put it in the MS-DOS stub of a portable executable, and that enables it to run on Mac, Windows, and BSDs and Linux, et cetera.
- 7:52
Really cool stuff. And once we conquered the portability issue with CPUs, um, I had the opportunity to work with Mozilla on bringing this to AI. And with AI, GPUs are indispensable.
- 8:06
As much as we focus on CPUs, we care very much about GPUs too. But GPUs have always had the problem of distributability. Many people have needed to ship CuBLAS binaries with their project, five hundred megs in size.
- 8:22
Can we really call our software open source if it spends the majority of its time in a proprietary blob? So I never felt comfortable with that, and one of the ways we're solving that is by distributing a library called tinyBLAS that enables you to ship your LLMs to platforms like Windows without depending on SDKs.
- 8:43
It'll run with only the driver installed. But more importantly, performance. Now, LLMs spend the majority of their time doing matrix multiplication. Probably the most important algorithm in the world.
- 9:00
Has a really simple definition. We've been making it go faster for prompt processing, and the way we did it is with a very simple trick we figured out, and this is something all programmers can adopt in their code, and it entails unrolling the outer loop.
- 9:20
So let's talk about what not to do first, and that would be unrolling the inner one. Um, we've all seen fun roll loops, Gen two. It's a bad idea.
- 9:29
Computers can generally do that on their own. If you unroll the outer loops, then your algorithm with matrix multiplication can sort of unfold like a flower and focus on pure flops like a BLAS kernel.
- 9:43
And that's really all there is to it to getting the majority of the benefits of BLAS to make prompt processing go really fast. So what's the impact to this really simple solution?
- 9:55
Um, this generalizes to a wide variety of hardware. We've seen everything from a scrappy hobbyist Raspberry Pi, um, to much bigger computers going significantly faster. You need algorithms like this to exploit the latest capabilities of hardware.
- 10:13
Token generation rates I wanna believe. If you use a gaming computer like Intel, you're going to see better performance with llamafile on those too. Really exciting stuff, like particularly with Alder Lake, we are able to get a four X improvement.
- 10:31
But Threadripper most of all, for the first time, AVX512 is available to consumers, and we've been able to help you prepare for that future. So if you have the Threadripper, you're gonna see better performance than ever, almost like a GPU.
- 10:47
Now, prompt eval speed, what makes it important is
- 10:53
it's really cool to be able to generate text and use a chatbot, but the way I want you to think about llamafile is it's more of a word-crunching machine that can help you understand our world.
- 11:05
And I love to use it personally for tasks like summarization. I love that it can help me read a blog post. And we've used other performance tricks too.
- 11:16
When... With NVIDIA, part of what makes them so successful, it's not just great hardware, but they built a great framework too. And their framework helps developers think about programming in a different way that helps them be successful.
- 11:33
I mean, who here thinks that software with CPUs just gets slower each year? Can I see a raise some hands? [laughs]
- 11:41
Well, part of the, um, one of the things that's great about NVIDIA is they showed us a better alternative to getting performance. And when I learned how to program in CUDA, I found one of the most important functions was syncThreads.
- 11:56
This is how you can implement it for CPU in, like, 10 lines of code. And if you use the lockstep programming model, use your CPU as though it were a GPU, you can get really good performance.
- 12:10
Now, this is gonna be a demo.
- 12:13
Showing the impact of this work before and after for summarization. And here we're gonna be processing an essay by Dijkstra, really cool, worth reading. But I want you to watch, like, as it processes it in terms of speed.
- 12:30
Here we see it going, and on the right we have the new version.
- 12:34
And it's like bam, bam, bam, bam. Huge night and day difference. It's already summarizing it, and the old version is, like, nowhere close.
- 12:45
So that is the kind of new performance you can expect, and it's the kind of performance that's actually possible, which I wouldn't have imagined beforehand. [cheering] It's really great. [clapping]
- 13:01
Thank you. CPUs can do so much. And people in the community have, like, loved this work. We've managed to attract some, like, really amazing contributors like Aiwyn, the inventor of KQuant.
- 13:12
It's very popular. I'm sure many of you have used them. He got them going 2X, 4X faster too on both x86 and ARM. So if you use quantized formats, those are gonna be better than ever with Llama File now too.
- 13:28
And it's worth mentioning that we've, um, seen really interesting things about this. Like, people, once we put this out into the world, people have come back and given us feedback and reported, like, their own experiences.
- 13:44
We found out that someone was running Mixtral 8x22B on a $350 CPU. And to me, that's just wonderful, um, because performance matters, but it's not really the thing we care about.
- 13:59
What we care about is intelligence. And to have the intelligence, you need to run bigger models, and RAM is cheap with CPUs. For the price of a graphics card, I put 512 gigs in my workstation, and that means I can run all the frontier models coming out, and I just have to wait a little longer, but I
- 14:19
get a much more intelligent answer. And the fact that that went from impossible to possible for most consumers is, um, you know, a story I want you all to tell.
- 14:33
Individuals are making a big difference, and you can be a part of that too. And I'm gonna hand it back to Steven, who can explain what Mozilla can do to support you getting involved in that effort. [clapping]
- 14:44
Thanks, Justine. Thanks a lot for all your efforts.
- 14:59
So yeah, that, that's a key message of this talk is, uh, anyone in this audience, you don't have to work for these big, giant, largest-in-the-history-of-humanity companies necessarily to have a big impact.
- 15:10
There's lots of headroom here. There's lots of unsolved, interesting problems in this space,
- 15:15
and we wanna get involved in helping. So we recently launched a program called Mozilla Builders, and this is a program by which we either sponsor or, in some cases, co-develop impactful open source AI projects.
- 15:29
Llama File was actually the first in this program. I'm happy to announce today the second, which is SQLite Vec. This is from a developer named Alex Garcia. Alex is adding vector search capability to SQLite.
- 15:41
And so for some folks in this audience, that'll have some obvious implications that are kinda cool. [clapping]
- 15:49
But just imagine, remember that little modest Raspberry Pi 5? So, like, imagine now a local LLM, open LLM, running privately on that machine with no network connection, connected to your personal private data, which you can use with confidence that it's safe to do RAG and other interesting applications.
- 16:08
That's the kind of stuff we're talking about here.
- 16:11
We also just launched our own accelerator. It's called the Mozilla Builders Accelerator. So we are offering 100,000 US in non-dilutive funding for open source projects that advance the promise and potential of local AI.
- 16:25
So that's AI applications running at the edge on user devices. These are some of the bullet points of areas we're particularly interested in, but it's not an exclusive list.
- 16:34
And you don't have to necessarily be building a company to apply for this accelerator.
- 16:39
So if you wanna learn more about the accelerator, this QR code will take you there. Take a picture of that, or just go to future.mozilla.org/builders. And, you know, uh, Justine and I, and a lot of Mozillians are here this week.
- 16:51
If you have something you're working on or something you think we should know about or you wanna collaborate with us, please find us, reach out, or reach out to me via email.
- 17:00
So thanks again. Thanks to Justine and the community on all their work on Llama File.
- 17:03
Thank you, Steven.
- 17:04
Thank you. [outro music]