推論系統
llama.cpp b10456、SYCLの量子化変換スケジューリングを修正——Arc 70のQ4_0→FP32スループットが158.19 GB/sに向上
新版では量子化ブロックのサイズに応じてスレッド数とワークグループ数を設定し、SYCL copy kernelの過剰または不十分なサブスクリプションを回避。Arc 70のマイクロベンチマークではスループットが20.21 GB/sから158.19 GB/sに向上したが、これはモデル全体のtoken生成速度が同じ比率で向上することを意味しない。
llama.cppは8月17日にb10456をリリースし、SYCLバックエンドが量子化tensor copy kernelを起動する際のスレッド数とblock数を修正した。従来の処理経路では、各量子化形式に含まれる要素数が十分に考慮されておらず、一部の変換処理でGPU work-itemが過剰または不足していた。新版では、起動規模をquant blockサイズに比例させるよう変更している。
最も顕著な結果は、Q4_0からFP32への逆量子化で確認された。コントリビューターがIntel Arc 70で測定したところ、スループットは20.21 GB/sから158.19 GB/sへと、従来の約7.8倍に向上した。レビュアーもArc Pro B60で9.08 GB/sから104.73 GB/sへの向上を報告している。ただし、ほかの量子化形式はおおむね横ばいであり、今回の変更が特定のデータレイアウトとスケジューリングの不整合を対象としたもので、すべてのSYCL kernelに対する汎用的な最適化ではないことを示している。
この処理経路は、モデルのロード、tensor転送、形式変換、一部の演算準備段階で使用される。関連するボトルネックを短縮できる一方、prompt processingやtoken単位のdecodeが直接7.8倍高速になるとは推定できない。実際の効果は、モデルの量子化形式、変換頻度、メモリ帯域幅、推論グラフがほかのGEMM、attention、CPU offloadのいずれに支配されているかによって異なる。
PRのAI利用に関する開示では、Claude Opus 5が並列スレッド生成方式の違いを発見する作業を支援したとされている。エンジニアリングチームはアップグレード後、モデルのロード、prefill、decode、ピークメモリを個別に測定し、自社で使用するArcモデルとoneAPI／Level Zeroドライバーの組み合わせで再検証すべきだ。現時点の公開データは2種類のIntel GPUのみを対象としており、リリース時点ではCIチェックが1件未通過のままだった。