PortvMind Cloud
TREN
ContactSign up

Solution scenario

A reference architecture for AI and data workloads

A training window, a checkpoint volume and inference latency are not served by one resource. This page shows which PortvMind Cloud service each of the three layers maps onto and where the decision is made.

ContactAll solution scenarios
Primary decision
Accelerator profile and the length of the training window
Data layer
Datasets in object storage, checkpoints on block volumes
Setup
GPU model and quota are selected in the console

Overview

Which infrastructure decisions does an AI workload actually make?

In this scenario the decision is taken in three places. The first is the accelerator profile: model size, memory requirement and the length of the training window determine the GPU choice, and the resource is released once the window closes. The second is splitting the data layer — raw datasets and labels live in object storage, while checkpoints written during training stay on a block volume. The third is scaling inference independently of training: training is batched and scheduled, inference is continuous and per request. The data-layer split comes before the accelerator profile.

Typical workload profile

Training and inference do not carry the same load

Training runs in batches inside a scheduled window and wants throughput; inference answers requests all day and wants response time. Collecting both in one resource group leaves the accelerator idling once the window closes. That is why the profile is defined separately along the traffic pattern, data volume and latency axes.

Traffic pattern

A scheduled training window, uninterrupted inference

  • Batch job queue
  • Accelerator off outside the window
  • Per-request inference

Data volume

The dataset grows, checkpoints rotate

  • Raw data: object storage
  • Checkpoints: block volume
  • One model artefact per version

Latency and compliance

Throughput in training, response time in inference

  • Training: throughput oriented
  • Inference: response-time oriented
  • Data residency as a scenario requirement

The profile describes the traffic pattern, data volume and latency need.

Reference architecture

A linear training line with an inference path attached

The reference architecture is drawn as a one-way line: raw dataset, training pool, checkpoint volume and model artefact. The published artefact moves down to the inference path. The dashed arrow returning from the checkpoint to the training pool marks the retraining loop; without it the step that updates the model with new data stays invisible in the architecture.

Reference architecture for the training and inference pathsRaw data flows from object storage into the GPU training pool and on to the checkpoint volume on block storage. A dashed retraining loop returns from the checkpoint to the training pool. The lower inference path runs from the model artefact to the inference service and on to egress traffic; the application request connects to the inference service.Region located in TürkiyeRaw data and labelsObject StorageTraining poolGPU / AI ComputeCheckpoint volumeBlock StorageModel artefactObject StorageApplication requestCalling systemInference serviceGPU / AI ComputeEgress trafficNetwork Data Transferretraining loop
GPU model and quota are selected in the console.

PortvMind Cloud services used

Four services, four separate lifecycles

GPU / AI Compute covers training and inference, Object Storage the dataset and the model artefact, Block Storage the checkpoint volume, and Network Data Transfer the outbound response traffic. Each is started and stopped on its own; when the accelerator is stopped the data layer stays in place and the next training window begins with the same dataset.

  1. GPU / AI Compute

    The training pool and the inference service come from the same service with separate lifecycles.

  2. Object Storage

    Raw datasets, labels and the published model artefact live here.

  3. Block Storage

    A low-latency volume for the checkpoints written during training.

  4. Network Data Transfer

    Outbound inference responses and dataset transfers are accounted for here.

Each service page links back to this scenario; the link is generated from the same list in both directions. All Services

Evaluation criteria

Four questions answered before provisioning

The decision table covers accelerator availability, data-layer separation, independent inference scaling and data residency. The data-layer split comes before the accelerator profile. Quota and the cost estimate are in the console and the calculator.

CriterionQuestion askedAnswer in this scenario
Accelerator availabilityAre the required GPU model and quota available in the region?GPU models and quota are listed in the console. The options are H100, H200 and L40S.
Data layer separationAre the dataset and the checkpoints kept on the same volume?No — the dataset sits in object storage and the checkpoints on a block volume.
Inference scalingCan inference scale independently of training?Yes — the two workloads run in separate resource groups and stop separately.
Data residencyMust the training data stay in the location in Türkiye?The region is selected at setup as Istanbul (tr-ist-01) or Ankara (tr-ank-01). KVKK is treated among the organisation’s requirements.

Unit price and quota are in the calculator and the console.

Related guides and documentation

Reading on GPU selection and object storage

Accelerator selection is covered in the guides. Object storage and API access are set up step by step in the documentation.

Guides

  • How to Choose a GPU Server for an AI Workload

    Choosing a GPU server does not start with picking a model name; it starts with writing down what the workload does. Define whether it is training or inference, whether the model and working data fit into GPU memory, and how quickly the job must finish. Then narrow the GPU model against that definition and size CPU, RAM, storage and network at the same time: if the slowest link is not the GPU, a faster GPU will not change the outcome. Close the decision with a representative trial run on your own data.

  • GPU Workloads on Kubernetes: Time-Slicing, MIG and MPS

    Kubernetes advertises GPUs as extended node resources through a vendor device plugin and schedules them from Pod requests. Default full-GPU allocation offers strong separation but can underuse capacity for small inference or development jobs. Time-slicing shares GPU time without memory or fault isolation, MIG partitions a supported GPU into hardware-isolated instances, and MPS is a runtime service that improves concurrent execution for compatible CUDA processes. Close the choice with a representative workload measurement.

  • What Is a GPU Server? How to Choose One for Your Workload

    A GPU server is a server with one or more graphics processing units that accelerate parallel compute alongside the CPU and system memory. Choosing one requires more than comparing GPU models. Model and dataset size, GPU memory, numerical precision, software compatibility, CPU and RAM balance, storage throughput, networking and total runtime all shape the right configuration.

Other solution scenarios

  • SaaS and Startups

    Environment separation, release promotion and a persistent volume per tenant.

  • Finance

    An intraday transaction band, an end-of-day batch band and a retention period.

  • E-Commerce and Retail

    A campaign peak with a known date, an elastic pool and an egress budget.

Let us plan the training window and the data layer together.

Share your model size, dataset volume and inference expectations; in the architecture consultation we map the accelerator profile, the storage split and the retraining loop together.

ContactOpen console