llama.cpp対応プラットフォーム完全ガイド

llama.cppとは、CPUとGPUの双方でLLMをローカル実行するための軽量推論エンジンだ。

llama.cppの公式リリースを開くと、ひとつのタグに対して20種類以上のビルドが並んでいる。macOSのApple Silicon版、Intel Mac版、Linuxのs390xビルド、Windows ARM版、CUDA 12用とCUDA 13用、Vulkan、SYCL、HIP、ROCm 7.2、OpenVINO、そしてopenEuler。「ローカルLLMを動かしたいだけなのに、どのファイルを落とせばいいのか」と立ち止まった人は多いはず。

実はこの分岐の多さこそ、llama.cppがいま最も「OSとハードウェアを選ばないLLM実行基盤」になっている証拠でもある。本記事では、ggml-orgが公式に配布しているllama.cppのビルド群をOS×CPUアーキテクチャ×GPUランタイムの3軸で整理し、自分の環境に最適な1本を逆引きで選べるよう徹底解説する。最新リリース（b8691・b8823・b8827・b8846）の動向にも触れ、単なるリリースノート翻訳では届かない「なぜこの構成なのか」まで踏み込む。

llama.cppが多様なプラットフォームをサポートする理由

llama.cppの公式リリースページ（ggml-org/llama.cpp）を開くと、最新タグ b8823（2026年4月17日リリース）には、macOS／iOS／Linux／Windows／openEuler の5プラットフォームに対する配布物がずらりと並んでいる。タグごとの中身を数えると、CPU向けビルドだけで10種類、GPUバックエンド込みなら20を超える派生が同時に提供されているのが現状。これは他のLLM推論ランタイムと比べても突出した広さといえる。

なぜここまで分岐するのか。理由はシンプルで、ローカルLLMを動かしたい人のハードウェア環境がそれだけ多様化しているから。RTX 5080を積んだWindows自作機もあれば、M系Macで完結したい人もいる。Intel ArcやAMD Radeonを使う人もいるし、サーバー用途でAscend NPUに載せたい中国市場のニーズもある。llama.cppはCPUのみのフォールバックを残しつつ、各GPUベンダーのランタイムにも個別対応しており、その組み合わせ爆発がそのまま配布物の数になっている。

配布されているビルドの大分類（macOS／iOS・Linux・Windows・openEuler）

公式リリースに載っているビルド群を大分類で整理すると、以下の表のようになる。

この表だけでも10種類を超える。さらにWindowsのCUDAは12.4 DLLs版と13.1 DLLs版が別ビルドで並んでおり、openEulerも310pと910bでさらに分かれる。「どれを落とせばいいか」が最初の難関になるのは当然の構造だ。

なぜ用途別ビルドが必要か（依存ライブラリ・GPUランタイム差）

llama.cppがビルドを統合しないのは、各バックエンドが要求する依存ランタイムやドライバが互いに排他的だから。CUDA 12.4向けのDLLとCUDA 13.1向けのDLLは別物で、同梱して動かすことができない。ROCmはAMD公式GPUランタイムでLinux優先、HIPはAMDのWindows向け実装、Vulkanはベンダーを問わない汎用GPU API、SYCLはIntelのoneAPI寄り。それぞれが別の動的ライブラリ群とリンクされる以上、配布物としては分割せざるを得ない。

裏返せば、ユーザー側からみると「自分のGPUに対応するバックエンドを内蔵したビルドを1本落とせば動く」状態が達成されている。ソースから自分でCMakeをいじってビルドする必要は基本的にない。この「事前ビルド済み配布物の網羅性」がllama.cppを実用ツールに押し上げている要因のひとつだ。

macOS／iOS 向けビルドの選び方

Apple Silicon時代に入ってから、macOSはローカルLLM実行のしやすさで一気に存在感を増した。統合メモリアーキテクチャ（CPUとGPUが同じメモリを共有する構造）のおかげで、VRAM不足を気にせず大規模モデルを扱えるのがM系Macの強み。llama.cppもこの環境を厚くサポートしており、最新のb8823では従来の Apple Silicon (arm64) に加え、KleidiAI enabled 版が並んで配布されている。

arm64 ビルドと KleidiAI 対応版の違い

KleidiAIとは、ARM社が公開しているARMアーキテクチャ向けの行列演算最適化ライブラリのこと。LLMの行列乗算（matmul）処理は推論コストの大半を占めるため、ここをARM CPUの命令セットに合わせて最適化すると体感速度が変わる。b8823で「macOS Apple Silicon (arm64, KleidiAI enabled)」が並列配布されたのは、この最適化を有効にしたバイナリを別途用意したことを意味する。

通常のarm64版でもMetalバックエンド経由でGPUは使えるが、CPU側の演算ルートを通る場面（量子化テンソルの一部処理など）でKleidiAI版は効きが期待できる。M系Macユーザーが新規にllama.cppを試すなら、KleidiAI enabled版を第一選択にしておくのが素直な判断になる。

Intel Mac ユーザーの選択肢

Intel Mac（x64）向けビルドも継続して配布されている。M系移行から年数が経ったとはいえ、現役のIntel MacBook Pro/iMacは依然として一定数残っており、llama.cppがx64ビルドを切り捨てていない点は実用上ありがたい。とはいえ、Intel Macには専用のGPUバックエンドが付いていないため、CPU推論が基本になる。3Bクラスの軽量モデルや量子化済み7Bあたりを動かす運用が現実的なライン。

「Intel MacからM系Macに買い替えるべきか迷っている」という人にとって、llama.cppの動作差はひとつの判断材料になる。同じ7Bモデルでも、Apple Siliconの統合メモリ＋Metalルートのほうが体感は明らかに上、というのが一般的なユーザー報告のトーンだ。

iOS XCFramework が想定する組み込み用途

iOS XCFrameworkは、iPhone/iPad向けアプリにllama.cppを組み込むための配布形態。XCFrameworkとはApple純正のフレームワーク配布形式（複数アーキテクチャ・複数プラットフォームを1パッケージにまとめる仕組み）のこと。これがあるおかげで、サードパーティ製のオフラインAIアプリ（オンデバイスLLMチャット、字幕生成、要約アプリなど）が比較的容易にllama.cppを内部エンジンとして取り込める。

PCで使う一般ユーザーには直接関係しないが、「llama.cppがiOSの組み込み用途まで視野に入れている」事実は、同プロジェクトのスコープがどれだけ広いかを示している。

Linux CPU ビルドの対応アーキテクチャ

Linux向けにはCPUのみのビルドが3アーキテクチャ提供されている。x64（Intel／AMD）、arm64、そしてs390x。最後のs390xはIBM Zメインフレーム向けの命令セットで、ここがリストに並んでいる事実は、llama.cppの想定ユーザーがホビイストだけではないことをはっきり示している。

x64 / arm64 ビルドの選び方

一般的なLinuxサーバーやデスクトップを使っているなら x64 ビルドを選ぶ。RaspberryPi（4以降）、AmpereのArmサーバー、Apple Silicon上のAsahi Linuxといった環境では arm64 ビルドが対応する。後者の用途は近年広がっており、Raspberry Pi 5での量子化済み3Bモデル動作報告も増えている。Linux上のarm64でllama.cppを動かす選択肢は、もはや特殊な実験ではない。

注意点としては、CPUビルドではGPUは使われないため、純粋なCPU推論の速度しか出ない。量子化（モデルの数値精度を落としてサイズと計算量を下げる手法）と組み合わせて、3B〜7Bクラスを現実的に動かすのが基本ライン。8Bを超えるモデルをCPUで快適に回すのは依然厳しい。

s390x がサポートされる業務的背景

s390xはIBM Zシリーズのメインフレーム向けアーキテクチャ。「メインフレームでLLMを動かす需要があるのか？」と疑問に思うかもしれないが、金融・保険・公共系の基幹業務がIBM Zで稼働している現場では、業務データを外部に出さずオンプレミスでAI推論を走らせたいニーズが確実に存在する。llama.cppがs390x向けバイナリを配り続けているのは、こうしたエンタープライズ用途の受け皿として機能しているから。

CPUのみとはいえ、メインフレームは並列性能と信頼性が桁違いに高い。バッチ処理で大量の文書を要約・分類するような用途には、案外フィットする。

Linux GPU バックエンドの全体像（Vulkan・ROCm 7.2・OpenVINO）

Linuxでは3種類のGPUバックエンドが並列配布されている。Vulkan、ROCm 7.2、OpenVINO。それぞれが対応するハードウェアと得意領域は異なり、誤って選ぶと「ビルドは動くがGPUに仕事が回っていない」状態になる。リリースタグb8691（2026年4月7日）では Vulkanビルドのfork失敗時にerrno文字列を出力するよう改善（#20868, #20904）が入っており、トラブルシュート性も少しずつ磨かれている。

Vulkan ビルドが汎用GPUの第一選択になる理由

Vulkanはクロスベンダーのグラフィック・コンピュートAPI。NVIDIA／AMD／IntelのGPUが共通して対応するため、llama.cppのVulkanビルドは「ベンダーを問わず動く保険」として機能する。CUDA環境を整えるのが面倒なケース、AMD Radeon／Intel ArcのGPUでとりあえず動かしたいケースで第一候補になる。

公式に配布されている Ubuntu x64 (Vulkan) と Ubuntu arm64 (Vulkan) を使えば、ARMサーバーに載せたGPUでもVulkan経由でアクセラレートできる。ただし、Vulkan経由はCUDAやROCmのネイティブパスより最適化が薄い場面があり、ピーク性能ではベンダー固有バックエンドに譲ることが多い。

ROCm 7.2 ビルドと AMD GPU の対応状況

ROCm（Radeon Open Compute）はAMDのGPGPUランタイム。CUDAに対するAMD公式の対抗実装にあたる。llama.cppの Ubuntu x64 (ROCm 7.2) ビルドは、ROCm 7.2環境を前提に、AMDのRadeon／Instinct系GPUでネイティブ性能を引き出すためのもの。

AMD GPUでLLMを本気で動かしたいなら、Vulkan経由よりもROCmを選んだほうが性能は伸びやすい。ただしROCmは対応GPUと対応カーネルのバージョン制約がCUDAより厳しく、Linux以外（特にWindows）でのサポートが限定的。「Linuxサーバー＋RDNA系Radeon／Instinct」の組み合わせで初めて旨味が出る、と理解しておくとよい。

OpenVINO ビルドが効くIntel CPU/GPU/NPU環境

OpenVINOはIntelが開発する推論最適化ランタイムで、Core Ultra世代以降のCPU・統合GPU（Xe）・NPUを統合的に活用できる。llama.cppの Ubuntu x64 (OpenVINO) ビルドは、Intel系ハードウェアを抱えた環境でCPU/GPU/NPUを賢く使い分けたいユーザー向け。

Intel Arc Aシリーズ／Bシリーズを単体GPUとして搭載するLinuxマシンや、Core Ultraを積んだミニPCを「ローカルLLM専用機」に仕立てるケースでは、OpenVINOビルドが現実的な選択肢になる。NPUの推論パスはまだ全モデルで安定しているわけではないが、対応モデルなら省電力で動かせる利点が大きい。

なお、ローカルLLMをDockerやベアメタルのLinuxサーバーで本格運用する場合、OS構成の選定もビルド選びと同じくらい結果に影響する。当サイトでは関連テーマとしてllama.cppの仕組みと始め方やVRAM不足エラーの対処を別記事で扱っている。

Windows ビルドの全体像

Windows向けの配布物はとくにバリエーションが豊富で、CPUビルドが2種類、GPUバックエンドが5種類並ぶ。表で整理すると次のようになる。

これだけ並ぶと選択がややこしいが、見方は単純。まずはCPUのみで動かすか、GPUを使うかを決める。GPUを使うなら、自分のGPUベンダーに対応する行を選ぶ。NVIDIA環境でCUDAを選ぶ場合だけ、12と13のバージョン分岐が追加で発生する、という構造。

Windows arm64 CPU ビルドが想定するハードウェア

Windows arm64 CPUビルドは、QualcommのSnapdragon Xを搭載したCopilot+ PCや、Microsoft Surfaceのarm64モデルを念頭に置いたバイナリ。x64エミュレーション経由でも動かせなくはないが、ネイティブのarm64ビルドのほうが当然速い。

ARM Windows環境はバッテリー駆動時間と省電力性が魅力で、外出先でローカルLLMを軽く動かすケースに向く。ただしGPUバックエンドはWindowsのarm64側にはまだ整備されておらず、CPU推論オンリー。3B量子化モデルの応答待ちを許容できる人向けの構成、という現実は押さえておきたい。

GPUバックエンドの並列配布が意味するところ

CUDA 12 と CUDA 13 の併存、Vulkan・SYCL・HIP の並列配布は、ユーザーに「どれかひとつを強要しない」設計方針の表れ。CUDA一本足にしてしまえば配布側のメンテコストは下がるが、それだとIntelやAMDのGPUを持つユーザーは置いてけぼりになる。

ローカルLLMの実行先がNVIDIAだけのものではなくなりつつある、という大きな流れを踏まえると、この分散配布はむしろ自然な進化と読み取れる。RX 9070 XTのような16GB VRAMを9万円台で出してくるAMDの動きや、Intel Arcの存在感を考えると、HIP／SYCLビルドの重要性は今後も増していく見込みだ。

Windows CUDA 12 と CUDA 13 の使い分け

Windows向けCUDAビルドが CUDA 12.4 DLLs版 と CUDA 13.1 DLLs版 の両方で配布されているのは、llama.cppの設計判断としてかなり親切な部類に入る。一般的には、CUDAランタイムは新しい方ほど新しいGPUアーキテクチャを最適にサポートする一方、古いドライバやWSL2環境では旧版のほうが通りがよい場面もある。両方が並ぶことで、ユーザー側のドライバ更新都合に合わせて選べる構造になっている。

CUDA 12.4 ビルドが必要なケース

CUDA 12.4 DLLs版は、CUDA 12系のランタイムを前提とするビルド。NVIDIAドライバが少し古めで、CUDA 13系まで上げきれていないマシンや、企業内ポリシーで最新ドライバへの更新が即座にできない環境ではこちらが安全側の選択になる。

GeForce RTX 40系以前のGPUを使っている場合、必ずしもCUDA 13に上げる必要はない。CUDA 12系で十分にチューニングされた llama.cppバイナリが安定して動くなら、無理に最新版へ追従するメリットは薄い。「いま動いている環境を壊したくない」を優先する運用にはCUDA 12.4ビルドが合致する。

CUDA 13.1 ビルドを選ぶべきケース

CUDA 13.1 DLLs版は、CUDA 13系のランタイムが入った新しめの環境向け。NVIDIA公式のCUDAリリースノートに沿うかぎり、新世代のアーキテクチャ向け最適化や新しい数値型サポートが入りやすいのは新CUDA側になる。RTX 50系（Blackwell世代）を新規に購入した人や、ドライバを最新に保っている自作機ユーザーは、CUDA 13.1ビルドのほうが将来的な恩恵を受けやすい。

ただし、ここで断定的な相性表を書くのは避けたい。NVIDIA公式仕様と実機検証で裏が取れる範囲では「新世代ハード×新CUDAランタイム」が組み合わせとして筋が通る、という整理にとどめておくのが安全。古いゲームと違って、AI推論は依存関係の更新が早く、半年単位で「常識」が動く分野でもある。

同居環境（複数GPU）での選択

複数GPUを同居させている環境ではCUDAビルドの選択がややこしくなる。例えば当サイトの検証環境（RTX 5080 16GB ＋ RTX 5060 Ti 16GB ／ i7-14700F ／ RAM 96GB）のようにデュアルGPUで運用する場合、両GPUが揃って対応するCUDAランタイムを選ぶのが基本になる。新世代と旧世代を混載しているなら、新CUDAランタイム側のドライバが旧GPUもサポート対象に含めているかを確認したうえで決めるのが筋の通るやり方。

CUDA 12 と CUDA 13 のどちらを採用しても、llama.cpp側がモデルロード時に対応バックエンドを自動選択してくれるため、ユーザーが個別にデバイスを指定する手間は最低限に抑えられる。とはいえ、複数GPUで負荷を分散させたい場合は環境変数（CUDA_VISIBLE_DEVICESなど）でデバイス順を明示的に固定しておくと、再現性が高く運用しやすい。

Windows の Vulkan / SYCL / HIP の位置付け

CUDA以外のWindows GPUバックエンドが3つも並んでいるのは、ベンダーごとの実行系を取り込もうとしているから。ここを整理しておくと、CUDAが使えない環境でもローカルLLMを動かす道筋が見える。

Vulkan が「全方位的な保険」になる理由

Windows x64 (Vulkan) ビルドは、特定ベンダーに紐づかない汎用GPUランタイムを使う。NVIDIA・AMD・Intelのいずれも、Vulkan対応ドライバを公式に提供しているため、Vulkanビルドはほぼ全てのデスクトップGPUで動く可能性を持つ。

具体的にメリットとして効くのは、CUDA非対応の環境でもとりあえず動かせる点。例えば古めのIntel iGPUしかない環境や、RadeonでROCm非対応世代のGPUを使っている場合でも、Vulkanビルドなら推論が通ることがある。性能はCUDAやHIPの専用バックエンドに比べると落ちるケースが多いものの、「動くこと」自体が貴重な選択肢になる場面は意外と多い。

b8691のリリースで、Vulkanビルド側のfork失敗時にerrnoの内容を出力するよう改善が入っている（#20868、#20904）。表面的には小さな修正だが、Vulkanビルドは多様な環境で動く分、エラーの切り分けが難しくなりがち。errno表示が出るだけでも、デバッグ時の手がかりは増える。

SYCL と HIP の現実的な選択ライン

Windows x64 (SYCL) ビルドは、Intel製GPU・iGPU・NPUを統一的に扱うためのランタイム。Intel ArcシリーズやXe系iGPUを持っている環境でローカルLLMを動かしたい場合、SYCLビルドが選択肢になる。Vulkanでも動かないわけではないものの、SYCLの方がIntel GPUに対しては最適化が効きやすい。

Windows x64 (HIP) ビルドは、AMD公式のHIP（Heterogeneous-compute Interface for Portability）を使うランタイム。Radeonユーザー向けで、ROCmとは別系統のWindows寄りパッケージング。LinuxではROCm 7.2が選べる一方、Windowsで安定運用したい場合のRadeonユーザーはHIPビルドが現実的な選択肢になる。

整理すると、Windows環境でCUDAが使えない場合の選び方はシンプル。Intel系GPUならSYCL、AMD系GPUならHIP、それでも動かないか不明な環境ならVulkanで保険をかける、という3段階で考えると迷いが少なくなります。

openEuler 対応が示すエンタープライズ Linux 戦略

openEuler向けに4種類ものビルドが配布されている事実は、見過ごされがちながら戦略的に重要な情報。ここから読み取れるのは、ローカルLLMの実行環境がx86サーバーやコンシューマGPUの世界だけにとどまらない、という潮流の広がり。

openEuler が AI 用途で並列配布される意味

openEulerは、Huaweiが主導して立ち上げ、現在はオープンアトムオープンソース基金会の下で開発されているLinuxディストリビューション。エンタープライズ用途を強く意識しており、中国国内のサーバー市場ではシェアを伸ばしている存在。

llama.cppの公式ビルドにopenEuler x86（310p）・openEuler x86（910b, ACL Graph）・openEuler aarch64（310p）・openEuler aarch64（910b, ACL Graph）の4種類が並んでいる事実は、x86サーバーとARMサーバーの両方で、専用AIアクセラレータと組み合わせる前提のリリースが存在することを示している。

これは何を意味するか。一言でまとめるなら、ローカルLLMの実行先がx86＋NVIDIA GPUという「Western Stack」に閉じない時代に入っているということ。CUDAやROCmが使えない環境でもAI推論を回したい需要が、企業向けLinuxの世界で確実に存在しているわけです。

310p / 910b の違い（推論寄り vs 学習寄り）の概観

310pと910bは、Huaweiが提供しているAscend系AIアクセラレータの製品ライン名。一般的に310系列は推論向け、910系列はより上位で学習・大規模推論向けと整理されている。ACL Graphは、Ascend Computing Language（ACL）のグラフ実行ランタイムで、910b対応ビルドにはこのACL Graph経由での実行系が組み込まれている。

llama.cpp公式リリースの公開タグから読み取れる範囲では、x86・aarch64それぞれに310pビルドと910b（ACL Graph）ビルドが並んでいる。つまり、サーバーCPUのアーキ（x86かARM）と、AIアクセラレータの種類（310pか910b）の組み合わせを丸ごとカバーしようとする意図が明確に見える。

エンタープライズ系のローカルLLM運用、特に中国市場や国産アクセラレータ前提の環境では、こうした選択肢があるかどうかで導入のハードルが大きく変わる。ベンダー独占からの脱却という視点で見ると、llama.cppがコミュニティ主導でこのレベルの対応を維持していること自体が興味深い動き。

b8823 で入った「アーキテクチャごとの単一 llm_build」化

ここからはコード構造側の変化を見ていく。b8823のリリースノートに記載されている「model: using single llm_build per arch (#21970)」は、表面的にはコードのリファクタに見えるが、長期的な保守性とユーザー体験に効く重要な整理。

アーキテクチャ単一化が長期的に効く理由

llama.cppは、対応するモデルアーキテクチャ（Llama・Mistral・Qwen・Gemmaなど）の数が増えるたびに、推論グラフを構築するためのコードパスも追加されていく構造。従来は新アーキの追加に伴って分岐が増え、似たような関数が複数ファイルに分散しやすい状態になっていました。

「single llm_build per arch」は、この分散したコードパスを1アーキ1ビルダー関数にまとめ直す方向の整理。コードの重複を減らし、新しいモデルアーキテクチャを追加するときの参照点を1か所に集約できるようになる。

なぜこれが長期的に効くのか。理由は2つある。1つ目は、保守コスト。アーキテクチャが10種類を超え、量子化フォーマットが多様化していくほど、分岐ロジックのバグは検出が難しくなる。単一化により、テスト範囲を絞り込みやすくなる。2つ目は、新規参入者の導入障壁。コミュニティ主導の開発において、コードの読みやすさはコントリビューターの増加に直結する要素。

ユーザー視点での影響（ビルド時間・バグの再現性）

エンドユーザー視点で見ると、内部のリファクタは普段意識しなくてもいい部分。とはいえ、影響がゼロではありません。

具体的には、ビルド時間の短縮に効く可能性がある。コードパスの整理は、コンパイル単位の整理にもつながりやすく、自分でllama.cppをソースからビルドする上級ユーザーにとっては時間短縮として体感できる場面が出てくる。

もう1つは、バグの再現性。アーキ別の分岐が散らばっていた時代は「特定モデル＋特定量子化＋特定バックエンド」の組み合わせでしか再現しないバグが発生しやすかった。単一化された後は、アーキ単位でのテストカバレッジが効きやすくなり、issueとして報告された問題の追跡もスムーズになる方向に進むはず。

ここで提示している仕様は、公式リリースページから直接拾える情報の範囲。ベンチマーク的な「どれくらい速くなった」という数値は、リリース内容に明記されていない以上、本記事では言及しない。

直近コミットで進んだ最適化（OpenCL/Adreno と meta backend）

b8823の前後に入っている最適化系コミットも、llama.cppがどの方向に進化しているかを示す指標になる。直近4タグ（b8691→b8823→b8827→b8846）を並べると、ハードウェア対応の広がりとマイクロ最適化が並走している様子が見えてきます。

OpenCL/Adreno 改善が示すモバイルAI推論の重要度

b8827（4月17日リリース）の主要変更は、OpenCLバックエンドにおけるq8_0量子化のset_tensorとmul_matの、Adreno向けディスパッチのリファクタリング（#21938）。Adrenoは、Qualcomm Snapdragonに搭載されているモバイルGPUのブランド名。

q8_0は8ビット整数量子化フォーマットの1つで、モデルサイズと推論速度のバランスがよく、ローカルLLM用途で広く使われている形式。set_tensorはGPU上にテンソルデータを書き込む操作、mul_matは行列積の処理ですね。これらをAdrenoに合わせて整理し直したということは、Snapdragon搭載スマホやノートPCで、量子化済みLLMを実用的な速度で動かす取り組みが具体化していることを意味する。

モバイルAI推論は、デスクトップGPUほど派手ではないものの、ユーザーベースの広さでは桁違い。Adreno向け最適化が定期的に入っているという事実は、llama.cppがクラウドからエッジまでをカバーしようとする姿勢を示している。

meta backend の最適化がもたらす推論コストへの影響

b8846（4月19日リリース）では、ggmlのmeta backendにおけるCPUオーバーヘッド削減が入っている（#22041）。具体的な変更点は2つあって、1つ目が「同じggml_cgraphが連続して使用される場合、サブグラフ構築をスキップする」、2つ目が「全てのサブグラフにUIDを割り当て、CUDAの高速UIDチェックパスをヒットさせる」。

これは何を意味するか。LLM推論はトークンを1つずつ生成する繰り返し処理になっており、各ステップでほぼ同じ計算グラフを使う。毎回サブグラフを再構築する処理は、無視できないCPUオーバーヘッドになっていた、ということ。同じグラフが連続するなら構築をスキップする、という最適化は、トークン生成ごとの推論レイテンシ削減に直接効く性質の変更。

CUDAパス側のUID割り当ても、同じ流れの中で意味が見えてくる。GPUカーネルの選択や引数のキャッシュをUID（一意識別子）ベースで高速化するパスがあり、サブグラフ全てにUIDを振ることで、そのパスを取りこぼさず使えるようになる。

短期間で立て続けにマイクロ最適化が入っていること、しかもCPUオーバーヘッド・GPUディスパッチ・モバイルGPU向けカーネルと最適化のレイヤーが分散していること。この方向性から見えてくるのは、llama.cppが「動くこと」のフェーズを越えて「効率を1%でも積み上げる」段階に入っている、という事実です。

ローカルLLMの実装を学ぶ目的で別のソフトに目を向けるなら、ComfyUIやStable Diffusion系の画像・動画生成パイプラインも参考になる。例えばLTX 1をComfyUIで動かすノード構成の全体像｜スクリーンショットで見る基本ワークフローでは、推論グラフの構築とノード単位での処理の流れが視覚的に追える。llama.cpp側でグラフ最適化が進む話を理解する助けになるはず。

自分のハードウェアに合うビルドの選び方

ここまで各ビルドの位置づけを整理してきました。最後に、読者が実際に「どれを落とせばいいのか」を逆引きできる選択フローを提示します。

ローカルLLM初心者向け：迷ったらこれ

選択フローは「OS→CPUアーキ→GPUランタイム」の3ステップ。まずOSで分岐し、次に持っているCPUアーキ（x64かarm64か）を決め、最後にGPUランタイムを選ぶ流れ。

文章で書くと長くなるので、主要環境ごとの最適解を一覧にまとめます。

迷ったときの第一選択は、上の表で自分の環境に最も近い行を選ぶこと。それでも決めきれない場合は、CPU版を最初に動かして「llama.cpp自体は動く」ことを確認してから、GPUバックエンドに進むのが安全です。

複数GPU・特殊環境ユーザー向けの追加考慮

複数GPUを混載している場合、選び方が少し複雑になる。CUDAバージョンを揃える、Vulkan版でベンダー横断する、ROCm＋CUDAを両立させる（Linuxのみ）などの選択肢がある。基本的には、上位GPU側に合わせてビルドを選び、下位GPU側がそのランタイムでも認識される構成にしておくのが無難。

eGPUや外付けGPUドック（Oculink接続等）を使っている場合は、ホストPC側のCPU・チップセットがバックエンド側で問題なく扱えるかも確認しておくと安心。古いノートPCにeGPUを足す構成では、PCIe帯域がボトルネックになりやすく、ビルドの選択以前にハードウェア側の制約が効いてくることが多い。

よくある質問

Q. CUDA 12 と CUDA 13 のビルドはどちらをダウンロードすればいい？

RTX 40系以前のGPUと既存のCUDA 12環境を使い続けるならCUDA 12.4 DLLs版が安定です。RTX 50系の新規購入や最新ドライバを入れている場合はCUDA 13.1 DLLs版のほうが将来的な恩恵を受けやすい。両方のビルドが並行配布されているのは、ドライバ互換性の橋渡しとして意図的に残されているためで、慌てて新CUDA側に揃える必要はありません。

Q. Apple Silicon Mac で KleidiAI 版と通常版どちらが速い？

KleidiAI（ArmのCPU向け行列演算ライブラリ）対応版は、ARM CPUのSIMD命令を使った行列演算最適化が組み込まれている。M系チップでCPU推論を回す場合は、KleidiAI版のほうが理論上有利。ただし、本記事執筆時点で公式リリースから明確な速度比較値は提示されていないため、断定は避けます。手元のモデルとモデルサイズで両方試して計測するのが確実な判断方法です。

Q. AMD GPU を使いたいが ROCm と HIP と Vulkan のどれを選ぶ？

Linuxで安定運用したいならROCm 7.2版が第一選択。Windowsでの選択肢が必要ならHIP版を試す流れになります。それでも動かない、もしくは古い世代のRadeonでROCm非対応の場合は、Vulkan版が保険として機能する。AMD GPUは世代によってROCm対応の可否が分かれるため、自分のGPU型番がROCm 7.2の対応リストに入っているかをまず確認するのが先決です。

Q. arm64 Windows ノートPCで llama.cpp は動く？

Windows arm64 (CPU) ビルドが公式に提供されているので、Snapdragon X系のWindowsノートPCでもCPU推論は動作する見込み。GPU/NPUバックエンドのarm64 Windows対応は本記事執筆時点では公式ビルドに含まれておらず、CPU推論が中心になります。軽量な3B〜7Bクラスのモデルを動かす範囲なら実用的、それ以上は速度面で厳しくなる、という現実的な棲み分けを想定しておくのが安全です。

Q. リリースタグはどのくらいの頻度で更新されている？

本記事で参照しているリリースを並べると、b8691（4月7日）→ b8823（4月17日）→ b8827（4月17日）→ b8846（4月19日）と、約2週間で4タグが切られている。1日に複数タグが出る日もあり、開発スピードはかなり速い。最新タグを追いかけるよりも、自分の環境で検証済みのタグを固定して使い、必要に応じてアップデートする運用が現実的です。

まとめ

llama.cppの公式リリースが20種類以上のビルドを並列配布している事実は、ローカルLLMが特定OS・特定GPUに縛られない時代に入っていることを示している。macOS/iOSのApple Silicon＋KleidiAI、LinuxのCPU3アーキ＋Vulkan/ROCm/OpenVINO、WindowsのCUDA 12/13＋Vulkan/SYCL/HIP、openEulerのAscend NPU対応まで、ハードウェアの多様化を真正面から受け止める設計。

「自分の環境に合ったビルドを選ぶ」というシンプルな前提を整えるだけで、推論速度や安定性は大きく変わってくる。逆に言えば、ここを間違えるとどれだけ高性能なGPUを持っていても本来の性能が出ない。本記事のH2-11で示した選択フローを基準に、まず1本ビルドを決めてから動作確認に進むのが現実的な進め方です。

リリース更新が短サイクルである点も忘れてはならない要素。b8691からb8846までが2週間、その間にOpenCL/Adreno最適化やmeta backend効率化が入り続けている。固定運用したい場合は特定タグ採用、最新動向を追いたい場合は検証環境で先に確認、という二段構えの運用が安全。

llama.cppのビルド選びは、ローカルLLMという広いテーマの入口に過ぎない。モデル選定・量子化フォーマット・推論パラメータ・周辺ハードウェアまで、踏み込むほど学ぶことが増える分野。本記事を起点に、それぞれの深掘りに進んでいく流れを作っていきましょう。

当サイトはAmazonアソシエイト・プログラムの参加者です。Amazonのアソシエイトとして、当サイトは適格販売により収入を得ています。

おすすめパーツ 価格まとめ

本記事は AIハードウェア図鑑 編集部 が記載時点の情報をもとに執筆。製品アップデートや第三者ベンチマーク・価格・対応ランタイム等の変動で評価が変わる可能性がある。一定期間経過した内容は再検証を推奨する。