You can rent a GPU server in under 60 seconds when the provider has ready capacity, a prebuilt image, and an automated control plane. The actual work is not typing an SSH command. It is choosing a configuration that fits, securing access, and making sure billing stops when the job finishes.
This guide shows the fastest path from an empty dashboard to a dedicated RTX 3090 server on BHK Cloud. It also covers the checks that prevent out-of-memory errors, exposed ports, lost checkpoints, and idle charges.
Open the GPU server rental page, select an RTX 3090 image, launch the node, copy the generated SSH command, and connect when the health indicator turns ready. BHK Cloud states that most prebuilt nodes provision in under 60 seconds.
Before You Rent a GPU Server
Spend one minute on sizing before starting the timer. The default BHK Cloud node includes a dedicated RTX 3090 with 24 GB GDDR6X, but VRAM requirements vary with model size, precision, context length, batch size, activations, and framework overhead.
A practical preflight checklist is:
- Confirm that the workload supports CUDA.
- Estimate peak VRAM and leave at least 10% headroom.
- Decide whether you need PyTorch, TensorFlow, JAX, or a custom container.
- Put datasets and checkpoints in durable storage.
- Create an SSH key instead of planning to use a password.
- Know the command that proves the GPU is visible.
- Decide how and when the node will terminate.
For common inference, LoRA or QLoRA fine-tuning, computer vision, image generation, and rendering pipelines, 24 GB is a useful starting point. A large unquantized model, long-context service, full-parameter training job, or FP64-heavy scientific application may need an A100-class accelerator instead. See our GPU cloud computing guide for sizing principles.
Step 1: Open the GPU Rental Page
Go to ai.bhkcloud.com/rent-gpu-server.html. The page lists the current RTX 3090 offer, region, memory, and hourly rate. At publication, BHK Cloud lists dedicated RTX 3090 compute in Frankfurt from $0.15 per GPU hour, with no minimum commitment.
Check availability and current terms before launch. Hourly rates, capacity, and included resources can change. If the workload must run in a specific jurisdiction, verify the selected region rather than inferring location from the marketing page.
Step 2: Sign In and Create Access Credentials
Open the BHK Cloud dashboard and authenticate. Create an API key only if you plan to automate launches; the dashboard flow is enough for a one-off server. Treat generated credentials as secrets:
- store them in a password manager or secret store;
- do not paste them into a public repository;
- do not bake them into a container image;
- scope and rotate them when the platform supports it;
- revoke credentials that are no longer used.
For shell access, upload your public SSH key. A public key normally ends in a comment such as a device name, while the private key remains on your own computer. Never upload the private key.
If you do not have a key, generate an Ed25519 key locally:
ssh-keygen -t ed25519 -C "gpu-access"
On Windows PowerShell, the same OpenSSH command works when the built-in OpenSSH Client feature is installed.
Step 3: Choose the RTX 3090 Configuration
Select a single RTX 3090 node for the first run. It provides 24 GB VRAM and 10,496 CUDA cores. Starting with one GPU keeps the test inexpensive and exposes memory or data-pipeline problems before multi-GPU complexity is added.
Choose a prebuilt image that matches the framework. A PyTorch image should already contain a compatible NVIDIA driver interface, CUDA runtime, cuDNN, Python, and common libraries. Use a custom Docker image when exact dependencies matter, but remember that pulling a large uncached image can extend startup time beyond the infrastructure provisioning target.
Review CPU, RAM, local disk, and network settings. The GPU is only one part of the server. Text tokenization, media decoding, augmentation, and data loading can bottleneck an otherwise fast accelerator.
Four 24 GB cards do not automatically behave like one 96 GB GPU. Multi-GPU jobs require model or data parallelism, and scaling depends on software and interconnect topology. Validate on one card before requesting a larger profile.
Step 4: Attach Storage Before Launch
Ephemeral local storage can disappear when a node is terminated. Put source datasets, model weights, and important checkpoints in durable object storage or a persistent volume.
BHK Cloud offers S3-compatible storage on the same platform. An S3-compatible bucket is useful because SDKs and tools can access it by changing the endpoint while keeping familiar APIs. Co-locating storage and compute also avoids repeatedly transferring large datasets across providers.
A clean directory plan is:
s3://project-name/datasets/
s3://project-name/checkpoints/
s3://project-name/outputs/
/local-nvme/cache/
Use local NVMe for disposable caches and unpacked shards. Sync outputs and checkpoints back to the bucket during the job, not only at the end.
Step 5: Launch the GPU Node
Click the launch control after reviewing the hourly price and configuration. The platform allocates the accelerator, attaches resources, boots the image, applies network policy, and runs a health check. With a cached prebuilt image and available capacity, BHK Cloud targets a ready state in under 60 seconds.
The timer should stop when the node is actually usable, not when the button returns. Wait until the dashboard reports ready and provides the public or private endpoint.
Automation users can follow the command pattern documented by the BHK Cloud GPU page:
export BHK_API_KEY="your-key-from-the-dashboard"
bhk gpu launch --type rtx3090
Command names and flags can evolve, so use the current dashboard or product documentation as the source of truth. Do not place the real key in shell history on a shared machine.
Step 6: Connect Over SSH
Use the connection string shown by the dashboard. It will resemble:
ssh -i ~/.ssh/id_ed25519 USER@SERVER_ADDRESS
The username, address, and port must come from the allocated instance. Confirm the host-key fingerprint on first connection. If a host key unexpectedly changes for an existing server, investigate rather than bypassing the warning.
Once connected, verify the accelerator:
nvidia-smi
python -c "import torch; print(torch.cuda.get_device_name(0)); print(torch.cuda.is_available())"
nvidia-smi should list an RTX 3090 and approximately 24 GB of memory. PyTorch should return True for CUDA availability. If the framework cannot see the GPU while nvidia-smi can, the image likely has a CUDA, container-runtime, or Python environment mismatch.
Step 7: Run a 60-Second Smoke Test
Do not begin a 20-hour training run immediately. Run a short test that loads the real model, reads a sample from the real storage path, and performs one inference or training step.
Record:
- peak allocated VRAM;
- GPU utilization;
- samples or tokens per second;
- data-loading time;
- output correctness;
- checkpoint upload success.
A synthetic matrix benchmark proves that CUDA works, but it does not validate the application. The most useful smoke test exercises model loading, preprocessing, GPU execution, and durable output together.
If the job fails with CUDA out of memory, reduce batch size, context length, resolution, or precision. For training, consider gradient checkpointing or accumulation. For inference, consider quantization and lower concurrency. If the model still cannot fit safely, move to a larger-memory GPU rather than operating at the limit.
Step 8: Secure the Running Server
Only expose ports that the workload requires. A notebook, inference API, or monitoring endpoint should not listen publicly without authentication and transport encryption. Prefer SSH tunneling, a private network, or an authenticated reverse proxy.
Keep package changes reproducible. Instead of manually installing dependencies and hoping to remember them, update a container definition or lock file. Avoid placing access keys in notebook cells, environment snapshots, command logs, or model artifacts.
For production data, confirm encryption, region, deletion policy, backups, and tenant isolation. A fast launch does not remove normal infrastructure-security responsibilities.
Step 9: Save Results and Terminate Billing
Copy final outputs, logs, environment details, and checkpoints to durable storage. Verify that the uploaded object can be listed or downloaded before deleting local state.
Then terminate the GPU from the dashboard or CLI:
bhk gpu terminate NODE_ID
Confirm that the node status becomes terminated and that compute billing has stopped. Stopping an operating system process is not always equivalent to releasing the GPU allocation. Persistent storage may continue to bill after compute termination, which is expected when you keep volumes or buckets.
At $0.15 per hour, a ten-minute validation run costs only a few cents in raw GPU time when billing is prorated. The expensive mistake is leaving the node idle overnight. Use automatic shutdown, job completion hooks, and budget alerts whenever possible.
Launch dedicated 24 GB GPU compute from $0.15 per hour, attach S3-compatible storage, and terminate when the work is complete. No long-term commitment.
Troubleshooting Quick Reference
| Symptom | Likely cause | First action |
|---|---|---|
| Provisioning takes longer than 60 seconds | capacity, image pull, or health-check delay | check instance events and use a cached prebuilt image |
nvidia-smi fails |
driver or allocation problem | reboot only if documented; otherwise contact support |
| PyTorch reports CUDA unavailable | incompatible framework image | select a tested CUDA image or rebuild the container |
| CUDA out of memory | model, cache, or batch exceeds 24 GB | reduce memory demand or choose a larger GPU |
| GPU utilization stays low | CPU, storage, preprocessing, or small batches | profile the input pipeline and increase workers carefully |
| SSH times out | endpoint, firewall, key, or readiness issue | verify status, address, port, and security rules |
| Outputs disappear after termination | data remained on ephemeral disk | sync checkpoints and outputs to persistent storage |
| Charges continue | instance not fully terminated or storage retained | confirm resource state and inspect the billing inventory |
Frequently Asked Questions
How fast can I rent a GPU server?
BHK Cloud states that most RTX 3090 nodes using prebuilt images are ready in under 60 seconds when capacity is available. A custom image pull, capacity constraint, or additional configuration can increase total startup time.
How much does it cost to rent an RTX 3090 server?
BHK Cloud lists dedicated RTX 3090 compute from $0.15 per GPU hour. The final bill can also include persistent storage or optional services. Check the current GPU product page before launching.
Can I rent a GPU server for only one hour?
Yes. BHK Cloud advertises no minimum commitment and billing that stops when the node is terminated. Verify the active billing terms at checkout, and release the allocation instead of merely disconnecting from SSH.
Is 24 GB VRAM enough for an LLM?
It is enough for many smaller models, quantized larger models, and adapter-based fine-tuning. Exact capacity depends on weights, precision, context, KV cache, concurrency, and runtime overhead. Load the real model in a smoke test before committing to a long run.
Do I need to install CUDA myself?
Not when you select a tested prebuilt machine-learning image. The image should contain the CUDA runtime and framework dependencies. Custom images are useful for reproducibility but must remain compatible with the host driver.
What happens to files when I terminate the server?
Files on ephemeral disks may be deleted. Persistent volumes and object storage survive according to their own lifecycle policies and may continue to incur storage charges. Save checkpoints and outputs before termination.
The Fastest Safe Workflow
The quickest reliable process is simple: size the model, use a prebuilt image, upload an SSH key, attach durable storage, launch one RTX 3090, run a real smoke test, save outputs, and terminate the allocation. The launch itself can take less than a minute. The discipline around it determines whether the result is secure, reproducible, and inexpensive.