In this article
The useful context is the one your workload and memory can support reliably. Preserve its effective settings rather than quoting only a model card maximum.
Set Ollama context length according to the task and available memory, then verify the effective configuration. A model’s advertised maximum is not proof that your machine can serve it at that length. Inputs, conversation history and generated output all belong in the working budget.
Define the useful window
Collect three representative inputs: a short question, a working document and a long conversation. Include system instructions, templates and any supporting material added by the application. The raw document alone is not the complete prompt.
Use the current context documentation for the installed release rather than assuming one timeless default. First choose a modest working limit and state why the task needs it. A higher number can increase memory demand without improving the useful result for short requests.
Put the setting in a known place
For a model created through a Modelfile, the source example is:
FROM qwen3:8b
PARAMETER num_ctx 8192The base name must match the actual installed tag. This illustrates an explicit context setting, not a universal recommendation for that model or GPU. Preserve a separate copy of the working Modelfile.
If the application also supplies request options, record them. Otherwise an operator may inspect one setting while the client requests another. Reproducibility requires the model configuration and the request path together, including any environment-based defaults used by the server.
Check memory after the change
Load the model and issue a short request with the chosen context, then try the representative longer input. Inspect placement using the supported process information and system observation. A successful greeting is not enough to establish behaviour at the working input length.
If increasing context changes the configuration to mixed CPU/GPU execution, include that in the result. The model may still answer correctly while the user experiences a different delay. Judge both usefulness and resource consumption rather than recording only a successful HTTP status.
Add concurrency only after the baseline
Parallel requests need additional resources. A single long request does not establish that several similar requests fit together. Keep a table for a small context, the chosen working limit and the next larger tested level, with memory, placement and response time.
Change concurrency separately. Preserve actual input and output lengths so another operator can reproduce the boundary. If the larger setting fails, return to the recorded working state before investigating further; do not erase a useful baseline while searching for a theoretical maximum.
Turn the check into a practical next step
The useful context is the one your workload and memory can support reliably. Preserve its effective settings rather than quoting only a model card maximum.
For the documented details, consult the primary documentation; configuration reference; additional official reference. Continue with ollama cpu gpu split and ollama two models parallel.