# Record an Equipment Contribution to a GPU Pilot

Record an equipment contribution to a GPU pilot using configuration, availability, responsibilities and acceptance evidence without inventing a valuation.

Author: Retrivium team
Updated: 2026-11-01
Canonical URL: https://retrivium.ai/journal/gpu-in-kind-contribution-register/
Language: en

An equipment contribution to a GPU pilot should be recorded as a defined resource: which machine is available, for what period, under which restrictions and with what responsibilities. Describe the contribution before assigning any financial interpretation to it.

A hardware record can support a practical discussion without claiming a market valuation, an ownership transfer or a return on the equipment.

## Describe the resource precisely

List the GPU devices and memory, CPU, RAM, storage, location constraints and available schedule. Identify the owner or authorised institutional contact. Include known restrictions on workloads, access and data.

FinOps allocation provides a useful distinction between resources and the objects to which costs are attributed. Its planning guidance also encourages explicit assumptions. Neither framework supplies the commercial terms for contributing a privately owned server.

## Separate provision from actual use

| Record | What it describes | What it does not establish |
| --- | --- | --- |
| Equipment offered | Available configuration | Guaranteed acceptance |
| Schedule agreed | A defined resource window | Continuous external demand |
| Workload completed | A particular useful result | Future revenue |
| Expense recorded | An operating cost | A market valuation |
| Resource returned | Handover evidence | Automatic resolution of all terms |

Preserve these as related but separate events. Otherwise an available server can be reported as fully used even when the pilot only ran a short compatibility check.

## Agree on evidence of completion

Choose a bounded technical result: a measured inference scenario, a readiness check or an approved data-processing output. Record the configuration and conditions so another person can understand what was tested.

Also describe the return state: access, data locations, remaining workloads and acceptance by the owner. A contribution involving research equipment may require a separate institutional decision. Technical readiness does not resolve programme or ownership restrictions.

## Avoid unsupported valuation shortcuts

Do not multiply offered hours by a guessed rental rate and present the result as an established contribution value. A public cloud price may describe a different system, service boundary and commercial arrangement.

If participants need a valuation or cost-sharing method, document it separately with its assumptions and agreed purpose. Keep actual paid expenses distinct from estimated replacement cost, reserved capacity and hypothetical sales. This makes later reporting easier to reconcile and avoids assigning meanings that were never agreed.

The next discussion can then address the actual resource and operating work instead of an unsupported headline valuation.

Continue with [Build a GPU Inventory CSV with nvidia-smi](/journal/gpu-inventory-csv-from-nvidia-smi/) and [Build a Payment Calendar for a GPU Pilot](/journal/gpu-funding-payment-calendar/).

## Official references

- [FinOps Foundation — allocation](https://www.finops.org/framework/capabilities/allocation/)
- [FinOps Foundation — planning estimating](https://www.finops.org/framework/capabilities/planning-estimating/)