{
  "type": "new-runtime-knowledge-guide",
  "version": 1,
  "generated_at": "2026-07-23",
  "volume": 15,
  "slug": "llm-simply-explained",
  "title": "LLMs in Plain English",
  "description": "Not the history of architectures or GPU micro-optimizations, but practical mechanics without academic fog: how text is cut into tokens, how transformer blocks recalculate the meaning, how the encoder and decoder differ, how the model learns and why it responds one token at a time.",
  "track": {
    "slug": "llm-foundations",
    "title": "LLM Foundations",
    "route": "https://newruntime.com/learn/tracks/llm-foundations/",
    "position": 2
  },
  "counts": {
    "sections": 7,
    "cards": 23
  },
  "routes": {
    "html": "https://newruntime.com/learn/llm-simply-explained/",
    "json": "https://newruntime.com/learn/llm-simply-explained.json"
  },
  "sections": [
    {
      "number": "01",
      "title": "Big picture",
      "intro": "",
      "cards": [
        {
          "number": "01",
          "title": "Complete scheme: from user text to next token",
          "tag": "Overview",
          "description": "If you take away all the marketing, there is a repetitive computational chain going on inside the LLM. The text is divided into tokens, the tokens are turned into vectors, the stack of transformer blocks recalculates these vectors many times, after which the model evaluates the probabilities from the dictionary and selects the next token.",
          "blocks": [
            {
              "kind": "code",
              "label": "Diagram",
              "language": "text",
              "value": "SIMPLE PHYSICS ONE ANSWER\n\nText\n  \"Explain transformer in simple words\"\n\n  ↓ tokenizer\n\nTokens\n  [\"Explain\", \"transformer\", \"in simple\", \"words\"]\n\n  ↓ lookup in the embeddings table\n\nVectors\n  e1, e2, e3, e4\n\n  ↓ + position signals\n\nTransformer blocks × N\n  attention → MLP → attention → MLP → ...\n\n  ↓ take the state of the last position\n\nLM head\n  logits over the entire dictionary\n\n  ↓ softmax/sampling\n\nNext token\n  \".\"\n\n  ↓ this token is added to the input\n\nThe cycle repeats"
            },
            {
              "kind": "code",
              "label": "if you compress it into one phrase",
              "language": "text",
              "value": "text → tokens → ids → vectors → contextual vectors → next-token scores → chosen token"
            },
            {
              "kind": "code",
              "label": "step by step",
              "language": "text",
              "value": "Search the database:\nquery → index → found document → show to user\n\nLLM:\nprompt → forward pass network → logits by dictionary → token\n\nImportant:\nthe model doesn't know the \"correct paragraph\"\nthe model knows \"which continuation is similar to the truth\""
            },
            {
              "kind": "list",
              "label": "useful formulations",
              "items": [
                "the model estimates probabilities",
                "the model compresses language statistics into weights",
                "the model stores articles as files"
              ]
            },
            {
              "kind": "code",
              "label": "Diagram",
              "language": "sql",
              "value": "WHAT DO WEIGHTS STORE?\n\nNot so:\n  weight_9281 = \"Paris is the capital of France\"\n\nMore like this:\n  many scales together strengthen patterns\n  \"after 'the capital of France' often comes 'Paris'\"\n  \"in SQL, after SELECT there is often a list of columns\"\n  \"the pronoun 'she' is often associated with the nearest female subject\"\n\nKnowledge is distributed, and does not lie piecemeal"
            },
            {
              "kind": "list",
              "label": "two things follow from this",
              "items": [
                "the model can generalize to new combinations",
                "the model can confidently mix similar patterns"
              ]
            }
          ]
        },
        {
          "number": "02",
          "title": "LLM does not “look for a ready-made phrase in the database”",
          "tag": "Overview",
          "description": "The model does not open internal Wikipedia and pull out a paragraph from it. Each time, it re-calculates which token now looks the most plausible, given all the current context and trained weights.",
          "blocks": [
            {
              "kind": "code",
              "label": "step by step",
              "language": "text",
              "value": "Search the database:\nquery → index → found document → show to user\n\nLLM:\nprompt → forward pass network → logits by dictionary → token\n\nImportant:\nthe model doesn't know the \"correct paragraph\"\nthe model knows \"which continuation is similar to the truth\""
            },
            {
              "kind": "list",
              "label": "useful formulations",
              "items": [
                "the model estimates probabilities",
                "the model compresses language statistics into weights",
                "the model stores articles as files"
              ]
            }
          ]
        },
        {
          "number": "03",
          "title": "What really lives in the scales",
          "tag": "Overview",
          "description": "The weight of a neural network is not a “cell with knowledge”, but a small numerical coefficient. The meaning is distributed among billions of such coefficients: somewhere the tendency to associate a pronoun with a noun is stored, somewhere a code pattern, somewhere statistics of facts and style.",
          "blocks": [
            {
              "kind": "code",
              "label": "Diagram",
              "language": "sql",
              "value": "WHAT DO WEIGHTS STORE?\n\nNot so:\n  weight_9281 = \"Paris is the capital of France\"\n\nMore like this:\n  many scales together strengthen patterns\n  \"after 'the capital of France' often comes 'Paris'\"\n  \"in SQL, after SELECT there is often a list of columns\"\n  \"the pronoun 'she' is often associated with the nearest female subject\"\n\nKnowledge is distributed, and does not lie piecemeal"
            },
            {
              "kind": "list",
              "label": "two things follow from this",
              "items": [
                "the model can generalize to new combinations",
                "the model can confidently mix similar patterns"
              ]
            }
          ]
        }
      ]
    },
    {
      "number": "02",
      "title": "How text becomes numbers",
      "intro": "",
      "cards": [
        {
          "number": "04",
          "title": "Tokenization: text is not cut into letters and not always into words",
          "tag": "Tokens",
          "description": "The model does not see “text” like a human. It receives tokens as input: sometimes they are whole words, sometimes parts of words, sometimes punctuation marks or spaces. Such a compromise is needed so that the dictionary is not endless and does not break up into too long chains of letters.",
          "blocks": [
            {
              "kind": "code",
              "label": "Diagram",
              "language": "text",
              "value": "EXAMPLE OF TOKENIZATION\n\nText:\n  \"Neural networks explain text\"\n\nPossible parsing:\n  [\"Neuro\", \"networks\", \"explain\", \"nyayut\", \"text\"]\n\nOther text:\n  \"transformers are useful\"\n\nPossible parsing:\n  [\"transform\", \"ers\", \"are\", \"useful\"]\n\nThe same symbolic world is cut into pieces of a dictionary\nThere are no letters inside the model, there are ID tokens"
            },
            {
              "kind": "code",
              "label": "minimal chain",
              "language": "text",
              "value": "\"Neural networks explain text\"\n→ tokenizer\n→ [4811, 932, 18452, 77, 901]\n→ then the network works only with numbers"
            }
          ]
        },
        {
          "number": "05",
          "title": "Embedding: Token ID turns into a dense vector",
          "tag": "Tokens",
          "description": "The token with ID `4811` does not mean anything by itself. Therefore, its index is used to pull out a row from the large embeddings table. The result is a vector of hundreds or thousands of numbers, which the network can already process with linear algebra.",
          "blocks": [
            {
              "kind": "code",
              "label": "what's literally happening",
              "language": "text",
              "value": "vocab_size = 128000\nd_model = 4096\n\nEmbedding matrix E ∈ R^[128000 × 4096]\n\ntoken_id = 4811\nvector = E[4811]\n\nThis is not a calculation \"by meaning\"\nThis is a lookup: we took a ready-made table row"
            }
          ]
        },
        {
          "number": "06",
          "title": "Positional cues: word order doesn't appear on its own",
          "tag": "Tokens",
          "description": "If you simply add up a set of tokens, phrases with different word orders will look the same. Therefore, position information is added to the model: which token is first, which is second, who is closer, who is further.",
          "blocks": [
            {
              "kind": "code",
              "label": "Diagram",
              "language": "text",
              "value": "WHY DO YOU NEED A POSITION\n\nPhrase A:\n  \"The dog bit the man\"\n\nPhrase B:\n  \"a man was bitten by a dog\"\n\nSame words, but different meaning.\n\nWithout position:\n  {dog, bitten, human} = almost the same thing\n\nWith position:\n  token_vector + position_signal\n  → the model knows who is earlier and who is later"
            }
          ]
        },
        {
          "number": "07",
          "title": "Contextualization: the word “bank” changes meaning according to its neighbors",
          "tag": "Tokens",
          "description": "The starting embedding for a word is usually the same. But after several transformer blocks, the representation of the word changes under the influence of neighboring tokens. This is why the same word can mean different things in different sentences.",
          "blocks": [
            {
              "kind": "code",
              "label": "Diagram",
              "language": "text",
              "value": "ONE WORD, TWO CONTEXTS\n\nBefore the context:\n  \"bank\" → e_bank\n\nAfter blocks in a sentence:\n  \"I put the money in the bank\"\n  → h_bank_money\n\nAfter blocks in another sentence:\n  \"the boat sailed to the river bank and the bank\"\n  → h_bank_river\n\nThe meaning changes not in the token dictionary, but inside hidden states"
            }
          ]
        }
      ]
    },
    {
      "number": "03",
      "title": "What it does Transformer Block do?",
      "intro": "",
      "cards": [
        {
          "number": "08",
          "title": "Why was attention needed at all?",
          "tag": "Attention",
          "description": "To understand a token, it's helpful to take a quick look at other important tokens. In a long phrase, the word at the end may depend on the word at the beginning. Attention provides a direct mechanism: not to drag the whole meaning through a narrow neck, but to immediately choose what to look at now.",
          "blocks": [
            {
              "kind": "code",
              "label": "Diagram",
              "language": "text",
              "value": "PROBLEM WITHOUT ATTENTION\n\n\"Marina came home because she was tired\"\n\nTo understand \"she\", it is useful to see \"Marina\".\n\nWeak scheme:\n  token → token → token → token → ... → \"she\"\n  long-distance communication is blurred\n\nWith attention:\n  \"she\" ───────────────▶ \"Marina\"\n  the necessary connection is made direct"
            }
          ]
        },
        {
          "number": "09",
          "title": "Self-attention: each token asks who is useful to it now",
          "tag": "Attention",
          "description": "Self-attention is not magic, but a way to mix information between positions. Each token creates three versions of itself: query, key and value. Query says “what am I looking for”, key says “how can I help”, value is “what information I convey if I am selected”.",
          "blocks": [
            {
              "kind": "code",
              "label": "the essence of the formula without unnecessary mathematics",
              "language": "sql",
              "value": "for token i:\nq_i = W_Q x_i\nk_i = W_K x_i\nv_i = W_V x_i\n\nscore(i, j) = q_i · k_j\nweights(i, :) = softmax(scores)\nnew_x_i = Σ_j weights(i, j) v_j\n\nThat is, token i collects a weighted mixture of value from other tokens"
            },
            {
              "kind": "code",
              "label": "Diagram",
              "language": "sql",
              "value": "INTUITION BY EXAMPLE\n\nPhrase:\n  \"Marina came home because she was tired\"\n\nThe \"she\" token builds the query:\n  What kind of subject do you mean?\n\nOther tokens offer keys:\n  \"Marina\" → fits strongly\n  \"home\" → fits weakly\n  “tired” → helps in meaning, but not as a subject\n\nAfter softmax:\n  weight(\"Marina\") = 0.62\n  weight(\"home\") = 0.05\n  weight(\"tired\") = 0.18\n  ...\n\nNew vector \"she\" receives a lot of information from \"Marina\""
            }
          ]
        },
        {
          "number": "10",
          "title": "MLP: after context exchange there is local processing",
          "tag": "Block",
          "description": "Attention answers the question “from whom to get information.” But after this, the model must still transform the already collected meaning. This is what MLP does: a small two-layer block that is applied separately to each position.",
          "blocks": [
            {
              "kind": "code",
              "label": "simple MLP role",
              "language": "text",
              "value": "attention:\n  “she” realized that she was connected with “Marina”\n\nMLP:\n  reworked this context\n  enhanced beneficial symptoms\n  reduced the noise\n  prepared a presentation for the next block\n\nAttention = gather connections\nMLP = transform collected"
            }
          ]
        },
        {
          "number": "11",
          "title": "Residual + LayerNorm: the glue that holds the deep network",
          "tag": "Block",
          "description": "Transformer is not just attention and MLP. Residual connections and normalization are also important. Residual allows each block not to break an already useful representation, but to neatly add an improvement on top of the old one. LayerNorm keeps numbers in a stable range.",
          "blocks": [
            {
              "kind": "code",
              "label": "Diagram",
              "language": "sql",
              "value": "ANATOMY OF ONE BLOCK\n\nx\n│\n├─ self-attention(x) = a\n│\n├─ x + a ← residual\n│\n├─layernorm(...)\n│\n├─MLP(...)\n│\n├─ + previous path ← residual again\n│\n└─ layernorm(...) → block output\n\nThe block does not write everything from scratch, but improves the current state"
            }
          ]
        }
      ]
    },
    {
      "number": "04",
      "title": "Encoder, Decoder and Encoder-Decoder",
      "intro": "",
      "cards": [
        {
          "number": "12",
          "title": "Encoder: read everything at once and show understanding",
          "tag": "Architecture",
          "description": "The encoder model sees the entire input. Each token can look both left and right. Therefore, encoder is especially good where you need to understand the text, rather than continue it: classification, search, reranking, NER, feature extraction.",
          "blocks": [
            {
              "kind": "code",
              "label": "Diagram",
              "language": "text",
              "value": "ENCODER-ONLY\n\nLogin:\n  [token1] [token2] [token3] [token4]\n\nAttention:\n  everyone sees everyone\n\nOutput:\n  h1 h2 h3 h4\n\nNext:\n  or take one common vector\n  or read the label for each token\n\nStrength: Understanding the entire input"
            }
          ]
        },
        {
          "number": "13",
          "title": "Decoder: write from left to right without looking into the future",
          "tag": "Architecture",
          "description": "The decoder-only model also uses transformer blocks, but with a causal mask. The token at position `i` sees only what came before it. It is this limitation that makes generation possible: the model honestly predicts the next token without knowing the future answer.",
          "blocks": [
            {
              "kind": "code",
              "label": "Diagram",
              "language": "text",
              "value": "DECODER-ONLY\n\nPosition 1 sees: [1]\nPosition 2 sees: [1,2]\nPosition 3 sees: [1,2,3]\nPosition 4 sees: [1,2,3,4]\n\nYou can't:\n  token 2 look at token 4\n\nYou can:\n  at each step predict token 5\n\nGPT, Llama, Claude-like models are decoder-only"
            }
          ]
        },
        {
          "number": "14",
          "title": "Encoder-decoder: one reads the input, the other writes the output",
          "tag": "Architecture",
          "description": "In the encoder-decoder architecture, the two roles are separated. Encoder reads all the source text and builds a representation of it. The decoder generates a response one token at a time, but at each step it can look at the encoder outputs through cross-attention. This is useful for translating, summarizing and converting text from format A to format B.",
          "blocks": [
            {
              "kind": "code",
              "label": "Diagram",
              "language": "text",
              "value": "ENCODER-DECODER\n\nSource text\n  \"Translate: The cat is sleeping\"\n        │\n        ▼\n  ENCODER reads the whole thing\n        │\n        ▼\n  h1 h2 h3 h4 ... hN\n        │\n        ▼\n  DECODER writes:\n  \"Cat\"\n  \"The cat is sleeping\"\n  ...\n\nAt each step, the decoder has two sources:\n  1. already written part of the answer\n  2. the entire input through cross-attention\n\nSimple: reader + writer in one system"
            },
            {
              "kind": "list",
              "label": "when it's especially appropriate",
              "items": [
                "translation",
                "summation",
                "structural text transformation",
                "for free chat today they often use decoder-only"
              ]
            }
          ]
        }
      ]
    },
    {
      "number": "05",
      "title": "How a model learns",
      "intro": "",
      "cards": [
        {
          "number": "15",
          "title": "How to learn decoder-only LLM: guess the next token",
          "tag": "Training",
          "description": "The main task of the decoder-only model is simple: to guess the next token using the left context. During training, she is shown the correct text in its entirety and is forced to predict the next token at each position. This is called next-token prediction.",
          "blocks": [
            {
              "kind": "code",
              "label": "Diagram",
              "language": "sql",
              "value": "EXAMPLE OF TEACHING WITH A PHRASE\n\nText:\n  \"The cat is sitting on the carpet\"\n\nThe model is taught in many steps at once:\n  \"Cat\" → predict \"sits\"\n  \"The cat is sitting\" → predict \"on\"\n  \"The cat is sitting on\" → predict \"carpet\"\n\nDuring training:\n  the model sees the correct prefix\n  not your own past answer\n\nFrom millions of such chains “language knowledge” is born"
            },
            {
              "kind": "code",
              "label": "what is being optimized",
              "language": "python",
              "value": "for each position:\n  logits → softmax → P(next token)\n  compare with the correct token\n  calculate loss\n  adjust the weights a little\n\nrepeat this on billions of examples"
            }
          ]
        },
        {
          "number": "16",
          "title": "How an encoder learns: fill in gaps and understand the context",
          "tag": "Training",
          "description": "Encoder models are usually trained differently. They corrupt the input: they hide some of the tokens or distort the text, and then ask them to restore what they missed. To cope, the model is forced to look at the left and right context simultaneously and learn to \"understand\" well.",
          "blocks": [
            {
              "kind": "code",
              "label": "Diagram",
              "language": "text",
              "value": "SIMPLE MLM EXAMPLE\n\nOriginal:\n  \"The cat is sitting on a warm carpet\"\n\nBroken input:\n  \"Cat [MASK] on warm [MASK]\"\n\nTask:\n  guess \"sits\" and \"carpet\"\n\nTo fill in the blank, you need to understand the entire context around"
            }
          ]
        },
        {
          "number": "17",
          "title": "Backprop in simple words: error pushes weights in the right direction",
          "tag": "Training",
          "description": "After each prediction, the model is compared with the correct answer. If the probability of the correct token was too small, you need to slightly adjust the weights that led to this. Backprop is a way to neatly propagate an error back throughout the network.",
          "blocks": [
            {
              "kind": "code",
              "label": "without formal gravity",
              "language": "text",
              "value": "1. the model predicted the probabilities\n2. saw the correct token\n3. got the error value\n4. calculated which weights increased the error\n5. moved them a little in the opposite direction\n\nTraining = billions of micro-weight shifts"
            }
          ]
        }
      ]
    },
    {
      "number": "06",
      "title": "How the model responds",
      "intro": "",
      "cards": [
        {
          "number": "18",
          "title": "Prefill: first the model “reads” the entire prompt",
          "tag": "Inference",
          "description": "When a user sends a request, the model first runs the entire prompt through itself. At this step, it builds context states for all existing tokens. This is a preparatory pass before the first new token is generated.",
          "blocks": [
            {
              "kind": "code",
              "label": "what's going on",
              "language": "sql",
              "value": "prompt = system + history + user_text\n\ntokenize(prompt)\nembed(prompt_tokens)\npass all tokens through all blocks\nget hidden states for all positions\n\nThis is where the understanding of the context before the first word of the answer comes from"
            }
          ]
        },
        {
          "number": "19",
          "title": "Decode: further response is generated one token at a time",
          "tag": "Inference",
          "description": "After the first new token, the model adds it to the context and repeats the calculation. Then another one. And one more thing. Hence the feeling of flow when streaming. On the outside it looks like printing text, but on the inside it's a cycle of \"evaluate probabilities → select token → add to context.\"",
          "blocks": [
            {
              "kind": "code",
              "label": "Diagram",
              "language": "sql",
              "value": "AUTO REGRESSION\n\nContext:\n  \"Explain attention\"\n\nStep 1:\n  the model selects \"simple\"\n\nStep 2:\n  context = \"Explain attention in simple terms\"\n  the model chooses \"in words\"\n\nStep 3:\n  context = \"Explain attention in simple words\"\n  the model selects \".\"\n\nThe answer is built from left to right, and not a whole paragraph at once"
            }
          ]
        },
        {
          "number": "20",
          "title": "Logits, softmax and temperature: how the next word is chosen",
          "tag": "Inference",
          "description": "At the output of the generation block, the model does not output a word directly. It produces a set of numbers throughout the dictionary. These numbers are called logits. After softmax they turn into probabilities. Temperature changes the “sharpness” of this distribution: low makes the choice more conservative, high adds variety.",
          "blocks": [
            {
              "kind": "code",
              "label": "Diagram",
              "language": "text",
              "value": "NUMBERS IN THE LAST STEP\n\nLast hidden state\n        │\n        ▼\nLM head\n        │\n        ▼\nlogits:\n  \"yes\" = 8.2\n  \"no\" = 6.9\n  \"maybe\" = 6.1\n  \",\" = 4.4\n\nsoftmax →\n  P(\"yes\") = 0.63\n  P(\"no\") = 0.17\n  P(\"possible\") = 0.08\n  P(\",\") = 0.01\n\ntemperature ↓\n  T = 0.2 → distribution is sharper, almost always “yes”\n  T = 1.0 → balance between certainty and variability\n  T = 1.5 → more rare variants"
            },
            {
              "kind": "list",
              "label": "practical intuition",
              "items": [
                "low temperature: code, formal answers",
                "medium: normal chat",
                "high: creative, but more risk of noise"
              ]
            }
          ]
        }
      ]
    },
    {
      "number": "07",
      "title": "Limits and common sense",
      "intro": "",
      "cards": [
        {
          "number": "21",
          "title": "Why is the model hallucinating?",
          "tag": "Limits",
          "description": "The model was trained to continue the text plausibly, and not to verify the truth of each statement. Therefore, if the context is weak, the question is ambiguous, or similar patterns are mixed in the scales, she can confidently give a beautiful but incorrect answer.",
          "blocks": [
            {
              "kind": "code",
              "label": "typical source of error",
              "language": "text",
              "value": "little context\nor\nthere are too many similar patterns\nor\nrequired fact rare / fresh / controversial\n\n→ the model selects a statistically plausible continuation\n→ not a verified fact"
            }
          ]
        },
        {
          "number": "22",
          "title": "Why prompt helps, but does not rewrite the model",
          "tag": "Limits",
          "description": "Prompt works as a temporary context. It can direct the model's attention, set the role, give examples and push towards the desired style. But it does not change the weights themselves. Once the request completes, this temporary context disappears unless you save them in the next context.",
          "blocks": [
            {
              "kind": "code",
              "label": "Diagram",
              "language": "text",
              "value": "WEIGHTS vs CONTEXT\n\nWeights:\n  long-term model parameters\n  change only by training/fine-tuning\n\nPrompt:\n  temporary input of the current request\n  affects only through attention in this launch\n\nResult:\n  prompt = directs\n  fine-tuning = rebuilds the model's habits"
            }
          ]
        },
        {
          "number": "23",
          "title": "Short selection card: encoder, decoder or encoder-decoder",
          "tag": "Limits",
          "description": "If you remove the noise of terms, the choice of architecture depends on the type of task. Need to understand the input? More often encoder. Do you need to freely continue the text? Decoder-only LLM. Do you need to convert one text to another with a strict binding to the input? Often encoder-decoder.",
          "blocks": [
            {
              "kind": "table",
              "headers": [
                "Architecture",
                "How he looks at the text",
                "Strength",
                "Typical tasks"
              ],
              "rows": [
                [
                  "Encoder-only",
                  "sees the entire input at once",
                  "understanding and comparison",
                  "classification, embeddings, reranking, NER"
                ],
                [
                  "Decoder-only",
                  "only sees left context",
                  "free generation",
                  "chat, code, letters, brainstorming"
                ],
                [
                  "Encoder-decoder",
                  "reads the entire input and writes the output step by step",
                  "transformation A→B",
                  "translation, summarization, structured generation"
                ]
              ]
            },
            {
              "kind": "list",
              "label": "practical conclusion",
              "items": [
                "not everything related to text needs to be solved by LLM",
                "narrow task + a lot of traffic = often more profitable than encoder",
                "free generation almost always gravitates towards decoder-only"
              ]
            }
          ]
        }
      ]
    }
  ]
}
