# GPU inference pilot: what to check before an operating agreement

A technical pilot plan for GPU owners and operators: objectives, model, request profile, success criteria, expenses, recovery and the final decision.

Author: Retrivium team
Updated: 2026-11-01
Canonical URL: https://retrivium.ai/journal/pilot-checklist/
Language: en

A technical pilot reduces uncertainty. It should establish whether a specific configuration suits the chosen model and operating mode. A pilot does not confirm future demand or replace a commercial agreement.

A one-page plan helps both parties understand the objective and result in the same way.

## Define the starting conditions

Record machine configuration, environment versions, available time and responsible people. Select a specific model version with a permitted use. Grant-funded equipment requires the necessary approvals before external commercial workloads.

Separately state what may change. A pilot on a working server does not automatically authorize OS reinstallation, file deletion or broader access.

## Agree on the request profile

Prepare several synthetic scenarios without confidential data: short conversation, long input, long output and concurrent requests. Record context limits and generation parameters.

A test result without its workload description is hard to use. “One hundred tokens per second” does not explain whether it covers one request or several, includes waiting, or accounts for errors.

## Choose metrics and criteria

Measure time to first token, total latency, successful responses, queues and resource limits. Examine variation rather than averages alone. The [vLLM metrics documentation](https://docs.vllm.ai/en/latest/usage/metrics/) helps define observable service metrics.

Add quality checks: answers must remain useful for the selected tasks. Changing weight format for speed requires a separate output comparison.

## Test operations

Assess power consumption, temperature and sustained stability. Test the agreed restart and return-to-readiness time. Do not simulate incidents on a machine carrying active work without separate approval.

Record pilot expenses and who pays them. Set early-stop criteria: hardware errors, conflicts with the owner’s work or exceeding agreed limits.

## Finish with a decision

The final report should contain configuration, results, limitations and the next step: onboarding, improvements or rejection. If work does not continue, revoke access and restore the agreed state.

After the technical conclusion, discuss [economics](/journal/inference-economics/) and [reporting](/journal/capacity-reporting/). An existing benchmark is not required for an initial proposal.