llama.cpp Gemma 4：プリフィル最適化、スループット改善

1. 前の層の計算結果を再利用する区間を短縮した

11月3日にマージされた変更は、前の層の計算結果を保持するKVキャッシュを再利用し、新しい値を保存しない層で、出力に不要なトークン計算を省略する。入力トークンを先に処理するプリフィル段階では、入力を分割して処理する中間バッチでこれらの層を飛ばし、最後のバッチで1行だけ処理する。すでに受け取った計算結果を活用する区間で、重複作業を減らした形だ。

開発陣は、各層に供給する入力表現である層別埋め込みのスケーリング計算を整理し、データの連続コピーも避けるようにした。

以下は原文の変更コードの適用条件だ。キャッシュを共有する層の有無や、同時に扱う入力の流れが1つかなどを確認し、必要な中間結果まで切り落とさないようにする。

    // KV-shared layers do not write to the KV cache, so prune non-output token rows before the first KV-shared layer
    bool prune_shared = crop_before_nextn(inp_out_ids) &&
                        hparams.n_layer_kv_from_start > 0 && hparams.n_layer_kv_from_start < n_layer &&
                        !cparams.embeddings && cparams.n_seq_max == 1;
    for (int il = (int) hparams.n_layer_kv_from_start; prune_shared && il <= n_layer; ++il) {
        prune_shared = !cparams.embeddings_layer_inp[il];
    }

2. M4 ProでE2Bの長い入力のスループットが向上した

変更リクエストの作成者は、量子化の影響を反映して学習した公式Google QATのQ4_0モデルで、変更前のmaster、つまり開発の基準コードと変更版を比較した。M4 ProでMetal・BLASと10スレッドを使ったE2Bの測定では、3つの入力長すべてで、毎秒の入力トークン処理数であるプリフィルスループットが大幅に増えた。

表：E2Bの入力長別プリフィルスループット

条件：M4 Pro、MTL,BLAS、10スレッド、gemma4 E2B Q4_0、3.10 GiB、4.63 B

単位：トークン/秒、±列は原文の数値の誤差部分

同じ環境での128トークン生成の測定値は、109.65から110.98トークン/秒とほぼ同じだった。改善の中心は、回答を書き続ける速度よりも入力を読み込む速度にある。

3. E4Bも入力長全般で改善した

作成者のM4 Proでの測定では、E4Bも同じ傾向を示した。以下の表はE4Bのみをまとめたもので、ハードウェアとスレッド設定は前の試験と同じだが、モデルサイズとパラメーター数は異なる。

表：E4Bの入力長別プリフィルスループット

条件：M4 Pro、MTL,BLAS、10スレッド、gemma4 E4B Q4_0、4.79 GiB、7.46 B

単位：トークン/秒、±列は原文の数値の誤差部分

同じ環境での128トークン生成のスループットは、63.39から63.62トークン/秒だった。E4Bでも入力スループットの向上と生成速度の維持が同時に見られた。

作成者は、テキスト・画像・音声入力に対する出力が変更前と同じで、16K・32Kの長さのプロンプトも試験したと報告した。

4. CPUとSnapdragonでも入力スループットが向上した

作成者のM4 Pro CPU試験では、同じ公式量子化モデルと10スレッドを使用した。512トークン入力で、E2Bは629.04から1811.26、E4Bは326.06から543.23トークン/秒へ向上した。

Snapdragon S26+では、OpenCL・HTP、6スレッド、マイクロバッチサイズ1024、HTP0デバイス、GPUに載せる層数を指定する設定nglの値-1という条件で測定した。同じ公式E2Bモデルで、512トークン入力は2303.07から5099.01、8192トークン入力は1896.88から4686.80トークン/秒へ増加した。プラットフォーム別の結果は、それぞれの環境内での変更前後の差を示している。

5. 利点を得るにはサーバーの同時処理構成の確認が必要だ

作成者が10月30日に公開したM4 Pro・Metalのサーバー試験では、13,789トークン入力の処理に、キャッシュをまとめて使う統合KVで4.22秒、分けて使う分割KVで11.72秒かかった。複数トークンを先行予測するMTPの未使用・使用の順で、スループットは統合KVが3261.9・3264.4、分割KVが1175.2・1175.0トークン/秒だった。

マージ時点での切り詰めの条件は、統合KVを使う単一シーケンス、つまり一度に処理する入力の流れが1つであることだ。標準のサーバーのように複数シーケンスを使う構成や、埋め込みを抽出する構成は対象外となる。26Bはプロンプト処理中にすべての層がキャッシュに値を保存するため、この最適化の利点はないと作成者は説明した。

入力計算を減らす利点の代償は、活用できる運用構成の幅にある。複数のリクエストを同時に処理するサーバーでは、単一シーケンスで得た入力スループットだけでなく、既存の同時処理要件も併せて検討する必要がある。

今回の最適化の価値は、回答生成そのものよりも長い入力の待ち時間を減らす点にあり、導入判断の出発点はモデルとサーバー構成だ。