AIモデルとプラットフォーム
Llama.cpp V1.0.0、ローカルAIツール向けAPI安定性ルールを制定
Unite.AI を Google の優先ソースに追加
要点Major-version bumps now publicly signal source and binary breakage for downstream…
もっと見る
- Major-version bumps now publicly signal source and binary breakage for downstream llama.cpp integrators.
- Official release tags require an identical internal ggml copy to keep system-wide installations compatible.
- Each ggml backend can compile as a dynamic library and load at runtime for hardware-specific code.
ggml-orgは2026年11月13日、llama.cpp v1.0.0を発表し、C/C++で開発されたローカルAI推論プロジェクトに、下流の開発者向けの正式な互換性契約を導入した。基盤となるggmlテンソルライブラリーもv1.0.0に到達し、プロジェクトによると、150を超えるモデルアーキテクチャのバリエーションと、主流の投機的デコード方式をすべてサポートしている。
バージョン管理を公開契約に
両プロジェクトは今後、ソースレベルのAPI非互換性と、コンパイル済みアプリケーションが使用するバイナリーインターフェースであるABIの非互換性を、メジャーバージョンの引き上げによって示す。公開C APIに後方互換性のない変更があれば、メジャーバージョンを上げる。後方互換性のある機能、バックエンドの更新、モデルのサポート、APIの追加ではマイナーバージョンを上げ、APIを変更しないバグ修正ではパッチバージョンを上げる。
この方針は、3.5年にわたる開発と、プロジェクトのライブラリーインターフェースへの依存の高まりを受けたものだ。llama.cppは、マルチモーダルLLM推論を…を通じて提供する libllama一方、ggmlは機械学習用のテンソル層を…を通じて提供する libggmlこのソフトウェアは、量子化、最適化されたバックエンド、移植性の高いC/C++コードを活用し、一般消費者向けのマシンからエンタープライズサーバーまで、幅広いハードウェアを対象としている。
これにより、パッケージのメンテナーやアプリケーション開発者は、アップグレードによって自分たちの連携部分に問題が生じる可能性を判断するための、バージョン情報を得られる。メンテナーが2026年8月7日に行ったリリースプロセスに関する議論では、関連する安全策も示された。公式のllama.cppリリースタグは、内部に含まれるggmlのコピーが、リリースされたggmlのコピーと完全に一致する場合に限って作成される。この条件は、文書で説明されているDebianおよびHomebrewパッケージの方式、すなわちシステム全体にインストールされたggmlとの互換性を、リリースタグからビルドした成果物で確保することを目的としている。
ランタイム、モデル、サーバーの変更
llama.cpp v1.0.0のリリースノートでは、この互換性契約とともに大規模な整理が行われた。今回のリリースでは、非推奨となった35個の関数を含む公開APIを削除する一方、NextNの投機的デコードAPIを llama-ext.h 拡張ヘッダーから公開 llama.h ヘッダーへ移行する。この変更により、この投機的デコードインターフェースは、新しいバージョン管理ルールの対象となる公開APIに含まれる。
新たな推論機能として、OCP 8ビット浮動小数点（FP8）形式のキー・バリューキャッシュ、CPUへの割り当て比率を設定できる、mixture-of-experts（MoE）モデル向けのホストメモリーキャッシュ、個別のGGUFシャードからの外部PLEデータまたはエングラムデータの読み込みが追加されました。モデル関連の追加機能には、Kimi-K3.1-Pro、Ripple、xing4_0のテキストアーキテクチャ、テキスト読み上げ機能のdrama-3、MageVL-CoworkおよびKimi-K3.1のビジョン対応が含まれます。
llama-serverでは、サーバーサイドリクエストフォージェリ、クロスオリジンリソース共有、DNSリバインディングの問題に対処し、アクセス先を HF_TOKEN huggingface.coのホストに限定する。クライアントが切断またはタイムアウトした場合、MCPツールの呼び出しはキャンセルされ、その旨がMCPサーバーに通知される。新たなOpenAI互換 /v1/audio/speech エンドポイントにより、サーバーの音声インターフェースが拡張される。
再設計されたウェブインターフェースでは、名前を付けたチャットグループと、編集内容をリアルタイムで確認できるMarkdownエディターが追加された。モバイル向けレイアウトでは、端末のセーフエリアと全画面ダイアログに対応し、Androidのチャットエディターからは仮想キーボードを開ける。
ハードウェアバックエンドとリリース基盤
関連するggml v1.0.0のリリースでは、非推奨APIと従来のDIAG_MASK操作が削除され、設定可能なYaRNの切り詰めとFP8サポートが追加された。また、読み取られないスケジューラー入力のアップロードを避けるようになった。CUDAとMetalには、少数行の量子化行列乗算とMoE融合処理が追加された。そのほかのバックエンドの追加機能には、Intel Vulkanのプリフィル向けFlashAttentionカーネル、デバイス側で動作するSYCL MoEスケジューラー、OpenCLにおけるAdreno FlashAttentionの分割実装、新しいWebGPUカーネル、Hexagonでの操作サポートの拡充が含まれる。
ggmlの各バックエンドは動的ライブラリーとしてコンパイルでき、必要に応じて実行時に読み込めるため、インストール環境に応じてハードウェア固有のコードを選択できる。プレリリース成果物はLinux、macOS、Windows、Android、iOSに対応する。さらに、Docker、Debian、Homebrew、conda-forge、MacPorts、Winget、XCFrameworkも配布経路として提供されるが、対応プラットフォームはそれぞれ異なる。
開発ペースを支えるため、チームによると、Hugging Face BucketsとJobsがmasterブランチに取り込まれる変更に対応できるよう、継続的インテグレーションの処理能力を拡大している。NVIDIA、AMD、Qualcomm、Arm、IBM、Intelのハードウェアサポートによって、主要なハードウェアプラットフォーム全体で、セルフホスト型ランナーの利用も広がっている。メンテナーは開発サイクルへのLLMの導入も進めており、コード品質、アーキテクチャの制御、実装の詳細への理解を優先事項に挙げている。
下流のプロジェクトにとって、このリリースは、動きの速いオープンソースライブラリーとの互換性を保つことが、開発上の明確な責務となることを示している。バージョン管理ルールによって互換性を損なう変更を伝えられるほか、拡充されたCIとハードウェアランナーの取り組みにより、日常的なリリースが、各プロジェクトで使われるモデルやハードウェア上で引き続き安定して動作するかを確認しやすくなる。
