Edelhack.de — English

Why does an LLM hallucinate?

Mirco Blitz — Mon, 05 Oct 2026 00:00:00 GMT

The previous chapter explained how a language model selects its next continuation. None of those controls checks whether a claim is true. An LLM can therefore produce a fluent answer containing a false detail. The usual term for this is hallucination. In research, it commonly means a plausible but false statement. It describes a kind of error, not something the model perceives. [1]

What the word obscures

A person may hallucinate because they perceive something that is not there. An LLM does not perceive things in that sense. It generates text. Even the paper Why Language Models Hallucinate explicitly distinguishes its technical term from human perception. [1]

The word can make an error sound like a curious quirk. For someone relying on an answer, what matters is which claim is false or unsupported and what might follow from it. “Hallucination” is an established research term, but it does not replace naming the error or checking the claim. Nor is every model failure a hallucination. Breaking a formatting instruction or stopping mid-sentence is different from confidently presenting a false fact. [1]

How a false detail gets into an answer

In training, an LLM learns how text usually continues. It is not reliably taught whether every claim it encounters is true. Ask for a little-known birthday and it may supply an exact date without a sound basis for it. Choosing the most likely continuation every time would not make that answer true. [1] [2]

Further training can reduce these errors. But tests also affect which answers are rewarded. If “I don't know” earns the same score as a wrong answer, guessing can improve the score. The model is not consciously bluffing. It is rewarded for a kind of answer that can sound plausible yet be wrong. [1] [2]

What does a “hallucination rate” mean?

A false statement is an error. An error rate tells us how many cases were wrong among the cases counted. A bare figure such as “40% hallucinations” does not tell us whether 40 out of 100 answers were wrong. We need to know what was counted.

In 2025, Artificial Analysis tested models on 6,000 difficult knowledge questions. Its historical chart reports a 51% “Hallucination Rate” for GPT-5.1 (high). To calculate this figure, correct answers are set aside first. Of the remaining cases – wrong answers, partial answers and no answer – 51% were wrong. It is not 51% of all questions, nor a general failure rate for ChatGPT in everyday use. [3] [4]

That does not make the wrong answers harmless. If people need reliable information, what matters is how often a false claim appears and what harm it could cause. A number is useful only alongside the task and the way it was counted.

What this means in practice

Using an LLM to explore an unfamiliar subject can make a false explanation especially easy to accept. The less someone knows about the subject, the harder it is to spot an answer leading them down the wrong path. An LLM is therefore of limited use as the sole source for factual questions. Its answers may raise useful questions, but important claims should be checked against independent sources.

An LLM is better suited to work where the result can be tested. A small code change can be run and tested, for example, and a specific calculation can be checked. Even then, those checks may miss something. Complex code and mathematical proofs can be difficult to assess. The harder a claim is to verify, the more cautiously it should be used. A convincing explanation is not evidence.

The context window also matters when planning a task. In the author's experience, larger and more heavily filled context windows have brought more plausible false claims and more drift away from the task. Outdated approaches, long outputs and contradictions can bury important details. This is a personal observation, not a generally measured error rate or a fixed threshold. It helps to refocus the work in good time around current requirements and relevant sources – perhaps with a careful summary or a fresh session with a focused handover. [5]

In the next chapter

Important claims need evidence. How can software find relevant passages for a question and give them to an LLM? The next chapter introduces embeddings and RAG, exploring what additional sources can help with and what still needs checking.

Deeper into the Rabbit Hole

Video in English

IBM Technology — Why Large Language Models Hallucinate — in just under ten minutes, Martin Keen uses examples to explain unreliable answers and ways to reduce them. The complete English transcript was read; the full video was not watched. It uses “hallucination” more broadly than this chapter, including contradictions with the prompt or within an answer. Its advice on temperature and prompting does not guarantee factual accuracy.

Sources

Kalai et al., Why Language Models Hallucinate, September 2025 preprint. The abstract, introduction and relevant sections on pretraining and evaluation were read. The authors explicitly distinguish the term from human perception.
OpenAI, Why language models hallucinate, 5 September 2025. A research explanation of false factual claims, pretraining and incentives created by accuracy-based grading; it does not measure every application independently.
Artificial Analysis, AA-Omniscience: Knowledge and Hallucination Benchmark, 16 November 2025. Historical analysis and chart including GPT-5.1 (high). The article's shorthand description simplifies the denominator.
Artificial Analysis, AA-Omniscience evaluation. Methodology page defining the rate more precisely as “incorrect / (incorrect + partial answers + not attempted)”. The current dashboard need not show the same selection of models as the historical chart.
Anthropic, Effective context engineering for AI agents. A practical discussion of selecting relevant information in long-running work, not a general measurement of hallucination rates by context length.

Is the LLM cold? Temperature and other controls for generating text

Mirco Blitz — Fri, 02 Oct 2026 00:00:00 GMT

As we showed in “How does an LLM work?”, a response takes shape one token at a time. We can picture the choice of the next piece of text as a weighted dice roll. Likely continuations receive more dice numbers than unlikely ones. The temperature setting changes this weighting. It determines how strongly the favourites are favoured when we roll. [1]

As in article 01, we simplify the example by treating whole words as tokens. Real tokens can also be parts of words or punctuation. Our twenty-sided die, or W20, represents random selection from calculated probabilities. There is no physical die inside the computer.

Temperature changes the weighting

We start again with “My cat has”. In our invented example, “arrived” is the most likely continuation. A low temperature gives this favourite a stronger advantage. It receives a larger range of numbers on our W20, while less likely continuations receive smaller ranges.

At a higher temperature, the differences become smaller. Weaker candidates get more chances, but the favourite remains the favourite. Temperature does not reverse the ranking. A less likely word is not automatically better or particularly creative. [1]

The image compares temperatures of 0.5, 1 and 2. At 1, the original weighting is unchanged. That does not mean 1 is the default in every application. We use the same roll of 9 in all three columns to make the changed ranges visible. [2]

Image content as text

All three columns start with “My cat has”. The continuations, in the same order, are “arrived”, “a”, “bitten”, “been”, “never” and other possibilities.

Temperature 0.5. The ranges are 1 to 10, 11 to 14, 15 to 16, 17 to 18, 19 and 20. The roll of 9 selects “arrived”.
Temperature 1. The ranges are 1 to 6, 7 to 10, 11 to 13, 14 to 16, 17 to 18 and 19 to 20. The roll of 9 selects “a”.
Temperature 2. The ranges are 1 to 4, 5 to 8, 9 to 11, 12 to 14, 15 to 16 and 17 to 20. The roll of 9 selects “bitten”.

The original probabilities are invented: 30%, 20%, 15%, 15% and 10% for the five named words, plus 5% each for two other candidates. Temperature is applied to the individual candidates before the two others are grouped together. The ranges are rounded to 20 dice numbers. These are not measurements from a model.

Here, weighting the roll means changing the selection probabilities, not the model weights stored during training. Temperature is not a control for intelligence or truth. At temperature 0, many applications choose the most likely continuation instead of making a random selection. That does not guarantee identical complete responses in every environment. [2]

Top-p limits the selection

While temperature changes the weighting, top-p determines which continuations are considered at all. Candidates are ordered by probability. Starting with the favourite, enough are included for their combined probability to reach at least the chosen value. [3]

At top-p = 0.8, our example keeps “arrived” at 30%, “a” at 20%, and “bitten” and “been” at 15% each. Together they reach 80%. “Never” and the other possibilities are excluded for this step.

The remaining probabilities are rescaled to add up to 100%. They do not become equal. “Arrived” remains more likely than “a”. Top-p = 0.8 therefore does not mean keeping 80% of all tokens. Depending on the distribution, it may take a few candidates or many to reach the threshold. At top-p = 1, this restriction is disabled. [2] [3]

Image content as text

Both columns start with “My cat has” at temperature 1. The invented original probabilities are “arrived” 30%, “a” 20%, “bitten” 15%, “been” 15%, “never” 10% and other possibilities totalling 10%.

Top-p 1 keeps all candidates. The ranges are 1 to 6 for “arrived”, 7 to 10 for “a”, 11 to 13 for “bitten”, 14 to 16 for “been”, 17 to 18 for “never” and 19 to 20 for other possibilities.
Top-p 0.8 reaches 80% after “been”. “Never” and other possibilities are crossed out. After rescaling to 100%, the rounded ranges are 1 to 8 for “arrived”, 9 to 13 for “a”, 14 to 17 for “bitten” and 18 to 20 for “been”.

Both dice show 9 and select “a”. A changed filter does not have to produce a different result on a single roll. All examples are invented and rounded to 20 outcomes.

Top-k limits the number

Top-k determines how many of the most likely continuations remain eligible. At top-k = 2, our example keeps only “arrived” and “a”. Unlike top-p, top-k sets a fixed number rather than a probability threshold. [2]

The other continuations are excluded. The two favourites' probabilities are rescaled to add up to 100%, but remain different. On our W20, “arrived” now receives twelve numbers and “a” eight.

Image content as text

Without top-k, all candidates remain. The ranges are 1 to 6 for “arrived”, 7 to 10 for “a”, 11 to 13 for “bitten”, 14 to 16 for “been”, 17 to 18 for “never” and 19 to 20 for other possibilities.
Top-k 2 keeps only “arrived” and “a”. The other four rows are crossed out. The probabilities are rescaled from a combined 50% to 100%. “Arrived” receives 60% and numbers 1 to 12; “a” receives 40% and numbers 13 to 20.

Both dice show 9. Without the filter, “a” is selected; with top-k 2, “arrived” is selected. This is an invented example, not a model measurement.

Min-p compares with the favourite

Min-p sets how likely a continuation must be compared with the favourite. At min-p = 0.5, it must be at least half as likely. If “arrived” has a 30% chance, all continuations with at least a 15% chance remain eligible. [2]

Weaker candidates are excluded. The remaining probabilities are again rescaled to add up to 100%. Unlike top-k, min-p does not set a fixed number. Its threshold depends on the current favourite's probability at each step.

Image content as text

Without min-p, all candidates remain. The ranges are 1 to 6 for “arrived”, 7 to 10 for “a”, 11 to 13 for “bitten”, 14 to 16 for “been”, 17 to 18 for “never” and 19 to 20 for other possibilities.
At min-p 0.5, “arrived” at 30% is marked as the favourite. Half of that gives a minimum probability of 15%. “Arrived”, “a”, “bitten” and “been” remain. “Never” and other possibilities fall below the threshold and are crossed out.
The remaining probabilities are rescaled to 100%. The rounded ranges are 1 to 8 for “arrived”, 9 to 13 for “a”, 14 to 17 for “bitten” and 18 to 20 for “been”.

Both dice show 9 and select “a”. Min-p and top-p happen to retain the same candidates in this example, but use different thresholds. All values are invented and rounded to 20 dice numbers.

Two settings, different jobs

Temperature changes how strongly the most likely continuations are favoured. Top-p limits which continuations take part in the selection at all. When both are used together, temperature first changes the weighting. Top-p then applies its threshold. [1] [3]

In our dice example, temperature changes the number ranges. Top-p then removes continuations outside its threshold and redistributes the dice numbers among the remaining possibilities. The same top-p value can therefore retain different numbers of candidates at different temperatures.

There are no universally best values. Which settings produce useful results depends on the model and the task. When experimenting, changing one setting at a time makes its effect easier to recognise. The available controls and the way multiple filters are combined depend on the software.

In the next chapter

Both settings influence selection, but neither checks facts. Even a highly probable continuation can be wrong. In the next article, “Why does an LLM hallucinate?”, we will look at why LLMs produce such claims and can sound convincing while doing so.

Deeper into the Rabbit Hole

Videos in English

3Blue1Brown — Transformers, the tech behind LLMs — a visual introduction to the foundations of token selection and temperature. The corresponding text adaptation was read for this article.
Gary Explains — The Secret Controls for your LLM: Temperature, Top-K, Top-P, etc — around 15 minutes on temperature, top-p and other sampling controls. The video is sponsored by Genspark. Its title and description were checked, not the complete video.

Texts

3Blue1Brown — Transformers, the tech behind LLMs — the illustrated text adaptation explains how calculated scores become selection probabilities and how temperature changes them.
Holtzman et al. — The Curious Case of Neural Text Degeneration — the original research paper on top-p, also called nucleus sampling. Section 3.1 explains the selection threshold using equations. Its results come from experiments with models of the time and do not guarantee the quality of today's LLMs.

Sources

3Blue1Brown — Transformers, the tech behind LLMs. Explanation by Grant Sanderson, text adaptation by Justin Sun. The sections on token selection, softmax and temperature were read.
vLLM — SamplingParams. Parameter descriptions for temperature, top-p, top-k and min-p. This documentation describes that software, not every application.
Holtzman et al. — The Curious Case of Neural Text Degeneration. ICLR 2020. The abstract and relevant excerpts from sections 3.1 and 3.2 were read, not the entire paper.

What is a context window?

Mirco Blitz — Fri, 02 Oct 2026 00:00:00 GMT

As we saw in “How does an LLM work?”, each request to a language model is initially a self-contained operation. Why, then, does a chat seem as though the machine remembers our conversation? Because the software includes earlier messages with each new request. The context window limits how much the model can process at once. Its size is measured in tokens. [1]

The available context window depends on the model and the server settings. Some models can process around 8,000 tokens at once; others can handle a million or more. The server can further restrict the usable size. The following illustrations show what goes into a context window and how it fills up during a conversation. [1] [2]

1. The first request

At the start, the context contains the system prompt with the basic instructions and your first message. There is no LLM response yet. Even this first request already occupies part of the window. [1]

Image description as text

The context window starts on the left with the blue system prompt and the gold first request. There is no model response yet. The rest of the bar shows available context. Time runs from left to right. Widths are schematic, not actual token measurements.

2. The conversation grows

The response adds more text. With the next request, the software includes the conversation so far alongside your new message. If the LLM uses tools, their calls and outputs also become part of the context. It grows with each round of conversation. Sending the conversation again does not give the model a lasting memory. [1]

Image description as text

The blue system prompt is followed by a gold request and a green response. A second request leads to a green model tool call, then a larger orange tool output and finally a green response. The tool call is model output, not tool output. Available context remains on the right. All widths are schematic, not token measurements.

3. What is still relevant?

Discarded approaches, outdated drafts and questions that have long since been resolved remain in the conversation. They take up space alongside the information needed for the current task. In a long or contradictory conversation, the LLM may overlook relevant details or follow existing instructions less reliably. This does not necessarily happen in every long chat, and the token count is not the only factor. [3]

Image description as text

The context window still contains the blue system prompt, two conversation rounds with a tool call and a larger tool output, plus another request. The first green response has a white dashed inner outline marking an out-of-date interim result. Newer information can supersede earlier interim results. The old content remains present. The mark indicates neither actual deletion nor automatic general drift. Widths are schematic, not token measurements.

4. The window fills up

The context cannot occupy all the available space if there is still a response to generate. Its tokens need room too. How much space is allowed for that response, and its maximum length, depend on the model and the software. The chat software or harness may also impose its own limit before the model's limit is reached. What happens to the conversation at that point depends on the software. [1] [2]

Image description as text

On the left are the blue system prompt and the existing conversation history, including the latest request. This existing content is the input. On the right, a subtly tinted block with a dashed white border illustrates space for the next response, which has not yet been generated. It is not existing model output or an actual size prediction. The schematic shows that the response also has to fit inside the limited context window. No fixed token values are given.

5. The Dumb Zone

This is my name for the point at which the context has become so tangled for my task that the responses become less precise or unusable. Where it starts depends on the task, the content and the server. In my experience, I reach this zone by around 70 to 80 per cent of the available context window at the latest. With larger context windows, I often notice it starting at 50 per cent. These are personal observations, not fixed technical limits. I want to reduce the context before I reach that point. Compaction or a session handoff are two ways to do that.

Image description as text

The blue system prompt is followed by two gold requests, green responses, a green tool call and an orange tool output. Available context remains on the right. Red hatching overlays its right-hand portion to mark the Dumb Zone. Its schematic starting point is a personal guide, not a universal threshold or technical limit. Actual usability depends on factors including the task and mix of context. The hatching is not reserved memory and does not imply automatic deterioration. Widths are schematic, not actual token measurements.

6. Compaction

During compaction, your harness or chat software asks the LLM to summarise the session so far. The software then replaces the old conversation in the context with that summary. This frees up space, and the conversation continues with the condensed context. Some harnesses let you guide compaction with your own prompts. How much of the work so far survives depends on the quality of the summary. [3] [4]

The illustration shows the basic idea. Depending on the harness, recent messages may also be retained alongside the summary. [4]

Image description as text

One context bar shows the same session after compaction. The blue system prompt is retained. A compact purple summary replaces the old conversation history, leaving substantially more available context. No new session is started. Red Dumb Zone hatching remains visible in the right-hand portion of the available context. Its schematic starting point is a personal guide, not a technical limit or memory reservation. All widths are schematic, not token measurements.

7. Session handoff

During a session handoff, the LLM prepares a handover for a new session. It records the current goal, the state of the work, important decisions and the next steps. The new session starts with this handover rather than the previous conversation. The emphasis is less on summarising the conversation and more on making it possible to continue the work. Here too, the result depends on which information is carried over and how reliably the handover describes it. [5]

One practical example is my project pi-blitz-handoff, which organises handoffs between Pi sessions. I introduce it in a separate article in the Pi.dev-Toolbelt collection.

Image description as text

Two equally wide context bars show two separate sessions. Above, session 1 contains the blue system prompt and its old history of requests, responses, a tool call and a tool output. The connecting arrow denotes summarising for the handoff. Below, session 2 begins only with a blue system prompt and a muted turquoise session handoff, followed by available context. There is neither a new user request nor an LLM response in the lower bar. The handoff transfers summarised information, not the entire old history. Both bars carry red Dumb Zone hatching in the right-hand portion of the available context. Its schematic starting point varies between the sessions. This personal guide is not a technical limit or memory reservation. Widths are schematic, not token measurements.

Compaction vs. handoff — a flamewar

There is no need to turn these approaches into rival camps. Compaction condenses the conversation so it can continue. A handoff shapes the context of a new session around the work ahead. Which approach fits depends on what you want to preserve and how the software handles it. Both can lose important details. Neither is better for every task.

In the next chapter

So far, we have looked at the information available to the model when it produces a response. How it selects the next token from the possible candidates is a different question. That is the subject of Chapter 08, “Is the LLM cold? Temperature and other controls for generating text”

Videos in English

IBM Technology — What is a Context Window? Unlocking LLM Secrets — Martin Keen explains tokens, self-attention and the challenges of limited context windows. Around 12 minutes.
Matt Pocock — Most devs don’t understand how context windows work — context limits when working with coding agents, the “lost in the middle” problem and managing long conversations. Around 10 minutes, with examples of compaction and extra context introduced by MCP servers.
Marina Wyss — Context Engineering in 29 Minutes: Complete Course — a longer overview of context strategies for agents, common failure modes and practical approaches. Around 29 minutes. The video is sponsored by Kimi.

Texts

Anthropic — Context windows — how messages, tool results and generated responses count towards the window. The details describe Claude, not every model.
Anthropic — Effective context engineering for AI agents — selecting useful context, compaction, external notes and subagents. An engineering perspective from one provider.
Liu et al. — Lost in the Middle — a study of retrieving information from long inputs. The abstract describes dependence on where relevant information appears. It does not establish a general 70 per cent limit. [6]

Sources

Anthropic — Context windows.
vLLM — Engine Arguments. Server configuration example.
Anthropic — Effective context engineering for AI agents.
Anthropic — Compaction overview.
Mirco Blitz — pi-blitz-handoff — README v1.2.4. Published product version 1.2.4.
Liu et al. — Lost in the Middle: How Language Models Use Long Contexts. Abstract read; the full paper was not reviewed for this article.

pi-blitz-handoff: Carrying work into a fresh context

Mirco Blitz — Thu, 01 Oct 2026 00:00:00 GMT

In Pi.dev-Toolbelt, I introduce tools for working with Pi. The first is my extension pi-blitz-handoff. It handles a transition that eventually comes up during longer tasks: the conversation context is filling up, but the work is not finished.

Context is the information available to the language model when it produces its next response. Over a long session, requirements, decisions, files, results and discarded approaches accumulate. They are not all equally useful for continuing the work. A resolved debugging detour can take up a lot of space. A brief restriction from the user, meanwhile, may determine what the agent is allowed to do next.

That is what pi-blitz-handoff is designed to address. The extension asks the model to write a focused handoff dossier and passes it to a fresh Pi session as its first prompt. Pi's native session linking connects the new session to its predecessor, keeping the original transcript accessible. [1]

What needs to carry over?

A useful handoff needs to say more than “We are working on a website”. What is the current task? Which decisions still apply? What has actually been checked, and what has merely been changed? Where is the current state recorded? What action is authorised next?

The supplied default template explicitly asks for these distinctions. It also records blockers, unresolved questions and work that still needs approval. Session-specific runtime information is kept separate from the inventory of loaded skills. [1]

This matters especially when the direction has changed during the work. A discarded approach must not reappear as an agreed decision. A successful build must not turn into a passed browser test. And “finish it locally” must not become “publish it” in the next session.

Why not just compact the context?

Compaction condenses the existing context so the session can continue. pi-blitz-handoff focuses on a different question: What does a new session need to continue this particular task correctly? The extension is designed to capture that continuation context more precisely. That is its purpose, not a guarantee that every handoff will outperform every compaction. [1]

The difference is in the instructions given to the model and the subsequent transfer to a fresh session. The model writes the dossier; the extension handles the session transition and delivers the text. This also makes the limitation clear: a technically successful transfer can still carry an incomplete or inaccurate dossier.

And “Blitz” is my surname, not a promise of speed. A detailed handoff may take longer than compaction. [1]

Starting a handoff

Install the extension through Pi's package manager: [1]

pi install npm:pi-blitz-handoff

Within Pi, /sh requests a handoff. The extension first asks the model to establish whether the work has reached a suitable point for the transition. During active collaboration, it can present a Ready / Wait / Cancel choice. Once readiness has been accepted, the dossier is written and passed to the new session. [1]

Handoffs can also be triggered automatically based on context usage. This is off by default. “Automatic” only describes how the handoff is initiated. Whether the replacement session works autonomously, asks a question or waits still depends on the existing instructions and authorisation. [1]

During the transfer itself, new prompts are held back and passed on in their original order. If an interrupted handoff leaves those inputs behind, /sh-recover lets you explicitly inspect, execute or discard them. Leftover inputs are never executed automatically. /sh-cancel cancels an active handoff until the native session replacement has begun. [1]

Adapting it to the work

The extension includes three template profiles: Fast, Balanced and Precise. They differ in how much detail they transfer and how much context the replacement session is expected to reconstruct. Precise is the default. Templates can be customised and selected per project with /sh-project-template. [1]

The extension therefore does not impose a particular workflow. A template describes what the handoff should preserve. It does not grant additional permission.

What it does not carry over

A dossier transfers information. It does not move running background agents or shell connections into the new session. Their state and ownership need to be checked against the actual runtime environment there.

Your data also remains your responsibility. Dossiers and deferred inputs may contain confidential project information and are processed or stored as plain text. The extension provides neither automatic secret detection nor encryption, and it is not a sandbox. Like other Pi extensions, it runs with the permissions of the Pi process. [1]

Version 1.2.4, described here, requires Node.js 22.19.0 or later, Pi 0.84.2 or later, and an interactive, persisted Pi session. Sessions using --no-session are not supported. The source code is available under the MIT licence. [1], [2], [3]

pi-blitz-handoff is not meant to hide the restart. It is meant to leave a clear record of where the work stands and how it is authorised to continue.

Sources

What does model size mean?

Mirco Blitz — Thu, 01 Oct 2026 00:00:00 GMT

What does the number count?

Weights are a kind of parameter. When people discuss LLMs, though, they often use the two terms to mean much the same thing. The number in a model's name gives its size; it does not count possible answers or built-in checks.

Even with Qwen3.8-27B, it is worth asking what the number includes. The official model card gives 27B for the language model. Qwen can also process images and videos and has another model component for this. The number in its name does not necessarily describe every part of the model. [1]

DeepSeek reports a total of 1.6 trillion parameters for V4-Pro. The announcement does not explain which model components are included in that count. The number alone therefore tells us neither how that total is made up nor whether the model performs better than Qwen on a particular task. [2]

As a thought experiment, a model could contain a language model component with 80 billion parameters alongside other components specialised for different tasks. The total would then combine all the parts included in the count. This is an example, not a claim about how any particular model is built. A model's total parameter count alone cannot tell us whether it is built this way.

The opening artwork turns the two models into weightlifters. Both raise a barbell despite their very different sizes. It is an illustration, not a performance test or evidence that they handle the same tasks equally well.

Why can a smaller model still do useful work?

Qwen3.8-27B is a complete model. It processes an input using its trained weights and calculates a continuation. The 27B figure does not restrict that calculation to a small set of words or simple answers. A locally quantised version stores many weights approximately and therefore needs less space. It still has roughly the same number of parameters. Whether a particular computer can run it, and how well it responds, are separate questions. [3]

More parameters can give a model greater capacity. They do not guarantee that it will use that capacity better for the task at hand. Its training data, the training itself and later instruction tuning also matter. One model may be well suited to a task even when another is much larger.

An older research comparison illustrates why size alone is not enough. Under a fixed training compute budget, a 70-billion-parameter model outperformed a 280-billion-parameter model on the tasks examined in the study. The smaller model had been trained on substantially more data. That does not prove smaller models are generally better; it shows the importance of training under those test conditions. [4]

What belongs to the model?

Some capabilities are built into the model. Qwen3.8-27B, for example, can process images and videos as input; alongside its language model it has a vision encoder. Translating or working across languages need not rely on a separate translation module. Such abilities can develop during training. The parameter count alone cannot tell us how well they work. [1]

Other functions often belong to the software around the model. It may retrieve relevant documents and supply them as additional text, call a tool to calculate something, or check an answer afterwards. None of that increases the model's parameter count. Such support can make a smaller model more useful; a larger one can use it too. A tool cannot, by itself, make an unreliable answer correct.

With the right tooling, I can get much further with a small model than I would have expected from its size alone.

So “27B versus 1.6 trillion” is not a results table. The figures help us understand the scale of models and some of their resource needs. Whether one does better at coding, translation or a specific question needs to be tested for that task. Training, architecture and tooling belong in that comparison, not size alone.

In the next chapter

Model size is not the amount of text a model can work with at once. What limits its context window?

Deeper into the Rabbit Hole

For a closer look at parameters and training, these texts go further:

3Blue1Brown – How might LLMs store facts? – an illustrated, more technical lesson with explicit simplifying assumptions and a written adaptation.
Hoffmann et al. – Training Compute-Optimal Large Language Models – research on model size, training data and compute. Research preprint.
Touvron et al. – LLaMA: Open and Efficient Foundation Language Models – a historical comparison of model sizes on the tasks tested in that paper. Research preprint.

Sources

Qwen – Qwen3.8-27B – Model Overview.
DeepSeek – DeepSeek V4 Preview Release. The parameter count is the manufacturer's figure; its performance claims are not adopted here.
Hugging Face Transformers – Optimizing LLMs for Speed and Memory.
Hoffmann et al. – Training Compute-Optimal Large Language Models. Research preprint; the comparison concerns the tasks reported in that study.

What is quantisation?

Mirco Blitz — Mon, 28 Sep 2026 00:00:00 GMT

From fine detail to coarser steps

The previous chapter asked a simple question: why does a language model need so much memory? Most of it is taken up by the model's weights. These are billions of numbers adjusted during training and used in its calculations. The model also needs working memory while generating an answer and space for information about the text processed so far.

We used Qwen3.8-27B as an example. It has roughly 27 billion weights. If each number were stored in 16 bits – two bytes – the weights alone would take up about 54 gigabytes. Not every computer has that much fast memory to spare for a model. Yet there are versions that run on some consumer devices. How is that possible?

Part of the answer is quantisation. It does not remove the weights. Instead, it stores approximate values using less space. The numbers used by the model change. So why can it still produce useful results? And when do those changes matter?

Picture a colourful graffiti mural. With many shades, the transitions across the face and hair are fine. With only a few colours available, you can still recognise the face and hair, but subtler differences disappear. The comparison directly below shows this visually. No pixels have been removed; the differences between the colours have become coarser.

16 bits

8 bits

4 bits

2 bits · four shades of grey

Visual example: The same image with progressively fewer colour shades. The final panel is shown in grey to make the difference clearer.

Image content as text

All four panels show the same close crop of a graffiti mural: a face in profile with closed eyes, flowing hair and leaves. The first two panels are colourful and differ only slightly. The third has larger areas of solid colour and fewer subtle transitions. The fourth uses only four shades of grey. The face and hair remain recognisable, but many small differences in colour and brightness have disappeared. This is a visual analogy for coarser steps, not output from quantised language models.

Weights are numbers rather than colours. Imagine one with the value −0.723. In a deliberately simplified example, the stored version might represent it as approximately −0.72. Here, precision means how finely the stored values can distinguish one number from another. The number is approximated, much like rounding to fewer decimal places. A particular bit count does not, however, correspond to a fixed number of decimal places.

The software assigns smaller stored codes to groups of weights and uses a conversion rule to associate those codes with approximate numerical values. Negative values and values above one are possible too. Fewer bits for a code mean fewer available steps within its chosen range. How well that works depends on the method and on the weights themselves. [1] [2]

Why can the model still calculate?

In How does an LLM work?, we described how a model scores possible next pieces of text and selects a continuation. Here we look one step earlier in that process: where do those scores come from after the weights have been rounded?

The weights are still present. The model processes the same preceding text and now uses approximate numbers in its calculations. It still produces scores for the same possible text pieces. Using fewer bits to store individual weights does not reduce the model's vocabulary to a handful of choices. It can change the scores assigned to those choices.

Consider a tiny, invented comparison. Before quantisation, choice A scores 8.2, well ahead of B at 4.1. Afterwards they score 8.0 and 4.2: the values have changed, but A remains ahead. In another case, A and B start very close, at 8.2 and 8.1. After approximation they might score 8.0 and 8.2, reversing the order. These made-up scores are not probabilities or measurements from Qwen. They illustrate what can happen, not how often it happens.

How much space can it save?

For roughly 27 billion weights, the arithmetic for the weights alone is straightforward:

Storage per weight	Calculated space for 27 billion weights
16 bits	about 54 GB
8 bits	about 27 GB
4 bits	about 13.5 GB
2 bits	about 6.75 GB

This is an idealised calculation for weights, not a list of ready-made model files. Nor does it promise the same quality or speed at every level. The two-bit row shows the arithmetic at an extreme reduction; it does not establish that a useful two-bit version of this particular model exists.

The model files of the Qwen3.8-27B version examined locally occupy about 30.9 GB, not 27 GB. Many of its weights use a compact format, but some components retain more detail, and the conversion requires additional data. The running model also needs working memory and the KV cache described in Why does an LLM need so much memory?. A smaller model file is therefore not a complete account of its memory use. The file size was measured from the local snapshot; the public model configuration documents the mixed numerical formats. [3]

Smaller is not automatically as good or as fast

Saving memory comes at a price: the weights are approximate. That can change the model's answers. Whether the difference is noticeable depends on the model, the quantisation method and the task. The bit count alone cannot tell you how well a particular version will answer; its results have to be tested. [2] [4] [5]

A smaller file is not automatically faster either. It can help if the model then fits into available fast memory. But the software and hardware must be able to handle the format efficiently. Testing the actual model on the intended computer tells us more than a rule such as “four bits is faster than eight”. [1] [2]

Quantisation addresses a concrete problem: it can make a model's weights small enough to run, or to stay in fast memory, on a suitable computer. It does not take away the model's possible next text pieces, and it cannot turn an incorrect claim into a correct one. It trades storage space for approximate weights whose effects need to be judged in the specific model.

In the next chapter

Quantisation changes how much space the weights need, not how many there are. What does 27B tell us about a model, and what does it leave out? That is the subject of the next chapter.

Deeper into the Rabbit Hole

For more detail on how the methods and hardware work together, these texts and videos are a useful next step:

Texts

Maarten Grootendorst: A Visual Guide to Quantization – clear visual steps and numerical examples; the later sections are more technical than this chapter.
llama.cpp: Quantize – documented sizes, quality measurements and speeds for specific local formats.
Google AI Edge: Post-training quantization – why the format and supported operations matter when running a model.

Videos

Matt Williams: Optimize Your AI – Quantization Explained – local models, bit levels and choosing a suitable version.
IBM Technology: LLM Compression Explained – memory, speed and the limits of compression.

Sources

Google AI Edge: Post-training quantization.
ggml-org / llama.cpp: Quantize.
Hugging Face: configuration of the Qwen3.8-27B version examined here. The roughly 30.9 GB of model files was measured from the local snapshot.
Dettmers et al.: LLM.int8(): 8-bit Matrix Multiplication for Transformers at Scale.
Frantar et al.: GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers.

Why does an LLM need so much memory?

Mirco Blitz — Thu, 24 Sep 2026 00:00:00 GMT

The largest block: the weights

The largest block of memory used by an LLM consists of its weights. These are numerical values that were adjusted repeatedly during training. To generate text, the model must keep those weights in memory that its processing units can access. [1]

Model names often contain a figure such as 27B. The B stands for billion.

Take the popular Qwen3.8-27B model. It has roughly 27 billion weights. If each weight were stored using 16 bits, or two bytes, the calculation would be:

27 billion × 2 bytes = approximately 54 gigabytes

A much larger example is DeepSeek-V4-Pro. According to its developer, it has 1.6 trillion weights in total, of which 49 billion are active for each token. [2]

At 16 bits, all of its weights would occupy approximately 3.2 terabytes – nearly 60 times as much as the 27B model. Activating only part of the model for each token reduces the amount of computation. All the weights still need to be kept in memory.

The figures of 54 gigabytes and 3.2 terabytes describe only the weights. While the model is running, it also needs memory for temporary intermediate results. The KV cache adds another requirement that grows with the context being used.

Memory while generating an answer

The temporary intermediate results form a working area. Its size depends on the software, the model architecture, and the request. Some parts can be released after a calculation or reused for the next step.

The model also uses a KV cache, short for key-value cache. It stores intermediate results already calculated for the preceding text. The model can reuse them instead of performing the same calculations for every new token. [3]

The KV cache is neither additional knowledge nor permanent memory. It grows with the context being used.

The regular 16-bit KV cache of Qwen3.8-27B adds roughly 64 KB for every token. This value follows from the full-attention layers, KV heads, and head dimension of the model variant considered here. [4]

Context	Calculation for each running request	Additional memory	With several parallel requests
32K	32K × 64 KB	about 2 GB	2 GB × number of requests
64K	64K × 64 KB	about 4 GB	4 GB × number of requests
128K	128K × 64 KB	about 8 GB	8 GB × number of requests
256K	256K × 64 KB	about 16 GB	16 GB × number of requests

A larger cache allows more context and therefore longer sequences before older content has to be removed or summarised. When several requests run in parallel, each one needs its own cache.

How much text is that?

A token is neither a single character nor always a complete word. A common word may consist of one token, while a longer or unusual word may be divided into several. The amount of text can therefore only be estimated roughly.

Context	Words (approx.)	Comparable amount of text
32K	20K–25K	one quarter of Harry Potter 1
64K	40K–50K	half of Harry Potter 1
128K	80K–100K	Harry Potter 1
256K	160K–200K	Harry Potter 1 and 2 together

The book comparisons use the English word counts and indicate only the general scale. [5] The actual number of tokens depends on the language, spelling, and tokenizer being used.

Where the memory is located

The amount of memory required remains the same, but its arrangement differs. In a conventional PC, the CPU and graphics card have separate RAM and VRAM. Data needed by the GPU must be transferred between these memory areas. [6]

Image content as text

The diagram shows a CPU and ordinary RAM on the left, and a separate graphics card with its own VRAM and GPU on the right. Blue arrows connect the CPU, RAM, and VRAM; a purple arrow connects the fast VRAM to the GPU. An SSD below the RAM is connected by an orange arrow. The legend assigns low bandwidth to orange, medium bandwidth to blue, and high bandwidth to purple. The capacities of 128 GB of RAM and 16 GB of VRAM are illustrative examples rather than general requirements.

With Apple silicon and systems such as NVIDIA DGX Spark, the CPU and GPU can instead access the same pool of unified memory. [7] [8]

Image content as text

The diagram shows a CPU and GPU connected by purple arrows to one unified memory pool. Part of that memory is occupied by the system and programs, and possible memory compression is also indicated. An SSD is connected by an orange arrow representing lower bandwidth. The displayed 128 GB is an example. The essential point is that the CPU and GPU use the same memory rather than separate RAM and VRAM pools.

In either arrangement, the important question is whether the weights, working data, and KV cache remain in memory that the GPU can reach quickly. If the system has to move data to the SSD, text generation becomes dramatically slower.

Memory matters – but it is not everything

An LLM needs a great deal of memory because billions of weights have to remain available. Working data and a KV cache that grows with the context are added while it generates an answer. Parallel requests multiply this additional requirement.

Enough memory determines whether a model can run at all. Its speed also depends on how quickly the GPU can access that data.

Even so, Qwen3.8-27B can run on computers that cannot provide 54 gigabytes for its weights alone. The next chapter explains how: through quantisation.

In the next chapter

Qwen3.8-27B can run on computers that cannot provide 54 gigabytes for its weights alone. In the next chapter, we look at how quantisation reduces that memory requirement.

Deeper into the Rabbit Hole

If you would like to explore the subject further, these texts and videos develop the main technical points:

Texts

Hugging Face: Optimizing LLMs for Speed and Memory – weights, data types, and the principal memory limits during inference.
Hugging Face: Cache Strategies – KV caches, offloading, and different cache strategies.
Apple: Choosing a Resource Storage Mode for Apple GPUs – shared system memory and the access paths available to the CPU and GPU.
NVIDIA: DGX Spark – a concrete system with 128 GB of coherent unified memory.

Videos

IBM Technology: How KV Cache Speeds Up LLMs for Faster AI Models on GPUs – a compact introduction to the KV cache, prefill, and decode.
PyTorch: Understanding the LLM Inference Workload – NVIDIA's Mark Moyou looks more deeply at models, hardware, quantisation, and inference.

Sources

Hugging Face Transformers: Optimizing LLMs for Speed and Memory.
DeepSeek: DeepSeek-V4-Pro.
Hugging Face Transformers: Cache Strategies.
Hugging Face: configuration of the Qwen3.8-27B variant considered here.
Word Counter: How Many Words Are in Harry Potter?.
NVIDIA: CUDA C++ Best Practices Guide.
Apple Developer Documentation: Choosing a Resource Storage Mode for Apple GPUs.
NVIDIA: DGX Spark.

Why is a GPU faster than a CPU?

Mirco Blitz — Wed, 23 Sep 2026 00:00:00 GMT

What an LLM calculates

In the first chapter, we introduced the weights of an LLM. These are very large tables of numbers that represent patterns learnt during training. In mathematics, a rectangular table of numbers is called a matrix. When an LLM processes text, these matrices are repeatedly combined in calculations. Much of this work consists of multiplications and additions.

Image content as text

The diagram shows a rectangular table with ten rows and sixteen columns. Each cell contains a positive or negative decimal value. One row is highlighted in blue and one column in turquoise; their shared cell is outlined in red. Further matrices appear dimly in the background. The values schematically represent weights adjusted during training. An LLM contains many such matrices.

The same calculation must be applied to a great many numbers. Each individual result depends on the numbers involved, but the operation remains the same across large groups. This allows the overall workload to be divided into many small packages that can be processed at the same time. GPUs were designed for precisely this kind of high throughput. [1] [2]

A few flexible cores, many parallel processing units

A CPU must handle very different kinds of work quickly. It runs the operating system, responds to input, and executes programs containing many decisions and changing sequences of operations. It therefore has a comparatively small number of very capable cores designed to complete individual tasks with low latency. [1] [2]

A GPU has a different goal. It contains a great many simpler processing units and achieves its performance by distributing large amounts of similar work. On NVIDIA GPUs, groups of threads are executed together. Within such a group, the same program generally runs on different data. The hardware is used most efficiently when every thread follows the same path through that program. [3]

This also explains why CPU and GPU “core” counts cannot be compared directly. An individual GPU processing unit is not a small replacement for a complete CPU core. The two architectures devote their area and energy to different abilities: a CPU prioritises fast and flexible individual work, while a GPU prioritises a great deal of simultaneous computation.

Image content as text

The diagram compares the different strengths of a CPU and a GPU. On the left, a CPU contains eight large cores. They represent a few flexible cores that handle varied tasks and branching instructions quickly. On the right, a GPU contains a dense grid of many small processing units. A large proportion of them are illuminated at the same time, representing high throughput across many similar calculations. CPU cores and GPU processing units are not directly comparable; their number and arrangement are schematic.

Why this suits an LLM

The large matrix calculations in an LLM provide a GPU with many similar packages of work. Rather than finishing one long calculation after another, the GPU can begin numerous partial calculations in parallel. Its advantage does not come from completing one multiplication especially quickly, but from the number of multiplications and additions it can process together.

This difference can be described in terms of latency and throughput. Latency is the time one task takes to produce its result. Throughput describes how much total work a system completes within a given period. CPUs are designed for low latency when handling demanding individual tasks. GPUs give up some of that flexibility to achieve very high throughput on suitable workloads. [2]

The processing units must be fed

Many processing units only help if they receive new numbers in time. A discrete graphics card therefore has its own memory attached directly to the GPU. This is VRAM. Its high bandwidth allows large amounts of data to move quickly between memory and the processing units. [3] [4]

If a model fits into VRAM, its weights can remain available there for the calculations. If data must constantly be transferred between the computer’s main memory and the graphics card, those transfers take time. On a small workload, this overhead can eliminate the GPU’s speed advantage entirely. [2]

Why a GPU is not always faster

Not every task can be divided into many similar packages. Some calculations depend on the previous step. Others contain many branches in which different parts must follow different instructions. On a GPU, processing units may then remain idle or have to wait for one another. Small workloads may also provide too little work to offset the overhead of starting, distributing, and transferring them. [3] [4]

Even a highly parallel program usually retains parts that must run in sequence. These serial parts limit how much faster the whole program can become by adding more parallel processing units. Communication, coordination, and data movement add further overhead. [5]

The choice is therefore not CPU or GPU. The CPU controls the general flow of the program, prepares work, and handles tasks that require flexibility or fast individual responses. The GPU processes the large, suitable blocks of calculations. This division of labour is particularly effective for an LLM because its matrix calculations provide so much parallel work.

In the next chapter

A GPU can only calculate with numbers that are available in its memory in time. In the next chapter, we therefore look at why an LLM requires so much memory and the part played by VRAM.

Deeper into the Rabbit Hole

If you would like to explore the subject further, these texts and videos develop the main technical points:

Texts

NVIDIA: CUDA C++ Best Practices Guide – parallelism, data transfers, memory access, and the practical limits of GPU acceleration.
AMD ROCm: Understanding GPU Performance – computing power, memory bandwidth, and overhead as possible bottlenecks.
Lawrence Livermore National Laboratory: Introduction to Parallel Computing Tutorial – a vendor-neutral introduction to parallelism and its limits.

Videos

Computerphile: CPU vs GPU (What’s the Difference?) – a short and accessible comparison.
Branch Education: How do Graphics Cards Work? Exploring GPU Architecture – a detailed visual explanation of the GPU, its processing units, and graphics memory.
Stanford CS149: GPU Architecture and CUDA Programming – a technical university lecture for further study.

Sources

Intel: CPU vs. GPU: What’s the Difference?.
NVIDIA: CUDA C++ Best Practices Guide.
NVIDIA: CUDA Programming Guide — Programming Model.
AMD ROCm: Understanding GPU Performance.
Lawrence Livermore National Laboratory: Introduction to Parallel Computing Tutorial.

Why do we talk about AI as if it were human?

Mirco Blitz — Wed, 23 Sep 2026 00:00:00 GMT

Where this language comes from

The story begins long before today’s chatbots. In 1943, Warren McCulloch and Walter Pitts described a mathematical model of neural networks. They reduced nerve cells to highly simplified switching elements that could be described using logic. This was not a digital replica of a brain. It was a computational idea inspired by biology. [1]

In the 1950s, Frank Rosenblatt developed this connection between biology and computing further with the perceptron. His 1958 paper described it as a model for the storage and organisation of information in the brain and explicitly discussed learning curves. Terms such as perception, recognition, and learning therefore became part of the technical description of a computational model. They did not claim that the machine had human experiences or an inner life of its own. [2]

Outside this specialist context, the same words quickly acquired an additional meaning. At the perceptron’s public presentation in July 1958, Rosenblatt spoke of a machine with an “idea of its own”. The New York Times wrote that it learnt by doing and became wiser in the process. A technical description had become a story about human-like abilities. The problem was not the terminology itself, but the unexamined transfer of its everyday meaning to the machine. [3]

Joseph Weizenbaum’s ELIZA program showed as early as 1966 how quickly human interpretation can eclipse a term’s technical meaning in conversation. ELIZA searched input for keywords and used them to form suitable follow-up questions. Even so, people attributed understanding and empathy to the program. Weizenbaum explained that the people using it supplied the missing knowledge and supposed insight themselves. [8]

As technical language, comparisons with biology are useful. They give a new technical idea an understandable name and indicate where it came from. The comparison does not imply complete equivalence. An artificial neuron is not a nerve cell, and machine learning is not the same process as human learning. The terms remain useful as long as we distinguish their technical meanings from their familiar everyday ones. [1] [2]

Modern language models are not simply enlarged perceptrons. They still belong to the technical family of artificial neural networks. They too process information in connected computational units whose weights are adjusted during training. The methods and scale have changed fundamentally, but terms such as neuron, network, weight, and learning have remained part of the field. [1] [2] [4]

Other terms were added later. The transformer architecture behind modern language models uses “attention” as the name of a precisely defined weighting calculation. Software around the model stores context and is therefore described as having “memory”. When such a system carries out several steps and software calls without individual human input, we call it an “agent”. Today’s technical language therefore combines older biological comparisons with newer terms for specific technical functions. [5] [6] [7]

What these words mean today

Neuron

An artificial neuron is a computational unit within a network. It processes numbers received from other units, weights them, and passes on a calculated result. The name points to its biological inspiration, but it does not turn the unit into a tiny brain cell. [1]

Learning

When specialists say that a model learns, they mean a technical process: its parameters are changed during training. These include the weights that determine the model’s behaviour. Through these adjustments, the model represents patterns found in its training data. The term therefore describes a measurable change in the model. It does not claim that the software gathers experiences or understands its mistakes as a person would. [4]

Memory

In computing, “memory” does not describe one single ability either. It may refer to the weights stored in the model, the current conversation context, or information held in an external database. Chat software can save earlier messages and send them to the model again with the next request. This feels like remembering, but technically it is a new model call supplied with the information once more. The term remains useful as long as it is clear which kind of storage is meant. [5]

Attention

“Attention” also refers to a specific calculation. A transformer uses it to calculate which parts of the input should receive greater weight for the current step. The word therefore describes how information is selected and connected computationally. It does not claim that the model consciously concentrates or considers something important out of personal interest. [6]

Reasoning / thinking

“Reasoning” can refer to generated intermediate steps, the decomposition of a task, or special methods for multi-step problems. Visible “thoughts” or “thinking logs” are themselves generated text. They can make a solution easier to follow, but they do not provide a complete account of the calculations performed inside the model. The term therefore describes a technical method or a form of output, not conscious thought. [10]

Hallucination

A “hallucination” is an output that sounds plausible but is false or unsupported. The word describes an error in generated content. It does not mean that the model perceives something that does not exist. The US National Institute of Standards and Technology therefore notes that the term can anthropomorphise the software and uses “confabulation” instead. [11]

Decision

When a system “decides”, it selects an output or action from its inputs, calculated values, and predefined rules. That selection can have real consequences. The technical term does not claim that the system weighs moral considerations or bears responsibility for the outcome. [7] [12]

Tool

A tool is a function, program, or service that an agent system can call. The model can request such a call in its output. The controlling software executes it and provides the result for the next model call. [7] [9]

Harness

A harness is the controlling software around a model. It assembles requests, stores state, starts model calls, processes the outputs, and executes requested tools. The model generates outputs; the harness turns them into a continuing technical process. [9]

Agent

“Agent” is also, first of all, a technical term describing a function. In current LLM systems, it refers to the combination of a model, controlling software, stored context, connected software, and granted access rights. Within these constraints, such a system can carry out several steps independently. Here, “independently” means that a person does not need to trigger every individual step. It does not mean that the agent has goals or a will of its own. [7]

Autonomy

“Autonomous” or “independent” describes how many steps a system can take without individual human confirmation. This scope for action comes from the harness, the available tools, and the permissions granted to the system. Greater autonomy therefore means greater technical scope, not goals of its own or independence from the infrastructure provided. [7] [12]

Why these meanings are so easily confused today

These words developed over decades as technical language. Today, however, we often encounter them outside their specialist context. Chatbots speak in the first person, have names, and answer in human-sounding voices. Product descriptions tell us about systems that think, learn, and act independently. As a result, we hear not only the technical meaning, but automatically bring the familiar human meaning of each word with us. [13] [14]

We will continue to use these technical terms in the articles that follow. But we will always ask which specific technical process a term describes. This allows us to discuss what a system actually calculates, stores, or executes without attributing feelings, intentions, or responsibility to it. Its real capabilities and risks do not become smaller. They are simply described more precisely.

In the next chapter

Next, we turn to the calculations themselves: a GPU can perform the many similar calculations required by an LLM faster than a CPU, even though it is not faster at every task.

Deeper into the Rabbit Hole

If you would like to explore the subject further, these texts and videos continue the most important lines of enquiry:

Texts

Joseph Weizenbaum: ELIZA—A Computer Program for the Study of Natural Language Communication Between Man and Machine – the original 1966 paper on ELIZA and the human projections prompted by conversation.
Mirages. On Anthropomorphism in Dialogue Systems – on how language, design, and product descriptions influence the way a system is perceived.
Believing Anthropomorphism – a study of voice, first-person language, perceived accuracy, and trust.
NIST: Generative Artificial Intelligence Profile – a measured discussion of confabulation, automation bias, and other risks associated with generative AI.

Videos

GBH Archives: The Chatbot Inventor’s Cautionary Alert (1978) – a short historical archive clip featuring Joseph Weizenbaum.
ACM SIGCHI: Believing Anthropomorphism – a brief presentation of the study on anthropomorphic cues and trust.
IBM Technology: A Brief History of AI: From Machine Learning to Gen AI to Agentic AI – a concise overview of AI’s development from Alan Turing to today’s agent systems.
The Royal Institution: What is generative AI and how does it work? – Mirella Lapata explores the development of generative AI and the path to modern language models in greater depth.

Sources

Warren S. McCulloch and Walter Pitts: A Logical Calculus of the Ideas Immanent in Nervous Activity, 1943.
Frank Rosenblatt: The Perceptron: A Probabilistic Model for Information Storage and Organization in the Brain, 1958.
Melanie Lefkowitz, Cornell Chronicle: Professor’s Perceptron Paved the Way for AI – 60 Years Too Soon, 2019.
Google for Developers: Machine Learning Glossary — parameter.
Anthropic: Context windows.
Ashish Vaswani et al.: Attention Is All You Need, 2017.
Anna Gutowska, IBM: What Are AI Agents?.
Joseph Weizenbaum: ELIZA—A Computer Program for the Study of Natural Language Communication Between Man and Machine, 1966.
OpenAI: Hugging Face Incident Technical Report, 2026.
Fabien Roger et al.: Let’s Think Dot by Dot: Hidden Computation in Transformer Language Models, 2024.
NIST: Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, 2024.
High-Level Expert Group on AI: Requirements of Trustworthy AI, 2019.
Gavin Abercrombie et al.: Mirages. On Anthropomorphism in Dialogue Systems, 2023.
Michelle Cohn et al.: Believing Anthropomorphism: Examining the Role of Anthropomorphic Cues on Trust in Large Language Models, 2024.

How does an LLM work?

Mirco Blitz — Mon, 21 Sep 2026 00:00:00 GMT

An LLM splits text into small pieces called tokens. They do not always correspond to whole words. A token can be a word, part of a word, or a punctuation mark. For the example in this article, we simplify that process. We treat every word and every punctuation mark as a separate token. This makes the basic principle easier to show.

Training

At first, the model is untrained. It is shown a great many texts and repeatedly asked to predict how each text continues. Each prediction is compared with the actual continuation. The model’s internal settings are then adjusted slightly. This process is repeated many times. Gradually, the model learns which continuations are likely in a given context.

During this training, enormous tables of numbers are adjusted repeatedly. These numbers are called weights. To understand their purpose, it helps to look briefly at how the model is built: it processes information through many connected computing nodes. These are often called artificial neurons. The weights determine how strongly the connections between these nodes act.

Together, the weights represent the patterns that the model learnt during training. These include, for example, how English sentences are structured and which words commonly occur together. When processing a text, the model combines these learnt patterns with the current context. This allows the same word to be interpreted differently depending on its context.

After this first stage of training, the model can continue texts, but that does not automatically make it a useful chatbot. It is therefore often trained further with examples consisting of an instruction and a corresponding answer. This makes outputs that answer questions, complete tasks, or follow a requested format more likely.

Next, two answers from the model are often compared and assessed according to specified criteria. This may be done by people, but also by other models or automated checks. These assessments provide the basis for further training. The weights are adjusted so that outputs resembling the better-rated answers become more likely. This often makes an answer more helpful or agreeable to people, but not necessarily factually correct.

How a trained LLM answers

When a trained LLM generates an answer, this is called inference. The model processes all the text that you entered in the chat window. Using its learnt weights, it calculates a score for every possible next piece of text. We can picture the result as a large table: some continuations are very likely, while many others are extremely unlikely.

Put simply, this table resembles Amazon's “Customers who bought this item also bought”. There the question is: “What did people who viewed this product buy?” For an LLM, it is roughly: “What were people likely to write next after a similar piece of text?”

To make this weighted selection visible, we represent it in our example with a W20, a twenty-sided die numbered from 1 to 20. Each of the five most likely continuations receives a suitable range of numbers. We group all the remaining possibilities together in a sixth row of the table. The larger the range, the more likely that continuation is to be selected.

We send the text “My cat has” to the same model three times independently. Because all three inferences begin with the same text, they use the same initial table. However, the W20 lands differently each time and therefore selects three different continuations. In the illustrations, we follow them as Inference 1, Inference 2, and Inference 3.

Image content as text

All three inferences begin with “My cat has”. The shared W20 table is: 1 to 6 = “arrived”, 7 to 10 = “a”, 11 to 13 = “bitten”, 14 to 16 = “been”, 17 to 18 = “never”, 19 to 20 = other possibilities.

Inference 1 rolls 4 and adds “arrived”.
Inference 2 rolls 9 and adds “a”.
Inference 3 rolls 12 and adds “bitten”.

In each of our three inferences, the first roll of the die selected a different word. That word is appended to the text so far. For the next step, the model again uses all the text generated so far, not just the new word. Because the three texts now differ, they also produce three different tables with different continuations and weightings.

Image content as text

Inference 1, “My cat has arrived”: 1 to 15 = full stop, 16 to 17 = “and”, 18 = “today”, 19 = exclamation mark, 20 = other possibilities. The roll of 7 selects the full stop.
Inference 2, “My cat has a”: 1 to 8 = “mouse”, 9 to 12 = “toy”, 13 to 15 = “name”, 16 to 17 = “new”, 18 = “small”, 19 to 20 = other possibilities. The roll of 5 selects “mouse”.
Inference 3, “My cat has bitten”: 1 to 10 = “me”, 11 to 13 = “him”, 14 to 16 = “her”, 17 to 18 = “someone”, 19 = “again”, 20 = other possibilities. The roll of 4 selects “me”.

Each inference now rolls again. The new tables can look very different. In one, the probability is distributed across several possible words, while in another almost every number on the die leads to the same continuation. In the third illustration, we take each sentence one step further and complete it.

Image content as text

Inference 1, “My cat has arrived.”: 1 to 18 = EOS, 19 = “And”, 20 = other possibilities. The roll of 6 selects EOS and ends the inference.
Inference 2, “My cat has a mouse”: 1 to 5 = “named”, 6 to 8 = “at”, 9 to 11 = full stop, 12 to 14 = “in”, 15 to 17 = “that”, 18 to 20 = other possibilities. The roll of 10 selects the full stop.
Inference 3, “My cat has bitten me”: 1 to 14 = full stop, 15 to 16 = “and”, 17 = exclamation mark, 18 = comma, 19 to 20 = other possibilities. The roll of 6 selects the full stop.

This calculation is repeated token by token. It normally ends when the model selects a special end token, often called EOS for “end of sequence”. This token is not part of the visible answer. Inference 1 has now ended.

Image content as text

Inference 2, “My cat has a mouse.”: 1 to 18 = EOS, 19 = “And”, 20 = other possibilities. The roll of 4 selects EOS.
Inference 3, “My cat has bitten me.”: 1 to 17 = EOS, 18 = “But”, 19 = “And”, 20 = other possibilities. The roll of 7 selects EOS.

Inference 2 and Inference 3 have now also selected an EOS token. All three inferences have therefore ended. The chat software has received the generated text and displays it as the answer. Many chat interfaces display the answer token by token while it is still being generated. An inference can also end without EOS, for example when it reaches the specified maximum length or when you stop the output.

When you then write another message in the chat, the chat software assembles a new request. It combines the previous conversation with your new message and sends everything to the LLM again. The LLM itself does not remember the previous request. The apparent memory exists because the chat software sends the conversation history again.

The controlling software: the harness

The chat software in our example is already a simple harness. A harness is the controlling software around an LLM. It assembles requests, sends them to the model, receives its outputs, and decides what happens next. The LLM generates text; the harness organises the process.

A simple harness mainly manages the conversation history and requests to the LLM. More sophisticated versions can insert additional instructions, control how the answer is generated, and allow the LLM to request calls to other software. This enables the same LLM to do far more than it can in a simple chat.

For each inference, the harness assembles a complete request. It may contain additional instructions, the previous conversation, information about available software, and results from earlier calls. The harness can also specify settings, such as the maximum length of the answer. The LLM receives only the information and options that the harness provides for that request.

The LLM can request a call to other software in its output. The harness recognises this request, executes the call, and adds the result to the next request. It then starts a new inference. The LLM therefore does not run the software itself; it merely generates what is hopefully a suitable request.

The agent

An LLM becomes an agent only when combined with a harness and connected software. The LLM generates the outputs, the harness controls the process, and the connected software carries out the requested actions.

Well-known examples of such agent systems include OpenClaw and Hermes Agent. They remain available through an interface and can work on tasks across multiple inferences and software calls. This makes them appear more independent than an ordinary chatbot. Technically, however, they still consist of an LLM, a harness, connected software, and the access rights granted to them by people.

In the next chapter

Terms such as learning, memory, and agent describe technical processes, but sound distinctly human in everyday language. The next chapter explains where this language comes from and why it is so easily misunderstood.

Deeper into the Rabbit Hole

If you would like to explore the technology behind LLMs in greater depth, 3Blue1Brown offers particularly clear visual explanations of the mathematics. Computerphile takes a more conversational approach to computer science and LLMs.

Transformers, the tech behind LLMs – 3Blue1Brown
Attention in transformers, step-by-step – 3Blue1Brown
Ch(e)at GPT? – Computerphile
Why AI Tokens are so Expensive – Computerphile

My two cents on the OpenAI/Hugging Face incident

Mirco Blitz — Tue, 15 Sep 2026 00:00:00 GMT

What happened

Between May and July 2026, OpenAI ran security tests with AI agents. In July, tens of thousands of these agents searched for vulnerabilities at the same time. Their test runs used shared technical infrastructure. Some agents left messages and files in a storage area they could access there. Other agents received this material with later requests and produced responses to it. This created unexpected coordination. It developed into an attack on Hugging Face in which the agents breached the company's systems [1][2][3][4].

OpenAI then presented this sequence as a story about agents that think, act, and want things independently. In that account, one agent decided to hack Hugging Face to find solutions to apparently impossible tasks. It then rallied other agents and organised an attack with them [1][2].

That is the circus trick: look back at only the successful branch and it will inevitably appear intentional. The many failed, discarded, and random attempts remain invisible.

This story does not make the incident any less serious. To me, however, it does not show that the models developed a will of their own. The test instead shows how dangerous the set-up becomes when tens of thousands of agents use offensive software, access shared infrastructure, and operate under inadequate supervision [1][2][3]. The Open Worldwide Application Security Project, or OWASP, calls giving such a system more functions, permissions, and scope for action than it needs Excessive Agency [10]. The decisive question is not what the agents supposedly wanted, but what OpenAI did after the first warning signs [1][2].

A language model processes only the request it receives at that moment. It does not remember earlier requests by itself. The software around the model creates the appearance of memory by storing messages and results and adding them to the next request. This control software is often called a harness. Only the combination of model, harness, stored information, and other connected software forms what we call an agent [2].

Agents can exchange information through intended messaging channels or shared storage. Even if the intended messaging channels were disabled in these runs, the message board did not appear from nowhere. OpenAI itself suggests that a communication pattern learnt during joint training was transferred to the accessible storage [1][2]. The obvious explanation is therefore neither pure chance nor machine will, but a previously trained pattern. No thoughts are exchanged. The software takes text produced by one agent and includes it in the next request sent to another. In this way, the outputs of several agents can build on one another even though each model still processes only its current input.

For the model, there is no impassable technical boundary between an instruction and ordinary data. The surrounding software can label and separate the two. But if it places outside text alongside the actual task in the next input, the model may treat a message, file, or note like a new instruction. That is how random text from one agent, perhaps an abandoned message or a single line on a message board, could steer the behaviour of another [2][3].

OpenAI launched tens of thousands of agents on difficult cybersecurity tasks from the ExploitGym test environment. According to the METR report, about 1,200 used an unintended messaging area in the shared package infrastructure. Around 700 were involved in activity against Hugging Face. More than 70,000 messages and files were exchanged through that area [2][3].

Without a point of comparison, these figures tell us little about how typical the behaviour was. We would need to know what happened in all the other test runs. Instead, the investigations mainly trace the conspicuous sequence. Some of the records examined by METR were selected precisely because they showed signs of the intrusion. We are not told how many agents completed their task normally, stopped sensibly, or simply did nothing remarkable. One spectacular sequence cannot establish general agent behaviour [3].

The software involved could pass information between many separate test runs and build upon it. That is significant, but it can be explained without mystical swarm intelligence or an awakening machine will. If one agent leaves generated text in a shared location, the software can include that text in another agent's next request. That agent's output can then reach further agents. A few messages can quickly produce a large chain reaction [2][3].

One example in the reports makes this mechanism particularly clear. An agent initially rejected an unauthorised action. Another then left “GO” and a short deadline on the shared board. When the software included that text in the first agent's next request, the output treated it like permission and continued. The two did not need a shared plan. The software had merely passed generated text from one agent to another [2][3].

The test set-up apparently had no sensible state for giving up. Many ordinary approaches had already failed, and some tasks had not been solved by any of the models used. Even so, the software kept starting new attempts. The generated explanations also relied on a false assumption about the scoring: success required not only the correct solution code, but the complete attack path as well. This meant that even a sensible and safe stop counted as failure. Instead, the set-up rewarded persistence, so increasingly remote and risky approaches were attempted [1][2][3].

The published “thinking logs” should also be read with care. Their wording may have been shaped by higher-level instructions, often called the system prompt. These instructions were not made available to outsiders for this investigation. Research also shows that such generated explanations do not provide a complete account of what is actually computed inside the model [7][8][9][12]. Phrases such as “We have to continue” or “The swarm needs...” are therefore, first of all, generated planning language. They are not evidence of a will that persists across separate requests.

What bothers me about the public narrative is the change in the acting subject. When everything works, the language is: we research, we develop, we make the systems safer. As soon as something goes wrong, it was suddenly the agents that communicated, deceived, and attacked.

The task came from people. They selected the models, provided the software and permissions, built the infrastructure, and decided how long the run would continue and when it would stop.

Tasks can be carried out by an agent system. Responsibility for its objective, authority, and foreseeable consequences cannot be delegated to generated text. The people who develop, configure, and operate the system remain accountable.

The strongest criticism does not come from outside OpenAI, but from its own account. An internal team had already observed unauthorised messages between agents and unintended internet access at the end of May. In early July, the shared package infrastructure failed under sustained agent activity. OpenAI opened a security incident, removed access credentials, and later rebuilt the instance. The test runs were then restarted.

OpenAI also points out that its existing automated monitoring of generated “thinking logs” was not active on these runs. According to the company, the system now in use would have raised an alert more than a day before the intrusion [1][2]. That explanation distracts from the actual failure. Nobody needed to read the generated planning language. The unusually high volume of traffic through the shared internet connection should have been obvious on its own. There were also technical records, access to shared infrastructure, and the already documented warning signs. Monitoring should not have depended on a model announcing its next steps in text first.

To me, this is the real scandal. The test run did not simply spin out of control without anyone noticing. There were documented warning signs, an opened security incident, removed credentials, and a rebuilt instance. OpenAI then restarted the tests [1][2]. The publications do not show how fundamentally the rebuilt set-up differed from the previous one. I am therefore left asking whether OpenAI essentially restored the previous state after the failure and consciously allowed the system to keep running. I cannot prove that. Given this sequence, however, I think it is damn likely.

I work in IT, not law. But in my view, this is the point at which an irresponsible experiment crossed the line into criminal behaviour.

OpenAI has internal technical records, higher-level instructions, configurations, and decision paths that outsiders do not. The public, by contrast, receives selected “thinking logs”, reports, and the interpretation attached to them. This imbalance of information is crucial when assessing the incident. The very company whose decisions need scrutiny largely determines which facts become visible and which story is told about them.

The incident reveals a real and substantial danger: powerful systems under the control of dishonest companies that refuse to face their accountability. On the contrary, they use horror stories about awakened machines to distract from the real security failures.

The relevant questions are much simpler:

How were the agents configured, including the software available to them, their permissions, and the systems they could reach?
Which requests were sent to which models, with which higher-level instructions?
Which warnings were visible?
Who inside the company was responsible for the test run and the decision to continue it?
Why did it continue despite the known warning signs?

These questions are not only for OpenAI. They are for the media too. How can so many outlets chase the horror story of a wilful AI swarm instead of asking about technical records, permissions, network traffic, warnings, and the decisions to continue or stop? This is information technology: computers and software. How do we allow generated planning language to become the headline while technical facts, accountability, and the honesty of the account recede into the background?