Model merge selection

A platform hosts fine-tunes of one base model. Teams and outside vendors ship weight deltas, some full fine-tunes, some adapter deltas. Memory and latency budgets mean you serve a small number of merged models rather than every contribution separately, so you must decide which contributions to combine.

What you receive is the base checkpoint, each delta, and a one-line statement of intent. What you do not receive, and cannot ask for under the contracts, is any contributor's training data or evaluation set. Your own suite is general and blind to what each contribution was for. Producing a merge is cheap. Evaluating one is not, and the number of candidate subsets is exponential, so you can score a handful. The predictor has to run on weights alone, before you spend an evaluation.

The trap is that parameter space does not map cleanly onto function space. Two deltas with near-zero cosine similarity can write to the same computation through different coordinates and destroy each other. Two with heavy overlap can compose fine because they encode the same capability twice. Networks carry symmetries that leave the function fixed and move the weights: permutation of hidden units, a scaling of one layer paired with its inverse in the next, and reparameterization of a low-rank adapter. A score that changes under any of those is measuring coordinates, not models.

Hand in the predictor: what it consumes, what it returns, and its cost in the number of contributions and in parameters. Hand in the invariance argument over the symmetries named above, worked rather than asserted. Hand in the admission rule that turns a score into accept, downweight or reject, and the experiment that would show the predictor tracks function-space interference rather than delta magnitude. State the case where it reports safe and the merge is broken.

Ties break toward a predictor that refuses when the deltas fall outside its stated domain, over one that always returns a number.