# Spare game-studio GPUs: separating resources for inference

How game studios can evaluate external GPU workloads without disrupting editors, testing or builds: select machines, schedules and production-restoration criteria.

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

Game-studio GPUs are spread across workstations, test machines and dedicated compute nodes. Some may become idle after a project ends. This is a reason to inventory the fleet and discuss inference on suitable machines while preserving development priority.

The most useful proposal unit is a server or workstation with a clear role and responsible person. “We have twenty graphics cards” does not establish how many can actually be allocated externally.

## Group machines by purpose

Start with four groups: daily workstations, test configurations, project infrastructure and confirmed free nodes. A test machine can have low utilization but high value for reproducing problems on particular hardware.

Do not judge that value by idle hours alone. Record each machine’s function and what happens if it becomes unavailable. Systems whose state matters for bug reproducibility need separate discussion.

## Preserve primary tooling requirements

[Epic Games documentation](https://dev.epicgames.com/documentation/unreal-engine/onboarding-licensees-in-unreal-engine) describes Unreal Engine hardware and software environments. It is a starting point for checking studio work, rather than confirmation of compatibility with an LLM engine.

Before the pilot, record driver version, OS and working applications. If the environment must change, define and test restoration. A driver change on one computer must not automatically become an upgrade of the entire production fleet.

## Select a machine that can be managed independently

Imagine three stations free after a demo delivery. One remains for project support, another is intermittently needed for tests, and the third is fully available for an agreed period. The third usually provides clearer initial pilot conditions.

This is an organizational example, not a promise that any gaming workstation is suitable. Test model memory, networking, sustained load and recovery next. All machine resources matter, rather than only the graphics card listed in its specification.

Include a short studio-work check: open a typical project, perform a familiar operation and compare with the original state. For test machines, preserve the configuration’s purpose so it still reproduces the intended device class afterward. Agreeing these checks with developers in advance is easier than reconstructing context before release.

## Set access and data boundaries

An external compute task does not require game source code, store accounts or confidential materials. Map directories and services that must stay outside the pilot environment. Assign responsibility for change approval.

If using containers, check permissions and resource limits. [Docker describes CPU and memory management](https://docs.docker.com/engine/containers/resource_constraints/), but specific limits must be set and verified. Application packaging alone does not describe whole-machine security.

## Assess a defined fleet segment

Start with one post-project node before deciding on another stage.

This uses existing equipment without rushing to rebuild infrastructure. For regular overnight intervals, see [workstation scheduling](/journal/studio-workstations-night/); between projects, see [seasonally available capacity](/journal/seasonal-gpu-capacity/).