Mistral Integration Improved in Llama.cpp(github.com) |
Mistral Integration Improved in Llama.cpp(github.com) |
A cpp binary depending on a python server is a bit sad.
I hope this is a stopgap measure and someone port it to C++ eventually:https://github.com/mistralai/mistral-common/blob/main/src/mi...
I hear the reason for this is that llama.cpp keeps breaking basic things, so they have become an unreliable partner. Seems this is what Ollama is trying to address by diluting their connections to llama.cpp and directly contacting companies training these models to have simultaneous releases (e.g. GPT-OSS).
They do release high quality inference code, ie https://github.com/mistralai/mistral-inference
Ollama brings value by exposing an API (literally over sockets) with many client SDKs. You don't even need the SDKs to use it effectively. If you're writing Node or PHP or Elixir or Clojurescript or whatever else you enjoy, you're probably covered.
It also means that you can swap models trivially, since you're essentially using the same API for each one. You never need to worry about dependency hell or the issues involved in hosting more than one model at a time.
As far as I know, Ollama is really the only solution that does this. Or at the very least, it's the most mature.
llama.cpp also got GPT-OSS early, like Ollama.
There's a lot of extremely subtle politics going on in the link.
Suffice it to say, as a commercial entity, there's a very clever way to put your thumb on the scale of what works and what doesn't without it being obvious to anyone involved, even the thumb.
Don't get me wrong, llama.cpp is an amazing tool. But it's development is nowhere near as cautious as something like the Linux kernel, so there is room there for a more stable alternative. Not saying Ollama will do this, but llama.cpp won't be everything to everyone.
But I also couldn't get vllm, or transformers serve, or ollama (400 response on /v1/chat/completions) working today with gpt-oss. OpenAI's cookbooks aren't really copy paste instructions. They probably tested on a single platform with preinstalled python packages which they forgot to mention :))
I'm not sure comparing to Linux kernel sheds light: what is different? Just Ubuntu/Red Hat LTS type stuff? What does LTS mean in the context of not-support-contracts and not-operating systems?
Steelmaning, I could say we mean....named branches? I guess a branch isn't a necessary condition...named versions?...that get fixes backported, but no new features.
Software where that's a commonly used approach are at least ~3 OOMs larger (i.e. are much more separable in terms of bug fixes vs. features and components) and hard to upgrade, i.e. it's hard for IT to force all N changes on end users since the last time they upgraded Linux machines, just to get a 0 day fix.
Here, it's a FOSS software library that needs to be part of an app to be useful, the consumers of the library are the ones would want to offer LTS.
I'm all ears if you dig up more info on a rollback or similar nasty scandal, but as it stands, I've been involved with it near-daily for 2 years now, including CI tests on every platform you can think of, and I've never, ever, heard of such a thing.
A guiding light here may be that Ollama inference is 99% llama.cpp or its consituents. From there, we notice a contradiction: if thats the case, how can we claim Ollama fulfills these ideas but llama.cpp doesn't? We could wave it away as they have a miraculous nose for what parts of llama.cpp won't fall victim to the issues we're worried about, but...well, here's one of my favorite quotes: "When faced with a contradiction, first, check your premises"
Ollama is llama.cpp with a nice little installer GUI and nice little server binary.
llama.cpp has a server binary as well, however, no nice installer GUI.
The only time recently Ollama had a feature llama.cpp didn't was they patched SWA in with Google, llama.cpp had it a couple weeks later.
Ollama is significantly behind llama.cpp in important areas, ex. the Gemma blog post, they note they'll get on tool calls and multimodal real soon now.
> Ollama is significantly behind llama.cpp in important areas, ex. the Gemma blog post, they note they'll get on tool calls and multimodal real soon now.
If you don't use those things, you don't need to care. I'll just use another model that works.
And that's the thing really. Most folks don't give a shit about getting the maximum performance. They're probably not even keeping their GPU busy all the time. They just need it to work consistently without having to worry about nonsense. Llama.cpp simply isn't that tool.