Accepting a GPU configuration as a team

Preparing the decision before provisioning

Start with a completed unit of work: an enriched and exported folder, a batch of renders opened by its recipient, or an evaluation accompanied by its outputs. Write the business criterion alongside the technical criterion. A program can finish without errors and produce unusable results. Conversely, a correct result obtained only once does not yet prove that the team can re-run the work and retrieve its files.

Keep the parameters that influence the load: input volume, precision, batch size, concurrency and dependencies. Distinguish between a queue of independent jobs, a task that spreads its computation across several cards and a service receiving requests continuously. These three arrangements do not have the same acceptance criteria. A line reading "powerful GPU" gives no one a way to decide.

The project owner sets the criteria before the tests. The operator prepares the access, the application owner provides the known launch procedure and the recipient validates the outputs. The same person may hold several roles; each role must nevertheless have a holder and a substitute. Within the chosen period, reserve time for installation, testing, a possible fix and the final export, in addition to the useful computation.

Separate manufacturer, allocation and actual task

A GPU datasheet describes reference hardware. The allocated machine brings other properties: the number of visible devices, the access granted, software versions, usable volumes and paths. The benchmark task brings a third level: the result obtained with your data and your settings. In the grid, assign each line to a single level so that a manufacturer characteristic is not treated as a measurement of your service.

Do not infer NVLink, a particular topology or disk throughput from the card model alone. If your application depends on these properties, turn them into explicit requirements, have the scope specified and then verify it on the target. If they are not necessary for your workload, do not add them as artificial acceptance conditions.

Memory per GPU and the number of cards remain two different columns. A B200 lot at Capordia includes two GPUs; that is not enough to give a single unified memory to a program designed for one card. Document the software's distribution mechanism before expecting a benefit from it.

Build the inventory without changing settings

On NVIDIA, the commands below report the tool version, the list of GPUs and a few attributes in CSV format. Consult the installed help first: the available fields and functions depend on the version. NVIDIA documentation recommends identifiers such as the UUID to track a device, since the order of indices may change. Keep the units as written by the tool. These readings do not launch a GPU task and do not qualify its performance.

For AMD, note the version with "amd-smi version", then the inventory and static properties with "amd-smi list --json" and "amd-smi static --json". Check the options via your installation's help. AMD SMI assumes an AMD GPU and its driver; the documentation consulted is that of AMD SMI 27.0.0. An unavailable field must remain "not established", with its reason, rather than be given a guessed value.

Then archive the versions of the application and its libraries. The CUDA banner in NVIDIA SMI does not by itself prove the version of the installed toolkit. For ROCm, match the combination of GPU, system and version against the corresponding matrix. In both cases, the decisive test remains launching your application in the environment actually intended.

The file provides the NVIDIA and AMD commands to run on your machine, then attach to the report. They are based on the official documentation; no CUDA or ROCm results were measured in this example. The downloadable command file covers both branches and the fields to attach to the report.

nvidia-smi --version
nvidia-smi --help-query-gpu
nvidia-smi -L
nvidia-smi --query-gpu=index,name,uuid,memory.total --format=csv

Turn every requirement into an observable check

A good acceptance line links a criterion, a method and a piece of evidence. "Enough storage" becomes, for example: working location identified, available space recorded before launch, and export opened from its destination. The amount needed is the amount your work needs, including intermediate files; this guide does not assume a disk capacity attached to each GPU.

Fix the units before comparing two readings. A decimal GB is one billion bytes; a GiB is 2 to the power of 30 bytes. Tools may display the English notations GB and GiB, or MiB for a smaller unit. Keep the raw value and its unit, then note any conversion. Do not rule out a configuration solely because a spec sheet and a reading use different notations.

For networking, test the project's flow: same destination, same permissions and a representative file type. A single download does not qualify the export of thousands of small results. Measure and document the transfer in both directions if the project uses them, then record the threshold your schedule requires. Without a threshold decided before the test, an observed duration remains just an observation.

A status of "not run" is better than a success with no evidence. The CSV grid leaves the observation, date and evidence columns empty. You may remove an out-of-scope check only if you explain why and keep the decision-maker's agreement.

Make the benchmark task a handover

Choose an authorized sample that brings out the constraints of the real work. A tiny demonstration is useful for checking the launch; it does not replace a case that reveals the memory peak, the intermediate files or the final export. Record the test set identifier, the versions and the settings. The shared folder references how secrets are supplied without storing their value.

The application owner performs a full cycle from a known startup to opening the outputs. The operator then repeats the journey from the procedure, without relying on a hidden state in the first operator's terminal. The goal is to verify a usable handover: paths, permissions, launch, log location and recovery.

Also define what happens after a controlled failure. A temporary output must be distinguishable from an accepted result. The acceptance folder must not invent a recovery mechanism the application does not have: it records the one that exists and refers to the migration procedure for organizing interrupted batches. If the computation is numerical, the tolerance belongs to the business protocol; bit-for-bit identity is not a universal requirement.

When you compare several configurations, keep this protocol constant. Also note errors and tests to redo. The final decision may favor one option because it simplifies the work queue, the acceptance or the schedule; it does not need to turn a single reading into an overall GPU ranking.

Read a filled-in example without mistaking it for a measurement

The downloadable "Atelier des plans" example is entirely fictional. A team wants to process a trial corpus of twelve technical documents and then produce a searchable index for reviewers. The twelve documents are a hypothetical arrangement; no speed, memory consumption or GPU measurement is given. The H100 target is a scoping candidate, to be confirmed after reviewing the software and the workload.

The application owner prepares the launch and the expected credentials. Operations checks access and the return of files. The person responsible for the results must confirm that each document has a readable output and a reference in the index. In this scenario, they have not yet been able to open the export from their destination. The hardware and application lines remain unexecuted; the fictional decision is therefore "go-live blocked."

This example shows how to fill in responsibilities and make a decision explainable without fabricating a success. The absence of proof of export is not a mere side note: it specifically blocks the use case that requires retrievable results. The next attempt must repeat this check, attach its evidence and have the decision dated. Simply deleting the comment in the grid is not enough.

Refuse, accept with a reservation, or defer the decision

An unmet blocking criterion halts acceptance of the scope concerned. A check that cannot be performed does not become a pass by default: it produces a "blocked" or "not executed" status, an action and an owner. Avoid using "reservation" to mask a prerequisite of the work. If an output cannot be retrieved, accepting the computation alone does not authorize the full chain.

A reservation may be suitable for a secondary item if the permitted use is clearly limited, if a temporary solution is verified and if someone accepts that scope. Record a recheck deadline and what will happen if it is not met. An acceptance limited to a trial does not amount to acceptance of production.

The minutes record the decision, the checks that justify it and those that remain open. Technical acceptance confirms neither a payment nor a contractual date: those tracking items keep their own references. Once the criteria are met, the team hands over to operations the launch procedure, the versions, the data locations and the exit procedure.

Download and use the version 1 acceptance file

The Markdown template serves as a cover page and minutes. The CSV grid provides the checks to customize, with columns for the level of evidence, the owner, the criterion decided before the test, the method, the observation, the evidence and the status. Open the CSV in UTF-8 with a comma as the separator; the result fields are intentionally empty. Keep a blank copy before working.

Open the template with a text editor and the grid with a spreadsheet. Adapt the fictional example to your requirements, then record the observations on your own machine. The license provided authorizes use and adaptation provided the notice is retained; product names and external documentation retain their respective rights.

Use this acceptance to authorize a precise scope, then update it when versions, data, or operating mode change. It is neither a universal benchmark nor a guarantee of no interruption. The migration guide takes over when a working state must be moved and the fate of each batch explained.