How a token becomes an answer (inference pipeline)

Your message goes through five stages before you see a reply: tokenization, prompt formatting, prefill, generation, detokenization.

Short answer

Your message goes through five stages before you see a reply: tokenization, prompt formatting, prefill, generation, detokenization. The pulsing cat represents generation. The wait before it appears is prefill.

Detailed explanation

1. Tokenization. Your message (“How are you?”) is split into small chunks called tokens (“How”, ” are”, ” you”, ”?”). Every model has its own tokenizer baked into the GGUF file. English averages ~0.75 words per token; Russian, Chinese, code all have different ratios.

2. Prompt formatting. The tokenized message is wrapped in the model’s chat template. Llama 3 uses <|start_header_id|>user<|end_header_id|>...<|eot_id|>. Qwen uses <|im_start|>user\n...<|im_end|>. Getting this wrong is the #1 cause of “the model produces gibberish” - Abliteration auto-detects the template from the GGUF.

3. Prefill. The model reads the entire formatted prompt at once (including all previous messages in the chat, plus system prompt) and builds up its KV cache. This is fast per token but there are many tokens, so on CPU it takes 0.5-5 seconds for a fresh chat and can be 10+ seconds if the chat is long. During prefill, you see the “Loading…” or “Thinking…” indicator with no visible output.

4. Generation. The model produces tokens one at a time, each token conditioned on everything before it. This is the phase where tokens per second (tok/s) is measured. The pulsing cat + streaming text you see is generation happening live.

5. Detokenization. As tokens stream in, they’re converted back into human-readable text and displayed. This is instant - no visible cost.

Reasoning models (DeepSeek R1, Qwen QwQ) add a hidden phase: they generate <think>...</think> tokens first (visible in Abliteration as the collapsible R block), then the final answer. From the pipeline’s perspective this is all just generation - it’s the model choosing to spend tokens on internal reasoning before answering.

Why it matters

Understanding where time goes helps you diagnose speed issues. Long “loading…” with no output = prefill on a long chat (or slow disk swap). Slow token streaming after that = generation-bound (CPU speed, model size). Weird symbols in output = tokenization/template mismatch. Sudden freeze mid-generation = usually RAM exhaustion (KV cache hit a wall).

In Abliteration specifically

The generating state shows two indicators simultaneously: a “Loading {Model Name}…” or “Generating…” text label, and a small pulsing cat animation. Both appear together - not one or the other.

Cancel (Stop button) behavior differs by stage: during generation (stage 4), pressing Stop halts cleanly and keeps whatever was already streamed. During model load or prefill (stages 1-3), the cancel request is not honored - Abliteration waits for prefill to complete before it can honor the stop. This can mean a several-second delay on a long chat between clicking Stop and generation actually halting.

The tok/s shown in the model info tooltip is an estimate for stage 4 only. It ignores prefill time, which is why a 45 tok/s model can still feel slow if you’re pasting a huge chat history - you’re paying a big prefill cost before the 45 tok/s clock starts.

Catalog is the map. Apps are the tools.

Run models on your own machine, not in the cloud.

Every model page has an "Open in Abliteration" button that hands the model directly to the first-party desktop client, at the quantization your rig can actually run. No API keys, no subscription, no prompt leakage.

Open in Abliteration