Miles: A PyTorch-Native Stack for Large-Scale LLM RL Post-Training

背景 / Background

2025年3月13日、オープンソースAIコミュニティは、大規模言語モデル（LLM）の大規模強化学習（RL）ポストトレーニング向けに設計されたPyTorchネイティブのソフトウェアスタック Miles のリリースを迎えました。この発表は、Zhewei Yao、Cheng-Ping Hsieh、Jie Ren、Hong Xu、およびMilesチームと広範なオープンソースRLコミュニティに所属する他の貢献者を含む著者チームによって、Hugging Faceブログで公開されました。

Milesスタックは、現代のLLM開発における重要なボトルネックであるポストトレーニングフェーズに対処します。膨大なテキストコーパスでの大規模モデルの事前学習はますます標準化されてきていますが、その後の段階である強化学習を用いたモデルの微調整（人間の好みに合わせたり、複雑な推論タスクを解決したりするため）は、断片化され、計算コストが高く、スケーリングが困難なままです。Milesは、複数のモデルコピー（アクター、クリティック、リファレンス）の管理、大規模分散トレーニングの処理、vLLM推論サーバやリモートエクスペリエンスバッファのような高度な機能のサポートなど、RLベースのポストトレーニングの独自の要求に対応できる、統一されたPyTorchネイティブソリューションを提供することを目指しています。

プロジェクト名「Miles」と、オープンソースLLM RLのために「もうひと踏ん張り（go the extra mile）」するというその目標は、既存のトレーニングフレームワークを超えようとするチームの野心を反映しています。著者らはMilesをRLポストトレーニングの民主化に向けた一歩として位置づけ、大規模AIラボのインフラを持たない可能性がある、より幅広い研究者や実務者が利用できるようにすることを目指しています。

社媒反応 / Social reception

Milesの発表は、AI研究・エンジニアリングコミュニティ全体で即座に議論を巻き起こしました。Hugging Faceのブログ記事自体では、この発表はユーザーから肯定的なフィードバックを受けました。コメント投稿者のAndrea氏は、「これは素晴らしい成果です！オープンソースLLMアライメント研究の限界を本当に押し広げています。チームの皆さん、おめでとうございます！」と書き込んでいます。別のユーザーJuarez氏は、このプロジェクトがRLトレーニングワークフローを標準化する可能性に熱意を示し、「これは信じられないほどです！オープンソースコミュニティに標準的なRLトレーニングフレームワークができる可能性に、とても興奮しています。おめでとうございます！」と述べています。

Hacker Newsでは、このリリースはLLMに対するRLの実践的な実装に関する技術的な議論を引き起こしました。ユーザー「kriiu」は、RL微調整に固有の多大なメモリオーバーヘッドを指摘し、「RL微調整は、複数のモデルコピーをメモリに保持する必要があるため、莫大なメモリオーバーヘッドが発生します」と述べています。このコメントは、技術的な深みを評価する他のユーザーから賞賛され、ユーザー「hackitup123」は「良いコメントです、ありがとう」と応答しました。

別のHacker Newsのスレッドでは、RLポストトレーニングの現在の限界について探求されました。ユーザー「cma」は、アクセスしやすいワークフローが不足していることを強調し、「ChatGPTファミリーについてはわかりませんが、オープンモデルの場合、RLベースのポストトレーニングはSFT（教師あり微調整）と比較して著しく困難です。人々が確実に使用できるオープンソースのワークフローは非常に少なく、通常はいくつかの古い論文に基づいてすべてをゼロから構築する必要があります」とコメントしています。この意見は、Milesが埋めようとしているギャップを浮き彫りにしています。

Redditでは、r/MachineLearningコミュニティが、興味と批判的な技術的質問が混ざり合った反応を示しました。「Proud_Ad_9632」というユーザー名のユーザーは、特定の実装選択について鋭い質問をしました。「RLは通常、PPOまたはGRPOを使用して行われます。GRPOは計算コストが低く、現在のRLフレームワークにより自然に適合します。なぜ著者がMilesにGRPOではなくPPOを依然として選択したのか、興味があります。実際、ブログ記事ではGRPOについて全く言及されていませんでした。」 この質問は、どのRLアルゴリズムがLLMポストトレーニングに最も適しているかという分野における重要な議論を浮き彫りにしており、MilesがPPO（Proximal Policy Optimization）に焦点を当てていることは、保守的な選択と見なされる可能性があります。

別のRedditコメント投稿者「muhaha」は、特にトレーニング中の推論サーバへのvLLMの統合に関して、フレームワークの実用的なユーザビリティについて懸念を提起しました。「Milesは推論サーバにvLLMを使用しています。vLLMは高スループットで知られています...しかし、トレーニングの初期ステップのように送信するトークンが少ない場合、vLLMはvLLM税（CUDAグラフ作成などのコスト）に悩まされます。多くのイテレーションでは、オーバーヘッドが大きくなります。また、別の推論エンジンを使用することは通常、同じモデルの2つのコピーにメモリを浪費しなければならないことを意味します。」 この技術的な批判は、Milesが広く採用されるために対処する必要がある、現実世界のエンジニアリング上の課題を指摘しています。

Redditでは、LLMポストトレーニングにおけるRLの性質について、より哲学的なやり取りも行われました。ユーザー「jacobmart」は、「LLMトレーニングの文脈におけるRLは、通常、探索や世界モデルがないため、古典的な意味でのRLではない」と主張し、ユーザー「lucy_jem」は「PPOは文字通り、価値関数を使用するポリシー勾配法です。『RLHF』における『RL』はPPOまたはその変種を使用します。環境がインタラクティブでないからといって、それがRLでなくなるわけではありません。」と反論しました。 この議論は、この分野における進行中の定義上の緊張関係を反映しています。

追加の肯定的な反応は、MilesのGitHubリポジトリでも見られ、ユーザー「tiancheng li」は「amazing work!」とコメントし、 ユーザー「lvshuhao」は「Great project!」と書き込んでいます。

学術的関連性 / Academic context

Milesは、RLベースのLLMポストトレーニングにおけるいくつかの重要な研究系譜に基づいて構築され、それらを統合しています。このスタックの設計は、DeepSpeedコミュニティのRLHF（人間からのフィードバックによる強化学習）に関する研究から影響を受けていますが、カスタムCUDAカーネルやDeepSpeed固有のインフラに依存するのではなく、完全にPyTorchエコシステム内で構築されている点で差別化されています。 この選択は、メンテナンスや拡張が容易なPyTorchネイティブソリューションへのAIコミュニティの広範なトレンドと一致しています。

Milesがサポートする主要なRLアルゴリズムは、確立されたポリシー勾配法であるProximal Policy Optimization（PPO）です。PPOは2017年にSchulmanらによって導入され、LLMにおけるRLHFの標準アルゴリズムとなり、ChatGPTのトレーニングで有名に使用されました。GRPO（Group Relative Policy Optimization）のようなより新しい代替手法ではなくPPOを選択したことは、計算効率とアルゴリズムの成熟度との間のトレードオフを反映しています。DeepSeek R1によって導入されたGRPOは、別個のクリティックモデルの必要性を排除し、理論的にはメモリ要件を削減します。しかし、PPOのより長い実績とより広範な理論的基盤は、汎用フレームワークにとってより安全な選択肢となる可能性があります。

Milesはまた、UC BerkeleyのvLLMチームによって開発された高スループット推論エンジンであるvLLMとも統合されています。vLLMは、PagedAttentionによる効率的なメモリ管理で知られており、ナイーブな実装よりもはるかに高いスループットでLLMを提供できます。RLトレーニング中に推論サーバとしてvLLMを使用することで、アクターモデルがより効率的に応答（ロールアウト）を生成できるようになり、これはRLトレーニングのデータ多消費型の性質にとって重要です。

トレーニングエンジンは、PyTorch FSDP（Fully Sharded Data Parallelism）とtorch.compileという、PyTorchエコシステムからの2つの重要な技術に基づいて構築されています。FSDPは、モデルパラメータ、勾配、オプティマイザ状態を複数のGPU間で効率的にシャーディングすることを可能にし、単一のGPUには大きすぎるモデルのトレーニングを可能にします。torch.compileは、PyTorchモデルのジャストインタイムコンパイルを提供し、より高速な実行のために計算グラフを最適化します。

このスタックのアーキテクチャにはリモートエクスペリエンスバッファが含まれており、推論サーバ（vLLM）とトレーニングエンジンを別々のGPUクラスタ上で実行できます。この分離は、生成ワークロードとトレーニングワークロードが異なるリソース要件とスケーリング動作を持つ可能性があるプロダクションデプロイにおいて重要です。エクスペリエンスバッファは、アクターモデルによって生成されたロールアウトを保存し、それらをトレーニングエンジンに供給して、非同期トレーニングループを可能にします。

Milesの設計は、RLポストトレーニングの「メモリ税」にも対処しています。RLHF形式のトレーニングでは、4つのモデルコピーを同時に維持する必要があります：トレーニング中のアクター（ポリシー）モデル、状態の価値を推定するクリティック（バリュー）モデル、KLダイバージェンス正則化に使用されるリファレンスアクターモデル、そしてリファレンスクリティックモデルです。LoRA（Low-Rank Adaptation）のようなパラメータ効率的な微調整（PEFT）技術を使用することで、Milesはこれらの追加モデルコピーのメモリフットプリントを大幅に削減できます。

ブログ記事では、Milesが最大70Bパラメータのモデルのトレーニングをサポートしていると明示的に述べており、これは「大規模」LLMポストトレーニングフレームワークのカテゴリに位置づけられます。このスケールは、複数のGPUノードにアクセスできるが、大規模AIラボのような専門的なインフラを持たない可能性がある組織のニーズに対応するため、重要です。

原始出处 / Origin

このブリーフィングの主要な情報源は、Zhewei Yao、Cheng-Ping Hsieh、Jie Ren、Hong Xu、およびMilesチームによって著された、Hugging Faceのブログ記事「Miles: A PyTorch-Native Stack for Large-Scale LLM RL Post-Training」です。 この記事は2025年3月13日に公開され、プロジェクトの公式発表として機能しています。

ブログ記事には、オープンソースコードをホストするMilesのGitHubリポジトリへのリンクが含まれています。コミュニティの反応は、ソーシャルレセプションのセクションで引用されているように、Hugging Faceのブログコメント、Hacker Newsの議論、Redditのスレッド（r/MachineLearning）、およびGitHubリポジトリのIssueとディスカッションページから収集されました。

会社と製品 / Company & product

Milesはオープンソースプロジェクトであり、商用製品ではありません。オープンソースライセンス（具体的なライセンスはブログ記事で詳述されていませんが、プロジェクトの位置づけから許容的なライセンスであると予想されます）の下でリリースされています。このプロジェクトはコミュニティ主導のようであり、複数の著者からの貢献があり、様々な機関に所属していますが、ブログ記事は機関の所属を明示的に列挙していません。

「製品」はMilesソフトウェアスタックそのものであり、「大規模LLM RLポストトレーニングのためのPyTorchネイティブスタック」と説明されています。このスタックには、以下のいくつかの主要なコンポーネントが含まれています：

1. トレーニングエンジン：PyTorch FSDPとtorch.compile上に構築されたこのエンジンは、アクターモデルとクリティックモデルの勾配ベースの最適化を処理します。複数のGPUとノードにわたる分散トレーニングをサポートします。

2. 推論サーバ：vLLMを搭載したこのコンポーネントは、トレーニング中のロールアウト（モデルの応答）の生成を処理します。トレーニングエンジンとは独立してスケーリングできる別のサービスとして実行されます。

3. リモートエクスペリエンスバッファ：推論サーバによって生成されたロールアウトを保存し、トレーニングエンジンに供給する分散バッファです。これにより、非同期トレーニングが可能になり、生成ワークロードとトレーニングワークロードが分離されます。

4. PEFT統合：モデルパラメータの小さなサブセットのみを更新することでトレーニングのメモリフットプリントを削減する、LoRAのようなパラメータ効率的な微調整技術のサポート。

5. RLアルゴリズム実装：PPOベースのRLHFのサポートと、他のアルゴリズムに拡張する柔軟性。

このプロジェクトは、大規模AIラボで使用される独自のRLポストトレーニングシステムに対するオープンソースの代替手段として位置づけられています。PyTorchネイティブの実装と、FSDP、torch.compile、vLLMのような広く採用されているツールとの統合を重視していることは、より広範なAI研究コミュニティにとってのアクセシビリティと使いやすさに焦点を当てていることを示唆しています。

総合評価 / Synthesis

Milesは、オープンソースLLMポストトレーニングエコシステムへの重要な貢献を表しています。このプロジェクトは本物のニーズに対処しています。RLベースのポストトレーニングは、LLM開発の中で最も困難で標準化が進んでいない側面の一つであり、既存のオープンソースソリューションはしばしば断片化され、スケーリングが困難であるか、特定のハードウェアやソフトウェアスタックに縛られています。

強みと機会：

1. PyTorchネイティブ設計：PyTorch FSDPとtorch.compile上に構築することで、Milesは研究コミュニティで最も広く採用されているディープラーニングフレームワークを活用しています。これにより、既にPyTorchエコシステムに精通している研究者や実務者にとっての参入障壁が低くなり、カスタムカーネルや専門的なインフラを必要とするフレームワークに関連するロックインを回避できます。

2. vLLMとの統合：推論サーバにvLLMを使用することは、vLLMの実証済みのパフォーマンスと広範な採用を考えると実用的な選択です。しかし、コミュニティの反応で指摘されているように、この統合はバッチサイズが小さいトレーニングの初期段階におけるレイテンシのオーバーヘッドに関連する課題ももたらします。

3. スケール能力：最大70Bパラメータのモデルをサポートすると明記されていることで、Milesは単なるおもちゃや研究プロトタイプではなく、本格的な大規模作業のためのツールとして位置づけられています。これは、大規模モデルを微調整する必要があるが、独自のインフラを開発するリソースを持たない可能性がある組織による採用にとって重要です。

4. オープンソースの精神：オープンソースの原則へのプロジェクトのコミットメントは、AI研究の民主化に向けた広範なトレンドと一致しています。十分に文書化され、アクセスしやすいフレームワークを提供することで、Milesは分野全体のRLベースのポストトレーニングの進歩を加速する可能性を秘めています。

課題と批判：

1. アルゴリズムの選択：GRPOのようなより新しい代替手法ではなくPPOに焦点を当てるという決定は、保守的と見なされる可能性があります。クリティックモデルを排除するGRPOは、メモリと計算の大幅な節約を提供し、Milesにそれが含まれていないことは、より効率的なRL手法に取り組む研究者へのフレームワークの魅力を制限する可能性があります。Redditユーザー「Proud_Ad_9632」によるコメントは、この懸念を浮き彫りにしています。

2. vLLM統合のオーバーヘッド：Redditユーザー「muhaha」によるvLLM税（小バッチ生成時のCUDAグラフ作成オーバーヘッド）に関する技術的な批判は、正当なエンジニアリング上の懸念です。vLLMは大規模なバッチサイズでの高スループットサービングに優れていますが、RLトレーニングは特に初期段階ではより小さなバッチを伴うことがよくあります。これにより、トレーニングが定常状態に達するまで、最適以下のパフォーマンスが発生する可能性があります。

3. 詳細の欠如：ブログ記事は高レベルのアーキテクチャと機能に焦点を当てていますが、詳細なベンチマーク、既存のフレームワーク（例：DeepSpeed Chat、TRL、Axolotl）とのパフォーマンス比較、または特定の設計選択の影響を示すアブレーション研究が欠けています。そのようなデータがなければ、潜在的なユーザーがMilesが既存のソリューションよりも意味のある改善を提供するかどうかを評価することは困難です。

4. 導入の複雑さ：フレームワークに関係なく、RLポストトレーニングは複雑なワークフローのままです。推論サーバ（vLLM）とトレーニングエンジン（FSDP）を同時に実行し、その間にリモートエクスペリエンスバッファを配置する必要があることは、小規模なチームや個人の研究者にとっては困難な運用上の複雑さをもたらします。

全体評価：

Milesは、LLMポストトレーニングツールキットへの、よく動機付けられ、思慮深く設計された追加です。そのPyTorchネイティブのアプローチ、vLLMとの統合、大規模トレーニングのサポートは、オープンソースエコシステムにおける真の痛点に対処しています。Hugging Face、Hacker News、GitHubでの肯定的な受け止められ方は、そのようなフレームワークに対する強い需要があることを示唆しています。

しかし、このプロジェクトは大きな逆風に直面しています。RLポストトレーニングの分野は急速に発展しており、新しいアルゴリズム（GRPO、REINFORCE変種など）やフレームワーク（DeepSpeed Chat、TRL、Axolotlなど）が定期的に登場しています。Milesは、それが機能することを示すだけでなく、既存の代替手段よりも優れているか、使用が著しく容易であることを示す必要があります。発表時に詳細なベンチマークが欠けていることは、顕著なギャップです。

さらに、コミュニティから提起された技術的な課題、特にvLLM統合のオーバーヘッドとPPOの選択に関するものは、Milesがユーザーの期待するパフォーマンスと効率を達成するために追加のエンジニアリング努力を必要とする可能性があることを示唆しています。プロジェクトの長期的な成功は、チームが迅速に反復し、コミュニティのフィードバックに応答し、急速に進化する研究環境に対応し続ける能力に依存します。

要約すると、MilesはオープンソースコミュニティにおけるLLMのRLポストトレーニングを標準化するための有望な一歩です。それは完成品ではなく、LLMアライメント研究の重要なインフラストラクチャになる可能性を秘めた初期段階のプロジェクトです。RLHFとLLMポストトレーニングに関心のある研究者や実務者は、プロジェクトの開発を注意深く監視すべきですが、プロダクションで採用する前に、それが特定のパフォーマンスとユーザビリティの要件を満たしていることを確認する必要があります。

参考文献 / References