Executable programs and extensions
Local LLM slow on its first run? Five checks before blaming the hardware
After installation, a silent first request can make the entire hardware choice feel wrong. But some of that wait may be preparing model files. Before raising settings at random, repeat the same short request and see what changes.
Downloading or generating?
A newly selected model may need downloading, and a downloaded model still needs loading into memory. Check progress and logs for the current stage. A faster GPU will not fix a network download. If the next request is much quicker, preparation may have contributed to the first wait. Yet keeping only the second result hides the experience of someone who launches the app each time. Record cold and already-running conditions separately.
What changes with a shorter input?
Start a new chat without history or attachments and ask something short. An improvement suggests that slow writing was not the only issue. Inspect an unnecessarily large context setting too; a supported maximum is not a compulsory default. Reducing it blindly can truncate useful material, so check the actual input and required headroom. Add document content gradually after the short test works. Changing many settings together makes this boundary harder to identify.
Where did the model end up?
Loading a file successfully does not mean execution is entirely on the GPU. On a discrete-GPU system, parts that do not fit may follow another compute path. Inspect placement and, if needed, try a smaller file with the same request. This is a capacity diagnostic, not a claim that smaller models are always better. On a Mac, account for the operating system and other applications sharing unified memory. A successful load is different from stable use alongside your usual work.
Do not mix different kinds of warm starts
Keeping a model resident and reusing a shared input prefix are different effects. Do not attribute every faster repeat to the same cache. Compare a new sentence while the app stays open with repeating an identical long input. If you warm up before testing, record that fact. Look at repeated results under comparable conditions rather than selecting the fastest run. Record application versions and model filenames so changes after an update remain explainable.
A cut-off answer is a different problem
A sentence ending halfway calls for checking output limits, stopping conditions, context headroom and errors before blaming speed. Raising the limit may increase generation time and change memory requirements. A short answer does not necessarily exhaust the limit either; the model may stop itself. Check completion reasons or logs where available. The first test should establish one reliably completed request, not the largest score. Then add the required documents, output length and acceleration options one at a time.