Try to leave Ollama and you hit a one-way door. Importing a GGUF into Ollama is a one-line Modelfile. Getting one out has no command at all - ollama export doesn't exist, and the GitHub issue requesting it, open since August 2023 with years of +1s, was closed "not planned" in April 2026.
The good news is that the door is only locked from the inside by naming, not by format. Every model Ollama downloaded to your Mac is sitting in ~/.ollama/models/blobs/ as standard GGUF bytes under a sha256 filename. You can recover every gigabyte of it. Here's how, and here's what won't come along.
Where does Ollama store models on a Mac?
Ollama stores model weights at ~/.ollama/models/blobs/ as content-addressed files named sha256-<digest>, resolved through manifest files under ~/.ollama/models/manifests/. The weights themselves are standard GGUF - only the naming and the manifest layer are Ollama-specific.
Each model in your library is really a manifest pointing at several blobs: one multi-gigabyte blob for the weights, plus small ones for the license, chat template, and parameters. The weights blob is the one you want, and there are two ways to find it.
How do you export a model from Ollama?
Run ollama show <model> --modelfile and read the FROM line - it prints the absolute path of the weights blob. Copy that file to a name ending in .gguf, and any llama.cpp-compatible runtime can load it directly. In our testing, a copied blob loaded and generated identically to the original download.
We didn't take that on faith. While benchmarking Ollama against upstream llama-server, we pointed llama-server directly at Ollama's blob files - the literal sha256-named paths - and they loaded and served tokens like any other GGUF, because they are GGUF. The walkthrough below is the same move with a friendlier filename.
The migration, step by step
The steps below move one model. Repeat for whatever's worth keeping, then reclaim the disk space at the end. If you'd rather skip the archaeology entirely, the section after this one is for you.
What doesn't transfer?
Honesty section. Three things stay behind:
Modelfile customizations. If you built custom models with ollama create - a system prompt, a temperature, a num_ctx - those live in Ollama's manifest layers, not in the GGUF. You'll re-apply them in whatever tool you land on. The chat template usually does travel, because upstream GGUF files embed their template in metadata.
The registry names. llama3.2:latest is an Ollama-ism. Your exported file is just a file, which is rather the point.
Symlink setups. Don't be tempted to symlink into the blob store instead of copying - ollama rm and Ollama's pruning delete blobs underneath your links. The community tools that linked blobs into other apps fought this for years, and the maintained one, gollama, dropped its linking feature as more trouble than it was worth. Copy, then delete the original.
The alternative: re-download as plain GGUF and skip the surgery
If your models are standard library pulls (and for most people they are), re-downloading is honestly less work than blob extraction. ToolPiper pulls models from Hugging Face as plain, named GGUF files into a folder you can see - ~/Library/Application Support/ToolPiper/models/ - with RAM-aware suggestions so you don't grab something your Mac can't hold. The downloads run in the background. There's no manifest to decode because nothing was ever hidden.
That's the storage model this whole guide exists to work around, applied from day one: your models are ordinary files with ordinary names, and leaving ToolPiper someday would need no guide at all.
The runner around those files is free - the native llama.cpp engine (upstream build b10485, stated publicly), unlimited downloads, multi-model switching, the local OpenAI-compatible API, embeddings, and an MCP server with over 420 tools. No account, no caps, no terminal. You are not moving to a frontend that still needs Ollama underneath. ToolPiper bundles the engine, so once your models are in its folder there is no second process to keep running: unlimited GGUF downloads, multi-model switching, the local OpenAI-compatible API, embeddings, speech, and an MCP server with over 420 tools, free and with no account. It also answers the Ollama API itself on :11434, so the tools you already pointed at Ollama keep working against ToolPiper without being reconfigured.
Cleaning up, and the order that matters
Verify before you delete anything. Load every exported file in whatever tool you are moving to and generate at least one token from each. An export that silently produced a truncated or wrong-sized file looks identical to a good one until something reads it, and the originals are the only copy you have until you have checked. Only then: ollama rm each model, and quit the menu bar app.
⚠️ Do not rm -rf ~/.ollama as a first move. That directory holds more than blobs. ~/.ollama/id_ed25519 is the keypair identifying you to Ollama's registry, and if you have ever pushed a model it is not something you can simply regenerate. server.json holds preferences you set deliberately. If you want the disk space back, delete ~/.ollama/models/, which is the part that is actually large, and leave the rest until you are certain you are not going back. The blobs directory is usually the largest AI-related folder on a Mac that's run Ollama for a while - ours was holding about 9GB for three models. Your exported GGUF files are now visible, named, and portable to any tool that speaks the format, which is every local inference tool that matters.
Download ToolPiper at modelpiper.com/download - a starter model downloads automatically, and your exported files drop straight into its models folder.
Part of our Ollama series. For the full head-to-head before you switch, see Ollama vs ToolPiper. For what the two engines do with identical files, see our same-bytes benchmark.