I tested briefly with a MacBook Pro m4 with 36gb. Run in LM Studio with open code as the frontend and it failed over and over on tool calls. Switched back to qwen. Anyone else on similar setup have better luck?
April 2026 TLDR Setup for Ollama and Gemma 4 26B on a Mac mini
31–40 of 132 posts
Re: April 2026 TLDR Setup for Ollama and Gemma 4 26B on a Mac mini
#32[dead]
Re: April 2026 TLDR Setup for Ollama and Gemma 4 26B on a Mac mini
#33Earlier quoted context omitted.
Does LM Studio have an equivalent to the ollama launch command? i.e. `ollama launch claude --model qwen3.5:35b-a3b-coding-nvfp4`
I don't think it does, but llama.cpp does, and can load models off HuggingFace directly (so, not limited to ollama's unofficial model mirror like ollama is). There is no reason to ever use ollama.
sure there's a reason...it works fine thats the reason
Re: April 2026 TLDR Setup for Ollama and Gemma 4 26B on a Mac mini
#34[flagged]
By desk you mean that "Mac mini"? Because it is pricey. In my country it is 1000 USD (from Apple for basic M4 with 24GB). My desk was 1/5th of that price. And considering that this Mac mini won't be doing anything else is there a reason why not just buy subscription from Claude, OpenAI, Google, etc.? Are those open models more performant compared to Sonnet 4.5/4.6? Or have at least bigger context?
I have the same setup (M4 Pro, 24GB). The e4b model is surprisingly snappy for quick tasks. The full 26B is usable but not great — loading time alone is enough to break your flow.
Re: subscriptions vs local — I use both. Cloud for the heavy stuff, local for when I'm iterating fast and don't want to deal with rate limits or network hiccups.
Re: April 2026 TLDR Setup for Ollama and Gemma 4 26B on a Mac mini
#35Earlier quoted context omitted.
> There is virtually no reason to use Ollama over LM Studio or the myriad of other alternatives. Hmm, the fact that Ollama is open-source, can run in Docker, etc.?
Ollama is quasi-open source. In some places in the source code they claim sole ownership of the code, when it is highly derivative of that in llama.cpp (having started its life as a llama.cpp frontend). They keep it the same license, however, MIT. There is no reason to use Ollama as an alternative to llama.cpp, just use the real thing instead.
If it’s MIT code derived from MIT code, in what way is its openness ”quasi”? Issues of attribution and crediting diminish the karma of the derived project, but I don’t see how it diminishes the level of openness.
Re: April 2026 TLDR Setup for Ollama and Gemma 4 26B on a Mac mini
#36Earlier quoted context omitted.
LM Studio has been around longer. I’ve used it since three years ago. I’d also agree it is generally a better beginner choice then and now. Unsloth Studio is more featureful (well integrated tool calling, web search, and code execution being headline features), and comes from the people consistently making some of the best GGUF quants of all popular models. It also is well documented, easy to setup, and also has good…
LM Studio isn't free/libre/open source software, which misses the point of using open weights and open source LLMs in the first place.
Disagree, there are a lot of reasons to use open source local LLMs that aren't related to free/libre/oss principles. Privacy being a major one.
Re: April 2026 TLDR Setup for Ollama and Gemma 4 26B on a Mac mini
#37There is virtually no reason to use Ollama over LM Studio or the myriad of other alternatives. Ollama is slower and they started out as a shameless llama.cpp ripoff without giving credit and now they “ported” it to Go which means they’re just vibe code translating llama.cpp, bugs included.
>Ollama is slower
I've benchmarked this on an actual Mac Mini M4 with 24 GB of RAM, and averaged 24.4 t/s on Ollama and 19.45 t/s on LM Studio for the same ~10 GB model (gemma4:e4b), a difference which was repeated across three runs and with both models warmed up beforehand. Unless there is an error in my methodology, which is easy to repeat[1], it means Ollama is a full 25% faster. That's an enormous difference. Try it for yourself before making such claims.
[1] script at: https://pastebin.com/EwcRqLUm but it warms up both and keeps them in memory, so you'll want to close almost all other applications first. Install both ollama and LM Studio and download the models, change the path to where you installed the model. Interestingly I had to go through 3 different AI's to write this script: ChatGPT (on which I'm a Pro subscriber) thought about doing so then returned nothing (shenanigans since I was benchmarking a competitor?), I had run out of my weekly session limit on Pro Max 20x credits on Claude (wonder why I need a local coding agent!) and then Google rose to the challenge and wrote the benchmark for me. I didn't try writing a benchmark like this locally, I'll try that next and report back.
Re: April 2026 TLDR Setup for Ollama and Gemma 4 26B on a Mac mini
#38Earlier quoted context omitted.
I don't think it does, but llama.cpp does, and can load models off HuggingFace directly (so, not limited to ollama's unofficial model mirror like ollama is). There is no reason to ever use ollama.
> I don't think it does, but llama.cpp does I just checked their docs and can't see anything like it. Did you mistake the command to just download and load the model?
-hf ModelName:Q4_K_M
Re: April 2026 TLDR Setup for Ollama and Gemma 4 26B on a Mac mini
#39There is virtually no reason to use Ollama over LM Studio or the myriad of other alternatives. Ollama is slower and they started out as a shameless llama.cpp ripoff without giving credit and now they “ported” it to Go which means they’re just vibe code translating llama.cpp, bugs included.
>Ollama is slower I've benchmarked this on an actual Mac Mini M4 with 24 GB of RAM, and averaged 24.4 t/s on Ollama and 19.45 t/s on LM Studio for the same ~10 GB model (gemma4:e4b), a difference which was repeated across three runs and with both models warmed up beforehand. Unless there is an error in my methodology, which is easy to repeat[1], it means Ollama is a full 25% faster. That's an enormous difference. Try…
It depends on the hardware, backend and options. I've recently tried running some local AIs (Qwen3.5 9B for the numbers here) on an older AMD 8GB VRAM GPU (so vulkan) and found that:
llama.cpp is about 10% faster than LM studio with the same options.
LM studio is 3x faster than ollama with the same options (~13t/s vs ~38t/s), but messes up tool calls.
Ollama ended up slowest on the 9B, Queen3.5 35B and some random other 8B model.
Note that this isn't some rigorous study or performance benchmarking. I just found ollama unnaceptably slow and wanted to try out the other options.
Re: April 2026 TLDR Setup for Ollama and Gemma 4 26B on a Mac mini
#40I tested briefly with a MacBook Pro m4 with 36gb. Run in LM Studio with open code as the frontend and it failed over and over on tool calls. Switched back to qwen. Anyone else on similar setup have better luck?
I failed to run in LM Studio on M5 with 32gb at even half max context. Literally locked up computer and had to reboot.
Ran gemma-4-26B-A4B-it-GGUF:Q4_K_M just fine with llama.cpp though. First time in a long time that I have been impressed by a local model. Both speed (~38t/s) and quality are very nice.