AI Engineer Europe 2026
Scaling the Next Paradigm of Heterogeneous Intelligence
Read the talk
Scaling Intelligence Across Models, Workflows, and Chips
Different steps in an AI workflow need different capabilities. Heterogeneous orchestration matches those steps to models and hardware, changing the cost and latency of the whole system.
From a talk by Adrian Bertagnoli
Before you start: Familiarity with LLM context windows, inference, and basic Python will help with the recursive-context example.
From one model on identical chips to coordinated specialists
Why solve every part of a complex problem by scaling one model on a fleet of identical chips? That is the opening question behind Adrian Bertagnoli’s account of heterogeneous intelligence. Introducing himself as a founding engineer at Callosum, he starts with the prevailing alternative: homogeneous scaling, where more training data and more parameters produce a more capable model. Neural scaling laws made that approach productive; his question is what changes when the engineering emphasis moves from training models to running inference.
The shift is already visible at three layers:
| Layer | Homogeneous starting point | Emerging heterogeneity |
|---|---|---|
| Architecture | Large dense model | Mixture of experts |
| Workflow | Single LLM call | Multiple interacting agents |
| Hardware | One chip role | Separate prefill and decode roles |
These changes introduce specialization inside the model, between calls, and underneath inference. They do not yet require an entirely heterogeneous cluster.
At this mild stage, agents can use different prompts or different LLMs while still running on largely homogeneous infrastructure. Greater heterogeneity assigns different models to different GPUs, then combines architectures such as state-space models and diffusion models on hardware suited to their computation. The proposed endpoint goes further than choosing from existing chips: models, software systems, and hardware co-evolve into a vertically integrated system.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Match collective capabilities to the problem’s demand
Real-world problems are multistep and open-ended. Their subproblems require different capabilities, so increasing one kind of intelligence can be an inefficient way to solve the whole task. Bertagnoli calls the alternative multi-agent heterogeneous intelligence: models of different sizes and architectures cooperating over long horizons. There is an infrastructure problem alongside the modeling problem. New silicon needs an interface through which it can contribute to the existing compute stack; simply making another accelerator available does not establish how agents should use it.
The principle of maximum heterogeneity formalizes this intuition through a distributed production model. In the diagram Bertagnoli describes, each agent has a distribution over a skill space, represented by its color. A ring connects the agents, representing communication. Together, their skills and interactions produce a collective production function: a profile of what the system can supply. That profile can fit one problem’s demand, labeled demand A, while serving demand B poorly.
Homogeneous scaling has two limitations in this picture. Replicating a specialist raises one peak without filling other gaps in capability. Replicating broad generalists spreads capacity across the skill space, producing the short cylinder in the illustration rather than enough capacity where demand is highest. Bertagnoli presents mathematical support and parallels across neuroscience, economics, and ecology. The corresponding distributed-production paper bounds the result by modeled skill distributions, communication, resource constraints, and environmental demand. The useful design principle is therefore to match diversity to the workload and its communication topology—not to maximize the number of different components indiscriminately.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Three places to optimize
This becomes an orchestration problem across three connected decisions:
- Hardware: Select where an agent runs according to its computational demands.
- Agents: Select the models and capabilities that perform the work.
- Workflows: Determine how agents interact and how their work is composed.
Bertagnoli develops two examples: heterogeneous recursion at the workflow layer, followed by a mixture of multimodal models for visual web navigation at the agent layer. In both, the opportunity comes from decomposing a task before deciding which resources should execute it.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Treat long context as an environment
A large context window does not guarantee that a model can reason reliably over everything in it. Recursive language models address that distinction. Bertagnoli refers to an MIT introduction from the previous October: the October 2025 author write-up preceded the paper submitted in December 2025. The motivating issue is context rot: performance can deteriorate even when the input occupies only part of the available window, depending on how much information the answer requires.
The distinction is easiest to see through two tasks:
| Task | Information needed as input grows |
|---|---|
| Find one needle in a haystack | O(1): retrieve a fixed amount |
| Add values across supplied rows | O(N): inspect a growing number of rows |
A longer haystack does not necessarily require a longer answer or more facts to construct it. Aggregation does require more of the input to participate in the result. Bertagnoli says constant-demand retrieval can remain effective across the full context window, while linear or quadratic demands can degrade at roughly 30–60% occupancy. He does not assign separate thresholds to the two complexity classes or specify a universal cutoff.
The recursive approach changes how the agent accesses the input:
- Keep the long context outside the model’s immediate prompt, in an environment the agent can inspect.
- Let a coding agent use a Python REPL to search it with keywords, regular expressions, or other programmatic operations.
- Extract relevant subcontexts and pass them to recursive calls.
- Let each call answer its question or delegate again.
Bertagnoli describes a file-backed context and identical recursive agents. The original RLM design also supports context held in an environment variable and calls to other models; neither files nor identical child models are requirements. The central mechanism is programmatic access to context, followed by bounded reasoning over selected portions.
For example, a support log can stay in a file while Python extracts complete records mentioning refunds. The resulting strings are the subcontexts a recursive call would receive:
python
from pathlib import Path
import re
context = Path("support-log.txt").read_text(encoding="utf-8")
records = re.split(r"\n\s*\n", context.strip())
refund_records = [
record
for record in records
if re.search(r"\brefund(?:s|ed)?\b", record, re.IGNORECASE)
]
batch_size = 20
subcontexts = [
"\n\n".join(refund_records[start:start + batch_size])
for start in range(0, len(refund_records), batch_size)
]
for index, subcontext in enumerate(subcontexts):
print(f"--- Subcontext {index} ---")
print(subcontext)
This illustrates the extraction step, leaving the recursive calls pending. The filter must match the question: a keyword search can select explicit refund mentions, but it would miss relevant records expressed with different vocabulary.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Route recursive work across models and chips
Once a workflow exposes smaller subcontexts, orchestration can choose how to process each one. Callosum’s extension maps generated subcontexts to different models and different chips, aiming to preserve the quality of frontier-model reasoning while reducing cost and latency. The distinguishing step is the joint selection of model and hardware, rather than recursion alone.
Bertagnoli presents results on OOLONG, the long-context reasoning and aggregation benchmark also used in the RLM work. He names GPT-5 and then GPT-5.2 as the contemporary baseline. For that baseline, Bertagnoli reports about 2,000 seconds to run through the benchmark and about $3.75 for one task. Those spoken units differ, so they should not be combined into a derived per-task throughput estimate.
The reported hardware choices produce different cost–latency tradeoffs:
| Configuration | Reported cost reduction | Reported speedup |
|---|---|---|
| Cerebras | 7× cheaper | 5× faster |
| SambaNova | 12× cheaper | 3× faster |
Both rows compare with the baseline described in the talk. SambaNova reduces the price further than Cerebras while giving up some latency advantage. These are Callosum-reported OOLONG results; the exact evaluation split, timing aggregation, and accuracy comparison are not specified in the presentation. The architectural point is that model-and-chip assignment creates choices along both cost and time axes.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Build infrastructure around heterogeneous workloads
Bertagnoli places these examples in a three-era history of compute. The CPU era made computation faster. The GPU era made it massively parallel, with NVIDIA dominating that transition. His proposed third era maps multi-agent workloads onto different chips according to what each step needs. Scaling then depends not just on the capacity of a device, but on how effectively the system assigns work across devices.
He connects that direction to Callosum’s work with ARIA, reporting a rounded 3 million grant toward what he calls the UK’s first heterogeneous co-located cluster. Callosum’s funding announcement describes funding for cluster research and development with CommonAI, rather than establishing that a commissioned cluster was already operating. The infrastructure ambition is to bring different hardware into one coordinated system.
Homogeneous scaling still receives credit for the progress that made these systems possible. The closing proposal is to let models, workflows, and silicon co-evolve, so that new forms of specialization can improve the system’s intelligence, speed, and cost together. Bertagnoli ends the prepared talk with an infrastructure builder’s expression of optimism: “This is the worst our infrastructure will ever be.”
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
How does the system choose a model?
The audience’s final technical question returns to the zoom example: is the assignment hard-coded, or does another model decide which model should do the work? Bertagnoli says the first implementation used bespoke mappings from simple subtasks to simple models. Callosum subsequently added an automation layer that detects task complexity and predicts the best-suited model and hardware. He does not describe the predictor’s implementation or validation. This leaves the routing decision itself as a central part of the system: decomposition exposes the choices, and the orchestrator must turn them into assignments that preserve quality while reducing execution cost.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
A distributed production model connecting agent specialization, communication, resource constraints and workload demand.
The research paper describing recursive inference over context held outside the model’s immediate prompt.
A benchmark testing whether models can analyze many text fragments and aggregate their findings.
Further reading
Callosum’s technical account of heterogeneous recursion and visual web navigation, with model configurations and cost–latency comparisons.
The authors’ October 2025 introduction to inspecting context programmatically and delegating subqueries through a REPL.
Callosum’s announcement of hardware partnerships and ARIA-funded research on co-located heterogeneous computing.
- ARIA Scaling Inference LabArticle
ARIA’s description of the lab, participating organizations and heterogeneous inference research goals.
Read the complete timestamped transcript
- 0:00
[upbeat music] Thank you for coming to my talk.
- 0:16
My name is Adrian Bertagnoli. I'm a founding engineer at Callosum, and today I'm gonna be talking about scaling the next paradigm of heterogeneous intelligence. So I'm gonna start, um, with explaining why we care about heterogeneity in the first place, what particular aspect make it very conducive for scaling AI, um, how it is actually used in practice today,
- 0:40
and how we can use-- utilize it in the future, um, to actually scale the next paradigm of intelligence. So to give you an intuition about what I mean with heterogeneous intelligence, I wanna take a step back and, um, explain the current prevailing paradigm of homogeneous, uh, intelligence.
- 1:00
So homogeneous intelligence in, in terms of AI mainly refers to scaling single models on a fleet of identical chips. So this was largely-- This era was largely brought about by the discovery of neural scaling laws, which showed us that more data and more parameters leads to better models.
- 1:19
However, this is primarily rooted in a training domain, and while we move towards an inference domain, this becomes less and less relevant. So it's already changing, um, and we already see some level of heterogeneity in-- um, going into our current systems.
- 1:39
So on the architecture level, we see that mixture of experts are replacing large dense models. On the workflow layer, we see that single LLM calls are being replaced by mi-- uh, multi-agent systems.
- 1:53
And finally, on the hardware level, single chips are being replaced by prefill decode disaggregated systems. So given that we are currently at the state of mild heterogeneity, how can you imagine, um, a, a greater level of heterogeneity?
- 2:11
How will that appear? So initially, will be what we currently are experiencing is mild heterogeneity. So everything is still running primarily on, on homogeneous clusters, but we have some variety in the prompts.
- 2:27
When we run, uh, multi-agent systems, we might use different LLMs for different sub-agents. Um, again, we have mixture of experts.
- 2:36
Uh, when we increase the heterogeneity, we might start to use different chips, um, for different models. So different LLMs might be put on different GPUs. Uh, they might be interacting.
- 2:50
We might be using different models completely. So we have a increase of state-space models, diffusion models, all interacting with each other, all on optimal hardware that exists currently. And the last stage, uh, where we really see the, the heterogeneous paradigm unfolding is when we have a co-evolution of systems, uh, hardware and software.
- 3:14
So th-there will be a unification where you'll have, um, a complete vertical integration of intelligence and hardware.
- 3:24
So why heterogeneity? Why is it a good thing in the first place? So real-world problems are complex, multi-step, and open-ended. They decompose into sub problems which require vastly different types of intelligences.
- 3:40
So scaling a singular type of intelligence to solve these is very inefficient and, and not optimal. So how do we solve them? Solving these actually requires models of different architectures and sizes working together, um, uh, acting together in long horizons, something we like to call multi-agent heterogeneous intelligence.
- 4:05
Furthermore, new generations of silicon is coming towards the market, but currently there's no interface which allows it to, um, this new hardware to be unified and, and constructively, um, help the current compute stack.
- 4:20
And so this is what we aim to change. So heterogene-heterogeneity, the benefit is not simply a belief that we have. We actually formalize it and proved it mathematically. Um, on the right-- on the left, you see a figure outlining, uh, the principle of maximum heterogeneity.
- 4:42
So these are heterogeneous agents where the color indicates, um, a distribution over a skill space. Um, if you take-- If you have a communication between these, here indicated by a ring topology, you can have a s-- what we like to call a production function.
- 5:01
And the production function is simply the demand, uh, can, can be well suited for the demand of one problem, but ill-suited for another problem. So here we have a, a production function that's well-suited for demand A and ill-suited for demand B.
- 5:18
If you want to do this in a homogeneous fashion, you would either be able to only scale one peak, or in the optimal case, to match this demand function, you would have only generalists, so as broad as possible, the skill set.
- 5:31
But then ultimately you'd have a very short cylinder that does not meet the production function readily. So we formalize this, and we, um, saw that across many domains, including neuroscience, economics, and ecology, these, these trends hold, and under any reasonable amount of constraints, heterogeneous systems outperform homogeneous ones.
- 5:56
So how do we use this in practice? Like, I've been telling you about the benefits of heterogeneity, but I've not told you anything about what it actually means in terms of AI.
- 6:07
So we optimize, um, multi-agent systems at three different parts of the workflow. So all the way from the hardware where agents run on, we choose different hardware depending on the computational demands on the agents, and then how agents interact and what workflow they construct.
- 6:27
Um, so we have already demonstrated multiple, uh, benefits of, of, uh, this type of orchestration, and I wanna go into a couple ones. Um, main- namely in the workflow, something, a primitive we like to call heterogeneous recursion, and in the agent layer, I wanna talk about multi-model, multi-modal video action language models.
- 6:52
So heterogeneous recursion. This is something, um... Who's here heard of recursive language models?
- 7:01
Okay. So for those of you who, um, know- don't know recursive language model, it's kind of a seminal paper that came out of MIT, uh, last October, and they basically showed that even if you only occupy a small, uh, percentage of the context window, you still can have dramatic context rot depending on the information complexity you want,
- 7:23
uh, from the prompt. So if you're doing a needle in a haystack task, that is O of one. The, the information requirement scales is constant throughout, regardless of how big the prompt is.
- 7:36
And then you can imagine adding up the rows. You, you, you give, uh, rows and columns. Adding up the rows would be O of N because as the prompt increases, the infor- informational requirement increases linearly.
- 7:49
So if the, if you have a constant information requirement, it scales well. You, you can occupy the full context window and actually get a, a good answer. However, when you go to linear or quadratic, uh, it degrades at around 60 to 30%.
- 8:04
So recursive language models solve this problem by actually treating the context as a, um, environment rather than putting it all into the prompt. So in practice, this looks like you present the context in a file, and then the, a coding agent interacts with it programmatically through Python REPL, um, basically doing keyword searches, regex, a- and other
- 8:29
tricks to extract subcontexts, and this subcontext is then passed off to an identical recursive agent. So this agent then can answer the question or spawn another recursive agent. And, and that's why it's called recursive, uh, language model.
- 8:44
So we simply extended this concept. Um, instead of using a single model on a single chip, we map based on the subcontext generated towards different chips and different models to emulate the performance while drastically, um, being cheaper and faster.
- 9:06
So here are results. Um, you can see this is on the OOLONG benchmark. This is basically, um, the benchmark they used in the paper. Um, and GPT-5, GPT-5.2 was the, um, most recent one when we produced this work.
- 9:21
Uh, it sits around here where it takes around two thousand seconds, um, to run through the, the benchmark, and it costs around, uh, $3.75 for one task. Our system, when we go on Cerebras, we s- are seven times cheaper and five times faster.
- 9:41
So you save incredibly much time or a lot cheaper, so it's basically like having your cake and eating it too. Um, with SamaNova, we even get, uh, further. We push the price down even further at the cost of some latency.
- 9:57
So we're 12 times cheaper and three times faster. So these are like making architectural decisions that are not like simply based on the hardware. You can make huge impactful, um, price differences and, and, and while m- emulating the intelligence you would have from frontier models.
- 10:20
So the next problem we wanted to address is basically, um, visual web navigation. So we used a mixture of open and closed, uh, video action language models, um, and we managed to beat, uh, the state-of-the-art of Video Web Arena, beating GPT-5.2 and Gemini, uh, 2.5 by 18% and 25% respectively.
- 10:45
And not only this, the way we did it is instead of treating the problem as a homogenous one, we, we acknowledge that the problem is heterogeneous, uh, i- itself.
- 10:59
It, it decomposes into multiple steps of visual reasoning, of, of textual reasoning, and each of these subcomponents requires different models to be, um, completed successfully. So here you see a fundamental shift of the Pareto frontier where you see singular models like Kimi K, uh, 2.5 and GPT-5.2
- 11:23
are outperformed by a mixture, a heterogeneous set of, of models. So when we use Qwen3-VL-8B-Instruct and Kimi K2.5, we're 1.3 times faster than using Kimi, Kimi alone.
- 11:39
We're 18 times cheaper than using, uh, GPT-5.2 alone. Um, and if we use, uh, Qwen3, um, plus GPT, we're actually three times faster and 3.7 times cheaper. So this is only benefit.
- 11:54
There's no downside, uh, in, in constructing this in a heterogeneous manner. So one part of, of our differentiating factor, why, how we were able to beat the state-of-the-art is- That we mapped certain subtasks like zooming and, and creating a different visual, um, reasoning for the agent.
- 12:14
We offloaded that into less intelligent models because you don't need GPT to zoom for you. So alone on these subtasks, we're able to be 11 times faster and 43 times cheaper than using ChatGPT.
- 12:29
And so this is what overal- overall accumulates towards these 3.7 times cheaper and three times faster.
- 12:38
So looking ahead, how do we s- view the future of compute? The first era of scaling compute was dominated by the CPU, where compute got quicker. The second era was making compute massively parallel.
- 12:54
This is dominated by NVIDIA. And the third paradigm,
- 12:59
compute is gonna become heterogeneous, mapping onto multi-agentic workloads and optimally, um, mapping these workloads onto different chips. We are actually, um, working with ARIA, the UK institute.
- 13:16
Um, we got a 3 million grant for the first-- for operating the first heterogeneous co-located cluster in the UK. So we really wanna make a difference and, and spearhead this new era of innovation.
- 13:31
So the era of h- homogeneous scale delivered extraordinary progress. We should be grateful for it. What comes next is heterogeneous intelligence, where models, workflows, and silicon co-evolve, and every new source of diversity makes the whole system smarter, faster and cheaper.
- 13:48
This is the worst our infrastructure will ever be. Thank you. [audience applauding]
- 14:01
How do you define which task to run on the, like, faster, uh, cheaper model? Like for instance, a zoom, is that something that's hard coded like, "Oh, if you have to zoom in this model," or do you have like a smarter model that decides the
- 14:15
So it is, um... Initially, we started doing bespoke decisions on mapping, uh, certain simple subtasks to simple models. But since then, we have, um, created an automation layer that detects the task complexity and automatically predicts the best model-- the best-suited model and hardware.
- 14:41
Any other questions? Great. Thank you so much for your attention. My name is Adrian Bertagnoli, and if anyone is interested, uh, we are hiring, so
- 14:55
yeah. Great. Thank you very much. [upbeat music]