Running large language models (LLMs) on your local machine has become increasingly popular, offering privacy, offline access, and customization. Ollama is a ...
ollama is getting less and less open, and (IMO) should not be used. If that doesn’t concern you, you should be using LM Studio anyway.
The model sizes they mention are mostly for old models no-one should be using. The only exception is a 70B MoE (Hunyuan), but I think ollama doesn’t even support that?
The quantization methods they mention are (comparatively) primitive and low performance, not cutting edge.
It mentions q8_0 twice, nonsensically… Um, it makes me think this article is AI slop?
I’m glad opensuse is promoting local LLM usage, but please… not ollama, and be more specific.
And don’t use ollama to write it without checking :/
It also sets context length to 2k by default iirc, which breaks a lot of tasks, and gives a general bad first impression to users who are likely using local models for the first time.
Is there any background information available on ollama becoming less open? It’s marked MIT licensed in the repo of my Linux distribution and on their Github.
Signs in the code they are preparing a commercial version of Ollama, likely dumping the free version as a bait and switch.
Heavy online marketing.
“Reinventing"the wheel” to shut out competition, even when base llama.cpp already has it implemented, like with modelfiles and the ollama API.
A lot of inexplicable forked behavior.
Beyond that:
Misnaming models for hype reasons, like the tiny deepseek distils as “Deepseek”
Technical screw ups with the backend, chat templates and such hidden from users, so there’s no apparent reason why models are misbehaving.
Not actually contributing to the core development of the engine.
Social media scummery.
Treating the user as ‘dumb’ by hiding things like the default hard 2048-token context window.
Not keeping up with technical innovations, like newer quantizations, SWA, batching, other backend stuff.
Bad default quantizations, even beyond the above. For instance, no Google QATs (last I checked), no imatrix, no dynamic quants.
I could go on forever about more specific dramas, and I don’t even remember the half of them. But there are plenty of technical and moral reasons to stay away.
LM Studio is much better put together if you want 1-click. Truly open solutions that are more DIY (and reward you with dramatically better performance from the understanding/learning) are the way if you have the time/patience to burn.
Thanks. I’ll factor that in next time someone asks me for a recommendation. I personally have Kobold.CPP on my machine, that seems to be more transparent toward such things.
Kobold.cpp is fantastic. Sometimes there are more optimal ways to squeeze models into VRAM (depends on the model/hardware), but TBH I have no complaints.
It has support for more the advanced quantization schemes of ik_llama.cpp. Specifically, you can get really fast performance offloading MoEs, and you can also use much higher quality quantizations, with even ~3.2bpw being relatively low loss. You’d have to make the quants yourself, but it’s quite doable… just poorly documented, heh.
The other warning I’d have is that some of it’s default sampling presets are fdfunky, if only because they’re from the old days of Pygmalion 6B and Llama 1/2. Newer models like much, much lower temperature and rep penalty.
Thanks for the random suggestion! Installed it already. Sadly as a drop-in replacement it doesn’t provide any speedup on my old machine, it’s exactly the same number of tokens per second… Guess I have to learn about the ik_llama.cpp and pick a different quantization of my favourite model.
What model size/family? What GPU? What context length? There are many different backends with different strengths, but I can tell you the optimal way to run it and the quantization you should run with a bit more specificity, heh.
I hate to drone on about this again, but:
ollama is getting less and less open, and (IMO) should not be used. If that doesn’t concern you, you should be using LM Studio anyway.
The model sizes they mention are mostly for old models no-one should be using. The only exception is a 70B MoE (Hunyuan), but I think ollama doesn’t even support that?
The quantization methods they mention are (comparatively) primitive and low performance, not cutting edge.
It mentions q8_0 twice, nonsensically… Um, it makes me think this article is AI slop?
I’m glad opensuse is promoting local LLM usage, but please… not ollama, and be more specific.
And don’t use ollama to write it without checking :/
It also sets context length to 2k by default iirc, which breaks a lot of tasks, and gives a general bad first impression to users who are likely using local models for the first time.
Yes, and it’s hard to undo, and not obvious!
Is there any background information available on ollama becoming less open? It’s marked MIT licensed in the repo of my Linux distribution and on their Github.
It’s kinda a hundred little things all pointing in a bad direction:
https://old.reddit.com/r/LocalLLaMA/comments/1kg20mu/so_why_are_we_shing_on_ollama_again/
https://old.reddit.com/r/LocalLLaMA/comments/1ko1iob/ollama_violating_llamacpp_license_for_over_a_year/
https://old.reddit.com/r/LocalLLaMA/comments/1i8ifxd/ollama_is_confusing_people_by_pretending_that_the/
I would summarize it as “AI Bro” like behavior:
Signs in the code they are preparing a commercial version of Ollama, likely dumping the free version as a bait and switch.
Heavy online marketing.
“Reinventing"the wheel” to shut out competition, even when base llama.cpp already has it implemented, like with modelfiles and the ollama API.
A lot of inexplicable forked behavior.
Beyond that:
Misnaming models for hype reasons, like the tiny deepseek distils as “Deepseek”
Technical screw ups with the backend, chat templates and such hidden from users, so there’s no apparent reason why models are misbehaving.
Not actually contributing to the core development of the engine.
Social media scummery.
Treating the user as ‘dumb’ by hiding things like the default hard 2048-token context window.
Not keeping up with technical innovations, like newer quantizations, SWA, batching, other backend stuff.
Bad default quantizations, even beyond the above. For instance, no Google QATs (last I checked), no imatrix, no dynamic quants.
I could go on forever about more specific dramas, and I don’t even remember the half of them. But there are plenty of technical and moral reasons to stay away.
LM Studio is much better put together if you want 1-click. Truly open solutions that are more DIY (and reward you with dramatically better performance from the understanding/learning) are the way if you have the time/patience to burn.
Thanks. I’ll factor that in next time someone asks me for a recommendation. I personally have Kobold.CPP on my machine, that seems to be more transparent toward such things.
Kobold.cpp is fantastic. Sometimes there are more optimal ways to squeeze models into VRAM (depends on the model/hardware), but TBH I have no complaints.
I would recommend croco.cpp, a drop-in fork: https://github.com/Nexesenex/croco.cpp
It has support for more the advanced quantization schemes of ik_llama.cpp. Specifically, you can get really fast performance offloading MoEs, and you can also use much higher quality quantizations, with even ~3.2bpw being relatively low loss. You’d have to make the quants yourself, but it’s quite doable… just poorly documented, heh.
The other warning I’d have is that some of it’s default sampling presets are fdfunky, if only because they’re from the old days of Pygmalion 6B and Llama 1/2. Newer models like much, much lower temperature and rep penalty.
Thanks for the random suggestion! Installed it already. Sadly as a drop-in replacement it doesn’t provide any speedup on my old machine, it’s exactly the same number of tokens per second… Guess I have to learn about the ik_llama.cpp and pick a different quantization of my favourite model.
What model size/family? What GPU? What context length? There are many different backends with different strengths, but I can tell you the optimal way to run it and the quantization you should run with a bit more specificity, heh.