AI RundownDaily
How Multimodal AI Actually Trains — Why Fusion Wins

How Multimodal AI Actually Trains — Why Fusion Wins

Multimodal model training works by converting text, images, and audio into a shared embedding space, then feeding those tokens into either a bolted-on adapter or a natively fused transformer trained end-to-end. The two approaches produce very different capabilities: adapters are cheap and fast to ship, but native fusion is what lets a model reason and generate across modalities in both directions. As of mid-2026, frontier labs are converging on native fusion as the default architecture, and the gap between the two approaches is becoming a competitive divide rather than a rounding error. For PMs, the question isn't which model to buy this quarter — it's whether your product's multimodal roadmap is built on an architecture pattern the industry is quietly abandoning.

Why it mattersFor product builders

Ask yourself this before your next roadmap review: is your product's multimodal feature actually multimodal, or is it a text model with a vision API stapled to the side? Most teams don't know the answer, because the demo looks identical either way — until a user asks for something that requires reasoning across modalities in both directions, like generating an image that matches a spoken description with the right physics, and the seams show up in production, not in the pitch. The concrete action for this week: pull the API docs or model card for whatever multimodal model sits underneath your core feature and find the sentence that describes how it was trained — natively and jointly from scratch, versus vision or audio added via adapter. Most vendors disclose this if you know to look for the word "native." If you can't find it, ask your vendor directly; a vendor who can't answer clearly is itself the answer. To be fair, if your use case is genuinely single-direction — read an image, describe it in text, done — an adapter-based model isn't a liability, it's a reasonable cost tradeoff. The risk is building a roadmap that assumes your current vendor's architecture will scale into cross-modal generation it was never designed for. Don't wait for a benchmark to tell you this. By the time it shows up on a leaderboard, your competitors will have already re-platformed.

Key Takeaway

Multimodal models align text, image, and audio encoders into one shared embedding space via contrastive training — the same technique OpenAI's CLIP used on roughly 400 million image-text pairs in 2021.

In May 2024, Meta's FAIR lab published a detail that quietly told you where multimodal AI was headed: Chameleon was pretrained from scratch, end-to-end, on roughly 10 trillion tokens of interleaved text and images in a single transformer. Compare that to the dominant shortcut of the era — take a finished text-only LLM, freeze most of its weights, and bolt on a vision adapter tuned on a few hundred thousand image-caption pairs. Same category, two completely different architectural bets.

The verdict, as of mid-2026: the bolted-on approach won the race to ship a demo. The fused approach is winning the roadmap that actually compounds. If your product's multimodal capability came from an adapter stapled onto a text model, you're not behind on features — you're behind on architecture, and that gap doesn't close with a fine-tune.

The trick is making every modality speak the same language

Before a model can reason across text, images, and audio, it has to convert all three into the same currency: numeric vectors that sit in one shared embedding space. Text gets tokenized the way it always has. Images get sliced into patches and run through a vision encoder (a Vision Transformer, typically) that turns pixels into patch tokens.

Audio gets converted into spectrogram or discrete codec tokens the same way. Each encoder is different; the target space they land in is not.

Getting there took a specific training trick: contrastive alignment, the technique OpenAI popularized at scale with CLIP in 2021, trained on roughly 400 million image-text pairs scraped from the web. The idea is simple to state and hard to execute — show the model a matched pair (a photo and its caption) and push their vectors together; show it a mismatched pair and push them apart. Do that across hundreds of millions of examples and you get an embedding space where "a photo of a golden retriever" and an actual photo of a golden retriever end up as neighbors, regardless of which encoder produced them.

That shared space is the whole trick. Without it, a model can process an image and process text, but it can't reason about how they relate — it's two separate competencies wearing the same UI.

Bolted-on adapters vs. built-in fusion — and why the gap is architectural, not cosmetic

Once modalities share a space, there are two very different ways to wire them into a language model, and the industry has been running both experiments in public for two years.

Late fusion (the adapter route). Freeze a pretrained text LLM. Train a lightweight vision encoder separately, then train a small projection layer that maps its outputs into the LLM's existing token space. This is how LLaVA-style models worked, and it's genuinely clever — you get a usable multimodal model for a tiny fraction of the compute of pretraining one from scratch, because the frozen backbone already did the hard work.

Early fusion (the native route). Tokenize every modality — text, image patches, audio, video — into one shared sequence from day one, then pretrain a single transformer on all of it jointly, with one autoregressive objective: predict the next token, whatever modality it belongs to. Chameleon did this. So did Meta's follow-on work, ANOLE, and a wave of "unified" models like Show-o that use one transformer for both understanding and generation.

Google has described its Gemini line as natively multimodal since its first release, rather than a text model with modalities added after the fact, and OpenAI made a similar architectural claim with GPT-4o in 2024 — a single model trained across text, vision, and audio rather than a text model wearing plug-ins.

To be fair to the adapter camp: for a huge class of products, late fusion is still the right call. If you need "read this screenshot and describe it" shipped next quarter, training a projection layer onto a frozen LLM is dramatically cheaper than a from-scratch multimodal pretrain, and it works well enough for understanding-only tasks.

Where it falls apart is generation and cross-modal reasoning that has to run in both directions — describing an image while reasoning about the physics inside it, or generating audio and video that stay in sync because they were never modeled as two separate tracks stitched together after the fact. That's the dubbing problem: an adapter model is like a foreign film dubbed after shooting, where the mouth movements never quite sync with the words because the two tracks were produced separately. A natively fused model shot the scene in one language from the start.

Where this goes over the next 12–24 months

A mid-2026 arXiv roadmap paper on native multimodal modeling frames this as a historical progression: early alignment-based fusion, then early-fusion "born-native" transformers, and now architectures where understanding and generation share weights symmetrically rather than generation being handed off to a separate diffusion sub-model. Expect that symmetry — one backbone doing both — to become the default frontier labs compete on, the way native mobile apps eventually replaced the hybrid web-wrapper apps that shipped faster in 2010 but couldn't match native performance once the platform matured.

My prediction, stated so it can be checked: by late 2027, any frontier lab still shipping a flagship model with vision or audio bolted on via adapter — rather than trained natively into the base model — will be visibly behind on cross-modal tasks (image generation with consistent physics, audio that stays synced to generated video) regardless of how strong their text benchmarks are. The adapter approach won't disappear; it'll settle into the "quick integration" tier, the way REST wrappers around legacy systems never went away even after native APIs matured.

For product teams, the harder question isn't which model is best today. It's this: if you've built your roadmap around one modality as the "primary" interface and others bolted on as features, are you betting on an architecture pattern the frontier is actively moving away from?

Get this in your inbox. AI Rundown Daily delivers original briefings every morning — free. Subscribe →

Was this take useful?

Get this in your inbox. AI Rundown Daily delivers original briefings every morning — free. Subscribe →

Frequently Asked Questions

Cost and speed. Pretraining a model natively across modalities from scratch requires trillions of tokens of interleaved data and a full pretraining run, while an adapter can be trained on a few hundred thousand image-text pairs on top of an already-finished LLM in a fraction of the time and compute. For understanding-only tasks — read an image, answer a question about it — that tradeoff is often perfectly reasonable. The gap only becomes a real liability when your product needs generation or reasoning that runs across modalities in both directions.

In most cases no — you're consuming a hosted model via API, so the architecture decision was already made by the vendor, and switching is a matter of evaluating a different model endpoint rather than retraining anything yourself. The real cost is evaluation time: you need to test your specific cross-modal use cases, not just read benchmarks, against both an adapter-based and a natively fused model before committing a roadmap quarter to either. Budget a focused one- to two-week bake-off rather than assuming marketing claims translate to your workload.

The timeline could be slower than this piece predicts — plenty of adapter-based products have shipped successfully for years and will keep working fine for understanding-heavy use cases. It's also possible the industry standardizes on a hybrid pattern rather than pure early fusion, since some recent "unified" architectures still route certain generation steps through specialized sub-modules for efficiency. Treat this as a directional bet worth tracking, not a hard deadline — recheck vendor architecture claims every couple of quarters rather than assuming today's snapshot holds.

AW
Aisha Williams

AI Futures & Strategy Editor

Big-picture, visionary, grounded in evidence

More articles by Aisha Williams
// Strategic Intelligence Dispatch

Get smarter on the frontier of AI.

Receive our original briefings, research deconstructions, and systems analysis. Delivered every morning, completely free.

* No spam. Unsubscribe anytime.

Related Articles

Handpicked by topic relevance
Mixture of Experts Explained: The Math That Makes AI Cheaper
llms

Mixture of Experts Explained: The Math That Makes AI Cheaper

Jul 21 · 5 min read
Tool-Use Training, Not Context Size, Makes Agents Work
ai tools

Tool-Use Training, Not Context Size, Makes Agents Work

Jul 21 · 5 min read
Open-Weight Isn't Open Source: Why the Label Is Broken
policy

Open-Weight Isn't Open Source: Why the Label Is Broken

Jul 21 · 5 min read

From the Learn Hub

Plain-language explainers on this topic
🤖 Models & Products

What is a multimodal LLM?

Learn Hub · intermediate
🤖 Models & Products

What is Gemini (Google's LLM)?

Learn Hub · beginner
📘 AI Fundamentals

What is RLHF (reinforcement learning from human feedback)?

Learn Hub · advanced

Continue Reading

All articles →
Mixture of Experts Explained: The Math That Makes AI Cheaper
llms

Mixture of Experts Explained: The Math That Makes AI Cheaper

5 min read
Tool-Use Training, Not Context Size, Makes Agents Work
ai-tools

Tool-Use Training, Not Context Size, Makes Agents Work

5 min read
Open-Weight Isn't Open Source: Why the Label Is Broken
policy

Open-Weight Isn't Open Source: Why the Label Is Broken

5 min read