smitty

The answer to your question is, it depends on your expectations. The tradeoff of a typical no VRAM machine is latency and quality.

My progression:

• I decided to try ollama and ran a small model on 8G RAM on a VPS. Slow but it worked. Ran an 3B parameter models – slowly. Struggled with 8B models. Problems with hallucinations from these small models. This was my induction into self hosting llms.
• Installed similar setup on a SFF desktop with 16G RAM. Ran 8B models slowly. More capability, but still below the threshold I was looking for. Open WebUI + ollama worked but still too slow.
• Acquired a 16G VRAM card and installed in an old desktop with 16G RAM. This runs 12B models and crosses the threshold, in my opinion, of usability as an assistant. This setup runs Open WebUI, again reinforcing usability.
• Am I satisfied? No. I’d like bigger, faster meaning more VRAM, on a newer platform, but content enough now to continue experimenting with what I have.

In sum: Don’t expect low laitency multi-step reasoning/planning with a low resource / no VRAM machine. Anything close to what you can get online at reasonable speeds requires ample VRAM.

For a reality check … I did a quick run on those three machines as they are still active. What follows has been synthesized through a cloud based model from real data:

same prompt, three machines

Prompt: “Explain how a hash table works, including collisions, in about 250 words.”
Run once on each machine with ollama run <model> --verbose, all Q4_K_M quantization.

What stood out

• The GPU box generated about 4-5x faster than the SFF while running a model roughly 3x bigger.
• Both CPU-only machines landed at 5-7 t/s. Usable, but slow for interactive chat.
• Turning thinking off on the 12B cut total time from 38s to 11.5s with no change in speed (~31 t/s) and no drop in answer quality on this prompt. Thinking would likely matter more for math, code, or multi-step problems, which this test doesn’t cover.
• The 12B had no factual slips. The smaller models made small conceptual errors (blurring hash code vs. index, calling the whole array a “bucket”) and one skipped lookup entirely.
• All of them left out worst-case O(n) behavior and resizing.

Caveats

• Different models on each machine, so this shows what each box can run well, not identical hardware running identical software.
• The thinking-on run generated about 1,180 tokens versus about 350 with thinking off, so compare tokens/sec rather than total time across those two rows.
• Quality scores are my rough 1-5 ratings on accuracy, length, completeness and cleanliness, with an LLM’s help, from one run each at temperature 1. Treat them as anecdotal, not a benchmark.
• gemma3n is listed by Ollama as 6.9B, but it uses an “effective parameter” design (Google calls it E4B, roughly 4B in practice), so it’s lighter than a dense 7B. That’s why it ran on the 8 GB VPS where a standard 8B struggled.

In the U.S. timezones were developed by the railroads before being written into law to keep the train traffic moving. I think they even called it railroad time. Back in the day when the big clock in town meant something … Imagine everyone setting 12:00 (noon) or ‘high noon’ with the sun directly overhead! There was no standard time nor timezones before we began traveling faster than the sun.