Can Hostinger make high-end GPU hardware practical to rent? I deployed a B200, worked through a connection issue, and measured real inference, image generation and monitoring. Read on for the results, costs and limitations that matter before you rent.
Tip: Confirm your preferred GPU is actually selectable, check the region and hourly burn rate, and export every important file before destroying an instance. Rebooting does not stop charges.
I scored Hostinger GPU Hosting using my two deployment experiences, the working B200’s benchmark results, its hPanel controls, and my conversations with support. I also checked the published billing and refund terms. I follow the HostAdvice hosting rating methodology, but this is a snapshot of one tested B200, not an uptime study or a comparison of every GPU model.
| Test | Score /10 | Why This Score |
| Pricing & Plans | 8.1 | Flexible hourly GPU rental and configurations, but continuous billing, non-refundable credits, and no pause option limit value. |
| Features | 8.8 | Powerful GPUs, generous VRAM, application templates, and monitoring tools, but no built-in backups or persistent storage. |
| Performance | 8.8 | Excellent BF16 results, fast Qwen inference, and subsecond SDXL generation, although sustained workloads remain untested. |
| Ease of Use | 8.0 | Quick deployment and straightforward management, but GPU stock limitations and the initial SSH issue caused frustration. |
| Level of Support | 7.8 | Fast, detailed AI responses and useful documentation, but reaching human support and resolving connectivity problems took time. |
| Overall | 8.3 | Impressive GPU performance and accessible deployment, offset by billing restrictions, limited recovery options, and support friction. |
Hostinger GPU Hosting uses an on-demand rental model rather than the fixed monthly subscriptions you typically find with website hosting. You rent GPU resources for workloads such as AI inference, model development, fine-tuning and image generation, with charges based on the configuration you select.
The GPU catalogue includes options ranging from the RTX 4090 and L40S to the A100 and NVIDIA B200, each offering different memory capacities and computing capabilities. However, availability can influence your choice. The RTX 4090 I initially wanted to test was out of stock in hPanel, despite appearing on Hostinger’s public pricing page.
Hostinger offers both standard and Dedicated B200 instances, with the latter costing more. You can also select different CPU, RAM and storage allocations. My first configuration included 16 CPU cores, 32 GB RAM and 300 GB storage, which I chose to support my AI benchmarks rather than relying on the smallest available setup.
Hostinger charges for GPU usage through prepaid credits. However, there are several conditions I would consider before launching an instance:
These conditions make cost planning particularly important for longer AI jobs. You need enough credits to cover both processing and setup time, while also accounting for delays or failed connections.
I tested GPU Hosting using an existing Hostinger account with credits already available, so I did not complete a new payment checkout. New customers can top up their balance after configuring an instance. Hostinger supports payment cards and digital wallets such as PayPal, although the available methods depend on the customer’s region.
I also did not encounter a separate GPU free trial. GPU purchases and AI credits are excluded from Hostinger’s standard 30-day hosting refund guarantee, so I would confirm the final configuration and credit requirements before making a payment.
The biggest advantage is flexibility. You can access expensive GPU hardware for a short workload without purchasing or maintaining your own server. However, the advertised hourly rate doesn’t tell the whole story.
My experience also showed why provisioning and connectivity matter to pricing. Time spent troubleshooting an inaccessible server can still contribute to your costs if the instance is running and consuming credits.
I would check the final credit consumption rate in hPanel, confirm GPU availability, and arrange external storage before launching a paid workload. For short, well-planned jobs, the rental model makes sense. For longer or unpredictable workloads, keeping an eye on credit consumption is essential.
A powerful GPU is only useful if you can access the hardware, run your workloads reliably, and get results within a reasonable time. Hostinger advertises its NVIDIA B200 with 192 GB of VRAM, but I wanted to see how that translated into actual performance.
I focused on three questions:
My first B200 deployment ran into a connectivity problem. hPanel displayed a private IP address that I couldn’t reach from my laptop, and Hostinger acknowledged an issue with the IP address displayed in the dashboard.
To separate that initial problem from the hardware’s performance, I launched a fresh B200 instance and successfully connected over SSH using the new endpoint. I completed the following performance tests on October 26, 2026.
The results below therefore come from a working replacement instance. The earlier connectivity issue remains part of my overall assessment, but it did not prevent me from evaluating the GPU’s performance.
I used an Ubuntu 24.04 B200 instance with a 16-core CPU allocation, 32 GB of RAM and approximately 300 GB of provisioned storage in Hostinger’s Los Angeles region. From my Pop!_OS laptop, I connected over SSH, checked the hardware with nvidia-smi, and installed a CUDA-enabled PyTorch environment. The server reported NVIDIA driver 595.91.07; PyTorch 2.11.0+cu128 recognized the GPU and supported BF16 computations.
I then ran three types of workloads: short BF16 matrix-multiplication and GPU-memory-copy tests, Qwen2.5-7B-Instruct language-model inference, and Stable Diffusion XL image generation. I repeated the AI workloads with fixed settings and recorded individual run times rather than relying on a single best result. Finally, I checked hPanel’s Metrics page to see if GPU activity appeared there.
These tests offer a practical snapshot of one instance. They do not establish long-term uptime, performance during sustained multi-hour loads, or how the B200 compares with competing GPU hosts under identical conditions. I also did not run a network throughput or multi-user inference benchmark.
The first reassuring result was that Ubuntu recognized an NVIDIA B200 immediately. nvidia-smi identified one B200, with 182,624 MiB of reported GPU memory, while PyTorch reported 178.34 GiB available to the device. Those binary-unit figures are broadly consistent with the advertised 192 GB VRAM, though the software-readable amount is not exactly the same number shown on the sales page.
Alt: nvidia-smi confirming the NVIDIA B200, driver 595.91.07, CUDA 13.2 driver support and approximately 178 GiB of GPU memory
The operating system also showed 32 GiB of RAM and 268 GiB of mounted filesystem capacity, as seen from inside the environment. The processor was identified as AMD EPYC 9575F, although lscpu displayed 224 logical CPUs. I checked the container’s CPU control settings rather than interpreting that figure as 224 cores included in my plan.
The cgroup limit was 1,600,000 microseconds per 100,000-microsecond period, giving the instance 16 CPU equivalents. This matched the 16-core allocation I had selected. It is an important distinction for readers because host-visible CPU topology can look far more generous than the capacity actually assigned to a hosted workload.
Verdict: The GPU model, usable memory, system RAM and enforced CPU quota aligned with the main resources I expected from my selected configuration. I did not find evidence of a missing or incorrectly identified GPU.
For a first measure of the B200’s raw calculation ability, I ran BF16 matrix multiplication through PyTorch. BF16 is useful here because it is widely used for AI model calculations, although a small synthetic matrix benchmark is not a substitute for running a complete model.
With 12 repetitions, the smaller 4,096-square matrix produced an estimated 1,402.7 TFLOP/s from a median operation time of 0.098 milliseconds. The 8,192-square matrix produced an estimated 1,668.8 TFLOP/s, with a median time of 0.659 milliseconds. These are calculated arithmetic-throughput estimates for the tested operations, not independently verified sustained application performance.
I also measured a 512 MiB GPU device-to-device memory copy. It completed in a median of approximately 0.17 milliseconds, equivalent to 3,137.1 GB/s of reported payload throughput. This tests movement within GPU memory; it is not the speed of downloading a model, reading the server’s disk, or sending data across the internet.
Alt: Hostinger B200 benchmark terminal showing BF16 matrix-multiplication estimates and 512 MiB GPU device-to-device copy results
The entire baseline script finished in 2.646 seconds. I liked seeing PyTorch recognize the card and run these operations without CUDA errors, but the short duration is also a limitation. We cannot use a few milliseconds of computation to conclude that the GPU will sustain identical throughput or temperatures through a long training job.
Verdict: The B200 delivered fast short-duration BF16 calculations and GPU memory transfers in my test. I treat these numbers as useful baseline measurements, not a published maximum, a long-run stability result, or a direct comparison with another host.
Synthetic throughput was encouraging, but I wanted to see the B200 handle an actual language model. I loaded Qwen2.5-7B-Instruct through Hugging Face Transformers in BF16 and asked it to explain GPU acceleration. The test used one prompt and a maximum of 128 generated tokens, repeated three times with the same settings.
Fetching and loading the model took 35.40 seconds in the recorded run. The first 128-token response then took 23.094 seconds, which worked out to just 5.54 tokens per second. The result initially looked disappointing, but the next two runs told a different story.
Run two completed its 128 tokens in 1.005 seconds, or 127.30 tokens per second. Run three took 1.029 seconds, or 124.35 tokens per second. That gives an average of about 125.8 tokens per second for the two later runs, with very little difference between them.
Alt: Qwen2.5-7B-Instruct benchmark output showing a slow first inference run followed by 127.30 and 124.35 tokens per second
The gap is significant. It is consistent with one-time setup or lazy initialization affecting the first generation, but I did not isolate the exact cause. I would not hide the 23-second result or present the later runs as what every first-time request will achieve. For someone serving a model, both initial latency and the faster repeated responses matter.
PyTorch reported a peak GPU allocation of 14.21 GiB. That is only a small part of the B200’s available memory, so this test demonstrates workable single-request inference rather than the benefit of hosting a model that actually needs close to 192 GB of VRAM. I did not test concurrency, batching, longer context windows, or an optimized inference server such as vLLM.
Verdict: Once the model had warmed up, Qwen’s short responses were consistently fast at roughly 126 tokens per second. The very slow first measured response is an important caveat, and these numbers apply to this specific 7B model and Transformers setup, not all language-model workloads.
For a second real application, I used Stable Diffusion XL to create a 1,024 × 1,024 product image of a black wristwatch resting on dark marble. I used 25 inference steps, FP16 weights, and the same prompt and random seed across three runs. This gave me repeatable measurements rather than three unrelated images with different levels of complexity.
The SDXL model took 18.29 seconds to fetch and load. The first image took 3.275 seconds. The second and third took 0.915 and 0.913 seconds, respectively, for a steady-state average of 0.914 seconds per image. The PyTorch process reported a peak GPU allocation of 11.49 GiB.
Alt: Stable Diffusion XL image generated on Hostinger’s NVIDIA B200 showing a black wristwatch on dark marble under studio lighting
I also inspected the exported images. All three files were byte-for-byte identical, which matched the fixed-seed setup and showed that the repeated test produced the same output. The watch, reflective surface and lighting were convincing at a glance, although close inspection of the dial showed small inconsistencies typical of generated product imagery. Those artistic imperfections should not be mistaken for GPU hardware errors.
The result was particularly useful because it gave me a concrete job to evaluate: once the pipeline was loaded, a full-size SDXL image arrived in under a second. However, this was single-image generation using one SDXL model, not a benchmark of video generation, large batches, or every image model available to rent.
Verdict: SDXL was responsive after initialization, with almost identical measured generation times in the later two runs. For short image-creation tasks, that made the rented B200 feel capable, while its much larger memory capacity remained mostly unused.
Earlier in the review, Hostinger’s Metrics page had shown flat lines because the GPU was idle. After running the benchmarks, I returned to the same 1-hour view and saw activity in both graphs. Compute throughput was displayed as 297 TFLOPs, and the VRAM chart showed a visible rise, including a hovered point of 14.3 GB.
Alt: Hostinger hPanel GPU Metrics graph showing non-zero compute activity and a VRAM spike with a 14.3 GB tooltip after AI benchmark tests
That was useful confirmation that hPanel recorded the workload rather than continuing to show a flat zero. It also made the Metrics page more informative than it had been immediately after deployment. The options for 1 hour, 24 hours, 7 days and 30 days were easy to locate.
I would still avoid a direct numerical comparison between hPanel’s 297 TFLOPs display and the synthetic 1,668.8 TFLOP/s result. The dashboard’s sampling window and calculation method were not established during my test, and its VRAM display is not identical to PyTorch’s process-level peak allocation. The graphs are useful for spotting activity and changes over time; they are not a replacement for workload-level timing or system measurements.
Verdict: Hostinger’s metrics did respond to actual GPU usage. I found the graphs useful for a quick check, although the dashboard does not explain enough about its aggregation to treat every displayed figure as a precise benchmark.
Hostinger’s second B200 instance gave me usable GPU acceleration across three very different tests. The synthetic BF16 results showed fast short calculations, Qwen2.5-7B reached roughly 126 tokens per second after an unusually slow first measured response, and Stable Diffusion XL produced 1,024-pixel images in approximately 0.91 seconds once initialized. I also confirmed the 16-core CPU quota and watched activity appear in hPanel.
Those are positive results, but I would not turn them into a promise about every AI workload. The tests were brief and performed on one instance, with relatively small models compared with the B200’s available VRAM. I did not benchmark sustained training, peak concurrency, long-term availability or external network speed. The earlier SSH endpoint issue also remains a separate operational concern, even though the replacement server connected successfully.
Verdict: For the workloads I actually ran, Hostinger’s B200 delivered impressive short-task performance and useful visibility in hPanel. It looks capable for GPU-heavy AI work, but the case for paying for 192 GB of VRAM depends on needing larger models or workloads than the ones I measured.
I approached Hostinger GPU Hosting the way I would approach a new GPU rental: find a suitable card, check the actual cost, launch an instance, and see how manageable the environment feels after it is running.
I also wanted to know how the GPU service fits into Hostinger’s larger hPanel, since getting a server online is only half the experience.
The deployment itself was quick. The purchasing journey was less predictable. The GPU I chose on the public pricing page was not available in hPanel, and my replacement came with a much higher hourly rate. Here is how the experience unfolded, from the first click to the management tools.
I started on Hostinger’s website and opened Products > Hosting > GPU hosting. I liked that GPU hosting had its own clearly labeled entry alongside web hosting, VPS hosting, and cloud hosting. I did not have to open a generic VPS product or work out if GPU hardware was available as an add-on.
Alt: Hostinger Products menu showing Hosting selected and the GPU hosting entry alongside other hosting services.
The link opened Hostinger’s GPU Hosting landing page, which advertised hourly NVIDIA GPU rentals for AI, rendering, and other compute-intensive work. A Get started button sat directly under the main headline. Clicking it did not immediately create an instance or send me to registration; it moved me down the same page to the GPU pricing section.
Alt: Hostinger GPU Hosting landing-page headline with the Get started button that scrolls to GPU pricing.
That was a sensible place to start. The pricing section put the available GPU models into separate cards, with their advertised starting hourly rates, VRAM, and recommended uses. I could compare hardware before being asked to configure a server. The range shown on the public page extended from the RTX 4090 through more expensive data-center GPUs, including the B200.
Alt: Hostinger GPU Hosting page showing its GPU pricing cards, starting hourly rates, and recommended workloads.
I initially settled on the NVIDIA RTX 4090. Hostinger advertised it from $0.42 per hour with 24 GB VRAM and recommended it for development, experimentation, image and video generation, 3D rendering, and inference with smaller models.
That seemed a reasonable starting point for the AI inference, image-generation, and GPU performance checks I had planned. I did not need to rent one of the most expensive cards just to establish a practical baseline.
Alt: RTX 4090 GPU pricing card showing the $0.42-per-hour starting rate, 24 GB VRAM, suggested uses, and Get GPU button.
After choosing the RTX 4090, I clicked Get GPU on its card. That took me to Hostinger’s account registration page. It offered sign-up through Google or GitHub, plus the usual email address and password fields.
The phone number field was marked optional, and a separate checkbox covered promotional messages via WhatsApp and SMS.
Alt: Hostinger Register screen showing Google and GitHub sign-in, email and password fields, an optional phone number, and the marketing consent checkbox.
The registration screen was uncomplicated. More importantly, GPU selection had not yet committed me to buying a particular server.
After account creation or login, I entered the GPU area of hPanel, where the hardware could actually be selected and launched. The panel showed a credit balance of 2,000.
The panel showed a credit balance of 2,000 because I already had a Hostinger account with credits available. If you’re signing up for the first time without an existing credit balance, you’ll encounter a payment step after configuring your GPU instance, where you can choose your preferred payment method before completing the purchase.
Verdict: Finding the GPU product and reaching the account panel was straightforward. I appreciated being able to compare GPU cards on the public page first, although the next stage showed why a pricing-page choice is not the same as a deployable instance.
The GPU page in hPanel was clean and easy to scan. Above the list, Hostinger explained that I could launch GPU instances directly from the panel, and the selectable hardware appeared below a visible credit balance. Seven models were listed, including the RTX 4090 I had chosen, but most Select buttons were disabled.
Alt: Hostinger hPanel GPU homepage showing the GPU list, Select buttons, and a balance of 2,000 credits.
I tried to select the RTX 4090 and found that its button was greyed out. Hovering over it produced an Out of stock message. I also could not select the RTX 5090, L40S, A100, or RTX PRO 6000 in that session. Only two options were available to me: the NVIDIA B200 and B200 (Dedicated).
Alt: hPanel GPU list showing the disabled RTX 4090 Select button with an Out of stock tooltip, while B200 and B200 Dedicated remain available.
This was the most significant friction in the purchasing experience. The public pricing page had invited me to rent a $0.42-per-hour RTX 4090, but I could not actually provision that GPU.
Hostinger was at least clear about the restriction in hPanel, rather than allowing me to fill out a configuration and fail after deployment. Still, it meant reconsidering both my test hardware and budget.
I chose the standard NVIDIA B200, advertised from $4.50 per hour with 192 GB VRAM. Its larger memory capacity also gave me room to test more demanding AI workloads later.
The alternative B200 (Dedicated) started at $7.08 per hour, and I had no specific requirement for exclusive GPU access that justified paying that premium. I clicked Select on the standard B200 to continue.
Verdict: Hardware availability was a limitation, not a navigation problem. The selection screen clearly distinguished usable stock from unavailable models, but I would check live inventory before budgeting around any GPU price shown on Hostinger’s public page.
After selecting the B200, Hostinger opened a Deploy your GPU instance page. It kept the GPU choices in a column on the left and the selected instance’s configuration on the right. That arrangement worked well: I could review the B200 alongside the available alternatives without losing sight of the server settings or running cost.
Alt: Hostinger Deploy your GPU instance page with B200 selected and fields for instance name, location, size, operating system, and SSH key.
I named the instance hostinger-gpu-review-b200. Hostinger specified that separate words in the name should use hyphens, which made the naming rule clear from the form itself.
The next field was region, and this revealed the second practical limitation: the dropdown offered only Los Angeles, United States. I had no other location to choose in this deployment session.
Alt: GPU region dropdown offering only Los Angeles, United States, for the selected B200.
The instance-size selector needed more attention than I first expected. Hostinger had preselected a 2-core, 64 GB RAM, 100 GB storage configuration at 506 credits per hour. Opening the dropdown revealed other CPU, RAM, and storage combinations with different rates. The selection was not a simple progression in which every smaller CPU count meant a lower price; the 4-core option, for example, was listed at 450 credits per hour.
Alt: B200 instance-size dropdown displaying the available CPU, RAM, storage, and credits-per-hour configurations.
I went with the X-Large option: 16 CPU cores, 32 GB RAM, and 300 GB storage at 488 credits per hour. This gave the server more CPU and disk capacity for setting up and running tests, without jumping to the 32-core configuration.
It was also slightly cheaper per hour than the preselected 2-core option. The important pricing point is that Hostinger’s advertised $4.50-per-hour B200 rate was a starting price. My actual selected configuration had a rate of 488 credits per hour, equivalent to about $4.88 per hour at the rate implied by Hostinger’s pricing cards.
Next I opened Select OS or application. In addition to Ubuntu 24.04, Hostinger offered ready-made choices for Ollama, JupyterLab, Unsloth, and InvokeAI. Those options could save setup time for someone focused on a particular AI application. I selected Ubuntu 24.04 because I wanted a clean operating system and control over the tools I installed for subsequent testing.
Alt: Select OS or application menu showing Ubuntu 24.04 alongside Ollama, JupyterLab, Unsloth, and InvokeAI.
Hostinger also offered an optional SSH key field. I left it unused for the initial deployment rather than adding a key during checkout. The panel later displayed password-based connection details, so the absence of a key did not leave me without an advertised login method. For a longer-running server, though, I would prefer key-based SSH access.
Before I clicked Deploy, the summary showed the chosen B200, X-Large configuration, and 488-credit hourly rate against my 2,000-credit balance.
Hostinger estimated that the balance covered about four hours of continuous use. I liked having this estimate immediately above the deployment button: it made the ongoing expense more visible than a price card that only says From $4.50/hr.
Alt: Completed B200 deployment form showing the X-Large 16-core configuration, Ubuntu 24.04, 488 credits per hour, and the Deploy button.
I clicked Deploy. Hostinger then showed a Setting up your GPU screen and said I could leave the page while provisioning continued. There was no extra manual infrastructure setup during this stage.
Alt: Hostinger Setting up your GPU progress screen displayed after clicking Deploy.
Roughly two minutes later, the success screen confirmed You’re all set! and said the GPU instance was up and running. It identified hostinger-gpu-review-b200 as a B200 with 192 GB VRAM and X-Large sizing. The next action was clearly presented as Manage, which made it obvious where to go after provisioning finished.
Alt: Successful GPU deployment confirmation for hostinger-gpu-review-b200 after approximately two minutes.
I clicked Manage from this confirmation screen to examine the controls I would be using after deployment. That direct handoff was a nice touch: there was no need to return to the general hPanel homepage and search for my new server.
Verdict: I found the actual launch flow efficient. I could change the hardware allocation, pick an OS image, see my hourly spend, and bring the B200 online in about two minutes. The areas that constrained my choice were GPU stock and the single available region, not the deployment form.
Manage opened a dedicated GPU management area rather than an ordinary web-hosting control panel. The left menu had only three entries: Overview, Metrics, and Exposed services. After the broad product selection screens, I appreciated how focused this navigation was.
Overview immediately answered the questions I would have after renting expensive hardware: Is it running? Which GPU and resources did I receive? What is the burn rate? How do I connect? The instance card marked hostinger-gpu-review-b200 as Running and confirmed the NVIDIA B200, 192 GB VRAM, 16 CPU cores, 32 GB RAM, 300 GB disk, Ubuntu 24.04, and Los Angeles location.
Alt: Hostinger GPU Overview showing the running B200, provisioned hardware, billing metrics, SSH connection details, and server controls.
Two controls sat directly on the instance card: Reboot and Destroy. Their visibility is useful because you need to know how to manage the instance lifecycle when you are paying by the hour. I did not execute either action during this part of the test, so I am evaluating how accessible the controls were, not claiming to have verified their behavior.
Above the server card, Hostinger showed compute throughput, VRAM usage, and credit spending. My initial capture displayed 0 TFLOPs throughput and 0 GB average VRAM usage because I had not yet run a GPU workload.
The credit summary showed 488 credits used in total, a burn rate of 488 credits per hour, and a remaining balance of 1,512 credits. That visibility was welcome, especially given how quickly paid GPU usage can accumulate.
The Connection panel placed the public IPv4 address, a copyable SSH command, and the password in one section. The SSH command included the Ubuntu username and a non-default SSH port; the password field had reveal and copy controls.
Hostinger also warned that a password changed through SSH would no longer match the one stored in hPanel. I could therefore find the connection information without searching documentation, although the screenshot alone does not prove that I successfully logged in over SSH.
Verdict: The dedicated Overview page was better organized for GPU administration than the general hPanel homepage. Server details, connection information, usage, and lifecycle controls appeared together, making basic administration approachable even with relatively powerful hardware.
After reviewing the Overview, I opened Metrics. Hostinger offered time filters for 1 hour, 24 hours, 7 days, and 30 days. The page plotted compute throughput in TFLOPs and VRAM usage in GB. The graphs were minimal and readable, with no unrelated system charts competing for attention.
Alt: Hostinger GPU Metrics page with 1h, 24h, 7d, and 30d time filters and idle compute-throughput and VRAM-usage graphs.
Both charts were flat at zero when I captured them. That was expected before running an AI job, so I would not treat these readings as evidence for GPU performance or a defect in the monitoring system.
The useful test comes later: start a real workload, check the graphs as usage changes, and compare them with measurements from inside Ubuntu.
I then opened Exposed services, the section for making an application running on the GPU server reachable over the internet. Because I had not created a service, the page displayed an empty state with an Add service button. Hostinger also included a warning that anything published would be accessible to anyone with the address unless the application had its own login.
Alt: Hostinger Exposed services page showing the first-service empty state, Add service button, and warning about public access.
I liked that warning. GPU workloads frequently involve notebooks, inference APIs, and other development interfaces that are not meant to be openly accessible. The entry point was easy to locate, but I had not yet added or tested a public service here, so I cannot assess the rest of that workflow or the security options from these screenshots alone.
Verdict: The Metrics and Exposed services sections were easy to locate and understand. At this point they demonstrated sensible navigation and clear warnings, while their behavior under load and with a live public application remained untested.
Only after checking the GPU-specific screens did I return to hPanel Home. That gave me a different perspective on ease of use: where would I find the GPU instance if I signed in again later instead of entering through the post-deployment Manage button?
My Home page opened with a prominent AI assistant prompt and a long Your business area full of existing websites.
Each site had a Manage site action, and several entries displayed reminders about temporary domains. Further down, I could see a VPS table with IP addresses, running statuses, expiration dates, and management buttons. On the left, the navigation brought together Websites, Domains, Emails, More services, website builders, AI agents, marketing tools, and developer services.
Alt: Hostinger main hPanel Home dashboard showing the assistant, existing websites, VPS table, and extensive left-hand product navigation.
There are advantages to this all-in-one arrangement. The product groups are labeled plainly, and an existing Hostinger customer can reach several types of hosting from one account. In my case, though, the amount of website-related content made the page visually busy.
My new GPU was not as prominent in the visible Home content as the websites and VPS entries. I found the GPU’s dedicated Overview, Metrics, and Exposed services navigation more focused once I had reached it.
The unusually long list of websites reflects what was already in my account; a new customer with no other services may see a less crowded page. Still, the distinction is important for the reader: deploying a GPU is a short, focused process, while the broader hPanel dashboard tries to serve every Hostinger product at once.
Verdict: hPanel is understandable but not equally focused across its different views. The GPU management screens were direct and practical; the account-wide Home page required more scanning when I wanted to concentrate on the GPU service.
The strongest part of Hostinger GPU Hosting’s usability was what happened after I found an available GPU. The configuration page showed the choices and their cost, Ubuntu and AI application images were easy to locate, deployment finished in roughly two minutes, and Manage took me directly into a compact instance dashboard.
I could find the GPU specification, credit burn rate, SSH information, and the main administration controls without working through a complicated cloud console.
But that convenience should not hide the limitations before deployment. I chose the RTX 4090 on the public page and could not rent it once I reached hPanel; most listed GPUs were unavailable, and Los Angeles was the only deployment region in my session. The B200 was substantially more expensive than my intended RTX 4090, and the rate of the X-Large configuration was higher than the advertised B200 starting rate. The general hPanel Home view also felt busier than the GPU-specific pages.
Verdict: I would call Hostinger GPU Hosting straightforward to set up and manage, provided the GPU you need is actually in stock. Confirm live availability, region choice, and the exact credits-per-hour rate in hPanel before committing to a workload or budget.
Hostinger provides 24/7 online support through its dashboard chat, with additional access through WhatsApp and email at support@hostinger.com. Unlike some hosting providers, it does not offer telephone support.
The main support experience now revolves around Hostinger Agent, an AI assistant that can answer questions, troubleshoot problems, retrieve documentation, and perform certain account-management actions. Hostinger also provides access to Customer Success Specialists when additional assistance is needed.
For this review, I tested the live chat using a real concern about my NVIDIA B200 GPU instance. I wanted to establish how quickly I could get accurate technical guidance and, more importantly, how easy it was to speak directly with a human when I requested one.
I also reviewed Hostinger’s knowledge base to assess the quality of its GPU documentation and see if customers could resolve common issues without contacting support.
I accessed live chat by clicking Agent at the top of hPanel. The chat opened alongside my GPU management page, allowing me to view my running B200 instance and its credit consumption while speaking with support.
Alt: Hostinger hPanel GPU dashboard showing the running NVIDIA B200 instance alongside the Hostinger Agent chat interface.
Hostinger Agent is the successor to Kodee, Hostinger’s former AI support assistant. Hostinger combined Kodee with its broader collection of specialized AI tools into a unified assistant. According to Hostinger, the agent can explain technical problems, provide troubleshooting instructions, suggest relevant documentation, and perform supported actions on a customer’s account.
However, my test focused on technical advice and human escalation rather than allowing it to make account changes.
I asked a practical question about GPU billing and data retention. Since Hostinger charges for GPU instances by the hour, I wanted to know if I could pause my server between AI workloads without losing my installed applications, models, and files. I also asked if rebooting would stop charges and what I should do to preserve my environment if destroying the instance was necessary.
The agent responded in less than 30 seconds.
Its response addressed all three concerns. It explained that rebooting only restarts the server and does not stop billing. Hostinger does not currently provide a pause or stop function that lets customers preserve a GPU instance without incurring charges. Destroying the instance stops billing but permanently deletes its local data.
The answer went further by explaining how I could preserve my working environment. It recommended transferring models and datasets to external storage, exporting Python or Conda dependencies, recording CUDA and PyTorch versions, and saving configuration files and deployment scripts.
Alt: Hostinger Agent explaining continuous GPU billing and recommending methods for preserving files, models, and software configurations before destroying an instance.
I liked the level of detail. Rather than simply stating that GPU instances could not be paused, the assistant addressed what I should do before destroying the server. Its guidance also matched Hostinger’s official GPU billing documentation, giving me a way to check the accuracy of the explanation.
However, answering the technical question was only the first part of my support test. Next, I wanted to speak directly with a human specialist.
At 17:23, I asked Hostinger Agent to connect me to a human customer support representative to confirm the GPU billing and data-retention details. Instead of arranging a transfer, it repeated the policy and encouraged me to continue with AI support, explaining that this would be faster.
I made another explicit request at 17:24. This time, I stated that I understood the policy and did not need another AI explanation. I specifically wanted a human representative and was willing to wait.
At 17:25, the assistant again summarized the billing rules before offering two options: Wait for a human review and Continue with Hostinger Agent.
Alt: Hostinger Agent offering Wait for a human review and Continue with Hostinger Agent after repeated requests for human support.
I selected the human-review option and confirmed that I wanted to continue with a person. Hostinger then displayed a review-in-progress message, a countdown, and a field where I could provide additional information for the specialist.
Alt: Hostinger support conversation showing a pending human review, countdown timer, and optional field for additional details.
At 17:31, approximately six minutes after the request entered the review process, I received a response associated with a specialist named Amber. The interface displayed “Response reviewed by Amber.”
Amber’s message asked me to provide my GPU instance name, the billing or data-retention points I wanted confirmed, and any relevant errors or screenshots.
Alt: Hostinger support message reviewed by Amber requesting information about the NVIDIA B200 instance and the billing concern.
I provided the instance name, hostinger-gpu-review-b200, and asked for confirmation of three important points: the absence of a pause function, permanent data deletion after destruction, and the availability of snapshots, backups, or persistent storage.
I also asked a question about the support process itself. Since the interface said the response had been reviewed by Amber, I wanted to know if I was now speaking directly with her or still interacting with AI.
At 17:33, I received another detailed answer. The response confirmed that GPU instances continue consuming credits while idle, that destruction permanently removes their local data, and that Hostinger does not currently provide GPU snapshots, automated backups, or persistent storage.
It also explained that an instance is destroyed immediately when the credit balance reaches zero, without a grace period. The suggested alternative was to export the environment to a separate VPS, cloud storage, or local computer using tools such as scp or rsync.
But the most revealing part of the response concerned human support. Hostinger explicitly confirmed that I was still communicating with Hostinger Agent, an AI assistant. A human specialist was overseeing or reviewing the conversation, but I had not been transferred to a direct one-to-one human chat.
Alt: Final Hostinger Agent response confirming GPU billing and backup limitations and explaining that Amber provided human oversight rather than direct live-chat assistance.
That distinction matters. I had deliberately requested a human representative rather than another automated explanation. Although the system obtained human oversight and produced a complete technical answer, it did not provide the direct human interaction I requested.
From the first question at 17:22 to the final clarification at 17:33, the entire support exchange took approximately 11 minutes. The initial AI answer arrived in less than 30 seconds, while human review became visible roughly six minutes after I requested escalation.
Verdict: Hostinger Agent impressed me with its speed and technical detail. The initial answer was accurate, practical, and supported by official documentation. Human review was relatively quick, but reaching it required repeated requests, and I never received a direct one-to-one conversation with a specialist. Hostinger’s system worked better as AI-led support with human oversight than as conventional live chat with an immediately accessible human representative.
After testing live chat, I turned to Hostinger’s online Help Center to see how easily GPU customers could find answers without contacting support.
The homepage was clean and well-organized, with a prominent search bar and documentation grouped into categories such as Getting Started, Hostinger Dashboard, VPS, Billing, and SSL Certificates. However, I couldn’t find a dedicated GPU category among the options displayed.
Alt: Hostinger Help Center homepage showing the search bar and documentation categories, including VPS, Billing, and Hostinger Dashboard.
I entered “gpu” in the search bar, and Hostinger returned 10 results. Eight focused specifically on GPU hosting, covering hardware selection, application templates, deployment, instance management, billing, exposed services, security, and comparisons with VPS hosting. The other two covered Hostinger’s refund policy and dashboard.
Alt: Hostinger Help Center search results for “gpu” showing 10 articles, including GPU setup, billing, instance management, and security guides.
I liked that the search immediately surfaced relevant GPU documentation, even without a dedicated category on the homepage. More importantly, the articles covered practical concerns such as hourly credit consumption, data loss after instance destruction, and securing publicly accessible applications.
Next, I examined the individual guides to see how clearly they explained these issues and how closely their instructions matched my hands-on experience.
I reviewed Hostinger’s guides on GPU setup and instance management. They cover hardware selection, regions, software templates, deployment, monitoring, and exposed services.
The instructions closely matched my experience in hPanel. I also appreciated that Hostinger acknowledged regional GPU availability limitations, which I encountered when the RTX 4090 was out of stock and Los Angeles was my only deployment option.
The GPU billing guide was particularly useful because it addressed the same concerns I raised during live chat.
It confirms that billing continues while an instance is idle, rebooting does not stop charges, and destruction permanently deletes local data.
More importantly, Hostinger warns that there are no automatic credit top-ups or low-balance notifications. Running out of credits results in immediate instance destruction.
Alt: Hostinger GPU billing documentation explaining continuous charges, credit depletion, and permanent data loss.
These are critical details for anyone running unattended AI workloads, and I liked that Hostinger explained them clearly.
Hostinger’s service exposure guide explains public access, port configuration, and supported protocols. It also clarifies that selecting HTTPS does not automatically configure TLS encryption.
The accompanying security guide covers application authentication and firewall protection. However, I would have liked a clearer warning about preserving SSH access before enabling restrictive firewall rules.
Alt: Hostinger GPU security documentation covering application authentication and public-service protection.
Verdict: Hostinger’s GPU documentation is clear, practical, and consistent with the support responses I received. Billing and security guidance stood out, although recovery remains a manual process without built-in GPU snapshots or persistent storage.
Hostinger delivered a strong AI-assisted support experience, although its human escalation process left room for improvement.
Hostinger Agent answered my GPU question in less than 30 seconds, explained the billing implications, and recommended practical steps for preserving my environment. Its guidance was detailed and consistent with official documentation.
Human oversight became available after approximately six minutes, and the final response addressed the additional questions I raised. However, I had to request escalation repeatedly, and the conversation remained AI-led rather than becoming direct live chat with a specialist.
The knowledge base was another positive. Its eight GPU-specific articles provided clear explanations of deployment, management, billing, service exposure, and security. The billing documentation was especially useful for understanding the risks of continuous credit consumption and permanent data loss.
Verdict: I found Hostinger’s AI chat and GPU documentation capable of resolving common technical questions quickly. However, I would like to see a more direct route to a human specialist, particularly for complicated or urgent problems. The quality of the information was good; access to direct human assistance was the main weakness of my support test.
Yes, for developers and AI teams that need serious GPU capacity without buying the hardware. My B200 ran Qwen inference at roughly 126 tokens per second after warm-up and generated SDXL images in about 0.91 seconds.
Deployment was quick once I had a working SSH endpoint. However, the first server’s IP-display problem, changing hardware availability, non-refundable credits and lack of a pause or built-in backups are meaningful risks.
| ชื่อแพลน | CPU | RAM | แบนด์วิดท์ | ราคา | |
|---|---|---|---|---|---|
| Free Trial | - | ไม่จำกัด | ฿0 | รายละเอียด | |
| Game Panel 2 | 2 core | 8 GB | 8 TB | ฿290 | รายละเอียด |
| Game Panel 4 | 4 core | 16 GB | 16 TB | ฿430 | รายละเอียด |
| Game Panel 8 | 8 core | 32 GB | 32 TB | ฿860 | รายละเอียด |
| Description | Expert Review |
|---|---|
| โฮสติ้งราคาประหยัดพร้อมประสิ�... | Read Shared Hosting Review |
| โฮสติ้ง WordPress ที่ ast และปลอดภัย พร�... | Read Wordpress Hosting Review |
| โฮสติ้ง VPS ที่ปรับขนาดได้ พร้อม�... | Read VPS Review |
| โฮสติ้งบนคลาวด์ที่รวดเร็ว, ยื�... | Read Cloud Hosting Review |
| โซลูชันโฮสติ้งที่ปลอดภัยและเ�... | Read Offshore Hosting Review |
| โฮสติ้งอีเมลที่ปลอดภัยและเชื�... | Read Email Hosting Review |
| โฮสติ้ง Python ที่เชื่อถือได้ พร้อ�... | Read Python Hosting Review |
| โฮสติ้ง PHP ประสิทธิภาพสูง พร้อม�... | Read PHP Hosting Review |
| โฮสติ้ง Windows VPS ที่เชื่อถือได้ พร�... | Read Windows VPS Review |
| โฮสติ้งที่รวดเร็วและยืดหยุ่น ... | Read Nodejs Hosting Review |
| โฮสติ้งที่ปรับให้เหมาะสมสำหร�... | Read Woocommerce Hosting Review |
| โฮสติ้งเซิร์ฟเวอร์เฉพาะสำหรั�... | Read Minecraft Server Hosting Review |
| โซลูชันการโฮสต์ที่ปรับขนาดได�... | Read Agency Hosting Review |
| โฮสติ้งที่รวดเร็วและปลอดภัย ป... | Read Magento Hosting Review |
| โฮสติ้งบน Linux ประสิทธิภาพสูง สำ�... | Read Linux Hosting Review |
| โซลูชันโฮสติ้ง Java ที่แข็งแกร่ง�... | Read Java Hosting Review |
| โฮสติ้งที่ปรับแต่งมาเพื่อเว็�... | Read Ecommerce Hosting Review |
| โฮสติ้ง Django ที่เชื่อถือได้ด้วย�... | Read Django Hosting Review |
| โฮสติ้ง cPanel ใช้งานง่าย มาพร้อมป�... | Read Cpanel Hosting Review |
| โฮสติ้งทรงพลังสำหรับธุรกิจ พร... | Read Business Hosting Review |
| Easy-to-use website builder with drag-and-drop tools and customizable templates. | Read Website Builder Review |
| Optimized hosting for Joomla sites with one-click installation and reliable performan... | Read Joomla Hosting Review |
| Powerful hosting with full PostgreSQL database support for data-driven applications. | Read PostgreSQL Hosting Review |
| Flexible hosting with MongoDB integration for scalable, modern web applications. | Read MongoDB Hosting Review |
| AI-powered website creation platform for building professional sites in minutes. | Read AI Builder Review |
| Reliable hosting for n8n workflow automation with easy setup and management. | Read n8n Hosting Review |
| VPS hosting with Docker support for containerized application deployment and scaling. | Read Docker VPS Review |
| โฮสติ้งเซิร์ฟเวอร์ SMTP เฉพาะสำห�... | Read SMTP Server Review |
| โฮสติ้งที่รวดเร็วและได้รับกา�... | Read Ruby on Rails Review |
| โฮสติ้งที่อัดแน่นด้วยฟีเจอร์�... | Read OpenClaw Review |
| โฮสติ้งที่รวดเร็วและเชื่อถือ�... | Read UK Hosting Review |
| โฮสติ้งราคาย่อมเยาและเชื่อถื�... | Read India Review |
| Read Singapore Review | |
| Read Australia Review | |
| Read AI Agent Review | |
| Read Paperclip VPS Review | |
| Read Hermes Agent Review | |
| Read Hostinger Connector Review | |
| Read Web Apps Hosting Review | |
| Read Hostinger Reach Review | |
| Read MCP Review | |
| Read hpanel Review | |
| Read Odoo Review | |
| Read Laravel Review | |
| Read MERN VPS Review | |
| Read Ubuntu Review | |
| Read Drupal Hosting Review | |
| Read Express.js Review | |
| Read React Review | |
| Read Nextjs Review | |
| Read AI Router Review |
Yes. My NVIDIA B200 ran Qwen2.5-7B inference and Stable Diffusion XL image generation successfully. Results vary by model, framework and instance size.
Hostinger advertises 192 GB of VRAM. My B200 reported 178.34 GiB through PyTorch, consistent with differences between decimal and binary memory units.
No. GPU credits continue being consumed while the instance is idle or rebooting. Destroying the instance stops usage charges but permanently removes its local data.
I did not see a dedicated GPU free trial during my checkout. Hostinger excludes GPU purchases and AI credits from its standard 30-day money-back guarantee.
Yes. SSH worked on my replacement B200 instance, although the first deployment displayed a private IP instead of a usable public SSH endpoint.
ตอบคำถามไม่กี่ข้อและค้นหาคำตอบที่เหมาะสมสำหรับคุณ!
เริ่มต้นการค้นหาโฮสติ้ง
