Executable programs and extensions
Last updated
llama.cpp: finding which settings are slowing you down
Use llama.cpp to pin files and settings and locate slow stages
llama.cpp runs GGUF1 models, and llama-server accepts HTTP requests. Direct use lets you record and change the backend, context, GPU2 placement, and concurrency. Keeping the model and request fixed while checking connectivity, prefill3 for long input, and answer decoding4 separately helps determine whether tuning is needed.
Consider llama.cpp when you want direct control of GPU placement or context length5 that your app does not expose. Starting a server with a fixed file and request helps you decide what to adjust across loading, input processing, and generation. You also manage binaries and updates yourself, so keep your app if it already offers the settings you need.
Create a baseline with one model and request
For summarizing a long technical memo, keep the GGUF file and request fixed. Check the server response with a short request, then submit the whole memo. Separating input processing from answer generation shows where you wait.
Direct execution also means managing the executable, drivers, updates, and commands. That effort is useful when you need conditions unavailable in an application or must reproduce a build-specific issue.

Check executable and model support even when a GPU is visible
Low GPU utilization alone does not indicate a faulty card. A CPU-only executable will not use a GPU backend even when a GPU is present. NVIDIA CUDA6, Apple Silicon Metal7, and Vulkan have different setup paths. Check detected devices and selected backend in startup logs; changing placement options cannot enable an undetected backend.
GGUF is a distribution format, not a guarantee that every build supports every model architecture. For a new architecture, check executable support and the conversion's source model. If you need image input, separately verify multimodal implementation and required files; a text GGUF alone does not provide an image path.
Start the server with a model path and baseline settings
After preparing a model file, replace ./models/model.gguf with its actual path. The local-guide alias, 4,096 context budget, and one parallel slot are baseline comparison settings. Context is shared by input and generated output, so 4,096 does not mean the full budget can be used for the memo input. Separate first-load time from subsequent requests.
Start GPU-layer placement at auto and inspect logs and per-GPU memory for actual placement. An auto option does not mean the entire model is on GPU. If the executable differs from expectations, check its version and --help, then save the smallest working command and its logs. A command with unsupported options removed is not the same condition as the original example.
Record the GGUF filename and quantization8, executable version, backend, 4,096 context, and one slot. Keep the model and runtime9 conditions fixed so you can change batch or GPU placement one item at a time.
llama-server -m ./models/model.gguf --alias local-guide --host 127.0.0.1 --port 8080 --ctx-size 4096 --parallel 1 --n-gpu-layers auto
Check readiness and API generation separately
After the server process starts, check that /health reports readiness and send a short prompt10. The first command checks status; the second requests text generation. Verify the alias and basic connection before submitting the full memo to isolate load and connectivity issues.
An API11 success does not verify that a client-specific template or tool-calling format works. The curl request below waits for the full response, so it can show round-trip time but does not measure time to first token12 or prefill and decode separately.
curl -sS http://127.0.0.1:8080/health
curl -sS http://127.0.0.1:8080/v1/chat/completions -H "Content-Type: application/json" -d '{"model":"local-guide","messages":[{"role":"user","content":"Reply with one short sentence."}],"max_tokens":128,"stream":false}'Separate prefill, decode, and concurrent requests
If the first answer is delayed after a long memo, prefill may be responsible; if tokens13 arrive slowly after generation starts, inspect decode. Long input also uses more context memory, so compare against the 4,096-context baseline and check GPU headroom and KV cache14.
Increasing prefill batch may help long-input processing, but it does not imply decode speeds up by the same factor. Increasing concurrency can affect aggregate throughput15 without reducing one user's completion time. For individual summaries, keep one slot as the baseline and change only the relevant batch, context, or GPU-placement setting indicated by logs.
For comparisons, keep the GGUF file and quantization, input and output lengths, backend, and concurrent request count fixed. After a warm-up run, send the same request at least three times and record whether the model is resident and whether the KV cache is reused.
A run is not a cold start if you could not clear the cache. If one result is an outlier, keep it and check warm-up state and background load before summarizing with the median.
A curl request that waits for the full answer measures round-trip time; it is not a benchmark that separates prefill and decode. Once the target task completes reliably, decide whether direct management provides enough benefit. If Ollama or LM Studio offers the needed options, you can keep using it.

Using quantized KV caches for long contexts on Vulkan
llama.cpp b11413 improves the Vulkan execution path for some long-context models. It targets sparse-attention architectures such as QSA in Qwen3.8-Flash-Next, which select only needed positions. With quantized K/V caches, the new path reads those selected positions instead of processing the entire context.
The PR author's Radeon R9700 and RX 7900 XT measurements report average decode improvements of 19% at 64K and 15% at 128K with q8_0 KV caches. Shorter contexts can have little benefit or regress, so the runtime selects the path. These figures do not apply to f16 caches or prefill. Use the following command after preparing a Vulkan build and a compatible model.
./llama-server -m /path/to/compatible-sparse-model.gguf --host 127.0.0.1 --flash-attn on --cache-type-k q8_0 --cache-type-v q8_0 --ctx-size 65536Version 0.6.0 also serves local decision models
Released on October 5, 2026, llama.cpp 0.6.0 adds /v1/systemone, an API that returns decisions and probabilities. It can route inquiries to teams or classify documents. The local decision-model example explains how to select a supported model and send the input and options. Official 0.6.0 release
Performance-related changes include Qwen4Exp MTP16, Metal Flash Attention17 for F16 KV, and CUDA NVFP4/MXFP4 computation paths. Compare the old and new versions using the same question and a feature supported by your model. Existing speed records retain the version used for their measurement so they can be compared with new records.
October 8 builds improve MoE caching and DFlash
Starting with llama.cpp b11507, MoE18 expert weights kept on the CPU19 can be cached across multiple GPUs. The cache reduces repeated transfers of needed experts to the GPU. It is worth testing when a large MoE model is split between system RAM20 and GPUs.
The current --moe-cache-mib specifies the total cache budget in MiB, distributed across GPUs according to --tensor-split. It is disabled by default with a value of zero. Check for the flag in llama-server --help, then compare both first-token wait and decode speed on the same document with and without the cache.
Build b11512 also fixes DFlash output-head sharing. When updating a DFlash setup, keep the main and draft models unchanged, send the same input and check that generation completes. b11507 and b11512 are October 8 rolling builds, a separate update series from the fixed 0.6.0 release.
Terminology notes
GGUF — A file format for model data, widely used by llama.cpp-based tools.
Back to the textGPU — A processor designed to handle many calculations in parallel. It performs model computations during AI inference.
Back to the textPrefill — The stage where an LLM reads the input prompt and computes representations for its tokens. Longer prompts contain more tokens to process.
Back to the textToken decoding — The stage that generates successive output tokens using the input and the response produced so far.
Back to the textContext window — The token span of input and generated content a model can handle in one request. The supported limit and memory use depend on the model and runtime settings.
Back to the textCUDA — A software platform for general-purpose computing on NVIDIA GPUs.
Back to the textMetal — Apple’s low-level technology for graphics and parallel GPU computation.
Back to the textQuantization — A way to represent model weights or values with fewer bits, reducing storage and memory use. The coarser representation can also affect accuracy.
Back to the textRuntime — The software environment that provides facilities needed while a program runs. In local AI, it can also refer to a model execution engine.
Back to the textPrompt — The input text sent to a model. For generative models it describes the desired result and strongly shapes the output.
Back to the textAPI — A defined interface that lets other code call a program’s functions.
Back to the textTime to First Token — The time from sending a request until its first output token arrives.
Back to the textToken — A unit into which a model divides input or output for processing.
Back to the textKV cache — Memory that stores attention keys and values from earlier tokens for reuse during later token generation. Its size depends on context length and batch size.
Back to the textThroughput — The amount of work processed or generated over time. Comparisons need the unit, such as tokens per second or requests per second.
Back to the textMTP — A training objective or model component for predicting multiple future tokens at once. In speculative decoding, those predictions can be proposed as candidate tokens.
Back to the textAttention — A neural-network operation that calculates relationships between input tokens and combines information from each position into the current representation.
Back to the textMoE — A model architecture that selects some of several expert subnetworks for each input. Total parameters can differ from the number activated for one token.
Back to the textCPU — The central processor that runs the operating system and general-purpose instructions; in AI workloads it also handles tasks such as preprocessing and data movement.
Back to the textSystem RAM — System memory that temporarily holds data while programs run.
Back to the text
Frequently asked questions
- What should you check first in this article?
- llama.cpp runs GGUF models, and llama-server accepts HTTP requests. Direct use lets you record and change the backend, context, GPU placement, and concurrency. Keeping the model and request fixed while checking connectivity, prefill for long input, and answer decoding separately helps determine whether tuning is needed.
- How much memory does it need?
- If the first answer is delayed after a long memo, prefill may be responsible; if tokens arrive slowly after generation starts, inspect decode. Long input also uses more context memory, so compare against the 4,096-context baseline and check GPU headroom and KV cache.
Change log
These entries record changes to the site's guidance. They do not automatically check your installed engine or model version.
Added llama.cpp server-start and recovery guidance
Added examples for starting a server with a prepared GGUF file and checking its local API. It explains how to change GPU offloading, context length and request count one at a time, then return to a working configuration if memory runs short.
Read next
Executable programs and extensions
Which local LLM app or serving engine should you start with?
Executable programs and extensions
MTPLX: will MTP make answers faster on your Mac?
Executable programs and extensions
Run local AI on a Mac with oMLX: what is new in 0.7.1rc1?
Executable programs and extensions
GGUF vs MLX: which model format should you download?
