Contents
  1. Text as vocabulary IDs
  2. Text units and preprocessing
  3. Subwords and unfamiliar-text coverage
  4. Learning and applying BPE merges
  5. Decoding and text preservation
  6. Special tokens and conversation formatting
  7. Language and formatting effects
  8. Joins, prefixes and offsets
  9. Complete-request token counts
  10. Tokenizer and model compatibility
  11. Check understanding
  12. Open questions
  13. Selected talks
  14. References
  15. Talk library
← All topics

Tokenization

Tokenization converts text into a model-specific sequence of integer identifiers. That conversion determines which distinctions survive, where text boundaries fall and how much input a request consumes. Reliable integration depends on understanding the complete interface: preprocessing, segmentation, reconstruction, structural markers and request formatting.

Text as vocabulary IDs

A vocabulary is a finite inventory of entries with integer IDs. A token occurrence references one entry at one sequence position. Encoding segments text and produces IDs; tokenizer decoding reconstructs text from IDs. Entries can represent whole words, fragments or characters, rather than one uniform linguistic unit.

Suppose a vocabulary contains cat → 7, space → 8 and dog → 9. The text cat cat becomes [7, 8, 7]: three occurrences referencing two distinct entries in a three-entry inventory. The repeated 7 preserves identity. Its numerical distance from 9 does not measure similarity in meaning.

Text and IDs cross different interfaces

The model consumes IDs; reconstruction interprets its output IDs.

Encoding maps text to vocabulary IDs. The model produces output IDs, which the matching decoder reconstructs as text. Model computation and text reconstruction are separate operations.
Read the diagram as text
  • Input text.
  • Tokenizer encoder.
  • Input ID sequence.
  • Model. Computation is outside this diagram's scope.
  • Output ID sequence.
  • Tokenizer decoder.
  • Reconstructed text.
  • Input textTokenizer encoder: Text.
  • Tokenizer encoderInput ID sequence: Encode.
  • Input ID sequenceModel: Condition on IDs.
  • ModelOutput ID sequence: Generate IDs.
  • Output ID sequenceTokenizer decoder: IDs.
  • Tokenizer decoderReconstructed text: Reconstruct.

Text units and preprocessing

A Unicode code point is a numbered position in Unicode's codespace. Character encodings represent text using code units: UTF-8 uses bytes, while UTF-16 uses 16-bit units. A programming language's string length may count these units rather than visible characters.

A grapheme cluster approximates a user-perceived character. A base letter followed by a combining accent can form one cluster despite containing two code points. Neither grapheme boundaries nor byte boundaries necessarily coincide with model-token boundaries.

Where text and boundaries change

Coverage after normalization cannot recover discarded distinctions.

This configurable pipeline transforms text, imposes regions, segments within them, maps pieces to IDs and inserts configured structural tokens.
Read the diagram as text
  • Original text.
  • Normalization. Configured transformation, or identity when absent.
  • Pre-tokenization. Establish permitted regions.
  • Segmentation. Operate within regions.
  • Vocabulary lookup.
  • Post-processing. Insert configured structural tokens.
  • Original textNormalization: Source text.
  • NormalizationPre-tokenization: Transformed text.
  • Pre-tokenizationSegmentation: Bounded regions.
  • SegmentationVocabulary lookup: Pieces.
  • Vocabulary lookupPost-processing: IDs.
Two representations of an accented letter
Text representationCode pointsUTF-8 bytesGrapheme clusters
Precomposed éU+00E9: oneC3 A9: twoOne
e followed by combining acute accentU+0065 U+0301: two65 CC 81: threeOne

Normalization selects a representation under an equivalence rule. NFD canonically decomposes characters; NFC also composes them where possible. NFKD and NFKC additionally apply compatibility transformations, such as replacing the fi ligature with fi. Compatibility normalization can discard meaningful distinctions. Lowercasing and accent removal are separate transformations, not synonyms for Unicode normalization.

Pre-tokenization partitions text into regions before segmentation. A punctuation-splitting configuration separates the apostrophe in I'm; individual-digit splitting makes 911 three regions. Later merges cannot cross those imposed boundaries. These stages are configurable, so case and whitespace behavior must be checked for the selected tokenizer.

Subwords and unfamiliar-text coverage

A subword is a reusable text segment, not necessarily a root or syllable. An out-of-vocabulary string lacks a direct entry; smaller pieces may still represent it. An unknown token is a placeholder used when the configured representation cannot cover the input.

Declared teaching inventories; vertical bars mark boundaries. These ASCII examples make character and byte lengths equal.
Inventorycatcatnap
Whole words: cat plus unknowncatUnknown
Lowercase charactersc|a|tc|a|t|n|a|p
All byte values; hexadecimal display63|61|7463|61|74|6E|61|70
Lowercase characters plus cat and napcatcat|nap

Whole-word coverage demands a growing inventory; character sequences require more positions for the same passage. Subwords balance these pressures. For a small model, a compact vocabulary can be useful even when it produces longer sequences. Inventory size alone therefore cannot identify the best representation.

Complete byte coverage starts with every byte value. Byte fallback instead uses UTF-8 byte tokens when ordinary pieces cannot represent a character. SentencePiece configuration distinguishes fallback, character coverage and normalization. Representing every remaining byte cannot restore text already changed by normalization.

Learning and applying BPE merges

Byte-pair encoding, or BPE, adapts a compression idea: repeatedly replace frequent adjacent symbol pairs with larger symbols. A corpus is the collection used to learn these rules. Pair frequencies include repeated occurrences of each word; merges change the counts available at the next iteration.

Illustrative pseudocode Python-like pseudocode
# Character-initialized, word-bounded training.
segments = split_words_into_characters(corpus, end_marker)
rules = []
for _ in range(merge_budget):
    counts = weighted_adjacent_pair_counts(segments, frequencies)
    if not counts:
        break
    pair = highest_count_pair(counts, tie_order)
    segments = replace_nonoverlapping_pairs(segments, pair)
    rules.append(pair)

Two frequency-weighted merges

Example

New pieces create new adjacent pairs.

1 / 3 · Initialize

Word boundaries prohibit cross-word merges.

Corpus weights remain fixed. Segmentation changes; learned rules accumulate. ◇ marks word ends. Prior snapshots remain visible.
Read the diagram as text
  • Fixed corpus. low×5; lower×2; newest×6; widest×3.
  • Initial: characters + ◇. e+s, s+t, t+◇ each count 9.
  • Rule 1: e+s → es. Declared first tie choice.
  • After merge 1. n|e|w|es|t|◇ ×6; w|i|d|es|t|◇ ×3.
  • Rule 2: es+t → est. Count 9; chosen over t+◇.
  • After merge 2. n|e|w|est|◇ ×6; w|i|d|est|◇ ×3.
  • Fixed corpusInitial: characters + ◇: Initialize.
  • Initial: characters + ◇Rule 1: e+s → es: Count; select.
  • Rule 1: e+s → esAfter merge 1: Replace.
  • After merge 1Rule 2: es+t → est: Recount; select.
  • Rule 2: es+t → estAfter merge 2: Replace.
  1. Initialize. Word boundaries prohibit cross-word merges. Active: Fixed corpus, Initial: characters + ◇. New: Fixed corpus, Initial: characters + ◇.
  2. Merge once. low and lower remain unchanged. Active: Fixed corpus, Initial: characters + ◇, Rule 1: e+s → es, After merge 1. New: Rule 1: e+s → es, After merge 1.
  3. Merge twice. Stop at the two-merge budget. Active: Fixed corpus, Initial: characters + ◇, Rule 1: e+s → es, After merge 1, Rule 2: es+t → est, After merge 2. New: Rule 2: es+t → est, After merge 2.

The figure's two rules encode the new word lowest as l|o|w|es|t|◇, then l|o|w|est|◇. The end marker ◇ is structural, not literal source text.

Encoding uses fixed merge ranks: priorities learned beforehand. It does not recount request-local frequencies. Byte-level implementations can start each permitted region with UTF-8 bytes rather than characters; preprocessing still restricts which pairs may merge.

Illustrative pseudocode Python-like pseudocode
# Encode one permitted region with fixed ranks.
pieces = initial_symbols(region)
while True:
    candidates = eligible_adjacent_pairs(pieces, ranks)
    if not candidates:
        break
    pair = minimum_rank_pair(candidates, ranks)
    pieces = replace_nonoverlapping_pairs(pieces, pair)
ids = [vocabulary[piece] for piece in pieces]

Suppose bc ranks before ab, both are available, and no larger merge exists. Ranked BPE encodes abc as a|bc. Left-to-right longest matching chooses ab|c. The vocabulary alone therefore does not specify the segmentation decision.

Other segmentation rules
MethodEncoding decision
WordPieceThe original BERT implementation takes the longest available match at each position. Continuation pieces use ##. If a remaining span cannot match, the whole word becomes unknown; unaffable is demonstrated as un|##aff|##able.
UnigramAssign probabilities to pieces and choose the segmentation with the largest product. Alternative segmentations can also be sampled. These probabilities score segmentations, not factual truth.
SentencePieceA toolkit supporting several methods, including BPE and Unigram; its name does not identify one decision rule.

Decoding and text preservation

Tokenizer decoding maps IDs through vocabulary pieces into text. Generation decoding instead selects the next output token; LLM Inference covers that process. Reconstruction cannot recover distinctions that encoding discarded.

Text preservation depends on the complete conversion.

  • NormalizationA normalized result can preserve the chosen equivalence while differing from the original code-point sequence.
  • Unknown inputAn unknown-token placeholder cannot identify the original excluded character.
  • Display optionsSpace cleanup and special-token removal can change decoded text.

Preserve bytes before reconstructing text

Example

Replacement loses the original fragments.

Declared token-byte partition C3 | A9, not a released vocabulary fixture. Joint decoding yields é; independent replacement decoding yields ��.
Read the diagram as text
  • C3 | A9. Two token byte fragments.
  • C3 A9.
  • é.
  • � | �.
  • ��.
  • C3 | A9C3 A9: If joining bytes first.
  • C3 A9é: Decode UTF-8.
  • C3 | A9� | �: If independently replacing errors.
  • � | ���: Join text.

UTF-8 reconstruction must handle complete byte sequences. The replacement character, U+FFFD, marks decoding errors; it does not preserve their original bytes. Incremental reconstruction retains incomplete trailing bytes until more arrive, rather than treating every token boundary as the end of a string.

Text equality and ID equality are separate invariants. In GPT-2's published fixtures, [15, 15] reconstructs 00, whose encoding is [405]. Re-encoding selects the tokenizer's segmentation, not necessarily the sequence originally supplied.

Special tokens and conversation formatting

A special token is a designated vocabulary entry with a structural or control role. Its readable spelling and reserved ID are different representations. A separator marks a boundary; beginning, ending and padding conventions depend on the model.

Structural roles
MarkerPurpose
BOSBeginning of sequence or prompt.
EOSEnd-of-sequence convention used for stopping.
PADPadding used to equalize sequence lengths within a batch.
Turn ending or handoffLlama distinguishes eot_id for turn completion, eom_id for handoff and end_of_text for base-model stopping. They are not interchangeable.

Insert structural boundaries once

A second insertion stage risks duplicate boundaries.

Direct template tokenization includes required structure. Rendering first requires disabling subsequent special-token insertion. Re-enabling it risks duplication.
Read the diagram as text
  • Ordered messages.
  • Matching chat template.
  • Rendered text with boundaries.
  • Complete input IDs.
  • Duplication risk.
  • Ordered messagesMatching chat template: Message data.
  • Matching chat templateComplete input IDs: If tokenize=True.
  • Matching chat templateRendered text with boundaries: If tokenize=False.
  • Rendered text with boundariesComplete input IDs: Encode: add_special_tokens=False.
  • Rendered text with boundariesDuplication risk: If boundaries are added again.
For recognized marker spellings, tiktoken exposes explicit policies.
PolicyResult
Default rejectionRaise an error for a recognized special-token spelling.
Treat as ordinary textSegment the spelling into ordinary pieces.
Explicitly allow recognitionEmit the designated reserved ID.

A chat template serializes ordered messages into model-specific content and boundaries. HTTP request JSON is not necessarily the tokenized text. A generation prompt supplies an assistant-start prefix where required.

Constructed from the pinned Mistral-7B-Instruct-v0.1 template
Structured inputTemplate contribution
User: Hi [INST] Hi [/INST]
Assistant: HelloHello
User: Bye[INST] Bye [/INST]

Together these contributions produce <s> [INST] Hi [/INST] Hello</s> [INST] Bye [/INST]. This configuration assigns BOS ID 1 and EOS ID 2; the complete conversation IDs are not shown. Its template adds no separate assistant prefix when add_generation_prompt is enabled. That option's effect depends on the template.

Boundary insertion needs one owner. Training with duplicated BOS markers and serving with one changes the representation even when message text matches. Daniel Han's fine-tuning examples illustrate this mismatch. Marker recognition also does not authorize instructions: role formatting cannot by itself separate trusted commands from hostile content; AI Security covers that boundary.

Language and formatting effects

Capitalization, leading spaces and surrounding punctuation can change a word's segmentation. Unusual code identifiers can fragment where common names remain compact. These effects follow vocabulary coverage and preprocessing; they do not establish that tokenization alone causes spelling or reasoning failures.

Published tiktoken test assertions, not local execution results. Their moving source requires revision pinning for reproducible fixtures; \n denotes newline.
EncodingTextResult
GPT-2hello world[31373, 995]
cl100k_basehello world[15339, 1917]
cl100k_basetoday\n␠ → today\n␠\n; ␠ means space3 tokens → 2 tokens
cl100k_base👍[9468, 239, 235]: three tokens

Subword fertility is the average number of subwords per tokenized word. Its denominator requires a stated word-segmentation convention. A separate measure records how often words split at all. Neither quantity measures comprehension, and comparisons across writing systems require care about what counts as a word.

Equivalent meanings also need not have equal lengths. A study using 2,000 FLORES-200 sentences translated into 200 languages compared token counts for corresponding translations. Ratios varied across evaluated languages and tokenizers. Topic selection, named entities and translation choices affect those ratios, so representation efficiency must remain distinct from translation quality or general language ability.

Joins, prefixes and offsets

Joining text can create eligible pairs across the join. With the earlier bc-first rules, separately encoding a and bc agrees with encoding abc; separately encoding ab and c does not. Equality must be established for the actual join, not assumed from correct fragment encodings.

An unfinished suffix may change when more text arrives, while pre-tokenization boundaries constrain possible merges. Consequently, tokenized prefixes need not remain prefixes after extension. Truncating IDs, decoding them and re-encoding text can also change segmentation. Explicit structural boundaries and ordinary text joins must be treated according to their configured rules.

Operation order changes IDs

Counts need not add.

GPT-2 fixtures: two separately encoded zeros produce two IDs; joined text produces one.
Read the diagram as text
  • Fragments: 0 and 0.
  • [15] and [15].
  • [15, 15].
  • 00.
  • [405].
  • Fragments: 0 and 0[15] and [15]: If encoding first.
  • [15] and [15][15, 15]: Join IDs.
  • Fragments: 0 and 000: If joining text first.
  • 00[405]: Encode.
Offsets need both a unit and a coordinate origin. In the NormalizedString NFKC example, mathematical double-struck text becomes ordinary letters; ranges are half-open UTF-8 byte ranges.
RangeSelected spanCorresponding span
Original bytes [0, 4)𝔾Normalized: G
Normalized bytes [0, 4)GoodOriginal: 𝔾𝕠𝕠𝕕

The same numerical interval selects different text because normalization changes the coordinate system. These internal Rust ranges do not establish every tokenizer API's offset units. Token positions, source-byte offsets and character indexes require explicit conversion rather than direct substitution.

Complete-request token counts

An exact local count describes one fully specified representation. Fix the tokenizer artifacts, preprocessing, special-token policy and template, then count the final IDs. Document-level counts are useful for screening, as demonstrated in Noah Hein's workshop, but do not establish the length of a subsequently assembled conversation.

Illustrative pseudocode Python-like pseudocode
# tokenizer and tools match the checkpoint's template.
ids = tokenizer.apply_chat_template(
    messages,
    tools=tools,
    tokenize=True,
    add_generation_prompt=True,
)
input_count = len(ids)
Different counts answer different questions.
CountWhat it establishes
String or byte lengthSize in the programming language's or encoding's units, not model tokens.
Content-only tokensEncoding length of supplied text without necessarily including conversation structure.
Final local IDsLength of that template's complete representation, including retained messages and template-supported material.
Provider countThe provider's documented accounting boundary, which may include additional material or estimation.

Claude's counting endpoint accepts structured messages, system prompts and tool definitions, but documents its result as an estimate that may differ slightly from message creation. A reproducible local count and an eventual provider count therefore make different promises. Fixed character ratios or per-message constants cannot erase that distinction.

The context window is a finite token allowance. Known input length, requested maximum output and actual generated length are distinct; their combined constraint and separate limits depend on the model and endpoint. Output caps do not themselves validate input fit. Context Engineering covers selecting and reducing included material when the complete request exceeds its allowance.

Tokenizer and model compatibility

A checkpoint is a saved model artifact containing learned state. Its tokenizer must preserve the expected vocabulary mapping and input conventions. A different tokenizer can assign the same integer to a different entry. Matching vocabulary sizes or readable reconstructed text therefore does not establish compatibility.

Adding vocabulary entries requires corresponding model dimensions, but resizing alone does not teach useful behavior for new IDs. Tokenizer artifacts, segmentation settings, special-token definitions and the chat template need to move together with the model.

Focused representation checks
FailureCheck that exposes it
Unexpected segmentationCompare deterministic IDs against fixtures tied to the intended tokenizer revision.
Lost text distinctionsCompare original text with reconstruction under the declared normalization policy.
Corrupted streamed charactersTest reconstruction when token delivery divides a multibyte character.
Unexpected structural interpretationTest marker-like user text under the intended literal or special-token policy.
Duplicated boundariesInspect the final training and serving sequences for exactly-once insertion.
Incorrect request sizeCount complete assembled input; distinguish local results from provider estimates.
Illustrative pseudocode Python-like pseudocode
# Fixture contract: deterministic, text-preserving settings.
ids = encode(text)
assert decode(ids) == text
assert ids == expected_ids

The assertions establish different properties: preserved text and unchanged representation. After an intentional tokenizer update, changed expectations require review of the responsible configuration. Automatically accepting new fixtures can hide an unintended change. Passing representation checks still does not establish model quality.

Open questions

  1. Reducing unequal representation costs across languages remains difficult because word boundaries, translations and corpus composition change the comparison. Progress would require smaller disparities on several parallel and domain-specific corpora without sacrificing text coverage or downstream quality.

  2. Choosing vocabulary granularity under constrained resources remains a joint design problem: larger inventories and longer sequences impose different burdens. A useful comparison would hold data and resource allowances fixed while measuring both representation length and task quality, rather than declaring a winner from token count alone.

  3. Portable source-span alignment remains difficult when normalization changes byte lengths and APIs expose different coordinate units. Progress would be an explicit cross-runtime contract that reproduces the same original spans for composed, decomposed and compatibility-normalized text.

Follow the curated reading path through the speakers and demonstrations behind this entry.

Explore more talks

The rest of the library, beyond the curated path. Cited talks support this entry; reviewed transcripts were processed in full. Metadata candidates have not been reviewed as sources or verified as topic members.

8 matching talks

TalkSpeakerEventYear
Diego CarpenteroAI Engineer Europe 20262026
AI Engineering 101

Cited in this entry

Noah HeinAI Engineer Summit 20232023
Jamie Neuwirth, Zack WittenAI Engineer World's Fair 20242024
Philipp KrennAI Engineer World's Fair 20252025
Daniel HanAI Engineer World's Fair 20242024
Mark MoyouAI Engineer World's Fair 20242024
Yesu FengAI Engineer World's Fair 20252025
Ishan AnandAI Engineer World's Fair 20242024

References

Coverage and source review
Processed transcripts
6 processed in full · 4 in the curated path
Automated source review
Passed
Metadata candidates
6 unreviewed; not verified topic membership
Corpus version
1bd8e407b26a07b33815594e1b2db5f41827119a2b3cb6fbf240f9fc571fc767

Automated review checks source support; it is not publication approval.

A synthesis of selected conference talks and technical references. Citations link to the source material; they do not imply that every talk on this subject is included.

  1. Hugging Face: Tokenizers

    Tokenizers introduction; Word-based; Character-based; Subword tokenization; Encoding; Decoding.

  2. How LLMs work for Web Devs: GPT in 600 lines of Vanilla JS

    A token ID identifies a vocabulary entry; its embedding supplies the numeric representation used to express relationships and perform model computation.

  3. Unicode Glossary

    Code Point, Encoded Character, Code Unit and Unicode Scalar Value entries; terminology for distinguishing text representations.

  4. Unicode Standard Annex #29: Unicode Text Segmentation

    Unicode 17.0, introduction, conformance and grapheme-cluster sections; first-use explanation and word-denominator caveat.

  5. Unicode FAQ: UTF-8, UTF-16, UTF-32 and BOM

    Encoding-form comparison and malformed-sequence handling; explains why byte fragments cannot always be decoded independently.

  6. Unicode Standard Annex #15: Unicode Normalization Forms

    Sections 1.1–1.2, equivalence examples and normalization-form definitions.

  7. Hugging Face Tokenizers: The tokenization pipeline

    Normalization, Pre-Tokenization, Model and Post-Processing sections; concrete preprocessing examples.

  8. Tokenization algorithms — Transformers

    Official algorithm overview; subword vocabulary, BPE training, and byte-level BPE.

  9. How LLMs work for Web Devs: GPT in 600 lines of Vanilla JS

    Whole-word tokenization trades a growing vocabulary for difficulty representing unknown or misspelled words.

  10. How LLMs work for Web Devs: GPT in 600 lines of Vanilla JS

    Character-level tokenization lengthens the sequence, enlarging the token-indexed matrices processed by the demonstrated model.

  11. Training an LLM from Scratch, Locally

    A large vocabulary can make the embedding table disproportionately large for a tiny model.

  12. SentencePiece configuration options

    Model type, character coverage, special symbols, byte fallback and normalization options.

  13. How LLMs work for Web Devs: GPT in 600 lines of Vanilla JS

    Byte-pair encoding (BPE) repeatedly merges frequent adjacent token pairs, growing the vocabulary while shortening the corpus representation.

  14. Training an LLM from Scratch, Locally

    Byte pair encoding (BPE) builds reusable tokens from recurring character patterns in the training data.

  15. Neural Machine Translation of Rare Words with Subword Units

    Section 3.2 and Algorithm 1; weighted-count observation is arithmetic from the published corpus.

  16. How LLMs work for Web Devs: GPT in 600 lines of Vanilla JS

    The demonstrated GPT-2 tokenizer uses the trained merge vocabulary and rankings to turn new text into the model's existing tokens.

  17. Language Models are Unsupervised Multitask Learners

    Introduction; section 2, Approach, equation 1; section 2.2, Input Representation.

  18. tiktoken educational byte-pair encoding implementation

    SimpleBytePairEncoding.encode, bpe_encode and bpe_train; counterexample is a direct illustrative application of the inspected algorithm.

  19. BERT original WordPiece tokenizer implementation

    WordpieceTokenizer.tokenize; concise comparison with ranked BPE encoding.

  20. Subword Regularization: Improving Neural Network Translation Models with Multiple Subword Candidates

    Section 3.2, equations 6–7, and Section 3.3; optional algorithm comparison.

  21. Hugging Face course: tokens and vocabulary IDs

    Word-based, character-based and subword tokenization; Encoding; Decoding.

  22. Language Models are Unsupervised Multitask Learners

    Section 2, Approach, equation 1; section 2.2, Input Representation; section 3.7, Summarization; generated samples.

  23. Transformers Tokenizer API

    decode, batch_decode, add_tokens, add_special_tokens and apply_chat_template; complements supplied serialization notes with interface-change conditions.

  24. Utilities for Generation: TextStreamer and TextIteratorStreamer

    Official Streamers API sections, put/end methods, queue behavior and threaded example.

  25. tiktoken encoding regression tests

    test_simple, test_simple_repeated, test_simple_regex, test_encode_surrogate_pairs, round-trip and special-token tests.

  26. Llama 3.3 Prompt Formats

    Tokens and User and assistant conversation sections; concrete illustration of distinct ending conventions.

  27. Transformers GenerationConfig: output reservation and termination

    GenerationConfig: Parameters that control the length of the output; Special tokens that can be used at generation time.

  28. tiktoken Encoding API implementation

    encode, encode_ordinary, decode, decode_single_token_bytes, decode_with_offsets and encode_with_unstable.

  29. Transformers: model-specific chat serialization

    Chat templates introduction; Using apply_chat_template; special-token warning; add_generation_prompt subsection.

  30. Mistral-7B-Instruct-v0.1 tokenizer configuration at b54db9339734a22dd2b55531bd8146540729fbb8

    Exact checkpoint configuration and template revision; serialization is an explicitly constructed teaching example derived from the template, not executed output.

  31. Fixing bugs in Gemma, Llama & Phi-3

    Check that training and inference insert the same single beginning-of-sentence (BOS) token where the model requires one.

  32. $1 AI Guardrails: The Unreasonable Effectiveness of Finetuned ModernBERTs – Diego Carpentero

    Direct injection and indirect injection—the speaker's context vector—exploit the model's weak separation between instructions and data; even review targets can contain instructions that bias their own evaluation.

  33. How LLMs work for Web Devs: GPT in 600 lines of Vanilla JS

    Tokenization can worsen character-counting problems because different surface forms of the same word become different token patterns.

  34. Training an LLM from Scratch, Locally

    An uncommon variable name need not have its own vocabulary entry; it can split into smaller pieces, increasing inference work.

  35. tiktoken regression tests: explicit thumbs-up token IDs

    Adds exact emoji IDs to the reused fixture note, which already supplies the three-token count. Uses the test's default encode configuration.

  36. How Good is Your Tokenizer? On the Monolingual Performance of Multilingual Language Models

    Tokenizer analysis, Figure 1 and Appendix A.3; definition and bounded multilingual evidence.

  37. Language Model Tokenizers Introduce Unfairness Between Languages

    Sections 3–4 and discussion of parallel-corpus limitations; evidence that comparable meaning need not occupy comparable token counts.

  38. Hugging Face Tokenizers: NormalizedString implementation and alignment tests

    NormalizedString structure, range conversion interface and slice test. Supplies an inspected upstream normalization-alignment fixture without reconstructing a tokenizer pipeline.

  39. AI Engineering 101

    The workshop treats tokenization as model-coupled and counts encoded tokens per document before processing.

  40. Transformers: chat templates serialize conversation history

    Chat templates introduction; Using apply_chat_template; add_generation_prompt; template special-token guidance.

  41. Understanding and counting tokens — OpenAI

    Official definitions, full-request accounting, reasoning-token and model-limit sections inspected.

  42. Claude Platform: Token counting

    How to count message tokens; text-request accounting boundary only.

  43. Conversation state: managing the context window — OpenAI

    Official Managing the context window section; the allocation procedure is an explicit engineering application of the documented limits.

  44. Google Machine Learning Glossary: training, inference, tokens, context, and RAG

    Official glossary entries for training, inference, token, context window, and retrieval-augmented generation; introductory vocabulary for c2, not an authority on agent security.

  45. Fixing bugs in Gemma, Llama & Phi-3

    Preserve the training chat template in the serving configuration; the demonstrated workflow generates an Ollama Modelfile from the fine-tuning setup.

  46. Training an LLM from Scratch, Locally

    Character-level tokenization keeps the workshop vocabulary small but requires more tokens and more composition to represent meaningful text.

  47. MCP = Mega Context Problem - Matt Carey

    Creating and loading a separate tool for every API endpoint can make the tool descriptions themselves exceed a practical context budget.