ggml の v1.0.0 は、単なる番号の繰り上げではありません。非推奨だった公開APIや古い演算を整理しつつ、YaRN の扱いを調整できるようにし、FP8 対応も加えています。しかも中身を見ると、CUDA、Metal、Vulkan、SYCL、OpenCL、WebGPU、Hexagon、CPU と、かなり広い範囲で性能改善が入っている。LLM 周辺の基盤ライブラリが、互換性より実用性と速度を優先する段階に入ったことを示すリリースだと受け取れます。
リリースノートの冒頭では、ggml 1.0.0 が deprecated だった public API を整理し、legacy の DIAG_MASK ops を削除したと説明しています。あわせて、RPC protocol も更新され、互換性のない相手は受け付けないようになりました。古い挙動を残したまま拡張するのではなく、ここで一度、土台を切り替えた形です。
機能面では、YaRN correction-bound rounding を制御するための ggml_rope_set_truncate と ggml_rope_get_truncate が追加されました。YaRN は長い文脈を扱うための RoPE 系の補正手法で、truncation を設定できるようにしたことで、バックエンドや用途ごとの挙動調整がしやすくなります。さらに FP8 support も入りました。リリース説明の中では、LLM 側での FP8 KV-cache support にも触れています。低精度表現を本格的に扱う流れが、API と実装の両方に降りてきたと言えます。
中身の更新はかなり広いです。scheduler は、読まれない入力の upload を飛ばし、前段の split で生成された入力だけを prefetch するようになりました。MoE cache は、キャッシュミスの一部を CPU で計算して結果を非同期で返せるようになっています。Meta backend では、テンサー数が少ない buffer に対して compute view limit を引き上げました。こうした調整は派手ではありませんが、実運用では効きます。
backend ごとの更新も多く、CUDA では少数行向けの MMQ、BF16 向けの MMVF、OCP FP8 support、NVFP4 の fused gate/up matmul、FlashAttention の拡張、MoE の扱い改善、VMM pool の予約見直しなどが入っています。Metal では MoE routing の融合や Top-K の deterministic 化、Vulkan では Intel 向けの FlashAttention prefill kernel や batched tensor copy、YaRN truncation 対応が追加されました。SYCL は device-side MoE scheduler を持ち、OpenCL は Adreno 向けの decomposed FlashAttention と decode 改善、WebGPU は batched tensor API と GROUP_NORM などの kernel 追加、Hexagon は Q5_0/Q5_1 support と conv_2d/conv_3d の強化、CPU では FlashAttention の V を F32 で accumulate するようになっています。バックエンドの種類が多いだけでなく、それぞれに細かい最適化が入っているのがこのリリースの特徴です。
まず目に入るのは、v1.0.0 なのに「新機能のお披露目」より「不要になったものの整理」が前面に出ている点です。古い API を残し続けると、使う側は安心ですが、内部実装はずっと二重管理になります。ggml は今や llama.cpp を含む周辺エコシステムの土台なので、ここで曖昧さを切るのは筋が通っています。RPC protocol を v9 に上げて、互換性のない相手を拒否するのも同じ発想でしょう。やさしさより、誤動作しないことを優先したわけです。
ただし、この決断は利用者によって痛みの大きさが違います。自前で ggml を埋め込んでいる人、古い fork を抱えている人、複数バックエンドをまたいで試験している人ほど影響を受けやすい。特に public API の削除は、単純な置換で済まないことがある。そういう意味では、v1.0.0 は「安定版の到達点」というより、今後の拡張のために足場を組み替えた節目に見えます。
今回の更新で個人的に重要だと思うのは、ggml_rope_set_truncate / ggml_rope_get_truncate の追加と FP8 support が同じタイミングで入っていることです。長い文脈を扱う補正と、より低い精度でメモリや帯域を節約する工夫は、一見別の話に見えます。でも実際には、どちらも「より長く、より大きいモデルを、限られたハードウェアで動かす」ための部品です。
ここで面白いのは、ggml が単に最先端の手法を追いかけているのではなく、実装に落とせるところだけを丁寧に取り込んでいる点です。YaRN の truncation を config で扱えるようにするのは、理論の追加というより運用の自由度を増やす仕事ですし、FP8 も対応を宣言するだけでは意味がありません。実際には GPU や backend ごとの経路が揃って初めて使えます。その意味で、このリリースは「使える精度」を少し下げ、「扱える文脈」を少し伸ばした、かなり実務寄りの更新だと思います。
CUDA、Metal、Vulkan、SYCL、OpenCL、WebGPU、Hexagon、CPU と、これだけ多様な backend に同時に手が入るプロジェクトは珍しいです。しかも内容は、ただの移植ではなく、few-row matmul、FlashAttention、MoE、Top-K の deterministic 化、バッファやワークスペースの扱いまで含みます。つまり ggml は、共通の抽象レイヤーであると同時に、各ハードウェアの癖を吸収する調整の場になっている。
この構図は、ライブラリとしてはかなり難しい。上位の利用者は「同じ API で動く」ことを求めるのに、下位の実装は GPU ごと、ドライバごと、場合によっては SoC ごとに事情が違うからです。今回の Vulkan の ReBAR detection、OpenCL の Adreno 向け最適化、Hexagon の clang-cl 対応、SYCL の VRAM 制限チェックなどは、その現実を正面から引き受けている例でしょう。きれいな共通化より、壊れない個別最適を積み上げる方向です。地味ですが、こういう更新があると、最終的に「この環境でも動く」が増えていく。
今回のノートを読んでいて印象的だったのは、性能向上が必ずしも新しいアルゴリズム一発ではないことです。scheduler が未使用入力の upload をやめる、MoE cache が一部を CPU 側で計算して非同期に返す、graph の再利用時の扱いを直す、空の tile を飛ばす。こうした改善は、単体では目立ちません。でも、実際の推論では小さな無駄が積み重なって全体の待ち時間になります。
だからこのリリースの価値は、ベンチマークの派手さだけでは測れないと思います。ggml はモデル実行の中心に近い層なので、ここで数ミリ秒、数割のメモリアクセス、不要な転送を削ることが、上位アプリの体感に直結します。逆に言えば、今回のような更新は「最新機能が増えた」以上に、「これまで動いていたものが、もう少し安く動くようになった」と見るべきです。v1.0.0 は記念碑的な数字ですが、実態はかなり実戦向きの手入れが詰まった版です。
