Olmix：大規模言語モデル開発におけるデータ混合フレームワーク
Allen AI は、大規模言語モデル開発におけるデータミキシングの複雑さを解決し、計算コストを削減する「Olmix」フレームワークを発表した。
キーポイント
データミキシングの課題と非効率性の解消
既存のアプローチは設定に関する指針が不足しており、データセットの変更ごとに再計算が必要でコストがかかるという問題点を解決する。
実証ベースのデフォルト設定と混合再利用技術
Olmix は経験則に基づくデフォルト設定を提供し、データが変化する際にも効率的にミキシングを更新できる「混合再利用」手法を導入している。
性能向上とデータ効率の劇的な改善
実験結果として、従来の手法と比較して下流タスクでのパフォーマンスが 12% 向上し、データ効率が 3 倍に改善されたことが示されている。
影響分析・編集コメントを表示
影響分析
本発表は、LLM 開発における「データエンジニアリング」の標準化に寄与する重要なステップです。特に、データセットの頻繁な更新やフィルタリングが行われる現代の開発環境において、ミキシング戦略を自動化・最適化する手法を提供することで、研究開発のスピードとリソース効率を大幅に向上させる可能性があります。
編集コメント
データミキシングはモデル性能に直結するが、その最適化プロセスは長年「ブラックボックス」として扱われてきました。Olmix はこの領域に体系的なアプローチと実証された効率化をもたらす画期的なツールと言えます。
2026 年 2 月 13 日
Ai2
現代の言語モデルは、ウェブテキスト、コード、PDF、数学データなど、多種多様なデータを対象にトレーニングされます。これらのソースをどのように組み合わせるかは、最終的なモデルの品質にとって極めて重要ですが、最適なレシピを見つけることは、LM（Language Model：大規模言語モデル）構築における最も複雑な部分の一つです。万能な公式は存在せず、「最良」の混合比率は、実務者がしばしば推測に頼らざるを得ない dozens の設計選択に依存します。実際には、多くの実務者が最終的なパフォーマンスを損なっていないかを確認する手段が乏しいまま、手動で混合比率を調整することに頼ってしまいます。
さらに状況を複雑にするのは、モデル開発の過程を通じてトレーニングデータが静的ではないという点です。最終モデルのトレーニング開始の数週間から数ヶ月前に至るまで、新しいデータセットを追加し、低品質なものを削除し、フィルタリングを行い、再編成を行う作業が常に行われます。これが LM をトレーニングする現実です。データが変更されるたびに、混合比率を最初から考え直す必要がある可能性があります。
本日公開する Olmix は、これらの課題に対する私たちの回答です。これは、LM が実際に構築されるプロセスに即したデータ混合のためのフレームワークであり、実務で繰り返し遭遇する 2 つの問題に対処しています：
- データミキシング手法をどのように設定するかについて、驚くほど指針が少ない。既存のアプローチは、モデルサイズや実験回数、使用するモデリング技術などについて異なる選択を行っており、これらの選択はしばしば互いに矛盾したり、文献において具体的に正当化されたりしていない。そのため、実務者は自分自身で考えなければならない。
- データセットが変更されるたびにデータミックスを最初から再計算すると、すぐにコストが高騰する。トレーニングコーパスが数十回の反復を通じて進化していく中で、ミキシングはあらゆる修正に対する負担となる可能性がある。
Olmix は経験的に裏付けられたデフォルト値を提供し、設定選択について推測する必要をなくすとともに、LM 開発の過程でデータが進化する際に効率的にミックスを更新するためのミクスチャー再利用手法を導入する。私たちの実験では、これにより、下流タスクにおいて 12% 向上し、全くミキシングを行わない場合と比較して 3 倍のデータ効率を実現した。
データミキシングで実際に重要なのは何か
良いデータミックスを見つけるための標準的なアプローチは、異なる混合物上で多数の小さなプロキシモデル（「スウォーム」と呼ぶ）をトレーニングし、そのパフォーマンスを確認した後、回帰モデルを用いてフルスケールモデルに対してどの混合物が最も効果的かを予測することである。（私たちの論文ではこれを「オフラインミキシングスキーマ」と呼んでいる。）これは理論的には単純である。しかし実際には、開発全体を通じてこれをどのように設定して実行するかについて、ほとんど合意がない。
Olmix は、データミキシングを現代の LM（大規模言語モデル）開発に追いつける反復可能なワークフローとして位置づけるアイデアを中心に構築されています。このフレームワークには 2 つの主要なコンポーネントがあります。1 つ目は OlmixBase で、これは研究で検証された設定選択肢を用いてオフラインスキーマを具体化するデータミキシング手法であり、開発初期段階において強力なスタートとなる混合データを生成します。2 つ目は、LM 開発の残りの期間を通じてデータが変化する際に、毎回ゼロから再計算することなく効率的にその混合を更新するための一連の mixture reuse（混合再利用） techniques（技術手法）です。
OlmixBase: ミキシング手法の設定における推測を排除する
私たちは、オフラインスキーマに従ってデータミキシング手法を設定する際に実務者が通常直面する疑問に答える包括的な研究を行いました。具体的には、「プロキシモデルはどれほど小さくできるか？」「必要なプロキシ実行回数はどれくらいか？」「どのような回帰モデルを使用すべきか？」といった問いです。この研究から得られた知見が、私たちが推奨するデータミキシング手法である OlmixBase の基礎となっています。
本研究では、キュレーションされたウェブテキストコーパスである DCLM データを用いて 10 億パラメータのモデルを訓練し、これを数学、コード、常識 QA を含む 52 の下流タスクにわたって評価しました。性能は、bits-per-byte（BPB）または UTF-8 バイト単位で正規化された正解の長さに対する負の対数尤度によって測定されました。
以下に、私たちが発見したいくつかの結果を示します：
プロキシモデル：小さすぎず、大きすぎない。 約15Mパラメータ以上のプロキシは、1Bパラメータのターゲットモデルと強い順位相関（ρ > 0.89）を示します。これより大幅に小さいプロキシは信頼性が低下し、1Mパラメータモデルでは ρ = 0.73 に留まり、確信を持って混合決定を下すにはノイズが多すぎます。特筆すべきは、RegMix が1Mのプロキシ構成を推奨している一方で、彼らの公開コードを検証すると、その実装は実際には約15Mに近いものであることが明らかになりました—これは私たちの結果が示す通り、適切なプロキシサイズです。計算リソースを節約するために極端に小さなプロキシを使用してきた場合、その節約の代償としてノイズの多い結果を得ている可能性があります。
混合コストはドメイン数に対して線形にスケーリングします。 既存の方法では20から500を超えるまでの様々な数のプロキシ実行を行いますが、ドメインセットのサイズに応じてどのようにスケーリングすべきかを説明しているものはほとんどありません。私たちは必要な回数が線形に増加すること—m個のドメインに対して O(m) 回の実行が必要であること—を発見し、計算リソースを割り当てるための具体的な指針を提示しました。ドメインセットが成長しても、混合コストが爆発的に増大する必要はありません。
線形回帰は強力なデフォルトです。 異なる論文では、混合重みから性能を予測するためにさまざまな回帰モデル（べき乗則、対数線形、勾配ブースティング、ガウス過程など）が使用されていますが、その根拠はしばしば不十分です。私たちは、スワームサイズ（混合空間を検索するために訓練するプロキシモデルの数）が重要な交絡因子であることを発見しました。異なるモデルは異なるスワームサイズで優れた性能を発揮するため、これが文献における合意の欠如を説明している可能性があります。さまざまな設定において、対数線形モデルは全体的な適合性が最も優れており、かつ下流検証においても競争力があることがわかりました。
最適化器が希少なデータを過度に反復させないようにしてください。 これは一般的な失敗モードです：混合手法がコード（またはその他のデータタイプ）の訓練に大きな割合を割り当てるよう提案しますが、利用可能なデータのほんの一部しかコードが存在しない場合、有害なデータの反復を強いることになります。既存の方法が無限のデータを前提としているのに対し、OlmixBase は明示的な反復制約を組み込んでおり、混合が実際のデータ可用性に基づいたものになるように保証します。
これらの知見はすべて OlmixBase に組み込まれています。信頼性がありつつも低コストで済む十分な規模のプロキシモデル、ドメインに線形スケールするスワームサイズ、対数線形回帰、そしてデータ不足の状況における実現可能性制約です。単なる推測ではなく、合理的な混合のスタートポイントをお探しであれば、OlmixBase はまさにそのために設計されています。
Mixture reuse: Efficient mixing for iterative development
Olmix の2つ目のコンポーネントは、初期のミックス作成後のプロセスに対応するものです。
Olmo 1–3 の開発経験から、私たちはデータセットを繰り返し追加・削除・改訂・分割するというパターンを繰り返してきました。これは SmolLM 1–3 など他の反復的な開発取り組みでも観察される典型的な行動です。これらの操作は、実際のトレーニングパイプラインがどのように進化するかを示しています。ここで問われるのは、データに変更があるたびに毎回ゼロからミックスを作成しなければならないのかという点で、それはコストがかかります。
Olmix は「ミックスの再利用（mixture reuse）」を導入しました。つまり、ドメインセットに変更が生じても、すべてを再計算する必要はありません。重要な洞察は、大部分の変更がコパス全体ではなく、ごく一部のドメインのみに関与するということです。したがって、ゼロから再計算するのではなく、変更のないドメイン間の相対比率を固定したまま、実際に変更されたドメインの比率のみを再計算します。実務的には、これはすべての変更のないドメインを1 つの「バーチャルドメイン（仮想ドメイン）」にバンドルし、そのバーチャルドメインと変更された部分のみを対象としたはるかに小さな混合問題を解決し、結果を再び完全なミックスに展開することを意味します。混合コストは最適化するドメインの数に対して線形にスケールするため、この手法は特に一度に変更されるドメインが数個程度の場合に計算量を劇的に削減します。私たちのデフォルトのアプローチをフルミックス再利用（Full Mixture Reuse）と呼びます。これはすべての変更のないドメインの比率を保持するものです。
しかし、フルミキシングリユースは必ずしも完全再計算（すべてのドメインからゼロから混合する）と一致するわけではありません。私たちの理論分析によると、結合——変更されていないドメインと変更されたドメインの両方が同じ下流タスクに影響を与える状態——がパフォーマンス劣化を駆動する主要な要因であることが明らかになりました。これは経験的にも確認できます。例えばコードデータを追加する場合、「ソフトウェア開発」ウェブコーパスのスライスと新しいコードデータの両方がコーディングタスクに影響し、同じ目的のために競合します。この場合、両者の比率は再計算されるべきです。
ここで登場するのが部分ミキシングリユースアプローチです：すべての変更されていないドメインの比率を維持するのではなく、変更されたドメインとともに一部のドメイン（例：ウェブ上のソフトウェア開発）のみを選択的に再計算します。このアプローチにより結合効果を低減し、完全再計算との格差を縮小できます——フルミキシングリユースよりもわずかに多くのプロキシ実行が必要となるだけです。
これらのアプローチを検証するため、5 回の更新からなる現実的な開発シナリオをシミュレーションし、最終的に 64 のドメインに到達させました。100B トークンで 1B パラメータのモデルをトレーニングする際、フルミクスチャーリユース（Full Mixture Reuse）は完全再計算の改善効果の 95% を達成しつつ、プロキシ実行回数を 74% 削減（216 vs. 832）し、部分ミクスチャーリユース（Partial Mixture Reuse）は 98% に達しながらもプロキシ実行回数を 67% 削減します。さらに、ミクスチャーリユースによって得た最適なミックスは、自然分布（ドメインサイズに比例する暗黙的な比率を持つ混合なしのベースライン）よりも 12.2% 優れており、データ効率では 3.05 倍向上しています。私たちのミックスは、arXiv、FineMath、コードといった高価値なドメインを加重する点で、完全再計算から得られる結果と質的に類似しています。
Olmix は誰のためのものか？
Olmix は、多様なデータで言語モデル（LM）をトレーニングしており、設定の選択について推測することに疲れた方々や、トレーニングコーパスが変更されるたびに高価な混合実験を再実行することに疲れた方々のために設計されています。これは、データが進化するにつれてミックスを継続的に改善できるよう、原理に基づいた初期構成と効率的な更新メカニズムを提供します。
根本的に、データミキシングは研究コミュニティによって過小評価されてきた我们认为。これはモデル品質における一次レバー（主要な杠杆）ですが、多くの実践者は明確な根拠もなく先行研究の設定をコピーするか、何かが変更されるたびにゼロから高価なスウィープに頼るか、手動で直感に基づいた調整を行うことに依存しています。Olmix はその現状を変えるための私たちの試みであり、実験に基づき、反復的な大規模言語モデル開発の現実を考慮して設計されています。
コードと論文を含む完全なフレームワークは現在、利用可能です。
最新の Ai2 ニュースに関する月次更新を受け取るには、購読してください。
原文を表示
February 13, 2026
Ai2
Modern language models are trained on many kinds of data—web text, code, PDFs, math, and more. How you combine these sources matters enormously for the quality of the final model, but figuring out the right recipe is one of the messiest parts of building an LM. There's no universal formula, and the "best" mix depends on dozens of design choices that practitioners often have to guess at. In practice, many practitioners end up resorting to manual tweaking of the mix, with little way to know if they're leaving performance on the table.
Making things harder, training data isn't static throughout model development. In the weeks and months leading up to when the final model starts training, you're constantly adding new datasets, removing low-quality ones, filtering, and reorganizing—this is the reality of training an LM. Every time your data changes, you potentially need to figure out the mix all over again.
Olmix, which we’re releasing today, is our answer to these challenges. It's a framework for data mixing designed to keep up with how LMs are actually built, addressing two problems we repeatedly encounter in practice:
- There's surprisingly little guidance on how to configure a data mixing method. Existing approaches make different choices about model sizes, how many experiments to run, what modeling techniques to use, and so on—and these choices often conflict or aren't concretely justified in the literature. Practitioners are left to figure it out themselves.
- Recomputing your data mix from scratch every time your datasets change gets expensive fast. As your training corpus evolves through dozens of iterations, mixing can become a tax on every modification.
Olmix provides empirically grounded defaults so you're not guessing at configuration choices, and it introduces mixture reuse techniques that let you efficiently update your mix as your data evolves throughout LM development. In our experiments, this translated to a mix that is 12% better on downstream tasks and 3x more data-efficient than no mixing at all.
What actually matters in data mixing
A standard approach to finding a good data mix is to train a bunch of smaller proxy models on different mixtures (a “swarm”), see how they perform, and use a regression model to predict what mix will work best for your full-scale model. (In our paper, we call it the "offline mixing schema.") That's straightforward in theory. In practice, there's little consensus on how to actually set this up and do it throughout development.
Olmix is built around the idea that mixing should be a repeatable workflow that can keep up with modern LM development. It has two main components: OlmixBase, a data mixing method that instantiates the offline schema with research-validated configuration choices, giving you a strong starting mix at the beginning of development; and a set of mixture reuse techniques for efficiently updating that mix as your data evolves throughout the rest of LM development—without recomputing from scratch each time.
OlmixBase: Taking the guesswork out of configuring a mixing method
We ran a comprehensive study to answer the questions practitioners typically face when setting up a data mixing method according to the offline schema: How small can your proxy models be? How many proxy runs do you need? What regression model should you use? The findings from this study form the basis of OlmixBase, our recommended data mixing method.
For our study, we trained 1B-parameter models on DCLM data, a curated web text corpus, partitioned into 24 topic-based domains, and evaluated them across 52 downstream tasks spanning math, code, and commonsense QA. We measured performance via bits-per-byte (BPB), or the negative log-likelihood of the correct answer normalized by answer length in UTF-8 bytes.
Here's some of what we found:
Proxy models: small, but not too small. Proxies above roughly 15M parameters achieve strong rank correlation (ρ > 0.89) with 1B-parameter target models. Substantially smaller proxies become unreliable—1M-parameter models achieve only ρ = 0.73, which is too noisy for confident mixture decisions. Notably, while RegMix recommends a 1M proxy configuration, investigating their public code revealed their 1M implementation is actually closer to 15M—which our results suggest is a good proxy size. If you've been using extremely tiny proxies to save compute, you may be paying for those savings in noisy results.
Mixing costs scale linearly with domain count. Existing methods use anywhere from 20 to over 500 proxy runs, but few explain how this should scale with your domain set size. We found that the required number scales linearly – O(m) runs for m domains – giving practitioners a concrete prescription for allocating compute. Even as your domain set grows, mixing costs don't have to explode.
Log-linear regression is a strong default. Different papers use different regression models to predict performance from mixture weights – power law, log-linear, gradient boosting, Gaussian processes, etc. – often with little justification. We found that swarm size (the number of proxy models you train to explore the mixture space) is a key confounding factor—different models excel at different swarm sizes, which may explain the lack of consensus in the literature. We found that across settings, log-linear models achieve the best overall fit while remaining competitive on downstream validation.
Don't let your optimizer over-repeat scarce data. It's a common failure mode: your mixing method suggests allocating a large portion of training on code (or some other data type) when code is only a fraction of your available data, forcing harmful data repetition. Unlike existing methods that assume unlimited data, OlmixBase incorporates explicit repetition constraints so your mix stays grounded in actual data availability.
All these findings are baked into OlmixBase—proxy models large enough to be reliable but small enough to remain cheap, swarm sizes that scale linearly with domains, log-linear regression, and feasibility constraints for data-limited regimes. If you've wanted a sensible starting point for mixing that isn't just guesswork, OlmixBase is designed to be exactly that.
Mixture reuse: Efficient mixing for iterative development
The second component of Olmix addresses what happens after your initial mix.
In our experience developing Olmo 1–3, we repeatedly added, removed, revised, and partitioned datasets—a pattern also observed in other iterative development efforts, such as SmolLM 1–3. These operations describe how real training pipelines evolve. The question is whether you have to mix from scratch every time data changes, which is costly.
Olmix introduces mixture reuse: when your domain set changes, you don't need to recompute everything. The key insight is that most changes only touch a few domains, not the entire corpus. So instead of recomputing from scratch, reuse the relative ratios among unchanged domains fixed and only recompute the ratios for the domains that actually changed. In practice, this means bundling all unchanged domains into a single "virtual domain," solving a much smaller mixing problem over just that virtual domain plus whatever has changed, and then expanding the result back into a full mixture. Since mixing cost scales linearly with the number of domains you're optimizing over, this dramatically cuts compute—especially when only a handful of domains change at a time. We call our default approach Full Mixture Reuse, which preserves the ratios for all unchanged domains.
However, Full Mixture Reuse doesn't always match full recomputation (mixing from scratch on all domains). Our theoretical analysis reveals that coupling—when unchanged and changed domains both impact the same downstream tasks—is a key factor driving performance degradation. We see this play out empirically; when adding code data, for example, the "software development" slice of the web corpus and the new code data both influence coding tasks, competing to serve the same purpose. In this case, both of their ratios should be recomputed.
This is where our Partial Mixture Reuse approach comes in: rather than preserving the ratios of all unchanged domains, you selectively recompute a subset of them (e.g., web software development) alongside the changed domains. This approach can reduce coupling effects and can close the gap to full recomputation—while requiring only a few more proxy runs than Full Mixture Reuse.
To test these approaches, we simulated a realistic development sequence of 5 updates, ending with 64 total domains. When training 1B parameter models on 100B tokens, Full Mixture Reuse achieves 95% of the improvement of full recomputation while using 74% fewer proxy runs (216 vs. 832), and Partial Mixture Reuse reaches 98% while using 67% fewer proxy runs. Furthermore, our best mix obtained via mixture reuse is 12.2% better than the natural distribution (a no-mixing baseline with implicit ratios proportional to domain sizes) and is 3.05x more data-efficient. Our mix looks qualitatively similar to what you'd get from full recomputation, up-weighting high-value domains like arXiv, FineMath, and code.
Who is Olmix for?
Olmix is for anyone training LMs on diverse data who's tired of guessing at configuration choices—or tired of re-running expensive mixing experiments every time their training corpus changes. It provides a principled starting configuration and an efficient update mechanism so you can keep improving your mix as your data evolves.
Fundamentally, we think data mixing has been underserved by the research community. It's a first-order lever on model quality, but most practitioners copy configurations from prior work without clear justification, rely on expensive sweeps from scratch every time something changes, or resort to manual, intuition-driven tweaking. Olmix is our attempt to change that—grounded in experimentation and designed for the realities of iterative large-scale LM development.
The full framework, including code and paper, is available now.
Subscribe to receive monthly updates about the latest Ai2 news.
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み