Soupはレイヤーストリーミングにより4 GBラップトップGPUで8Bモデルのファインチューニングを可能にする

Overview

SoupはLLMファインチューニングをシンプルなワークフローに変換します：1つのYAML設定、1つのコマンド、そしてSSHやインフラストラクチャの手間は不要です。このプロジェクトは控えめなハードウェアでのトレーニングを対象とし、具体的には4 GBのVRAMしかないラップトップGPUで8Bモデルを動作させることを可能にします。

How It Works

レイヤーストリーミングは、凍結されたベースモデルをVRAMから外し、GPUにデコーダーレイヤーを1つずつ供給します。LoRAの間、ベースは読み取り専用であるため、ホストRAMに居座り、小さな事前に割り当てられたVRAMバッファにストリーミングされ、専用のCUDAストリームで1レイヤー先までプリフェッチされます。これにより、ピークVRAM使用量はモデル全体ではなく単一レイヤーのサイズ程度に削減されます。

量子化はベースに適用されます（デフォルトは4‑bit NF4）ことで、さらにメモリフットプリントを縮小します。アダプター（LoRA）はVRAM内で通常通りトレーニングされます。

DPOなどの好みベースの損失については、参照モデルは2番目のコピーではなく、Soupは同じストリーミングベースを再利用し、そのアダプターをオフにします。そのため、ストリーミングされる重みのセットは1つだけです。これにより参照はメモリ上では「無料」になりますが、時間コストが発生します：DPOは標準の教師ありファインチューニングと比較して、ステップごとにレイヤースタックを約1.52倍多く読み込みます。

システムは非ストリーミングの常駐実行とビットExactであることを保証します：複数のアーキテクチャと精度において最大絶対ロジット差は0.0であり、CIテストで検証済みです。

Key Features

• Zero SSH: リモートGPUマシンにログインする必要はありません。
• One configuration: 単一のsoup.yamlファイルがトレーニングのすべての側面を制御します。
• Automatic handling: バッチサイズ、GPU検出、量子化は自動的に管理されます。
• Local execution: ユーザー自身のGPUでQLoRAを使用したトレーニングが実行され、クラウドは不要です。
• Preference loss support: v0.72.4では、レイヤーストリーミングによるDPO、ORPO、SimPO、KTOがサポートされ、参照モデルは上記のように扱われます。
• Correctness focus: プロジェクトは生の速度よりもビットExactな再現性を重視しています。

Recent Updates (v0.72.4)

• レイヤーストリーミングは、教師ありファインチューニングだけでなく、DPO、ORPO、SimPO、KTOにも対応しました。
• RTX 3050 Laptop（4 GB、Windows）で測定：ストリーミングDPOのピークVRAM使用量は教師ありファインチューニングのピーク使用量の0.914倍でした。
• DPOの参照のために2番目のフルモデルを強制すると、約730 MB追加され、これは重みのほぼ1コピーに相当します。
• ORPOとSimPOは本当に参照フリーです；KTOはDPOと同じ参照メカニズムを再利用します。
• VRAMプレフライトは、ペアドロス（chosen + rejected）を行の2倍として考慮します。
• grpoとppoは、トークンごとにレイヤーを再読み込みする生成ステップがあるため、ストリーミングではメリットを相殺できないため除外されています。
• このリリースはまだBETAとマークされています。

Usage Guide

Installation

# Light core (CLI, config, data tools)
pip install soup-cli
# Add training dependencies (torch, transformers, peft, trl, datasets, …)
pip install "soup-cli[train]"

Create a Configuration

# Interactive wizard
soup init
# Or start from a template (e.g., chat)
soup init --template chat

典型的な8Bモデル用のsoup.yamlは次のようになるかもしれません：

base: meta-llama/Llama-3.1-8B-Instruct
task: sft
data:
  train: ./data/train.jsonl
  format: alpaca
  val_split: 0.1
training:
  epochs: 3
  lr: 2e-5
  batch_size: auto
  lora:
    r: 64
    alpha: 16
  quantization: 4bit
  stream_layers: true
  stream_source: auto
output: ./output

Train, Test, and Ship

soup train --config soup.yaml          # LoRA, quantization, batching handled
soup chat  --model ./output            # talk to your model
soup push  --model ./output --repo you/my-model

追加のコマンドにはsoup merge、soup export（GGUF、ONNX、TensorRTなどへ）、soup eval benchmark、soup data inspect、soup recipes list、soup autopilot、および環境チェックのためのsoup doctorがあります。

Performance Measurements (Author‑Reported)

• RTX 3050 Laptop（4 GB、Windows）では、Llama‑3.1‑8BをNF4とレイヤーストリーミングで119.6 tok/s達成し、ピークVRAM使用量は3.32 GB、SM占有率は**100 %**でした。
• 同じカードでは、量子化されていないbf16ベースのQwen2.5‑3Bを143 tok/sで2.15 GBのVRAMで実行できます；ベースを常駐させていたらCUDA‑OOMになります。
• 0.5 Bモデルサイズでのベースライン（常駐）とのストリーミングオーバーヘッドは**1.43×**です；著者は検証用にベースラインを提供しています。
• これらの数値はWindows固有です；Linuxではやや良くなる可能性があります。
• すべての測定記録（廃棄された実行も含む）はリポジトリのbenchmarks/ディレクトリで利用可能です。

Community Insights

• Local model ROI: コメンテーターは、小さなオープンウェイトモデルが大規模なホストモデルのコストを回避し、LLMに対する多くの企業が見ているROI危機に対処すると指摘しました。
• Practical use: あるユーザーはコミュニティ銀行のAMLコンプライアンスのためにファインチューニングされた4Bモデルを運用しており、同じROI根拠を挙げています。
• VRAM question: コメントでハードなVRAM要件がまだ存在する理由が質問されました；著者は、凍結ベースは各行列乗算の前に到達する必要があるためストリーミングが必要であり、ストリーミングによって要件が単一レイヤーに削減されることを説明しました。
• Hyper‑parameter tuning: 他のコメントでは、Soupがハイパーパラメータを自動チューニングし、複雑なトレーニング判断を行う方法について質問がありました；ソースでは自動ハイパーパラメータ検索については説明されていません；CLIはバッチサイズ、GPU検出、量子化を自動処理し、学習率、LoRAランクなどは設定ファイルで設定されます。
• Data amount: ファインチューニングに必要なデータ量についての質問が挙げられました；リポジトリは短い例データセットのみを提供し、必要なデータサイズに関する具体的なガイドラインはソースにはありません。
• Hardware recommendation: 4 GB GPUラップトップの具体的なおすすめモデルについてのリクエストがありました；ソースは特定のモデルを推奨していません。
• Website cost and readability: ユーザーは「Get Started for Free」ラベルが変更になる可能性と、サイトのグレー・オン・ブラックの可読性について疑問を呈しました；プロジェクトのライセンスはApache‑2.0で、無料のままです。
• Comment quality: 観察者は、スレッドのコメントのほぼ半分が死んでいるかLLM生成のように見え、投稿のスコアに対する低シグナルコメントの比率が高いことを指摘しました。

Limitations and Frequently Asked Questions

• VRAM ceiling: 著者は4 GBカードでの8B以上のモデルサポートを主張していません；14B NF4は約7.5 GBのページロックホストメモリを必要とし、テストラップトップで測定された約7.12 GBの上限を超えます。
• Preference loss overhead: 参照モデルはメモリ上では「無料」ですが、DPOはステップごとにレイヤースタックの読み込みが1.52×増加します。
• Excluded algorithms: GRPOとPPOは意図的に除外されています；なぜなら、トークンごとの生成ではレイヤーを毎回再読み込みする必要があり、ストリーミングの利益が相殺されるからです。
• Automatic hyper‑parameter tuning: ソースでは学習率、LoRAランク、その他のハイパーパラメータの自動チューニングについては詳細が提供されていません；これらはsoup.yamlで指定する必要があります。
• Data size guidance: 必要なファインチューニングデータセットのサイズについての普遍的なルールは示されていません；ユーザーは自身のデータで実験する必要があります。

Conclusion

Soupは、レイヤーストリーミングと4‑bit量子化により、4 GBのVRAMしかないコンシューマーラップトップGPUでも8BパラメータLLMのファインチューニングを可能にすることを示しています。このアプローチは数値の正確性（常駐トレーニングとのビットExactマッチ）を保ちながら、インフラストラクチャの要求を最小限に抑えます—SSH不要、単一の設定ファイル、バッチサイズと量子化の自動処理。プロジェクトはオープンソース（Apache‑2.0）のままであり、特に単一の4 GBラップトップではできないハードウェア集中的な検証へのコミュニティからの貢献を奨励しています。