2026年のAIエンジニアリング・スタック:LLMフレームワーク完全ガイド

The Unified Architecture of Large Language Models

大規模言語モデル(LLM)を取り巻くエンジニアリング領域は、散在する実験的なスクリプトの寄せ集めから、堅牢で多層的なソフトウェアスタックへと成熟しました。2025年後半現在、そのエコシステムは「事前学習(Pre-training)」、「事後学習(Post-training / Fine-tuning)」、「推論(Inference / Deployment)」という3つの明確なライフサイクルによって定義されています。本記事では、各フェーズを支配するフレームワークについて、専門家レベルの徹底的な分析を行います。NVIDIAのモノリシックなMegatron-LMから、柔軟で多機能なms-swiftに至るまで、各ツールのアーキテクチャ上の決定、ハードウェアの最適化、そしてトレードオフについて解説します。


パート1:事前学習(Pre-training)フレームワーク

事前学習は、LLMライフサイクルにおける「熱力学的な頂点」とも言えるフェーズです。膨大な計算資源を必要とし、数千のGPUにわたってモデルのFLOPS利用率(MFU)を最大化することがエンジニアリングの主目的となります。このカテゴリのフレームワークは、Qwen 3DeepSeek-V3のような大規模なMoE(Mixture-of-Experts)アーキテクチャに必要な、複雑な分散コンピューティングの「振り付け」を管理します。

1.1 テンソル並列の巨人:NVIDIA Megatron-LM

リポジトリ: https://github.com/NVIDIA/Megatron-LM

Megatron-LMは、現存する最大級のモデルにおける基礎的なリファレンス実装としての地位を確立しています。NVIDIAによって開発されたこのツールは、ユーザーフレンドリーなライブラリというよりは、極限スケールのコンピューティングにおける「青写真」と言えます。そのアーキテクチャ思想の中心にあるのはテンソル並列(Tensor Parallelism: TP)であり、これは個々の行列演算を複数のGPUに分割することで、ノード間の通信レイテンシを最小化する技術です。

スケールのアーキテクチャ

2025年、Megatron-LMは単純なTPを超えて進化しました。Megatron Core (MCore)の導入は大規模なリファクタリングを意味し、分散プリミティブをモデル定義から分離してモジュール化しました。これは、Qwen 3に見られるような高密度MoEハイブリッドのようなアーキテクチャの複雑化に対応するために不可欠なシフトでした。重要な革新の一つがコンテキスト並列(Context Parallelism: CP)です。コンテキストウィンドウが(Long-Context Qwenのバリエーションによって)100万トークン以上に拡大するにつれ、標準的なシーケンス並列(SP)では不十分になりました。CPはアテンション計算自体を分割し、KVキャッシュとアテンションスコアを致命的な通信オーバーヘッドなしにGPU間で分散させることを可能にします。

ハードウェアとの共生:Transformer Engine

Megatron-LMの優位性は、Transformer Engine (TE)によって強化されています。TEは、NVIDIA HopperおよびBlackwellアーキテクチャ上でのネイティブFP8(8ビット浮動小数点)学習を可能にします。テンソルをFP8とBF16の間で動的にキャストすることで、TEはMegatron-LMが行列乗算のスループットを倍増させることを可能にします。

1.2 メモリの最適化:Microsoft DeepSpeed

リポジトリ: https://github.com/microsoft/DeepSpeed

Megatron-LMが計算の並列化に焦点を当てているのに対し、MicrosoftのDeepSpeedは「メモリの壁(Memory Wall)」に取り組みます。その核心的な貢献であるZero Redundancy Optimizer (ZeRO)は、オプティマイザの状態、勾配、パラメータを利用可能なすべてのGPUに分割して配置します。

MoEの時代:DeepSpeed-MoE

Qwen 3DeepSeek-V3がヘビーなMoEアーキテクチャを採用する中、標準的なデータ並列処理は非効率になります。2025年のアップデートではDeepSpeed-MoEに焦点が当てられており、トークンをそれぞれの専門家(エキスパート)にルーティングするために必要な「all-to-all」通信プリミティブを最適化しています。これにより、エキスパート並列のオーバーヘッドが大幅に削減されます。

1.3 ミニマリストな挑戦者:Hugging Face Nanotron

リポジトリ: https://github.com/huggingface/nanotron

Megatron-LMのようなフレームワークが硬直化するにつれ、アーキテクチャを反復開発する必要がある研究者のためにNanotronが登場しました。Nanotronの哲学は「ミニマルな3D並列」です。クリーンでPythonライクなAPIを通じて分散プリミティブ(TP、PP、DP)を提供し、古いフレームワークにありがちな「設定地獄(config hell)」を回避しています。

1.4 ネイティブの進化:PyTorch FSDP2 & Torchtitan

リポジトリ: https://github.com/pytorch/torchtitan

PyTorchチームはFully Sharded Data Parallel 2 (FSDP2)によってその差を縮めました。オリジナルのFSDPとは異なり、FSDP2はテンソルレベル(DTensor経由)でシャーディングを管理し、メモリレイアウトのきめ細かい制御を可能にします。Torchtitanはそのフラッグシップ実装であり、非同期チェックポイント(Async Checkpointing)を活用して、ネイティブなPyTorch構造が数千のGPUまでスケールすることを実証しています。

技術比較分析:事前学習

特徴セット Megatron-LM DeepSpeed Nanotron PyTorch FSDP2
主な並列化 テンソル (TP) + パイプライン (PP) データ (ZeRO) + パイプライン 3D (TP+PP+DP) シャーディングデータ (ZeROスタイル)
状態管理 複製 (TP) / 分割 (PP) 分割 (ZeRO 1/2/3) ハイブリッド パラメータごとのシャーディング
MoEサポート ネイティブ (MCore) DeepSpeed-MoE (最適化済) 基本機能 DTensor経由でネイティブ対応
開発者体験 高難易度 / 硬直的 中程度の複雑さ 高いハッカビリティ ネイティブ / Pythonic
最適な用途 Qwen 3 / DeepSeek 事前学習 異機種混在クラスタ 研究 / プロトタイピング ネイティブPyTorchユーザー

パート2:事後学習(Post-Training)フレームワーク

事後学習(SFTおよび選好アライメント)は、生の予測エンジンをプロダクトへと変える工程です。2025年のランドスケープはParameter Efficient Fine-Tuning (PEFT)によって支配されており、QwenやDeepSeekの特定のアーキテクチャをサポートするツールへの大規模なシフトが起きています。

2.1 Qwenのスペシャリスト:ms-swift (ModelScope)

リポジトリ: https://github.com/modelscope/ms-swift

Swiftは急速にファインチューニングにおける「スイスアーミーナイフ」となりました。特にQwenDeepSeekエコシステム内で活動するエンジニアにとっては必須のツールです。ModelScopeチームによって開発されたこのツールは、Qwen 3に見られる最新のアーキテクチャ上の癖(例:tie-embeddingの問題、VLMにおける動的解像度)に対して最も堅牢なサポートを提供します。

“Tuners” の抽象化

Swiftは、標準的なLoRAを超えた「Tuners」という高レベルな抽象化を導入しており、Res-Tuning(視覚言語)、NEFTune(ノイズ埋め込み)、LoRA+などをサポートしています。また、Swiftでファインチューニングされたモデルをコンテナ化された推論エンジンへとシームレスにエクスポートできる「Push-to-Deploy」ワークフローはユニークな特徴です。

2.2 設定エンジン:Axolotl

リポジトリ: https://github.com/axolotl-ai-cloud/axolotl

Axolotlは依然としてプロダクトパイプラインの旗手です。単一のYAML設定ファイルを介して学習の複雑さを隠蔽する、統一的なラッパーとして機能します。

  • マルチパッキング(Multipacking): Axolotlのサンプルパッキングの実装は効率化において重要です。シーケンスを連結することで、すべてのトークン位置でGPUが有用な勾配を計算できるようにします。
  • 2025年のアップデート: Axolotlは、消費者向けハードウェア上での70B+パラメータモデル向けに、FSDPおよびDeepSpeed Zero-3バックエンドを完全にサポートしました。

2.3 カーネルオプティマイザ:Unsloth

リポジトリ: https://github.com/unslothai/unsloth

Unslothは、Transformer層の標準的なPyTorch実装を置き換えるために、手書きのTritonカーネルを使用します。逆伝播のステップを手動で導出し、VRAM使用量を最大60%削減します。これにより、ハイエンドのコンシューマー向けGPU 1枚でQwen-3-72B(量子化版)のファインチューニングが可能になり、ローカル環境でのファインチューニングにおける第一選択肢となっています。

2.4 統合ワークフロー:LLaMA-Factory

リポジトリ: https://github.com/hiyouga/LLaMA-Factory

LLaMA-Factoryは、100以上のモデルをサポートする普遍的なフレームワークです。学習メトリクスをリアルタイムで可視化するWebUI (LLaMA Board)で有名です。GaLore (Gradient Low-Rank Projection) や DoRA のような高度なアダプタを実装し、SFT、DPO、PPOを単一のグラフィカルなパイプラインに統合しています。

技術比較分析:ファインチューニング

フレームワーク アーキテクチャ 最適化の焦点 最適な用途 インターフェース
ms-swift ネイティブラッパー Qwen/DeepSeekエコシステム マルチモーダル / アジア圏モデル CLI / Python / UI
Axolotl ラッパー (HF/Peft) スループット (Multipack) プロダクションパイプライン YAML Config
Unsloth カーネル置換 VRAM / 速度 コンシューマー向けハードウェア Python Library
LLaMA-Factory ラッパー (統合型) アルゴリズムの多様性 実験 / UI WebUI / CLI
HuggingFace TRL ネイティブライブラリ アライメント (DPO/ORPO) 研究 / カスタムRLHF Python Library

パート3:推論&デプロイメント(Inference & Deployment)フレームワーク

推論フェーズでは、新たな制約としてTime-to-First-Token (TTFT)Inter-Token Latency (ITL)が登場します。2025年のランドスケープは、ロングコンテキストでのやり取りにおいてKVキャッシュが生み出す「メモリの壁」との戦いです。

3.1 スループットの標準:vLLM

リポジトリ: https://github.com/vllm-project/vllm

vLLMは、KVキャッシュの断片化を解決するPagedAttentionによって、モダンなサービングを定義づけました。2025年の機能: vLLMは、限られたハードウェアでQwen 3-72Bを実行するために不可欠なFP8 KVキャッシングの堅牢なサポートを追加しました。また、Speculative Decoding(投機的デコーディング)Chunked Prefill(チャンク化プレフィル)もサポートしており、長いシステムプロンプトの処理が他のリクエスト生成を滞らせないようにしています。

3.2 構造化のスペシャリスト:SGLang

リポジトリ: https://github.com/sgl-project/sglang

SGLang (Structured Generation Language) は、DeepSeek-V3でよく見られる複雑でエージェンティック(自律的)なワークフローに最適化されています。KVキャッシュにはRadix Tree (RadixAttention)を使用します。

  • メカニズム: エージェントが思考し、計画し、行動する際、履歴を再利用します。SGLangはこれらのプレフィックス(接頭辞)を木構造でキャッシュします。
  • パフォーマンス: 「推論してから回答する(Reason then Answer)」ループにおいて、SGLangはvLLMと比較して最大5倍のスループットを達成します。

3.3 エンタープライズ・コンパイラ:NVIDIA TensorRT-LLM

リポジトリ: https://github.com/NVIDIA/TensorRT-LLM

TensorRT-LLMはコンパイラです。特定のGPU(例:H100)向けに最適化されたバイナリエンジンへとモデルをコンパイルします。レイヤーを積極的に融合(フュージョン)し、Hopper GPU上でのFP8推論におけるゴールドスタンダードとなっています。ただし、静的なコンパイルが必要なため、アダプタを動的に交換することはできません。

3.4 4-Bitのスピードスター:LMDeploy

リポジトリ: https://github.com/InternLM/lmdeploy

LMDeployはTurboMindエンジンを特徴としています。その際立った点は、W4A16(4bit重み、16bitアクティベーション)推論の極限的な最適化にあります。中国のモデルエコシステム(Qwen、DeepSeek、InternLM)に高度に最適化されており、シングルユーザーのレイテンシシナリオではvLLMを凌駕することがよくあります。

3.5 エッジの民主化:llama.cpp

リポジトリ: https://github.com/ggerganov/llama.cpp

データセンターがvLLMで稼働する一方、llama.cppはコンシューマー向けハードウェア、特にApple Silicon上での高性能な推論を独力で民主化しました。その「キラーアプリ」はGGUFファイルフォーマットであり、効率的なメモリマッピングとヘテロジニアスな計算を可能にし、レイヤーをCPUとGPUの間でシームレスに分割します。
“K-Quant”のアドバンテージ: llama.cppは、重要な重み行列の高い精度を維持しつつ他を圧縮する洗練された量子化手法(Q4_K_Mなど)を利用します。これにより、MacBook Pro上でDeepSeek-V3Qwen-3-Instructのような巨大モデルを実用的な速度でローカル実行することが可能になり、OllamaLM StudioといったローカルAIツールの全エコシステムを支えています。

技術比較分析:推論

エンジン コアメカニズム キャッシュ戦略 最適なユースケース 量子化の焦点
vLLM PagedAttention ブロックテーブル 一般的なサービング / 高QPS AWQ / GPTQ / FP8
SGLang RadixAttention Radix Tree (LRU) エージェント / 推論ループ AWQ / FP8
TensorRT-LLM コンパイラ / フュージョン 静的割り当て エンタープライズ / H100クラスタ FP8 / INT8
LMDeploy TurboMind 永続的バッチ Qwen 4-bitサービング AWQ / W4A16
llama.cpp GGUF / Metal 線形 / Mmap エッジ / CPU / Apple Silicon GGUF (K-Quants)

パート4:スタックの未来

2025年後半のトレンドは「境界の消失」です。学習フレームワークが推論機能を追加し(例:DeepSpeed-MII)、推論エンジンが学習機能を追加する様子が見られます。現在追求されている「聖杯」は、エンドツーエンドFP8パイプラインです。Qwen 3の最初の事前学習ステップからvLLMでの最後のトークン生成まで、モデルをFP8のまま維持し、スタックを統合してインテリジェンスのコストを劇的に削減することが目標です。2026年のエンジニアにとって、選択は戦略的なものになります。

  • 基盤: Megatron-LM(スケール) または DeepSpeed(異機種混在)
  • 洗練: ms-swift(Qwen/マルチモーダル) または Axolotl(プロダクション設定)
  • デプロイ: vLLM(汎用API) または SGLang(エージェンティック/推論)

2025年後半のLLMスタックは、ツールの「カンブリア爆発」を超え、アーキテクチャの専門化によって定義される統合フェーズへと移行しました。この領域での成功は、もはや独自の分散学習ループを書くことではなく、これら成熟したフレームワークのオーケストレーションを習得することにあります。勝利のためのエンジニアリング戦略は、特定の制約ボトルネックに対して適切なツールを選択することにあります。事前学習における計算ボトルネックを克服するためのMegatron-Core、事後学習のアルゴリズム的なニュアンスをナビゲートするためのms-swift/Axolotl、そして推論のメモリ帯域幅ボトルネックを解決するためのvLLM/SGLangです。Qwen 3やDeepSeek-V3のようなモデルがコンテキスト長と論理の限界を押し広げるにつれ、これらのレイヤー間の摩擦は減少し、最終的には人工知能のための統一された、コンパイラ駆動型のOSが生まれることになるでしょう。