# A reference GPU-node configuration for a small pool

Document one reproducible GPU node through hardware, software, workload, metrics and meaningful deviations before evaluating additional servers.

Author: Retrivium team
Updated: 2026-11-01
Canonical URL: https://retrivium.ai/journal/gpu-reference-configuration/
Language: en

If every server joins as a separate experiment, a pool accumulates hard-to-explain differences: drivers, weight formats and implicit settings. A reference configuration connects hardware to tested service behavior.

For a small project, one reproducible node and its description can suffice. Document quantity matters less than another specialist understanding the test and which changes require repeating it.

## Record the hardware foundation

Specify GPU model, memory, count, host resources and connections. Include operating conditions such as power mode, networking and maintenance route. Do not combine different hardware variants under one general name.

The reference should not become a mandatory shopping list. Another machine may support a different useful workload. Identify differences first, then decide which matter for the task rather than rejecting heterogeneous equipment automatically.

## Preserve the software set

Record driver, runtime, engine and model versions, weight representation and launch settings. A changing tag without its resolved version does not reproduce a result.

[NVIDIA CUDA Compatibility](https://docs.nvidia.com/deploy/cuda-compatibility/minor-version-compatibility.html) relates compatibility to versions and capabilities. CUDA installed is therefore insufficient for node comparison. Preserve exact versions and confirmation of the required scenario instead of inferring compatibility from family names.

## Describe the workload

Include known input and output lengths, concurrency and warmup. State tested model functions separately: text chat does not establish tools or structured output.

Preserve observation methods. [vLLM metrics](https://docs.vllm.ai/en/stable/usage/metrics/) can support indicator selection but must match version and scenario. A measurement without units and workload context is difficult to use in the next-server decision.

## Maintain a deviation list

Suppose a new node has the same GPU but less RAM and another disk. Check loading and recovery before repeating the service test. A restriction appearing only during weight updates still belongs in the node record.

Avoid one better-or-worse label for every difference. Some tasks prioritize memory, others startup or connectivity. A reference supplies a comparison language while retaining heterogeneous-fleet options. Preserve exact weight revision and artifact ID too: identical short filenames can represent different conversions. A changed artifact cannot automatically inherit previous results without comparing conditions.

## Apply the reference to the next decision

Owners can submit specifications and compare them with the selected scenario. Funders can distinguish confirmed capabilities from expenses introduced by another configuration, reducing uncertainty before expansion.

Prepare with [a reproducible stack](/journal/software-stack-reproducibility/) and [mixed GPU fleets](/journal/mixed-gpu-fleet/).