# Baphomet 1.1 4B: eight Qwen3.5 fine-tunes, eight numbers searched, and a gain its author calls noise

> Satyajit Ghana — Head of Engineering @ Inkers Technology
> canonical: https://ai.satyajit.si/articles/baphomet-1-1-4b
> date: 2026-11-13
> tags: model-merging, evolutionary-search, qwen, small-models, benchmarks, fine-tuning

On 13 November [CloudGoat](https://x.com/croudgoat/status/2121210210136248763) posted Baphomet 1.1 4B, a model made without training. The first post says the merge, through "constructive interference", "outperformed all expert models in fitness across 3 major benchmarks." The second names the method: "an evolutionary merging pipeline combining EvoGM and MERGE^3" over "eight major community fine-tuned models", with "the weights most heavily injected" from Qwen3.8-Distill. The third post is the one I wish more release threads had: "despite a substantial increase in cost compared to creating Baphomet 1.0 4B, the improvements in benchmark scores remained marginal and not significant."

That is an unusually honest pair of claims, and they pull in different directions. The first is about a fitness set. The second is about a held-out test. Most of this article is about the distance between those two, because it is the same distance every evolutionary merge has to cross, and this one is small and public enough to measure it end to end.

<Figure
  src="https://media.thesatyajit.com/ai/articles/baphomet-1-1-4b/fig1.jpg?v=b7698fbecc072f5b"
  alt="Four horizontal bar panels titled Fitness (mean of 3), MMLU-Pro, GPQA and BFCL, on the 110-item fitness set with a 4,096-token cap. Baphomet-1.1-4B leads the fitness panel at 76.4, then EvoGM round-1 winner 72.2, Qwen3.8-Distill 68.6, DeepSeek-V4-Pro-distill 66.4, Qwopus-v3 61.9, Baphomet-1.0-4B 60.3, Uniform average 59.2, Qwopus-Coder 56.4, NeoHorse 51.1, T-Max 51.1, AREX-Turbo 48.1 and Agents-A1 42.2. On BFCL, AREX-Turbo has the longest bar at 95.0 against Baphomet-1.1's 92.5."
  caption="The chart from the launch post. Its own subtitle says the right thing: 1.1 was chosen on these 110 items, so its score is optimistic. Read the BFCL column too: AREX-Turbo is at 95.0, above the merge's 92.5 (CloudGoat's post on X, image 1)."
/>

I read the [model card](https://huggingface.co/CloudGoat/Baphomet-1.1-4B), the thread, the [EvoGM source](https://github.com/JiangTao97/evogm) and CloudGoat's [GoatMerge](https://github.com/CroudGoat/GoatMerge), the papers the pipeline is built from, and the safetensors header of the merge, its base and all eight parents, by HTTP range request. I did not download a weight or run the model.

<ModelCard repo="CloudGoat/Baphomet-1.1-4B" />

## Eight deltas off one Qwen3.5-4B

Model merging in this form needs a shared ancestor. All eight parents are published as fine-tunes of [Qwen/Qwen3.5-4B](https://huggingface.co/Qwen/Qwen3.5-4B), so each one can be written as the base plus a difference, its **task vector**:

$$
\tau_i = W_i - W_{\text{base}}, \qquad W_{\text{merged}} = W_{\text{base}} + \sum_{i=1}^{8} \lambda_i\, \tau_i
$$

The card's coefficient table and the second image in the thread give the eight $\lambda_i$, and the Hub metadata gives what each parent is:

| # | Parent | What it is, per its own card | Declared base | $\lambda$ |
|:-:|:--|:--|:--|--:|
| 1 | `InternScience/Agents-A1-4B` | long-horizon agent, the 4B sibling of [Agents-A1](/articles/agents-a1) | none declared | 0.011589 |
| 2 | `Jackrong/DeepSeek-V4-Pro-Qwen3.5-4B` | SFT on about 250,000 DeepSeek-V4-Pro math and STEM samples | `unsloth/Qwen3.5-4B` | 0.203923 |
| 3 | `empero-ai/Qwen3.8-4B-Distill` | full fine-tune on about 45,000 traces from Qwen3.8 2.4T A95B | `Qwen/Qwen3.5-4B` | 0.590137 |
| 4 | `Jackrong/Qwopus3.5-4B-Coder` | coding agent, reconstructed Claude reasoning traces | `Qwen/Qwen3.5-4B` | 0.001337 |
| 5 | `Jackrong/Qwopus3.5-4B-v3` | reasoning distillation plus tool-calling RL | `unsloth/Qwen3.5-4B` | 0.297193 |
| 6 | `BAAI/AREX-Turbo` | deep-research agent | `Qwen/Qwen3.5-4B` | 0.032303 |
| 7 | `TokenRhythm/NeoHorse-1-4B` | agentic post-training, repackaged text-only | `Qwen/Qwen3.5-4B` | 0.002979 |
| 8 | `allenai/tmax-4b` | terminal agent, 200 steps of DPPO RL | `Qwen/Qwen3.5-4B` | −0.000742 |

Two parents declare `unsloth/Qwen3.5-4B` instead of Qwen's repo. That is the same model: the Hub lists the same LFS sha256 for both shards of both repos (`26a93f06…` and `cb544bd9…`). GoatMerge's provenance file for Baphomet 1.0 pins the base snapshot `851bf6e`, which is the current head of `Qwen/Qwen3.5-4B`. Agents-A1-4B declares no base at all.

Headers can't prove ancestry; only weight values could, and I didn't read those. What headers can prove is that the subtraction is well defined. On the range-read headers I count 738 tensors and 4,659,865,088 parameters in the base. Baphomet 1.1 has the same 738 names, shapes, dtypes and byte offsets in the same two shards, which is what the card says: a file you can drop in where the base was. The parents differ in what they ship:

- DeepSeek-V4-Pro, both Qwopus models and Qwen3.8-Distill have all 738 tensors with matching shapes.
- Agents-A1-4B and AREX-Turbo are missing the 15 multi-token-prediction tensors (120,599,552 parameters), so their task vector is zero there, as the card says.
- NeoHorse and tmax have only the 426 language-model tensors: no MTP, and none of the 297 vision tensors (333,514,240 parameters). NeoHorse's keys start `model.` instead of `model.language_model.`; its own header metadata says the values are unchanged by that repackaging, and the card says the keys were remapped before subtraction.
- One detail the card does not mention: the base stores 48 tensors in fp32, the `A_log` and `norm.weight` of each of the 24 linear-attention layers. Qwen3.8-Distill, Agents-A1, AREX, NeoHorse and tmax store those 48 in bf16. Their task vector on those tensors therefore includes the rounding of an fp32 value to bf16, a relative error up to about $2^{-8}$, whether or not training touched them. At $\lambda = 0.59$ that is far too small to matter, but it means "tensors where a donor equals the base exactly are skipped" would rarely, if ever, skip those.

A smaller point about the predecessor. Baphomet 1.0's card says that with `normalize: true, rescale: true` enabled, "normalized coefficients are applied." GoatMerge's `LinearKernel` adds $\sum w_i \tau_i$ to the base and never reads `normalize` (only the GTA path does), so 1.0 really added 0.1375 of every vector, weights summing to $0.1375 \times 8 = 1.10$, which is what the 1.1 card and the thread's λ chart say. The 1.0 card also cites arXiv 2603.09938 as "hitit et al."; that number is a survey by other authors, and the 1.1 card has the right number, [2511.21437](https://arxiv.org/abs/2511.21437), though under an author list (Hitit, Sankar, Kim, Risteski, Elgohary) that is not the one arXiv gives (Hitit, Girrbach, Akata).

## Why adding fine-tunes can work at all

Fine-tuning moves a model a short distance from its base. Around the base, loss is close to quadratic, so for any task $t$ with gradient $g_t$ and curvature $H_t$:

$$
L_t(W_{\text{base}} + \Delta) \approx L_t(W_{\text{base}}) + g_t^\top \Delta + \tfrac12\, \Delta^\top H_t\, \Delta
$$

Put $\Delta = \sum_i \lambda_i \tau_i$ into that and the quadratic term splits into each parent's own term plus cross terms $\lambda_i \lambda_j\, \tau_i^\top H_t\, \tau_j$. Those cross terms are the **interference**. If parent $i$'s change sits in directions task $t$ doesn't care about, or parents push the same directions the same way, the merge keeps what each parent learned and adds up. That is constructive interference: a merged model that beats each of its parents. If two parents push the same weights in opposite directions, they cancel, and the merge can land worse than both.

Labs use the same arithmetic inside their own pipelines. Holo4 folds two RL-trained LoRA experts back into its fine-tuned model with equal weight ([Holo4: open computer-use weights, graded on the lab's own benchmarks](/articles/holo4)), and IQuest-Q1 ends its post-training with a cross-stage residual merge ([IQuest-Q1](/articles/iquest-q1)). There the experts come from one training run and were built to be merged. Baphomet's eight were not: they come from eight teams with eight data mixes, which is the "in-the-wild" case. For weight edits that are not fine-tunes at all, see [Deletion Tuning and closed-form edits](/articles/weight-edits-without-finetuning).

The [in-the-wild merging study](https://arxiv.org/abs/2511.21437) (Hitit, Girrbach and Akata) is the paper both Baphomet cards lean on. It merged twelve public fine-tunes per base across four models and sixteen benchmarks, and found that plain task arithmetic was the only one of six methods that consistently produced models beating every merged checkpoint, with gains it calls limited. It also measured why: on Qwen3 4B, the pairwise cosine between task vectors of twelve unrelated fine-tunes is never above 0.020.

<Figure
  src="https://media.thesatyajit.com/ai/articles/baphomet-1-1-4b/fig6.png?v=617b885362901e76"
  alt="A 12 by 12 heatmap of pairwise cosine similarities between task vectors of fine-tuned Qwen3 4B variants. The diagonal is 1.000. Every off-diagonal cell is between -0.003 and 0.020, nearly white on a red-blue scale from -1 to 1."
  caption="Twelve public Qwen3 4B fine-tunes, as task vectors: almost exactly orthogonal to each other in weight space. That is the condition under which a plain sum keeps what each parent learned (A Systematic Study of In-the-Wild Model Merging, Figure 21)."
/>

Near-orthogonal over four billion weights is a weak statement, though. Two task vectors can be orthogonal in total and still fight over the few weights a particular benchmark depends on. The widget below shrinks the problem to 24 weights and two tasks so you can watch it happen.

<InterferenceLab />

Run the presets. With no shared weights, the plain sum ($\lambda = 1, 1$) gets both tasks close to perfect while each parent is near the base on the other's task: that is constructive interference in its cleanest form. Move half of B's support onto A's with the weights agreeing, and the sum overshoots the shared weights, so averaging ($\lambda = 0.5, 0.5$) beats it. Flip the shared weights to conflict and no setting of the two λ recovers both tasks, because the parents want the same coordinates in opposite directions. Density is the other family of fixes: TIES and DARE keep only the largest entries of each task vector, which removes the small drift every fine-tune leaves on weights it wasn't aiming at. In the toy, trimming to 40% lifts the plain sum from 97.9 to 99.3. Baphomet uses none of this. Its merge is `linear` with density 1.0, so all eight vectors go in whole, and the only thing searched is how much of each.

## Eight numbers, not a recipe per layer

"Evolutionary model merging" covers search spaces of very different sizes, and this is the first thing to pin down when someone uses the phrase.

[Akiba and colleagues](https://arxiv.org/abs/2403.13187) at Sakana, who named the idea, searched two spaces. In parameter space they used TIES-Merging with DARE and set up a sparsification density and a mixing weight for every source model at each layer, embeddings included. (The model they report used the simplest version, two DARE-TIES parameters per source model, because the finer split did not help on their small dataset.) In data-flow space they kept the weights fixed and evolved the path a token takes through layers drawn from several models: an indicator per slot saying whether a layer is used, plus a scaling matrix for the hop between layers. Their DFS run had $T = 192$ slots, a search space of $2^{192}$ paths before the scales.

<Figure
  src="https://media.thesatyajit.com/ai/articles/baphomet-1-1-4b/fig3.png?v=ea6ab55d34ed9383"
  alt="Two source models drawn as stacks of three blue and three red layer blocks, with accuracies 0.18 and 0.31 on Japanese math questions. Three merged models on the right: one merged in parameter space with blended purple layers at 0.52, one merged in data-flow space that stacks blue and red layers at 0.36, and one merged in both at 0.56."
  caption="The original evolutionary merge: mix the weights in each layer (PS), reorder which layers a token passes through (DFS), or both. Baphomet does a much smaller version of the first (Evolutionary Optimization of Model Merging Recipes, Figure 1)."
/>

Baphomet's search space is eight real numbers. One $\lambda_i \in [-1, 1]$ per parent, the same for every layer and every tensor: no per-layer weights, no densities, no layer routing. That is the formulation EvoGM's paper uses too ($\boldsymbol\lambda \in \mathbb{R}^N$, "the dimensionality of the optimization space corresponds directly to the number of expert models"). It is a sensible choice for a hobbyist budget. A per-layer recipe for eight parents over 32 layers is 256 weights before densities, and a fitness evaluation costs minutes of GPU time. It also limits what the search can find. Qwen3.8-Distill's change to layer 3 and to layer 30 get the same 0.59.

## EvoGM: a generator that learns where the winners are

EvoGM ([Jiang et al., ICML 2026](https://arxiv.org/abs/2605.29295)) replaces the hand-written mutation and crossover of a classic evolutionary algorithm with two small networks trained on the search's own history. Reading the paper alongside `fusion_bench/method/evogm.py`, the loop is:

1. **Seed the population.** One one-hot vector per parent ($\lambda_i = 1$, all others 0), one uniform average ($\lambda_i = 1/N$), and uniform random vectors in $[-1, 1]$ to fill it. The paper sets the population to $P = 2N$. A one-hot candidate is $W_{\text{base}} + \tau_i = W_i$: the parent itself. That is most likely why every parent appears as a bar on the fitness chart above: in EvoGM the parents are measured as candidates.
2. **Split winners from losers.** Sort everything evaluated so far by fitness; the top 30% are winners (`winner_portion: 0.3`).
3. **Train two generators.** Each is an MLP, $N \to 128 \to 256 \to 256 \to 256 \to 128 \to N$ with a `tanh` output, so a generated λ stays in $[-1, 1]$. $G_{-\to+}$ maps losers toward winners and $G_{+\to-}$ the other way. The loss is a cycle term weighted 100 (a loser sent to the winners and back should come back unchanged, and the same the other way), plus an optimisation term that pulls $G_{-\to+}$ of every loser toward the centroid of the winners.
4. **Generate and select.** Apply $G_{-\to+}$ to the current population, evaluate the new candidates, keep the best $P$.
5. **Shift the basis.** At the end of a round, the top $N$ candidates become the new "experts": their merged task vectors replace the original eight, and the next round searches mixtures of those. In the code this is a matrix product on the coefficient basis rather than new weights on disk, so the final λ is still expressed over the eight original parents.

<Figure
  src="https://media.thesatyajit.com/ai/articles/baphomet-1-1-4b/fig4.png?v=200f69a426b56296"
  alt="EvoGM overview. Top left, N experts as vectors from a pretrained point combine into a merged point. Population initialization with one-hot, average and random coefficient vectors, population size 2N, evaluated on a validation set into a history. Generative evolution and selection: train a dual generator, generate candidates with the loser-to-winner generator, evaluate, select the top P. Evolving expert basis: select top N and recompute task vectors for the next round. Right panel: winner-loser pairing by sorting the history and taking a Cartesian product, and two five-layer MLP generators mapping losers to winners and winners to losers."
  caption="EvoGM's loop: seed with the parents, the average and random mixes; learn a loser-to-winner map from the history; generate, evaluate, select; every round, promote the best mixes to be the new basis (EvoGM paper, Figure 2)."
/>

The method is cleverer than a random mutation, but it is still a selection procedure: it proposes λ, measures fitness on a small set, and keeps what measured best. EvoGM's own tables show what that costs. In its single-task Qwen2.5-1.5B experiment, EvoGM has the best test score on 5 of 8 tasks, but its MMLU-Pro row is 0.429 on the validation split it selected on and 0.224 on the test, below the single best expert's 0.232. On that task the search won on validation, and the test kept a fraction of it.

## The fitness function

Everything hangs on what "fitness" measured, and the card is specific:

- **110 items:** 40 from MMLU-Pro, 30 from GPQA, 40 from BFCL non-live.
- **Per-task accuracy, then the mean of the three.** A GPQA item is worth $1/90$ of the score and an MMLU-Pro item $1/120$.
- **Thinking mode with a 4,096-token cap, and a truncated answer counts as wrong.**

That last rule matters more than it looks. A 4B model in thinking mode often runs past 4,096 tokens on a GPQA question. Under this fitness function, a candidate that thinks less and finishes is rewarded twice: for getting answers it would have got anyway, and for not being cut off. The search has no way to separate "reasons better" from "stops sooner." Keep that in mind for the held-out numbers.

On those 110 items the post's chart puts Baphomet 1.1 at 76.4, which is 32 of 40 MMLU-Pro, 17 of 30 GPQA and 37 of 40 BFCL. The best parent, Qwen3.8-Distill, is at 68.6. Baphomet 1.0 is at 60.3, below Qwopus-v3 and above the uniform 1/8 average at 59.2. So on the fitness set the merge beats every parent on the mean, by 7.8 points over the best one. It doesn't beat every parent on every benchmark: on BFCL, AREX-Turbo is at 95.0 and the merge at 92.5, tied with Qwen3.8-Distill and Qwopus-v3.

<Figure
  src="https://media.thesatyajit.com/ai/articles/baphomet-1-1-4b/fig2.jpg?v=6aed54383b2a47f1"
  alt="Grouped bar chart of the coefficient lambda for each of the eight parents, for Baphomet-1.1-4B (sum 1.14), the EvoGM round-1 winner (sum 1.05) and Baphomet-1.0-4B (sum 1.10, 0.1375 for every parent). Baphomet-1.1 puts 0.59 on Qwen3.8-Distill, 0.30 on Qwopus-v3 and 0.20 on DeepSeek-V4-Pro-distill, near zero elsewhere. The round-1 winner has 0.63, 0.23 and 0.10 on the same three."
  caption="Where the weight went. The search put 0.59 on Qwen3.8-Distill, 0.30 on Qwopus-v3 and 0.20 on DeepSeek-V4-Pro and left the five agent fine-tunes near zero (CloudGoat's post on X, image 2)."
/>

The λ chart reads differently once you know where the parents sit on fitness. The three parents that got weight are the three best parents on the fitness set (68.6, 66.4 and 61.9). The five agent and coding fine-tunes, which score 42.2 to 56.4, got almost nothing: their summed λ is 0.047. Those three heavy coefficients add to 1.091, which is 95.8% of the total 1.139. The search mostly learned "use the three reasoning distills, Qwen3.8 most." A person reading the parent scores would have guessed the direction. The search found the proportions.

The sum is past 1, too. A merge with $\sum \lambda = 1.14$ moves further from the base than any parent does along the shared directions. With near-orthogonal task vectors that is not strange (each parent keeps most of its own displacement), and the search had $[-1, 1]$ per coordinate to play with.

## The MERGE^3 part: estimating fitness from 40 items

Round 1 scored 40 candidates on all 110 items. Rounds 2 and 3 scored 64 more candidates on a 40-item subset and estimated the rest. This is where the thread's "MERGE^3" comes in, although the card itself only says "IRT-accelerated."

[MERGE^3](https://arxiv.org/abs/2502.10436) (Mencattini et al.) uses **item response theory**, the model behind adaptive tests like the GRE. Each item $i$ has a discrimination $\alpha_i$ and a difficulty $\beta_i$, each model $m$ has an ability $\gamma_m$, and the chance of a correct answer is

$$
P(Y_{im} = 1) = \frac{1}{1 + e^{-\alpha_i^\top \gamma_m + \beta_i}}
$$

Fit the item parameters once, and a model's score on all of $D$ can be estimated from its answers on a subset $\bar D$: count the items it actually answered, and fill in the rest with predicted probabilities. MERGE^3 adds one assumption for merging, that a merged model's ability is the same linear mix of its parents' abilities, $\gamma_{\tilde m} = \sum_i \lambda_i \gamma_i$, so it only has to fit λ on the subset rather than a new ability from scratch. The paper's subset is a uniform random sample (it found random as good as cleverer choices), its item parameters come from public leaderboard results, and its headline is a 50-fold cut in fitness FLOPs against Akiba's 1,000-trial run on a single GPU.

<Figure
  src="https://media.thesatyajit.com/ai/articles/baphomet-1-1-4b/fig5.png?v=dbfe5dfc29e04563"
  alt="MERGE^3 diagram. Left, Extract and Estimate: a dataset is sampled into a reduced set, and each endpoint model is evaluated on the full dataset to fit IRT ability parameters gamma 1 and gamma 2. Right, Evolve: the two endpoint models are merged repeatedly in an Evo Merge loop scored by a performance estimator that uses gamma 1, gamma 2 and the reduced set, producing the merged model."
  caption="MERGE^3: shrink the fitness set, fit each parent's ability with IRT on the full set once, then score merges on the small set with an estimator that fills in the rest (MERGE^3 paper, Figure 2)."
/>

Baphomet's version, as the card describes it, is a cousin rather than a copy. Its 40 items were "chosen for Fisher information", the items that best separate candidates near the current ability, rather than sampled at random. It uses a 2PL model (a scalar ability, one discrimination and one difficulty per item) rather than MERGE^3's multidimensional one, and the card does not say whether it uses the linear-ability assumption. It also does not say where the item parameters came from. The obvious source is round 1 itself, 40 candidates times 110 items of right-or-wrong, but that is my guess. Candidates that looked weak were stopped early, and the best estimates were re-scored on all 110 before the winner was picked, so the 0.764 is a real 110-item score, not an estimate.

The cost arithmetic is in the card. Round 1 took 7.1 kernel-hours for 40 candidates, or 10.65 minutes per full 110-item evaluation on Kaggle's T4×2. Rounds 2 and 3 took 6.5 hours for 64 candidates: 6.09 minutes each, and that figure already includes the early stops and the full re-scores. Scoring those 64 the round-1 way would have taken about 11.4 hours. So the IRT shortcut bought roughly 1.75x per candidate in practice, against the paper's 50x. That isn't a failing of the port. MERGE^3's 50x is against a 1,069-item fitness set and 1,000 trials; when the full set is only 110 items there isn't a 50x to win.

## What the search bought, in fitness

The card gives four fitness numbers on the 110 items: Baphomet 1.0's coefficients at 0.603, the best of round 1 at 0.722, the best of round 2 at 0.733, and the final 1.1 at 0.764. The widget below puts those in a strip and, above them, simulates a search like this one to show what a maximum over many noisy measurements does.

<CurseSim />

The simulation is invented: a search whose candidates get slightly better on average as it goes, each scored on $n$ items with honest binomial noise. Only the sampling arithmetic is real. At 110 items and 104 candidates, roughly Baphomet's 40 plus 64, the pick's measured fitness lands several points above its true accuracy on most seeds, and the pick is often not the truly best candidate. That gap is the **winner's curse**, and it does not need any overfitting in the usual sense. Taking the maximum of a hundred noisy numbers selects for the ones whose noise came up positive.

The card says this itself in its caveats: λ "was chosen as the best of more than 100 candidates on a 110-item fitness set. The fitness score (0.764) is therefore optimistic." I'll add one thing it does not say. On 110 items, the standard error of a single score near 0.76 is about 4 points. The jumps from round 1 to round 2 (0.722 to 0.733) and from round 2 to the final (0.733 to 0.764) are each smaller than that.

## The held-out test: 180 items, three models

The card's real evaluation is a separate 180-item test, "disjoint from" the fitness items: 80 MMLU-Pro, 50 GPQA-Diamond, 50 BFCL non-live AST, thinking mode with an 8,192-token cap, one sample per item at temperature 0.6, truncation counted wrong.

| Model | Overall | MMLU-Pro | GPQA-Diamond | BFCL non-live | Truncated | Mean output tokens |
|:--|:-:|:-:|:-:|:-:|:-:|:-:|
| Qwen3.5-4B | 70.0% | 71.3% | 42.0% | 96.0% | 22.8% | 3,983 |
| Baphomet-1.0-4B | 77.8% | 77.5% | 58.0% | 98.0% | 15.6% | 3,180 |
| Baphomet-1.1-4B | 79.4% | 81.2% | 62.0% | 94.0% | 10.0% | 1,834 |

Turned back into items, which is what the percentages are:

| Model | MMLU-Pro (of 80) | GPQA (of 50) | BFCL (of 50) | Total (of 180) | Truncated |
|:--|:-:|:-:|:-:|:-:|:-:|
| Qwen3.5-4B | 57 | 21 | 48 | 126 | 41 |
| Baphomet-1.0-4B | 62 | 29 | 49 | 140 | 28 |
| Baphomet-1.1-4B | 65 | 31 | 47 | 143 | 18 |

Every percentage in the card's table is consistent with whole items, and the overall column is pooled over items rather than the mean of the three benchmarks the fitness function used. Against 1.0, the merge is +3 items on MMLU-Pro, +2 on GPQA and −2 on BFCL: three items net, 1.7 points. One item is 0.56 points.

The card ran exact McNemar tests, which only look at items where the two models disagree. Against 1.0, 1.1 was right and 1.0 wrong on 10 items, and the reverse on 7: $p = 0.63$. I get the same $p$ from the binomial: 7 or fewer of 17 under a fair coin, doubled, is 0.629. To reach $p < 0.05$ with 17 disagreements, the split would have had to be 13 to 4, a net of 9 items, or 5 points. Against the base it is 20 to 3, $p$ well under 0.001 (I get 0.00049). So the merge is clearly better than Qwen3.5-4B, and statistically indistinguishable from the cheaper 1.0. The thread said "marginal and not significant"; that is exactly what the numbers say.

Now the truncation column. Assuming, as the card states, that every truncated answer is wrong, accuracy among the answers that finished is 126 of 139 for the base (90.6%), 140 of 152 for 1.0 (92.1%) and 143 of 162 for 1.1 (88.3%). Baphomet 1.1 finishes 10 more answers than 1.0 and gets 3 more right, so of the ten extra answers it finished, seven are wrong. These are not paired (the card does not say which items each model ran out of room on), so they do not prove that 1.1 reasons no better on the same items. They are what you would see if the main thing that changed is length: 1,834 output tokens on average, against 3,180. Some of that brevity may be inherited rather than selected: Qwopus-v3, at λ 0.30, advertises "shorter, more stable reasoning paths" on its own card.

The cap also explains the fitness-versus-test gap for 1.0. On the fitness set, at 4,096 tokens, 1.0's GPQA is 23.3%. On the test, at 8,192, it is 58.0%. Different items, but a jump that size looks like a model that thinks long being allowed to finish. A fitness function with a 4,096-token cap and truncation scored as wrong favours the λ that thinks least. The 16.1-point fitness gap between 1.1 and 1.0 shrinks to 1.7 on the test, and three things changed at once: the cap doubled, the winner's-curse optimism fell away, and the items and the scoring (per-task mean against pooled items) changed. I can't apportion the shrink between them, but the cap is the one the search could exploit.

## Did it beat its parents?

That is the claim in the first post, and the answer depends on which set.

On the 110-item fitness set: yes on the mean, 76.4 against 68.6 for the best parent, and no on BFCL. It is also the set the λ were selected on, among more than 100 candidates, and the winner's curse argument above applies to the merge but not to the parents, which were each measured once.

On the 180-item test: unknown. The test table has three rows, the base, 1.0 and 1.1. None of the eight parents was run on it. The held-out claim that would settle "constructive interference" (the merge beating Qwen3.8-Distill on items neither was chosen on) is not in the release. Given that the merge is 59% Qwen3.8-Distill's task vector and that Qwen3.8-Distill was 8.3 points ahead of 1.0 on fitness, it is entirely possible that Qwen3.8-Distill alone would score near 79.4 on the test. I can't tell, and neither can the card.

The overfitting question for evolutionary merges has two layers, and the card handles one. **Item overlap**: the fitness and test items are disjoint, per the card; I can't check it, since neither item list nor the EvoGM port is published (CloudGoat's GitHub has GoatMerge and a CABS fork for mergekit, nothing else on this). **Benchmark overlap**: the fitness set and the test are the same three benchmarks, same formats, same cap rule at different lengths. The search tuned eight numbers to do well on MMLU-Pro, GPQA and BFCL, and the release measures MMLU-Pro, GPQA and BFCL. The card says "only the three benchmarks above were measured." Anything outside them, including the agent work five of the parents were trained for, is unmeasured, and the λ near zero on those five suggests their skills are mostly gone.

Akiba's original run did better on this point than most follow-ups. It searched on 1,069 translated GSM8K items and tested on the 250 MGSM-JA items, then also ran a Japanese language benchmark suite the search never saw. Baphomet does the first half.

## A negative result, published as one

The useful result here is negative, and the author published it as one, which is worth more than another merge that "beats everything." An eight-scalar evolutionary search, done carefully, with held-out items, a paired test and the winner's curse stated in the card, moved a 4B merge from 77.8% to 79.4% on 180 items, a difference a fair coin produces 63% of the time, for 13.7 kernel-hours of Kaggle T4×2 on top of 1.0. The change you can measure is length: 1.1 writes a little over half as much as 1.0 and is cut off less often, under a fitness function whose 4,096-token cap rewarded exactly that.

If you want a Qwen3.5-4B to run, 1.1 is a reasonable pick over 1.0 for that reason alone: the same accuracy on this test at 58% of the output tokens. Treat its agent and tool behaviour as unknown; BFCL went down by two items and nothing agentic was run. If you are thinking of running an evolutionary merge on a hobby budget, the lessons are in the card's own caveats. A 110-item fitness set cannot resolve the differences a search over 100 candidates produces. Put the parents on the held-out test, or "beats its parents" stays a fitness-set claim. Score the cap you will deploy at, or the search will optimise length. And the item that would most change my reading of this release is a single extra row: Qwen3.8-4B-Distill on the 180-item test.

<Callout type="note">
How I checked. Read, not run: the thread through the fxtwitter API; the 1.1 and 1.0 model cards and `goatmerge.json`; the Hub metadata of the base and all eight parents, including LFS hashes for `unsloth/Qwen3.5-4B` and `Qwen/Qwen3.5-4B`; the safetensors headers of the base, 1.1 and every parent by HTTP range request (no tensor bytes); `JiangTao97/evogm` at `bb7b00a` (`evogm.py`, its configs) and `CroudGoat/GoatMerge` at `44ba5aa`, 9 November, a month after 1.0 was built (`merge.py`, `kernels.py`, `consensus.py`); the EvoGM, MERGE^3, Akiba and in-the-wild papers. Computed: the item counts, accuracy among finished answers, McNemar and binomial p-values, the λ sums, the per-candidate cost and the standard errors. The two widgets are toys with seeded synthetic numbers; neither is Baphomet's data except the strip of four fitness points. I did not download weights, compare tensor values, or run any model.
</Callout>