The honest truth: no GPUs at Hostinger
Let us be direct, because several coupon-style sites imply otherwise: as of October 2026, Hostinger’s entire product line — shared hosting, cloud hosting, and all KVM VPS tiers — runs on CPU-only hardware. There is no GPU VPS plan, no GPU add-on, and no announced GPU product. Hostinger’s AI story is about managed AI products (AI Website Builder, Horizons, the OpenClaw and Hermes Agent automation plans), not about renting you graphics cards.
This matters because the wrong purchase is expensive in time: buying a big KVM VPS expecting GPU acceleration will not magically give you one, and you will discover it only after spending an afternoon installing CUDA drivers that have no hardware to talk to. If your workload genuinely needs a GPU — training, fast LLM inference, image/video generation — skip straight to the GPU providers listed below.
What you CAN do on a Hostinger VPS: CPU inference
No GPU does not mean no AI. Modern quantized models run on plain CPUs via tools like Ollama, and for light workloads a Hostinger KVM VPS is a legitimate, cheap place to run them:
- Small chat models (1B–3B parameters) for private assistants, drafting, and Q&A over your own documents.
- Embeddings for semantic search and RAG pipelines — embedding models are small and CPU-friendly.
- Classification, summarization, and extraction jobs that run in the background where speed does not matter.
- Development and prototyping — build your whole AI pipeline on the cheap VPS, then move inference to GPUs only if you need the speed.
The honest limit: CPU inference is slow compared to GPUs. A 7B–8B model on a shared vCPU generates a few tokens per second — usable for background jobs and personal experiments, painful for an interactive chatbot with users waiting. Set expectations accordingly: the VPS is for “AI that can take its time,” not for real-time products.
Our Ollama on Hostinger VPS guide covers installation and the critical detail — how much RAM each model size needs, and which KVM plan fits which model.
Where to go for real GPU hosting
When CPU is not enough, these are the established GPU clouds, with indicative pricing checked October 2026. GPU pricing moves often — treat these as order-of-magnitude guides and confirm on the provider’s page before committing:
- RunPod — the default recommendation for individuals. Rent RTX 4090 / A100 pods by the hour or “secure cloud” by the month; a 4090 pod typically runs around $0.40–0.70/hr on demand. Excellent template ecosystem for LLMs, Stable Diffusion, and training.
- Vast.ai — a marketplace of GPU hosts, often the cheapest per-hour rates anywhere. More variance in reliability — fine for experiments and batch jobs, verify before production.
- Lambda — purpose-built AI cloud with on-demand and reserved GPU instances; popular with startups doing serious training.
- Paperspace (by DigitalOcean) — Gradient notebooks and GPU machines with a gentler learning curve; good first GPU cloud for developers.
- Hyperscalers (AWS, GCP, Azure) — every GPU type imaginable at the highest prices and the most paperwork. Justified at company scale, overkill for a side project.
For a broader comparison of AI hosting options, see our best GPU hosting for AI roundup.
The cost math: VPS vs GPU cloud
A Hostinger KVM 2 VPS (
VPS KVM 2
24-month plan, paid upfront
Renews at $14.99/mo
- 2 vCPU + 8 GB RAM
- 100 GB NVMe storage
- 8 TB bandwidth
- Full root access
- n8n one-click template available
The practical rule:
- Always-on light AI (personal chatbot, nightly document processing, embeddings) → Hostinger VPS with Ollama. Flat, cheap, private.
- Burst GPU work (fine-tuning a model, generating a batch of images, benchmarking) → RunPod/Vast.ai by the hour. Spin up, run, shut down.
- Production GPU inference (customer-facing LLM features) → serverless GPU inference APIs (Together, Fireworks, Replicate) usually beat self-hosting on total cost — you pay per token, not per server.
A legitimate hybrid: Hostinger VPS + GPU API
One architecture deserves a special mention because it is genuinely the best of both worlds for many apps: run your application on the cheap, flat-rate Hostinger VPS, and call a GPU inference API only for the heavy AI steps. Your Node or Python app handles users, business logic, and the database; when it needs an LLM judgment call or an image generated, it makes an API request to Together AI, Fireworks AI, or Replicate and gets the result in seconds.
You keep the VPS’s predictable bill, you get true GPU speed for the AI parts, and you never manage a GPU driver. For most “app with AI features” projects, this beats both pure-CPU self-hosting and full GPU rental.
Implementation is straightforward: your backend keeps an API key for the inference provider in its environment variables, sends the prompt, and caches frequent answers (in Redis or even a simple file cache) to cut repeat costs. Many teams start with the provider’s cheapest model tier and only upgrade when quality demands it — the VPS side of the architecture never changes, so you are not locked in.
Frequently asked questions
Does Hostinger offer GPU VPS plans?
No. As of October 2026, Hostinger has no GPU servers in any product line — shared, cloud, and KVM VPS plans are all CPU-only. Hostinger’s AI products are managed software (AI builder, Horizons, automation plans), not GPU rentals.
Can I run AI models on a Hostinger VPS without a GPU?
Yes, for small models. Ollama runs quantized LLMs (1B–8B parameters) on CPU; a KVM VPS handles chat, embeddings, and background AI jobs. Expect slow token generation on larger models — see our Ollama sizing guide.
What is the cheapest way to get GPU access?
Vast.ai’s marketplace usually has the lowest hourly GPU rates; RunPod is the best balance of price and reliability for most individuals (a 4090-class pod around $0.40–0.70/hr on demand). For occasional use, serverless inference APIs (Together, Fireworks, Replicate) charge per token with no server to manage. Prices checked October 2026.
Can I install CUDA on a Hostinger VPS?
You can install the software, but it will not help — CUDA needs NVIDIA hardware, and Hostinger VPS plans have none. Do not buy a larger KVM plan hoping for GPU acceleration; the constraint is hardware, not plan size.
Is a Hostinger VPS or RunPod better for a personal AI chatbot?
The VPS, for most people: a small Ollama model serves a personal chatbot fine on CPU at a flat monthly rate, with your conversations staying on your own server. Choose RunPod when you need a larger model or faster responses than CPU can deliver.
Will Hostinger launch GPU hosting in the future?
Hostinger has not announced GPU products as of October 2026. Their AI investments have gone into managed products (AI Website Builder, Horizons, AI automation plans) rather than raw GPU infrastructure. We will update this page if that changes.
Ollama model selection: which model for which KVM plan
The page covers the concept. Here is the specific model-to-plan mapping based on RAM requirements. Model sizes are approximate for standard quantization (Q4_K_M, the common default):
| Model size | RAM needed | Example models | Minimum KVM plan |
|---|---|---|---|
| 1B-3B parameters | 2-4 GB | Llama 3.2 1B/3B, Qwen 2.5 1.5B | KVM 1 (4 GB) |
| 7B-8B parameters | 6-10 GB | Llama 3.1 8B, Mistral 7B, Qwen 2.5 7B | KVM 2 (8 GB) |
| 13B-14B parameters | 10-16 GB | Qwen 2.5 14B, Phi 4 14B | KVM 4 (16 GB) |
| 27B-32B parameters | 20-32 GB | Qwen 2.5 32B, Gemma 27B | KVM 8 (32 GB) |
| 70B parameters | 40-80 GB | Llama 3.3 70B | Not practical on Hostinger VPS |
Critical nuance: the OS, Docker, and Ollama itself consume 1-2 GB before the model loads. A 7B model needing 8 GB of RAM on a KVM 2 plan with 8 GB total will struggle. Size one tier above the model's bare requirement, or use a smaller quantization. The 70B row is honest about the ceiling: even KVM 8 cannot comfortably serve 70B models. That workload belongs on a GPU cloud.
Quantization explained: what Q4, Q8, and F16 mean for your RAM
Quantization is how large models fit into limited RAM. It reduces the numerical precision of the model's weights, trading a small quality loss for dramatically lower memory:
- F16 (full precision): the original model. Highest quality, highest RAM. A 7B model needs roughly 14 GB. Impractical on most VPS plans.
- Q8 (8-bit): near-identical quality to F16 for most tasks, roughly half the RAM. A 7B model needs about 8 GB. The quality-conscious choice when RAM allows.
- Q4_K_M (4-bit): the Ollama default. Slight quality degradation that most users never notice in practice, roughly one-third the RAM of F16. A 7B model fits in about 5 GB. This is why the table above works.
- Q2/Q3 (aggressive): significant quality loss, but models fit in remarkably small RAM. Useful for experimentation, not for production quality.
Practical rule: start with the Ollama default (Q4_K_M). If responses seem degraded for your specific task, try Q8 on the same model before jumping to a larger model. A 7B model at Q8 often outperforms an 8B model at Q4 on quality-sensitive tasks, and the RAM math is similar.
RAG on CPU: a practical architecture
Retrieval-augmented generation (chat with your documents) is one of the best CPU-friendly AI workloads because the heavy lifting is search, not generation:
- Embeddings on CPU are fast enough. Embedding models (nomic-embed-text, mxbai-embed-large) are small, typically under 1 GB. They encode documents into vectors quickly even on shared vCPUs. This step is not the bottleneck.
- Vector storage is just a database. Use Qdrant, ChromaDB, or pgvector (PostgreSQL extension) in Docker alongside Ollama. For collections under a million documents, any of these run fine on KVM 2.
- Generation is the slow step. When a user asks a question, the system retrieves relevant chunks and asks the LLM to synthesize an answer. On CPU, a 7B model generates a few tokens per second. For a personal knowledge base with one user, this is acceptable. For multiple concurrent users, it queues badly.
- Chunking matters more than model size. Well-chunked documents with good embeddings and a 3B model outperform poorly-chunked documents with an 8B model. Invest effort in document preprocessing, not model size.
This architecture runs comfortably on KVM 2 for personal and small-team use. The n8n sizing guide covers the adjacent pattern of AI-augmented workflows.
When CPU inference breaks: recognizing the limits
Specific failure modes that tell you CPU is no longer enough:
- Interactive latency. If users wait more than 10 seconds for a response to start, the experience is broken. This happens with 7B+ models on shared vCPUs under any concurrent load. Either reduce to a smaller model or move to GPU inference.
- Context window pressure. Long documents and extended conversations consume context window, which increases RAM usage and slows generation further. A 7B model with a 32K context window on CPU is painfully slow. Keep contexts short or accept GPU costs.
- Batch processing backlogs. Nightly document processing that takes 8 hours on CPU might take 20 minutes on GPU. When the batch window exceeds the available night, it is time to burst to GPU.
- Fine-tuning. Do not attempt fine-tuning on CPU. Even parameter-efficient methods (LoRA) are impractically slow without GPU acceleration. This workload goes to RunPod or Lambda from the start.
The honest summary: CPU inference on a Hostinger VPS covers personal assistants, background processing, embeddings, and prototyping. Everything interactive at scale, everything with large contexts, and all training workloads need GPU infrastructure. The hybrid architecture on this page (VPS app plus GPU inference API) remains the sweet spot for most production applications.