What is really impressive about this project and llama.cpp as well is that they keep finding new ways to speed up the code on the same hardware. Every time I upgrade (once a month or so) there is usually a 5 to 10% speed boost.
edit: Just to verify: I had planned to upgrade today, ran my usual benchmark prior and after and the runtime went from 4:22 to 3:59. That's a really long prompt (50K tokens) so prefill is a good chunk of that and the rest is spent on token generation.
Totally, I’ve been fiddling with local models on my machine (16GB AMD GPU + 64GB DDR4) for a few years and it’s remarkable the pace of improvement in what I can run. It has gone from complete novelty/useless to legitimately capable models running fast enough and with a big enough context to be useful running in a coding harness on a real codebase. A lot of that is down to the models themselves and the people making quants, but it feels like every time I pull llama.cpp changes and rebuild I get more performance and capability.
While I think that llama.cpp is an outstanding project - a one-stop-shop to get almost any model to run on almost any hardware, you get a lot more speed from specialised inference engines with kernels made for your hardware.
But if you don't have time to evaluate other engines and you simply want a rock solid inference engine, then llama.cpp is one of the best ones to go to.
> you get a lot more speed from specialised inference engines with kernels made for your hardware.
Of course you will. But that's not the point. The point is that Llama runs just about every model on just about every hardware. You can always improve on any metric by dropping that constraint. But there are a lot of such metrics:
- ease of use
- range of hardware
- accuracy of results
- range of models
Probably others. Llama.cpp may not be best at any one of those. But across all of them it has been consistently good. They've shown they're willing to stay the course as well. This is a foundation level project much like Linux or Apache.
I run vllm and llama.cpp; llama.cpp is pretty hackable by a local agent and is fast to start up, while vllm takes and age to build its optimized cuda graph.
The result is I run my big model (glm 5.3 flash) on llama.cpp and my small utility model (Qwen3 vl 8b) on vllm. Qwen often has better vision than glm (despite the tiny size) and can respond to tool calls from glm and importantly it doesn't use gobs of prefill+kv and is super fast.
Long time llama.cpp user (and user of other ggml based AI programs) running on my crappy AMD card that only supports vulkan and it's usable thanks to GGML and llama.cpp, great program great project.
If you load an MoE model that slightly exceeds your GPU memory budget, llama.cpp and ggml v1.0.0 can cache less-frequently used experts in host memory rather than failing to load.
"""
Description
The main goal of ggml is to be a simple, portable, and efficient tensor library for machine learning with minimal setup.
Plain C/C++ implementation without any dependencies
Cross-platform - x86, ARM, RISC-V, LoongArch, PowerPC, s390x, and WebAssembly
SIMD-optimized kernels for x86, ARM, and RISC-V
Broad backend support - CPU, GPU, NPU, and browser
2- to 8-bit integer quantization, plus MXFP4 and NVFP4 microscaling formats
Zero memory allocations during runtime
"""
There's ample precedent for this. When you're building something to scratch an itch, the name is secondary. You cast about for one. Ah, you have a name. That'll do.
For example, DJ Delorie's djgpp project, built in 1989, was how I got into "real" programming on MS DOS.
Fun story time. I started programming on Turbo Pascal. I had read some C code from those demo scene guides, so felt I understood it fairly well by the time I got my hands on a copy of djgpp. I decided to port a relatively simple program I had written in Turbo Pascal, about 300 LOC, line-by-line. It was a small demo just doing a simple rotating, texture-mapped triangle.
I carefully converted it, and went over it several time one line at a time, fixing it until I had read over it three times and was happy.
I then ran the djgpp compiler...
Now, what I hadn't realized at the time was the difference between C and C++. The examples I had seen was C, and I didn't really know what C++ was.
The compiler churned on my code and spit out about 3500 errors and warnings (it counted for me).
I was shocked. How did my 300 line C program manage to produce over 10 errors and warnings per line, on average?!
I spent a long time trying to figure this one out. The first error was inside the first function, and the error made no sense to me.
After several days of carefully going over each line and banging my head against the table, I suddenly saw it. There, at the very start of the program, before the line the first error or warning pointed to.
In Turbo Pascal I had used const to define things like screen width and height. So I'd have
I removed the two semi-colons and the program compiled and ran just fine...
I ended up staying in Turbo Pascal, I preferred a compiler that gave me sensible errors and quickly. I did pick up C++ much later, and I guess ironically came to appreciate its const correctness.
Historically, Linus didn't name linux. Other people did it for him.
> During the start of his work on the system, he stored the files under the name "Freax" for about half of a year. Torvalds had already considered the name "Linux", but initially dismissed it as too egotistical.
What is really impressive about this project and llama.cpp as well is that they keep finding new ways to speed up the code on the same hardware. Every time I upgrade (once a month or so) there is usually a 5 to 10% speed boost.
edit: Just to verify: I had planned to upgrade today, ran my usual benchmark prior and after and the runtime went from 4:22 to 3:59. That's a really long prompt (50K tokens) so prefill is a good chunk of that and the rest is spent on token generation.
Totally, I’ve been fiddling with local models on my machine (16GB AMD GPU + 64GB DDR4) for a few years and it’s remarkable the pace of improvement in what I can run. It has gone from complete novelty/useless to legitimately capable models running fast enough and with a big enough context to be useful running in a coding harness on a real codebase. A lot of that is down to the models themselves and the people making quants, but it feels like every time I pull llama.cpp changes and rebuild I get more performance and capability.
While I think that llama.cpp is an outstanding project - a one-stop-shop to get almost any model to run on almost any hardware, you get a lot more speed from specialised inference engines with kernels made for your hardware.
But if you don't have time to evaluate other engines and you simply want a rock solid inference engine, then llama.cpp is one of the best ones to go to.
> you get a lot more speed from specialised inference engines with kernels made for your hardware.
Of course you will. But that's not the point. The point is that Llama runs just about every model on just about every hardware. You can always improve on any metric by dropping that constraint. But there are a lot of such metrics:
- ease of use
- range of hardware
- accuracy of results
- range of models
Probably others. Llama.cpp may not be best at any one of those. But across all of them it has been consistently good. They've shown they're willing to stay the course as well. This is a foundation level project much like Linux or Apache.
I run vllm and llama.cpp; llama.cpp is pretty hackable by a local agent and is fast to start up, while vllm takes and age to build its optimized cuda graph.
The result is I run my big model (glm 5.3 flash) on llama.cpp and my small utility model (Qwen3 vl 8b) on vllm. Qwen often has better vision than glm (despite the tiny size) and can respond to tool calls from glm and importantly it doesn't use gobs of prefill+kv and is super fast.
what happens if you swap the setup? i.e., what's the perf ( and UX) diff just from the inference engine?
For this project it's more about achieving the 'train once, run everywhere' paradigm that Java had.
What hardware are you running inference on?
I have an Intel Arc Pro B70. Serves me well! I use Qwen 3.8 27B
Running it with Vulkan or SYCL?
Awesome! ggml and llama.cpp are the Linux of the AI world. Driving local inference one bit at a time.
Wishing you unlimited power and may you never see a day of low battery. Respect and Love. Keep it up.
Long time llama.cpp user (and user of other ggml based AI programs) running on my crappy AMD card that only supports vulkan and it's usable thanks to GGML and llama.cpp, great program great project.
If you load an MoE model that slightly exceeds your GPU memory budget, llama.cpp and ggml v1.0.0 can cache less-frequently used experts in host memory rather than failing to load.
I prefer this entry point: https://github.com/ggml-org/ggml
but this post is pointing out that they've hit v1.0.0 (a major milestone) by linking to the v1.0.0 release notes
In my opinion, this is a genuine engineering product. LLM.cpp, the savior of our difficult times...
for context:
Not just legacy hardware, but also ready for the immediate future, with RISC-V support.
Congrats for 1.0.0.
Imagine naming a library after yourself.
> GGML is a C library for machine learning (ML) - the "GG" refers to the initials of its originator (Georgi Gerganov).
https://github.com/rustformers/llm/blob/main/crates/ggml/REA...
Every single .exe file begins with the two letters MZ because Mark Zbikowski needed a "magic number" to begin the PE format.
There's ample precedent for this. When you're building something to scratch an itch, the name is secondary. You cast about for one. Ah, you have a name. That'll do.
For example, DJ Delorie's djgpp project, built in 1989, was how I got into "real" programming on MS DOS.
> DJ Delorie's djgpp project
Fun story time. I started programming on Turbo Pascal. I had read some C code from those demo scene guides, so felt I understood it fairly well by the time I got my hands on a copy of djgpp. I decided to port a relatively simple program I had written in Turbo Pascal, about 300 LOC, line-by-line. It was a small demo just doing a simple rotating, texture-mapped triangle.
I carefully converted it, and went over it several time one line at a time, fixing it until I had read over it three times and was happy.
I then ran the djgpp compiler...
Now, what I hadn't realized at the time was the difference between C and C++. The examples I had seen was C, and I didn't really know what C++ was.
The compiler churned on my code and spit out about 3500 errors and warnings (it counted for me).
I was shocked. How did my 300 line C program manage to produce over 10 errors and warnings per line, on average?!
I spent a long time trying to figure this one out. The first error was inside the first function, and the error made no sense to me.
After several days of carefully going over each line and banging my head against the table, I suddenly saw it. There, at the very start of the program, before the line the first error or warning pointed to.
In Turbo Pascal I had used const to define things like screen width and height. So I'd have
Well, C doesn't have const, but I had picked up it had #define. However, my Turbo Pascal habits had kicked in, and so I had written I removed the two semi-colons and the program compiled and ran just fine...I ended up staying in Turbo Pascal, I preferred a compiler that gave me sensible errors and quickly. I did pick up C++ much later, and I guess ironically came to appreciate its const correctness.
Also dlmalloc, phkmalloc, jemalloc for a few more examples
For example, Debian. AWK. PKZIP. ARJ. Korn shell. Bourne shell. jemalloc, dlmalloc. djbdns.
I don't have to imagine.
"Linux".
Hey, it worked for Carnegie!
This is the winning response.
And we can only hope that our modern robber barons will use their ill-gotten gains to create something as beneficial as Carnegie libraries.
I'm biased (see: pianojacq.com)
Imagine trying to name a file format for yourself even if it wasn't yours to begin with...
Par for course for being Linux of AI
Historically, Linus didn't name linux. Other people did it for him.
> During the start of his work on the system, he stored the files under the name "Freax" for about half of a year. Torvalds had already considered the name "Linux", but initially dismissed it as too egotistical.
https://en.wikipedia.org/wiki/History_of_Linux#Naming
He did name Git, tho
Conjecture: He named git after himself.
They wrote a large portion (and all of the initial version I think), they can name it whatever tf they want.
What do you think Linux is named after?
Answered in another thread
jealous?