Unified training lifted HumanEval+ performance to 24.96% pass@1

Training a language model today resembles a factory floor with several separate production lines. First, the model reads a vast corpus of text; then it learns from more specialized data; after that, it is trained to follow instructions; and only then does it receive feedback through RL. At every transition, the data, code, infrastructure, and team change. This also creates a familiar problem: while improving one skill, the model may partially forget another.

The authors of the paper Training Foundation Models with a Single Algorithm tested whether this relay race could be turned into one continuous process. Their answer is that the different stages can be framed as training on target data distributions, with examples mixed into a shared stream and a single token-weighted maximum-likelihood loss optimized across them. Even RL policy updates are reduced here to fitting response probabilities while accounting for the reward received.

What this looks like in a simple example

Imagine a small model that is first taught ordinary language, then logic puzzles, and finally programming. A conventional pipeline runs three consecutive training sessions. With Unified Training, the training server can receive examples of all three types at once, but in different proportions: a large amount of general-language data, fewer puzzles, and a small share of tasks that reward correct code.

The weight of each stream determines what the model focuses on at that moment. Earlier data does not disappear entirely, so the model is less likely to lose capabilities it has already acquired. It is less like a graduate who closes the textbook after the exam and more like a professional who continues reviewing the fundamentals while practicing.

On logic tasks, performance depended heavily on the composition of the mixture: roughly 4% to 39% pass@1 on tasks of a familiar size. Staged variants achieved between 12.24% and 24.54%. On new tasks with 12 characters, the unified approach delivered roughly 1–13%, while the selected staged variant scored 5.58%. The spread matters more here than the attractive maximum: the algorithm itself does not eliminate the need to tune data proportions.

In an experiment with a 0.76-billion-parameter model, RL on mathematics followed by code produced 23.67–24.96% pass@1 on HumanEval+ when mixed data accounted for 0.5% to 5%. Conventional sequential training achieved 22.94%. The difference is small, but it shows that retaining part of the earlier data stream can help the next adaptation stage.

Where the evidence ends

The main limitation of the study is scale. All experiments were conducted on models with fewer than one billion parameters. Moreover, for the 0.76B model, unification was used only during the final RL stage, not across the entire journey from pretraining to a finished assistant. It is therefore too early to claim that separate pipelines are no longer needed.

The researchers also found no universal mixing schedule. One ratio performs better on familiar puzzles, another on new tasks, and a third on code. In a real product, additional factors would include compute costs, data-filtering quality, asynchronous-system latency, and conflicting safety objectives.

What teams should do

Developers building their own models should treat Unified Training as a testable engineering hypothesis. There is no need to rewrite the entire stack immediately. Teams can begin with a narrow experiment: during the SFT or RL stage, retain a small share of data from the previous stage, then compare new-skill quality and the degree of forgetting on a fixed test suite.

For product teams, another idea may be more useful: the boundaries between pretraining, fine-tuning, and RL may be an organizational convenience rather than a fundamental property of learning. If the result is reproduced on larger models, a single asynchronous stream could simplify data transfer between stages and allow priorities to change faster. For now, the paper's value lies not in the promise of “one algorithm for everything,” but in the code, model, and concrete experimental setup that teams can test on their own task sets.