llm-foundry を採用する前に読む: Composer 前提の学習基盤と StreamingDataset の設計
LLM training code for Databricks foundation models
ひと目でわかる
- これは何？
- llm-foundry は MPT と DBRX を実際に学習するために Databricks Mosaic チームが使ったコードベースで、学習・評価・推論変換までを 1 つのリポジトリにまとめている。ただし Composer と MosaicML platform への依存が強く、そこを外して使えるかどうかが採用判断の分かれ目になる。
- 誰に向いている？
- llm-foundry が向くのは、Composer をすでに学習基盤として使い、データを StreamingDataset 形式に変換する前提を許容でき、MPT 系や HuggingFace モデルを 125M から 70B の範囲で扱いたいチームである。逆に、素の PyTorch の学習ループに自前のデータパイプラインを組み合わせて運用しており、Composer を入れるつもりがない場合、このリポジトリの中心部分はほぼ使えない。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 174 日前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
llm-foundry が埋めているのは学習スクリプトの隙間ではなく、データ形式の隙間である
LLM の学習コードは世の中に大量にある。llm-foundry が他と違うのは、モデル定義や学習ループよりも、データの受け渡し形式を固定している点にある。リポジトリ直下の scripts/data_prep/ は、元のテキストデータを StreamingDataset 形式へ変換するためのスクリプト群であり、学習側はこの形式を読むことを前提に組まれている。つまり llm-foundry を採用するとは、学習アルゴリズムを借りるというより、データの持ち方とシャーディングの方針を借りることに近い。
対象読者は README から読み取れる範囲では 2 種類いる。1 つは MPT や DBRX のような公開モデルを自分のデータで再現したい研究・開発者。もう 1 つは 125M から 70B の規模で HuggingFace モデルを finetune したい実務者である。README は scripts/train/ の説明で「train or finetune HuggingFace and MPT models from 125M - 70B parameters」と明記しており、このレンジが想定スコープだと考えてよい。逆に、数億パラメータの小規模モデルを 1 枚の GPU で回すだけなら、このリポジトリの構成は過剰になる。
Composer が学習ループを持ち、llm-foundry はその上のモデルとデータを供給する
アーキテクチャの層構造は README の記述から素直に読み取れる。最下層に Composer があり、llm-foundry はその上でモデル、データセット、コールバック、ユーティリティを提供する。学習の進行、チェックポイント、ロギングといった制御は Composer 側の責務であり、llmfoundry/ ディレクトリに入っているのはそれらに接続する部品である。
この分担は、llm-foundry を単体のライブラリとして評価しようとすると見えにくい。学習を回すときに実際に動いているのは Composer の Trainer であり、llm-foundry はその設定対象を増やしている。したがって、Composer のバージョンアップが llm-foundry の動作に直結する。リリースが v0.20.0、v0.21.0、v0.22.0 とほぼ毎月のペースで切られている事実は、追従の頻度がそれなりに必要であることを示している。
DBRX に関しては、README が「optimized versions of Composer, LLM Foundry, and MegaBlocks」で学習したと述べている。公開されている llm-foundry がその最適化版と同一であるとは README からは確認できない。ここは区別して読むべき箇所である。
scripts/ 配下の 4 系統を把握すれば全体像はほぼ掴める
README が示す scripts/ の構成は 4 つに分かれている。data_prep/ は変換、train/ は学習と finetune、inference/ は HuggingFace または ONNX 形式への変換と生成、eval/ は in-context-learning タスクでの評価である。train/ の下には benchmarking があり、学習スループットと MFU を計測する。inference/ の下にも benchmarking があり、こちらは推論のレイテンシとスループットを計測する。
この並びで実務上重要なのは、学習と推論が同じリポジトリ内で完結する点だ。学習したモデルを別リポジトリの変換ツールに渡すのではなく、inference/ のスクリプトで HuggingFace 形式に落とせる。モデルの受け渡しで形式の食い違いに悩む時間を減らせるという意味はある。
一方で eval/ が扱うのは academic または custom の in-context-learning タスクであり、業務固有の評価指標をそのまま流し込める作りではない。README の記述からは、評価を自前で組む余地がどの程度あるのかまでは判断できない。
動かすまでの手順は README の範囲では起動スクリプトまでしか見えない
README から確認できる実行経路は 2 つある。1 つは scripts/train/ 配下のスクリプトを直接叩く方法、もう 1 つは mcli/ 配下の定義を使って MCLI 経由で MosaicML platform に投入する方法である。README は後者について「launch any of these workloads using MCLI and the MosaicML platform」と説明している。
推論を試すだけなら、より軽い経路が用意されている。README は scripts/inference/README.md の手順に従い、hf_generate.py または hf_chat.py で HuggingFace 形式のモデルをプロンプトできるとしている。MPT-7B などを手元で動かして挙動を確かめたい場合、学習環境を組む前にここから入るのが現実的だ。
注意すべきは、この記事の材料には具体的な CLI 引数、YAML のキー名、環境変数の一覧が含まれていないことである。pip install llm-foundry で入るという事実は PyPI バッジから読み取れるが、その先の設定値は TUTORIAL.md と各ディレクトリの README を参照する必要がある。設定キーを推測で書くのは避けたい。
Composer を外したいチームにとって、このリポジトリは分割しにくい
最も現実的な制約は Composer への依存である。llmfoundry/ のモデル定義だけを抜き出して素の PyTorch で回すことは技術的に不可能ではないが、データセット、コールバック、ユーティリティが Composer のインターフェースを前提に書かれているため、抜き出すほど残るものが薄くなる。Composer を既に使っているなら導入コストは小さい。使っていないなら、llm-foundry の導入は Composer の導入とほぼ同義になる。この点は採用判断で最初に確認すべきである。
2 つ目の制約はデータ形式である。scripts/data_prep/ を通す前提が強いため、既存のデータパイプラインが別形式で動いている場合、変換工程を挟むことになる。ストリーミング形式に変換してしまえば以後は扱いやすいが、変換自体の検証コストは無視できない。
3 つ目は実行環境である。mcli/ は MosaicML platform を前提とした定義であり、オンプレミスや他クラウドで同じ定義をそのまま使えるかは README からは判断できない。platform を使わない場合、scripts/train/ を直接叩く経路に自分で寄せる必要がある。
素の PyTorch と HuggingFace Trainer に対する差分はどこにあるか
比較対象として最も自然なのは HuggingFace の Trainer である。Trainer はモデルとデータセットを渡せば学習ループを組み立ててくれるが、データのシャーディングやストリーミングの形式には踏み込まない。llm-foundry は逆で、データ形式を StreamingDataset に固定する代わりに、大規模データを分割して扱う前提を最初から組み込んでいる。どちらが優れているかではなく、データ側を固定できるかどうかで選ぶべきものである。
もう 1 つの比較軸は Composer 自体との関係である。Composer は学習ループとスケジューリングを提供する汎用ライブラリで、llm-foundry はその上に LLM 固有のモデル、トークナイザ、データ変換を載せたものになる。Composer だけでは MPT の構成や DBRX の MoE は組み立てられない。逆に llm-foundry だけでは学習は回らない。両者は代替関係ではなく上下関係にある。
MegaBlocks は DBRX の学習で使われたと README が述べているが、これは MoE の計算を効率化するための別リポジトリであり、llm-foundry に含まれるものではない。MoE を自分で組む場合、llm-foundry だけでは足りない可能性がある。
Apache-2.0 のコードとモデル重みのライセンスは別物である
リポジトリ本体は Apache-2.0 で提供されている。バッジにも LICENSE ファイルにもその記載がある。コードを改変して自社製品に組み込むことは、Apache-2.0 の条件に従う限りにおいて可能である。
ただし、ここで止まってはいけない。README は DBRX について「Our model weights and code are licensed for both researchers and commercial entities」と述べ、Databricks Open Source License と Acceptable Use Policy の所在を示している。つまり DBRX の重みは Apache-2.0 ではなく別ライセンスである。MPT についても表があり、MPT-30B、MPT-7B などの Instruct 系は商用利用可、Chat 系は商用利用不可と明記されている。同じ MPT という名前でもモデルによって条件が違う。
コードのライセンスだけを見て「Apache-2.0 だから自由」と判断すると、重みの利用条件で詰まる。モデルを選ぶ段になってから表を確認するのでは遅い。どのモデルを finetune するかを決める時点で、その行の Commercial use 列を見ておく必要がある。
毎月のリリースに追従する前提で運用を設計する
v0.20.0 が 2025-04-29、v0.21.0 が 2025-05-31、v0.22.0 が 2025-07-29 と、リリース間隔はおよそ 1 か月から 2 か月である。メジャーバージョンが 0 のままであることを踏まえると、破壊的変更が入る余地は残っていると考えたほうがよい。学習基盤は一度動き出すと数週間単位で占有されるため、リリースのたびに追従する運用は現実的でない。特定のバージョンを固定し、更新は計画的に行う形になる。
更新コストを左右するのは Composer 側のバージョンである。llm-foundry のリリースノートだけを見ても、依存する Composer の変更までは追えない。更新を検討するときは、llm-foundry と Composer の両方のリリースノートを突き合わせる必要がある。
もう 1 つ、README には TUTORIAL.md への言及があり、「a deeper dive into the repo, example workflows, and FAQs」と説明されている。設定の実例はここに集約されている可能性が高い。バージョンを固定したら、そのバージョンの TUTORIAL.md を手元に置いておくのが、更新時の差分確認を最も安く済ませる方法になる。
編集部の結論
llm-foundry が向くのは、Composer をすでに学習基盤として使い、データを StreamingDataset 形式に変換する前提を許容でき、MPT 系や HuggingFace モデルを 125M から 70B の範囲で扱いたいチームである。逆に、素の PyTorch の学習ループに自前のデータパイプラインを組み合わせて運用しており、Composer を入れるつもりがない場合、このリポジトリの中心部分はほぼ使えない。採用前に確認すべきは、scripts/data_prep/ の変換スクリプトが自分のデータ形式に対応しているか、scripts/train/ の YAML が自分のモデル構成を表現できるか、そして mcli/ のワークロード定義が MosaicML platform 以外でも意味を持つかの 3 点である。
コミュニティノート