llama.cpp 0.2.0、安定版とデイリービルドを分離――パッケージメンテナーが互換バージョンを固定可能に

llama.cpp 0.2.0の中心的な変更は、特定のカーネル高速化ではなくリリース制度にある。今後、`vX.Y.Z`は更新間隔が比較的長く、ダウンストリームでの配布に適した安定版を表す。一方、mainブランチへのコミットとほぼ同時に生成される`b[番号]`タグは、nightly／開発版として明確に位置付けられる。長らくビルド番号を追い続けるしかなかったアプリケーション、言語バインディング、Linuxパッケージにとって、これはバージョンを固定・比較し、アップグレードポリシーを設定するための基準点となる。

メンテナーはさらに、正式なタグを作成する際、llama.cppに組み込まれるggmlが、リリース済みのggmlと完全に一致していなければならないと定めた。これはABIとパッケージングに関わる重要な点だ。Debianではすでに、実行ツール、`libllama`、開発用ヘッダーに加え、CUDA、HIP、Vulkanなどのggmlバックエンドが個別のパッケージに分割されている。組み込み版とシステムライブラリの間にずれが生じると、コンパイルに成功しても、ロード時や推論時に失敗する可能性がある。セマンティックバージョニングにより、パッケージマネージャーは依存関係を表現しやすくなり、ダウンストリーム側も新しいモデルのサポートを導入する前に、テスト済みのベースラインを維持できる。

0.2.0には、実行レイヤーに関する多数の変更も含まれる。具体的には、Arm SME2 F32 GEMVカーネル、SYCLのQ5_Kカーネルとロード処理の修正、Adreno OpenCLの互換性対応、LFM2／LFM2-MoEのテンソル分割、LFM2向けDSparkドラフトモデル、マルチモーダルプロジェクター用デバイスの指定機能、Metal、CUDA、Vulkanにおける量子化またはKV-cacheパスの調整などだ。これらの機能には統合に利用できる安定版タグが付与され、mainブランチを直接追跡する必要がなくなった。

ただし、プロジェクトは依然として0.x段階にある。バージョン規則と自動リリースプロセスは確立されたばかりで、リリースサマリーさえ今後の改善項目として残っている。また、安定版タグはLTS、セキュリティ監査、あるいは全バックエンドでのテスト完了を意味するものではない。ダウンストリーム側は、`libllama` API、RESTインターフェース、ggmlのバージョン、モデル形式を個別に追跡し、CUDA、Metal、Vulkan、SYCLなど、実際のデプロイ先ハードウェア上で回帰テストを構築すべきだ。