GPU Deployments

Hubfly GPU Deployments let you provision accelerated compute for AI workloads without managing a separate GPU server workflow by hand. You can search available GPU offers, choose disk size, select a notebook-ready or SSH-capable template, launch the instance, open the Jupyter endpoint when available, monitor runtime state, stream logs, copy data between GPU instances, and control billing from a dedicated GPU wallet.

Use this guide when you need GPU infrastructure for Jupyter notebooks, machine learning experimentation, model inference, AI tooling, data processing, CUDA workloads, prototype training jobs, or project-bound accelerated compute.

What GPU Deployments provide

Common use cases

GPU Deployments are designed for workloads where CPU containers are not enough.

Good fits include:

• Jupyter notebooks for data science and ML experimentation
• GPU-backed Python environments for PyTorch, TensorFlow, CUDA, and notebook workflows
• Inference servers for models that need GPU acceleration
• LLM tooling, vector workflows, and AI application prototyping
• Batch jobs that need short-lived GPU capacity
• Model testing, benchmark runs, and temporary research environments
• Project-specific AI tools that should appear in the same project as the app they support

Use normal Hubfly containers for web apps, APIs, workers, databases, queues, and services that do not need GPU acceleration. Use GPU Deployments when the workload depends on CUDA, high VRAM, GPU compute, or notebook-ready accelerated environments.

How GPU provisioning works

GPU provisioning is a two-step workflow:

1. Choose a GPU offer and disk size.
2. Choose a GPU template and provision the instance.

During provisioning, Hubfly records the selected offer, template, disk size, binding scope, runtime type, provider instance ID, resources, networking, hourly rate, and synchronization status.

A typical workflow looks like this:

1. Open the project.
2. Open the AI GPUs panel.
3. Click Add GPU.
4. Choose whether to bind the GPU to the project.
5. Sort offers by price if needed.
6. Review GPU model, GPU count, TFLOPS, VRAM, CPU RAM, CPU cores, disk, region, and hourly rate.
7. Enter the disk size to provision.
8. Choose a template.
9. Review any disk recommendation warning.
10. Provision the GPU.
11. Open the GPU details page after the instance appears.
12. Use the Jupyter endpoint, logs, cost view, and lifecycle actions as needed.

Requirements

GPU provisioning requires:

Lifecycle actions such as start, stop, and destroy require container control permissions. Binding changes require update permission.

GPU wallet and billing

GPU Deployments use a dedicated GPU wallet, separate from normal container billing. The GPU wallet is required before provisioning.

Important billing behavior:

• GPU offers show an hourly billable price in the UI.
• GPU detail pages show hourly rate, currency, and a monthly estimate based on 720 hours per month.
• GPU wallet balance is monitored separately from normal project container spend.
• If the GPU wallet is empty, provisioning is blocked.
• If the wallet reaches zero or below, running GPU instances can be stopped automatically to prevent continued spend.
• Low balance warnings are generated around $1.50 and $1.00 wallet thresholds.
• Destroying an instance stops the remote GPU and finalizes pending usage records.

GPU offers

GPU offers represent live rentable GPU capacity. Hubfly searches verified, rentable, on-demand offers and displays the normalized hardware details.

Each offer can include:

Offers are loaded in pages. The UI initially loads a smaller batch and can hydrate more offers in the background. You can refresh offers when availability changes.

Choosing the right GPU offer

Choose the offer based on the bottleneck in your workload:

Avoid choosing the cheapest offer blindly. A very low-cost GPU with too little VRAM or disk can fail later, waste setup time, or require a rebuild.

Disk sizing

GPU disk must be at least 10 GB and cannot exceed the offer’s disk limit.

Hubfly asks for the disk size before template selection because the disk becomes part of the instance provisioning request. The UI defaults to a conservative size when the offer has enough disk capacity and warns when a template recommends more disk than you selected.

Use these rough starting points:

Disk under-sizing is one of the most common GPU workflow problems. Account for package caches, downloaded model weights, notebooks, generated artifacts, logs, and dataset staging.

GPU templates

GPU templates define the environment installed on the instance. Templates can include Jupyter support, SSH support, direct SSH behavior, base images, recommended disk size, and usage popularity.

Template cards show:

• Template name
• Template image
• Recommended disk size
• Jupyter badge when direct Jupyter support is available
• SSH Direct badge when direct SSH is available
• SSH badge when SSH is used

Hubfly searches recommended templates and sorts normalized templates by usage count, so common templates appear higher. You can search templates by name, image, or hash ID.

Choosing a template

Choose templates based on the way users will access the GPU:

If the selected disk is below the template recommendation, Hubfly warns you. You can still proceed, but the workload may run out of disk during package installation, model download, dataset preparation, or notebook execution.

Project-bound vs global GPUs

When provisioning a GPU, you choose whether to bind it to the current project.

You can rebind a GPU later from the details page when the instance is not deleted or deleting. This lets you start globally for experimentation, then bind to a project when the workload becomes part of a product or team environment.

Runtime states

GPU instances can move through several runtime states.

The project GPU panel auto-syncs visible instances while the page is open. Detail pages also expose status, last synced time, and provider metadata.

Lifecycle actions

GPU detail pages support:

Destroy is the strongest cleanup action. Use it when you are done with a GPU and do not need the remote instance anymore.

Jupyter access

Jupyter access appears when the template and provider networking expose the required notebook port and token. Hubfly builds the Jupyter endpoint from the public IP, mapped host port for 8080/tcp, and the Jupyter token.

The GPU details page shows:

• Jupyter endpoint when available
• Pending state while port mapping is not ready
• Copy button for the endpoint
• Public reachability state

If the Jupyter endpoint is pending, wait for provisioning and sync to complete. If it remains unavailable, verify that the selected template supports Jupyter direct access and inspect logs for startup errors.

Networking considerations

GPU Deployments are exposed differently from standard Hubfly HTTP endpoints. The GPU detail page focuses on provider-level reachability such as public IP, mapped ports, SSH host/port, and Jupyter URL.

Keep these points in mind:

• Jupyter URLs may include an access token. Treat them as sensitive.
• Do not share notebook links publicly.
• Prefer project-bound scope for GPUs that support a specific product, service, or environment.
• Use normal Hubfly networking, load balancers, and Firewall docs for standard app ingress patterns.
• Keep production application frontends in normal containers unless the service must run directly on GPU compute.

Logs and monitoring

GPU detail pages include live logs. Hubfly requests recent provider logs, tails up to recent output, and refreshes while streaming is enabled.

The logs view supports:

• Live polling
• Pause and resume
• Clear local view
• Log levels such as info, warn, error, and debug
• Recent daemon/container logs

Use logs to diagnose:

• Template startup failures
• Jupyter not starting
• Package installation failures
• CUDA/runtime import errors
• Application crashes
• Missing model files or disk problems

For production GPU services, pair logs with application-level health checks, model warmup checks, request metrics, and cost monitoring.

Data copy between GPU instances

Hubfly supports direct data copy between GPU instances owned by the same account. This is useful when replacing hardware, moving experiments, or creating a new instance from work produced on another GPU.

Important behavior:

• Source and destination must be different instances.
• The destination must be stopped or paused before copying.
• Docker-style instances default to copying /workspace/.
• VM-style transfers copy from / to /.
• The copy workflow can be cancelled for the destination instance.
• The UI shows copy progress for the active copy window.

Use data copy for:

• Moving notebooks and artifacts to a newer GPU
• Migrating from a cheaper test GPU to a stronger inference GPU
• Preserving experiment output before destroying an old instance
• Rebuilding an environment with a better template while keeping work files

Do not rely on copy as your only backup strategy for critical datasets or model artifacts. Store important artifacts in durable object storage or versioned storage outside the temporary GPU instance lifecycle.

CI/CD and automation considerations

GPU Deployments are best for interactive and operational GPU workflows from the dashboard today. For CI/CD pipelines, use GPUs intentionally:

• Keep model build and packaging steps reproducible in Git.
• Store model weights and datasets outside the notebook when they need to survive rebuilds.
• Use project-bound GPUs for workloads tied to a deployable app.
• Use global GPUs for research capacity that moves between projects.
• Stop or destroy temporary GPUs at the end of experiments.
• Document template, disk size, GPU model, and package versions used for reproducibility.

For production inference, keep the deployment artifact reproducible. A notebook should be treated as experimentation unless the runtime, model files, dependencies, and startup commands are intentionally managed.

Docker and containerization notes

GPU templates behave like prebuilt runtime environments. Treat them like container images from an operational perspective:

• Know what base image and CUDA runtime the template uses.
• Match framework versions to the GPU/CUDA environment.
• Keep dependencies pinned for repeatability.
• Avoid manual snowflake setup that cannot be reproduced later.
• Export notebooks, requirements, model configuration, and startup scripts into Git when the work becomes important.

If a workload does not require GPU hardware after development, move the production app back to a standard Hubfly container for cheaper and simpler operation.

Security best practices

Follow these practices for GPU workloads:

• Treat Jupyter tokens and notebook URLs as secrets.
• Do not paste production credentials directly into notebooks.
• Store API keys and model registry tokens securely.
• Avoid exposing notebooks to untrusted users.
• Stop or destroy GPUs when experiments end.
• Keep dependencies patched, especially notebook servers and ML tooling.
• Use project binding when team ownership and project visibility matter.
• Avoid downloading untrusted model files or running unknown notebooks on shared workloads.
• Review logs and provider snapshots when debugging suspicious behavior.

Performance notes

GPU performance depends on more than the GPU name.

Evaluate:

• VRAM for model size and batch size
• GPU count for parallel workloads
• CPU cores and CPU RAM for preprocessing
• Disk capacity for datasets and checkpoints
• Region for user or data locality
• Template compatibility with CUDA and framework versions
• Startup time for large environments and model downloads

For inference workloads, measure cold start, model load time, steady-state latency, throughput, GPU memory usage, CPU saturation, and disk I/O. For notebook workflows, monitor disk growth and package cache size.

Production recommendations

For production GPU usage:

1. Choose a template that matches the runtime you can reproduce.
2. Use enough disk for model weights, dependencies, logs, and artifacts.
3. Keep the GPU wallet funded above low-balance thresholds.
4. Bind production GPUs to the project that owns the workload.
5. Keep important code and configuration in Git.
6. Store datasets and model artifacts outside the GPU instance lifecycle.
7. Use logs to verify startup and runtime behavior after every change.
8. Stop or destroy unused GPUs aggressively to control spend.
9. Avoid sharing Jupyter URLs outside trusted operators.
10. Treat notebooks as development surfaces unless hardened for production use.

Troubleshooting

FAQ

Are GPU Deployments the same as normal containers?

No. GPU Deployments use GPU offers, GPU templates, provider-backed GPU instances, a GPU wallet, and GPU-specific lifecycle controls. They can appear inside a project, but they are not the same as standard Hubfly app containers.

Can I run Jupyter notebooks?

Yes, when you choose a template with Jupyter support and the provider exposes the required port and token. The detail page shows the Jupyter endpoint when it is available.

What is the minimum disk size?

GPU provisioning requires at least 10 GB of disk, and the disk value cannot exceed the selected offer’s maximum disk.

What happens if my GPU wallet is empty?

Provisioning is blocked when the wallet is empty. If the wallet reaches zero or below while instances are running, Hubfly can stop running GPU instances and notify you.

Should I bind a GPU to a project?

Bind it when the GPU belongs to that project’s workload, team, billing context, or topology. Keep it global when it is shared research capacity or not tied to one project yet.

Can I move data between GPU instances?

Yes. Use the copy workflow. The destination must be stopped or paused before copying.

Can I destroy a GPU after copying data?

Yes. After confirming important files are copied or stored elsewhere, destroy the old GPU to stop active remote capacity and clean up spend.

Should production inference run from a notebook?

Usually no. Notebooks are excellent for experimentation, but production inference should use a reproducible runtime, pinned dependencies, predictable startup behavior, and clear operational ownership.

Related docs

• Platform
• Scaling
• Networking
• Firewall
• Templates