Summary: Released on June 5, Ollama 0.30 expands GGUF support, enables Vulkan by default, and reports up to 20% higher NVIDIA throughput. The NVIDIA figure came from Gemma 4 26B on an RTX 5090 with Q4_K_M quantization and has no independent verification in the post. The release also lets supported GGUF models keep tool calling, lowering setup cost for local coding-agent use.
Released on June 5, Ollama 0.30 works at the engine level: gains in llama.cpp push performance and GGUF model compatibility ahead at the same time. This release ships no crowd-pleasing extras; it simply makes running models locally easier across a broader range of hardware — the MLX engine on Apple silicon gets strengthened, while every other platform gains a larger set of runnable models plus quicker execution via the GGUF engine.
Up to 20% on NVIDIA — a figure that comes with its test conditions
Top billing goes to a throughput gain of up to 20% on NVIDIA hardware; check the test conditions before the size: the optimization is the product of NVIDIA working alongside llama.cpp contributors, and the benchmark ran the Gemma 4 26B model on an RTX 5090 with Q4_K_M quantization. “Up to” plus one configuration is a double qualifier — another model, quantization, or card may not repeat it. These optimizations do merge into llama.cpp upstream, so every user gets them with the engine instead of a demo-only setup.
Vulkan enabled out of the box: no install hurdle left on the GPU acceleration path
For adoption, the bigger deal is Vulkan shipping enabled by default. Turning on acceleration for AMD or Intel GPUs used to mean installing vendor-specific libraries first, and that step was where many attempts fell over. Acceleration on the GPU now works with no setup at all, across a wider set of hardware. One plain caveat: no Vulkan-versus-native-backend comparison appears in the post, so heavy users chasing peak throughput ought to measure first and pick a backend after. For the common “just get the model running” situation, the default route is plenty.
Broader GGUF support, with imports trimmed to three steps
Model-side, GGUF support is visibly wider: newer families like LFM and Prism, plus fine-tuned models from Unsloth, now run as loaded — no holding out for an official library listing, no conversion scripts of your own. Bringing in a GGUF downloaded from Hugging Face sticks to the routine Ollama users already know:
FROM ./my-model.Q4_K_M.gguf
ollama create -f Modelfile my-model
ollama run my-modelIn the Modelfile, FROM points at the GGUF file itself (or a directory holding GGUF files); once create has run, launching with run is indistinguishable from launching anything else in the library. Zero conversion scripts, zero backend configuration — the release’s most immediate simplification of day-to-day work. Teams chasing fresh models lose the wait as well: fine-tune releases land weekly, and the old fork — hold out for an official listing or maintain a conversion script — folds into one FROM line, leaving nothing between a model’s release and local use.
Tool calling survives the import: local models driving coding agents
The most developer-relevant line: a GGUF model that supports tool calling keeps that support inside Ollama; the import does not strip it away. First run ollama show my-model and check the output for the tools capability; once confirmed, the local model can go behind coding agents and personal assistants. The post demonstrates the command as ollama launch claude --model my-model, and hermes plus openclaw follow the same pattern. A sane rollout: verify capability with show, attach the model via launch, then run a small task to exercise the full path — have the agent call one simple tool and inspect the result — before this goes anywhere near a real workflow.
(This paragraph is my interpretation) The value here is optionality: a coding agent’s model no longer has to come from a cloud API, giving privacy- or cost-conscious setups a local alternative. Tool-call quality still rests on the model, so the two cheap gates stand — confirm capability before importing, run a small task after.
Taking a brief announcement at face value
As announcements go, this one is short, and honesty requires a few qualifications. The 20% number is the vendor’s own claim, tied to one configuration, with no independent verification behind it. Vulkan’s real performance, and which file gets picked when a directory holds several GGUF files, go unaddressed — community testing will fill those gaps. Hence simple upgrade advice: NVIDIA users should benchmark their own models after upgrading before concluding anything; AMD and Intel users should verify the GPU is truly being used; and anyone importing a GGUF for tool calling should run ollama show first. 0.30’s worth lies not in a dramatic number but in three friction points of the local-model workflow — setup cost, model compatibility, agent integration — each one layer thinner.