ローカルLLMのContextは64K・128K・256Kでどう変わる？【待ち時間と探索範囲の実践記録】

はじめに
1．先に結論
2．Contextの基本と今回の使用環境
3．64K・128Kで記録した待ち時間
4．256Kと広域探索で長くなった作業
5．圧縮失敗から考えた作業の区切り方
6．私の使い分け
おわりに

はじめに

こんにちは、kanatoです。

前回は、Qwen Code DesktopをOllamaにつなぎ、ローカルLLMをブログ制作の作業環境で使えるところまで進めました。接続できた後に気になったのが、Contextをどれくらいにして使うかです。長い資料を読ませたいとき、容量は大きいほど便利そうですよね。

さて、今回は2026年9月7〜8日に、私のPCで64K・128K・256Kを試したときの待ち時間と、ファイルを広く探させたときの様子をご紹介したいと思います。私の使い分けは64Kを標準、128Kを長文用とし、広い探索は依頼の範囲を絞るという形になりました。

前回：Qwen Code DesktopをOllamaのローカルLLMに接続【64K／128Kモデルの設定記録】

ノート

資料をたくさん読めると便利そうだよね。でも、待ち時間まで長くなったら困るかも・・・。普段使いのちょうどいいところを考えてみよう！

1．先に結論

今回の環境では、次の使い分けにしました。

普段の確認や文章作業は、64K・Thinking ONを標準にする。
多くの資料や長い文章を一緒に参照したいときは、128Kを候補にする。
256Kを普段の設定にはせず、広いファイル探索は対象を絞って頼む。

9月7日の2ファイルに限定したルール確認では、64Kで43秒、128Kで3分49秒でした。128Kではモデルの一部がCPU側のメモリへ配置されていました。

ただ、翌日に64KでSkills全体を調べてもらったときには、約1時間57分かかりました。小さめのContextにしても、調べる範囲が広ければ待ち時間は長くなります。私にとっては、Contextの設定と一緒に、何をどこまで探してもらうかを決めることが大事でした。

2．Contextの基本と今回の使用環境

Contextは、モデルが参照できる文脈の容量で、トークン数で表されます。日本語の文字数とは別の単位です。ここでは64Kを65,536、128Kを131,072の設定として使いました。

会話の中では、依頼文だけでなく、読み込んだ資料やツールの結果も扱います。容量が大きいほど長い文脈を扱いやすくなりますが、必要なメモリも増えます。この点はOllamaのContext lengthの説明でも案内されています。

今回使った環境は次の通りです。

項目	2026年9月7〜8日の環境
OS	Windows
GPU	RTX 5060 Ti 16GB ×2
推論サーバー	Ollama
作業アプリ	Qwen Code Desktop
モデル	9月7日の測定は`qwen3.8:27b`。9月8日の作業は64K用に登録したモデル
推論設定	Thinking ON
主な作業	ブログ制作のルール確認、ファイル探索、Skillsの棚卸し

9月7日の測定では、モデル名はqwen3.8:27bのままで、OllamaとQwen Code DesktopのContext設定を切り替えて試しました。ollama psのCONTEXT欄には、64Kで65536、128Kで131072と表示されています。64K用・128K用の別名モデルは、この測定のあとに作ったもので、作り方は前回の記事にまとめました。9月8日の1時間57分と圧縮エラーは、この64K用のモデル（表示名「Qwen3.8 27B – 64K – Thinking」）での作業です。GPUを2枚使う環境での結果なので、GPUやメモリ構成が違うPCでは結果も変わります。

もう一つ、Qwen Code側のcontextWindowSize（Desktopの設定画面では「コンテキストウィンドウ」）と、モデルへ実際に送れる1回分の入力上限も分けて考える必要があります。Qwen Code公式の設定説明では、この項目はモデルの想定最大容量を定義し、1リクエストのトークン上限そのものではないとされています。

3．64K・128Kで記録した待ち時間

9月7日は、64Kと128Kで同じ系統の2ファイルに限定したルール確認を行いました。ThinkingはどちらもONです。

Context設定	作業全体の経過時間	`ollama ps`のPROCESSOR表示	`ollama ps`のSIZE表示
64K（65,536）	43秒	100% GPU	20 GB
128K（131,072）	3分49秒	13%/87% CPU/GPU	24 GB

この数字は、Qwen Code Desktopの「処理済み」表示を基準にした経過時間です。出力速度の測定値や、繰り返し試した平均値ではありません。2回の依頼文が完全一致した記録はないため、速度倍率は算出していません。

100% GPUは、GPUがずっと100%の稼働率だったという意味ではありません。OllamaのFAQでは、PROCESSOR欄はモデルがどのメモリに配置されているかを表すと説明されています。128Kで表示されたCPUとGPUの割合（13%/87%）も、処理時間の内訳ではなく配置の情報です。SIZE欄は64Kで20GB、128Kで24GBと表示され、同じモデルでもContextを大きくすると必要なメモリが増えていました。

ギア

データによると、128KではCPU側とGPU側への配置が混在していたのであります！ Contextを変えて試すときは、待ち時間だけでなくPROCESSOR欄も一緒に残すと、違いを追いやすくなるのであります。

今回、128Kの方が長く待ったことと、CPU側への配置があったことは確認しています。ただ、その時間差のすべてがCPU側への配置によるものだと決めるには、入力や会話履歴、モデルの読み込み時間などもそろえて測る必要があります。普段は64Kを使い、長い文脈が必要なときに128Kへ切り替えることにしました。

4．256Kと広域探索で長くなった作業

256Kでは、ブログ制作用のルールを置いたフォルダ全体と共通ルールのファイルを読んで、守るべきルールを根拠のファイル付きで整理してもらいました。Ollama側のContext lengthを256Kにした状態で、この作業の処理済み表示は約1時間30分でした。作業が終わった後のQwen Code Desktopの画面には、26%使用済み、52k使用済み、合計200kと表示されていました。

Ollama側の設定が256Kでも、Qwen Code側の表示は合計200kで、使われていたのはそのうちの約52kです。256Kの全部を入力していたわけではありません。また、このときは参照範囲がフォルダ全体で、前節の指定2ファイルの確認とは違いました。43秒や3分49秒と並べて、Contextだけによる速度差として読むと条件を取り違えてしまいます。

広く探す作業の記録を分けると、こうなります。

日付	設定と依頼内容	経過時間
9月7日	Ollama側を256Kにして、ブログ制作ルールのフォルダ全体を探索・整理	約1時間30分
9月8日	64K ThinkingでSkills全体を棚卸し・分類	約1時間57分

64Kでも長時間になったことから、Contextを小さくすればどんな作業もすぐ終わる、というわけではありませんでした。確認するファイルが増えれば、読むだけでなく、次に何を調べるかを考えたり、結果を整理したりする作業も増えます。

この経験から、次に頼むときは対象と出力を先に決めたいと思いました。例えば「ブログ制作のルールを全部調べて」より、次のように依頼する形です。

記事の下書きを作るために、指定した2ファイルの本文構成と文体のルールを確認してください。結果は10項目以内にまとめ、追加で読む必要があれば、先に候補と理由を示してください。

これは依頼文の例で、同じ条件で何秒短くなるかを測ったものではありません。ただ、何を調べたら終わりなのかを共有しておけば、際限なく探索が広がることを避けやすくなります。

5．圧縮失敗から考えた作業の区切り方

9月8日の長い探索の後、同じセッションで追加調査を続けると、次のエラーが表示されて止まりました。

Internal error: Context is too large to send safely after automatic compression. Estimated prompt tokens: 44075; hard limit: 42536; compression status: COMPRESSION_FAILED_INFLATED_TOKEN_COUNT. Start a new session or reduce the resumed history before continuing.

画面の表示は英語で、自動圧縮のあとでも文脈が大きすぎて安全に送れない、という内容でした。推定入力が44,075トークン、表示された上限が42,536で、圧縮に失敗しています。メッセージの最後には、新しいセッションを始めるか、再開した履歴を減らしてから続けるようにという案内もありました。64Kを選んでいても、会話をそのまま延ばし続けられるとは限らなかった、という経験です。この42,536という値は、そのときのエラーに表示されたもので、すべての64K設定に共通する上限として読む値ではありません。

案内のとおり新しいセッションから始め直すなら、それまでに調べた内容を先にファイルへ保存しておくと続けやすくなります。自動圧縮だけに任せるより、途中で結果を保存して区切る方が扱いやすそうです。調査結果、結論の根拠、次に読むファイルをまとめておけば、新しい会話でも続きを始めやすくなります。

例えば、ルールの確認が終わったところで、その結果をファイルに保存します。次の会話では保存先と必要な原資料を指定して、記事の構成を考えてもらう。構成が決まったら、さらに下書きへ進むという分け方です。要約だけで細かい条件が消えないよう、元の出典も一緒に残しておきたいところです。

6．私の使い分け

ここまで試して、普段は64K Thinking、長い資料をまとめて扱う場面は128Kという使い分けにしました。256Kは必要な理由があるときに候補とし、まずは作業の範囲を整理します。

やりたいこと	私の入口
指定ファイルの確認、文章や構成の検討	64Kで始める
長い資料や複数資料を一緒に参照	128Kを候補にし、メモリ配置も確認する
多くのフォルダから必要資料を探す	先に候補を一覧にし、読む範囲を分ける
調査から執筆まで会話が長くなる	成果と出典を保存して、工程の区切りで引き継ぐ

自分の環境で比べるときは、モデル名と量子化、アプリの版、Context設定、Thinkingの有無、依頼文、対象ファイル、経過時間、ollama psの表示を一緒に残すと振り返りやすいと思います。同じ依頼を同じ資料で試し、できあがった内容も確かめると、速さと使いやすさの両方を見られます。