Store on Wasabi, Train on Vultr: A Faster Path to AI at Scale

Most AI teams don't overspend on GPUs. They overspend moving data around them.

A training run doesn't touch its dataset once and move on. It works through the same data again and again, saving progress along the way and checking its own results as it goes. While this is normal for training workloads, some storage providers charge for every one of those touches, every request, every byte out, so normal training activity turns into a running tab.

That cost tends to show up all at once, when a run finishes and the storage charge sitting next to the compute charge is bigger than anyone expected. From there, teams start trimming checkpoints, shrinking eval sets, and cutting runs short just to keep the bill in line.

A 2026 IDC study on the AI-driven data economy found that nearly 95% of organizations surveyed are storing more data because of AI and generative AI adoption. As those volumes grow, so does the number of times that data gets touched, and the bill that comes with it.

That's the idea behind Wasabi's addition to the Vultr Cloud Alliance: run training on Vultr while keeping data in Wasabi, with each side scaling independently as the work demands it, so storage costs track what you actually store, not how often you touch it.

The reread tax and other considerations

While AI teams focus on GPUs and getting their models right, a data-intensive process runs alongside that compute. Traditional applications use caching to limit repeated storage access; a web app reads a file once and keeps a copy on hand instead of going back for it again. AI training works differently: it involves multiple epochs, or full passes through the same dataset, with checkpoints (snapshots of the model's progress) written and read back in along the way, and outputs pulled back out during evaluation to check how the model's doing. Over a project's life, that's the same data read, written, and reread thousands of times, and storage priced by the request and the byte charges for every one of those touches.

Cost isn't the only catch. High-throughput or latency-sensitive training also benefits from a direct, dedicated line between compute and storage, and most providers make teams wait weeks to set one up rather than offering it as something you can just turn on.

Swapping in a new storage layer shouldn't mean ripping out what's already working, either. Positioning object storage as a wholesale replacement for existing infrastructure, rather than an additional choice, creates unnecessary migration risk, which is why Wasabi's addition to the Vultr Cloud Alliance is explicit that it complements Vultr's own object storage offering rather than replacing it.

Compute on Vultr, data in Wasabi

Good training storage checks a short list of boxes: it holds data durably in a format every framework can already reach, it doesn't let fees stack up as epochs and evaluation runs accumulate, it offers a private connection for workloads that need it without forcing one on workloads that don't, and it lets more GPU capacity or more data get added without forcing a storage migration or a compute vendor change.

One way to meet those requirements is to decouple storage from compute, so you can scale each according to its own performance, capacity, and cost requirements. AI training and inference run on Vultr Cloud GPU, Cloud Compute, Bare Metal, or Vultr Kubernetes Engine (VKE), while Wasabi Hot Cloud Storage provides an S3-compatible object storage target for datasets, checkpoints, model artifacts, and outputs.

Standard internet connectivity is available by default, but when a workload needs a private path, Wasabi Direct Connect gives you a dedicated or hosted connection straight into a Wasabi storage region from Vultr’s data centers. Either way, you can read, write, and reread data with no egress or API request fees. That means repeated access to your data doesn’t pile up charges as training runs expand.

Beyond AI: The same model, more workloads

AI is where this pays off fastest, but the underlying idea holds for any workload where compute and storage don’t need to scale in lockstep.

• Backup and disaster recovery: Run production or recovery infrastructure on Vultr while Wasabi holds S3-compatible backup storage, separate from the compute it protects.

• Long-term retention: Keep archives in Wasabi and spin up Vultr compute only when that data needs processing.

• Multicloud: Add Vultr to an existing multicloud architecture without duplicating or migrating the data already sitting in Wasabi.

• Media and content: Run processing and delivery workloads on Vultr while Wasabi holds the underlying media library, and let each side scale on its own.

Keeping AI at scale and on budget
The fastest path to AI at scale moves beyond GPUs to an architecture where storage is no longer something teams have to work around, scaling independently from compute instead of taxing every read, write, and reread along the way.

With Wasabi now part of the Vultr Cloud Alliance, that's a conversation worth having before the next training run starts. Talk to a Vultr or Wasabi rep about connecting Vultr Cloud GPU to a Wasabi bucket, and see what it does to the bill.

Want to see this new alliance in action? Visit https://wasabi.com/partner/integrations/vultr to learn more.