Windowsでllama.cppを使う方法｜GGUF・CPU・GPU backend・serverの選び方

llama.cppはモデル形式ではなく推論runtime

llama.cppはC/C++のローカル推論実装です。GGUFはモデルを保存・配布する形式、llama.cppはその形式などを読み込んで推論するruntimeです。拡張子がGGUFなら、すべてのモデルとbackendで動くという意味ではありません。

• GGUFとは - GGUF、quantization、model metadataの基本を見る
• GGUF・safetensors・Ollamaの違い - 形式、framework、runtime、管理層を分ける
• LM StudioでGGUFを読み込めない時 - 同じモデル形式でもruntime対応が異なる時の診断へ進む

Windowsで始める導入経路を選ぶ

公式READMEはllama.app、Docker、GitHub releaseのprebuilt binaryを導入経路として案内しています。初心者は現在のWindows用binaryを選び、ソースbuildは必要なbackendや変更が決まってから検討します。GPU対応版、CPU版、releaseごとに含まれるtoolは異なることがあるため、asset名だけで決めずREADMEと配布物の説明を合わせて確認します。

1. 公式repositoryから現在のWindows向け開始手順またはrelease一覧へ進む。
2. Windows x64/Arm64、CPUかGPUか、必要なbackendを照合して配布物を選ぶ。
3. model fileを別に用意するか、公式quick startのHugging Face download例を使うか決める。
4. まず短いpromptを一回実行し、version、model名、backendログ、出力を記録する。
5. 動作を確認した後にserver/APIや追加のGPU offloadを設定する。

llama cli -hf ggml-org/Qwen3.5-0.8B-GGUF
llama serve -hf ggml-org/Qwen3.5-0.8B-GGUF

上は2026-09-28に公式READMEが掲載しているHugging Face quick startの形です。model名、command、Windows packageの構成は変わるため、実際に取得したreleaseに付属するREADMEと現行の公式CLI仕様を使ってください。Hugging Faceから初回取得する場合は、そのdownload通信もローカル推論とは別の通信として扱います。

• llama.cpp公式repository - Windows用quick start、現在のCLI/server、releaseへ進む
• llama.cpp build guide - WindowsのCPUとbackend別build条件を確認する

CPUで基準を作ってからbackendを選ぶ

CPUだけで同じGGUFと短いpromptを試すと、ファイル、runtime、chat template、基本的なメモリ条件を先に確認できます。GPU版を選んだだけでGPUが使われるとは限らないため、起動ログのbackend/device表示とGPU利用状況を確認し、短い同一promptでCPU結果と比べます。

この表は全GPUの対応保証ではありません。たとえばllama.cppのSYCL資料はWindows 11とIntel GPU familyの条件を示します。AMDにはRadeon/Ryzen向けのWindows binary資料と、ROCm 7.14.0のllama.cpp導入資料があり、配布元・runtime・versionを混ぜずに対応条件を照合します。Vulkanもdriverと個別のoperator対応に左右されます。model、backend、buildが組み合わさった時の実行可否を確認してください。

• llama.cpp SYCL backend - Intel Arc/iGPUのWindows条件とdevice一覧を確認する
• AMD Radeon/Ryzen Windows LLM資料 - WindowsのAMD GPU対応範囲とuse caseを見る
• AMD検証済みllama.cpp binary - 対象GPU、driver、binaryの条件を確認する
• Intel OpenVINO backend資料 - Intel CPU/GPU/NPUのOpenVINO build条件を見る

AMD GPUでROCm 7.14を使う時の導入とGPU確認

AMD ROCm AI Ecosystemのllama.cpp資料はWindows 11向けにROCm 7.14.0の手順を掲載しています。ROCm compatibility matrixでGPU名だけでなくgfx architecture、Windows build、driverを先に照合し、AMD GPU driverとROCm runtimeを別の要件としてそろえます。

1. AMDのcompatibility matrixで対象のRadeonまたはRyzen APU、gfx architecture、Windows、driverを選んで対応条件を確認する。
2. ROCm 7.14.0 install guideでWindows、Compute、対象deviceのgfxを選び、pipまたはtarballの手順をその環境に合わせて進める。ROCm runtimeとAMD GPU driverは別に必要。
3. llama.cppの公式releasesから`win-rocm-7.14-x64`を含むWindows assetを選び、build番号とSHA256を確認する。assetにはllama.cpp実行ファイルとbackend libraryが入り、ROCm runtimeは別途必要。
4. pip環境ではROCmの`_rocm_sdk_core\bin`と`_rocm_sdk_libraries\bin`を起動shellのPATHへ加える。AMD資料に従い、同じruntime版の`amdhip64_7.dll`、`rocm_kpack.dll`、`amd_comgr.dll`をllama.cpp実行ファイルの隣にも配置する。
5. `llama-cli.exe --list-devices`で認識deviceを見てから、同じGGUFで`llama-bench.exe`を実行し、backend表示がROCmか確かめる。device名の表示だけでは実際の計算利用まで証明しない。

$rocmVenv = 'C:\rocm\venv' # 実際のROCm仮想環境に置き換える
$rocmCoreBin = Join-Path $rocmVenv 'Lib\site-packages\_rocm_sdk_core\bin'
$rocmLibrariesBin = Join-Path $rocmVenv 'Lib\site-packages\_rocm_sdk_libraries\bin'
$env:PATH = "$rocmCoreBin;$rocmLibrariesBin;$env:PATH"
Set-Location C:\llamacpp
.\llama-cli.exe --list-devices
.\llama-bench.exe -m C:\models\small.gguf -p 128 -n 128 -ngl 999

この例はpipでROCm runtimeを入れた場合のPowerShell内だけに適用するPATH設定です。実際のvenv、llama.cpp、GGUFの場所へ置き換えてください。公式資料ではruntime libraryがPATHにない場合、エラーを出さずCPU backendへfallbackする場合があります。`amdhip64_7.dll`はWindowsのSystem32にもあるため、ROCm側の3 DLLを実行ファイルの隣へそろえる手順も省かないでください。device検出と、benchmarkやmodel実行時のbackend・負荷は別々に確認します。

• AMD ROCm AI Ecosystem: llama.cpp - ROCm 7.14.0のWindows用binary、DLL、device確認手順を見る
• ROCm 7.14.0 compatibility matrix - Radeon/Ryzen APU、gfx architecture、Windows、driverの条件を選ぶ
• ROCm 7.14.0 install guide - Windowsでpipとtarballを選ぶ
• llama.cpp公式releases - 対象ROCm versionのWindows assetとSHA256を確認する

GGUF、モデル対応、architecture mismatchを切り分ける

GGUFはファイル形式とmetadataの仕様です。推論runtimeが、そのmetadataの`general.architecture`や必要tensor/operatorを実装しているかは別の確認です。モデル名にGGUFと書かれていても、古いbuildや別backendで未対応のarchitectureならloadに失敗することがあります。

1. エラー全文、llama.cpp version/commit、Windows binary名、backend/deviceを記録する。
2. Hugging Face Model CardとFilesでbase model、repo revision、GGUF file、必要なmmprojなどの補助fileを照合する。
3. llama.cppのsupported models一覧でarchitectureを確認し、対象releaseで対応しているか読む。
4. 同じruntimeで既知の小さなモデルを試し、runtime全体の問題と個別モデルの問題を分ける。
5. 新しいarchitectureを使う時は、対応する公式release/buildを確認してから比較し、再現条件を保存する。

SHA256やファイルサイズが配布元と一致することは、途中破損の確認には役立ちますが、runtimeのarchitecture対応までは証明しません。画像入力モデルで別配布される`mmproj`はvision projectorの補助fileで、単独の通常LLM本体として扱いません。ComfyUIなど画像生成向けGGUFも、llama.cpp用LLMのGGUFと用途・内部構造が同一とは限りません。

• llama.cpp supported models - architectureごとの対応と注意点を確認する
• LM StudioでGGUFが読み込めない時 - LM Studio内での保存場所・runtime・形式の切り分けを見る
• LM Studioで画像を読み込む - vision modelとmmprojの組を確認する

CLIとserverを用途で分ける

CLIは短いprompt、model/backend比較、batch処理の確認に向いています。`llama.cpp`公式quick startの`llama serve`はOpenAI互換API serverの入口です。serverを使う場合は、port、bind先、API key、呼び出すclient、終了方法を確認し、LANやインターネットへ公開する予定がなければ公開範囲を広げません。

API serverが起動したことだけで、認証やネットワーク範囲が適切だとは限りません。モデル取得、serverへのHTTP request、app側の保存・履歴は別々のデータ経路として確認します。

• ローカルAIをAPIで使う方法 - LM Studio/OllamaなどのAPIとclient設定を比較する
• ローカルAIのLAN serverをWindowsで使う - localhostとLAN公開を分ける確認へ進む
• ローカルAIの安全性とプライバシー - 外部公開、認証、ログ、モデル取得の境界を見る

同じ条件で速度・memory・生成内容を比較する

backendが使えても、毎回の速度や生成品質はmodel、quant、context、GPU offload、driver、binary、promptで変わります。数字を比べる時は同じモデルと同じ短文で条件を固定し、初回model load、prompt processing、generation、peak RAM/VRAMを分けて記録します。

• llama.cppのversion/commitと取得したrelease名を保存する。
• model repo/revision、GGUF filename/quant、補助modelを記録する。
• backend/device、GPU layers、context、sampling、promptと出力上限をそろえる。
• 初回downloadとload、prompt処理、生成速度、最大memoryを別々に記録する。
• 起動できるか、速度が実用的か、出力が用途に合うかを別の判定にする。

• ローカルAIの速度・RAM・VRAMを測る方法 - TTFT、tokens/s、peak memoryの測り方を見る
• ローカルAI用PCスペックの見方 - VRAMと共有memoryを含めてPC側の条件を見る
• GPUオフロードとは - CPU/GPU間でmodel layersを割り当てる考え方を見る