Use case · AI & GPU compute
Machine learning pipelines
A machine-learning pipeline is the end-to-end workflow that turns data into a deployed model and keeps it current — ingestion, processing, training, deployment, and monitoring. It needs mixed compute (CPU for data, GPU for training), orchestration to coordinate the stages, and storage for data flowing between them. EU hosting keeps the whole pipeline's data sovereign.
Key points
- A pipeline is the end-to-end workflow from raw data to a deployed, monitored model.
- Its stages need different resources — CPU-heavy data processing, GPU training, serving for inference.
- Orchestration coordinates the stages, running them in order and on schedule.
- Data flows between stages, so storage and data movement are part of the infrastructure.
- The whole pipeline handles the data, so EU hosting keeps all of it under European jurisdiction.
What is a machine-learning pipeline?
A machine-learning pipeline is the end-to-end workflow that takes raw data and turns it into a deployed model, then keeps that model current over time. Rather than training being a one-off act, real machine-learning work is a sequence of stages — bringing in data, preparing it, training a model, validating it, deploying it, and monitoring it in production — that together form a pipeline from data to working model. Framing the work as a pipeline captures that these stages connect: the output of one feeds the next, and the whole flow, not any single step, is what produces and maintains a useful model.
Hosting a machine-learning pipeline therefore means supporting this whole workflow, which is more varied than any single stage. The pipeline spans data-heavy processing, compute-heavy training, production serving, and ongoing monitoring, each with different demands, and it needs something to coordinate these stages into a coherent flow. Infrastructure for an ML pipeline has to provide for all of this — the varied compute, the storage for data moving between stages, and the orchestration that runs the stages in order. This makes pipeline infrastructure broader than infrastructure for training or inference alone, since it must serve the entire path from data to deployed, maintained model.
The stages of an ML pipeline
A typical machine-learning pipeline moves through several stages. It begins with data ingestion — bringing in the raw data the model will learn from, from whatever sources hold it. Then comes data processing and preparation — cleaning the data, transforming it, and engineering the features the model will use — which turns raw data into a form suitable for training. Next is training, where the model learns from the prepared data, followed by validation, where the trained model is evaluated to confirm it performs acceptably. Then the model is deployed to serve predictions in production, and finally it is monitored to watch its performance over time.
These stages form a logical sequence, each depending on the one before, and each with its own character. Ingestion and processing are largely about handling data — often substantial amounts, often on CPUs. Training is the compute-intensive stage that typically uses GPUs. Deployment and serving are about running the model reliably for users. Monitoring is ongoing, watching for problems that call for intervention. Understanding these stages clarifies why a pipeline needs varied infrastructure: no single kind of resource serves all of them, and the pipeline as a whole draws on data handling, heavy compute, reliable serving, and continuous observation in turn.
Mixed compute: CPU for data, GPU for training, serving for inference
A defining feature of ML pipelines is that different stages need different compute, so a pipeline uses a mix of resources rather than one kind. The data ingestion and processing stages are often CPU-heavy: cleaning, transforming, and preparing large datasets is work that CPUs do, and it can be substantial, sometimes rivalling training in the resources it consumes. Training is the GPU-intensive stage, where the model learns using the parallel compute GPUs provide. Serving the deployed model for inference is different again, needing whatever the model requires to respond in production, which may be GPU or CPU depending on the model.
This mix means pipeline infrastructure has to provide varied compute, matched to each stage, rather than assuming everything runs on GPUs. Provisioning only GPUs would waste them on CPU-bound data processing and leave the pipeline unbalanced; provisioning only CPUs would starve the training. A well-built pipeline pairs CPU capacity for the data-heavy stages with GPU capacity for training and appropriate serving capacity for inference, so each stage runs on suitable resources. When we host ML-pipeline infrastructure, this mix is part of the design — sizing CPU and GPU resources to the stages that need them, so no stage is bottlenecked and no expensive resource is wasted on work it is not suited to.
Orchestration: coordinating the pipeline
Because a pipeline is a sequence of connected stages, something must coordinate them — running each stage in the right order, at the right time, passing outputs along, and handling dependencies and failures. This is orchestration, and it is what turns a set of separate stages into a running pipeline. Orchestration schedules the stages, ensures each runs when its inputs are ready, and manages the flow so the pipeline executes coherently from data to deployed model, whether run on demand or on a schedule. Without orchestration, the stages would have to be run and connected manually, which does not scale and is error-prone.
Orchestration is therefore a real part of ML-pipeline infrastructure, sitting above the compute and storage to drive the workflow. The orchestration itself runs on infrastructure and coordinates work across the compute resources the stages use, so it needs a place to run and the ability to direct the pipeline's execution. Tools exist to define and run such pipelines, but they need infrastructure beneath them to execute on. When we host pipeline infrastructure, providing for the orchestration — the coordination layer that runs the stages — is part of supporting the pipeline as a whole, since the pipeline is defined as much by how its stages are coordinated as by the stages themselves.
Data storage and movement through the pipeline
Data flows through an ML pipeline from stage to stage — raw data in, processed data to training, trained models to deployment, and predictions and monitoring data out — so storage and data movement are integral to the infrastructure. Each stage reads its inputs and writes its outputs, which the next stage consumes, and all of this data needs somewhere to live and a path to move along. The volumes can be large: raw and processed datasets, model artefacts, and the data generated in production all have to be stored and made available where the stages that need them run.
Providing for this means storage sized and placed for the pipeline's data flow. Fast storage matters where it feeds compute-intensive stages, such as delivering data to training without bottlenecking the GPUs; capacity matters for holding the datasets, models, and results the pipeline accumulates; and the storage has to be accessible to the stages across the pipeline. Underprovisioning storage or data movement bottlenecks the pipeline, leaving compute waiting on data. A well-designed pipeline treats storage and data movement as first-class parts of the system, sized to the data flowing through, which we account for when specifying pipeline infrastructure rather than treating storage as secondary to compute.
Reproducibility and versioning
Machine-learning work needs to be reproducible — able to be repeated and understood — which in a pipeline means tracking the versions of data, code, models, and experiments as they flow through. A model results from particular data, particular processing, and particular training, and being able to reproduce or account for a model requires knowing which versions of each produced it. Without this tracking, it becomes hard to reproduce results, understand why a model behaves as it does, or roll back to a previous version, all of which matter for developing and operating models responsibly.
Supporting reproducibility means the infrastructure and practices around a pipeline keep track of these versions — of the datasets used, the code and configuration, and the resulting models — so that any model can be traced to what produced it and results can be reproduced. Reproducible environments, such as containerised stages, help ensure that a stage run again behaves the same, and versioned storage of data and models preserves what each pipeline run used and produced. This versioning and reproducibility is part of running an ML pipeline well, and the infrastructure should support it, so that the pipeline produces models that can be understood, reproduced, and managed over their life, rather than opaque artefacts.
Continuous pipelines: monitoring and retraining
Many ML pipelines are not run once but continuously, because deployed models degrade over time as the world changes and the data they see drifts from the data they were trained on. Monitoring a deployed model watches for this — tracking its performance and the data it receives to detect when it is no longer performing well — and when degradation is found, the pipeline is run again to retrain the model on newer data and redeploy it. This makes the pipeline a loop rather than a one-way flow: deploy, monitor, retrain, redeploy, keeping the model current as conditions change.
Supporting this continuous operation adds requirements to pipeline infrastructure. Monitoring needs to run continuously against the deployed model, collecting and assessing performance and data; retraining needs the compute of the training stage available when triggered; and the orchestration must be able to run the pipeline again as needed, on a schedule or in response to monitoring. The infrastructure therefore supports not a single pass but an ongoing cycle, with the resources for monitoring, retraining, and redeployment available over time. When we host pipeline infrastructure, provisioning for this continuous loop — the monitoring and periodic retraining that keep models current — is part of supporting real, production ML work, which is rarely a one-time effort.
Bare metal, cloud, and sovereignty for pipelines
For ML pipelines, the choice between dedicated and on-demand infrastructure applies across the mixed resources the pipeline uses. Ongoing pipelines with steady work — regular retraining, continuous monitoring, production serving, and steady development — keep their resources busy enough that dedicated infrastructure at a fixed cost is usually economical, across both the CPU-heavy and GPU-heavy stages. Pipelines that run only occasionally, or have very spiky resource needs, can suit on-demand capacity for the variable parts. A continuously operating pipeline is often sustained enough that dedicated infrastructure forms the economical core, with on-demand capacity for bursts.
Sovereignty applies with particular force to pipelines, because the whole pipeline handles the data. Data flows through every stage — ingestion, processing, training, serving, monitoring — so the pipeline touches the data comprehensively, and where the pipeline runs governs all of that data. VV Internet Hosting is incorporated in the Netherlands, within the EU, so a pipeline hosted with us runs under European jurisdiction and outside the direct reach of the US CLOUD Act. For pipelines handling personal, sensitive, or regulated data — which many do, given that the data passes through every stage — keeping the whole pipeline in the EU keeps all of that data under European law, rather than exposing it at any stage to foreign legal access. Because the pipeline handles the data end to end, its sovereignty is the sovereignty of the entire data flow.
Where VV Internet Hosting fits — and where it does not
We host dedicated infrastructure for machine-learning pipelines end to end: CPU capacity for data ingestion and processing, GPU servers for training, serving capacity for inference, storage sized for the data flowing between stages, and a place for the orchestration that coordinates it all — in EU datacenters under European jurisdiction. This suits teams running continuous, production ML pipelines, where the mix of sustained resources is economical on dedicated hardware and where the data passing through the whole pipeline makes European sovereignty matter. For that, we are a strong fit, and we will size each part of the pipeline to its role.
We are candid about our limits. Pipelines that run only rarely, or have highly variable resource needs, may be better served by on-demand capacity for the variable stages, and we will say so. If you need a hyperscaler's fully managed ML-pipeline platforms and their proprietary orchestration and tooling ecosystem, that is a different kind of provider than we are. We provide the dedicated, sovereignty-aware infrastructure on which you run your pipeline and its tools, on hardware you control — which suits teams that want that control and European data sovereignty for their whole pipeline, and is not the right choice for those wanting a fully managed platform. If our model matches your needs, we can host the pipeline well; if not, we will point you toward what fits.
Related use cases
See also
Questions
ML pipelines, answered plainly
Common questions about hosting for ML pipelines.
What are the stages of a machine-learning pipeline?
Typically data ingestion (bringing in raw data), processing and preparation (cleaning, transforming, feature engineering), training (the model learns from prepared data), validation (evaluating the trained model), deployment (serving predictions in production), and monitoring (watching performance over time). Each depends on the one before, forming a sequence from data to deployed, maintained model.
Why does an ML pipeline need mixed compute?
Different stages need different resources. Data ingestion and processing are often CPU-heavy — cleaning and transforming large datasets. Training is GPU-intensive. Serving the deployed model needs whatever it requires to respond in production. A well-built pipeline pairs CPU capacity for data-heavy stages with GPU capacity for training, so no stage is bottlenecked and no resource wasted.
Why does sovereignty matter especially for pipelines?
Because the whole pipeline handles the data — it flows through ingestion, processing, training, serving, and monitoring, so the pipeline touches the data comprehensively. Where the pipeline runs governs all of that data. Hosting the entire pipeline in the EU keeps every stage's data under European jurisdiction, outside the direct reach of the US CLOUD Act, rather than exposing it at any stage.
Planning ML pipelines infrastructure?
We host dedicated, EU-sovereign infrastructure sized to your workload — and we will tell you plainly when something else fits better. Tell us what you're building.