Your prompt is only part of the window
A context window includes the system instructions, conversation history, retrieved documents, tool results and the answer being generated. Reasoning tokens also consume room where the model generates them. Budgeting only for the first prompt can miss the peak.
For a standard attention model, the KV cache stores keys and values for each live token. The model architecture determines how many values are needed per token. Grouped-query attention often reduces this cache relative to a model with a separate KV head for every attention head.
The same model, four times the cache
Ministral 3 14B has 40 layers, eight KV heads and a head dimension of 128. At FP16, one 8,192-token conversation requires approximately 1.25 GiB of standard KV cache. At 32,768 tokens that becomes 5 GiB. The weights are unchanged.
Four simultaneous conversations at the same allocated length can also use roughly four times the cache of one. This is why a model that runs alone may fail under multiple users. Prefix sharing and other optimizations can change actual use; the planner does not assume they are available.
A supported context is not a free allocation
The model card may advertise an extended context that needs special runtime configuration or positional scaling. The calculator marks extended context separately. Selecting it does not configure your runtime; follow the model card’s instructions.
Static caches may allocate the full configured window in advance; dynamic caches can grow as tokens arrive. Sliding-window, hybrid and compressed-attention architectures behave differently. The calculator uses a separate cache profile for each architecture. Models with unverified cache behavior show no fit verdict.
See it on your own setup.
Change the model, hardware or context and see the memory budget update.
Try this example