Optimize — every setup that fits

The calculator gives one answer per GPU: the smallest unit that fits. Optimize keeps the alternatives. For one model it enumerates every way to serve it that fits in memory — each GPU, each weight precision, each tensor, pipeline and expert parallel shape — at every context length, and puts them on one map of speed per user against $ per million output tokens. Use it when the question is not "what fits" but "what is the best trade-off".

What you set

• Model — a catalog model, a HuggingFace repo or a manual architecture, or the model you were sizing when you came from the calculator's "Optimize map" link (the calculator's geometry rides along). There is no default model; nothing runs until one is set. Share links restore catalog models only.
• Users at once — concurrent users decoding at the same time. Every mark on the map is re-sized for this load: KV cache for each user, speed at that batch.
• Workload — the prompt and answer per request: Chat (1K → 256), RAG / documents (8K → 256), Long answers (1K → 2K) or Long context, where the prompt fills half the context window.
• Runtime and KV cache precision — vLLM, SGLang, TensorRT-LLM, llama.cpp or Ollama; FP16, FP8 or INT8 KV.
• Include — end-of-life GPUs (off by default), and Tensor parallel for MoE for MoE models (off by default, see below).

What the sweep enumerates

Each point is computed with the same primitives as the calculator, so a point equals what the calculator prints for that exact unit. The shapes tried:

• Dense models — every valid tensor-parallel degree on one node up to the fabric's limit. When nothing fits without pipeline stages, the smallest pipeline depth at the largest TP (NVSwitch multi-node up to 64 GPUs; PCIe, bridge and xGMI stages inside one node).
• MoE models — every expert-parallel degree that fits. Tensor-parallel shapes are added for a GPU only when no EP degree fits there, or for every GPU with Tensor parallel for MoE, marked as reduced calibration.
• llama.cpp and Ollama — one GPU only: they split layers across GPUs, which adds memory but not speed.
• Rack-scale systems — only beyond one 8-GPU node.

Precisions are the ones your runtime supports, minus the ones that would mislead: NVFP4 only on Blackwell, MXFP4 only for gpt-oss, block-scaled FP8 folded into FP8 (same size and speed), no TensorRT-LLM on AMD. FP8 on GPUs without native FP8 tensor cores (Ampere and older) stays on the map with an FP8 emulated badge — it runs, but slower than INT8.

Every context stop at once

The sweep covers context stops from 4K to 1M tokens, up to the model's maximum, in one request. The context slider then switches between stops without another request; each point also records the longest context that setup holds, shown on the pick card as "Fits up to 128K context on this setup". The window is the per-user KV reservation, so as the slider moves right, setups slow down, get pricier or stop fitting. Details in Goals, draggable limits and the context slider.

Optimize, the calculator and the Pareto explorer

The calculator's list is one greedy unit per GPU. What fits shows the minimum GPU count per model. The Pareto explorer on the TCO page sweeps batch sizes against a latency SLA and applies a sizing margin. Optimize does none of those: it answers "which setups fit, and where does each sit on cost and speed" for a fixed user count. Pick a setup there, then Apply to calculator for the memory breakdown or Size a fleet in TCO for a fleet.