Reame - Self-hosted LLM inference on the hardware you already have

by
Reame is a CPU-first LLM inference server on llama.cpp with an OpenAI-compatible API. Built for narrow, repetitive workloads on cheap hardware — a €5 VPS, a free tier, a 2-core ARM box. Its memory layer caches prompts, prefixes and past generations to disk, so request #100 costs a fraction of request #1. MIT.

Add a comment

Replies

Best
I kept hitting the same wall: I had narrow, repetitive AI work — extracting fields from documents, classifying tickets, tagging products in batches — and every option pushed me toward a metered API or a GPU I didn't want to rent. But these workloads don't need frontier reasoning. The answer lives in the context you already provide. That's exactly where a small model on a cheap CPU is enough — if the server stops treating every request as brand new. So Reame is built on one rule: on a CPU, never compute the same thing twice. A persistent shared-prefix KV cache — prompt prefixes are snapshotted to disk and reused across different prompts, restarts and processes. A system prompt is paid for once, by the first user. Palimpsest — every generation feeds an on-disk archive that drafts future tokens for free. Domain workloads repeat; let them pay off. Self-regulating speculation — it measures whether speculation pays on your hardware and turns itself off when it doesn't. ARCA — a Redis-compatible shared-memory daemon so a fleet shares an exact cache and a generation corpus. One config line wires a node to it. An OpenAI-compatible API — point any OpenAI client at it. reame run qwen2.5-1.5b --serve and you have an endpoint. What it is not: a ChatGPT replacement. Frontier reasoning and broad knowledge need frontier parameter counts. Reame is for the narrow, repetitive, private-data cases — and it says so. Everything is measured on real hardware, including the results that hurt: a 30B-class MoE that answered perfectly and 10× too slow; oversubscribed vCPUs where speculation backfires (so Reame disables it); consensus voting that fixes variance but not a model's actual reasoning gap. Benchmarks that only show wins are advertising — these aren't. MIT-licensed, C++17, 254 isolated tests, CI on Linux + macOS, prebuilt binaries Homebrew. Repo: I'd love to hear: what repetitive LLM workload are you running (or would run) on cheap hardware, and what's stopping you today? I answer everything here.

finally something for tiny boxes like my old VPS. The disk cache thing actually works, like the second request comes back way faster and barely touches CPU.

One thing that would make this way more useful for me: built-in support for batched inference across multiple cached prompts. Right now I assume requests still queue one at a time, but if the memory layer already knows the prefixes, batching the matching ones together could really cut down latency on bursty workloads.

Honestly impressed it actually runs on a 5 euro VPS without choking, and the cached prefixes made repeat calls nearly instant on my end.

Memory layer caching is a clever way to keep costs down on tiny boxes. One thing that would help me adopt it faster is a built-in warmup script that pre-decodes common prompt prefixes after a restart, so the first real request after deploy doesn't eat the cold-cache penalty and wreck latency on smaller instances.