llama.cppに、特定モデルのアテンション、つまり入力間の関係を計算する機能の処理で、一時データを保持する中間メモリバッファを作らない変更がマージされた。該当するQwen系モデルの実行時に、グラフィックスメモリとCPUが使うホストメモリをともに節約でき、メモリが厳しい環境でも大きなモデルを扱う余裕が生まれる。

1. モデルのアテンション処理で不要なバッファを削除

2026年10月23日にマージされた、コード変更のレビューを求めるプルリクエスト30965は、qwen4expに適用される変更だ。提出者は、このモデルのアテンション層12個がすべてQSA方式のため、kq_maskを別途割り当てる必要はないと説明した。

個別のマークを保持する領域を作る代わりに、必要な選択結果をまとめて融合する方式だ。コミットの説明によると、複数の処理ストリームを併用した際に選択結果の配列形状が合わず、メモリの事前確保段階で発生していたエラーも修正した。

2. 一時的な演算結果を保持する計算バッファで確認されたメモリ削減

提出者のsanmaiは計算バッファだけを集計し、基準コードから作った実行ファイルである従来のmasterビルドと変更後のビルドを比較した。下表のubatchは、一度に計算するトークンのまとまりのサイズを表す。

測定は5090@400Wで行われた。CUDA0はGPU側、CUDA_Hostはホスト側のバッファを指す。

表：ビルド別の計算バッファメモリ

条件：Qwen3.8-Flash-Next UD-Q4_K_XL, 5090@400W, --load-mode dio, -cmoe --moe-cache-mib 8000 -ctk q8_0 -ctv q5_1

単位：MiB

一時的な演算結果を保持する計算バッファで確認されたメモリ削減
項目masterPR
CUDA0バッファ、ubatch 409670885046
CUDA0バッファ、ubatch 8192133279237
CUDA_Hostバッファ、ubatch 40962765717
CUDA_Hostバッファ、ubatch 819255261430

両バッファとも変更後のビルドで小さくなった。提出者は、トークンのまとまりのサイズが4096ではGPUとホストのメモリをそれぞれ2GB、8192ではそれぞれ4GB削減したと要約した。モデルの計算に必要な一時作業領域が、両方で同時に減った結果だ。

3. 速度と実モデルでの検証

提出者は、ほかの条件が同じ場合、トークン生成速度が40%向上したと述べた。公開された変更後のビルドの測定では、ubatch 4096、モデルのエキスパート情報を一時保存するエキスパートキャッシュ17750 MiBのとき、入力処理速度は毎秒1004トークン、生成速度は毎秒45.5トークン、グラフィックスメモリの最大使用量は32066 MiBだった。

ubatch 8192、エキスパートキャッシュ13400 MiBでは、入力処理速度が毎秒1470トークン、生成速度が毎秒41.2トークン、グラフィックスメモリの最大使用量が32036 MiBだった。両測定では、前述の5090@400Wと同じ読み込み方式を使った。

原文の速度表には従来ビルドの基準値がなく、2回の実行もキャッシュ設定が異なるため、相互の優劣は比較しにくい。計算バッファの表も、メモリ全体ではなく一時計算領域を集計した結果だ。

レビュー承認者のServeurpersoComは、実際のUD-Q4_K_XLモデルで確認したと述べた。モデルが参照する入力範囲であるコンテキスト16384で、次のトークン候補のスコアであるロジットが従来ビルドとバイト単位で一致し、コンテキスト262144、トークンのまとまりのサイズ8192では、計算バッファと固定ホストバッファがそれぞれ4GiB減ったという。

4. 公開された実行コマンドで条件を確認

提出者は、Qwen3.8-Flash-NextのUD-Q4_K_XLモデルで使った実行コマンドを公開した。このコマンドはエキスパートキャッシュを13400 MiBに設定した測定に対応し、読み込み方式とトークンのまとまりのサイズも確認できる。

llama-server -hf unsloth/Qwen3.8-Flash-Next-GGUF:UD-Q4_K_XL \
    --no-mmproj -ctk q8_0 -ctv q5_1 --cache-ram 32768 \
    -b 8192 -ub 8192 \
    -cmoe --moe-cache-mib 13400 --load-mode dio

提出者は、この方法の効果を最も実感するのは16GB・24GBのグラフィックスカードの利用者だと予想した。確保した領域の価値は、メモリの限界にどれほど近い条件で実行するかに左右されるという見方だ。

5. モデルに合わせた最適化の意味

利点はGPUとホストの計算領域の削減であり、そのために必要なのはモデルごとの実行経路を調整する開発と検証だ。今回の変更でも、配列形状の修正と実モデルのロジット比較が併せて行われた。利用者の設定の組み合わせより、実装側に作業が集中する最適化だ。

変更は19個の自動チェックを通過し、masterにマージされた。該当モデルを使う開発者には、マージ内容を含むビルドでメモリ削減を活用する道が開かれたことになる。

今回のマージは、QSAモデルで不要なバッファを削除し、特にメモリの限界に近い実行環境に実質的な余裕をもたらす。