← back
00 · opening
Last updated July 23, 2026

The transformer never sees a word.

You already know the trick for text: split it into tokens, turn each token into a vector, let attention mix them, predict the next one. A multimodal model does the exact same thing to a photo, a voice note, a PDF. Nothing about the reasoning core changes. The whole job is teaching each new sense to speak in vectors.

· four senses, one language · TEXT · IMAGE AUDIO · PDF any input VECTORS one shared space 1 TRANSFORMER same attention

scroll

01 · the one thing to carry over

A language model already doesn't read words.

Here is the fact everything else hangs on. When you type a sentence into an LLM, the very first thing it does is throw the letters away. Each token is looked up in a table and replaced by a list of numbers, a vector of a few thousand values. From that moment on, the model is only ever pushing vectors around.

Attention does not know it is working on English. It takes a list of vectors, has each one look at the others, and mixes them. The final vector is turned back into a probability over the vocabulary, and one token is sampled. Append it, run again. That loop is the whole engine.

So the model's real input was never text. It was a sequence of vectors. Text is just one convenient way to produce them. Hold onto that, because it is the entire secret to how images, audio and documents get in.

the pivot If the transformer eats vectors and does not care where they came from, then any thing you can turn into a sequence of vectors can be fed to it. Multimodality is not a new brain. It is new doorways into the same room.
02 · the unifying idea

Every modality is a different door to one room.

Picture a single, shared vector space: an enormous coordinate system where a point can mean the word "dog," the sound of a bark, or a photo of a spaniel, and if they mean the same thing, they sit near each other. The transformer lives inside this room and reasons over whatever points it is handed.

Each modality gets its own encoder, a piece of network whose only job is to take raw input, pixels, audio samples, a rendered page, and turn it into points in that shared room. The encoder is the border crossing. Text has a trivial one, a lookup table. Images and audio need real neural networks. But once anything is through the door, it is just vectors on the same footing as the words, and attention mixes them all together in one sequence.

many encoders in, one transformer
TEXT IMAGE AUDIO PDF lookup table vision encoder audio encoder render + vision SHARED VECTOR SPACE TRANSFORMERattention · same as ever next token
Swap the leftmost column and the encoders change. The shared space and the transformer never do.
in essence · the transformer never asks where a vector came from
# one model, many inputs. the encoder is the only modality-specific part.
def forward(inputs):                 # inputs: text, an image, some audio, a page...
    seq = []
    for x in inputs:
        enc = ENCODERS[x.modality]      # pick the door for this modality
        seq += enc(x)                   # -> vectors in ONE shared space
    return transformer(seq)            # same attention, same next-token loop
# pixels instead of words changes ENCODERS, not the transformer.
03 · the vectors, concretely

What an embedding actually looks like.

"Turned into a vector" stays abstract until you watch it happen once. So here is one worked example per door, with real shapes. The width below is 4,096 numbers, the embedding dimension of a Llama-3-8B-class model. Bigger models use wider vectors, but the story never changes.

text · a lookup

"dog"

input
The token "dog", which the tokenizer maps to one integer, say id 5679.
what happens
Row 5,679 is copied out of a learned table of shape [128,256 × 4,096]. No math at all.
output
4,096 floats.
image · a matmul

one 16×16 patch

input
16 × 16 pixels × 3 colors = 768 raw numbers, the patch's RGB values scaled to about ±1.
what happens
One learned matrix of shape [4,096 × 768] multiplies the pixel list. A single matmul.
output
4,096 floats.
audio · a small net

~20 ms of sound

input
A slice of the spectrogram: 80 mel energies per 10 ms frame, plus its neighbors.
what happens
A conv stem and encoder layers digest it; a connector stretches the result to the LLM's width.
output
4,096 floats, one vector per ~20 ms.
in essence · three doors, one identical output
# the same LLM width (4,096 floats), reached three ways
"dog"                             # text: a table lookup, no computation
  → id 5679 → E[5679]
  → [ 0.013, -0.208,  0.091, ...,  0.044]

patch(row 3, col 7)               # image: one matrix multiply768 pixel values → W @ px
  → [-0.171,  0.062, -0.055, ...,  0.238]

frame @ t=1.20s                   # audio: conv + attention, then a connector80 mel energies → encode
  → [ 0.087, -0.114,  0.302, ..., -0.201]
# three origins, one shape. downstream, nothing can tell them apart.
The float values are invented for illustration. The shapes and the mechanics are the real ones.
the point An embedding is not a summary or a description. It is just a fixed-length list of floats, and every door is judged by one thing only: whether it drops its floats in the right neighborhood. Text earns its list by lookup, a patch by a matmul, a sound by a small network. The transformer receives identical-looking lists either way.
04 · images, part one

An image is worth sixteen-by-sixteen words.

A sentence is already a sequence, so tokenizing it is natural. An image is a grid of a million pixels, with no obvious "first" or "next." The Vision Transformer solved this with an idea so blunt it is almost funny: chop the image into a grid of small squares and call each square a token. A patch of, say, 16×16 pixels becomes one item in a sequence, exactly like a word.

Each patch is flattened into a line of numbers and pushed through one small linear layer, a patch embedding, which turns its raw pixels into a vector in the shared space. Then a positional embedding is added so the model knows where the patch sat. Now the picture is a sequence of vectors, and it can walk into the same transformer the words use.

a picture becomes a sequence
one image · 16 patches 16 vectors · one per patch
the patch's journey · tap a station or press play
01 / the image
A grid of pixels.
Start with a raw photo, a wall of red-green-blue values with no order the model can read yet.
05 · order & position

Attention has no idea what came first.

Why did that stepper need an "add position" station at all? Look at what attention literally computes. Each token derives three small vectors, a query, a key and a value. The score between two tokens is a dot product of a query with a key. The scores are softmaxed into weights, and the output is a weighted average of the values. Every one of those operations acts on a set. No index, no "previous", no "next" appears anywhere in the formula.

in essence · attention is a weighted average over a set
# attention, for one token A among {A, B, C}
w = softmax([q_A·k_A, q_A·k_B, q_A·k_C])   # who should A look at?
out_A = w[0]*v_A + w[1]*v_B + w[2]*v_C      # a weighted average. that is all.
# hand it B and C in swapped order: the same numbers come out.
# without position, "dog bites man" and "man bites dog" are one bag of words.

So order has to be smuggled in as data: before attention runs, a position vector is added to each token's embedding. After that, two queries and keys can "feel" how far apart their tokens sit, because the position signal is baked into the dot products.

What does that position vector look like? The original 2017 transformer used sine waves: each dimension oscillates at its own frequency, fast ones ticking every position, slow ones drifting across thousands, like the second, minute and hour hands of a clock. A Vision Transformer instead keeps a plain learned table, one free vector per grid slot, random at the start, shaped by training. And most modern LLMs use RoPE, which rotates the query and key vectors by an angle proportional to position instead of adding anything at all. Three flavors, one job: make identical tokens at different slots look different.

the sinusoidal position table · one column per position
Read the highlighted column top to bottom: that list of values is the vector added to the token at slot 9. Fast rows tick every step, slow rows drift across dozens. A position, written in sine waves.
the point Order is not part of the machine. It enters the transformer the same way meaning does: as numbers folded into the vectors. Which is exactly why the same trick generalizes, a 1D position for words, a 2D grid position for image patches, a timestamp for audio frames.
06 · images, part two

Teaching pixels and words to share an address.

Patchifying gives you image vectors, but they start out in the vision encoder's own private space, not the language model's. Two moves connect them.

First, alignment. A model called CLIP is trained on hundreds of millions of image-caption pairs to place a photo and its description at the same spot. After that, "a photo of a dog" and an actual dog photo are neighbors. The vision encoder now speaks a language the text model can understand.

Second, the bridge. Most vision-language models keep a frozen CLIP-style encoder and bolt on a tiny connector, often a two-layer network, that projects image vectors precisely into the LLM's token space. This is the recipe behind LLaVA and most open vision models: a photo enters as a few hundred visual tokens, slotted into the prompt right next to the words.

in essence · one training example from each stage, verbatim
# a CLIP alignment pair (one of ~400,000,000)
{ "image": beach_dog_0412.jpg,      # just pixels, nothing labeled inside
  "text":  "a golden retriever running on a beach" }
# batched 32,768 at a time: pull each true pair together,
# push the 32,767 mismatches apart. that is the whole recipe.

# a LLaVA connector-tuning example (one of ~600,000)
{ "image": "coco/000000215677.jpg",
  "conversations": [
    { "from": "human", "value": "<image>\nWhat is unusual about this image?" },
    { "from": "gpt",   "value": "The man is ironing clothes on a board
                              attached to the roof of a moving taxi." } ] }
# at train time the <image> slot is replaced by ~576 vectors from the
# frozen vision encoder. only the tiny connector learns to make them legible.

That "few hundred tokens" is why images cost what they do. Providers slice a picture into tiles and charge per tile. It is the same accounting as text: more visual detail means more tokens means more compute.

in essence · why one photo costs a paragraph's worth of tokens
# how many tokens is an image? (OpenAI high-detail accounting, 2026)
def image_tokens(w, h, tile=512):
    w, h = fit_inside(w, h, box=2048)      # shrink to fit a 2048 box
    w, h = scale_short_side(w, h, to=768)   # then short side -> 768px
    tiles = ceil(w/tile) * ceil(h/tile)     # count the 512px tiles
    return 85 + 170 * tiles                # base + per-tile
image_tokens(1024, 1024)                  # -> ~765 tokens for one picture
# Claude and Gemini use different formulas, same idea: detail = tokens.
the takeaway: A vision-language model is usually three parts: a vision encoder that patchifies, a connector that aligns, and the same LLM you already know. Only the middle piece is new, and it is often the smallest thing in the whole system.
07 · audio

Sound becomes a picture first.

Raw audio is brutal to model directly: a single second is tens of thousands of samples, far too many to attend over. So almost every audio model does something sneaky. It converts the waveform into a spectrogram, a picture with time across the bottom and pitch up the side, and then treats that picture almost exactly like the image case.

This is what Whisper does: waveform to a log-mel spectrogram, then a convolutional stem and a transformer encoder that emit a sequence of vectors, one per short slice of time. From there it is the shared-space story again: those vectors can feed a decoder that writes text, or be projected into an LLM so it can "hear" your voice note.

Generating audio needs the reverse. A neural codec compresses sound into a stream of discrete audio tokens using residual vector quantization, the model predicts those tokens like any other sequence, and the codec's decoder turns them back into a waveform. Understanding uses the spectrogram door; generation uses the codec door.

a waveform becomes a picture of sound
waveform · ~16,000 samples/sec spectrogram · time × frequency
in essence · 30 seconds of speech, by the numbers
# whisper-large's front door, concretely
samples = 30 * 16_000            # 480,000 amplitude values
mel     = log_mel(samples)        # (80, 3000) · 80 pitches x 10 ms frames
h       = conv_stem(mel)          # (1500, 1280) · stride-2 conv halves time
vectors = encoder(h)              # 1,500 vectors · one per 20 ms of sound
# 480,000 samples in, 1,500 vectors out: a 320x squeeze.
# your voice costs ~50 vectors per second, the price of dense prose.
the sound's journey · tap a station or press play
01 / the waveform
A wall of samples.
Raw sound is amplitude measured tens of thousands of times a second. Too long to attend over directly.
08 · documents & PDFs

A PDF is not special. It's a photo.

This is the one that surprises people. A modern model usually does not parse a PDF's internal structure at all. There are two doors, and the interesting one is almost aggressively simple.

door one · read the text

OCR to tokens

how
OCR extracts the characters, and they enter as ordinary text tokens.
good at
Clean, text-heavy pages. Fast, cheap, reliable.
loses
A bar chart becomes a few stray numbers. A merged-cell table garbles. A diagram vanishes.
door two · look at the page

Render as an image

how
Rasterize each page to a picture at ~200 DPI, then run the exact image pipeline from section 3.
good at
Layout, tables, charts, stamps, handwriting, anything where position carries meaning.
costs
More tokens and more compute than plain text. Dense pages get expensive.

That second door is the punchline. To read your PDF, the model takes a screenshot of each page and patchifies it like any other image. It does not know it is a "document." It is looking at a picture that happens to be full of words and lines, and reading it with the same vision machinery it uses for a photo of a beach.

mid-2026 · the scoreboard

So who reads documents best right now? The surprise of the past year: the generalists won. On public OCR leaderboards in early 2026 the top of the table is not a document specialist at all. Gemini 3, Claude Opus 4.6 and GPT-5.2, ordinary frontier multimodal models walking through the render-and-look door, beat dedicated OCR pipelines on messy scans, receipts and handwriting, with roughly 3-4× fewer character errors on noisy pages.

The research edge runs the logic backwards. DeepSeek-OCR showed that a page-as-image can be the cheap option, not the expensive one: one vision token can carry roughly ten text tokens' worth of content at ~97% fidelity, so a dense page fits in a few hundred vision tokens where a raw text dump needs thousands. Its January 2026 successor reads a complex page in 256 to 1,120 vision tokens. The door we picked for faithfulness is turning into a compression scheme.

whowhat it iswhy it matters
Gemini 3 · Flash / Progeneralist frontier VLMtops the OCR Arena leaderboard, early 2026
Claude Opus 4.6 · GPT-5.2generalist frontier VLMsbeat dedicated OCR systems on real documents
DeepSeek-OCR-23B document specialist~10× optical compression; a page in a few hundred vision tokens
dots.ocr · Qwen3-VLsmall open modelsnear-free parsing, 100+ languages

The honest caveat: VLM readers run 5-10× slower than classic OCR engines. And what happens when they misread is the subject of the next block.

the accuracy question

If a page is just patch vectors, a fair worry follows. Patchifying is lossy compression, and a next-token engine never says "unreadable." Show it a smudged 7 and it will happily emit the most plausible digit instead, with full confidence. Nothing in the mechanism guarantees a number survives the trip. So where does the accuracy actually come from? Four places, none of them magic.

01 · spend enough tokens
Accuracy scales with pixels per glyph. Pages render at ~150-200 DPI and large pages get tiled, so detail costs tokens. DeepSeek-OCR measured the dial: ~97% decoding under 10× compression, falling to ~60% near 20×. Skimping shows up as misread digits.
02 · train on transcription
Models see millions of page-image and exact-text pairs in training, and get scored by character error rate on document benchmarks. Reading glyphs out of patches is a learned, measured skill, not a hope.
03 · open both doors at once
Production pipelines feed the rendered page and the extracted text layer together. Text tokens carry exact characters, patch vectors carry layout, and attention cross-references the two. This is how Claude's PDF mode ingests documents.
04 · re-read, then verify
The patch vectors stay in the context, so the model can attend back to the exact region when you ask about one cell. And when the stakes are real (invoices, contracts), pipelines cross-check against a classic OCR pass or demand page-anchored citations.
in essence · how a careful pipeline reads a PDF
# both doors at once, then verify (Claude-style ingestion)
for page in pdf:
    seq += vision_tokens(render(page, dpi=200))   # layout, charts, stamps
    seq += text_tokens(extract_text(page))        # the exact characters
answer = llm(seq + question)
# digits anchor to the text stream, positions to the pixels.
# high stakes? cross-check with classic OCR, or require a
# page + bounding-box citation before trusting a number.
the honest answer Accuracy is bought, not guaranteed. Enough tokens for the resolution, transcription baked into training, a text layer to anchor exact characters, and a second pass when a wrong digit costs money. The embedding gets you understanding; the checks get you trust.
the takeaway: There is no separate "PDF understanding." There is text (the OCR door) and there is vision (the render door). In 2026 the frontier increasingly picks the vision door, because a page's layout is information, and the only way to keep it is to look.
09 · fusion

Three ways to let a modality in.

Once you can turn an image or a sound into vectors, one question remains: how do those vectors actually meet the language model? The field has tried three answers, and they line up as a clear progression from bolting-on to building-in.

2022 · bolt it on

Cross-attention

idea
Keep the LLM frozen. Inject a few image vectors through added cross-attention layers.
bridge
A resampler squeezes an image to ~64 vectors.
seen in
Flamingo, early vision add-ons.
2023 · slot it in

Projection

idea
Project image vectors into the token space and concatenate them into the prompt, one flat sequence.
bridge
A small MLP connector. Hundreds of visual tokens.
seen in
LLaVA, most open VLMs.
2024+ · build it in

Native early-fusion

idea
No bridge. Every modality is a token from pretraining, in one shared vocabulary.
bridge
None. Trained on mixed streams from scratch.
seen in
Chameleon, GPT-4o, Gemini.
the arc Read those left to right and you see the whole history. We went from gluing a camera onto a frozen reader, to feeding it pictures alongside words, to raising one model that grew up seeing, hearing and reading at once. Each step trusts the shared space more.
10 · training

How the shared space is learned.

A shared vector space is not free. Something has to teach a dog photo and the word "dog" to land in the same place. Three techniques stack up, matching the three fusion styles.

Contrastive alignment is where it starts. Show the model a batch of image-caption pairs, and train it to pull each true pair together while pushing every mismatch apart. Do this across hundreds of millions of pairs and the two encoders converge on one geometry. That is CLIP, and it is the reason any of this works.

Connector tuning comes next. Freeze the vision encoder and the LLM, and train only the little bridge between them on image-and-caption data, then lightly instruction-tune. Cheap, fast, and enough to give a text model working eyes. Native pretraining is the heavy option: mix every modality into one token stream and train the whole model on next-token prediction over all of it, from the first step.

in essence · the loss that builds the shared space
# CLIP: pull matching image+text together, push mismatches apart.
img = image_encoder(images)               # N images   -> N vectors
txt = text_encoder(captions)              # N captions -> N vectors
scores = img @ txt.T                       # N x N grid of similarities
loss = cross_entropy(scores, diagonal)    # the diagonal is the true pairing
# minimize this and "a dog" lands exactly where a dog photo lands.

The detailed pipeline, pretraining then post-training, gets its own teardown in the LLM training explainer. The multimodal twist is only this: the data stream now carries pictures and sound, not just words.

11 · the other direction

Vectors back into the world.

Everything so far was input: senses into vectors. Output runs the arrow backwards, vectors into pixels or sound. There are two dominant ways to make an image, and they mirror the fusion debate.

the transformer's native trick

Autoregressive tokens

idea
Predict image tokens one by one, exactly like words, then a codebook decoder turns the grid of indices into pixels.
wins
One model, one loop, for text and images alike. Natural any-to-any.
seen in
Chameleon, GPT-4o image generation.
the image specialist's trick

Diffusion

idea
Start from noise and denoise toward the prompt over many steps, in a continuous latent space.
wins
Higher fidelity and detail, usually a separate specialist model.
seen in
Most standalone image and video generators.

Audio output is the same story with a different codec: predict discrete audio tokens, then let the neural codec's decoder rebuild the waveform. Put input and output together and you get an any-to-any model, one network that reads a screenshot, hears a question, and answers in speech or a fresh picture. Google's Gemini Omni, announced in May 2026, pushes this furthest: a single backbone taking any mix of text, image, audio and video and generating video out.

the symmetry Input and output are mirror images across the same room. An encoder maps the world into the shared space; a decoder maps a point back out. Understanding and generation are the same trip, run in opposite directions.
12 · why it works

Attention is blind to where a vector came from.

Step down one level and the reason all of this holds becomes almost inevitable. Look at what attention physically does: it takes a set of vectors and computes weighted averages of them, based only on how they point relative to each other. It never inspects an origin tag. A vector from the word "cat" and a vector from a 16×16 patch of fur are, to the attention math, indistinguishable kinds of thing. They are just points.

And meaning, in these models, is geometric. A vector means what its neighbors mean; the content is the position, not the label. So if your encoder does its job, if it lands "a dog barking" near the word "dog" and near a photo of a dog, then reasoning about the sound and reasoning about the sentence are literally the same computation. The transformer does not translate between modalities. There is nothing to translate once everyone is a point in one space.

That is why the modality gap is an encoding boundary, not a reasoning boundary. Adding a new sense to a model, touch, smell, a stream of sensor data, has never required a smarter transformer. It requires one thing: a good encoder that maps the new signal into the shared space. The intelligence is already modality-agnostic. It was waiting for the door.

the crux The hard, mysterious part of a multimodal model is not the "multi." It is the same next-token engine you already understood. The genuinely new work lives entirely at the border: the encoders that decide where each sense lands. Get the geometry right and reasoning comes for free.
13 · closing

Same engine, more senses.

A multimodal model is not a different species from the LLM you already understand. It is that exact model, handed a wider set of doors. The transformer still never sees a word, or a pixel, or a soundwave. It sees vectors, mixes them with attention, and predicts the next one.

Everything followed from one move: turn each modality into a sequence of vectors in one shared space. Patchify an image, picture a sound as a spectrogram, screenshot a page. Align them with contrastive training, bridge them with a small connector or grow them together from scratch. Run the arrow backwards through a decoder and the model speaks in pictures and sound too. Learn the border crossing, and the whole thing lines up behind it.

The interactive diagrams are schematic, built to carry the intuition rather than exact tensor shapes. Patch counts, token costs and codebook sizes are representative figures from the cited papers and provider docs, and vary by model and configuration.

built to learn, one vector at a time
← back to heqinghuang.com reasoning models llm training