手元のPCでLLM（Large Language Model、大規模言語モデル）を動かすときによく使われる llama.cpp が、11月13日に v1.0.0 になりました。これまでは b12359 のような通し番号のビルドを出すだけでしたが、今後はライブラリの C API に互換性のない変更を入れるとき、メジャー番号を上げます。速さも変わりました。RTX 3090 での検証では、1件ずつ生成する速さは前と同じです。推測デコードを使ったときは最大55%、4件を同時に処理したときは合計で22%速くなっています。ただ、消えたオプションやサーバーの認証の決まりなど、そのまま上げると起動しなくなる変更もあります。
背景と文脈
llama.cpp は、Georgi Gerganov さんが2023年に始めた C/C++ のプログラムです。大きな GPU がない PC でも LLM を動かせるようにしたもので、モデルは GGUF（llama.cpp で使うモデルファイルの形式）で読みこみます。Ollama や LM Studio のように、裏で llama.cpp を動かしているアプリも少なくありません。
これまでの llama.cpp には、決まったバージョン番号がありませんでした。変更が入るたびに b7864、b12199 といった番号のビルドが出て、使う側はその番号を追いかけていました。ggml-org のチームが Hugging Face のブログに出したllama.cpp v1.0.0 のお知らせによると、公開から約3年半たち、ライブラリの関数を直接呼ぶアプリが増えたため、API を安定させることにしたそうです。
新しい番号の付け方は semver（セマンティック バージョニング。互換性を壊すとき、機能を足すとき、不具合を直すときで、上げる桁を変える決まり）です。お知らせに載っている決まりは次のとおりです。
| 上げる桁 | 上げるとき |
|---|---|
| メジャー（1.x.x の 1） | include フォルダの C API に互換性のない変更を入れたとき |
| マイナー | 互換性を保ったままの機能追加、モデルの対応、GPU などの対応の更新 |
| パッチ | API が変わらない不具合の修正 |
この決まりで守られるのは、ライブラリの C API だけです。コマンドのオプションやサーバーの HTTP API も同じように守るとは、お知らせには書かれていません。実際、v1.0.0 でも --defrag-thold というオプションがなくなりました。通し番号もなくならず、v1.0.0 はビルド b12359 にあたります。
技術/ビジネス面
速くなったのは、NVIDIA の GPU 向けの新しい計算の仕組みが入ったからです。推測デコード（speculative decoding。先に何トークンか下書きを作り、本体のモデルでまとめて確かめて、合っていた分を一度に採用する方法）では、本体のモデルが2〜24トークンをまとめて計算する場面が多くなります。これまでの計算方法は、この中途半端な数に向いていませんでした。PR #31533「CUDA: few-row MMQ for BS 2-24」で入った方法は、重みを1回だけ読み、確かめるトークン全部に使い回します。
PR によると、対象は Ampere 世代（RTX 30 シリーズ）以降の NVIDIA の GPU です。量子化（モデルの数値を4ビットなどに丸めて小さくすること）の形式も、Q4_K や Q8_0 など8種類に限られます。PR の作者が Qwen3.8-27B と推測デコードで、プログラミングの会話80件を使って測った結果がこちらです。
| GPU | 前（トークン/秒） | PR 後 | 差 |
|---|---|---|---|
| RTX 3090 Ti | 57.58 | 77.70 | +34.9% |
| RTX 5090 | 141.50 | 170.67 | +20.6% |
| RTX PRO 6000 Max-Q | 122.77 | 143.31 | +16.7% |
| DGX Spark | 32.75 | 36.05 | +10.1% |
古い世代の GPU ほど伸びています。80件すべての会話で前より速く、出てくる文章の正確さの指標もほとんど変わっていません。
速さ以外の変更もあります。KV キャッシュ（それまでの会話の計算結果を覚えておくメモリ）を FP8 という8ビットの形で持てるようになりました。MoE（入力ごとに一部の専門家の層だけを動かすモデル）の専門家の層をメインメモリに置いておくキャッシュや、読み上げ用の /v1/audio/speech も入っています。
開発者として試すなら
homebrewserver.club のllama.cpp v1.0 の検証記事が、RTX 3090（24GB）の Linux の PC で、上げる前のビルド12199と v1.0.0 を Docker で比べています。モデルは Qwen3.5 の 9B と 27B（Q4_K_M）で、5回測った真ん中の値です。
| 条件 | 前（トークン/秒） | v1.0 | 差 |
|---|---|---|---|
| 27B、1件ずつ | 39.2 | 38.7 | -1.3% |
| 27B、4件同時（合計） | 95.6 | 116.4 | +22% |
| 9B、4件同時（合計） | 277.7 | 316.8 | +14% |
| 27B、MTP あり、短い質問 | 45.1 | 68.5 | +52% |
| 27B、MTP あり、長い質問 | 46.5 | 71.9 | +55% |
| 9B、MTP あり、短い質問 | 96.5 | 122.3 | +27% |
| 9B、CPU だけ | 6.7 | 6.7 | 同じ |
1件ずつふつうに使うだけなら、上げても速さは変わりません。速くなるのは、何人かが同時につなぐサーバーとして使うときと、推測デコードを使うときです。9B の MTP は、前のビルドでは推測デコードなし（121.8）より遅くなっていました。v1.0 で 122.3 になり、やっと並んだところです。小さいモデルでは、推測デコードを入れてもあまり得をしません。
MTP（Multi-Token Prediction。モデル自身が持っている、次の数トークンを予想する部品）を使う推測デコードは、MTP の部品が入った GGUF を用意して、次のように起動します。検証記事で使われたコマンドです。
llama-server -m Qwen3.5-27B-MTP-Q4_K_M.gguf -c 32768 -np 1 \
--spec-type draft-mtp --spec-draft-n-max 6検証記事によると、Docker なら ghcr.io/ggml-org/llama.cpp:server-cuda-v1.0.0-b12359-b1b770d のように版を固定したイメージもあります。llama-server --version で、今のビルド番号を確かめられます。
上げる前に、起動の設定を見直しておくと止まらずに済みます。起動スクリプトに --defrag-thold が残っていたら消してください。llama-server を 127.0.0.1 以外で待ち受けさせて、ツールや MCP（Model Context Protocol。AI に外部の道具をつなぐための決まり）を有効にしている場合は、--api-key で鍵を設定します。llama-server の説明書では、鍵なしで動かすための --allow-unauthenticated-tools は、信頼できるネットワークの中だけで使うものとされています。
画像の URL が社内のアドレスを指している場合も、初期設定では読みこまなくなりました。社内の画像サーバーを使うなら --media-allow-private-urls を付けます。Hugging Face の鍵（HF_TOKEN）は、huggingface.co 以外には送らなくなっています。
Ollama から使っている人は、すぐには速くなりません。検証記事によると、Ollama 0.40.16 に入っている llama.cpp はビルド12177で、v1.0 の変更はまだ含まれていません。
これからどうなるか
llama.cpp をライブラリとして組みこんだアプリを作る人は、メジャー番号を見るだけで、作り直しが要るかどうかがわかるようになります。これまでは、どのビルドで関数が変わったかを自分で追う必要がありました。v1.0.0 でも35個の古い関数が消え、構造体にも項目が増えています。C API を直接呼んでいる場合は、今回だけは手直しが要ります。
サーバーとして使う人には、少し事情が違います。HTTP API やオプションが semver で守られるのかどうかは、まだはっきりしていません。CI や Docker では、v1.0.0 という番号だけでなくビルド番号まで固定しておくと、急にオプションが消えて止まる事故を防げます。
社内で1台の GPU に何人かがつなぐ使い方なら、v1.0 に上げるだけで処理できる量が2割ほど増えそうです。ただしこれは RTX 3090 と 27B で測った1つの結果です。自分の GPU とモデルで、上げる前と後を同じ条件で測ってから決めてください。PR の作者は、次に MoE モデル向けの計算にも同じ仕組みを広げる予定を挙げています。
まとめ
llama.cpp v1.0.0 から、C API の互換性はメジャー番号で守られるようになりました。速さは、RTX 30 シリーズ以降の GPU で推測デコードや同時処理を使うときに上がり、1件ずつ使うだけなら変わりません。上げる前に --defrag-thold の削除と、外に公開したサーバーでのツール・MCP の鍵の設定を確かめてください。Ollama の利用者は、Ollama 側の更新を待つことになります。
参考リンク
- llama.cpp v1.0.0 リリースノート（GitHub）
- llama.cpp v1.0.0: A stronger foundation for the local AI ecosystem（Hugging Face）
- CUDA: few-row MMQ for BS 2-24（PR #31533）
- llama-server README（GitHub）
- llama.cpp v1.0 on an RTX 3090（homebrewserver.club）
アイキャッチ画像: Photo by Tonia Kraakman on Unsplash
