Scaling Projects
Turn a one-off test into a repeatable, longer run — without burning your wallet.
Start with a representative run
Before you commit a big training or inference job, run something short and real. It should exercise the image, the access method, your dependencies, and — if you care about it — the GPU. Then write down the tier, config, image, and billing plan that worked, so it's repeatable.
Plan capacity before a long run
- Size the config around the actual CPU, RAM, disk, and GPU you saw the short run need.
- Check the hourly rate and the billing-plan discount before you create it.
- Confirm GPU capacity with ANK when a deadline depends on a specific piece of hardware — don't gamble a launch date on availability.
- Keep your model data and checkpoints somewhere restorable. Deleting an instance takes them with it.
Scale out instead of up
When a workload parallelises, two instances are often better value than one large tier. The 2X tiers (Multi-Node Instances) give you two GPU instances on two hosts as a single request. They suit data-parallel training and distributed inference; they are not a substitute for one big GPU when a model must fit in a single memory space, and the 1 GbE member link can't carry tight tensor-parallel collectives.
What's not documented yet
Managed multi-instance orchestration, managed storage, and serverless workloads aren't here yet — multi-node tiers are two ordinary instances you orchestrate yourself. Treat managed clustering and serverless as coming soon, not as things you can build on. For a repeatable deployment workflow, peek at Developer Resources and loop in Support.