Soup: 1本のYAMLで8Bモデルを4GBノートGPUに載せる試みと、その代償
Fine-tune LLMs from one YAML. Layer streaming trains an 8B model on a 4 GB laptop GPU.
ひと目でわかる
- これは何？
- Soupは設定ファイル1本とコマンド1つでLLMのファインチューニングを完結させるCLIだ。低VRAM向けのレイヤーストリーミングを売りにする一方、v0.74.0では凍結ベースがfp32で読み込まれていたという修正が入っている。何が実際に動き、どこで壊れるのかをリポジトリの記述から読み解く。
- 誰に向いている？
- 4GBから12GB程度の単一GPUでQLoRAを回し、SSHやクラウドのセットアップに時間を割きたくない個人や小規模チームには向く。逆に、マルチノード分散学習、独自のデータパイプライン、厳密な再現性が要件なら別の道具を選ぶべきだ。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。直近 1 日以内に新しいコミットがあります。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
Soupが埋めようとしている穴は「設定」ではなく「環境構築」
READMEの冒頭は「Fine-tune and post-train LLMs in one command. No SSH, no config hell.」と宣言し、Why Soup?の節で「経験のあるチームでも時間の30〜50%をインフラとの格闘に費やしている」と主張している。この数字の出典は示されていないので、そのまま受け取るべきではない。ただし、対象読者の輪郭ははっきりしている。GPUを1枚だけ持つ個人、あるいは社内検証用に小さなモデルを回したい開発者だ。データセットの前処理、量子化、バッチサイズの決定、勾配チェックポイントの有無といった判断を、YAMLのキーに落とし込むのがSoupの役割になる。
注意したいのは、Soupが学習アルゴリズムそのものを発明しているわけではない点だ。基盤にはtransformers、TRL、PEFT、bitsandbytesが並んでおり、v0.74.0のリリースノートは「Transformers 5.x、TRL 0.29、PEFT 0.20」への追随を挙げている。つまりSoupの価値は、これらのライブラリの組み合わせとバージョン整合を、利用者に代わって面倒を見るという一点に集約される。逆に言えば、その組み合わせが崩れたときの影響もSoup側に集中する。
レイヤーストリーミングはVRAMではなくRAMとディスクの勝負になる
最大の売りは「Fine-tune an 8B model on a 4 GB laptop GPU」という一文だ。仕組みはREADMEに短く書かれている。Layer streamingは凍結したベースモデルをVRAMに置かず、デコーダ層を1枚ずつGPUへ送り込む。学習対象はLoRAアダプタ側だけなので、ベースの重みは勾配を持たない。だから常駐させる必要がない、という理屈になる。
READMEが示す測定値は、RTX 3050 Laptop 4GBでLlama-3.1-8B-Instruct + NF4、119.6 tok/s、ピーク3.32 GB。同じ3.32 GBでH100でも113.00 tok/sが出たと書かれている。ここで気にすべきは、この数字がv0.72.2時点のもので、v0.73.0の正確性修正で32Bにおいて4.8%の速度低下があったと明記されていることだ。4GBカードでの再測定は行われていない。また、この機能はstream_layers: trueで明示的に有効化するオプトインで、README自身がBETAと書いている。
もう1つの制約はメモリの置き場所だ。図の説明には「3.60 GBのベースストアがRAM上に32層分ピン留めされ、VRAMバッファは113 MBが2つ」とある。つまりVRAMを削った分、ホスト側のRAMとディスクI/Oが効いてくる。4GBのGPUを積んだノートPCが、同時に32GBのRAMを持っているとは限らない。この点は採用判断で最初に確認すべき数字になる。
v0.74.0が直したのは速度ではなく、静かな精度の話
リリースノートの見出しは「the base was loaded in fp32 the whole time」だ。SFTの読み込み経路3つすべてで、凍結ベースがチェックポイントの倍精度で実体化されていたと書かれている。H100とLlama-3.1-8B + LoRAでの測定として、ピークが48,241 MiBから18,658 MiBへ、2.59倍、28.9 GBの削減、3回の繰り返しでバイト単位に同一だったと述べられている。学習可能なベースは意図的にfp32のままだという。
ここで読むべきは、これが「速くなった」話ではなく「無駄にメモリを食っていた」話だという点だ。VRAMが足りない環境では、この無駄がそのままOOMとして現れる。つまりv0.74.0より前のバージョンで「4GBでは動かなかった」という経験をした人がいても不思議ではない。逆に、十分なVRAMがある環境ではこの修正の恩恵はほぼ見えない。
同じリリースにはセキュリティ寄りの修正も並ぶ。省略形や10進、16進、8進で書かれたIPv4表記（127.1、2130706433、0x7f000001、0177.0.0.1）がテレメトリとWebhookのガードを通過していたという4件のSSRFバイパス、そしてsoup serveが非ループバックホストにバインドされる際、--tool-auth-tokenがなければ警告ではなく終了コード2で落ちるようになった変更だ。後者は破壊的変更なので、既存の起動スクリプトは見直しが要る。
導入はpipとinitとtrainの3手で終わる
READMEのクイックスタートはこの3行だ。
pip install "soup-cli[train]" soup init --template chat soup train
extrasの設計は素直で、[train]を付けなければ軽量なCLIだけが入る。v0.74.0では[train,mlx]の組み合わせが解決できるようになったと書かれており、それ以前は2つのextrasが宣言する範囲を同時に満たせなかった。MLX経由でApple Siliconを使う予定があるなら、この修正以前のバージョンではpipの解決自体でつまずくことになる。
設定はYAML1本で、レイヤーストリーミングを使うならstream_layers: trueを書く。クラウドを使う場合はsoup train --cloud lambdaがあり、既定ではplan-only、つまり実行計画の提示までで止まる。実際に起動した場合はfinally節で終了処理が走り、終了したことをポーリングで確認する仕組みだと説明されている。
Web UIも用意されているが、READMEからは起動コマンドやポート、認証の有無までは読み取れない。ここは導入前に本体のドキュメントを確認する必要がある。
対応GPUの境界と、torch床の不整合という2つの落とし穴
v0.74.0のリリースノートには、無料のColab/Kaggle枠ではレイヤーストリーミングがそもそも動かなかったと書かれている。T4、P100、V100、GTX 16xxがクラッシュしていた。理由も明示されている。peftがLoRAアダプタをチェックポイントのdtypeで作る一方、fp16のGradScalerはfp32の勾配を要求するためだ。つまり「無料枠で試す」という最も手軽な検証経路が、つい最近まで塞がっていたことになる。
もう1つ、README末尾に残された既知の制限も見逃せない。宣言されているtorch>=2.5.0の下限はtrl>=0.29と両立しない。torch 2.5.1ではtrlがimportできないという。新規インストールではより新しいtorchが解決されるため通常は表面化しないが、既存プロジェクトの依存を固定している環境にSoupを足すと、この床に当たる可能性がある。
この2つに共通するのは、Soupが広いバージョン範囲と広いハードウェアを宣言しつつ、実際に検証された組み合わせはもっと狭いという構図だ。READMEが自ら「check it yourself on a free Colab T4」と検証ノートブックを案内しているのは誠実だが、裏を返せば自分の環境で確かめる以外に確証がないということでもある。
AxolotlやUnslothとの違いは抽象度の高さにある
同じ領域にはAxolotlとUnslothがある。AxolotlはYAML駆動という点でSoupに近いが、設定キーの数と学習手法の網羅性で性格が異なる。Axolotlは設定ファイルがそのまま学習の全パラメータを露出させる方向に振れており、SFT、DPO、ORPOといった手法の切り替えや、DeepSpeed、FSDPによるマルチGPU構成まで設定で表現する。Soupは逆で、バッチサイズや量子化を「Auto everything」として自動決定側に寄せ、利用者が触るキーを絞る。自由度を削って判断コストを下げる設計だ。
Unslothは発想がもっと下の層にある。カーネルレベルで学習を書き換えて速度とメモリを稼ぐ。Soupのレイヤーストリーミングは「凍結ベースをVRAMに置かない」という発想で、Unslothの最適化とは競合せず重ねられる可能性があるが、両者を同時に使った場合の挙動についてREADMEは何も述べていない。
選び分けの基準は単純だ。マルチGPUや独自の学習ループ、特殊な損失関数が必要ならAxolotl側に寄る。1枚のGPUでとにかく動かしたいならSoupの抽象度が効く。ただしSoupの抽象度は、裏で何が起きているかが見えにくいという代償を伴う。v0.74.0のfp32問題は、まさにその見えにくさが原因で長く残っていた不具合だ。
Apache-2.0とメンテナンスの見取り図
ライセンスはApache-2.0で、特許条項と帰属表示の条件を含む標準的な内容だ。ここから先は法的助言ではないが、実務上確認すべき点は2つある。1つ目は、学習に使うベースモデルやデータセットのライセンスはSoupのライセンスとは独立しているという当たり前の事実だ。Llama系のモデルには独自の利用条件がある。2つ目は、成果物の配布形態だ。SoupはGGUFやOllama向けの出力を扱うため、量子化された重みを配る場合はモデル側の条件がそのまま効く。
メンテナンス面で目を引くのは、v0.74.0のリリースノートが「このリリースでマージされた120件のうち116件がメンテナ以外から、25人によるもの」と述べている点だ。外部コントリビューションの比率が高いという事実は、バス係数の観点では安心材料になる。ただし、これは品質の証明ではない。変更の速さはそのまま追従コストになる。v0.73.3、v0.73.2、v0.74.0と短期間にリリースが並び、うち1つは破壊的変更を含む。バージョンを固定して運用するか、追随する余力を確保するかの判断が要る。
リポジトリはアーカイブされておらず、最終pushは2026年9月9日、v0.74.0は2026年9月4日付だ。DOIが付与され、ベンチマークディレクトリと検証用ノートブックが公開されている点は、数値を自分で追試できる体裁が整っていることを意味する。
編集部の結論
4GBから12GB程度の単一GPUでQLoRAを回し、SSHやクラウドのセットアップに時間を割きたくない個人や小規模チームには向く。逆に、マルチノード分散学習、独自のデータパイプライン、厳密な再現性が要件なら別の道具を選ぶべきだ。導入前に確認すべきは3点で、1つ目は自分のGPUがレイヤーストリーミングの対応外になっていないか（v0.74.0のリリースノートはT4/P100/V100/GTX 16xxでクラッシュしていたと述べている）、2つ目はtrl>=0.29とtorch>=2.5.0の組み合わせが動かないという既知の制限に自分の固定バージョンが当たらないか、3つ目はsoup serveを非ループバックにバインドする構成なら--tool-auth-tokenを用意できるかだ。この3つがクリアできないなら、Soupの採用は保留したほうがよい。
コミュニティノート