LoRA Speedrunリーダーボード、Qwen2.5-1.5Bのファインチューニングを6分05秒に短縮し、GSM8K正解率61.1%を達成

LoRA Speedrunは、GSM8Kで完全一致正解率61.1%を達成した、Qwen2.5-1.5Bのファインチューニング記録6分05秒を公開しました。この結果は、プロジェクトのベースラインである11分57秒から49%短縮すると同時に、より高い評価スコアを達成しています。

この改善には、より大規模なGPUや異なるベースモデル、より多くの学習可能パラメータは必要ありませんでした。どちらの実行でも、1基のNvidia L40Sと同じランク16のLoRA構成が使用されています。記録を生んだのは、トレーニング例の配置方法と、どのトークンを損失計算に含めるかの変更でした。

この違いにより、LoRA Speedrunリーダーボードは単発の最適化に関する主張以上に興味深いものとなっています。固定されたタスク、ハードウェア、正解率の基準、検証プロトコルによって、ファインチューニング性能が再現可能なシステム競争へと変わります。中心となる対決は、もはやモデル同士ではありません。効率的なデータ処理と、回避可能なパディングやプロンプトトークンに計算資源を費やす従来型トレーニングパイプラインとの競争です。

LoRA Speedrunリーダーボードが勝利の定義を変える

注目すべき結果は、同じ公開トラックのルール下で、実時間の短縮とスコアの向上を両立していることです。

開発者のSaivineethは、2026年7月18日にベースラインと現在の記録の両方を公開しました。プロジェクトの最初のトラックでは、参加者が1基のL40S GPUを使用し、GSM8Kのトレーニング用分割データでQwen2.5-1.5Bをファインチューニングすることが求められます。

提出結果は、完全一致正解率で少なくとも57%に到達する必要があります。完全一致とは、抽出された最終回答が、期待される推論に似ているだけでなく、参照回答と等しくなければならないことを意味します。

ベースラインは3エポックのトレーニングを行い、11分57秒で完了しました。プロジェクトのGSM8K評価では59.4%を記録しています。より高速な提出結果は2エポックをトレーニングし、6分05秒で完了して、61.1%を記録しました。

これらの数値は5分52秒の短縮を示しています。また、プロジェクトの評価環境内で正解率が1.7パーセントポイント向上したことも示しています。時間の改善率は約49%であり、リポジトリが簡潔に表現する「ほぼ2倍の高速化」を裏付けています。

プロジェクトは、リーダーボード、タスク仕様、スクリプト、検証用成果物をspeedrunリポジトリで公開しています。この透明性が重要なのは、ファインチューニング速度に関する主張では、異なるモデル、アクセラレーター、データセット、停止条件が混在することが多いためです。

LoRA（低ランク適応）は、元のモデルの重みを固定し、選択した層に付加された小さな行列をトレーニングします。元のLoRA論文では、学習可能パラメータとメモリ要件を削減する方法として、このアプローチが提示されました。

LoRA Speedrunでは、提出結果を学習可能パラメータ3,000万以下のアダプターのみのトレーニングに制限しています。一方で、参加者はアダプターの配置、ランク、スケジュール、トレーニング例の順序、カーネル、量子化、停止動作を変更できます。

この自由度が、有意義なエンジニアリング競争の余地を生み出します。これらの制約により、タスクを置き換えたり、GPUを追加したり、モデルの全パラメータをファインチューニングしたりするだけで勝つことはできません。

指標となるのはトレーニングの実時間であり、浮動小数点演算数やトレーニングステップ数ではありません。実時間の計測には、データ読み込み、パディング、カーネルの動作、オプティマイザーの処理など、実際の実行中に生じるコストが含まれます。

タイマーは、エンドツーエンドのモデルプロジェクトにおける全段階を計測するものではありません。評価はトレーニング時間に含まれず、リポジトリはモデルとデータセットのファイルを事前取得できます。したがって、この記録が表しているのは管理されたトレーニング競争であり、本番環境へのデプロイに要する総時間ではありません。

それでも、この管理された範囲こそがプロジェクトの主な利点です。狭く定義された記録であれば、広範で文書化が不十分な比較では隠れがちな最適化効果を明らかにできます。

この設計は、トレーニング目標を固定し、より高速な実装を募る公開競技であるmodded-nanoGPTの精神を受け継いでいます。LoRA Speedrunは、その形式をモデルの事前学習ではなく、パラメータ効率の高い適応に応用しています。

この記録は、今後の提出結果に単純な問いを投げかけます。同じ正解率基準を3回満たしながら、別の手法で6分05秒を上回れるでしょうか。これは、あるファインチューニングライブラリが一般的に高速だと主張するよりも検証しやすい問いです。

データ効率がファインチューニングフレームワークに圧力をかける理由

この結果は、利得の大半がアダプターの数学的手法ではなく、トークン利用方法の変更から得られたため、デフォルトのトレーニングパイプラインに再考を迫っています。

多くのファインチューニング比較では、アダプターのランク、量子化、オプティマイザーの選択、GPUクラスに焦点が当てられます。これらの変数は重要ですが、一般的なバッチ内部で発生する無駄な処理から注意をそらす可能性があります。

長さが異なるトレーニング例は通常、バッチ内のすべてのシーケンスが同じ長さになるようパディングされます。パディングトークンによってテンソルは処理しやすくなりますが、有用なトレーニング内容が追加されるわけではありません。

あるトレーニング例が隣接する例よりはるかに長い場合、短い例にはより多くのパディングが追加されます。アクセラレーターは、学習にほとんど、あるいはまったく貢献しない位置まで処理することになります。

シーケンスパッキングは、複数のトレーニング例を共有の固定長シーケンスに配置することで、この問題に対処します。より優れたパッキングにより、各フォワードパスとバックワードパスで処理される有用なトークンの割合が高まります。

優勝した提出結果は、パッキングと完了部分のみを対象とする損失マスキングを組み合わせました。このマスキングでは、プロンプト部分を学習目標から除外し、応答トークンのみでトレーニング損失を計算します。

プロンプトは引き続きコンテキストを提供します。しかし、オプティマイザーは、質問文を再現するようモデルに学習させることを目標にはしません。

これらの変更は、2種類の非効率性をそれぞれ対象としています。パッキングは未使用のシーケンス空間を減らし、完了部分のみのマスキングは学習信号を望ましい出力に集中させます。

優勝した実行では、ベースラインの3エポックではなく2エポックが使用されました。エポックとは、選択されたトレーニングデータ全体を1回処理することです。モデルが引き続き正解率基準を超えられるなら、1エポックを削減することで大幅に処理を減らせます。

ここで61.1%というスコアが極めて重要になります。どれほど効率的にトークンを処理しても、57%を下回る高速な実行は失格となります。

より高速な提出結果は、単にぎりぎりで基準を超えたわけではありません。公開されている検証レポートによると、採用された結果はプロジェクト所定の再実行と監査を通過しています。

この発見は、人気のあるファインチューニングスタックの保守担当者に、デフォルト設定の再検討を迫ります。利便性を重視するパイプラインでは、多くのデータセットで機能するという理由から、単純なバッチ処理と全シーケンス損失が優先される場合があります。

Speedrunは異なる問いを投げかけます。タスクと出力形式が予測可能になったとき、汎用的な利便性のための設計が、どの程度の測定可能なコストを課すのかという問いです。

この圧力は、社内の機械学習チームにも及びます。チームは、パディング率、1秒当たりの有用なトークン数、不要な損失計算を測定する前に、より新しいアクセラレーターの比較に時間を費やしているかもしれません。

ハードウェアのアップグレードは実行時間を短縮できますが、非効率なデータ準備はそのまま残る可能性があります。ソフトウェアによる改善は、モデル品質の目標を変更することなく、対応する複数のアクセラレーターに適用できる場合があります。

LoRA Speedrunの結果は、普遍的な49%の短縮を証明するものではありません。利得は、シーケンス長の分布、プロンプト形式、バッチ構成、実際に必要なエポック数によって異なります。

均一な長さのトレーニング例を含むデータセットでは、パッキングによる効果は小さくなります。すべてのトークンのモデリングが必要なタスクでは、同じ方法で完了部分のみのマスキングを利用できない可能性があります。

それでも、この記録によって立証責任は変わります。パッキングを無視するファインチューニングパイプラインは、なぜそのワークロードがより高密度なトークン利用の恩恵を受けないのかを説明する必要があります。

同じことが損失設計にも当てはまります。チームは、会話の記録全体をモデルに学習させたいのか、アシスタントの応答部分だけを学習させたいのかを明確にする必要があります。

開発者にとって、これらの問いは実験速度に影響します。実行時間が短くなれば、同じ計算時間内で、より多くのスケジュール、アダプター配置、データ選択をテストできます。

組織にとって、より大きな影響は反復能力です。運用上の価値は、単一の6分間のジョブを称賛することではなく、より多くの管理された実験を実行できることにあります。

チームには、構成、データセット、評価上の判断に関する記録も必要です。検索可能なエンジニアリングナレッジベースは、あるトレーニング手法が別の手法に置き換えられた理由を保存するのに役立ちます。

こうした記録がなければ、反復が高速化しても、実験数だけが増え、組織としての理解が深まらない可能性があります。どの変更が結果を引き起こしたのかをチームが再現できる場合にのみ、速度は価値を持ちます。

パッキングと損失マスキングが単純なLoRAベースラインを上回る

主な競争は、最適化されたトークン処理と、利便性を中立的な選択肢として扱う単純なLoRAパイプラインとの間で繰り広げられています。

ベースラインでは、すべての線形層にランク16のLoRAアダプターを適用し、3エポックとコサイン学習率スケジュールを使用しました。記録を達成した実行でも、同じ中核的なアダプター構成が維持されています。

このため、比較の焦点は非常に明確です。優勝したアプローチは、LoRAから別のパラメータ効率の高い手法に切り替えたわけでも、アダプターの規模を縮小したわけでもありません。

シーケンスパッキングは、各モデル入力の構成を変更します。各トレーニング例を個別にパディングする代わりに、パイプラインは複数のトレーニングレコードを、より長く、より隙間なく使われるシーケンスに収めます。

正しい実装では、トレーニング例の境界を維持する必要があります。ある問題のトークンが別の問題に対する意図しないコンテキストになったり、パッキングされたレコード間でラベルが破損したりしてはなりません。

完了部分のみのマスキングは、ターゲットラベルを変更します。プロンプト位置には無視対象のラベルが割り当てられ、応答位置はクロスエントロピー損失の対象として維持されます。

クロスエントロピー損失は、期待される次のトークンにモデルがどれだけの確率を割り当てるかを測定します。マスキングされた位置は、その計算にも、関連する学習信号にも寄与しません。

この組み合わせにより、単位時間当たりの有用な処理量が向上します。パッキングによってモデルを通過する空の位置が減り、マスキングによって最適化が回答生成に集中します。

2エポックのスケジュールも直接的な短縮に貢献しています。しかし、バッチ構成と学習目標の集中を考慮しなければ、エポック数を減らしただけで報告されたスコアが向上したことは説明できません。

したがって、この結果は新しいLoRAアルゴリズムというより、規律あるシステムエンジニアリングの成果に見えます。周辺の無駄を減らすことで、同じアダプター設計からより多くの価値を引き出しています。

この違いは、この記録をQLoRA、DoRA、PiSSA、rsLoRA、LoRA+などの手法と比較する際に重要です。これらの手法は、精度、パラメータ化、初期化、スケーリング、学習率を変更します。

LoRA Speedrunでは、これらの手法のいくつかを達成済みの勝利ではなく、未解決の方向性として挙げています。将来の提出結果では、これらをパッキングと組み合わせるか、この短時間の実行ではオーバーヘッドが利点を上回ることが判明するかもしれません。

たとえば、量子化はメモリ使用量を削減できますが、量子化と逆量子化にも追加の処理が必要です。すでに無理なく収まる15億パラメータのモデルでは、メモリ削減が自動的に実時間の短縮につながるわけではありません。

カスタムカーネルにも同様のトレードオフがあります。融合演算はメモリ移動と起動オーバーヘッドを削減できますが、コンパイル時間や形状の制約により、短時間のトレーニングジョブが複雑になる可能性があります。

公開レースは、これらのトレードオフを共通の尺度で明らかにする。手法が勝つのは、その全トレーニング工程がより速く完了し、なおかつ評価要件を満たす場合に限られる。

この焦点によって、研究上の新規性と運用上の有用性が区別される。科学的に興味深い手法であっても、このトラックを改善するとは限らない一方、単純なバッチ処理の変更がリーダーボードを席巻することもある。

Qwenベースモデルも競争の性質を形作っている。公式のQwenモデルカードでは、15億4,000万パラメータ、コンテキスト長32,768トークンの因果言語モデルと説明されている。

このスピードランでは、その最大コンテキスト長全体をテストするわけではない。実際のシーケンス処理負荷は、設定、タスクのフォーマット、バッチ制限によって決まる。

GSM8Kには、複数ステップの推論を必要とする小学校レベルの算数文章題が収録されている。オリジナルのGSM8Kデータセットには、7,473件のトレーニング問題と1,319件のテスト問題が含まれている。

答えを自動評価できるため、このベンチマークは今なお有用である。ただし、単一の完全一致スコアでは、幅広い数学的推論能力、信頼性、未知の領域における挙動までは測定できない。

このプロジェクトは、別の懸念も認識している。現代のベースモデルは、事前トレーニング中に類似した数学コンテンツに接していた可能性がある。リーダーボードでは57%を最適化目標として扱っており、新たに発見された推論能力の証拠とは見なしていない。

この位置づけは重要である。この記録を、公開されているあらゆるQwen2.5-1.5Bのベンチマークスコアと直接比較すべきではない。

プロンプトテンプレート、デコード規則、回答抽出、モデルのバリアント、評価ハーネスによって、GSM8Kの結果は変わり得る。Qwen2.5-1.5BとQwen2.5-1.5B-Instructも別個のチェックポイントである。

有効なのは内部比較である。プロジェクトで固定されたトラックの条件下では、パッキングを用いた2エポックの提出物が、公開ベースラインより速く完了し、より高いスコアを記録した。

より広範な主張を行うには、他のモデルファミリーやタスクでの再現が必要である。この要件は、プロジェクトの第2トラックへと直接つながっている。

61.1%という結果は、意図的に限定された意味を持つ

リーダーボードはスクリーンショットより強力な検証を提供するが、現在の証拠では普遍的なファインチューニング手法は確立されていない。

各候補記録は、コード、設定の詳細、注記、自己申告の結果を含むプルリクエストとして提出される。その後、継続的インテグレーションによって静的検証が実行される。

リポジトリによると、自動セキュリティレビューでは、ネットワークアクセス、テストセットへの接触、ハーネスの改ざん、データ流出の試みがチェックされる。公式実行の前には、メンテナーが提出物を承認しなければならない。

検証ハーネスは、承認されたコードを新しいシードで3回実行する。3回すべてが目標を上回る必要があり、その平均値が公式タイムとなる。

これらの実行は、指定されたL40Sを使用し、ネットワークが遮断されたModalサンドボックス内で行われる。ハーネスは、トレーニング可能なアダプターパラメータを監査し、モデルとデータセットのハッシュも確認する。

審査プロトコルは、単独のベンチマーク投稿より多くの情報を提供する。受け入れ規則が定義され、他の開発者が確認できる成果物も残される。

Modalは、L40Sを48 GBのGPUメモリを搭載したサポート対象アクセラレーターとして記載している。同社のGPUドキュメントでは、固定されたアクセラレーター名を使用することで、ユーザーが特定のハードウェアクラスを指定できるとも説明している。

しかし、3回の再実行だけですべての変動要因を解消できるわけではない。ホストの挙動、ソフトウェアバージョン、温度条件、クラウドのスケジューリングは、短時間の実時間測定に依然として影響を与え得る。

6分間の実行では、小さなオーバーヘッドの重要性が増す。起動時の挙動、キャッシュされた成果物、データローダーのタイミング、コンパイルに関する判断が、総時間に占める割合は大きくなる。

プロジェクトは、環境を固定し、同一のハードウェアを使用することで、こうした懸念の一部に対処している。公開検証レポートからは、提案された改善が新しいシードでも維持されるかどうかも確認できる。

それでも、この記録は1つのモデルとタスクの組み合わせに属する。GSM8Kのプロンプトと回答は比較的構造化されているため、補完部分に焦点を当てたトレーニングに有利に働く可能性がある。

他のタスクでは、シーケンス全体にわたってフォーマットを再現する能力がモデルに求められる場合がある。対話トレーニングには、複数のアシスタントターン、ツール呼び出し、システム指示、選好ラベルなどが含まれる可能性もある。

サンプルが複雑なアテンションマスクを使用する場合、パッキングも難しくなる。単純な実装では、サンプル境界を越えた情報漏洩を許したり、位置に関する挙動を歪めたりする可能性がある。

第2トラックは、この制約に対するプロジェクト初の回答である。このトラックでは、SmolLM2-1.7Bと、異なる入出力特性を持つ質問応答データセットSQuAD v1.1を組み合わせている。

2026年7月21日時点で、このトラックには完全一致率77.5%、11分8秒のベースラインが掲載されている。SQuADのトレーニングサンプルの先頭20,000件を使用し、1エポックでトレーニングしている。

記録を樹立したパッキング手法は、まだ両方のトラックで首位を獲得していない。したがって、リポジトリ自体が、トラック固有の記録と一般的に転用可能な手法を区別している。

これが最も重要な懐疑的解釈である。6:05という結果は、固定条件下での最適化を実証しているが、転用可能性は依然として未解決の実証的課題である。

また、リーダーボードは精度の最大化ではなく、しきい値を設定している。この設計では、より遅い設定によって実質的に優れたモデルが得られる場合でも、条件を満たした最速の実行が評価される。

このトレードオフはプロジェクトの目的に合致するが、本番環境のチームが直面する目標は異なる。単一のベンチマークだけでなく、安全性評価、領域の網羅性、キャリブレーション、回帰テストが必要になる場合がある。

医療、法律、金融向けのアダプターは、公開された精度基準を超えたというだけでトレーニングを止めるべきではない。デプロイ基準は、誤った出力がもたらす影響を反映しなければならない。

同様に、完全一致評価では推論上の欠陥が隠れる可能性がある。モデルが不安定な論理で正しい最終値に到達することもあれば、フォーマット上のミスによって妥当な推論が不正解と判定されることもある。

したがって、61.1%というスコアは、このレース内での合格結果として解釈すべきである。これはモデルの包括的評価でも、Qwen2.5-1.5Bが汎用的な数学能力を獲得した証拠でもない。

この限定的な解釈によって、エンジニアリング上の成果が損なわれるわけではない。むしろ、主張を検証可能なほど正確にする。

次のLoRA Speedrun記録が証明すべきこと

次の3つのシグナルによって、6:05が持続性のあるシステム上の成果なのか、それとも初期段階のトラック固有の最適化なのかが明らかになる。

第1のシグナルは、同じQwen2.5-1.5Bトラックで6:05を上回る、独立した作成者による提出物である。現在のリーダーボードでは、ベースラインと記録の作成者が同一である。

リポジトリの検証プロセスは、再現不可能な主張のリスクを軽減している。しかし、外部からの参加があれば、手順、環境、最適化がプロジェクト作成者以外にも利用可能かどうかを検証できる。

より高速な提出物が受理されれば、スピードランという形式自体の信頼性が高まる。また、このベンチマークに、競合するアプローチを引きつけるだけの最適化余地があることも示される。

新しい提出物が、データ選択、1エポックのスケジュール、融合カーネル、別のLoRA配置のいずれを使用するかに注目すべきである。各戦略は異なるボトルネックを対象としており、残りの時間がどこに費やされているかを明らかにするだろう。

第2のシグナルは、シーケンスパッキングと補完部分のみを対象とした損失マスキングが、SQuADトラックを改善するかどうかである。SmolLM2-1.7Bと異なるタスクにまたがって転用できれば、より広範な効率性の主張を裏付けられる。

失敗した場合も有益な情報となる。この記録が、GSM8Kのシーケンス長、出力形式、トレーニングの動力学に強く依存していることを示唆するためである。

トラックをまたぐ提出物が成功するために、同一の49%削減を達成する必要はない。SQuADの75.5%というしきい値を満たしながら、この手法が有用な速度向上を維持できることを示す必要がある。

第3のシグナルは、提出物やソフトウェア変更が増えた際の、公式検証時間の挙動である。再実行の結果が安定していれば、実時間による順位付けへの信頼性が高まる。

変動が大きい場合は、カーネル、ドライバーバージョン、キャッシュ、ホストレベルの条件について、リーダーボードでより厳密な報告が必要であることを示す。短時間の記録には、例外的に慎重な計時規律が求められる。

こうしたシグナルは、GitHub上の単なる注目度より重要である。スター数は関心の高さを示せても、トレーニング手法の速度、精度、転用可能性を検証することはできない。

LoRA Speedrunのリーダーボードは、すでに信頼できる最初の結果を示している。公開ベースラインを11:57から6:05へ短縮すると同時に、GSM8Kの完全一致率を59.4%から61.1%へ向上させた。

より深い貢献は、その競争設計にある。ハードウェアとタスクを固定することで、アルゴリズム上の選択、カーネル、データパイプライン、停止規則が、1つの測定可能なレースに集約される。

開発者は、この結果を普遍的なレシピに仕立てるべきではない。代わりに、提出物を再現し、トークン使用率を確認し、同じ変更を自分たちのワークロードでテストできる。

最も有用な問いは、すべてのLoRAジョブを6分で完了できるかどうかではない。現在のパイプラインが、本来不要だった処理に時間のほぼ半分を費やしているかどうかである。

今後数か月にわたり、外部から受理された記録、トラックをまたぐ転用、安定した検証実行によって、その答えが明らかになる。それまでは、6:05という記録は、境界が明確に定義された優れたベンチマーク結果である。

チームで小規模言語モデルをファインチューニングしているなら、ハードウェアを変更する前に、パディング、有効な損失トークン、1秒あたりの有用トークン数を測定すべきである。そのうえで、管理された各実行を記録し、固定された品質しきい値の下で結果を比較する。次に意味のあるLoRA Speedrun記録は、単にストップウォッチが速いことではなく、そうした管理条件を耐え抜く証拠から生まれる。