llama.cpp Xing4.0：CPU・CUDA推論グラフ、GGUF変換

1. モデル登録から推論まで対応

2026年11月5日にマージされたプルリクエストには、モデルの計算構造を表すアーキテクチャと、学習前に定める設定値であるハイパーパラメータの登録、計算に使う多次元数値配列であるテンソルの読み込み、変換スクリプト、モデル演算の実行順序を示す推論グラフの実装が含まれる。変更は16個のコミットとしてマージされ、マージ時点で28個のチェックに合格した。

PR作成者は、Intel Xeon Platinum 8468でCPU推論を、NVIDIA H800 80GBでCUDA推論を確認したと述べた。両方の実行環境で、基本機能が動作するかを確認するテストに合格したという。

2. 既存の演算子の組み合わせでグラフを構成

モデルの計算を実行順に組み合わせた推論グラフは、新しいggml演算子ではなく既存の計算部品を組み合わせる。複数の先行層の値を後続層に加える残差接続を混合するmHCにも、複数の計算をまとめて実行する融合演算子を再利用する。

追加トークンを予測するMTPは、ドラフトトークンを検証して生成を速める既存の投機的デコーディングの仕組みに接続された。

3. GGUF変換とMTPの重みの選択

変換スクリプトは、Hugging Faceの重みをGGUFに変換する経路に新モデルを登録する。既存の変換コードを基に、トークンの順序情報をモデルに与える位置エンコーディングの設定を補正し、SentencePieceで文をトークン単位に分割するトークナイザーの経路を使用する。

変換時には、追加予測を担うMTPブロックを除外するか、このブロックと、共有のトークンを数値ベクトルに変える埋め込み・値の範囲を調整する正規化・出力の重みだけを格納した別ファイルを作成できる。以下は、2つの選択に応じて保存する重みを絞り込む原文のコードだ。

        # --no-mtp: drop the appended NextN block entirely.
        if is_mtp and cls.no_mtp:
            return None
        # --mtp: keep ONLY NextN-block tensors plus the shared embeddings/
        # norm/lm_head (so the resulting GGUF carries just the draft head).
        if cls.mtp_only and not is_mtp and name not in (
            "model.embed_tokens.weight", "model.norm.weight", "lm_head.weight",
        ):
            return None

4. 量子化の品質を基準精度とともに提示

作成者は29Bモデルで重み形式別のパープレキシティを報告した。文の予測がどれだけ適切かを示す指標で、低いほど良い結果となる。基準精度のbf16と、重みの保存精度を下げる量子化を適用した2形式の結果を併せて示した。

表：29Bモデルの重み形式別パープレキシティ

条件：29Bモデル

単位：PPL

品質表ではq8_0が基準精度に近い値を示し、iq4_nlはそれより高かった。

作成者は、量子化に敏感な重みの精度を保護するためにimatrix.datを指定し、近く公開する予定だと述べた。

5. GPUスループットの向上と追加の計算コスト

作成者はH800 80GBのCUDA環境でllama-benchを使って速度を測定した。入力処理のpp512とトークン生成のtg128を分けて報告しており、表の誤差列は原文で±の後に記載された数値だ。

表：H800 80GB CUDAのスループット

条件：NVIDIA H800 80GB、CUDA、llama-bench pp512/tg128

単位：トークン毎秒

このGPU測定では、量子化した2形式とも基準精度より入力処理とトークン生成のスループットが高かった。品質表と速度表のモデル規模が同じかどうかは、原文に明記されていない。

開発者は、新しい演算子なしに既存の実行基盤でモデルを利用できるようになった。ただし、学習済みのhc_scaleの重みとは別にpostゲートに固定定数2.0を掛けるスケーリング演算には、層ごとに計算ノードとGPU演算コードを実行するカーネル呼び出しが追加されるコストが伴う。作成者は、この演算を単純に削除するとpostゲートが半分になって計算結果が変わるとし、今後の最適化対象に挙げた。

今回のマージの要点は、Xing4.0の重み変換からCPU・CUDA推論までを既存の実行基盤でつなぎ、追加計算の最適化を今後の課題としたことにある。