The AZMX inference engine

A context is an object, not a buffer.

llamay runs GGUF models on your machine from one Go binary, and lets you fork a conversation, write it to disk, and pick it up on another machine. Every other engine recomputes the prompt.

macOS and Linux. On Windows: irm https://llamay.com/install.ps1 | iex. No account, no card, nothing leaves the machine.

one static binary no cgo, no Python 17 architectures 23 formats CPU · Metal · CUDA · Vulkan OpenAI · Anthropic · Ollama APIs

Three commands

The whole first session.

Install, pull a model, talk to it. llamay has its own store and its own downloader, so nothing else has to be installed first — and it reads a model Ollama already pulled, as a courtesy rather than a dependency.

serve with no -m takes the first model in your store and listens on 127.0.0.1:11435 — beside Ollama's 11434, and deliberately away from 8081.

The five-minute quickstart →
terminal
$ llamay pull qwen2.5:0.5b
pulling manifest
pulling c5396e06af29
  [========================] 100.0%  379.4 MiB / 379.4 MiB  (26.7 MiB/s)
verifying sha256 digest
stored qwen2.5:0.5b (379.4 MiB)

$ llamay run -m qwen2.5:0.5b -p "The capital of France is"
Paris. It has been the capital since 987, when Hugh Capet…

$ llamay serve
llamay v0.4.0  metal+accelerate  17 architectures
listening on http://127.0.0.1:11435

What you get

An engine you can audit, in a binary you can copy.

No CGo and nothing outside the Go standard library on the default build. The GPU backends are one build tag each.

The idea

Agents branch. A linear cache makes them pay for it.

Inference engines treat a context as memory inside a process. That is right for a chatbot and wrong for an agent, because agents do not run forward in a line — they branch, backtrack and resume.

THE SHARED PROMPT — COMPUTED ONCE page 0 page 1 page 2 refcount 3 · one copy in memory · 64 positions to a page FORK A appends · new page FORK B appends · new page FORK C rewrites page 2 · clones it WHAT THE FORK ITSELF COST 0 pages allocated a copying implementation needs 256 for the same eight branches the copy happens on a write, in one function, and nowhere else AND THE SAME THING ON DISK snapshot pages + weight digest + CRC restore refuses a different model 91× faster than re-prefilling a 512-token context and the ratio grows with context length, which is the whole point
Positions live in fixed-size pages, so two contexts can point at the same page. Everything else — the prefix tree, the fork, the snapshot — is built on that one fact.

The prefix tree

A radix tree over token sequences returns the longest prefix already computed. Only the new suffix is prefilled — which is what agent traffic is, the same system prompt with one more turn on the end.

Copy on write

A fork copies the page-pointer slice and increments refcounts. A page is cloned only when a branch writes to one whose refcount is above one.

Snapshots that refuse

The digest of the weights is recorded and checked on load. KV computed under different weights is not detectably wrong at generation time — it produces confident nonsense — so it fails at load instead.

Proved against a stupid twin

A reference implementation that shares nothing runs beside it in lockstep, under randomised operation sequences, with the full invariant set asserted after every single step.

How the state engine works, in full →

Measured

Including the column where it loses.

llamay's x86 prefill beats llama.cpp on three of four models. Its decode loses on every platform tested. Those are different problems and the table keeps them apart.

Linux, 18 threads, AVX2, no GPU anywhere in the container. Four models, A/B/A/B interleaved, medians.
Model llamay prefill llama.cpp llamay decode llama.cpp
qwen2.5-0.5b94.367.11.41×7.630.00.25×
llama-3.2-1b52.834.21.54×3.018.40.16×
gemma-3-1b68.133.72.02×5.517.20.32×
gpt2-124m261.61060.40.25×24.5213.10.11×
0 pagesallocated by forking a 32-page context eight ways
91×faster to restore a 512-token context than to re-prefill it
0.014–0.488%of llama.cpp's perplexity on the eight architectures that clear the gate
68%of llama.cpp's decode rate on an M4 — the number that loses
gpt2 is the same defect twice

It is the one x86 row llamay loses badly, and the one model whose perplexity is 4.67% off llama.cpp's where every other architecture tested is inside 1.3%. Both llamay kernel sets agree with each other exactly on it, which puts the fault in the gpt2 block rather than in a SIMD path. It is the next thing to fix, not a footnote.

Every round of every measurement, the commands that produced them, and the two ways this benchmark lies if taken casually, are in the throughput page.

Drop-in

The two APIs your client already speaks — and one it does not.

OpenAI and Anthropic are implemented because those are what everything is written against. Ollama's is implemented in its own shapes — newline-delimited JSON, streaming on by default, durations in nanoseconds — so a client written for it can be pointed here by changing a URL, and then uninstall what it was written for.

The context routes have no counterpart anywhere. They are the point.

Every route, with its body →
fork one prompt four ways
$ curl -X POST localhost:11435/v1/contexts \
    -d '{"prompt":"<the long system prompt>"}'
{"id":"ctx_1","tokens":14,"pages":1}

$ curl -X POST 'localhost:11435/v1/contexts/ctx_1/fork?n=4'
# 4 branches, each holding all 14 tokens, sharing the parent's page

$ llamay ctx fork -m model.gguf -i base.llamayctx -n 8 -o branches/
source                    base.llamayctx, 46 tokens, 1 pages
branches                  8 in 19µs (2µs each)
pages allocated           0
pages a copy would need   8
memory held               128.00 KiB (a copy would be 1.00 MiB)

Before you install

What it does not do.

A list of what an engine cannot do is more useful than a list of what it can, and it is the first thing anyone finds out anyway.

It decodes slower than llama.cpp

On an M4, 68% of llama.cpp's decode rate and 64% of Ollama's. llama-server remains the right answer when raw single-stream throughput is all that matters. Shipping both is a feature.

Two models need the exact KV cache

gpt-oss and phi3-mini exceed the 5% total-variation bound under vq8. Run them with -kv f32; llamay verify says so per file.

No Mamba, no vision encoder

State-space models are declined at load rather than approximated. DeepSeek-V2 and V3 are refused by name: latent attention changes what a KV page holds, which is the allocator, the fork and the snapshot format, not the attention alone.

The GUI is macOS only

The chat window ships for macOS today. On Windows and Linux llamay is a CLI and a server, which is the whole surface either way.

The i-quants are read, not written

IQ2, IQ3 and IQ4 load and run on the portable Go kernels only. llamay quantize will not produce one: picking grid points well is a search against an importance matrix, and a bad i-quantiser is worse than none.

Nothing is sent anywhere

Not a limitation, but it belongs in the same list. The server listens on loopback and no provider is configured until you add one. There is no llamay registry and there will not be one.

Install it in one line.

Free, open source, and everything runs on your machine.