自分のパソコンでモデルを動かしているなら、直接インストールしたにせよ、その上に作られたアプリ経由にせよ、裏で働いているのはllama.cppである可能性が高いでしょう。このプロジェクトがライブラリのバージョン1.0.0を公開し、セマンティックバージョニングを採用すると約束しました。事務的な話に聞こえますが、その上で開発する人にとっては、いつ互換性が壊れるかについての約束です。
ルールは単純で、発表の中に示されています。公開C API、つまりincludeフォルダーのヘッダーに互換性のない変更があればメジャーバージョンを上げます。後方互換の機能追加、バックエンドの更新、新しいモデルへの対応、APIの追加ではマイナーバージョンを上げます。APIを変えないバグ修正ではパッチ番号を上げます。同じルールは、その下にある機械学習エンジンggmlやほかのggml-orgのプロジェクトにも適用され、チームはAPIとABIの両方で非互換をより厳格に示すとしています。
背景には規模があります。開始から3年半で、llama.cppに依存するプロジェクトは長いリストになりました。記事によると、現在は150を超えるアーキテクチャのバリエーションと主要な投機的デコーディング手法すべてに対応しています。配布先も広がっており、Docker、Debian、Homebrew、conda-forge、MacPorts、Winget、さらにAppleのプラットフォーム向けのXCFrameworkが挙げられています。テストはHugging Faceの基盤上で行われ、NVIDIA、AMD、Qualcomm、Arm、IBM、Intelの支援を受けた自前のマシンも使われています。
私たちがレビューするツールにとって、これは目立たないものの重要な変化です。OllamaもLM Studioもllama.cppとggmlを利用 しており、多くの小さなデスクトップアプリも同様です。これまで上流の変更を追う人は、インターフェースの変更を見つけるために変更履歴を丹念に読む必要がありました。互換性が壊れるときにそれを知らせるバージョン番号があれば、こうしたプロジェクトはより少ないリスクでより頻繁に更新でき、新しいモデルへの対応がより早く利用者に届くはずです。Hugging Faceのチームは、macOSとWindows向けに独自のLlamaデスクトップアプリも出しています。
限界も述べておくべきでしょう。セマンティックバージョニングは約束であって保証ではなく、対象はC APIであり、品質や速度に関わるあらゆる挙動の変化ではありません。多くの人が直接使うコマンドラインツールやサーバーのオプションについても何も示していません。あるコメント投稿者は、非常に長いプロンプトの処理がまだ望むほど速くないと指摘しており、バージョン1.0.0はその解決をうたってはいません。