CapordiaAssembling a starting file that is compact but reconstructible
Keep the versions of the system, the application, and its dependencies, the launch procedure, and a small representative dataset. Add the expected paths, the permissions, and how to verify the outputs. This manifest describes a known reference. For a change, create a candidate version alongside that reference; secrets stay in your access management system. Name the missing items and their owner rather than hiding them behind an "environment ready" statement.
Designate one person for acceptance and another for the switch decision when your organization requires it. They must know the criteria before the new workload becomes a dependency for the rest of the team. The Ubuntu, PyTorch, Blender, or custom preference chosen at checkout guides preparation; it does not replace a precise inventory of your application.
Verifying the resources that are actually visible
On handoff, compare the detected model, the number of cards and their memory against the expected scope. Also note the project-relevant elements that the GPU alone does not describe: system, workspace, permissions and access to destinations. Any discrepancy becomes a precise question to address, without assuming a CPU, network or disk capability absent from the spec sheet.
On an NVIDIA environment with nvidia-smi available, the proposed command reads the name, the total memory reported by the tool and the driver. It does not qualify performance or all CUDA dependencies. For AMD, use the documentation matching the hardware and the ROCm combination selected; avoid transposing an NVIDIA check as proof that an MI300X works.
nvidia-smi --query-gpu=name,memory.total,driver_version --format=csvRun a complete pass with separate criteria
Check access, configuration, data loading, execution and export in turn. For each step, note an observation and a decision. A program that finishes without error has not necessarily produced all the expected files. Conversely, a correct display of the card does not prove that the software is using the chosen GPU.
Set the acceptable result before the test. It can be an exact number of folders, an image checked visually or a numerical criterion. PyTorch points out that full reproducibility is not guaranteed across versions and platforms. So choose the tolerance suited to the work together with its owner; do not widen it after the fact solely to make the test pass.
| Step | Expected observation | Decision if failure |
|---|---|---|
| Access | The authorized person reaches the right environment | Fix access before import |
| Loading | All test set inputs are readable | Fix the package or its permissions |
| Execution | The processing uses the intended resources and finishes | Identify the dependency or setting |
| Result | The content meets the written criteria | Suspend the campaign expansion |
| Export | The result is usable from its destination | Fix the output before switching |
Worked example: one hundred folders received, ninety-nine results
In this fictional case, a team replaces version A of a preprocessing step with version B. Its manifest states the code, dependencies and output format before and after; the acceptance set still consists of the same 100 folders identified from 001 to 100. Version A produces 100 results. Version B finishes but exports 99 distinct identifiers: folder 057 is missing. The written criterion requires 100 results with no duplicates. The change is therefore rejected at this stage.
A dependency needed for folder 057 is missing from the candidate package. The team restores it in a new version of the manifest, checks that folder, then replays the 100 inputs on the corrected candidate. It gets back 100 distinct identifiers and opens the package from the final destination. The complete test verifies that the fix did not merely repair the isolated case. This result resolves the discrepancy described; it does not yet prove operation on a larger volume or under continuous load.
Compare the manifest before and after, then decide on adoption
The change record fits in a few lines: reason, element changed, elements kept, criteria and owner. Keep a usable copy of the reference configuration. If you change the driver, the framework and the data format all at once, you multiply the possible causes of a discrepancy. Split them where possible; otherwise, explicitly treat this set as a broader change.
After correction, have the new reference approved by the owner of the result. The table below organizes this decision; it is not an inventory of software provided. A selected version becomes the reference only after the agreed checks. Date the adoption and indicate the tasks to which it applies, so that two people do not silently launch two variants of the same campaign.
| Element | Before | Candidate retained after correction |
|---|---|---|
| Application | Version A | Version B, dependency fix included |
| Acceptance inputs | 100 frozen folders | The same 100 folders |
| Required results | 100 distinct identifiers | 100 distinct identifiers, accepted format |
| Publication | Reference used by the team | Adoption dated after manager approval |
Keep a rollback option without mixing results
Before adoption, check that the previous reference can still read its inputs and resume its state. Keep the candidate's outputs separate, avoid publishing twice, and define who can decide on the rollback. If the new software irreversibly modifies working files, simply keeping the old program is not enough: a compatible data state is also required. The migration guide covers switching between environments; here, the decision concerns the qualified software change.
Payment confirmation and provisioning remain separate from these technical checks. The "I have paid" button signals a payment; it validates neither access nor the software change. Run the tests once the environment is actually accessible, then link their result to your order reference in the internal record.
Finish with a team able to operate and exit
The expected output is a short record: environment surveyed, acceptance set, accepted checks, remaining gaps and the person who decides what happens next. Have someone who did not prepare the installation review the launch procedure. If that person has to ask for a path or an essential setting, complete the record before handing over operations to them.
Also plan the final retrieval and its check. Common mistakes are scaling up the workload before acceptance, changing several versions during diagnosis and only discovering the export at the deadline. Over 3, 7 or 30 days, allow time for these steps within the chosen period, without treating them as operations that are necessarily instantaneous.
Questions to decide
Is a detected card enough to accept the deployment?
No. Detection verifies part of the hardware scope. You still need to load the inputs, run the software, check its results and retrieve them from their destination. Each check must have a distinct criterion.
Must outputs be exactly identical after a GPU change?
That depends on your workload. Define what must remain strictly identical and what falls under a justified tolerance. Document the versions and parameters; perfect identity must not be assumed for every piece of software and every environment.
Who decides that a gap is acceptable?
The person designated for the criterion concerned, together with the switch decision-maker when the gap affects the service. The person running the test describes the observation; they do not automatically replace the business or data owner.