Start with the workload boundary
Qwen2.5-Coder 7B Instruct is useful to plan as a concrete coding workload because its official configuration exposes the attention shape needed for a KV Cache estimate and its repository metadata exposes an exact parameter total. This profile keeps those source facts attached to one reviewed revision. The resulting tables answer a narrower and more actionable question than “does a 7B model fit?”: how much memory should the selected weight path, context window, simultaneous request count, runtime reserve, and implementation margin occupy together?
Begin with the row that matches the artifact format you intend to load. The 4-bit and 8-bit rows are planning paths for quantized weights; the BF16 row represents two bytes per parameter. A runtime still needs a matching artifact and loader. The loaded-weight figure stays constant across each row, while KV Cache grows with context. Every table cell opens the main planner with the model ID, exact revision, parameter total, layer count, hidden size, attention-head count, KV-head count, context, and format already restored. This makes the page a starting state rather than a dead-end lookup table.
Read the target as a capacity boundary
The “modeled” value combines loaded weights, FP16 KV Cache for the selected active requests, and the shared runtime reserve. The larger “target” also includes the implementation margin used throughout the VRAM planner. Compare the target with usable GPU memory, not only the number printed on a GPU box. The linked plan defaults to ninety percent usable memory so display allocation, driver behavior, runtime workspaces, and other process pressure remain visible instead of silently consuming the entire nominal tier.
The candidate GPU class in a cell is the first common capacity tier whose usable-memory allowance clears that target under the current assumptions. It is a screening boundary: open the cell, replace the tier with the hardware you own or are considering, and keep the resulting headroom visible. If the workload will share a GPU with other processes, increase the runtime reserve or lower the usable-memory fraction before comparing tiers.
Treat context and concurrency as separate decisions
Long context and simultaneous requests create different operational pressure even though both consume KV Cache. Context controls the cache held for each active sequence. Concurrency multiplies that sequence pressure. A local coding session may need one active request with a larger prompt, while an API endpoint may need several requests at a deliberately smaller maximum context. The serving table holds the 4-bit weight path constant so this relationship is easy to inspect.
Choose the largest context the workflow genuinely needs, then test the expected active-request count rather than the total number of users. Queued requests and simultaneously decoded sequences are different capacity questions. If the table crosses a GPU boundary, open the scenario and compare four adjustments in order: lower the maximum context, reduce active concurrency, evaluate FP8 KV Cache where the runtime and hardware path support it, or introduce tensor parallelism. Keep replicas as a separate availability and throughput decision because each independent replica loads another copy of the weights.
Turn the profile into a deployment check
Use the exact-revision link as the record for the planning baseline. Confirm that the downloaded weight artifact matches the selected format, then set the runtime context and concurrency limits from the same scenario. Run a representative coding prompt or request mix that reaches the intended context shape, record observed peak allocation, and return that observation to the planner by adjusting reserve or utilization. This closes the loop between a source-derived estimate and the runtime boundary you will operate.
For a single-user coding workflow, start with the 8,192-token column and one active request. For retrieval-augmented work, include retrieved passages and response allowance inside the context value. For an API-serving path, use the concurrency table and continue into the vLLM planner after choosing the memory envelope. The next useful decision is always the same: preserve the exact model identity and request shape while changing only the hardware or runtime assumption you are testing.