はじめに
前回の結論は、「128K は動くが、読み込みに 21〜24 分かかる」でした。
ただ、これは初回の話です。同じ文書に何度も質問するなら、 2 回目以降は読み込み済みの状態を使い回せるはずです。 llama-server にはそのための仕組みがいくつもあります。
| オプション | 既定 | 役割 |
|---|---|---|
--cache-prompt | 有効 | 前回と先頭が一致する部分を再計算しない |
--ctx-checkpoints | 32 | 途中の状態を保存しておく数 |
--cache-ram | 8192 MiB | 使い終わった状態を RAM に置いておく |
--cache-reuse | 0 | KV をずらして、途中から一致する塊も使い回す |
--slot-save-path | 無効 | 状態をディスクに保存・復元する |
ただし、このモデルには癖があります。前回わかったとおり、 SSM とフルアテンションのハイブリッド構成です。
SSM の状態は、読んだトークンを積み重ねた「今の状態」がひとつあるだけです。 KV キャッシュのように「100 トークン目まで戻す」ことができません。 そのため、普通のモデルと同じようには使い回せないかもしれません。
使い回せるなら、どういう条件で使い回せるのか。 測りました。
測り方
判定は体感ではなく、サーバが返す **timings.prompt_n（実際に処理し直したトークン数）**で行います。
「速くなった気がする」ではなく、「何トークン読み直したか」を見ます。
文書は、このシリーズの作業記録を連結したものです。 まず 32K で 6 通りを試して仕組みを見極め、そのあと 128K で確認しました。
| # | 試したこと |
|---|---|
| E1 | 同じプロンプトをもう一度送る |
| E2 | 同じ文書に、別の質問を送る |
| E3 | 文書の途中（50% の位置）に 1 行差し込んで送る |
| E4 | 別の文書を挟んでから、元の文書に戻る |
| E5 | ディスクに保存し、サーバを再起動してから復元する |
32K の結果
| # | 試したこと | 処理し直し | 取り込み |
|---|---|---|---|
| — | 初回 | 32,155 | 159.4 秒 |
| E1 | 同じプロンプトを再送 | 4 | 0.7 秒 |
| E2 | 同じ文書・別の質問 | 515 | 4.7 秒 |
| E3 | 文書の途中を書き換え | 32,170（全部） | 160.7 秒 |
| E4 | 別の文書を挟んで戻る | 4 | 0.7 秒 |
| E5 | ディスクから復元 | 32,154（全部） | 156.0 秒 |
質問を変えるだけなら 4.7 秒。 初回の 34 分の 1 です。 別の文書を挟んでも、RAM に残っていて 0.7 秒で戻れました。
一方で、途中を 1 行書き換えると全部読み直し、 ディスクから復元しても全部読み直しでした。
なぜこうなるのか: 戻れる場所が 2 か所しかない
詳細ログ（-lv 4）を出すと、理由がそのまま書いてありました。
created context checkpoint 1 of 32 (n_tokens = 31466, size = 124.990 MiB)
created context checkpoint 2 of 32 (n_tokens = 31978, size = 126.002 MiB)チェックポイント（SSM の状態の保存）は、プロンプト末尾の 2 か所にだけ作られます。 末尾の 512 トークン手前と、4 トークン手前です。 8K、16K、24K と読み進める途中では作られていません。
これで 4 つの結果がすべて説明できます。
- 同じプロンプト: 4 手前に戻り、4 トークンだけ処理する
- 別の質問: 512 手前に戻り、文書の末尾 500 トークン弱と質問を処理する
- 途中の書き換え: 書き換えより手前に戻れる場所が無いので、最初から処理する
- ディスクから復元: 次の節で説明します
KV キャッシュだけなら、どの位置にでも戻れます。 戻れないのは SSM の状態のほうで、保存しておいた地点にしか戻れないわけです。
ディスクからの復元は、KV しか戻らない
保存（0.68 GiB、3.6 秒）も復元（0.3 秒）も成功していました。 サーバは復元した内容が完全に一致していることまで認識しています。
selected slot by LCP similarity, f_sim_best = 1.000 (> 0.100 thold), f_keep = 1.000それでも読み直した理由は、サーバ自身が出していました。
forcing full prompt re-processing due to lack of cache data
(likely due to SWA or hybrid/recurrent memory, ...)保存ファイルに入るのは KV だけで、チェックポイントは入りません。 質問を変えなくても、応答の生成に 4 トークン戻る必要があります。 その 4 トークンを戻せないので、最初から読み直すことになります。
念のため、同じ質問をそのまま送る場合も試しました。こちらも全部読み直しでした。
| 処理し直し | |
|---|---|
| 復元 → 同じ質問 | 31,982（全部） |
| 復元 → 別の質問 | 31,981（全部） |
このモデルでは、ディスクへの保存はまったく役に立ちません。
128K で確かめる
仕組みが分かったので、128K では E1・E2・E4 だけを測りました。 途中の書き換えと、ディスクからの復元は、32K と同じ理由で全部読み直しになるのが確定しています。
| # | 試したこと | 処理し直し | 取り込み |
|---|---|---|---|
| — | 初回 | 130,179 | 1,053.5 秒（17.6 分） |
| E1 | 同じプロンプトを再送 | 4 | 1.8 秒 |
| E2 | 同じ文書・別の質問 | 515 | 10.7 秒 |
| E4 | 別の 128K 文書（初回 15.6 分）を挟んで戻る | 4 | 2.1 秒 |
128K でも、質問を変えるだけなら 10.7 秒。初回のおよそ 100 分の 1 です。 32K（4.7 秒）より遅いのは、読み直す 515 トークンが深い位置にあり、 1 トークンごとに 13 万トークン分を参照するからです。
E4 も効きました。128K ぶんの状態（KV 約 2.8 GiB ＋ チェックポイント 2 個）が RAM キャッシュ（上限 8 GiB）に収まり、別の 128K 文書を読ませたあとでも 2.1 秒で戻れました。
初回の読み込み時間が、また動いた
今回の初回は 17.6 分でした。前回測った 2 回（21.5 分、24.2 分）より明らかに速い。 割り込みもスリープも起きていないことは確認しています。 直前まで PC が 10 時間スタンバイしていたので、冷えていたのかもしれません。
3 回測って 17.6〜24.2 分。同じ設定でも 4 割近い幅があります。 前回の記事は「21〜24 分」と書いていたので、追記しておきました。
ついでに見つかった、以前の記事の誤り
サーバの起動ログに、こんな行が出ていました。
srv load_model: cache_reuse is not supported by multimodal, it will be disabledserve.ps1 に入れている --cache-reuse 256 が、最初から無効でした。
このモデルは画像も扱えるマルチモーダル版で、画像用の mmproj を読み込んでいるためです。
では mmproj を外せば使えるのか。外して起動すると、理由が変わって同じく無効になりました。
srv load_model: cache_reuse is not supported by this context, it will be disabled--cache-reuse は KV をずらして、途中から一致する塊を使い回す仕組みです。
ずらせない SSM の状態とは両立しません。このモデルでは構造的に使えないわけです。
困るのは、第2回でこう書いていたことです。
--cache-reuseが効いている証拠cache_n : 425 ← キャッシュから再利用したトークン prompt_n : 21 ← 実際に計算したトークン
再利用は実際に起きていました。ただしそれは、既定で有効な --cache-prompt によるものです。
先頭が一致する部分を再計算しない、という基本の仕組みでした。
現象は本物で、効果を別の設定のものと取り違えていました。 「設定を入れた → 速くなった → その設定のおかげ」と結びつけて、 その設定が本当に有効になっているかを確かめていませんでした。
第2回の記事には訂正を追記しました。serve.ps1 の --cache-reuse は、
別のモデルでは効く可能性があり害も無いので、コメントを直したうえで残しています。
どう使えばいいか
| 使い方 | 2 回目以降 |
|---|---|
| 同じ文書に質問を重ねる | 速い（数秒） |
| 別の文書と行き来する | 速い（RAM に残っている間は） |
| 文書を書き換えて読ませ直す | 全部読み直し |
| サーバを再起動する | 全部読み直し（ディスク保存も効かない） |
まとめると、文書は末尾に足していく、質問は最後に置く、サーバは止めない。 この 3 つを守れば、読み込みの待ち時間は初回だけで済みます。
一方で、llm の設定には気をつける点があります。
CLI の回で、
12 時間使わなければモデルをメモリから降ろす設定（--sleep-idle-seconds 43200）を入れました。
降ろしたあとの挙動は測っていませんが、キャッシュも一緒に消えると考えるのが自然です。
長い文書を扱う日は、この設定を意識しておく必要があります。
まとめ
- 質問を変えるだけなら数秒。 同じ文書への 2 回目以降は、ほぼ待たずに済む
- 途中を書き換えると、全部読み直し。 戻れる場所（チェックポイント）が末尾の 2 か所にしかない
- ディスクへの保存は役に立たない。 KV は戻るが、SSM の状態は戻らない
- 理由はどれもハイブリッド構成。SSM の状態は、保存しておいた地点にしか戻れない
- 第2回の「
--cache-reuseが効いている」は誤り。効いていたのは既定の--cache-promptだった
前回の「21〜24 分」は、初回だけ払えば済む待ち時間でした。 ただし、それは文書を書き換えず、サーバを止めないことが前提です。
関連記事 Related Posts
128K の文書の奥まで、ちゃんと読めているのか 128K の文書の奥まで、ちゃんと読めているのか
ローカルLLMに128Kトークンの文書を読ませ、20か所に仕込んだ事実を拾えるか測りました。深さによる取りこぼしは無く、文書に無いことは「記載なし」と答えました。唯一の誤りは、先頭2文字が同じ別の番号との取り違えで、片方の名前を変えると消えました。 ローカルLLMに128Kトークンの文書を読ませ、20か所に仕込んだ事実を拾えるか測りました。深さによる取りこぼしは無く、文書に無いことは「記載なし」と答えました。唯一の誤りは、先頭2文字が同じ別の番号との取り違えで、片方の名前を変えると消えました。
使っていない画像機能を外したら、メモリは1GiB減り、速度は変わらなかった 使っていない画像機能を外したら、メモリは1GiB減り、速度は変わらなかった
ローカルLLMのサーバが、テキストしか使わないのに画像用のmmprojを毎回読み込んでいました。外すと速くなるかを、前回まとめたチェックリストに沿って測りました。1回目は計測中のずれが大きく速度について何も言えず、裏で別のAIセッションが動いていたと分かったので、止めて測り直しました。メモリは1GiB減り、速度は3%未満の差で変わりませんでした。既定は外すことにしました。 ローカルLLMのサーバが、テキストしか使わないのに画像用のmmprojを毎回読み込んでいました。外すと速くなるかを、前回まとめたチェックリストに沿って測りました。1回目は計測中のずれが大きく速度について何も言えず、裏で別のAIセッションが動いていたと分かったので、止めて測り直しました。メモリは1GiB減り、速度は3%未満の差で変わりませんでした。既定は外すことにしました。
コンテキストを 128K まで伸ばしたら、壁はメモリではなく待ち時間だった コンテキストを 128K まで伸ばしたら、壁はメモリではなく待ち時間だった
ローカルLLMのコンテキストを32Kから128Kまで伸ばして測りました。予想していたメモリ不足は起きず、理由はモデルの構造にありました。代わりに見えた壁はプロンプトの取り込み時間で、128Kを読ませるだけで21〜24分かかります。途中で自分の自動起動に計測を汚された話も含みます。 ローカルLLMのコンテキストを32Kから128Kまで伸ばして測りました。予想していたメモリ不足は起きず、理由はモデルの構造にありました。代わりに見えた壁はプロンプトの取り込み時間で、128Kを読ませるだけで21〜24分かかります。途中で自分の自動起動に計測を汚された話も含みます。