llama.cpp v0.8.0は、特にマルチモーダル推論において、ローカルAIにとって大きなアップデートです。2026年10月28日にリリースされ、Liquid AIのLFM3ファミリーやDeepSeek V4.1 Flashなどの新しいモデルアーキテクチャへの対応が追加されたほか、/v1/realtimeによる実験的なリアルタイム音声機能と、POST /ttsによるテキスト読み上げ機能が追加されました。モデル管理、サーバーツール、複数のメモリ処理経路も改善されています。ただし、新たに列挙されたすべてのアーキテクチャや音声ワークフローが、あらゆるデバイスで本番利用できる状態にあるわけではありません。
ホームサーバーで最初に行うべきことは、リリースのバージョンを固定し、動作確認済みのGGUFモデルを1つ実行して、ピークメモリ使用量とレイテンシを記録し、APIを非公開に保つことです。その後でビジョンや音声を試してください。新しいサーバーエンドポイントがあっても、互換性のある音声モデル、メディアフロントエンド、マイクの入力経路、アクセス制御、十分なGPU・CPU性能の代わりにはなりません。
| リリースに関する質問 | ホームサーバーユーザー向けの回答 |
|---|---|
| v0.8.0のリリース日は? | 2026年10月28日(GitHubのリリースタグ)。 |
| 注目の新しいモデルファミリーは? | Liquid AIのLFM3テキスト、ビジョン、音声、オムニに加え、その他のアーキテクチャにも対応。 |
| リアルタイム音声に対応していますか? | 実験的な音声ストリーミングAPIと/v1/realtimeサーバーエンドポイントが新たに追加されました。実際に利用できる機能はモデルやバックエンドによって異なります。 |
| TTSは利用できますか? | 互換性のあるテキスト読み上げモデル向けに、POST /ttsエンドポイントが追加されました。 |
| v0.8.0では、すべてのモデルで必要なRAMが減りますか? | いいえ。改善効果はワークロードやバックエンドによって異なります。RAM使用量は引き続き、選択したモデルとサービング設定によって決まります。 |
| これはZimaOSで実行できますか? | 互換性のあるLinuxビルドやコンテナで動作する可能性があります。この記事はZimaOSパッケージとしての認証を主張するものではありません。 |
llama.cpp 0.8.0で実際に何が新しくなったのか?
公式のv0.8.0リリースノートでは、変更点がモデル互換性、マルチモーダル対応、API・サーバーの更新、コアメモリ管理、バックエンド最適化に分類されています。このリリースを理解するには、ローカルユーザーがすぐに利用できる機能と、特定のハードウェアや新たな統合コードを必要とする高度な機能を分けて考えるのが最適です。
| 分野 | 確認された変更 | テスト項目 |
|---|---|---|
| モデルのサポート | LFM3-1.7B、LFM3-VL-2B、LFM3-Audio-2B、LFM3-Omni-2B、DeepSeek V4.1 Flashなど | 正確なチェックポイント、GGUF形式、チャットテンプレート。 |
| 音声ストリーミング | 実験的な mtmd_audio_stream API |
選択したモデルがライブ音声フレームを正しく処理できるかどうか。 |
| リアルタイムサーバー | 新しい /v1/realtime 会話・文字起こしエンドポイント |
クライアントプロトコル、ストリーミング動作、障害復旧。 |
| 音声出力 |
対応するTTSモデル向けのPOST /tts |
モデルとの互換性、音声出力の品質、レイテンシ。 |
| MoEメモリ | ホストメモリ上のエキスパートキャッシュ方式をLRUから50/50 SLRU設計に変更 | ピーク時のRAM使用量、ディスク/ネットワーク負荷、対象MoEの実測トークン/秒。 |
| サーバー/ルーター/UI | デバイスメモリの余裕、会話ツールの改善、Hugging Faceでのモデル閲覧とダウンロード | 永続化、デバイスの制限、再現可能なモデル選択。 |
| バックエンド |
ggml v0.28.0とCUDA/SYCL/OpenCL/Hexagonの改善 |
デプロイ前のプラットフォーム固有のリグレッション。 |
DeepSeek V4.1 Flashアップデートの解説は、モデルの更新とランタイムがモデルを読み込む機能を区別するのに役立ちます。リリースノートに「対応」と記載されていても、特定の量子化方式、GPU構成、リアルタイムのユーザー体験が保証されるわけではありません。
このリリースではリアルタイム音声とテキスト読み上げはどのように機能しますか?
これまで、自宅でホストする音声アシスタントでは、マイク音声の取得、音声からテキストへの変換、LLMへのリクエスト、音声合成といった別々のコンポーネントを組み合わせることが一般的でした。バージョン0.8.0では、マルチモーダルインターフェース(mtmd)に実験的な音声入力ストリーム経路が導入され、OpenAI形式のリアルタイムプロトコルを使用するリアルタイムサーバーエンドポイントが公開されます。また、互換モデル向けの独立したPOST /ttsエンドポイントも用意されています。
これらは別個の機能です。/v1/realtimeは、音声ストリーミングを使う会話または文字起こしのワークフローの入口です。/ttsは、対応する音声モデルを通じてテキストから音声を生成します。どちらも単独で常時待機型のアシスタントを実現するものではなく、実際のチェックポイントをテストしない限り、特定の言語、往復の遅延、出力音声形式、プラットフォームとの統合が保証されるわけでもありません。

実用的な音声テストとして、マイクの権限、サンプルレート、コーデック変換、部分フレームの処理、発話終了の検出、キャンセル、ネットワークタイムアウトへの対応を確認してください。音声録音と文字起こしデータは、明確な保存ポリシーに従って保管してください。ユーザー向けアプリが別のマシンで動作している場合、推論がNAS上で実行されるからといって、音声がネットワークを通過しないわけではありません。
メモリとMoEの変更が重要なのはなぜですか?
v0.8.0では、ホストメモリに保存された混合エキスパート(MoE)の重み向けに、セグメント化されたLRU(SLRU)キャッシュを50/50で導入しています。再利用パターンの異なるエキスパートを、より適切に扱うことが目的です。実際の効果は、エキスパートのルーティング、プロンプトの分布、メモリへの常駐状況によって異なります。一般的な小型の密モデルでは、この変更の効果はほとんどないか、まったくない場合があります。
スパースアテンションの処理も再構成され、リリースには、よりすっきりしたno_allocの処理、新しいggml演算、バックエンドの最適化が含まれています。これらはメモリ割り当てやスループットに影響する可能性がありますが、モデル配信の基本的な計算式を覆すものではありません。重みの使用メモリ + 実行時バッファー + KV/コンテキストの状態 + マルチモーダルテンソル + 同時実行数 + 運用上の余裕。
4ビットの2Bクラスのモデルは、大型のチェックポイントが収まらない環境でも、容易に動作させられる場合があります。それでも、長いプロンプトの処理や複数のクライアントへの配信は、小型NASに過大な負荷をかけることがあります。モデルのメモリ使用量に基づくルーティングガイドでは、容量計画ではGGUFのダウンロードサイズだけでなく、ピーク時の総メモリ使用量も考慮すべき理由を解説しています。Kimi K3のデプロイ上限に関する分析では、その逆の極端な例を示しています。実行時機能を使っても、1兆パラメーターのチェックポイントを一般向けデバイスのメモリに収めることはできません。
ローカルで実際に試せる新しいモデルは?
手早く測定可能なローカル実験を試したいなら、未テストの大型マルチモーダルチェックポイントよりもLFM3-1.7B GGUFのほうが適切な出発点です。公式のGGUFカードには、llama.cppとの互換性が記載されています。画像や動画が必要になったらLFM3-VL-2Bに移行し、正しいプロジェクターと前処理をテストしてください。音声やオムニモーダル機能には、それぞれのモデルに対応した専用の統合が必要です。
| ワークロード | 実用的な出発点 | 決めつけない |
|---|---|---|
| CPUのみの8 GBホストでのテキスト推論 | 小型のQ4 GGUF、4Kコンテキスト、同時リクエスト1件 | 高速な音声処理、または256Kコンテキストのサービス。 |
| 16 GB以上でのプライベート文書Q&A | 小型モデルと独立した検索・インデックスサービス | モデルがNAS上のファイルを自動で読み込みます。 |
| 16~32 GB以上のメモリ、または適切なGPUでのビジョン処理 | VLモデルと検証済みのビジョンプロジェクター | 画像・動画トークンの料金は通常のテキストと同じです。 |
| 十分な性能を備えたテストマシンで動作する音声アシスタント | 互換性のある音声モデルと実験的なAPIクライアント | クライアント側のテストなしで、安定した無人24時間365日運用。 |
| 共有ZimaCube 2サービス | ストレージ、モデルキャッシュ、アプリデータを分離し、リソースに上限を設定する | ディスク容量だけでGPU並みの推論速度が得られます。 |
ローカルモデルのサイズや量子化についてさらに比較するには、一般向けハードウェアのAIモデルガイドをご覧ください。ZimaOS App Storeを利用する場合は、Ollamaのハードウェア要件に別のデプロイ方法が記載されています。Ollamaのパッケージとllama.cppの上流機能は、同等の保証として扱えるものではありません。
Linuxにllama.cpp v0.8.0をインストールして検証する方法
以下はソースからビルドして検証する手順であり、v0.8.0がすでにZimaOS App Storeで利用可能だという、裏付けのない主張ではありません。CPU対応サーバーをビルドし、再現性のためにタグを固定し、ドキュメントに記載されたLFM3 GGUFを使用して、ループバックのみにバインドします。
git clone https://github.com/ggml-org/llama.cpp.git
cd llama.cpp
git checkout v0.8.0
cmake -S . -B build
cmake --build build --config Release -j --target llama-server
./build/bin/llama-server \
-hf LiquidAI/LFM3-1.7B-GGUF:Q4_K_M \
-c 4096 --host 127.0.0.1 --port 8080
同じホストの別のターミナルで、サーバーが実際にモデルを読み込んだことを確認します。
curl -s http://127.0.0.1:8080/v1/models
curl -s http://127.0.0.1:8080/v1/chat/completions \
-H 'Content-Type: application/json' \
-d '{"model":"local","messages":[{"role":"user","content":"ローカルのGGUFモデルの利点を2つ挙げてください。"}],"max_tokens":128}'
必要に応じて、"local"を/v1/modelsが返す正確なモデルIDに置き換えてください。リリースでは、現在のCLIの使い方でモデル引数(--modelまたは-hf)が明示的に必須とされているため、どちらも指定しない古い起動スクリプトは動作しなくなる可能性があります。対応するCUDA、Vulkan、Metalなどのバックエンドの選択肢については、上流のビルド手順を参照してください。認証、TLS、制限、信頼できるクライアントの境界を設定するまでは、ポート8080をパブリックに公開しないでください。
コンテナベースのホームサーバーでは、永続的なモデルストレージ、リソース制限、互換性のあるCPU/GPU機能、検証済みのマウントマッピングも必要です。次に参考にするのに最適なのは、NASアプリを壊さずにローカルLLMをデプロイするです。モデルのダウンロード先を共有ブートドライブに移す前に、手順に従ってください。
既存のAIサーバーをアップグレードする前に、何をテストすべきですか?
上流のリリースに多くの機能が追加されると、サーバーが問題なく起動しても挙動が変わる場合があります。現在のバイナリまたはコンテナイメージ、モデルのハッシュ、以前のフラグ、受け付けられたレスポンスを少なくとも1つ、ロールバック用の記録として保管してください。そのうえで、小規模な回帰テストの組み合わせを実行してください:
- 互換性:タグ、GGUFファイル名、チェックサム、バックエンド、チャットテンプレートを記録し、起動時の警告を確認してください。
- レイテンシ:モデルやコンテキストを変えずに、両方のバージョンで同じ短いプロンプトと長いプロンプトを実行し、プリフィル時間、デコード速度、レイテンシの95パーセンタイルを記録してください。
- メモリ:ホストRAMとVRAMのピーク使用量、モデルのアンロード動作、同時リクエスト数、他のNASアプリが引き続き快適に応答するかを記録してください。
- 音声:関連機能を使う場合は、リアルタイム接続のライフサイクル、文字起こし、TTS出力、キャンセル、再接続を個別に検証してください。
- セキュリティと復旧:ネットワークのバインド、ファイルのアクセス権、永続化パス、再起動時の挙動、以前のバイナリへのロールバックを確認してください。
モデルファイルのパス確認チェックリストと、ランタイムの状態と重みファイルを分離する方法をご確認ください。モデルブラウザーでダウンロードが簡単になる場合は、特に重要です。ダウンロードが簡単だからといって、数ギガバイトのデータが実際にどこに保存されたかを把握しなくてよいわけではありません。
よくある質問
llama.cpp v0.8.0はLFM3と同じものですか?
いいえ。llama.cppは推論ランタイムです。LFM3はLiquid AIのモデルチェックポイントのファミリーです。v0.8.0では新たにLFM3の統合がサポートされますが、モデルファイルは別途選択して入手する必要があります。
v0.8.0では、あらゆるGGUFモデルとリアルタイムに会話できますか?
いいえ。新しい音声経路は実験的で、モデルによって異なります。サーバーが/v1/realtimeや/ttsを公開していても、テキスト専用モデルに音声の入出力機能が備わるわけではありません。
/v1/realtimeは本番環境で使用できる音声APIですか?
リリース時点では実験的な機能として扱ってください。無人で稼働させる前に、選択したモデル、音声エンコード、クライアントとの互換性、中断時の挙動、想定されるセッション数での安定性をテストしてください。
アップグレードすると、すべてのモデルでVRAM使用量が減りますか?
必ずしも必要ではありません。メモリやバックエンドの変更によって、特定のワークロードの性能が向上する場合があります。ただし、VRAMとRAMの必要量は、重み、コンテキスト、量子化、デバイスのバックエンド、リクエスト数によって異なります。リリースノートから推測するのではなく、実際の環境でベンチマークしてください。
llama.cppの実行にNVIDIA GPUは必要ですか?
いいえ。CPU 推論と複数の GPU バックエンドに対応しています。CPU のみの処理でも小型モデルなら十分な場合がありますが、適切なアクセラレーションを利用する場合に比べると、大幅に遅くなることがあります。まず利用可能な RAM とモデルサイズを確認してから、バックエンドを選択してください。
ZimaOS App Store から v0.8.0 を直接インストールできますか?
この記事では、ZimaOS App Store パッケージのバージョンを検証しておらず、公式のワンクリックインストール方法も紹介していません。このガイドでは、上流の Linux ソースコードを特定のバージョンに固定してビルドする方法を説明し、お使いのハードウェアやコンテナー環境に応じて応用できる確認手順を紹介しています。
以前の llama-server コマンドは変更せずに使い続けられますか?
フラグとモデルを確認してください。v0.8.0 のリリースノートによると、現在の CLI コマンドには --model または -hf が必要です。バージョンを固定し、起動ログを確認し、API の応答をテストしてください。稼働中のサービスを変更する前に、ロールバック用ファイルも保管しておきましょう。
まとめ
llama.cpp v0.8.0 がすぐに役立つのは、モデル互換性の拡大と、より高機能なローカルサーバーです。リアルタイム音声は期待できる一方で、まだ実験的な機能です。プライベートなループバック API で小型の LFM3 GGUF を動かすのは、最初の検証目標として妥当です。画像入力、音声ストリーム、同時利用ユーザーを追加する前に、実際のメモリー使用量と出力品質を記録してください。
NASを使う場合、適切な構成の基本は変わりません。既知のボリュームにモデルを保存し、実際に利用できる RAM/VRAM に合った推論ランタイムを選び、保護されたアプリケーションからその API を利用します。ZimaCube 2 はプライベートなストレージおよびアプリケーションプラットフォームとして活用できますが、実測したハードウェアとバックエンドの構成がないまま、高速なマルチモーダル推論ノードとして確実に使えると謳うべきではありません。新たにサポートされたモデルファミリーを検討している場合は、実際のランタイムのリリースノートとあわせて、LFM3 のローカルモデルとハードウェアガイドをご覧ください。
情報源と対象範囲
2026年10月29日に確認した公式ドキュメント:llama.cpp v0.8.0 のリリースノート、上流のビルドガイド、LFM3-1.7B 公式 GGUF、LFM3-VL 公式 GGUF、Liquid AI の発表解説。機能サポートに関する情報は上流のリリースノートに基づいています。ZimaSpace は、このリリースのベンチマークを独自に実施しておらず、特定の ZimaOS ビルドでの動作も認定していません。
テクノロジー&AIハブ
続きを読む

ホームAIスタックの目標復旧時点を決める要因とは?
ホームAIスタックにおける目標復旧時点を仕組みから解説し、共有リソースのトレードオフ、クエリファンアウトに関する3つのFAQ、実践的な内容を紹介します。

複製されたAIインデックス間のサイレントな不一致を検出するコンポーネントとは?
複製されたAIインデックス間のサイレントな不整合を検出するコンポーネント、その共有リソースに関するトレードオフ、クエリのファンアウトに関する3つのFAQを、仕組みを中心に解説します。

家庭内デバイス間でAIセッションを確実に引き継ぐための機能とは?
家庭内デバイス間でAIセッションを確実に引き継ぐ仕組みを中心とした解説、共有リソースに伴うトレードオフ、クエリのファンアウトに関する3つのFAQ、そして実践的な




