llama.cpp CUDA Fusion、プロンプト処理を最大10.7%高速化
llama.cppは10月25日、CUDA最適化をマージした。コントリビューターによるベンチマークでは、DGX Sparkでプロンプト処理性能が最大10.7%向上したと報告されている。llama.cpp CUDA fusionの変更は、トークン表現をアテンション段階の間で変換するモデルのフィードフォワードネットワーク内の演算を統合するものだ。その効果は、後続の各応答トークンの生成ではなく、プロンプトの読み込みに関係する。
コントリビューターのanujjによる測定では、NVIDIAのRTX 5090でも改善が示されているが、報告された伸び率は小さい。これらは著者自身が報告した比較であり、独立して再現された結果ではない。根本となる変更はマージ済みコードで確認できる一方、実用上の価値は依然としてモデル形式、ハードウェア、ワークロードに左右される。
中心となる比較は、関連する演算を統合する融合実行と、それらの演算を個別にスケジューリングする既存の実行パスとの間にある。以前の提案も同じ機会を別の方法で追求していた。今回マージされたアプローチは、値がGPUスレッドに届く方法を再編し、保存済みモデルの重みを変更せずに中間処理を削減する。ローカルで長いプロンプトを実行する開発者にとって、これは既存のデプロイメントと比較して測定する価値のある、具体的なソフトウェア改善となる。
llama.cpp CUDA fusionのマージで変わること
このマージ済み変更は、対応するNVIDIAハードウェア上で、既存の最適化をより大規模なプロンプト処理ワークロードへ拡張する。
NVIDIAのGPUコンピューティングプラットフォームであるCUDAは、この実装の実行環境を提供する。llama.cppの量子化行列乗算パスであるMMQは、圧縮されたモデル重みを含む計算を処理する。量子化では、ストレージとメモリの要件を抑えるため、これらの重みを低い数値精度で表現する。
マージされたfusionの変更は、対応する高密度フィードフォワード層内で繰り返される一連の処理を対象とする。個別のgate投影とup投影が同じ入力を変換し、その後、ゲート線形ユニット（GLU）が活性化関数と要素ごとの乗算を通じて両者の結果を結合する。
従来、このパス上の大規模ワークロードでは、投影とその結合を別個の演算として処理していた。anujjによれば、新実装ではこの一連の処理を単一の行列乗算カーネルで実行する。カーネルとは、GPUスレッド群に対して起動される関数である。
この統合が重要なのは、周辺処理もリソースを消費するためだ。入力の準備、演算の起動、中間結果の書き込み、それらの再読み込みはいずれもオーバーヘッドを追加し得る。演算を結合することで、意図された数学的変換を維持しつつ、その一部のトラフィックを取り除く機会が生まれる。
この変更は、すべての実行パスに同時にこの考え方を導入するものではない。コントリビューターによれば、小バッチ向けのfusionは、別の行列ベクトル実装ですでに存在していた。行列ベクトル計算は通常、ここで重視される行列行列計算よりも小規模なワークロードに対応する。
この違いが、発表がプロンプト処理に焦点を当てている理由を説明する。回答生成前に入力プロンプトを処理するprefillフェーズでは、より大きな処理バッチが表れ得る。新たに対応した実行パスは、推論のこの部分を対象としている。
時系列も重要だ。プルリクエストの最初の説明は10月4日付で、プロジェクトは10月25日にマージした。マージにより実装はプロジェクトのmasterブランチに入る。ただし、すべてのパッケージ済みアプリケーションがすでにこの変更を含むことを意味するものではない。
デスクトップアプリケーション、コンテナ、下流プロジェクトは、それぞれのスケジュールでllama.cppを取り込める。そのためユーザーは、インターフェースの背後で実際に動作しているランタイムのバージョンを特定する必要がある。アプリケーションの更新と上流ソースのマージは別の出来事だ。
既存のモデルファイルについては、互換性の状況は比較的明確だ。コントリビューターは、保存される重みレイアウトは変わらないとしている。ユーザーは、タイトルにあるinterleaved rowsへの言及を、特別に再配置されたモデルファイルをダウンロードする必要があるという意味に解釈すべきではない。
したがって、直近のニュースは限定的かつ具体的だ。対応する実行シーケンスに、上流で追加の最適化が利用可能になった。特定のリクエストで利用されるかどうかは、ランタイムの適格性チェックに依存する。
ベンチマークの伸びはSparkで大きく、RTX 5090では小さい
報告された結果は、掲載された構成全体で一貫した改善方向を示すが、その規模はハードウェアと量子化によって異なる。
著者はGB10プロセッサを搭載するDGX Sparkをテストし、別途RTX 5090もテストした。両方のベンチマーク表では、masterと記されたベースラインをプルリクエストと比較している。掲載されたすべての行で、変更後実装の方がプロンプト処理スループットが高いと報告されている。
DGX Sparkでは、最大の改善率として記載されているのは、圧縮重み形式であるIQ4_XSを使用したLlama-3.1-8Bだ。スループットは毎秒2,933.9トークンから3,249.0トークンへ増加している。著者は、この構成で10.7%の向上を報告している。
SparkにおけるLlama-3.1-8Bの他の結果は、このピークを下回るものの、依然として大幅な改善が報告されている。Q4_K_M構成は毎秒2,749.3トークンから3,000.6トークンへ移行した。Q5_K_M構成は毎秒2,699.4トークンから2,960.3トークンへ増加した。
これらのラベルは、同一バイナリを交換可能な形で測定した結果ではなく、異なる量子化モデル構成を示している。その結果は、最適化を評価する際に正確なファイル形式を一致させるべき理由を示す。モデルファミリー名だけでは、関連する変数が抜け落ちる。
Sparkの表には、Qwen3.8-27BおよびQwen3.6-27Bと記されたモデルも掲載されている。これらの名称は、コントリビューターの報告におけるベンチマークラベルとしてここでも再掲している。パフォーマンス表そのものは、それらの学習詳細、能力、または広範な提供状況を独立して確立するものではない。
Qwen3.8-27Bと記されたエントリーでは、Sparkでの改善率は4.6%から7.4%の範囲にある。Q4_K_Mの行は毎秒840.1トークンから899.9トークンへ上昇した。IQ4_XSの行は毎秒882.4トークンから948.0トークンへ増加した。
RTX 5090の結果では、改善の規模が異なる。掲載された構成全体で、著者は1.9%から4.7%の向上を報告している。このより小さい割合の範囲は、ハードウェア固有の解釈が不可欠であることを示す。
IQ4_XSのLlama-3.1-8Bでは、RTX 5090の結果は毎秒12,997.6トークンから13,603.3トークンへ増加した。報告された改善率は4.7%だ。Qwen3.8-27B Q6_Kのエントリーでは、スループットは毎秒3,220.5トークンから3,281.0トークンへ、すなわち1.9%上昇した。
したがって、llama.cpp fusionのベンチマークは限定的な結論を支持する。著者が選んだ長いプロンプトのテストでは、この最適化は報告された行列全体で測定上の入力スループットを改善している。ただし、対応するすべてのGPUで同一の向上幅を示すものではない。
また、この割合比較だけでは、なぜSparkの恩恵がより大きいのかも明らかにならない。異なるメモリ挙動、実行特性、既存のボトルネックが最適化結果に影響し得る。それらの相対的な寄与を明らかにするには追加のプロファイリングが必要であり、これらの見出しレベルの測定だけでは提供されていない。
購入者にとって有用な示唆は、評価の規律に関するものだ。これらの結果だけで、割合の向上幅に基づいてハードウェアを選ぶことは正当化されない。絶対的なスループット、モデルの適合性、メモリ容量、実際のアプリケーションレイテンシは、依然として別個の検討事項である。
Interleaved rowsが計算間の処理を削減する
実装の中心的な変更は、gate演算を適用する前に、関連する結果をまとめて配置することにある。
Anujjは、gateとupの行を8つずつ交互のチャンクとして読み込むと説明している。この配置により、対応する値が同じスレッドの作業結果内に置かれる。スレッドは最終出力を書き込む際に、それらの値を結合できる。
レジスタは、実行中のスレッドに割り当てられるGPU内の小規模なストレージ領域であり、それらの中間結果を保持する。そこで結合処理を適用すれば、その計算部分について中間出力バッファを経由する別途の往復を避けられる。意図される節約は、実行構成から生まれる。
この実装は、gate投影向けに第2のアキュムレータタイルを導入するのではなく、1つのアキュムレータ配置を維持する。アキュムレータは乗算中の部分和を保持する。タイルは、まとめて処理される行列要素のブロックである。
この設計判断は、この実装を以前のfusion提案と区別する。コントリビューターの説明によれば、新しいアプローチはam17anの提案に従ったものだ。両方の提案は関連する演算を対象とするが、計算の構成方法は異なる。
この違いは、見た目の問題ではなく実用的なものだ。より多くの中間状態を保持すると、GPUの限られた実行リソースへの負荷が増える可能性がある。演算の結合が役立つのは、節約効果が追加のスケジューリングやストレージコストを上回る場合に限られる。
このため、「カーネル数が少ない」ことが自動的に「推論が速い」ことを意味するわけではない。より大きな結合演算は、条件によってはハードウェアを効率的に利用できない場合がある。最適化では、その利点を打ち消す新たな制約を避けつつ、十分な並列処理を維持しなければならない。
マージ済みコードは、適格性チェックを通じてこの懸念を反映している。ワークロードがこのfusionパスに適しているかを評価する。対応する数学演算だけでは、fusionを実行すべきことは保証されない。
この実装は、行列乗算処理を縮約次元に沿って分割するスケジューリング手法であるstream-kとも競合する。融合パスはこの分割方式を使用できない。そのため、タイル配置が十分な効率を提供するかを判断する別の方法が必要になる。
Johannes Gaesslerはレビュー中にこの問題を提起し、期待されるタイル効率とstream-kの事前比較を求めた。マージ済みコードには、融合パスを選択する前の効率判定が含まれている。これは条件付き実行が設計の一部であることを示している。
fusionスケジューリングのレビューは、この最適化に対する最も有用な懐疑的視点を提供している。魅力的な単純化が性能を失う可能性のある状況に焦点を当てている。これは、ベンチマークの存在をめぐる意見の相違ではなく、技術的な制約だ。
したがって、ここでの主な競争はランタイム内部にある。融合実行は、適格な演算形状において既存のスケジューリング方式を上回らなければならない。これらの結果には、別の推論フレームワークに対するより広範な勝利を示す証拠はない。
この仕組みは、ユーザーがllama.cpp CUDA fusionに何を期待すべきかも明確にする。これは既存の計算における処理を再編するものだ。モデルの推論能力を高めたり、学習済み知識を拡張したり、無関係なメモリ制限を解消したりするものではない。
同じモデルは、引き続き同じ一般的なタスクを実行する。エンジニアリング上の機会は、特定のシーケンスの出力に到達するまでの時間を短縮することにある。
より高速なプロンプト処理が変えるのは待ち時間の一部
ベンチマークは入力処理を測定しているため、実用上の価値は、実際のリクエストにおいて入力処理がどれだけの割合を占めるかに依存する。
報告されたコマンドは、16,384トークンを含むプロンプトを処理し、生成トークン数をゼロに指定している。トークンは、モデルが消費し生成するテキスト単位だ。この設定は、完了した会話応答を測定するのではなく、プロンプトのスループットを分離する。
このコマンドでは、バッチサイズとマイクロバッチサイズに2,048を指定しています。マイクロバッチは、より大きなバッチから切り出される小さな実行単位です。また、注意計算時のメモリトラフィック削減を目的としたアテンション実装であるFlash Attentionも有効にしています。
著者は、以前に処理したトークンのアテンション情報を保持するキー・バリューキャッシュに半精度ストレージを指定しています。コマンド内には5回の繰り返しも含まれています。これらの設定は検証条件を定義するものであり、引用する結果には併記すべきです。
プロジェクトのベンチマーク手法では、プロンプト処理とトークン生成を区別しています。この分離は、これらの数値を読み解くうえで重要です。入力トークン毎秒と出力トークン毎秒は、異なる性能上の問いに答える指標です。
たとえば開発者が、ローカルモデルに大規模なソースファイルの調査を依頼するケースを考えてみましょう。その入力処理は、回答が始まるまでの遅延に大きく寄与する可能性があります。対象となるprefillパスの高速化は、インタラクションのその部分に対応します。
短い会話のやり取りは、別のワークロードです。長い回答の生成に費やす時間と比べ、プロンプトの処理量は比較的少ないかもしれません。その場合、同じ入力スループットの向上が待ち時間全体に与える影響は小さくなります。
キャッシュ済みプロンプトにも別の違いがあります。プロンプトキャッシュは、システムがすでに処理した入力の計算結果を再利用します。アプリケーションがその処理を正常に再利用できれば、この最適化で高速化できる新規入力は少なくなります。
文書分析には、推論以外の処理も含まれます。アプリケーションは、モデルに何かを送信する前に、ファイル取得、テキスト抽出、パッセージの順位付け、指示文の準備などを行うことがあります。モデルの入力処理が高速化しても、周辺ステージの完了が早まることまでは示されません。
検索可能なナレッジベースを維持するチームにとって、この分離はより適切な性能判断を支えます。検索品質とコンテキスト選択は、何がモデルに届くかを決定します。ランタイムのスループットは、対象となる計算をどれほど速く処理するかを決定します。
この違いは、アプリケーション保守者にも課題を突きつけます。自社製品にどのランタイムが組み込まれているか、一般的なワークロードが最適化パスに到達するかを把握する必要があります。ローカルAIが高速化したという一般的なリリースノートだけでは、これらの問いには答えられません。
有効なのは、アプリケーション境界での計測です。最初のトークンまでの時間は、出力開始までの遅延を測定します。総応答時間はインタラクション全体を測定し、生成スループットは出力開始後の速度を測定します。
ランタイムの更新後、各指標は異なる動きをする可能性があります。prefillの改善により、後続テキストの生成速度を変えずに初期待ち時間を短縮できる場合があります。こうした結果を分けて報告することで、ユーザーはアップグレードをより正確に把握できます。
llama.cppのプロンプト処理において、最も有力なユースケースは、対象構成での新規かつ十分に大きな入力です。著者のベンチマークは意図的にこのワークロードを強調しています。その結果をすべてのチャットセッションに拡張することは、証拠の範囲を超えます。
サポート対象の形式と正確性チェックが境界を定める
マージされたコードには重要な制約があり、著者による正確性報告は、明示されたテスト範囲の中で読むべきです。
プルリクエストでは、NVIDIA Turing以降のアーキテクチャにおいて、Q4_K、Q5_K、Q6_K、Q8_0、IQ4_XSのウェイトタイプをサポートすると説明しています。これらがサポート対象のウェイトファミリーです。モデルファイルには複数のタイプを組み合わせられるため、ファイル全体のラベルだけでは内部のすべてのテンソルを説明できません。
実装では、関連するgateウェイトとupウェイトが融合に必要な条件を満たすことも確認します。結合処理は対応する計算を想定しているため、形状、タイプ、レイアウトが重要です。非対応の構成では、別の実行パスが維持されるべきです。
マージされたコードは、行境界のフォールバックを必要とするケースを除外しています。フォールバックは、通常の処理タイルをきれいに埋められない形状を扱います。この制約は重要です。元の説明では、開発中に境界ケースを含むテストについて述べられているためです。
したがって読者は、冒頭のテスト要約と最終コードの選択ルールを区別すべきです。より広範な開発版実装をテストしたことは、テストしたすべての形状がマージ版でも対象のままであることを示すものではありません。実際の実行を決めるのは最終的なガード条件です。
演算パラメータにも制約があります。コードは、融合を選択する前に特定の活性化設定を確認します。これらのチェックは、必要な挙動が異なるにもかかわらず、表面的に似た演算をランタイムが互換と見なすことを防ぎます。
対象範囲は高密度なフィードフォワード演算にも集中しています。選択されたサブネットワークにトークンをルーティングするMixture-of-Expertsモデルには、異なる実行要件があります。レビューでは、これらのモデルを普遍的にカバーしたと示すのではなく、追加のサポート作業が必要であることを明示しています。
ほかのハードウェアバックエンドは、llama.cppをサポートしているというだけでこの最適化を受けるわけではありません。コントリビューターは、この変更をほかのバックエンドとは明確に区別しています。したがって、NVIDIAハードウェアでの結果から、Apple GPUやAMD構成で同等の効果が得られるとは結論づけられません。
正確性の証拠は心強いものですが、依然として著者による報告です。Anujjは、GB10でバックエンド演算テストスイート全体が成功したと述べています。報告では、RTX 5090で行列乗算スイートが成功したことも示されています。
コントリビューターはさらに、融合の有効・無効を切り替えた指定テストで、パープレキシティの結果が同一だったと報告しています。パープレキシティは、モデルが評価テキストをどれだけ適切に予測するかを測る指標です。有用な数値チェックではありますが、考え得るすべてのアプリケーション挙動を表すものではありません。
この結果が裏付けるのは、普遍的な出力同一性より限定的な主張です。明示された評価でスコアが同一でも、すべてのプロンプト、設定、プラットフォームにおいて生成回答が同一であることは証明されません。より広範な検証には、より広範な証拠が必要です。
今回確認した情報源には、llama.cppの融合ベンチマークを独立して再現した結果もありません。上流でのレビューとマージは、プロジェクトがコードを受け入れたことを示します。しかし、コントリビューターによる測定を外部の性能監査に変えるものではありません。
これらの境界が報告された向上を否定するわけではありません。むしろ、主張が有用となる範囲を定義しています。ハードウェアとモデルタイプが一致する読者には具体的な検証理由があり、ほかの構成では別途証拠が必要です。
最も妥当な解釈は、両面を組み合わせたものです。この変更には明確な仕組みと公開された測定値があり、同時に実行条件を規定する明示的な条件もあります。
改善がどこまで広がるかを示す3つの兆候
次に必要な証拠は、上流コード、再現可能な測定、そしてユーザーが体感するレイテンシを結び付けるものです。
第1の兆候は、下流での採用です。今後数か月で、アプリケーションのリリースとパッケージ化されたビルドによって、どの製品がマージ済み実装を含むかが明らかになるはずです。ユーザーは多くの場合、別のアプリケーションを介してllama.cppを利用するため、これは重要です。
プロジェクトのCUDAビルド手順では、上流のコンパイル手順を説明しています。パッケージ化された配布物は、異なるリリーススケジュールに従う場合があります。最新バックエンドを使用しているという一般論よりも、含まれるソースに紐付くバージョン識別子のほうが有益です。
広く利用されるアプリケーションがこの変更を取り込めば、即時採用の根拠は強まります。古いリビジョンのままであれば、マージの実用上の到達範囲は限定されたままです。その結果は、根本的な最適化を否定するのではなく、配布時期に関する問題を示すものです。
第2の兆候は、明示的な設定を伴う独立再現です。有用な報告では、ハードウェア、モデルファイル、ランタイムのリビジョン、ベンチマーク引数を特定すべきです。また、新規プロンプト処理、キャッシュ済み入力、生成出力を分けて扱うべきです。
異なるプロンプト長での再現は、向上がワークロードの規模にどれほど左右されるかを明らかにします。サポート対象の異なるGPU世代での報告は、列挙されたマシン以外でも傾向が続くかを検証します。性能低下を示す結果は、選択ロジックの制限を特定する助けになります。
重要なのは、すべての実行が見出しの最大値に一致するかどうかではありません。比較可能なワークロードで、許容できる変動範囲の中、再現性のある改善が見られるかどうかです。より小さくても一貫した向上は、運用上有用になり得ます。
第3の兆候は、アプリケーションレイテンシです。チームは、更新後のランタイムが代表的なリクエストにおいて回答開始までの待ち時間を短縮するかを測定すべきです。生成スループットと総応答時間は、別個の測定値として維持すべきです。
この証拠は、カーネルの変更をユーザー体験に結び付けます。長くキャッシュされていないプロンプトで初期遅延が短くなれば、実装が実用上もたらす価値を裏付けます。総応答時間が変わらなければ、測定されたワークフローではほかのステージが支配的であることを示します。
形式やアーキテクチャの対応拡大は、このマージで確立されたものではなく、追加の開発となります。将来の主張では、それぞれ固有の実装と測定値を示すべきです。現在の結果は比較の基準であり、こうした拡張を事前に裏付けるものではありません。
現時点で、llama.cpp CUDA fusionはローカル推論性能を再検討する具体的な理由を提供します。これは、対象となるフィードフォワード計算内の繰り返し作業を対象とし、開示されたプロンプト処理条件で測定可能な向上を報告しています。全面的な高速化を約束することなく、評価を正当化するには十分です。
稼働中のデプロイメントを更新する前に、現在のランタイム識別子と代表的なリクエストセットを保存してください。更新後には、同じモデルファイル、プロンプト長、キャッシュ条件、出力設定で比較します。初期待ち時間を回答生成と分けて記録し、各結果とともにベンチマーク引数も保持してください。長文書ワークフローでは、合成的なスループットだけに頼らず、日常的な利用に似た新規入力を含めてください。会話型ワークロードでは、入力処理の遅延が小さくなることで、体験にとって十分に重要な変化が生じるかを確認してください。そのうえで、自身の測定結果をもとに、上流の改善をリリーススケジュールのどこに組み込むべきか判断してください。更新後のランタイムは、ユーザーが実際に待っているリクエストの部分を短縮していますか？
