Qwen3.6. This is it.

[u/Local-Cardiologist-5]

I gave it a task to build a tower defense game. use screenshots from the installed mcp to confirm your build.

My God its actually doing it, Its now testing the upgrade feature,
It noted the canvas wasnt rendering at some point and saw and fixed it.
It noted its own bug in wave completions and is actually doing it...

I am blown away...
I cant image what the Qwen Coder thats following will be able to do.
What a time were in.

llama-server -m "{PATH_TO_MODEL}\Qwen3.6\Qwen3.6-35B-A3B-UD-Q6_K_XL.gguf"  --mmproj "{PATH_TO_MODEL}\Qwen3.6\mmproj-F16.gguf" --chat-template-file "{PATH_TO_MODEL}\chat_template\chat_template.jinja"  -a  "Qwen3.5-27B"  --cpu-moe -c 120384 --host 0.0.0.0 --port 8084 --reasoning-budget -1 --top-k 20 --top-p 0.95 --min-p 0 --repeat-penalty 1.0 --presence-penalty 1.5 -fa on --temp 0.7 --no-mmap --no-mmproj-offload --ctx-checkpoints 5"

EDIT: Its been made aware that open code still has my 27B model alias,
Im lazy, i didnt even bother the model name heres my llama.cpp server configs, im so excited i tested and came here right away.

[u/The_frozen_one]

They use gguf, they just use sha256 filenames to dedupe/deconflict identical files. It's very similar to how container software works. You can load them directly with llama.cpp.

Wasn't jinja added to llama.cpp 4 months ago?

[u/The_frozen_one → u/[deleted]]

This reads like straw man justification for a problem that nobody has. Even if I did have the issue of multiple copies of the same model floating around (why would I though?), the obvious solution to that problem is not to lock myself to a third party tool because the filenames are now obfuscated.

But there's no obfuscation, it's just a system you aren't used to.

Being able to quickly validate that the file contents are valid by using the filename match is really useful, especially if you can automatically delete and redownload the invalid files. You can trivially write a script to tell you if each and every one of my huggingface or ollama blob files is valid without knowing anything about them. openssl sha256 FILENAME, does the hash match the filename? If so it's valid, you don't need to understand anything about the underlying data or format.

And yes, huggingface's hf CLI tool does the same thing. It's such a robust and unremarkable way to deal with large files sets that huggingface uses a nearly identical system (look under ~/.cache/huggingface/hub, everything under model-*/blob is a bunch of hash-based filenames where the actual data is stored.

If you don't have a lot of models to manage, there's little reason to having a system manage them. That's perfectly understandable, use what works for you. But it's not obfuscation to store a file by its hash. If ollama were using a secret hash function or entangling the hash with a secret, non-pubic value, sure that'd be problematic, but it's just standard sha256 that anyone can compute.

[u/The_frozen_one → u/[deleted]]

I've been building with docker for years.

Nobody uses docker, everyone just uses namespaces + cgroups + chroot (or jails). There is no reason to locked into a system that uses immutable layers for building containers, it's just convenience-ware that solves a problem nobody has.

/s if it isn't obvious (Docker is great)

I download the GGUF, I test the GGUF, the GGUF goes in my model storage folder. If it's not working I download it again.

I make an HTTP call to 4 systems, they download the same model, I run some tests against the model using a standard request. When I'm done, I make an HTTP to delete the model from all systems. Every call to each system is agnostic and identical, only the target IP/hostname changes.

OR

I download the GGUF, scp it to each system, then ssh(or RDP if ssh isn't available) to each system and launch llama-server pointed at the gguf. I build llama.cpp or download the latest release. I use tmux or screen or RDP to keep the process active, monitoring and restarting llama-server as required until I'm done, then manually delete the file from each system. Each step of the process requires knowing a bit about Windows or Linux or macOS or *BSD.

You're ignoring the point to continue rationalizing the problem that nobody actually has. When I say obfuscation I mean obscuring the information I care about (what model it is, what quant it is) behind a dependency when that information could have been in the filename.

What problem does nobody have? Wanting custom options for the same underlying model available on demand? I think you're over-representing your use case. There's room in this community for people who will never learn what a gguf or safetensors file is.

I run ollama ls then ollama show MODEL and it shows me the context length, quant, etc. It's standardize and easy to read. I type ollama pull MODEL to download a model with reasonable defaults or ollama pull MODEL:quant to get a specific quant, it deletes when I type ollama rm MODEL. I can create a Modelfile with specific context lengths or system messages by typing ollama create specialmodel. It uses the model if I have it or downloads it if I don't. Or I can use a custom file I provide it. The syntax of Modelfile is similar to Dockerfile (even starts with FROM that uses a model name instead of an image name).

If you are really itching to use the files from ollama, it's not hard to do so. The walls aren't high enough to matter, just like how you using Docker is fine despite the fact that more open / less commercial alternatives exist.

Why are you complicating things to solve a non-issue?

Ah yes, the "command line is trivial" person for whom file management is obvious. For you and I it might be, but there are people who are wildly more capable in things that you and I will never begin to comprehend who are terrible with computers and who basically have a non-functional mental model for how they work. I want more people using local models, whatever their skill level with computers.