GPU Cloud

GPU Server Hosting Models: Dedicated Hardware, Managed Operations and Colocation Responsibilities

The GPU server hosting market sells one word for three different contracts:

  1. Dedicated GPU hosting: the buyer rents a physical server that the provider owns.
  2. GPU colocation: the buyer owns its servers and leases space, power and cooling for them.
  3. Provider-operated infrastructure: the provider's engineers run the GPU servers for the buyer, for an ongoing term or until the buyer's own staff take over.

Two factors separate these contracts most: who owns the hardware and who runs it day to day. Vendor labels such as single-GPU or multi-GPU don't show who answers for a failed fan at 3 a.m. or who pays for a dead GPU.

GPU Server Types by Form Factor

Vendors describe GPU servers by form factor, meaning the server's physical build. CloudMinister classifies them into five types:

  1. Single-GPU server: one GPU paired with a standard multi-core CPU, an entry-level configuration suited to small-scale deep learning experiments and prototyping.
  2. Multi-GPU server: two, four, eight or more GPUs in one chassis, delivering higher throughput for large model training and production-scale inference.
  3. Virtualized GPU server: a single physical server shared among multiple users or virtual machines, each receiving a dedicated slice of GPU resources.
  4. Cloud-based GPU server: on-demand GPU access without hardware ownership, billed per hour of use.
  5. Edge GPU server: GPU compute placed physically close to the data source to cut round-trip latency.

The three models below each give the buyer dedicated physical servers. Hourly cloud GPU rental gets its own comparison against colocation.

GPU Server Hosting Models Compared by Ownership and Operations

Place each hosting offer on those two axes, hardware owner and day-to-day operator, before comparing prices.

ResponsibilityDedicated GPU hostingGPU colocationProvider-operated infrastructure
Hardware ownerProviderBuyerBuyer under managed operations; passes to the buyer at handover in a build-and-transfer engagement
Day-to-day operationsBuyer, or the provider on a managed planBuyer, with facility technicians on request at some sitesProvider, for an ongoing term or until handover
Power, cooling, space and connectivityProviderColocation facilityWherever the buyer's hardware runs under managed operations; built by the provider in a build-and-transfer engagement
ContractRental of an exclusive physical serverLease of rack space, power, cooling and connectivityManaged operations service or build-and-transfer engagement
ExitThe rental ends and the buyer migrates its dataThe buyer de-racks and moves the hardwareManaged service ends with hardware and data still with the buyer; trained buyer staff take over at handover
Best fitSteady utilization without capital for hardwareOwned hardware without an in-house facilityA small or absent in-house GPU operations team

One fleet can mix models. A company can rent dedicated servers for one workload and colocate its own servers for another.

Model 1: Dedicated GPU Hosting

HostSailor defines the model as one buyer's exclusive access to a physical server. Other tenants don't share its CPU, RAM, storage, networking or installed GPUs. The buyer pays for the server around the clock, idle hours included.

On an unmanaged plan, the buyer runs the software:

  1. Drivers and operating system: bare metal plans give the buyer administrator-level control over the operating system, kernel and drivers, so the team installs the frameworks each workload needs.
  2. Scheduling: the buyer queues training and inference jobs across the GPUs.
  3. Monitoring: the buyer's staff watch GPU health and restart failed jobs.

Managed dedicated plans move part of that work to the provider. CloudMinister's managed GPU server plans, for example, cover OS updates, CUDA (NVIDIA's GPU programming platform) version management, security patching and monitoring.

Confirm two things in the contract: the tasks the plan covers and the buyer's access level. Dedicated rental suits workloads with steady, known utilization.

Size the GPU memory (VRAM) before signing the contract. CloudMinister estimates that a 70-billion-parameter language model needs roughly 140 GB of VRAM, spread across several GPUs.

Ask what the provider can upgrade during the contract. HostSailor notes that a model that fits today can need more VRAM after an increase in context length or traffic.

Model 2: GPU Colocation

Colocation splits responsibility two ways:

  1. Buyer: purchases and racks its own GPU servers.
  2. Facility: supplies the power, cooling, physical space and connectivity for those servers.

Check rack density before signing the lease. A GB200 NVL72 rack, which holds 72 NVIDIA GPUs, needs roughly **120 kW** of power, more than many traditional facilities can deliver per rack.

Some facilities sell on-site technician time, often called remote hands, for reboots and part replacements. Colocation fits a buyer that has capital for hardware, wants the hardware on its balance sheet, and has engineers to run the servers.

Model 3: Provider-Operated GPU Infrastructure

The third model hands day-to-day operations to the provider in two forms:

  1. Ongoing managed operations: the provider runs scheduling, monitoring and recovery on the buyer's hardware as a continuing service.
  2. Time-bounded transfer: the provider builds and runs the environment, then hands operations to the buyer's trained staff.

Zettabyte offers zWARE, its GPU cluster management software, as a managed service from its network operations center. zWARE schedules jobs, tracks GPU, network card and power health, and starts automated recovery when it detects a fault. The buyer keeps control of its hardware and data under the managed service.

For time-bounded transfer, Zettabyte's BOTT (build, operate, train, transfer) methodology runs in four phases:

  1. Strategic planning and design: the provider analyzes requirements and plans capacity for the expected workloads, power and cooling.
  2. Construction and deployment: the provider builds out the site, integrates the hardware and deploys the software stack.
  3. Operations and optimization: the provider monitors performance, maintains the systems and tunes them over time.
  4. Customer handover: the provider trains the buyer's staff and hands over documentation and standard operating procedures, so the buyer's team can take over the assets and operations.

BOTT fits an organization that plans to run its own GPU infrastructure and needs time to build the team.

How to Choose a GPU Server Hosting Model

Four checks point a buyer to one model:

  1. Utilization pattern: steady, high utilization justifies paying for dedicated hardware or colocation space. HostSailor recommends calculating break-even from your own monthly GPU hours, storage and transfer costs. Test a vendor's quoted break-even percentage against those numbers with a worked break-even comparison between colocation and cloud rental.
  2. In-house GPU operations staff: colocated hardware suits a team that handles drivers, the network between GPUs, monitoring and recovery itself. A team without those skills needs a managed operations contract or a BOTT engagement with a training plan.
  3. Capital for hardware: owning hardware takes capital up front. Dedicated rental leaves the hardware purchase with the provider.
  4. Rack power density: colocation requires a facility that can power and cool high-density GPU racks at the planned rack count. Dedicated hosting leaves facility sizing to the provider.