Which Charges Can Continue After Your GPU Job Stops on Container, Bare-Metal, and Managed-Cluster Services?

A job finishing, a machine stopping, and a resource being deleted are three separate events, and the charges around a GPU run attach to resources rather than to the job. When a training script exits, the container, server, or cluster it ran on is not removed along with it, while attached resources such as a public IP, and any prepaid term, follow their own end dates. On GMI Cloud's GPU infrastructure, each deployment form has a defined end-of-life action: a pay-as-you-go container is terminated, a bare-metal server or a managed cluster (in early access) is deleted from its list, and an Elastic IP is released on its own. Cost control after a run is therefore a short, ordered teardown of whatever the next run will not use.

Container and bare-metal rows in the console open their orders through View Order, which shows the order number, billing method, status, and amount, and the Orders page under Billing and Usage keeps the full history. Teardown and reconciliation happen in the same place, which makes it practical to compare container, bare-metal, and managed-cluster costs on one account after the work is done, not only on the quote.

Three events in a resource's life

Only the actions in the "Resource removed" row take a resource off the account; stop, restart, and reboot leave it in place under its order.

Billing events on each deployment form

Containers: the plan decides when billing can end

A pay-as-you-go container runs without an end date, and its More actions menu terminates it whenever you choose. A job's exit does not terminate it, and the container stays on the account under its pay-as-you-go order until it is terminated. When nothing else is planned for that container, terminating it soon after the job exits closes the gap.

A prepaid container runs for its rental period, and terminating it early is not part of a prepaid plan. Its cost is fixed when the plan is bought, so the decision that matters comes at renewal. Renew Plan offers extensions from one day to three years and shows the new end time and price before payment; extend only when the next run is scheduled, and to the shortest period that covers it.

Reconfiguring a container permanently erases the data stored inside it. Copy outputs and checkpoints to persistent storage before any reconfigure or terminate step, so cleanup never forces a choice between keeping data and ending the charge.

Bare metal: stop and delete are different actions

The Bare Metals page offers Stop, Start, Reboot, and PowerCycle, plus delete. Stopping powers the server down while it stays provisioned to your organization under its order, ready to start again. Deleting removes the server from the account, so for a server the next run will not use, delete is the end-of-life action.

Managed clusters: nodes belong to the cluster

Ending a job does not by itself remove a managed cluster's worker nodes, which belong to the cluster rather than to the job. A pay-as-you-go cluster is charged by the minute with no upfront cost, so a cluster with no work planned for the weekend is one to delete on Friday. A prepaid cluster is billed for its term. The cluster list shows each cluster's billing method next to its node count and status.

Attached resources that keep their own meter

Elastic IPs

An Elastic IP is billed pay as you go, by the minute, from allocation until it is released, whether it is associated with an instance or not. Terminating a container does not release its Elastic IP, and disassociating an address returns it to the account in a Disassociated state, still allocated. Release is the step that ends billing for the address.

There are two paths to that step. While a container is still running, its networking comes off from the container's detail page in a fixed order: firewall first, then the Elastic IP. After a container has been terminated, open the Elastic IP page, disassociate the leftover address if it still shows as associated, and release it there. A released address goes back to the pool and is unlikely to come back on a new allocation, so release only addresses that no client or DNS record depends on.

Firewalls and VPCs

Firewalls are configuration objects scoped to one data center, and a firewall can be deleted only once no instance is associated with it. Deleting unused custom firewalls keeps the next teardown audit short and keeps an old rule set from being attached to a new instance by mistake.

Storage and network lines

The pricing page treats compute as the GPU price, with networking and storage set up per workload as separate items. Treat each storage volume or network resource configured for the workload as its own line in the teardown review, kept or removed on its own decision rather than by default with the GPU resource. An Elastic IP's bandwidth specification is chosen at allocation, together with the address.

A resource timeline for one finished job

The timeline below uses assumed times to show which resources are still on the account, with no prices attached. Assume a pay-as-you-go container with one Elastic IP and an external checkpoint volume:

1. Monday 09:00: container created and running. The Elastic IP was allocated last week, so its per-minute line is already running.
2. Monday 15:40: training job exits. The container and the address are both still on the account.
3. Monday 17:10: engineer copies the final checkpoint and terminates the container. The Elastic IP is not released with the container, so its line continues.
4. Tuesday 10:00: team decides the address is not needed for next week's run and releases it from the Elastic IP page. The IP line ends.
5. Ongoing: the checkpoint volume is kept on purpose because the next run needs it, and it appears in the teardown review as a deliberate keep.

Two gaps follow the job in this example: the container stayed up for 90 minutes after the exit, and the Elastic IP stayed allocated for 18 hours 20 minutes, from the exit to Tuesday's release, a span that includes those 90 minutes. Both shrink when teardown is part of the job script and the run plan names, in advance, which attached resources stay.

With the same job on a pay-as-you-go managed cluster, the timeline comes down to one decision: delete the cluster once no further work is planned for its nodes. On a prepaid cluster, the equivalent control is sizing the term to the planned work before buying it.

Teardown and reconciliation checklist

Run these steps in order after the last job of a run:

1. Save outputs. Copy results, logs, and checkpoints off any container before terminating or reconfiguring it. Download Logs is available from the container's actions menu.
2. Detach a running container's networking. For a container you are about to remove, disassociate the firewall first, then the Elastic IP, from its detail page.
3. Remove the compute resource. Terminate pay-as-you-go containers, delete bare-metal servers that the next run will not reuse, and delete managed clusters that no longer have scheduled work.
4. Release or keep each Elastic IP on purpose. On the Elastic IP page, keep an address only when a client or DNS record needs it for the next run; disassociate and release the rest.
5. Clean up configuration. Delete custom firewalls with no associated instances.
6. Close open orders. Pending orders under Billing and Usage can be continued or cancelled; cancel the ones that belong to abandoned launches.
7. Reconcile. Compare what is still listed on the Containers, Bare Metals, Managed GPU Clusters, and Elastic IP pages with the run plan. Each live resource should have scheduled work or a named reason to persist, each prepaid term should map to planned use, and the Orders history is the billing record to check them against.

FAQ

Can we keep the same public IP between weekly runs?

Keep the Elastic IP allocated and associate it with the next instance when the run starts. It stays billed by the minute while allocated, which is the cost of a stable address. The next instance has to be in the same data center as the address, because only instances in that data center appear as association targets.

When should a prepaid container be renewed?

Renew when the next run is on the calendar, and pick the shortest extension that covers it. Renewal can be done at any time while the container is running, and the Renew page shows the new end time and price before payment. Renewing before the current end time keeps the container running without interruption.

Build the teardown into the next order

When the next run is planned, decide up front which resources are per-run and which persist, and pick billing methods to match: pay as you go for per-run containers and clusters, prepaid or committed capacity for steady work. To set this up, sign in to the GMI Cloud console, or talk to our sales team about prepaid and committed terms sized to your schedule.