LMStudioとOllamaでggufモデルを相互利用する！This article explains how to share and reuse GGUF model files between LM Studio…

Running large language models locally has become increasingly practical, and two of the most popular desktop tools for the job are LM Studio and Ollama. Both can execute models in the GGUF format, yet each maintains its own storage layout, which often leads users to download the same multi-gigabyte model twice. Sharing a single GGUF file between the two applications saves disk space and bandwidth, and it is a useful skill for anyone building a local AI workflow around more than one tool.

GGUF, which stands for GPT-Generated Unified Format, is the file format introduced by the llama.cpp project as the successor to the older GGML format. It packages model weights along with metadata such as tokenizer information, architecture parameters, and quantization details into a single file. Because both LM Studio and Ollama rely on llama.cpp under the hood, they can in principle consume the same GGUF file. The obstacle is not compatibility of the format itself but the differing conventions each tool uses to catalog and locate its models.

LM Studio takes a relatively transparent approach. It stores downloaded models as ordinary GGUF files inside a models directory, typically organized in a publisher and repository folder hierarchy that mirrors how models are published on Hugging Face. Because the files sit on disk as plain GGUF, they are easy to find, copy, or point other software at. LM Studio also lets users configure the location of this directory, which makes it straightforward to place models where another tool can reach them.

Ollama works differently. Rather than keeping a single named GGUF file, it uses a content-addressed blob store, usually located under a hidden .ollama directory in the user's home folder. Model layers are saved as blobs named by their SHA-256 hash, and separate manifest files describe how those blobs combine into a named model. This design is efficient for deduplication and versioning, but it means the underlying GGUF data is not sitting there as a conveniently named file you can hand to another program.

To move a GGUF from LM Studio into Ollama, the common method is to create a Modelfile, a small text file containing a FROM directive that points to the path of the existing GGUF, and then run the ollama create command to register it. Ollama imports the weights and generates the appropriate manifest, after which the model can be run like any other. Going the other direction, from Ollama to LM Studio, requires locating the correct blob in Ollama's store. Since the blobs lack a .gguf extension and are named by hash, users typically inspect the manifest to identify the right file, then copy it or create a symbolic link with a proper name inside LM Studio's models directory so the application will recognize it.

A few practical caveats are worth noting. Copying duplicates the file and doubles disk usage, which partly defeats the purpose, so symbolic links are often preferred when the operating system supports them, though this ties the two tools to a shared file that neither should delete independently. Quantization level and model architecture must be supported by the version of llama.cpp bundled with each application; a very new model may load in one tool but not in an older build of the other. It is also sensible to keep backups of any manifests before editing storage directories by hand, because Ollama does not expect manual changes to its blob store.

Beyond these two applications, the same GGUF file can generally be reused by other llama.cpp-based front ends and by the command-line tools shipped with llama.cpp itself, as well as projects such as Jan, GPT4All, and text-generation-webui, depending on their configuration. The broader trend is a growing ecosystem of local inference tools that converge on GGUF as a shared container, which reduces lock-in and lets users experiment with different interfaces without repeatedly re-downloading weights. As always, exact directory paths and commands may change between releases, so it is advisable to confirm the current locations in each tool's documentation before rearranging files.