Verda joins GPU instances, clusters and serverless containers in one cloud

Verda brings several ways of running AI workloads into one GPU cloud: individual instances, multi-node clusters and serverless containers. The company previously operated as DataCrunch. Its current offer is most useful when a team needs to move between experimentation, training and deployment without pretending those workloads have identical storage, latency or billing requirements.

01 / ProductOne company identity, several execution models

Verda’s rebrand announcement describes the transition from DataCrunch to Verda as a change of name with the same company, team and platform. The announcement set the website transition for November 2025. Older DataCrunch references therefore belong to this company history rather than a separate competing provider.

The current platform overview groups GPU instances, clusters, serverless execution and supporting storage. An instance gives a team a machine-oriented environment. A cluster joins multiple nodes for coordinated work. A serverless deployment starts from an application container and lets the platform manage replicas. Choosing between them changes both the amount of infrastructure the customer operates and the way idle capacity affects the bill.

Verda presents itself as a European AI cloud. That positioning is relevant to teams evaluating where their workloads run, but it should lead to a service-specific location discussion. The region of the selected compute, data stores, backups and support access still needs to match the organization’s requirements. A European company identity alone cannot answer every data-residency question.

02 / AudienceFor teams whose AI application has more than one phase

A research group may want an interactive instance while developing a model, a cluster for a larger training run and a container endpoint for application traffic. Verda addresses those related needs through one platform. The potential benefit is continuity of tools and commercial relationship; the evaluation still needs to prove that artifacts and data move cleanly between the chosen services.

A useful customer profile is a team with its own model weights or GPU application, familiarity with containers and a reason to manage inference behavior. It might process a backlog of media, run scientific workloads or deploy a specialized model. A team using only a third-party model API should first establish why owning compute would improve quality, economics or control.

Operational ownership also matters. Someone must decide whether a slow response comes from loading weights, waiting for a replica, downloading an input or running the model itself. Without that distinction, adding GPUs can raise spending while leaving the user-facing delay unchanged. A small evaluation should therefore include the developer and the person responsible for the production service.

03 / WorkflowA proposed path from a media backlog to a live endpoint

Consider a team using its own model to classify a library of short videos, then offering the same classification for newly uploaded clips. This is an illustrative evaluation, not a measured Verda deployment. Begin with a versioned container, pinned model weights and a test set that includes unusual formats, empty clips and inputs near the application’s size limit.

Run the backlog as completion-based work with canonical inputs stored outside disposable compute. Each job should have a stable identifier, a recorded model version and an output location that survives the worker. Make retries idempotent: repeating a failed classification should not create duplicate records or charge a downstream customer twice. Compare accepted classifications per hour, including input transfer and failures, rather than just GPU utilization.

The serverless container product describes batch jobs and dedicated endpoint deployments, scaling behavior and monitoring. For the endpoint phase, measure the first request after an idle period separately from requests reaching a warm replica. A low average latency can conceal a cold-start delay that matters to a person waiting for a result.

Set a queue limit and decide what the application tells users while capacity is starting. If the workload needs a continuously warm replica, include that baseline in the budget. If it can scale to zero, check whether bursts are long enough to make the billing interval economical. These are workload design choices; the serverless label does not remove them.

For training that outgrows a node, Instant Clusters offers managed multi-node setup with Kubernetes-related scheduling and Slurm options. Start with a small distributed run before reserving a larger cluster. Verify that training resumes from a checkpoint and that data loading scales alongside the accelerators. An advertised rapid setup time is a vendor claim, not evidence that a particular customer’s data and dependencies are ready.

Use the shared filesystem when multiple compute resources need a common POSIX-accessible data path. Its persistence has a different purpose from an image registry or local scratch disk. Record which location contains the authoritative dataset, which is a cache and which holds retained outputs. That simple distinction makes cleanup and recovery less ambiguous.

04 / PricingThe same GPU name can carry a different service price

The public pricing page separates GPU instances from serverless configurations. The entries below are USD figures consulted on 23 September 2026. CPU, memory and deployment arrangements differ between services, so the H100 rows are not interchangeable quotations for an identical bundle.

The ten-minute interval is especially important for short serverless bursts. Estimate charges from replica lifetimes under the documented interval, not solely from the seconds that the model spends generating an answer. Loading, queue behavior and scaling decisions can change the number of intervals consumed. Test the intended request pattern before extrapolating from a long, continuously busy benchmark.

For a stable workload, compare a continuously allocated instance with the actual serverless pattern, including idle time and the engineering burden of running the instance. For training, compare the total time to a valid checkpoint. The cheapest displayed accelerator is not necessarily the lowest-cost configuration if it causes additional partitioning, slower execution or more operational work.

05 / DistinctionsThe connections between services are the real evaluation surface

Verda’s breadth makes it possible to ask how the same application behaves as the team changes execution models. That is more useful than treating every GPU service as an isolated price card. The container image, model artifact and dataset should have a clear route from development to deployment, with the customer retaining a reproducible description of that route.

The Runpod blueprint provides another perspective on GPU instances and serverless workloads. A practical comparison would keep the same model, input distribution, concurrency and recovery requirements. Changing all those variables at once would make an apparent cost difference difficult to interpret.

The Modal blueprint is useful when the team is also considering a more code-centered cloud execution workflow. The decision is partly about the development model: whether engineers prefer to package and operate a broader infrastructure environment or express execution through a more opinionated application interface. Neither approach removes the need to understand startup, persistence and resource consumption.

06 / QuestionsCheck persistence, interruption and location before expanding

Ask what survives each lifecycle action for the services you choose. Stopping an instance, completing a batch job, scaling an endpoint to zero and deleting a deployment are different events. The application should not depend on an undocumented assumption that all of them preserve local files. Restore a saved output from the intended persistent store before using the workflow for valuable data.

Confirm whether any discounted capacity can be interrupted and what signal the application receives. A batch job may tolerate a restart from an external checkpoint; a live request may require a queue, timeout and retry policy. The buyer should describe that tolerance explicitly instead of assuming a discounted offer behaves like dedicated capacity.

Public pricing is a snapshot and does not demonstrate available inventory in a desired region. Before a deadline-dependent run, establish the exact accelerator, supporting resources and reservation terms. For sensitive data, include the applicable service locations and access model in the review. These details are more consequential than a broad claim that all workloads can use the same cloud.

07 / DecisionChoose the service that matches the work’s lifetime