AI and cloud GPUs for e-commerce

Running models yourself instead of calling a hosted API comes down to two questions: will the model fit, and will the GPU be busy? Fit is about VRAM. An 8B-parameter model needs about 6 GB at 4-bit quantization and roughly 16 GB or more at 16-bit, so the model and precision decide the smallest card you can use. Utilization decides the bill. A GPU rented by the hour costs the same whether it serves one request or thousands, so batch jobs such as rewriting catalog descriptions or classifying reviews suit per-second billing that stops when the job ends. A service that answers customers all day needs a machine that stays up, with the networking and regions of a normal cloud.

RunPod vs Vultr follows that split. RunPod is usually cheaper per GPU hour, bills per second and offers the widest range of consumer and data center cards, which fits experiments and batch inference. Vultr costs more per hour but gives full VMs, private networking and 30+ locations for production services. Deploying a private LLM covers serving. Use Ollama for simple single-user setups, and vLLM for high-throughput serving with an OpenAI-compatible API. In both cases, keep the model's port closed and reach it through an SSH tunnel or an authenticated reverse proxy. An open inference port is the most common mistake on a rented GPU.

Most store automation doesn't need a GPU at all. Self-hosted n8n on a small VPS runs workflows with Docker Compose, Postgres and HTTPS through Caddy on about 2 GB of RAM. It also covers what must be backed up (the database and the encryption key) and what the licence allows (internal business use, not reselling n8n as a hosted service). The older guides in this topic go further: fine-tuning with QLoRA, self-hosting FLUX and ComfyUI for product images, and running agent frameworks on a Linux server. Read them with the same two questions in mind: what has to fit in memory, and how many hours a day the hardware will be doing paid work.