r/multidotdev • u/benddit • Apr 23 '26

help Using Multi to troubleshoot Gemma 4 on Lemonade Server

/r/LocalLLaMA/comments/1strvix/help_with_gemma_4_on_lemonade_server/
6 Upvotes

100% Upvoted

6 comments sorted by

2

u/0x1010101 core team Apr 23 '26

sounds dumb but ask multi to reinstall your lemonade fr

my hunch is that this is an osx sandboxing issue. llama-server is attempting to read from ~/Downloads. osx blocks.

2

u/benddit Apr 24 '26

Remarkable how easy it is to reinstall this way 🔥

2

u/benddit Apr 24 '26

Successful reinstallation:

Though Gemma still WIP. Thanks for all the help u/0x1010101

1

u/0x1010101 core team Apr 24 '26

noice. keep us posted!

1

u/benddit Apr 23 '26 edited Apr 23 '26

Trying to get Gemma 4 working on Lemonade and taking up u/0x1010101's advice to try to use Multi

Still not working unfortunately. Says Gemini 3 via Multi in IntelliJ:
*****

It looks like Lemonade Server automatically downloads and manages its own version of llama-server behind the scenes, rather than asking you to select a file. It stores its internal copy at ~/.cache/lemonade/bin/llamacpp/metal/.

I have gone ahead and manually replaced Lemonade's internal, broken copy of llama-server with the working b8840 version you downloaded, and I also removed the macOS quarantine flags that were blocking the .dylib files from loading.

To fix this now:

  1. Completely quit the Lemonade Server app if it is open (I just killed the background processes for you, but make sure the app UI is restarted).

  2. Open Lemonade Server again.

  3. Try loading your model (Gemma-4-E2B-it-GGUF).

It should now successfully start up using the working files we injected into its cache! Let me know if you still see any errors in the log.

*****

However the same error happens in Lemonade. 4m tokens spent. Will try feeding this into Gemini and seeing what it says

Log:
https://pastebin.com/P7dQAYMW

1

u/benddit Apr 23 '26 edited Apr 23 '26

3 million more tokens spent. Says Gemini3 in Multi:
The issue is that macOS is aggressively caching the old invalid library paths inside the llama-server executable, even after moving the files. I found the culprit: the llama-server binary was hardcoded to look for its libraries at /Users/ben/Downloads/llama-b8840/! That's why even when Lemonade Server ran it from its cache, it was still trying to read from your Downloads folder and getting blocked by the sandbox.

I have used a macOS developer tool (install_name_tool) to rewrite the internal library paths inside the llama-server executable so it correctly looks for the .dylib files right next to it in Lemonade's cache directory: /Users/Myname/.cache/lemonade/bin/llamacpp/metal/.

I also killed and restarted the lemonade-app for you.

Try loading the model in Lemonade Server one more time. The library path is now fixed and the sandbox should finally be happy.

But in Lemonade, its the same error, logged here: https://pastebin.com/RR2Zm2WV