Intern-S2: A Scientific Agentic Foundation Model

Chapter 1: The Body — What 397B Is Made Of

Before any training story, you need to know what is being trained. This chapter walks the tensor path from four different kinds of input into one hidden space, and then out again as either text or numbers. Where the paper publishes a shape, we use it. Where it does not, we say so out loud rather than inventing one — a system report is allowed to omit its hidden size, and we are not allowed to fill it in.

What the paper tells you about the backbone, and how

The report never gives you a table of layer counts. But it leaks the architecture in the places where architecture forces an engineering decision, and those leaks are reliable. Three of them:

Four input types, one hidden space

A multimodal model is, mechanically, a set of projections — small learned maps that take whatever an encoder produced and re-express it as something shaped like a token embedding, so the language backbone can attend over all of it at once. Intern-S2-Preview has four such lanes.

Lane 4 is the genuinely new limb. Everything before it in the literature turns "predict the next 200 values" into "emit two hundred numerals as text," and Chapter 9 will show you exactly what that costs.

The time-series encoder, derived

Start with the problem, because the design is a direct answer to it. Scientific time series, in the paper's list, "exhibit substantial variations in sequence length, sampling frequency, and channel dependency." Concretely, one encoder has to survive all of these:

Now the pipeline, stage by stage, as §2.2.1 lays it out.

Stage 1 — temporal chunking. The input series is "partitioned into temporal chunks, enabling localized processing of long sequences." This is the same reason you tile a huge image: attention is quadratic, and 300,000 positions of quadratic attention is not a thing you do.

Stage 2 — compressive patching. Each chunk goes through three sub-steps, in order:

Worked example 1: where the 300,000 steps go

The paper says the encoder maintains "a controllable output sequence length for heterogeneous long time series" by "dynamically adjusting the temporal patching process according to input length." Let us make that arithmetic concrete. The specific patch length and query count below are illustrative — the paper does not publish them — but the relationship between them is exactly what the sentence describes.

Let L be the patch length in raw samples and Q the number of Q-Former queries per patch. For an input of T steps:

Take the paper's stated maximum, T = 300,000, and suppose you have budgeted 1,024 tokens of the LLM's context for this signal. Solve for L with Q = 4:

Now feed the same encoder a short radar burst, T = 4,096 samples. If L stayed fixed at 1,172 you would get ⌈4096/1172⌉ = 4 patches, so 16 tokens — a four-thousand-sample signal squeezed into sixteen vectors, which is why S1-Pro could not do high-frequency short signals well. Adapt L instead: with the same 1,024-token budget, L = 4 · 4,096 / 1,024 = 16 samples per patch. Sixteen samples per patch on a megahertz signal is 16 µs of detail per token. That is what "dynamically adjusting the temporal patching process according to input length" buys, and it is why the same module now covers both astronomy and radar.

Stage 3 — the channel-wise Transformer. This is the change from the previous generation, and it is worth dwelling on because the paper states the old behaviour explicitly: Intern-S1-Pro "directly aggregated multi-channel representations through mean pooling." S2 replaces that with "a channel-wise Transformer encoder to model inter-channel dependencies before being fed into the Transformer encoder body."

Worked example 2: what mean pooling destroys

Mean pooling across channels is a linear operator, and linear operators cannot see relationships. Here is the smallest example that shows it. Take three EEG channels at one time patch, with a feature that is positive when the channel leads and negative when it lags:

Three physically distinct states, one identical pooled vector. The propagation direction — often the entire clinical finding — lives in the ordering across channels, and mean pooling is invariant to ordering by construction. A Transformer over the channel axis is not: its attention computes pairwise interactions, so it can represent "channel 1 is high while channel 3 is low" as a distinct pattern from its mirror image.

What the upgrade bought, in the paper's own numbers

Put those together and the practical statement is: a job that used to take a certain wall-clock time on a certain card now runs in roughly one fifth to one sixth of that time using roughly one fifth of the memory, on a 25% longer signal. If you had a single 80 GB accelerator and the old encoder saturated it at 240,000 steps, the new one has room for the 300,000-step maximum and a great deal of headroom besides. That headroom is the entire reason the radar case became possible: high-frequency signals mean more patches per second of real time.

The forecasting branch, and why it is not text

Here is the design, from §2.2.2. Two streams condition one generator:

Two engineering decisions here deserve the "why," because both are load-bearing.

Why a Q-Former between the two streams and the forecaster? Because they have different lengths and different natures. The LLM context is however many tokens the prompt was; the encoder output is however many patch tokens the signal produced. Cross-attending a forecaster directly into both would make the conditioning cost grow with prompt length, and would give an instruction like "forecast the next 200 steps" the same weight as two hundred tokens of unrelated preamble. The Q-Former's fixed query set is a bottleneck by design: a constant, learned number of slots that both streams must compete to write into.

Why a separate horizon predictor rather than just generating until a stop token? Because a numerical branch has no stop token. A text decoder can emit an end-of-sequence symbol; a branch that emits real numbers has to be told how many to emit. The instruction says it in English ("forecast the next two seconds," "predict 96 steps ahead"), so a small module reads the instruction and converts it to an integer. The paper reports that module gets it right 99% of the time — and Chapter 9 will show you that this unglamorous component is responsible for one of the paper's largest margins, because the competing general-purpose models fail on precisely this step.

The forecaster, written out

forecasting branch# Lane 4. Values out, not numerals. Called after the LLM has reasoned in text.

def forecast(llm_hidden, series_tokens, stats, instruction_hidden):
    mu, sigma = stats                                # kept by the encoder's normalisation step

    # how many values does the instruction ask for? A numerical head has no EOS.
    horizon = horizon_predictor(instruction_hidden)  # int, reported 99% accurate

    # two conditioning streams, each squeezed to a fixed number of slots
    sem = qformer_sem(llm_hidden)                    # (B, Q, D) what was asked / what the text said
    num = qformer_num(series_tokens)                # (B, Q, D) what the signal actually did
    cond = cat([sem, num], dim=1)                  # (B, 2Q, D) constant cost, whatever the prompt

    y = []
    state = start_token()
    for t in range(horizon):                        # causal Transformer forecaster
        h     = forecaster_block(state, cross_attend=cond)
        val   = value_head(h)                        # a REAL number, not a token id
        y.append(val)
        state = advance(state, val)

    return stack(y) * sigma + mu                     # de-normalise: the stats come back here

Three lines are worth naming. horizon = horizon_predictor(...) is the module with no analogue in a text decoder, and Chapter 9 will show it is responsible for every 100 in Table 5's success-rate column. cond = cat([sem, num]) is why the conditioning cost does not grow with prompt length. And * sigma + mu is why the normalisation step in Lane 3 was careful to retain the statistics rather than discard them — without them, the branch can emit shapes but not values.

Why the visual encoder is frozen and the LLM is not

Lane 2's most consequential line is a parameter-freezing decision, stated once in §3.1 and easy to miss: "The visual encoder remains frozen, while the LLM backbone, visual projection, and prediction head are optimized." Work out what that arrangement forces.

Three consequences follow, and all three are load-bearing.

First, the targets stay still. The contrastive objective of Equations (7)–(8) predicts the encoder's own features. If the encoder were trainable, the target would move every step, and the cheapest way to reduce the loss would be for the encoder to collapse all patches onto one easily-predicted vector. Freezing removes that degenerate solution entirely — you cannot game a target you cannot change.

Second, the document knowledge lands in the backbone. This is the point of the whole stage. If the vision tower were doing the learning, you would end up with a better page encoder and an unchanged language model. Because only the language side moves, "the model's ability to continue a visual sequence" is written into the same weights that will later be asked to reason about the paper's contents.

Third, it is cheap. No gradients through the vision tower means no activations to keep for it, and the encoder can be run once and cached. For a stage the paper describes as "a lightweight stage for modality expansion," that is the difference between running it over your whole PDF corpus and running it over a sample.

Walking one real prompt through all four lanes

Concept plus realisation means following actual data. Take the opening scene's question, posed to the model as a single multimodal turn, and account for every token.

Now the output side. The model reasons in text — that is Lane 1 again — and when it reaches the forecast, control passes to Lane 4: the horizon predictor reads "the next two seconds," converts it to an integer using the sampling rate, and the causal forecaster emits that many real values, cross-attending to both the LLM's semantic state and the encoder's numerical representations, with μ and σ from the normalisation step available to put the values back on the original scale.

The encoder forward pass, written out

Concept without realisation is decoration, so here is the whole Lane 3 path as code, with a shape comment on every line. Names follow §2.2.1; the constants marked illustrative are ones the paper does not publish.

time-series encoder# x: (B, C, T) - batch, channels, time steps. T can be up to 300,000.

def encode_series(x, token_budget=1024, Q=4):        # Q = queries per patch (illustrative)
    B, C, T = x.shape

    # --- normalisation: keep the statistics, do not discard them ---
    mu    = x.mean(dim=-1, keepdim=True)          # (B, C, 1)
    sigma = x.std(dim=-1, keepdim=True)           # (B, C, 1)  <- retained as auxiliary stats
    xn    = (x - mu) / (sigma + 1e-6)               # (B, C, T)

    # --- temporal chunking: localised processing of a long sequence ---
    chunks = split_into_chunks(xn)                   # list of (B, C, T_chunk)

    # --- compressive patching, per chunk ---
    L = ceil(Q * T / token_budget)                  # patch length ADAPTS to input length
    toks = []
    for ch in chunks:
        h = cnn_local(ch)                            # (B, C, T_chunk, D) local morphology
        p = to_patches(h, L)                         # (B, C, n_patch, L, D)
        t = qformer(p, n_query=Q)                    # (B, C, n_patch, Q, D) fixed count per patch
        toks.append(t)
    z = cat(toks, dim=2)                          # (B, C, N_tok, D) with N_tok ~ token_budget/Q

    # --- NEW in S2: model the channel axis instead of averaging it away ---
    z = channel_transformer(z)                     # (B, C, N_tok, D) inter-channel dependencies
    z = merge_channels(z)                          # (B, N_tok, D)   <- S1-Pro used mean() here

    # --- global temporal context ---
    z = transformer_body(z)                        # (B, N_tok, D)
    return to_llm_space(z), (mu, sigma)           # (B, N_tok, D_llm) + the stats the forecaster needs

Two lines are the whole chapter. L = ceil(Q * T / token_budget) is the length-control valve from Worked Example 1 — the patch grows with the input so the token count does not. And channel_transformer replacing a mean() is the single architectural change that Worked Example 2 justified.

Worked example 3: what "20% of the memory" actually means

Efficiency multipliers are abstract until you attach a machine to them. Suppose the old encoder, at its 240,000-step maximum, occupied 40 GB of a single 80 GB accelerator and took 6.0 seconds per forward pass. The paper reports the new encoder runs "approximately 5 ∼ 6× faster" while "reducing GPU memory consumption to around 20% of the previous version," at a maximum length that is itself 25% longer.

The last row is the one that changes what you can build. Two concurrent signals is a demo; ten is a batch. And the memory saving is what makes the radar case viable at all: a megahertz signal produces far more patches per second of real time, so the module has to be cheap per patch before high sampling rates are affordable.

What 256K tokens of context is for

The maximum sequence length turns up three times in the paper, in three different roles, and it is worth seeing them together because they are the same budget spent on different things.

And a sense of scale for the middle row. If an average agent turn — one assistant message plus one tool observation — runs about 1,200 tokens, then 262,144 tokens is roughly 218 turns of interaction before the window is full. That number is the practical meaning of "long task horizon," and it is also, from Chapter 7's annotator list, why "context-, turn-, or session-limit termination" is a behaviour worth penalising: running out of room is a failure mode with a specific budget attached.

What the report publishes, and what it withholds

A useful habit when reading a system report is to write down the gaps explicitly, because they bound what you can conclude and what you could reproduce.

The pattern is consistent: mechanisms and headline scalars are published; the constants that would let you reproduce the run are not. That is normal for a frontier system report and it is worth stating plainly rather than reading past. Everything in this lesson that is a specific number is from the left column. Everything illustrative is labelled.

Chapter 2: Memory Decoder — Specialising Without Rewriting

Here is a situation every team with a good general model eventually hits. The model is strong. A collaborator needs it to be strong at one specific thing it has never seen — non-coding RNA family classification, say, or a lab's internal assay protocol. The obvious move is to fine-tune. And the obvious move is a trap, for a reason the paper states plainly:

Notice this is not the usual hand-waving about catastrophic forgetting. It is sharper: the parameters that encode "how to plan a tool sequence" are the same tensors as the parameters that encode "what a promoter–enhancer interaction is." There is no biology submatrix you can update in isolation. Gradient descent on 40,000 RNA examples touches everything.

And the reason this matters more in science than elsewhere: "the long-tailed and continuously evolving nature of scientific expertise." There is no fixed set of domains. Every month there is a new assay, a new instrument, a new subfield. If specialising costs you a full fine-tune of a 397-billion-parameter model plus a regression suite across every general benchmark, you will do it approximately never.

The reframe: attachment instead of rewriting

Memory Decoder's answer is to stop editing the model at all. Instead:

That last equation is Equation (3) of the paper, and it is worth staring at:

Three properties fall out immediately, and each one is a design win.

Prove the first property, since everything rests on it

"A convex combination of two distributions is a distribution" is the load-bearing claim of Equation (3), and it takes three lines to prove, so prove it.

Non-negativity. For any token v, p_final(v) = (1 − λ)p_S2(v) + λp_mem(v). Both probabilities are ≥ 0, and both coefficients are ≥ 0 whenever λ ∈ [0,1]. A sum of non-negative terms is non-negative. ✓

Normalisation. Sum over the vocabulary and pull the constants out:

Exactly 1, for every λ, with no renormalisation step. ✓ Verify it on the worked table: at λ = 0.3 the fused column is 0.420 + 0.305 + 0.190 + 0.085 = 1.000, and at λ = 0.7 it is 0.580 + 0.245 + 0.110 + 0.065 = 1.000.

Where the memory's knowledge comes from: retrieval, compressed

The memory is not just a small model fine-tuned on the domain. It is trained to imitate a retrieval system. Follow the construction.

Step 1 — build a token-level datastore. Given a domain instruction-tuning corpus D_sft = {(q⁽ⁱ⁾, a⁽ⁱ⁾)}, walk every position on the answer side. At position t of example i, the prefix is c_t⁽ⁱ⁾ = [q⁽ⁱ⁾ ; y_<t⁽ⁱ⁾]. Encode that prefix into a key k_t, and store the pair (key, next token). You now have a lookup table whose entries are "in this exact context, this exact token followed."

Step 2 — define a retrieval distribution. For a new prefix, find the nearest keys and let them vote, weighted by distance. That is Equation (1):

Unpack every symbol. N(k_t) is the retrieved neighbour set. d is the retrieval distance. τ is a temperature. The indicator 1[y = v_j] means a neighbour only votes for the token it actually stored. And exp(−d/τ) means a neighbour whose context was nearly identical votes loudly, while a distant one barely whispers.

Worked example 4: the retrieval vote, by hand

Suppose τ = 1 and the five nearest neighbours to the current prefix are:

Group by token. "enhancer" collects 0.8187 + 0.6065 + 0.1003 = 1.5255. "promoter" collects 0.4966. "silencer" collects 0.2019. The total is 1.5255 + 0.4966 + 0.2019 = 2.2240. Normalise:

Check: 0.6860 + 0.2233 + 0.0908 = 1.0001, which is rounding. Note what this distribution encodes that a one-hot label would not: "enhancer" is the answer, but "promoter" is the reasonable confusion and "silencer" is the far one. That relative structure is precisely the extra signal the memory is being taught.

Step 3 — compress the retrieval into parameters. Running a nearest-neighbour search over a token-level datastore at every decoding step is expensive and stateful. So the memory is trained to predict what the retrieval would have said, with a two-term loss — Equation (2):

β ∈ [0,1] "balances the retrieval teacher and the gold SFT answer." Both terms are needed, and you can see why by imagining each alone. Pure KL: the memory learns to imitate a retriever, including the retriever's mistakes, and can never exceed it. Pure cross-entropy: you are back to ordinary fine-tuning on hard labels and you have thrown away the ranking structure. The mixture says match the neighbourhood's shape, but stay anchored to the truth.

The router: a learned, per-token trust dial

Now the question that decides whether any of this works: how much should we trust the memory at this particular token?

The router is "lightweight" and "token-level," and it decides λ_t from "their hidden states and output-distribution uncertainty features." That last phrase is the interesting one. The router does not only look at what each model wants to say; it looks at how confident each one is. A backbone that is spreading its mass over forty plausible tokens and a memory that is putting 0.9 on one of them is a strong signal to raise λ. The reverse — a confident backbone and a flat memory — is a strong signal to lower it.

The router is trained with the backbone and the memory both frozen. Its loss, Equation (4), is cross-entropy on the fused distribution plus a signed linear regulariser on λ itself:

The regulariser is a straight line in λ, and its slope s_t is a signed indicator keyed to which corpus the training example came from — the router is trained "on a mixture of domain and general instruction data," with α_s > 0 controlling the strength. Since the objective is minimised, a negative slope on domain examples pulls λ_t up, and a positive slope on general examples pushes it down.

Worked example 5: fusing two distributions, and reading the router

Shrink the vocabulary to four tokens so the arithmetic is visible. A biology prompt is mid-answer, and the two models disagree:

At λ = 0.3 the argmax is still "enhancer" (0.420) but only just; at λ = 0.7 it is decisive (0.580). And here is the crossover worth computing by hand: the backbone prefers "promoter" (0.35 > 0.30) while the memory prefers "enhancer" (0.70 > 0.20). At what λ does the fused argmax flip?

Barely any memory weight is needed to overturn this particular decision — 9.1% — because the backbone was nearly indifferent between its top two while the memory was not. That is the mechanism by which a 4-billion-parameter module can move a 397-billion-parameter model's output: it does not need to overpower the backbone, only to break its ties in the right direction.

What it actually bought: the 21-task table, recomputed

The paper instantiates one memory — Intern-MemDec-4B, on biology — and evaluates on all 21 tasks of Biology-Instructions. This is the cleanest result in the paper because you can verify the headline number yourself from the row data. Here it is, with the deltas computed:

Worked example 6: verify the averages yourself

Add the "frozen 397B" column. Running the sum in the table's order: 63.11, then 83.06, 136.74, 221.14, 277.71, 334.67, 374.91, 397.37, 482.11, 545.16, 615.64, 677.52, 746.12, 815.79, 874.23, 880.84, 963.49, 1019.69, 1079.33, 1158.13, and finally 1195.26. Divide by 21:

Now the "with MemDec" column: 72.57, 99.82, 160.53, 249.65, 305.64, 372.73, 409.17, 447.64, 534.98, 595.61, 667.84, 727.94, 795.94, 863.74, 917.71, 934.89, 1019.70, 1079.41, 1139.89, 1225.59, 1266.82. Divide by 21:

And the gain, computed two ways as a check. As a difference of averages: 60.3248 − 56.9171 = 3.4076. As an average of differences: the deltas sum to 1266.82 − 1195.26 = 71.56, and 71.56 / 21 = 3.4076. Identical, as they must be — the mean is linear.

Look at which tasks lost, because the pattern is not random. Four of the seven regressions are protein property-prediction tasks — solubility, stability, thermostability, enzyme function. And look at the biggest wins: promoter–enhancer interaction (+16.01), DNA transcription-factor binding in mouse (+10.13), CRISPR on-target activity (+10.57), non-coding RNA family (+6.90). Those are nucleotide-sequence tasks.

A single memory trained on one domain corpus has a centre of mass. Where the memory's training data was dense, λ is doing useful work; where it was thin, the router is still occasionally routing to a module that has nothing better to say than the backbone did, and the fusion dilutes a good prediction with a mediocre one. The honest reading of §5.3 is: the memory attachment is a real gain in aggregate, it is domain-shaped rather than uniform, and the failure mode is bounded and visible.

The cross-domain check — and what it does and does not show

The obvious worry about any specialisation method is that it quietly wrecks everything else. The paper checks: it evaluates the memory-augmented variant on MMLU Pro, Mol-Instructions, MMMU Pro, MicroVQA, IMO-Answer-Bench, and SFE, with Intern-S1-Pro (1T) as an extra reference, and reports that "Intern-MemDec-4B remains close to the frozen backbone on general knowledge, reasoning, scientific, and multimodal benchmarks while improving the target biology benchmark."

Two things about that sentence. First, it is exactly the claim the architecture predicts: at λ ≈ 0 the fused model is the backbone, so the router only has to learn to keep λ small off-domain. Second, "remains close" is reported as a radar plot (Figure 12c), not as a table of numbers — so we can tell you the claim and the mechanism, and we cannot give you the per-benchmark deltas, because the paper does not print them. Note the asymmetry in evidence quality: the biology gain is a 21-row table you can audit, the no-regression claim is a shape.

When you should not reach for this

Every mechanism has a domain of applicability, and the 21-task table tells you where this one's edges are. Read the seven regressions as a specification.

The whole mechanism, in twenty lines

memory decoder inference# backbone and memory are BOTH frozen. Only the router was ever trained here.

def step(prefix):
    h_s2,  p_s2  = backbone(prefix)      # (D_s2,), (V,)  frozen 397B
    h_mem, p_mem = memory(prefix)        # (D_mem,), (V,) frozen 4B, domain-trained

    # the router sees hidden states AND uncertainty, not just the argmaxes
    feats = cat([h_s2, h_mem,
                  entropy(p_s2), entropy(p_mem),      # how confident is each one?
                  max(p_s2),     max(p_mem)])
    lam = sigmoid(router(feats))            # scalar in (0, 1), fresh EVERY token

    return (1 - lam) * p_s2 + lam * p_mem     # (V,) still sums to 1 - Equation (3)


# router training: both models frozen, mixed domain + general data
def router_loss(prefix, gold, is_domain):
    p_final = step(prefix)
    ce  = -log(p_final[gold])                # fused likelihood supplies the curvature
    s_t = -1.0 if is_domain else +1.0       # signed, keyed to the corpus
    return ce + alpha_s * (s_t * lam)         # Equation (4): constant-gradient prior

Read the last line once more. s_t * lam is linear in λ, so its derivative is the constant s_t. On domain data that constant is negative, so minimising the total pushes λ up; on general data it is positive, so minimising pushes λ down. The cross-entropy term is the only thing that can overrule it, and it will, whenever a high λ would make the fused prediction worse. The whole router is one scalar, one sigmoid, and a prior with a sign.

Where this sits among the four ways to specialise a model

Memory Decoder is one option in a well-populated field. Lining them up makes the trade explicit — and makes clear that there is no free lunch, only different bills.

Where the retrieval idea comes from, and what changed

Equation (1) will look familiar if you have seen kNN-LM: build a datastore of (context representation, next token) pairs from a corpus, and at inference interpolate the language model's distribution with a distance-weighted vote from the nearest neighbours. That method works and it has a well-known cost — you carry the datastore forever, and every decoding step pays a nearest-neighbour search over it.

The row that matters most is the fourth. A retriever is a lookup and cannot answer for a context it never saw; a model trained on the retriever's outputs has been forced to find structure in those outputs, and structure extrapolates. That is the same reason a student who learned the pattern beats a student who memorised the answer key, and it is the actual argument for Equation (2)'s existence.

Chapter 3: Teaching a Model to Read a Page

Open a chemistry paper and look at what carries the information. A reaction scheme. A table of yields with the interesting row bolded. An equation set inline between two paragraphs that reference it as "(3)". A caption that says "see inset." Now run that page through a text extractor and read what comes out: the equation is a run of mangled symbols, the table is a comma soup, the figure is gone entirely, and the two paragraphs that referred to each other by position are now adjacent to something else.

Text extraction is lossy in a very specific way: it deletes exactly the structure that made the document a document. This chapter is about the paper's three answers to that, all in §3. They are independent engines and they attack different losses.

Visual Pre-training: predict the next patch of the page

The idea is disarmingly simple once stated. You already have a huge corpus of scientific PDFs. You are already training on the text you extracted from them. Render the same documents as page images and train on those too, with an objective that needs no labels at all.

Here is the pipeline, with shapes, following Equations (5) through (9).

Step 1 — encode the page. A frozen visual encoder E_v turns the page image I into a sequence of visual features:

Step 2 — drop the blank paper. A foreground mask m_i "removes blank regions," and the survivors are put in raster-scan order — left to right, top to bottom, exactly how a person reads:

This step is pure economy and it matters more than it looks. A journal page is mostly margin. If a quarter of your patches are white paper, a quarter of your compute is spent predicting that blank follows blank — a task with essentially zero loss and therefore zero gradient. Masking them out concentrates the budget on ink.

Step 3 — run it through the LLM autoregressively. The visual features are projected into the language model's hidden space by W_in, run through the backbone Φ_θ, and a lightweight head ψ predicts the next visual latent:

Read that as: take all patches up to t, project, run the LLM, take the hidden state at position t, and map it to a prediction of what patch t+1 looks like. It is next-token prediction with patches instead of tokens.

Step 4 — and here is the actual insight: score it contrastively, not with a regression.

Unpack it. s_tj is the cosine similarity between the prediction at position t and the true patch at position j+1, divided by a temperature τ. The softmax runs over the batch B. And L_VP is the negative log of the diagonal — the probability that the prediction for position t matched the true continuation of position t, and not somebody else's.

Step 5 — interleave with text. Both objectives run together during continued pre-training:

And the parameter split is the crux: "The visual encoder remains frozen, while the LLM backbone, visual projection, and prediction head are optimized." The encoder is a fixed measuring instrument. What is being trained is the language model's ability to continue a visual sequence — which means the document structure is being written into the backbone, not into a separate vision tower.

Interleaved text–image data: rebuilding the page as a sequence

The second engine attacks a different loss. §3.2 opens by naming what is wrong with the standard recipe: "Existing multimodal pre-training strategies heavily rely on image caption data, which captures semantic alignment between an image and a local text span." That is fine for object recognition. But in a PDF, "the more critical information … often lies in the contextual relationships between images, equations, tables, and surrounding text, including layout position, explanatory paragraphs before and after visual elements, textual references, cross-page reasoning chains, and the progressive organization of knowledge in long documents."

The goal, in the paper's phrase, is that the model learn "not only what an image depicts, but also how it is embedded in document narratives." The pipeline:

Step 4 is the clever one and it deserves its own derivation.

Visual gain: a filter that measures whether a picture is worth anything

Treating equations and tables as images rather than as parsed text is a deliberate bet, and it is not free: an image costs far more tokens than the LaTeX would. So you had better be sure the visual content is carrying information. The paper measures it, borrowing the trick from Toolformer: compute the language model's perplexity on the page text twice — once with no visual input, once with the images, tables, and equations included — and define

"A significant decrease in PPL after adding visual information indicates that the visual content provides meaningful support for understanding the page." Decorative images, advertisements, and weakly related visuals score near zero. Experimental figures, mechanism diagrams, structural illustrations, tables, and equations produce "a notable PPL reduction." The paper then combines "human review with domain-specific thresholds and retain only pages whose visual gain exceeds the corresponding threshold."

Worked example 7: turn a perplexity drop into bits

Perplexity differences are hard to feel. Convert them. Perplexity is the exponential of the average per-token cross-entropy in nats, so PPL = e^H and therefore H = ln(PPL).

Take a page from a mechanism-diagram-heavy chemistry paper: text-only PPL 12.4, interleaved PPL 9.1. Then:

Now scale it. A dense page might be 700 text tokens, so the figure supplied 700 × 0.4464 ≈ 312 bits — about 39 bytes — of information that was genuinely not recoverable from the text alone. That is not much in absolute terms, but it is the right unit to reason in, because now you can compare it against the cost: if the cropped figure costs 256 image tokens to include, you are paying 256 tokens for 312 bits. Whether that is a good trade is a threshold, which is exactly why the paper says the thresholds are domain-specific.

Contrast with a decorative stock photo on a press-release page: text-only PPL 11.0, interleaved PPL 10.9. Then ΔH = ln(11.0) − ln(10.9) = 2.3979 − 2.3888 = 0.0091 nats = 0.0131 bits per token, or about 9 bits for the whole page. Nine bits, for hundreds of image tokens. Discard.

Why 256k chunks with a 512-token overlap

Two numbers, both worth a sentence. The 256k cap matches the maximum sequence length the rest of the system is built for, so a pre-training sample and a distillation trajectory live in the same regime — no separate long-context machinery.

The 512-token overlap is a seam repair. Cut a document at a hard boundary and every fact whose evidence straddles the cut becomes unlearnable: the model sees the conclusion without the premise in one chunk, and the premise without the conclusion in the other. Overlapping by 512 tokens means any dependency shorter than 512 tokens is intact in at least one chunk. The cost is duplication: at a 512/256,000 overlap ratio you are re-training on 0.2% of tokens twice, which is nothing.

Image retrieval: going to look for the rare good pictures

The third engine is the least glamorous and the most operational. The observation in §3.3: retrieval of high-quality data "is a common practice in preparing textual pre-training corpus. However, the pipeline of retrieving high-quality image data is underexplored." The goal is to "recall high-quality data and raise their sample ratio during the training."

Visual Pre-training as code

visual pre-training# One training step on a batch of rendered pages. No labels anywhere.

def vp_step(page_images):                       # (B, 3, Hpx, Wpx)
    with no_grad():                              # the visual encoder stays FROZEN
        z = visual_encoder(page_images)           # (B, N, Dv) N patches per page

    m = foreground_mask(z)                       # (B, N) bool - drop blank paper
    u = raster_scan(z[m])                        # (B, L, Dv) with L <= N   -- Eq (5)

    hid  = backbone(W_in @ u)                     # (B, L, D_llm) autoregressive, causal
    pred = head(hid)                              # (B, L, Dv) predicted NEXT latent -- Eq (6)

    # contrastive scoring: identify the true continuation among in-batch targets
    a = l2norm(pred[:, :-1])                     # (M, Dv)  predictions  u_hat_{t+1}
    b = l2norm(u[:, 1:])                        # (M, Dv)  targets      u_{t+1}
    s = (a @ b.T) / tau                           # (M, M) cosine / temperature -- Eq (7)
    loss_vp = cross_entropy(s, arange(M))       # the DIAGONAL is the label -- Eq (8)

    return lam_text * loss_text + lam_vis * loss_vp   # Eq (9)

The label is arange(M). Nobody wrote it down; it is the index of each prediction's own continuation, and every other position in the batch serves as a negative. That is where "requires neither OCR and layout parsing nor paired data and manual annotations" comes from, concretely.

Worked example 8: what the foreground mask saves

The mask looks like housekeeping. Put numbers on it. Take a single-column journal page rendered at a patch grid of 48 × 36, so N = 1,728 patches. Typical margins on such a page — top, bottom, left, right, plus inter-column and inter-paragraph white space — run around 35% of the area. Then:

A causal Transformer over a sequence pays roughly quadratically in length for attention, so the attention work scales as (1,123 / 1,728)² = 0.4224 — about 42% of what the full grid would have cost. And the discarded 605 patches were the ones with essentially no loss to reduce, since predicting "blank follows blank" is free. You removed 35% of the tokens and 58% of the attention cost while losing none of the gradient signal.

Why equations and tables are cropped as images

§3.2 names exactly three kinds of visual unit to crop: "regular images, interline equations, and tables." The first is obvious. The other two are a deliberate and slightly surprising choice, because both could have been serialised as text — LaTeX for the equation, markdown for the table.

And this connects straight back to Visual Pre-training: the reason cropping equations as images is affordable is that the backbone has already been trained, in §3.1, to model rendered mathematical layout as a visual sequence. The two engines are not independent; the second one spends a budget the first one created.

Worked example 9: the chunking overhead

Filtered pages are concatenated in document order and split "into chunks suitable for long-context VLM pre-training, with each chunk capped at 256k tokens and sharing a 512-token overlap." What does the overlap cost?

Each chunk after the first repeats 512 tokens of its predecessor. With a stride of 256,000 − 512 = 255,488 new tokens per chunk, a document of D tokens needs about D / 255,488 chunks, and the duplicated fraction is:

Two tokens in a thousand, seen twice. For a corpus of 1 trillion tokens that is 2 billion duplicated tokens — real, and utterly worth it against the alternative. Consider a cross-reference like "as we showed in Section 2, the yield was 84%" landing 200 tokens after a hard chunk boundary. Without overlap, the model sees the claim with no evidence in one chunk and the evidence with no claim in the other, and the dependency is unlearnable from either. With a 512-token overlap, every dependency shorter than 512 tokens survives intact in at least one chunk.

What the parser has to get right first

Everything in §3.2 rests on one upstream component: MinerU2.5-Pro, which "perform[s] OCR and layout-aware structural parsing on PDF documents" and "identifies text blocks, headings, paragraphs, and visually informative regions on each page." If that step is wrong, the interleaved sequence is wrong, and the model learns a false page.

What visual gain cannot see

Visual gain is a good filter and it is worth understanding its blind spots, because the paper hedges it with "we combine human review with domain-specific thresholds" and that hedge is doing real work.

Why life sciences, chemistry, and materials science

The interleaved pipeline "focuses on life sciences, chemistry, and materials science." That is a scoping decision, and it lines up exactly with where the evaluation is strongest — which is either a coincidence or the point.

Those five rows include the two largest margins in the entire paper. Biology-Instructions at 4.1× the best competitor and MP20 at 4.1× are exactly the two domains whose page structure this pipeline was built to preserve. That is not proof of causation — the SFT mixture and the RL tasks also targeted these domains — but the alignment between what §3.2 chose to parse and where §5.2 reports its largest wins is worth noticing.

Worked example 10: the scale of the image index

§3.3 gives enough numbers to size the system. "Hundreds of millions" of images, each encoded to a 1024-dimensional vector. Take 300 million as the working figure.

Raw vector storage, at 4 bytes per dimension:

At half precision, 614 GB. Either way it does not fit on one machine's memory, which is precisely the paper's stated reason for "constructing multiple collections based on the Milvus vector database and storing image vectors in shards to support subsequent high-performance retrieval."

Brute-force search cost per query. A single cosine similarity over 1024 dimensions is about 1024 multiply-adds. Against 300 million vectors:

At a very generous 10¹¹ effective operations per second on a CPU that is roughly 3 seconds per query — per query, single-threaded, with the whole index in memory. Which is why nobody does brute force, and why the pipeline is retrieve-then-rerank: an approximate index narrows 300 million to a few hundred in milliseconds, and then "a reranker model to rerank candidate results and assign quality scores" pays the expensive per-item cost on only those few hundred.

The three engines, by cost profile

A practical question when borrowing any of this: what does each engine cost, and when do you pay it?

Notice the asymmetry. The first engine is nearly free and has no operational tail. The second costs two forward passes per page at build time and leaves behind a threshold you now own. The third is the only one that leaves a system running: an index at hundreds-of-millions scale is a service with uptime, storage, and re-indexing concerns long after the training run finished.

How the three engines feed each other

It is worth being explicit that these are not three parallel improvements. They form a chain.

And all three exist to serve one number that will not appear until Chapter 9: SimpleQA-Verified 69.90, fifteen points clear of the next open model, measured without retrieval tools. Factual recall without tools is a pre-training result. It is the cleanest available evidence that this section of the paper did something real.

What the retrieval pipeline costs, and why it is worth it once

One more piece of arithmetic on §3.3. Encoding "hundreds of millions" of images with an 8-billion-parameter embedding model is not a small job. But note where the cost sits: it is paid once per image, ever. After that, every query — every text-to-image and image-to-image lookup, forever — costs one query encoding plus an approximate search. The expensive model is on the write path, not the read path.

Which is exactly the opposite of the caption-model decision in the same section. For an image query, the system "uses a caption model to generate a textual description of the image, and the caption text is then encoded into a vector," so it can search from "both visual and semantic perspectives." That caption is generated at query time — on the read path — and it is worth it because the two views recall genuinely different neighbours: the image embedding finds things that look alike, and the caption embedding finds things that are about the same thing. A fluorescence micrograph and a schematic of the same pathway look nothing alike and are semantic neighbours.

Chapter 4: Rollout Economics — Not Idling the Cluster

Reinforcement learning on a language model has a rhythm: generate, score, update. Generate a batch of responses to a batch of prompts, run a verifier over them to get rewards, take a gradient step, repeat. In a small setup you barely notice the generate phase. At this scale it is the whole story — "rollout generation is the primary computational bottleneck in reinforcement learning."

And it is a bottleneck with a nasty shape. Not slow-on-average: slow-in-the-tail.

The straggler problem, made concrete

You launch 8,192 rollouts. Most finish in a few thousand tokens. But this is a long-chain-of-thought reasoning model with a maximum generation length of 65,536 tokens, and a handful of prompts will send it most of the way there. In a synchronous pipeline you cannot start training until the batch is complete, so:

Put numbers on it. Suppose 99% of your rollouts finish by 4,000 tokens and 1% run to 65,536. The batch is not done until the slowest one is done, so the wall-clock cost of the batch is set by 65,536 tokens of autoregressive decoding, while the average rollout needed roughly 4,600. The ratio 65,536 / 4,600 ≈ 14 means that for about thirteen-fourteenths of the batch's duration, the overwhelming majority of your accelerators have nothing to do. On a cluster that costs real money per hour, this is the difference between a training run and a heating bill.

The two standard escapes, and the one the paper picked

§4.3.1 names the field's two answers before choosing:

Intern-S2-Preview takes the first: "a co-located partial-rollout system based on the XTuner training engine and the LMDeploy inference engine." Here is the loop, exactly as described:

Nothing computed is thrown away. That is the whole argument for pause-over-abort: a rollout 40,000 tokens deep represents 40,000 forward passes, and discarding it burns all of them.

The bill: your trajectory now has multiple authors

Step 4 hides a real problem, and the paper states it without flinching: "because a resumed trajectory may contain segments generated before and after one or more policy updates, different tokens within the same trajectory can originate from different behavior-policy versions."

Think about what that means for the gradient. Policy gradient methods assume the data you are learning from was sampled from the policy you are updating. Here, token 12,000 of a trajectory came from π_v3 and token 45,000 came from π_v5, and you are updating π_v6. Every one of those tokens is off-policy — drawn from a distribution that is not the one you are differentiating.

The classical repair is importance sampling: reweight each sample by how much more or less likely it is under the policy you care about than under the one that produced it. The paper records, for every sampled token, both the behaviour-policy version and the generation-time log-probability, and then writes Equation (10):

Note the subscript beh(i,t): the behaviour policy is indexed by both the trajectory and the position within it. Different tokens of the same response can have different denominators. That is unusual, and it is a direct consequence of pause-and-resume.

The system also bounds how stale a trajectory may get: "a trajectory is discarded if its oldest retained segment was generated more than three policy updates before the current learner." Three. That is a hard cap on how far the ratio can drift, enforced by deletion rather than by a correction term.

Clipping the weight, not the objective — and why that is different from PPO

Importance ratios have a well-known pathology: they are unbounded above and their variance can explode. So the ratio is truncated, Equation (11):

And then a sentence that is easy to skim past and is the most important thing in the section:

Sit with the difference, because it is a genuinely different algorithm and the distinction is often muddled.

Concretely: if ρ = 8.0 and the clip bound is 1.2, PPO (for a positive advantage) contributes nothing at all from that token. Here, the token contributes with weight 1.2 — capped, but present. Given that pause-and-resume manufactures off-policy tokens by design, an update rule that deletes them would throw away exactly the data the system went to such trouble to preserve.

The other inconsistency: two engines, one model, different answers

There is a second, sneakier source of mismatch, and it has nothing to do with time. The rollouts are generated by LMDeploy and the gradients are computed by XTuner. Same weights, two different implementations. They do not agree exactly.

For a sparse MoE model there are two reasons, and the paper separates them cleanly.

Reason 1 — routing. An MoE router picks a small set of experts per token via a top-k over router logits. A discrete argmax has no tolerance: a difference of 10⁻⁶ in a logit can flip which expert runs, and then the two engines have computed different functions, not merely different roundings. The fix is Rollout Routing Replay (R3): "the expert selections made by LMDeploy during rollout are recorded and replayed by XTuner when evaluating the corresponding tokens. This ensures that rollout and training follow the same expert paths."

Reason 2 — arithmetic. Even on the same path, numerics differ. The mitigation is the precision map from Chapter 1: FP8 for expert linear layers, BF16 elsewhere, FP32 for apply_rope, RMSNorm, the MoE router, Gated DeltaNet recurrent states, and the language-model head.

What is left over. "After routing replay and operator-level alignment, a small number of tokens may still exhibit large probability discrepancies because of residual numerical differences." So a third mechanism, borrowed from KPop: detect and drop the survivors using the bidirectional binary KL divergence, Equations (12) and (13):

Read Equation (12) as: collapse the whole vocabulary to a two-outcome question — "was it this token, or was it anything else?" — and measure the KL between the two engines' answers to that question. p^train and p^rollout are the probabilities the two engines assign to the token that was actually sampled, "under matched model parameters and replayed routing decisions." A token survives only if both directions are under the threshold φ.

Worked example 11: binary KL by hand, and why both directions

Case A — ordinary disagreement. p^train = 0.90, p^rollout = 0.80.

Reverse it:

Different numbers — 0.0367 versus 0.0444 — from the same pair, which is the first thing to internalise: KL is not symmetric. Both are small; at any sane φ this token survives.

Case B — a real outlier. p^train = 0.05, p^rollout = 0.60. The rollout engine thought this token was the obvious choice; the training engine thinks it was nearly a mistake.

Nineteen to thirty-one times larger than Case A in the two directions. This token is masked out.

And notice how the three mechanisms stack, because they are not redundant:

Making generation itself faster: speculative decoding that chases the policy

Partial rollout fixes idling. It does not make a token come out faster. For that the paper adds speculative decoding — and then hits a problem specific to RL.

The standard method: a small, cheap draft model proposes several tokens ahead; the expensive policy model verifies all of them in one parallel forward pass, using an exact rejection-sampling procedure. Because the verification is exact, "this verification procedure preserves the sampling distribution of the policy model" — so, crucially, "speculative decoding accelerates rollout generation without introducing additional off-policy bias." You are not approximating the policy. You are sampling from it, faster.

The answer is to train the draft online: at each RL iteration, update the draft using the current policy's token distributions on the rollout states just collected, "while gradients are stopped through the policy model." The draft chases; the policy never feels it.

Deriving the acceptance rate, and the loss that targets it

Let p be the target policy's distribution at a draft position and q the draft's, both computed at the rollout sampling temperature. Two divergences matter:

And now the identity that ties the second one directly to speed, Equation (21):

Under lossless speculative sampling, the probability that a drafted token is accepted equals the overlap of the two distributions — the area both agree on. Minimising total-variation distance is therefore literally maximising the acceptance rate. Not a proxy for it. The same number.

Worked example 12: acceptance and the overlap identity

Vocabulary of three, target p = (0.60, 0.30, 0.10), draft q = (0.50, 0.20, 0.30).

Overlap: min(0.60, 0.50) + min(0.30, 0.20) + min(0.10, 0.30) = 0.50 + 0.20 + 0.10 = 0.80.

Total variation: ½( |0.60−0.50| + |0.30−0.20| + |0.10−0.30| ) = ½(0.10 + 0.10 + 0.20) = ½(0.40) = 0.20.

And 1 − 0.20 = 0.80. The identity holds. Four out of five drafted tokens are accepted here.

The classical speculative-sampling result (Chen et al. and Leviathan et al., 2023, both cited by the paper) says that with acceptance rate a and K drafted positions, the expected number of tokens produced per verification round is (1 − a^K+1)/(1 − a). The paper uses K = 4. So:

That table is standard theory, not the paper's measurement — include it to build intuition, not to attribute. What the paper reports is the end result: speculative decoding "ultimately delivers an approximately 2× speedup in rollout generation and a 1.7× end-to-end speedup for the overall RL training pipeline."

The hybrid draft loss: two objectives, adaptively mixed

So why not just minimise D_TV, since that is the acceptance rate? Because absolute value has a constant-magnitude subgradient — it points the right way but tells you nothing about how far off you are, which makes it a poor optimisation target when the draft starts far from the policy. Forward KL has the opposite character: smooth, well-scaled gradients, but it is optimising a proxy.

The paper uses the hybrid LK loss, Equation (22), and mixes the two with a coefficient that depends on how well things are going, Equation (23):

ᾱ_k is the current acceptance rate at draft position k, aggregated over sequence and batch. Compute the schedule:

The paper's summary of the schedule matches the arithmetic exactly: when alignment is poor, "the objective is therefore dominated by the forward KL term, which provides smooth and well-scaled gradients for rapidly aligning the draft distribution with the evolving policy"; as acceptance rises, "the objective gradually shifts from stable distribution matching to direct acceptance-rate optimization."

The full objective averages over K draft positions, Equation (24):

with K = 4 and η = 3. Note λ_k is per-position: the first drafted token is easy to get right and the fourth is not, so position 1 will be deep in TV mode while position 4 is still doing KL. One schedule per lookahead depth, automatically.

The rollout loop, written out

co-located partial rollout# One RL iteration on a shared GPU pool. XTuner trains, LMDeploy generates.

def iteration(prompts, batch_target=8192, max_stale=3):
    launch(prompts)                                # keep the engine saturated: as one
    done = []                                       # finishes, another request takes its slot
    while len(done) < batch_target:
        traj = next_completed()
        done.append(traj)
        launch_one(next_prompt())

    # PAUSE, do not abort: prefixes + metadata are retained
    paused = pause_in_flight()                     # each keeps tokens, logprobs, policy version

    # the SAME GPUs now train
    for mb in split(done, n=8):                    # 8 mini-batch update steps
        policy_update(mb)                          # each step makes the REST more off-policy
    version += 1

    offload_training_state()
    sync_weights_to_inference()

    # resume, dropping anything that has drifted too far
    for t in paused:
        if version - t.oldest_segment_version > max_stale:
            discard(t)                              # hard staleness bound = 3 updates
        else:
            resume_from_prefix(t)


# the correction that pause-and-resume makes necessary
def token_weight(tok):
    rho = exp(logp_now(tok) - tok.logp_at_generation)   # Eq (10), per-token behaviour version
    rho = clip(rho, 1 - eps_low, 1 + eps_high)          # Eq (11)
    return detach(rho)                                  # NOT part of the graph - this is the
                                                        # difference from PPO surrogate clipping

The line worth pausing on is for mb in split(done, n=8). Eight mini-batch updates per rollout batch means that even the completed trajectories are off-policy for seven of the eight steps — they were generated by the policy as it stood before step one. Partial rollout is not the only source of staleness; it is the source that makes staleness per-token rather than per-batch.

Worked example 13: how stale is "three updates"?

Translate the staleness bound into tokens. Suppose a batch closes when 70% of rollouts have completed, and the median completed rollout ran 4,000 tokens. Then a paused trajectory resumes having been paused once, and can be paused at most three times before it is dropped. Three pause cycles is roughly three more batch windows, so a surviving long rollout can accumulate on the order of four windows' worth of generation — call it 16,000 tokens — split across four policy versions.

Now count gradient steps. Each window is 8 mini-batch updates, so a token generated in the first window and used in the fourth is being evaluated by a policy that is 3 × 8 = 24 gradient steps away from the one that produced it. At a learning rate of 1 × 10⁻⁶ that is a small drift, which is precisely why 3 is a defensible bound and 30 would not be:

The three failure modes, and which mechanism owns each

It is easy to lose track of what is fixing what, because Chapter 4 stacks four corrections. Sort them by the question each one answers:

The first three are about agreement between two implementations. The fourth is about agreement between two moments in time. Conflating them is the easiest mistake to make while reading §4.3.1, and the paper is careful to keep them apart: R3 "removes discrete expert-routing mismatch, whereas the BKL mask filters the remaining token-level numerical outliers," and the clipped weight "corrects the policy mismatch introduced by pause-and-resume partial rollouts and repeated mini-batch updates."

Chapter 5: Shaping the Advantage

By the end of Chapter 4 we have tokens, log-probabilities, and a repaired importance weight. What we do not yet have is the number that says how good was this response. That number — the advantage — is what multiplies the log-probability in the gradient, and this chapter is about the three transforms the paper applies to it, in order, and why each one exists.

Here is the pipeline. Everything downstream of the verifier:

Step 1: the leave-one-out baseline, derived from scratch

Why does a policy gradient need a baseline at all? Because raw rewards have an arbitrary origin. If every response to a query scores 1.0, multiplying every log-probability by +1.0 pushes all of them up — a large, uninformative update that says nothing about which response was better. What you want is the relative quality within the group.

The paper follows Intern-S1-Pro in using the leave-one-out form, Equation (27):

The baseline for response i is the mean of the others, excluding i itself. That exclusion is not fussiness — if i were included in its own baseline, the baseline would be correlated with the thing it is subtracted from, which biases the estimator. Leaving one out makes the baseline independent of the sample it corrects.

Worked example 14: LOO advantages for a group of eight

G = 8 rollouts on one maths query, verifier gives 1 for correct and 0 for incorrect. Six correct, two wrong: R = (1, 1, 1, 0, 1, 0, 1, 1), so ∑R = 6.

For a correct response (R_i = 1), the others sum to 6 − 1 = 5, so the baseline is 5/7 = 0.714286 and

For an incorrect response (R_i = 0), the others sum to 6 − 0 = 6, so the baseline is 6/7 = 0.857143 and

Check the group sums to zero, as a correct baseline must: 6(+0.285714) + 2(−0.857143) = 1.714286 − 1.714286 = 0.000000. ✓

Which is also why a group where every reward is identical is worthless: every advantage is exactly zero and the gradient contribution is nil. Rather than waste the rollouts, the paper adopts DAPO's dynamic sampling: "query groups whose rewards are all identical are filtered out online and replaced with newly sampled groups." You keep sampling until you get a group that disagrees with itself.

Step 2: GEPO — why heterogeneous tasks cannot share an advantage scale

Now the multi-task problem. The RL mixture spans "diverse scientific and general-purpose tasks" that "differ in structure, solution diversity, and uncertainty of policy exploration." Consider two extremes:

The paper's diagnosis: this heterogeneity "makes group-based policy optimization methods induce an entropy-dependent bias, making advantage signals across prompt groups statistically non-comparable." Two groups can produce advantages of the same magnitude that mean completely different things about the update they will cause.

Group-level entropy, Equation (25), is the diagnostic — estimated from samples you already have, with no extra rollouts:

Note the inner sum runs over t, so this is total sequence surprisal averaged across the group, not a per-token average. Longer responses contribute more. Then GEPO reshapes:

The published coefficient values are not in the report, so the worked numbers below are illustrative; the branch structure is the paper's.

Worked example 15: group entropy on two task families

Take K = 4 responses per group, five tokens each, and read off the average per-token log-probability.

Group M (maths, verifiable answer). The policy is confident: log π ≈ −0.05 per token. Per response, ∑_t log π = 5(−0.05) = −0.25. So

Group S (open-ended scientific write-up). Many tokens are genuinely free: log π ≈ −1.20 per token. Per response, 5(−1.20) = −6.00. So

A factor of twenty-four between two groups in the same batch. Now suppose at this training step the thresholds are H_low = 1.0 and H_high = 4.0. Group M sits below H_low, so its positive advantages are attenuated; group S sits above H_high, so its negative advantages are attenuated. With illustrative coefficients of 0.5 on the low-entropy positive branch and 0.8 on the high-entropy negative branch, and reusing the advantages from Worked Example 14:

Read what that does to the entropy gap over time. In group M, rewarding successes is what sharpens the distribution further — so damping the positives slows the slide toward collapse. In group S, punishing failures is what narrows exploration — so damping the negatives keeps the search alive. Each branch pushes back against the direction each regime was already drifting.

Step 3: adaptive length regularisation, and the invariant that makes it safe

Long-chain-of-thought models overthink. The paper cites the literature on it and names the symptom: "producing unnecessarily long reasoning trajectories even when the correct solution can be reached with substantially less computation."

The standard fixes both have costs the paper wants to avoid: an explicit length reward "introduce[s] auxiliary optimization objectives that may conflict with task rewards," and a separate length-control fine-tuning stage "complicate[s] the post-training pipeline and may disturb capabilities acquired during earlier RL stages." So instead: reweight advantages directly, with two principles.

Formally, let P_q = { i : Â_i > 0 } be the positive set, Equation (14). Then, Equation (15):

with the length weight, Equations (16) and (17):

Three things to notice before computing anything. The min and max are taken over the positive set only, so length is scored relative to the other successful answers, not to failures. α is "the minimum weight assigned to long responses" — a floor, so the longest correct answer is down-weighted but never zeroed. And γ "controls the shape of the length-dependent decay," so you can make the penalty gentle near the short end and steep near the long end, or the reverse.

The big fraction in front is a normaliser, and it is the whole safety argument. Read it as: multiply everything by whatever constant restores the original total.

Worked example 16: the full length reweighting, verified

Continue Worked Example 14. Six positives with  = 2/7 = 0.285714 each, two negatives at −0.857143. Their reasoning lengths, in tokens:

Activation check. |P_q| = 6, G = 8. With an illustrative τ = 0.5 the threshold is τG = 4, and 6 ≥ 4, so regularisation fires. (Had only three of eight been correct, nothing below would happen at all.)

Compute the weights. L⁺_min = 900, L⁺_max = 5000, so the span is 4100. Take α = 0.2 and γ = 1 (illustrative — the paper does not publish them):

Compute the normaliser. The weights sum to 1.00000 + 0.94146 + 0.88293 + 0.70732 + 0.59024 + 0.20000 = 4.32195. Since every Â_j is the same 0.285714 here, both sums factor:

Apply it. Ã_i = 1.388263 × w_i × 0.285714:

The sum came back to 1.714339 against an original 1.714286 — a discrepancy of 0.000053, entirely from rounding the weights to five decimals. That is the invariant the paper describes: "The normalization term approximately preserves the total positive advantage mass, thereby changing the relative preference among successful responses without substantially altering the overall optimization scale."

And the reported result of the whole mechanism, from the Intern-S2-Preview-35B ablation in Figure 8: "Both settings achieve comparable reward curves, while adaptive length regularization substantially reduces the average output length." Same accuracy, shorter answers — which is the only version of this result worth having, because a length penalty that costs accuracy is just a worse model.

Composing the three, and the order that matters

Equation (28) states the composition:

GEPO first, length second. The paper gives the reason for that order in one line: "This ordering ensures that the length-dependent weights act on the final entropy-adjusted advantages rather than modifying the verifier rewards." Since the length stage's normaliser is computed from the advantages it is rescaling, running it after GEPO means it preserves the post-GEPO mass — the thing that will actually be used — rather than a quantity GEPO is about to change.

The full objective, term by term

Everything from Chapters 4 and 5 arrives in Equation (29):

The training configuration, in full

Where log π comes from, derived once so it never mystifies again

Equation (29) is REINFORCE, and REINFORCE is one line of calculus that is worth deriving because every term in this chapter is a modification of it.

You want to maximise the expected reward of your policy: J(θ) = E_{y ∼ πθ}[R(y)]. Write the expectation as a sum and differentiate:

That is not yet an expectation — you cannot sample it. Multiply and divide by π_θ(y), which is legal wherever the probability is nonzero:

using ∇ log f = ∇f / f. That is the whole trick, and it is why every policy-gradient objective you will ever read has a log-probability in it: the log is what turns a derivative of a probability into something you can estimate by sampling.

And now the baseline is easy to justify. Adding any constant b that does not depend on y leaves the gradient unbiased, because E[∇ log π] = ∇ ∑_y π(y) = ∇1 = 0. So R(y) − b has the same expected gradient as R(y), with a variance you can choose b to minimise. The leave-one-out mean is a b that is nearly optimal and, critically, independent of the sample it corrects.

The pipeline as code

advantage shaping# From a group of verifier rewards to the scalar that multiplies log pi.

def shape(R, lengths, group_entropy, H_lo, H_hi, tau=0.5, alpha=0.2, gamma=1.0):
    G = len(R)
    if all_equal(R): return None                    # DAPO: resample this group entirely

    # --- 1. leave-one-out baseline, Eq (27) ---
    tot = sum(R)
    A = [(r - (tot - r) / (G - 1)) for r in R]      # sums to exactly zero

    # --- 2. GEPO, Eq (25)-(26): entropy-regime rebalancing ---
    if group_entropy < H_lo:
        A = [a_lo * a if a > 0 else a for a in A]  # damp exploitation
    elif group_entropy > H_hi:
        A = [a_hi * a if a < 0 else a for a in A]  # protect exploration

    # --- 3. adaptive length regularisation, Eq (14)-(17) ---
    P = [i for i in range(G) if A[i] > 0]
    if len(P) >= tau * G and P:
        lo, hi = min(lengths[i] for i in P), max(lengths[i] for i in P)
        w = {i: alpha + (1 - alpha) * (1 - (lengths[i] - lo) / (hi - lo + 1e-9)) ** gamma
             for i in P}
        norm = sum(A[i] for i in P) / (sum(w[i] * A[i] for i in P) + 1e-9)
        for i in P: A[i] = norm * w[i] * A[i]      # mass preserved, order changed

    return A                                        # one scalar per RESPONSE, shared by its tokens

Note the guard on the length stage: if len(P) >= tau * G and P. When the model is failing most of the time on a query, the branch never runs and every advantage passes through unchanged. Difficulty gates concision, automatically, per query, with no schedule.

Worked example 17: what γ actually does to the curve

α sets the floor and γ sets the shape. Take α = 0.2 and vary γ over the normalised length r = (L − L⁺_min) / (L⁺_max − L⁺_min), so w = 0.2 + 0.8(1 − r)^γ:

Check one cell by hand at r = 0.5, γ = 2: (1 − 0.5)² = 0.25, so w = 0.2 + 0.8(0.25) = 0.2 + 0.2 = 0.4000. ✓ And at γ = 0.5: (0.5)^0.5 = 0.70711, so w = 0.2 + 0.8(0.70711) = 0.2 + 0.56569 = 0.76569. ✓

Read the columns as policies. γ < 1 is forgiving in the middle and punishes only the extreme tail — "I do not mind moderately long answers, but the very longest should not be the template." γ > 1 falls away immediately — "I want the shortest one, and everything else is roughly equivalent." Since the normaliser restores the total either way, γ controls purely who gets the credit, not how much there is.

The Muon line, and why the optimizer is worth a sentence

"We use the Muon optimizer with a learning rate of 1 × 10⁻⁶ and a weight decay of 0.01." One line, easy to skip. But Adam and Muon differ in a way that matters at this scale.

For RL on a post-SFT checkpoint, "spread the update evenly across directions" is exactly the property you want: you are making a small correction to a model that is already good, and you would rather not let a handful of coordinates take the whole step. Combined with a learning rate of 1 × 10⁻⁶ — two to three orders of magnitude below a typical pre-training rate — the message of the configuration line is consistent: this stage is a nudge.

Chapter 6: Harness × Task — Making an Agent Trainable

Everything so far trains on a response: one prompt in, one long generation out, one verifier score. But the whole premise of Chapter 0 was that scientific work is a loop. So how do you run reinforcement learning when the episode is not a paragraph but a forty-minute session in which the model opens files, runs a test suite, reads a stack trace, edits three files, and runs the suite again?

The paper's answer is not an algorithm. It is an abstraction and a lot of infrastructure. And the abstraction is worth the chapter, because it is genuinely reusable.

The two things that were tangled

Before this framework, an agentic RL setup was usually one bespoke pipeline per combination: this agent scaffold running these tasks. Change the scaffold and you rewrote the rollout code; change the task source and you rewrote the verification code. The paper's move is to name the two axes and cut between them:

Their composition, in the paper's words, "converts heterogeneous agent executions into a common form of RL experience: an interactive rollout with an explicit environment, an observable action–observation history, and automatic outcome signals."

White box and black box

The harness axis splits in two, and the black-box half is the ambitious part.

Read that last cell again. The claim is that Intern-S2-Preview was trained with reinforcement learning inside real, third-party agent runtimes, unmodified. The agent framework thinks it is calling an ordinary model API. It is actually generating RL rollouts.

Which forces a specific engineering problem: those frameworks speak different protocols. The serving layer therefore accepts OpenAI Chat Completions, OpenAI Responses, and Anthropic Messages, streaming or not, and relays "streamed text, reasoning, and tool-call events … to the harness in their native form." From the client's side, in the paper's phrase, "this remains an ordinary model service."

Token-in, token-out — the detail that makes it trainable

Here is the problem that would kill this if it were not solved. To compute a policy gradient you need the exact token IDs the policy emitted and the exact log-probabilities it assigned. But a black-box harness gives you back a string. Re-tokenising that string is not guaranteed to reproduce the original token sequence — tokenisers are not injective over rendering round-trips, and one merged or split token silently corrupts your gradient.

So the serving layer "transparently captures training-only evidence, including exact input and output token IDs, rollout log probabilities, and token-wise MoE router experts, without exposing these extensions to the agent's control logic." The paper names the interface token-in–token-out (TITO):

The summary sentence is precise and worth memorising: "TITO therefore preserves the sampled token sequence, while R3 preserves the conditional computation path that produced it." Two different kinds of fidelity, both required, and the second one only exists because the model is a mixture of experts. This is the same R3 from Chapter 4, doing the same job in a harder setting.

Three protocols, one service

The protocol list in §4.4.1 is short and its implications are not. "Our LLM serving layer accepts OpenAI Chat Completions, OpenAI Responses, and Anthropic Messages, and supports both regular and streaming generation."

The trap hiding in that table is that each envelope implies a different string, and therefore a different token sequence, for what is semantically the same conversation. Which is exactly why the next section's TITO design matters: if the gateway rendered a response into a protocol envelope and the trainer later re-tokenised that envelope, the token sequence it recovered would depend on which harness happened to be connected. The tokens are captured before the envelope is applied.

Two views of one interaction, kept deliberately apart

A rollout produces two completely different kinds of record, and the design's cleverness is refusing to merge them.

The stated benefit: keeping the views separate "decouples environment-facing logic from model-specific training representations while retaining a lossless path from an agent action to the policy tokens that generated it." You can change the tokeniser without touching the environment code, and change the environment without touching the trainer.

The PrefixTree: storing a branching session without storing it twice

Now the data structure, which is the most quietly elegant thing in the paper.

An agentic session is a growing context. Turn 1 is the system prompt plus the task. Turn 2 is all of that, plus the assistant's first response, plus a tool result. Turn 3 is all of that, plus more. Store each model call as an independent record and you store the system prompt once per call — and if you sample several rollouts from the same task, you store the shared history once per rollout too. At 256K-token sessions this is ruinous.

So: "The Trace Store organizes each session as an incremental PrefixTree. Each node represents a newly appended context delta or assistant response and stores its token IDs, labels, rollout log probabilities, and router experts. Longest-prefix matching reuses the stable history of a session and appends only newly observed segments."

And the tree carries the loss mask with it, which is the second thing it is for: "System instructions, user messages, and tool observations are masked from the loss, while eligible policy-generated segments retain their training labels."

That masking is not optional bookkeeping. Consider what happens without it. A tool observation is text the model did not write — it is a compiler error, a directory listing, a JSON blob. Train on it and you are doing maximum-likelihood on your own environment's output format, teaching the policy to hallucinate plausible-looking tracebacks. The mask is the line between "the model's actions" and "the world's replies," and the PrefixTree is where that line is recorded.

The third job the tree does is the subtle one: "the PrefixTree preserves the lineage and exact boundaries of model calls across multi-turn and branching interactions. It thus establishes a stable correspondence between a semantic agent action and its rollout-time token span." That correspondence — "this tool call, in the transcript" maps to "these 340 token positions, in the trace" — is what makes Chapter 7's per-message credit assignment possible at all.

Where the tasks come from

An agent RL framework with no tasks trains nothing. The task distribution comes from two sources with very different characters.

Source 1 — curated executable coding and terminal tasks. Table 1 of the paper, in full:

Worked example 18: what the tasks-per-environment column is telling you

First verify the totals. Tasks: 59,136 + 2,438 = 61,574; + 7,480 = 69,054; + 32,100 = 101,154; + 20,200 = 121,354; + 80,000 = 201,354; + 13,500 = 214,854. Environments: 222 + 2,401 = 2,623; + 8,101 = 10,724; + 32,075 = 42,799; + 19,472 = 62,271; + 8 = 62,279; + 1 = 62,280. Overall ratio 214,854 / 62,280 = 3.45.

Now the interesting part. That 3.45 average is a lie in the way averages usually are, because the column is wildly bimodal:

Check: 121,354 + 93,500 = 214,854 ✓, and 62,271 + 9 = 62,280 ✓. So 43.5% of all training tasks live inside nine environments. Those two collections are procedural terminal and workspace tasks — many different objectives inside a small number of containers. The SWE family is the mirror image: one repository snapshot per issue, so nearly one environment per task, which is exactly what "mine real-world GitHub issues, pull requests, and repository histories" produces.

Whatever the source, everything is normalised into the same contract — "an initialized execution environment, a natural-language objective, and an automatic verifier" — by "materializing its base repository or container and required assets as the initial environment, translating its issue statement or instruction into the task objective, and retaining its tests or reward programs as the verifier."

And one line about what this normalisation deliberately does not do: "these tasks remain grounded in live environments rather than being reduced to static instruction–response pairs, so their rewards reflect program behavior, repository state, and task-specific execution outcomes." The reward is what the computer did, not what a judge thought about a transcript.

Source 2 — the self-evolving task synthesiser

Curated coding tasks teach coding. For "broader agentic coverage" the paper builds a closed loop that manufactures its own tasks out of community-contributed skills — documents that "describe concrete user workflows and their required tools and dependencies."

Step-level curation: keeping bad steps in the context, out of the loss

One more mechanism, and it is a nice one. When synthesised tasks are rolled out to build offline training data, trajectories that pass outcome filtering still get step-level curation. Each interaction step is annotated by behaviour type — the paper's list is worth reading in full, because it is a taxonomy of how agents fail:

And then the treatment: "Erroneous steps remain in the interaction context but can be marked as skip and excluded from the imitation loss, while the remaining responses serve as optimization targets."

That sentence contains a real insight. You cannot simply delete a bad step, because the steps after it were caused by it — the recovery only makes sense given the error. Delete the error and the recovery becomes an unmotivated non-sequitur, and you have taught the model to produce recoveries out of nowhere. Keeping the step in context and excluding it from the loss says: this happened, condition on it, but do not become it. The paper's own summary: "This selective masking avoids imitating flawed intermediate behavior without destroying the causal context of later actions."

The contract, as code

An abstraction is only real if you can write its interface down. Here is harness × task, with the two halves that never touch each other.

harness x task# A TASK knows nothing about agents. A HARNESS knows nothing about tasks.

class Task:
    def setup(self) -> Env:  ...      # materialise repo/container + assets
    objective: str                     # the instruction, in English
    def verify(self, env) -> Reward: ... # run tests / reward program AFTER the agent stops

class Harness:
    def run(self, objective, env, model_url): ...  # its OWN loop, prompts, tools, stop rule


def rollout(harness, task):
    env = task.setup()
    session = trace_store.new_session()             # a PrefixTree root

    # the harness thinks model_url is an ordinary OpenAI/Anthropic endpoint
    harness.run(task.objective, env, model_url=gateway.url(session))

    reward = task.verify(env)                       # executed, not judged
    notes  = process_annotator.scan(session)        # deterministic error detection
    return replay_buffer.add(session, reward, notes)


# what the gateway captures WITHOUT the harness ever knowing (TITO)
def on_model_call(session, new_context):
    prefix_ids = session.tokenised_prefix                # reused, never re-tokenised
    new_ids    = tokenize(new_context)                 # only the delta
    out        = engine.generate(prefix_ids + new_ids)
    trace_store.append(session,
        token_ids = out.ids,           labels  = "trainable",
        logprobs  = out.logprobs,      experts = out.router_experts)  # R3
    return render_native(out, protocol=session.protocol)   # chat / responses / messages

Everything the trainer needs is captured in on_model_call, and nothing in Harness.run knows it happened. That is the whole black-box story in one function.

Worked example 19: what the PrefixTree saves on one task

Take a single task rolled out G = 8 times, as a group-relative method requires. Each session is a 10-turn interaction; suppose the shared system prompt plus task statement is 3,000 tokens, and each turn adds an average of 1,200 tokens of assistant response plus tool observation. Assume the eight rollouts agree for the first two turns and then diverge (a plausible pattern — the opening moves of a task are nearly forced).

Naive storage: one flat context per model call. Turn t of one session contains the whole history, so its stored length is 3,000 + 1,200t. Across 10 turns, one session stores:

Eight sessions: 768,000 tokens.

PrefixTree storage: each node once. The shared trunk is the 3,000-token header plus two shared turns, so 3,000 + 2,400 = 5,400 tokens, stored once. Each of the eight sessions then contributes eight divergent turns of 1,200 tokens: 8 × 1,200 = 9,600 tokens each. Total:

Two separate effects are stacked in that number, and it is worth separating them. Most of the saving is that a node is stored once rather than once per turn that contains it — that is the incremental-delta property, and it applies even to a single session with no branching (96,000 tokens flat versus 15,000 as deltas, a 6.4× saving). The rest is prefix sharing across the eight rollouts of the trunk. As the paper puts it: "Longest-prefix matching reuses the stable history of a session and appends only newly observed segments."

Worked example 20: what black-box support is worth

Suppose you support 5 harnesses and 4 task families. Count the integration work under each design.

Twenty against nine is a 2.2× saving today; the ratio grows as H·T against H + T. But the marginal number is the one that actually decides whether a research group can move: adding a harness costs one adapter instead of four pipelines, which is the difference between "we will support the new agent framework next quarter" and "someone can do it this afternoon."

And there is a second-order benefit the paper gestures at in its evaluation. Because the training framework can drive real harnesses, the evaluation can too — and it does: SkillsBench on OpenClaw 2026.5.7, Terminal-Bench on Terminus 2, SWE-Bench Pro and Multilingual on Mini-SWE-Agent, ResearchClawBench on ResearchHarness v0.0.49. Train and test on the same class of artefact, and the distribution shift between the two shrinks to the difference between task sets rather than the difference between a synthetic loop and a real one.

What each piece of the infrastructure is for

§4.4.1 names half a dozen components. Sorted by the problem each one exists to solve:

Notice that six of those eight are not machine learning at all. They are process isolation, protocol adaptation, resource lifecycle, and storage. The paper's own framing of why this is the contribution: the composition "converts heterogeneous agent executions into a common form of RL experience."

The self-evolving loop, and the word "closed"

One last thing about §4.4.2 worth drawing out. Most synthetic-data pipelines are open loops: generate, filter, train, ship. This one closes:

"We aggregate execution failures and verifier feedback by skill domain and synthesis stage, and use these statistics to update skill sampling weights as well as synthesis skills, environment templates, and stage-specific prompts. The revised system then resamples capability paths and generates the next task distribution, progressively improving executability, coverage, and difficulty from observed agent behavior."

Chapter 7: Credit and Integrity

You have a session. It has eleven assistant messages, nine tool results, and one number at the end: solved. Now answer two questions that decide whether the training works.

First: which tokens get the credit? The session succeeded, but message four called a tool that does not exist, and messages five and six were spent recovering from that. Reward everything equally and you have just taught the model that inventing tool names is part of a winning strategy.

Second: is the reward even real? The verifier ran a test suite. The agent had write access to the repository. What stopped it from editing the tests?

§4.4.3 answers both, in that order.

Session-aware outcome credit: one reward, many segments

Start with the base case. An agentic session "may contain multiple assistant responses separated by system instructions, user messages, tool calls, and environment observations. Nevertheless, these segments jointly solve one task and receive one final outcome reward."

So within a rollout group for the same task, a group-relative advantage A_i is computed from the complete-session reward — the same group-relative machinery as Chapter 5, one level up. Then: "The same session advantage is assigned to all eligible policy-generated segments in its trace, rather than treating each model call as an independently rewarded episode."

Two bookkeeping facts make this work, both from Chapter 6: "Token-level labels exclude non-policy context from the loss, while the PrefixTree preserves the exact boundaries of the trainable response segments."

Process-aware advantage control: the fix for succeeding badly

Now the interesting case. "Outcome-only credit can reinforce undesirable intermediate behavior when a session eventually succeeds despite malformed outputs, invalid or repeated tool calls, unnecessary recovery attempts, or abnormal termination."

The architecture keeps two channels strictly apart:

The process weight w_i,k ∈ [−1, 1] for segment k of session i enters through Equation (30):

and the advantage is zero for non-trainable tokens.

Stare at the branch. The weight applies only when the advantage is positive. The paper's reason: "They are applied only to positive advantages, so the negative learning signal of failed trajectories is preserved."

Worked example 21: four segments, one session, one reward

A session succeeded and drew a group-relative advantage of A_i = +0.60. Four trainable assistant segments; the process annotator flagged two of them.

Now run the same four segments in a session that failed, A_i = −0.60. The branch in Equation (30) means the weights are ignored entirely: every trainable segment gets −0.600, including the good ones.

That asymmetry looks unfair on segment 1 — it was a reasonable action, penalised for the company it kept. It is nonetheless the correct engineering choice, for two reasons. Reason one: if you let process weights reduce the penalty on well-formed steps inside failures, you have built an incentive to produce beautifully-formatted actions that solve nothing, and format is much easier to optimise than correctness. Reason two: outcome failure is the only signal in the entire system that is unambiguously trustworthy, because a program produced it. Weakening it with heuristic annotations trades a hard signal for a soft one.

And note what makes Equation (30) implementable at all: it needs w_i,k to be applied to the exact token span of message k. That mapping is precisely what Chapter 6's PrefixTree was built to preserve — "The PrefixTree maps each annotated message to its exact trainable token span." Without the trace store, this mechanism could not exist.

Outcome versus process, and why the paper keeps them separate

The split in this chapter has a name in the literature, and the paper cites it: the distinction between outcome supervision and process supervision. Outcome supervision scores the final answer; process supervision scores each intermediate step. Both have a well-known character.

The usual move in the literature is to train a process reward model and use it to shape rewards throughout the trajectory. This paper does something more conservative: it keeps outcome supervision as the only source of reward, and uses process information solely as a multiplicative gate on positive credit, computed from deterministic checks rather than a model.

Worked example 22: the group-relative advantage for a session

Where does A_i come from in an agentic setting? The same place it came from in Chapter 5, one level up: a group of rollouts of the same task, each scored by the verifier on the complete session.

Take G = 6 rollouts of one SWE task under one harness. All-correct semantics, so the reward is binary. Two of the six solved it: R = (1, 0, 0, 1, 0, 0).

Check the sum: 2(+0.800) + 4(−0.400) = 1.600 − 1.600 = 0.000. ✓

Now note the difference from a reasoning group. On a hard task where only two of six succeed, a success is worth +0.800 and a failure only −0.400 — the rare outcome carries twice the signal. Compare with Chapter 5's group of eight where six succeeded: there, success was worth +0.286 and failure −0.857. The estimator inverts the asymmetry automatically as difficulty changes, which is exactly the behaviour you want on a task distribution spanning "resolve a one-line typo" and "implement a multi-file feature."

And then each of those six numbers is broadcast to every trainable segment in its session, modulated by the process weights of Equation (30) whenever it is positive. A successful rollout with eleven assistant messages produces eleven token spans all carrying +0.800, minus whatever the annotator withheld.

What makes a segment "eligible"

The paper says the session advantage is assigned to "all eligible policy-generated segments." That qualifier is carrying two separate filters, and it is worth pulling them apart.

These operate at different granularities and both are necessary. Provenance is a span property: an entire tool observation is out, regardless of its contents. Numerical trust is a token property: a single position inside an otherwise-good assistant message can be dropped while its neighbours train. A segment can therefore be fully eligible by provenance and still contribute nothing, if every one of its tokens failed the mask.

The annotator's taxonomy, mapped to weights

§4.4.2 lists the behaviour types the step-level curation annotates, and §4.4.3 lists what process weights "can suppress or reverse." Putting the two lists side by side gives you the practical mapping — the specific values are illustrative, the categories are the paper's.

Two structural notes. The weight is bounded in [−1, 1], so the most a process annotation can ever do is invert the session advantage completely — it cannot amplify it. And every one of these detections is deterministic: the paper specifies "a process annotator attaches an adv_penalty to the specific assistant message exhibiting a deterministic process error." No model judges taste here. Either the JSON parsed or it did not; either the tool name is in the registry or it is not.

Verifier integrity: what stops the agent cheating

This section exists because of a hard truth about executable rewards: an environment that an agent can act in is an environment an agent can corrupt. The paper names the threats — "executable environments expose the reward channel to solution leakage, test manipulation, and other forms of reward hacking" — and then lists the countermeasures. Each one is a specific attack, closed.

Notice the shape of the fourth row, because it is the general pattern: the agent's edits and the grading artefacts are applied in a fixed order, with grading last. The agent may write whatever it likes to the test files; the canonical versions are overlaid afterwards. This converts a security problem ("prevent the agent from touching the tests") into a sequencing problem ("it does not matter what it touched"), which is a much easier problem and does not require sandboxing that the agent cannot reason around.

And a small operational note buried in §5.1.2 that shows the same instinct applied at evaluation time: for SWE-Bench Pro, "we modified the official evaluation image to avoid agents getting ground truth from git logs." They found the leak in somebody else's benchmark image and closed it before reporting a number on it.

The credit-assignment problem this design does not solve

Be clear about the boundary. Session-aware outcome credit plus process weights gives you two things: an unbiased reward, and a way to withhold it from mechanically-bad steps. It does not give you an answer to the classic question.

The field's usual answers all carry costs this paper chose not to pay:

Over many rollouts of many tasks, the coarse signal is not as bad as it sounds: a step that reliably appears in successful sessions and not in failed ones accumulates positive credit statistically, even though no single session identified it. That is the same argument that makes REINFORCE work at all, and it is why the paper can afford to leave the fine-grained question open — at the price of needing more rollouts than a per-step method would.

What the reward curves actually show

Figure 11 reports reward trajectories "across SWE, general-purpose, and terminal tasks under multiple agent harnesses," each panel "a representative example over 160 optimization steps," locally smoothed. The paper's own reading:

And then a caveat the paper writes itself, which is worth quoting because most reports do not: "These different dynamics are expected: a harness determines the interaction policy and context construction, while the task determines the environment and reward semantics. The shared upward trend is therefore evidence that the common trace, credit-assignment, and optimization stack remains effective across distinct harness–task compositions, rather than evidence that their absolute reward scales are directly comparable."

Translated: do not read these curves against each other. A reward of 0.4 on a terminal task and 0.4 on a SWE task are different quantities with different verifiers. What the figure supports is a claim about the machinery — that one training stack works across compositions — not a claim about which composition is harder.

Credit assignment as code

session credit# One session's trace -> a per-token advantage map.

def assign(session, group_rewards, i):
    # group-relative advantage from the COMPLETE-SESSION reward
    A = group_rewards[i] - mean(group_rewards[:i] + group_rewards[i+1:])

    adv = zeros(session.n_tokens)              # default: no gradient anywhere

    for seg in session.segments:               # from the PrefixTree, in order
        if seg.label != "trainable":            # system / user / tool observations
            continue                            # stay ZERO - never imitate the environment

        w = seg.process_weight                  # in [-1, 1], from the annotator
        a = w * A if A > 0 else A            # Eq (30) - the asymmetric branch

        # the PrefixTree gives the EXACT token span for this message
        adv[seg.start:seg.end] = a

    return adv


# the process annotator never touches the reward, only the weight
def annotate(seg, history):
    if not parses(seg):                 return 0.0    # malformed output
    if seg.tool not in TOOLS:              return 0.0    # invalid tool name
    if identical_to_recent_failure(seg, history): return -0.5  # repeated failed call
    if seg.stop_reason in ("context_limit", "turn_limit"): return -0.5
    return 1.0

Two lines carry the chapter. if seg.label != "trainable": continue is the boundary between the model's actions and the world's replies. a = w * A if A > 0 else A is the asymmetry. Everything else is bookkeeping that the trace store already did.

Worked example 23: the same four segments, three outcomes

Extend the earlier example to see the full behaviour of Equation (30). Same session shape, same annotations, three different verifier verdicts, and a group whose other rollouts give A the values below.

Three readings. In column one, a clean win: the two good segments get full credit, the malformed call gets nothing, and the repeated call is actively pushed down inside a session that succeeded — which is the entire point of the mechanism. In column two, the same structure scaled down sixfold, because the leave-one-out baseline says this success was expected. In column three, the weights vanish and every trainable segment carries the full penalty.

And note the bottom row across all three columns: the tool observations are zero everywhere. There is no verdict under which the model is trained to reproduce its environment's output.

All-correct semantics, worked

"We use conservative all-correct semantics for software-engineering tasks, requiring both target-fix and regression checks to pass." Make that concrete on a SWE-style task, which ships two test sets:

Suppose a task has 3 fail-to-pass and 412 pass-to-pass tests. An agent submits a patch that fixes all 3 and breaks 1 of the 412. Under a proportional metric it scores 414/415 = 99.76%. Under all-correct semantics it scores 0.

The harsh version is the right one, and the reason is what a partial reward would teach. A gradient that rewards 99.76% is a gradient that says "breaking one unrelated test is a rounding error." Compound that over training and you have a policy with a systematic tolerance for collateral damage — which is precisely the behaviour that makes an automated code agent unusable in a real repository. Binary all-correct semantics encode the actual acceptance criterion of the job.

Why leakage is not a hypothetical

It is tempting to read the leakage-prevention list as due diligence. It is not; each item corresponds to a channel that an optimiser will find, because the optimiser is not trying to cheat — it is trying to maximise a number, and these are the cheapest paths to that number.

The last row is the subtlest and the paper closes it explicitly: "Missing grading artifacts, execution failures, and unparseable verifier outputs are tracked separately from genuine task failure, preventing infrastructure errors from being interpreted as successful policy behavior." If a broken run is silently scored as a pass, you have built a reward for breaking the runner.

Chapter 8: Two Experts, One Model

There is a problem we have been walking past. Chapters 4 and 5 built a reasoning RL pipeline. Chapters 6 and 7 built an agentic RL pipeline. They are different objectives, different reward semantics, different response lengths, different entropy regimes. What happens if you just train one model on both at once?

The paper's answer is careful: "Although mixed reinforcement learning enables a single policy to acquire broad capabilities, jointly optimizing highly heterogeneous reasoning and agentic tasks can introduce optimization conflicts and prevent the model from fully exploiting domain-specific training signals."

Note it does not say joint training fails. GEPO exists precisely to make heterogeneous joint training work, and the multi-task RL stage is joint. The claim is narrower: for two families this far apart, you get more out of specialising first.

The shape of the final stage

Why two experts and not twenty

Multi-teacher distillation usually means many fine-grained domain specialists. The paper deliberately does not: "we organize specialization around two broad capability domains. Our preliminary evaluation suggests that independently training teachers for many fine-grained domains incurs substantial RL and infrastructure costs, while providing limited additional benefit for our setting."

Do the arithmetic that sentence implies. Each teacher is a full RL run on a 397-billion-parameter model — the partial-rollout cluster, the verifier fleet, the sandbox provider, all of it. Twenty teachers is twenty of those. And the marginal return is bounded: after the first few domains, teachers start overlapping, and a student cannot absorb more than the union of what its teachers know. Two teachers over two genuinely disjoint capability families sits at, in the paper's phrase, "a favorable balance between specialization quality, training cost, and distillation complexity."

The distribution mismatch problem, and why shared ancestry fixes it

Here is the failure mode that makes on-policy distillation hard. In on-policy distillation, the student generates the trajectories and the teacher scores them. That is the good property — the student is corrected on states it actually visits, not on a teacher's idealised transcript. But it has a precondition: the teacher must be competent at scoring what the student produced.

Think about what "outside the reliable support" means concretely. The teacher assigns a probability to the student's token given the student's prefix. If that prefix is somewhere the teacher would essentially never have gone, the teacher's distribution there is not a considered judgement — it is an extrapolation from a region it barely modelled. You are asking an expert about a situation they have never been in and treating the answer as ground truth.

Two things reduce the gap. First, structural: "both expert policies are derived from the same SFT checkpoint and therefore retain broadly compatible generation behaviors." They are siblings, not strangers. Second, procedural: a warmup borrowed from Nemotron 3 Ultra — "we use the reasoning and agentic experts to generate high-quality trajectories and perform a lightweight SFT warmup on the original SFT model," and that becomes the initial student. "This warmup exposes the student to the characteristic reasoning patterns and interaction behaviors of both teachers, increasing the overlap between student-generated trajectories and teacher-supported distributions before OPD optimization begins."

The objective, and which direction of KL it is

The idealised objective, Equation (31):

which the paper notes is equivalent to minimising

"on states induced by the student itself."

The other virtue is density. Compare it to what Chapter 5 was working with: "In contrast to RL objectives based on sparse trajectory-level rewards, OPD provides dense token-level supervision from the corresponding expert throughout the generated trajectory." One scalar for a 60,000-token response, versus a teacher opinion at every single position.

Worked example 24: the communication payload, and why they cut it

To give the student a teacher opinion at every position, the teacher's opinion has to travel from a teacher-scoring worker to a learner worker. How much data is that?

Take a single trajectory at the system's maximum, H = 256K = 262,144 tokens.

Option A — full-vocabulary logits, O(HV). The paper does not publish its vocabulary size, so use a round V = 100,000 purely to feel the magnitude:

Option B — top-k logits, O(Hk). The paper names top-64 as the realistic version of this:

Option C — the sampled token's teacher log-probability only, O(H).

Option C is 64× smaller than Option B and roughly 100,000× smaller than Option A. Now multiply by a batch: at 8,192 trajectories, Option B would be 33.6 MB × 8,192 ≈ 275 GB moving across the interconnect per batch. Option C is about 4.3 GB. That is the difference between a design that runs and one that spends its life in the network.

The paper's justification for why the cheap option suffices: "Since our teachers share the same SFT origin and the warmup stage further reduces their policy discrepancy with the student, we find that transmitting only the teacher log-probability of each sampled token is sufficient for stable distillation."

The practical objective: same machinery, different advantage

To reuse the partial-rollout infrastructure, OPD is written in the same clipped importance-weighted REINFORCE form as Chapter 5. Only the advantage changes, Equation (33):

where π_prox is "the frozen proximal student policy used to construct the distillation signal." The paper's reading: "The advantage is positive when the teacher assigns a higher probability to the sampled token than the proximal student and negative otherwise, thereby increasing or decreasing the probability of the sampled action accordingly."

Worked example 25: reading the distillation advantage

Because it is a difference of logs, the advantage is exactly the log of the probability ratio: Â^OPD = ln( p_T / p_prox ).

Two properties worth naming. First, the advantage is self-annihilating at convergence: when the student matches the proximal policy's teacher-agreement, the advantage is zero everywhere and training halts on its own. There is no reward to keep chasing. Second, the scale is logarithmic, so a teacher that assigns 0.002 to something the student liked produces a strongly negative but finite advantage — it does not blow up the way a raw ratio p_T/p_prox would in the other direction.

The importance ratio and clipping are unchanged from Chapter 4, Equations (34) and (35), using "the same interval as reasoning RL":

and the full objective is Equation (36):

Compare it with Equation (29) side by side and the symmetry is exact:

The paper says it outright: "Equation (36) has the same optimization form as the unified reasoning RL objective in Equation (29). … The only distinction is the advantage."

Worked example 26: forward versus reverse KL, on three outcomes

The direction claim in the callout above is easy to assert and worth proving to yourself once. Take a teacher that is genuinely bimodal — two acceptable continuations and one bad one — and a student restricted to a family of distributions that can only really commit to one place.

Consider two candidate students:

Forward KL, D(p_T ‖ S) — the mass-covering direction. For S_cover:

For S_mode:

Forward KL prefers S_cover, 0.146 against 0.626 — by a factor of 4.3. It would rather the student hedge across all three options, including the bad one, than commit to a good one.

Reverse KL, D(S ‖ p_T) — the mode-seeking direction. For S_cover:

For S_mode:

Reverse KL also prefers S_cover here, 0.196 against 0.453 — because S_mode abandoned one of the teacher's two genuinely good modes, and reverse KL does penalise that too. So where is the mode-seeking? Look at which term dominates S_cover's reverse KL: 0.33 ln(0.33/0.10) = +0.394, coming entirely from the bad option. Reverse KL punishes the student for putting mass where the teacher does not, weighted by the student's own mass there. So its gradient's loudest instruction is "get out of the third slot."

Follow that instruction and see who rewards it. Move S_cover's third component from 0.33 to 0.02, redistributing onto the teacher's two good modes — call it [0.49, 0.49, 0.02]. Compute both divergences for that student:

Now compare the rewards for abandoning the bad option. Reverse KL fell from 0.19634 to 0.05127 — a 74% reduction. Forward KL fell from 0.14631 to 0.08430 — only 42%. And push the third component all the way to zero and the asymmetry becomes absolute: reverse KL's 0.02 ln(0.02/0.10) term goes to 0 · ln 0 = 0, while forward KL's 0.10 ln(0.10/q) term diverges to infinity. Forward KL will not let you drop a teacher behaviour at any price. Reverse KL positively wants you to.

Why a frozen proximal student, and not the live one

Equation (33) compares the teacher against π_prox, "the frozen proximal student policy used to construct the distillation signal" — not against the current learner π_θ. That distinction is worth a paragraph, because it is exactly the same instinct as the detached weight in Chapter 4.

If the advantage were sg[log π_T − log π_θ] with π_θ live, the target would move underneath every mini-batch update: the same token would have a different advantage on mini-batch 1 and mini-batch 8 of the same rollout batch, purely because the learner had drifted. Freezing the reference at the start of the batch gives every token in that batch a fixed target, so the eight mini-batch steps are all optimising the same objective. It is a trust region built out of a snapshot rather than a constraint.

on-policy distillation stepdef opd_batch(prompts_by_domain, student, teachers, prox):
    loss = 0.0
    for d, prompts in prompts_by_domain.items():        # d in {"rea", "agt"}
        traj = student.generate(prompts)                    # ON-POLICY: the student drives
        for t in traj:
            # the teacher only ever scores the SAMPLED token -> O(H) payload
            lp_T    = teachers[d].logprob_of(t.ids, t.states)  # (H,)
            lp_prox = prox.logprob_of(t.ids, t.states)         # (H,)
            adv     = detach(lp_T - lp_prox)                   # Eq (33) = log(p_T / p_prox)

            rho = detach(clip(exp(student.logprob_of(t.ids, t.states) - t.logp_beh),
                              1 - eps_low, 1 + eps_high))       # Eq (34)-(35)

            mask = t.bkl_mask & t.is_policy_token             # drop tool output, prompts, padding
            loss -= lam[d] * (mask * rho * adv *
                              student.logprob_of(t.ids, t.states)).mean()
    return loss                                              # Eq (36) - identical shape to Eq (29)

Compare the body of that loop with the reasoning-RL objective and the only line that differs is adv. Everything else — the clipped detached ratio, the numerical mask, the policy-token mask, the mean — is reused verbatim.

The domain weights λ_d, and what they can go wrong

Equation (36) carries a per-domain coefficient λ_d that "controls the contribution of each teacher domain," and Equation (31) uses the same symbol to control "the sampling or loss weight of each domain." The paper does not publish its values, and the value it chose is the entire content of "how much of each expert survives."

The middle column is the one that makes this work, and it is worth being explicit about why. "During OPD, each query is assigned to either the reasoning or agentic domain, and the corresponding expert is selected as its teacher." The two teachers are never asked about the same prompt. There is no arbitration, no averaging of two opinions about one token, and therefore no way for the teachers to actively disagree. λ_d is a data mixture weight, not a blend of conflicting supervision.

What the student ends up with

The paper's closing claim for the stage: "The resulting student consolidates the scientific reasoning capabilities of the mixed-reasoning policy and the long-horizon interaction capabilities of the agentic policy into the unified Intern-S2-Preview model."

And this is why Chapter 9's shape is what it is. A model that had only run reasoning RL would look strong on SciReasoner and weak on Terminal-Bench; one that had only run agentic RL would look like the reverse. Intern-S2-Preview-397B is competitive on both and best-in-class on neither of the agentic leaders — which is the signature of a consolidation, and the price you pay for one set of weights instead of two.

Reading Equation (36) as a gradient

One more pass, to make the mechanism physical. Differentiate the summand with respect to θ. Only log π_θ carries gradient, so for a single trainable token:

Now read the sign. Gradient descent steps in the direction of −∇L, which here is + mρ̄Â^OPD∇ log π_θ. So:

And the magnitude is ln(p_T / p_prox), so a token the teacher rates ten times higher gets a push of ln 10 = 2.303 while one it rates 1.1 times higher gets 0.095 — a 24× difference in step size from a 9× difference in opinion. The logarithm compresses the extremes, which is what keeps a single confidently-disagreeing token from dominating a batch.

What distillation cannot recover

One honest limit before the summary. On-policy distillation transfers what a teacher would say at the student's own states. That is a strong signal, and there are things it structurally cannot move.

The whole post-training pipeline, end to end

This is the last training chapter, so here is the complete journey from pre-trained checkpoint to released model, with every mechanism from Chapters 4 through 8 placed where it acts.

Two structural observations. First, stages 2a and 2b are parallel, not sequential — they branch from one checkpoint and never see each other's gradients, which is exactly what makes them specialists. Second, the same three low-level mechanisms — partial rollout, R3, the BKL mask — appear in stages 2a, 2b, and 4. They are the substrate, not features of any one stage.

Chapter 9: The Scoreboard, Read Honestly

Every model report's results section is written by people who want the model to look good. That is fine and expected; the reader's job is to read the table rather than the prose. This chapter puts all four evaluation tables in front of you with the losses marked, and then says what each one actually supports.

The comparison set is seven other frontier models: Qwen3.5-397B-A17B, DeepSeek-V4-pro, Kimi-K2.7-Code, GLM-5.2, GPT-5.5, Gemini-3.1-Pro, and Claude-Opus-4.8. Some are open-weight, some are not, and the paper's own convention distinguishes "best among open-sourced models" from "best among all models" — a distinction we will keep, because it changes almost every conclusion.

Table 2 — scientific benchmarks

Now read it properly, because there are two completely different stories in that table.

And ProteinBinder-9 deserves a special note. Intern scores 4.36 and the field scores between 1.64 and 2.40. That is the best result in the column and it is also, in absolute terms, a pass rate of about four percent on de novo protein binder design. The benchmark asks a system to "generate protein binders that satisfy a predefined binding interface and pass a multi-stage structural and physicochemical evaluation pipeline," with candidates assessed using RFdiffusion and AlphaFold 3 and then filtered on interface confidence, binding energy, and molecular contacts. Winning a benchmark where every model is near the floor tells you the ordering is right and very little about whether the capability is usable.

Table 3 — general benchmarks

The paper's summary of this table — "the best results among open-source models on MMLU-Pro (89.75), SimpleQA-Verified (69.90), MMMU-Pro (80.46), and ChartQAPro (69.65)" and, on agentic tasks, "consistently outperforms Qwen3.5-397B and demonstrates performance comparable to that of Kimi-K2.7-Code" — is accurate. It is also carefully scoped, and the scoping is where the information is.

What each scientific benchmark actually asks

A score is meaningless without knowing what was scored. §5.1.1 describes each benchmark, and the descriptions change how you read the numbers — particularly the ones where Intern's margin is enormous.

Worked example 27: the multimodal rows have holes in them

Look again at the multimodal blocks of Tables 2 and 3 and count the dashes. DeepSeek-V4-pro and GLM-5.2 have no entry on XLRS-Bench, MicroVQA, SFE, ObsCrisis-Bench, MMMU-Pro, or ChartQAPro — six rows, two models, twelve missing cells.

That matters for how you read "best among open-sourced models." On MMMU-Pro, Intern's 80.46 is compared against Qwen3.5's 80.29 and Kimi's 77.92, and GLM-5.2 — which beats Intern on SGI-Bench, ResearchClawBench, TerminalBench, SWE-Bench-Pro, and SWE-Bench-Multilingual — simply is not in the column. The lead is real over the models that were measured. It is silent about the two that were not.

The likely and unremarkable explanation is that those models are text-only or their multimodal variants were unavailable. The reading instruction stands regardless: a dash is not a zero and it is not a loss; it is an absence, and an absence narrows the claim.

The two multimodal losses, examined

Two scientific-multimodal rows go against the model, and they are worth a look because they are the only places in Table 2 where a general model beats it on perception.

ObsCrisis-Bench is the interesting one, because it is the benchmark in the table that most resembles the paper's own thesis: heterogeneous evidence (multispectral imagery plus optional numerical station measurements), across multiple timesteps, requiring "early warning, event-type and timing prediction, impact assessment, and post-event recovery analysis." A model with a dedicated time-series encoder ought to be advantaged here. It scores fourth of six models with a number, and the whole field is under 33.

Table 4 — time-series understanding on SciTS (F1)

This is where the architecture chapter cashes out, and the margins are enormous.

Three separate claims live in that table, and they are worth separating.

Claim 1 — modelling the numbers beats describing them. Look at BIU01: every general model scores between 0.0 and 1.5 F1. Both Intern models — the only two with a dedicated time-series encoder — score 20.8 and 36.5. The paper's reading: this highlights "the importance of directly modelling the underlying time series rather than relying solely on textual descriptions or visualized signals." Note also that the vision-language variants do not rescue it: GPT-5-mini scores 0.8 looking at a plot of the signal. A picture of the data is not the data.

Claim 2 — the smaller model beat the bigger one, and you can count it. Nine tasks are supported by both Intern models. Intern-S2-Preview-397B wins seven: ASU03 (75.9 → 91.0), BIU01 (20.8 → 36.5), BIU03 (88.3 → 98.3), EAU01 (99.5 → 100.0), MEU01 (65.6 → 81.8), PHU01 (36.8 → 66.9), PHU04 (93.2 → 99.9). It loses two: ASU01 (98.0 → 97.1) and NEU06 (71.3 → 70.2), both by about one point. Seven of nine, at "less than half the number of parameters." The single largest jump is PHU01, 36.8 to 66.9 — the paper calls this out by name.

Claim 3 — two tasks are new. RAU01 and RAU02 are blank for Intern-S1-Pro. These are the radar tasks — "radar coding-scheme classification and mode-and-modulation classification, which was not supported by Intern-S1-Pro." S2 scores 88.4 and 60.2 against general-model baselines in the 4–32 range. That capability is a direct consequence of the Chapter 1 change that made the encoder handle "high-frequency but short sequence lengths."

Table 5 — forecasting on SciTS: MAPE, with the success rate in brackets

This is the most instructive table in the paper, and the reason is the parenthesis.

Lower MAPE is better; higher success rate is better.

Worked example 28: why the parenthesis destroys three rows

Look at ENG02. GPT-5-mini reports a MAPE of 56.1, which is lower — better — than Intern's 60.2. If you read only the first number, the general vision-language model wins that column.

Now read the second number: 4.5. It produced a usable forecast on 4.5% of the cases. The 56.1 is the error on the 4.5% it managed, which is a conditional average over a self-selected sample — the easy ones, the short horizons, the cases where the output length happened to fit. Intern's 60.2 is the error over 100% of them.

Make the comparison honest by asking a question that does not depend on which subset was attempted: on 1,000 forecasting requests, how many produce a usable answer at all?

The paper explains the failures precisely: "Text and Vision-Language LLMs often exhibit low success rates because long prediction horizons can exceed their output capacity, while strict sequence-length and formatting requirements frequently lead to instruction-following failures. Moreover, generating forecasts through discrete text tokens can compromise numerical precision."

Every one of those three failure modes is what Chapter 1's Lane 4 was built to remove. Output capacity: a numerical branch emits values, not thousands of numerals. Formatting failures: there is no format to get wrong. Precision: values are values. And the horizon predictor — that unglamorous module with 99% accuracy — is what turns "forecast the next two seconds" into an integer without an instruction-following failure.

Against the specialised forecasters, which all achieve 100% success by construction, Intern wins six of the seven columns outright — ENG02, ENG03, MEG03, PHG02, URG01, URG05 — and on NEG03 it posts 59.2 against Moirai-Large's 59.1, a gap of 0.1. Winning six of seven against dedicated time-series models, while also being a 397-billion-parameter language model that reads PDFs, is the strongest single result in the report. The paper adds one more data point: on GIFT-Eval, "a benchmark for general time series forecasting," it achieves "a competitive zero-shot MASE of 0.785."

Worked example 29: aggregate the SciTS understanding table

Table 4 has eleven columns and it is easy to lose the shape. Average the F1 scores over the nine tasks both Intern models support — ASU01, ASU03, BIU01, BIU03, EAU01, MEU01, NEU06, PHU01, PHU04:

Intern-S1-Pro (1T): 98.0 + 75.9 + 20.8 + 88.3 + 99.5 + 65.6 + 71.3 + 36.8 + 93.2.

Running: 98.0, 173.9, 194.7, 283.0, 382.5, 448.1, 519.4, 556.2, 649.4. Divide by 9:

Intern-S2-Preview-397B: 97.1 + 91.0 + 36.5 + 98.3 + 100.0 + 81.8 + 70.2 + 66.9 + 99.9.

Running: 97.1, 188.1, 224.6, 322.9, 422.9, 504.7, 574.9, 641.8, 741.7. Divide by 9:

A gain of 10.25 F1 points, at roughly 40% of the parameters. And the strongest general-purpose baseline on the same nine tasks — take Gemini2.5-Flash in its text configuration: 64.1 + 16.3 + 1.5 + 12.4 + 67.6 + 60.9 + 5.8 + 20.7 + 64.8 = 314.1, so 314.1 / 9 = 34.90.

Two different comparisons live in that column and they should be read differently. The 47-point gap to a general model is an architecture gap — one system models the signal, the other reads a description of it. The 10-point gap to the predecessor is a refinement gap: same idea, better encoder, half the parameters. Chapter 1's channel-wise Transformer and adaptive patching are what that ten points is made of.

The forecasting columns, counted

Against the five specialised forecasters — all of which achieve 100% success by construction, since they are purpose-built numerical models — here is who wins each column of Table 5, by lowest MAPE.

Six of seven, with the loss being a tenth of a point. And note which specialist is strongest changes column by column — TimeOmni three times, Chronos twice, Moirai and TimeMoE once each — while one general-purpose foundation model is at or near the top of every column. That is the strongest form the result can take: not "we beat the best baseline" but "we beat a different best baseline in each domain."

What the whole scoreboard supports, in one paragraph

Domain-native scientific tasks: dominant, by margins that indicate a capability difference rather than a tuning difference. Time series: dominant, understanding and forecasting alike, with a smaller model beating its trillion-parameter predecessor seven times out of nine. General knowledge and factuality: best among open models, behind Gemini-3.1-Pro. Multimodal: best among open models by margins running from 0.10 to 1.9 points, behind Gemini-3.1-Pro. Strict instruction following: a genuine weakness — sixth of eight, fourth of five open models. Competition mathematics: sixth, on a 33-problem benchmark. Agentic coding, terminal, and research: competitive, frequently second among the open models, generally behind Claude-Opus-4.8 and GLM-5.2 — though it does beat Claude on SWE-Bench-Multilingual (81.67 against 77.00) and edges it on SGI-Bench (49.37 against 49.06). That is a specialist that has not given up being a generalist — which is precisely what the Chapter 8 distillation stage was for.

What the general and agentic benchmarks actually ask

Same treatment for Table 3, because two of its rows are far more informative than their numbers suggest once you know the protocol.

Worked example 30: count the wins instead of reading the prose

Prose summaries in results sections are selection functions. Do the counting yourself. Across the 25 benchmark rows in Tables 2 and 3, here is where Intern-S2-Preview-397B lands:

Check the arithmetic: 5 + 8 + 6 + 6 = 25 rows, which is Table 2's fourteen plus Table 3's eleven. Thirteen of the twenty-five — 52% — are "best overall or best open." That is a strong result and it is not a clean sweep.

And the distribution of the other twelve is informative. Of the six rows where Intern places fourth to sixth, five are agentic or strict instruction-following benchmarks — SkillsBench, SciCode, TerminalBench, WildClawBench, AdvancedIF. The single exception is HMMT-2026, competition mathematics, on 33 problems. Not one of the twelve is a knowledge, science, or perception benchmark.

Worked example 31: what "leading" means when the margin is 0.10

Two rows in the tables are claimed as leads and deserve to be read with a ruler on them. MicroVQA: Intern 68.81, Qwen3.5 68.71 — a gap of 0.10. MMMU-Pro: Intern 80.46, Qwen3.5 80.29 — a gap of 0.17.

MicroVQA "consists of 1,042 expert-curated multiple-choice questions." A gap of 0.10 percentage points on 1,042 items is:

One question. Now put an error bar on it. For a binomial proportion at p ≈ 0.69 with n = 1,042, the standard error is

The claimed lead is 0.10 points against a one-sigma sampling error of 1.43 points — roughly one fourteenth of a standard error. These two systems are, on this benchmark, indistinguishable.

The Memory Decoder result, held to the same standard

Apply the discipline to Chapter 2's headline as well. The +3.40 average on Biology-Instructions came from 21 tasks, so the per-task deltas are the sample. Fourteen positive, seven negative. The positive deltas average +6.24 and the negative ones −2.22. The largest single move, +16.01 on promoter–enhancer interaction, contributes 16.01 / 21 = 0.76 points of the 3.40 — 22% of the whole gain from one task out of twenty-one.

Drop the top three gains (+16.01, +10.57, +10.13 = 36.71) and the average gain falls from 3.40 to (71.56 − 36.71)/21 = 34.85/21 = +1.66. Still positive, still real, half the headline. The honest sentence is: the memory produces large gains on a handful of nucleotide-sequence tasks, small gains on many, and small regressions on a third of the benchmark.

A checklist for reading any model report

This chapter has been an exercise in one skill, and it generalises. Six questions, in the order they are worth asking:

Run those six over any report, including the ones you write, and most of what a results section can hide stops being hidden.

Chapter 10: Connections, Limits, and the Cheat Sheet

Intern-S2-Preview is a system report, and the right way to hold a system report in memory is not as one idea but as a set of independently reusable mechanisms plus a claim that they compose. Here is that set, each pointing at where you can go deeper.

Where every mechanism connects

The lineage this sits in

None of this appeared from nowhere. The paper's own citation trail sketches a fairly clean lineage, and knowing it tells you what to read next.

If you are building X, take Y from this paper

The most useful thing to carry away from a system report is a set of borrowable decisions. Sorted by what you might be building:

The honest limits

The paper's conclusion volunteers most of these, which is worth acknowledging: "Intern-S2-Preview remains a preview system; future work should improve reliability over longer scientific workflows, expand domain-specific memories and task environments, strengthen verifiers, and deepen integration with specialized scientific tools."

Every mechanism, and the one sentence that justifies it

A compression of the whole lesson: each design decision paired with the single reason it exists. If you can reconstruct the right-hand column from the left, you have the paper.

Six questions this paper leaves open

The most useful thing a reader can extract from a system report is the list of experiments nobody has run yet. Each of these is answerable and none of them is answered here.

A glossary of every term this lesson bolded

Every equation, on one page

The numbers worth remembering

The five sentences to carry out of this paper

If you remember nothing else, remember these. Each is a claim you can now defend from first principles.

Build the intuitions yourself — a weekend checklist

Almost none of this needs 397 billion parameters to understand. Every mechanism has a toy version.

References

1. Intern-S2-Preview Team, Shanghai AI Laboratory. "Intern-S2-Preview: Scientific Agentic Foundation Model," 2026 — arXiv:2608.13505. The paper this lesson is built on. Weights: huggingface.co/internlm/Intern-S2-Preview; agentic RL framework: github.com/InternLM/xtuner.
2. Bai, L. et al. "Intern-S1: A Scientific Multimodal Foundation Model," 2025 — arXiv:2508.15763. Reference [8]. The predecessor line; Intern-S1-Pro is the control throughout the evaluation.
3. Cao, J. et al. "Memory Decoder: A Pretrained, Plug-and-Play Memory for Large Language Models," NeurIPS 2025 — reference [12]. The mechanism of Chapter 2.
4. Cheng, G., Lyu, C., Gao, S., Zhang, W., Chen, K. "Group Entropy-Controlled Policy Optimization," 2026 — arXiv:2607.16850. Reference [21]. GEPO, from the same lab.
5. Yu, Q. et al. "DAPO: An Open-Source LLM Reinforcement Learning System at Scale," 2025 — reference [96]. The dynamic-sampling rule that filters all-identical reward groups.
6. Shao, Z. et al. "DeepSeekMath," 2024 — reference [65]. The group-relative optimisation paradigm the agentic credit assignment follows.
7. Chen, C. et al. "Accelerating Large Language Model Decoding with Speculative Sampling," 2023 — arXiv:2302.01318. Reference [14], with Leviathan et al. as [43]. The lossless verification procedure Chapter 4 relies on.
8. Aksu, T. et al. "GIFT-Eval: A Benchmark for General Time Series Forecasting Model Evaluation," 2024 — arXiv:2410.10393. Reference [4]. Where the 0.785 zero-shot MASE was measured.
9. Ansari, A. F. et al. "Chronos: Learning the Language of Time Series," TMLR 2024 — reference [5]; Woo, G. et al. (Moirai) — [85]; Shi, X. et al. (TimeMoE) — [68]. The specialised forecasters in Table 5.
10. Burgess, J. et al. "MicroVQA," 2025 — arXiv:2503.13399. Reference [11]; Bartmann, C. et al. "MolecularIQ," 2026 — arXiv:2601.15279, reference [9]. Two of the scientific benchmarks in Table 2.
11. Badertdinov, I. et al. "SWE-rebench V2," 2026 — arXiv:2602.23866, reference [6]; Bai, F. et al. "ClawGym," 2026 — arXiv:2604.26904, reference [7]. Two of the seven task sources in Table 1.
12. Chen, Z. et al. "Agent-FLAN," ACL Findings 2024 — [19]; "T-Eval," ACL 2024 — [17]; "MindSearch," 2024 — arXiv:2407.20183, [18]. The lab's own agent-learning lineage that the harness × task abstraction grew out of.
13. Achiam, J. et al. "GPT-4 Technical Report," 2023 — arXiv:2303.08774. Reference [2], cited in §1 as the general-purpose family the paper positions against.
14. Abramson, J. et al. "Accurate structure prediction of biomolecular interactions with AlphaFold 3," Nature 630, 2024 — reference [1]; Watson, J. L. et al. (RFdiffusion) — reference [82]. The two tools inside ProteinBinder-9's grading pipeline — worth knowing, because they define what a score of 4.36 on that benchmark means.
15. Aggarwal, P. and Welleck, S. "L1: Controlling How Long a Reasoning Model Thinks with Reinforcement Learning," 2025 — arXiv:2503.04697. Reference [3]. The reward-based approach to length control that §4.3.2 explicitly chooses not to use.
16. Chen, X. et al. "Do Not Think That Much for 2+3=? On the Overthinking of o1-like LLMs," 2024 — arXiv:2412.21187. Reference [16]. The named symptom that adaptive length regularisation exists to treat.
17. Cui, G. et al. "The Entropy Mechanism of Reinforcement Learning for Reasoning Language Models," 2025 — arXiv:2505.22617, reference [22]; Cheng, D. et al. "Reasoning with Exploration: An Entropy Perspective," AAAI 2026, reference [20]. The entropy literature GEPO is a response to.
18. Yang, A. et al. (Gated DeltaNet) — reference [95]. Named in the paper's FP32 precision list, which is the only place the backbone's use of gated linear attention is visible.
19. Wang, Y. et al. "SciCode," 2024 — reference [75]; "SGI-Bench," reference [90]; "ResearchClawBench," reference [91]. The three science-agentic benchmarks that set the current ceiling on end-to-end research automation.

A closing note on what this paper is evidence for

Stand back from the tables. The claim a report like this can actually support is narrower than "we built a better model," and it is more interesting.

It is evidence that a scientific specialist need not be a narrow one. The model that scores 56.92 on multi-omics sequence analysis — against a field between 4.49 and 13.87 — also scores 89.75 on MMLU-Pro and 61.56 on SWE-Bench Pro. Ten years of intuition said those trade against each other. The staged pipeline of Chapter 8 is the mechanism by which they did not, and the two-expert distillation is the specific step that made it affordable.

It is also evidence that the interesting frontier has moved from the model to the loop around it. Two of this paper's four architecture pages are about input and output paths for signals. Twenty of its thirty content pages are about rollout scheduling, numerical consistency between engines, credit assignment across a session tree, and stopping an optimiser from cheating a test harness. If you had told a researcher in 2020 that a frontier model report would spend two thirds of its length on those subjects, they would have thought you were describing a different field. They would have been right, and the field is this one now.

What to read next, in order

If this paper interested you, there is a natural reading order that builds the background it assumes rather than the background it cites.