Running both n8n and Ollama (with a Large Language Model) on a single VM requires a careful balance of resources. The primary bottleneck will be the LLM you choose to run via Ollama, as RAM and CPU/GPU requirements vary wildly between a small model (like Phi-3 or Llama 3.2 1B) and a medium model (like Llama 3.1 8B).
Hi @Elimelikeli Welcome!
Clock speed is not what limits token generation, memory bandwidth is, so a 3.5 GHz core buys you very little over a 2.5 GHz one on the same RAM. Anything modern at 2.5 GHz or above is fine. Give the VM physical cores rather than hyperthreaded vCPUs, and expect the gains to flatten around the physical core count, usually near 8, past which extra threads mostly add overhead.
What changes Ollama’s speed far more than GHz is the guest CPU type. On Proxmox or plain KVM the default generic model hides AVX and AVX2 from the guest, so Ollama drops to its slow path and logs “CPU does not have minimum vector extensions”, which also disables GPU inference if you add a card later. Set the VM CPU type to host, or x86-64-v3 if you need live migration, then confirm it inside the VM:
Ubuntu Server 24.04 LTS is the safest OS choice here, since it has the best out-of-box Docker and NVIDIA driver support if you ever add a GPU passthrough later, and most n8n/Ollama Docker guides assume it. For a baseline VM without knowing your host hardware yet, start with 4-8 physical CPU cores (not hyperthreaded vCPUs), 16 GB RAM minimum (32 GB if you plan to run a 13B+ model), 100 GB disk for the OS plus model weights, and a virtio NIC for best throughput under KVM/Proxmox. Set the VM CPU type to host as Anshul mentioned, since that also determines whether a 7B model runs usably or falls back to the slow path. Install Docker, pull an 8B-class model like llama3.1:8b first, and watch RAM/CPU usage with htop during a test prompt to see if you need to scale up.
