LitGPT を採用すべきか: 抽象化を捨てた LLM 実装の実像

LitGPT が解こうとしている問題は「モデルの中身が見えない」ことにある

多くの LLM ライブラリは、モデル定義をフレームワーク内部に隠し、利用者には設定オブジェクトだけを渡す。LitGPT は逆を行く。README は「Every LLM is implemented from scratch with no abstractions and full control」と述べており、各モデルが単一ファイルの実装として置かれていることを前提にしている。これは学習曲線を寝かせる代わりに、デバッグ時にスタックトレースを追ってモデルの forward まで到達できることを意味する。対象読者は、モデルの重み変換や attention の実装を自分で確認したい研究開発者、あるいは finetune の挙動がおかしいときにフレームワークのバグか自分の設定ミスかを切り分けたいエンジニアである。逆に、モデルの中身に関心がなく「とにかく推論結果が返ればよい」という用途では、この設計方針は利点にならない。

対応モデルは 20 以上、ただし一覧は「読む人」向けに書かれている

README のモデル表には Llama 3 系 (1B から 405B)、Code Llama、CodeGemma、Gemma 2、Phi 4、Qwen2.5 と Qwen2.5 Coder、R1 Distill Llama などが並ぶ。サイズは 0.5B から 405B まで幅があり、単一 GPU で動く範囲からマルチノード前提の範囲まで含まれる。ここで注意したいのは、この表が「どのモデルがどの精度で動くか」を示すものではないことだ。モデル名とパラメータ数、原著論文へのリンクが並んでいるだけで、量子化時のメモリ量やスループットは README には書かれていない。採用判断の材料としては、対応モデルの網羅性は確認できるが、性能の比較はできない。README は「Optimized for fast inference」とも述べるが、その裏付けとなる数値は提示されていない。

インストールは extra 依存をどこまで入れるかで変わる

最小構成は `pip install 'litgpt[extra]'` である。ソースから入れる場合はリポジトリを clone したうえで、uv を使うなら `uv sync --all-extras`、pip を使うなら `pip install -e ".[extra,compiler,test]"` という 2 通りの手順が README に示されている。extra と compiler と test という 3 つのグループが分かれている点は実務上意味がある。compiler を入れるかどうかは、torch.compile 系の最適化を使うかどうかに対応する。test は開発参加時のみ必要になる。つまり「本番の推論環境に何を入れるか」を自分で選ぶ設計であり、フルスタックのフレームワークのように 1 コマンドで全部入りにはならない。依存の範囲を把握せずに extra だけを入れて動かし、後からコンパイル関連の機能が使えないと気づく、という順序になりやすい。

推論は LLM.load と generate の 2 行から始まる

README の quick start は `from litgpt import LLM` に続けて `LLM.load("microsoft/phi-2")` を呼び、`llm.generate(...)` に文字列を渡す例を示している。返り値は文字列で、例ではスペル修正の結果がそのまま出力されている。ここで読み取れるのは、LitGPT が Hugging Face のモデル識別子を受け取る設計だという点である。つまり重みの取得経路は Hugging Face 側に依存しており、独自形式のチェックポイントを前提にしていない。オフライン環境や社内ミラーを使う場合にこの経路をどう差し替えるかは、README の範囲では説明されていない。Python API の詳細は tutorials/python-api.md に分離されており、この記事で確認できるのは quick start の 2 行までである。

finetune は YAML レシピと LoRA/QLoRA の選択が中心になる

README の機能一覧には LoRA、QLoRA、Adapter が挙げられ、学習のレシピは YAML として管理される構成が示されている。つまり finetune の設定は Python コードではなく YAML ファイルに書き、それをコマンドから読ませる流れになる。この形式の利点は、ハイパーパラメータの差分をバージョン管理しやすいことだ。欠点は、YAML のキーがどのモデル実装のどの部分に対応するのかがファイル単体からは見えにくいことで、結局はモデル実装のファイルを読む必要がある。FSDP への対応も README に記載があり、1 台から 1000 台以上の GPU/TPU までを対象にするとされている。ただし README には具体的な起動コマンドやノード間設定の例は示されていないため、分散構成の実際の手順はリポジトリ内の該当ドキュメントを確認する必要がある。

抽象化を排した設計は、モデル追加のたびに保守者を必要とする

LitGPT の最大の制約は、利点の裏返しとして現れる。モデルごとに実装が独立しているため、新しいアーキテクチャが出るたびにそのモデル用の実装を追加する必要がある。共通の抽象レイヤーがあれば 1 箇所の修正で済む変更が、モデル数だけ存在するファイルに波及しうる。README のモデル一覧を見ると Llama 3 系だけで 1B、3B、8B、70B、405B と複数サイズが並び、Qwen2.5 も 0.5B から 72B まで 7 サイズある。サイズごとに実装ファイルが分かれているとは限らないが、少なくともモデル系列ごとに対応コードが存在する構成である。結果として、上流モデルの改訂に追随する速度は、抽象化されたライブラリよりも保守者の人数に依存しやすい。fp4/8/16/32 の精度切り替えも README に記載があるが、どの精度がどの GPU で動くかの対応表は示されていない。

比較対象としての Hugging Face Transformers との違い

同じく多数の LLM を扱うライブラリとして Hugging Face Transformers がある。両者の違いは抽象化の位置にある。Transformers はモデル定義を共通のインターフェースに揃え、新しいモデルを追加するコストを下げる方向に最適化されている。LitGPT は逆に、モデルごとの実装を独立させ、読みやすさと制御性を優先する。したがって「上流の新モデルをいち早く試したい」なら Transformers が有利であり、「特定モデルの学習ループを自分で書き換えたい」なら LitGPT のほうが追いやすい。両者は排他的ではなく、LitGPT が Hugging Face のモデル識別子を受け取る以上、重みの入手経路としては併用される。選定の軸は、抽象化によって失う可読性と、抽象化によって得られる追随速度のどちらを優先するかである。

ライセンスと保守コスト、そして導入前に確認すべきこと

LitGPT 自体は Apache-2.0 で提供され、README も「Apache 2.0 for unlimited enterprise use」と述べている。ただしこれはリポジトリのコードに対する条件であり、読み込むモデルの重みはそれぞれ別のライセンスに従う。Llama 系や Gemma 系の重みには独自の利用条件があり、Apache-2.0 だからといって商用利用が無条件に認められるわけではない。ここは法務判断の領域であり、本記事で結論を出すことはできない。保守の観点では、リリースは v0.5.11 から v0.5.13 まで約 1 年で 3 回という間隔が記録されており、活発な破壊的変更が続く前提でバージョンを固定して運用するほうが安全である。導入前に確認すべきは、対象モデルが一覧に存在すること、YAML レシピで自社の GPU 構成を表現できること、そして重みのライセンス条件の 3 点に絞られる。

編集部の結論

LitGPT は、モデル内部の実装を読み書きしながら pretrain から finetune、deploy までを一貫して扱いたいエンジニアに向く。逆に、モデルの中身に関与せず推論 API だけを安定して呼びたい場合や、新しいモデルが出るたびに自前の重み変換を保守したくない場合には向かない。導入前に確認すべきは、対象モデルが README の一覧に載っているか、config の YAML で自分のハードウェア構成を表現できるか、そして Apache-2.0 の下で配布される重みと自社の利用条件が整合するかの 3 点である。

公式情報源

1. License: Apache-2.0
2. Lightning-AI/litgpt on GitHub
3. Project website
4. README
5. Releases