Executable programs and extensions

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.

Two people at control panels and laptops on either side of a central server, with colored lines and blocks connected from it
Direct execution makes files and settings easier to record, but builds and updates also need management.

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.

Start a local server with a GGUF model
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
This assumes the executable is on PATH. If self-built, adjust its path and check the GGUF location and that build's --help.
A green book with an animal illustration connected by an arrow to a yellow book with a speech bubble, in front of a landscape display
Fix the model and request to compare the effect of later setting changes.

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.

Check server readiness and answer 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}'
Keep the server terminal running and use another terminal. Check readiness before requesting generation.

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.

A hand places a yellow block on a path-shaped board while a magnifying glass enlarges a red route between blocks
Find the slow stage between input processing and generation, then change only related settings.

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.

Set cache types in an existing Vulkan server command
./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 65536
Compare with a compatible sparse model and a sufficiently long context. Adjust the model path and context size to available memory.

Version 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

  1. GGUF — A file format for model data, widely used by llama.cpp-based tools.

    Back to the text
  2. GPU — A processor designed to handle many calculations in parallel. It performs model computations during AI inference.

    Back to the text
  3. Prefill — 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 text
  4. Token decoding — The stage that generates successive output tokens using the input and the response produced so far.

    Back to the text
  5. Context 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 text
  6. CUDA — A software platform for general-purpose computing on NVIDIA GPUs.

    Back to the text
  7. Metal — Apple’s low-level technology for graphics and parallel GPU computation.

    Back to the text
  8. Quantization — 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 text
  9. Runtime — 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 text
  10. Prompt — The input text sent to a model. For generative models it describes the desired result and strongly shapes the output.

    Back to the text
  11. API — A defined interface that lets other code call a program’s functions.

    Back to the text
  12. Time to First Token — The time from sending a request until its first output token arrives.

    Back to the text
  13. Token — A unit into which a model divides input or output for processing.

    Back to the text
  14. KV 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 text
  15. Throughput — 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 text
  16. MTP — 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 text
  17. Attention — A neural-network operation that calculates relationships between input tokens and combines information from each position into the current representation.

    Back to the text
  18. MoE — 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 text
  19. CPU — 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 text
  20. System 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.

  1. 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.