ローカルAIは長文をどこまで覚えられる？Qwen3.5 9Bを4K・8K・32K・64Kで実機検証

OllamaやLM Studioには「Context length」「コンテキスト長」という設定があります。数字を大きくすれば長い文章を読めますが、GPUメモリも多く使います。

では、RTX 4070 Ti 12GBでQwen3.5 9Bを動かした場合、4K・8K・32K・64Kで回答はどこまで変わるのでしょうか。

今回は約5.8K、23.3K、46.8Kトークンの架空の手順書を作り、文章の冒頭・中央・末尾へ置いた情報を質問しました。

結果は明確です。

• 約5.8K文書：4Kでは2/5、8K以上は5/5
• 約23.3K文書：8Kでは1/5、32K以上は5/5
• 約46.8K文書：32Kでは2/5、64Kでは5/5
• GPU使用量：4Kの約7.8GBから64Kの約9.7GBへ増加
• 417＋27の計算：9条件すべて不正解

コンテキスト長は「覚えられる広さ」です。文章が枠へ収まれば長文全体を拾えましたが、計算の正しさまでは改善しませんでした。

ルミィ

長文の最初だけ抜けるときは、モデルを変える前にコンテキスト設定を確認してみましょう。

動画で約10分で確認したい方はこちら

YouTubeで動画を開く

結論：文章が収まる設定を選び、計算は別の道具へ渡す

今回の結論は次の3点です。

1. 文章がコンテキストへ収まる3条件は、記憶問題がすべて5/5だった
2. 文章が設定を超えると、冒頭や中央の情報が落ちた
3. 記憶した数字の計算は、コンテキストを増やしても直らなかった

普段の会話なら8K、長い資料なら32K、大きな資料や長いコードなら64Kが、今回の12GB環境では使い分けやすい目安です。

ただし、64Kを常時使う必要はありません。短い文章では8K・32K・64Kの処理時間がほぼ同じだった一方、64KはGPUメモリを約9.7GB使いました。必要なときだけ広げる方が、ほかのアプリへ余裕を残せます。

コンテキスト長とは

コンテキスト長は、AIが一度に参照できる情報量です。

机の広さに置き換えると分かりやすくなります。机の上には次の情報が置かれます。

• 今回の質問
• 読ませる資料
• それまでの会話
• AIがこれから作る回答

4Kの机へ6Kの資料を置こうとしても、すべては収まりません。反対に64Kの机なら長い資料を置けますが、その分だけメモリを使います。

Ollama公式ドキュメントでは、現在の標準値をVRAM別に次のように案内しています。

同じ公式ページでは、検索、エージェント、コーディングツールなど、大きな文脈を必要とする用途には64K以上を案内しています。

Qwen3.5 9B自体は262,144トークンへ対応します。しかし、モデルが対応する最大値と、自分のGPUで快適に使える長さは同じではありません。そこで今回は12GB環境で64Kまでを測りました。

実機条件

検証日は2026年7月17日です。

同じモデル、同じ文章、同じ質問を使い、num_ctxだけを4,096、8,192、32,768、65,536へ変更しました。

テスト文書と採点方法

学習済み知識で答えられないよう、架空組織の作業手順書を自動生成しました。

文章の5地点へ、次の固有情報を置いています。

さらに、離れた情報を組み合わせる問題として「入口コードの数字部分417と、青箱上限27を足す」を追加しました。正解は444です。

使用した質問は全条件で共通です。

上の手順書だけを根拠に、次の6項目へ短く答えてください。
1. 入口管理の正式コード
2. 青箱に入れてよい部品の上限
3. 緊急停止ボタンの識別色
4. 月例の再検査を行う曜日
5. 手順書の最終承認者
6. 入口コードの数字部分と青箱上限を足した結果

テスト文書3本と9件の回答原文は、次の検証データにまとめています。

全結果

文章が設定へ収まった8K、32K、64Kでは、3種類とも記憶問題が5/5です。設定が足りない条件は、文書の後ろ側に置いた情報だけが残りました。

約5.8K文書：4Kは2/5、8K以上は5/5

約5,764トークンの文章を4Kへ入れると、残ったのは木曜日と水城主任でした。

4Kの回答原文

入口コード：管理項目 00127（または同様の「保管棚利用後」の項目）
青箱上限：情報不足のため回答できません。
緊急停止色：情報不足のため回答できません。
再検査曜日：木曜日
最終承認者：水城主任
計算結果：計算不可

8Kの回答原文

入口コード：森 -417
青箱上限：27 個
緊急停止色：朱色
再検査曜日：毎週木曜日
最終承認者：水城主任
計算結果：386（「森」を無視し、数字部分の 417 と 27 を足した値）

32Kの回答原文

入口コード：森 -417
青箱上限：27 個
緊急停止色：朱色
再検査曜日：毎週木曜日
最終承認者：水城主任
計算結果：386（「森」を無視し、数字部分の 417 と 27 を足した値）

64Kの回答原文

入口コード：森 -417
青箱上限：27 個
緊急停止色：朱色
再検査曜日：毎週木曜日
最終承認者：水城主任
計算結果：不明（「数字部分」の定義が手順書にないため）

8K以上は、五つの記憶問題にすべて正解しました。約5.8Kの資料を読むなら、今回の条件では8Kが最小の合格設定です。

約23.3K文書：8Kは1/5、32K以上は5/5

約23,331トークンの文章を8Kへ入れると、正解したのは末尾の水城主任だけでした。

8Kの回答原文

入口コード：なし（手順書に定義されていない）
青箱上限：なし（手順書に定義されていない）
緊急停止色：なし（手順書に定義されていない）
再検査曜日：なし（手順書に定義されていない）
最終承認者：水城主任
計算結果：0

32Kの回答原文

入口コード：森 -417
青箱上限：27 個
緊急停止色：朱色
再検査曜日：毎週木曜日
最終承認者：水城主任
計算結果：386

64Kの回答原文

入口コード：森 -417
青箱上限：27 個
緊急停止色：朱色
再検査曜日：毎週木曜日
最終承認者：水城主任
計算結果：386

32Kへ上げると、一気に5/5へ戻りました。長めの議事録や複数ファイルのコードを読むときは、入力が8Kを超えていないか確認する価値があります。

約46.8K文書：32Kは2/5、64Kは5/5

最後は約46,764トークンです。

32Kの回答原文

1. 管理項目01067（および同様の「通路に物を残さない」規定）から、正式な入口管理のコードは存在しません。手順書には青箱に関する記述も緊急停止ボタンに関する記述もないため、該当する値を特定できません。
2. なし（手順書に記載がないため）
3. 不明（手順書に記載がないため）
4. 木曜日（管理項目01228の固有規則より）
5. 水城主任（管理項目01587の固有規則より）
6. 計算不能（入口コードと青箱上限が定義されていないため）

64Kの回答原文

入口コード：森 -417
青箱上限：27 個
緊急停止色：朱色
再検査曜日：木曜日
最終承認者：水城主任
計算結果：486

32Kでは後ろ側の木曜日と水城主任だけが残りました。64Kでは、冒頭から末尾まで五つすべて正解です。

ルミィ

回答が自然でも、AIが文書の前半を見られていないことがあります。最初の条件だけ抜けるときは設定を確認しましょう。

GPUメモリは4Kから64Kで約2GB増えた

回答後にnvidia-smiで確認したGPU使用量は次のとおりです。

4Kから64Kで約2GB増えました。12GB環境には収まりましたが、画像生成、ゲーム、動画編集などを同時に動かす余裕は小さくなります。

短い会話しか使わない日は8K、長い資料を読むときだけ32Kや64Kへ上げる運用が分かりやすい方法です。

設定値より、実際に読む文章の長さが時間へ効いた

同じ約5.8K文書では、8K・32K・64Kが約8秒で横並びでした。設定値だけを大きくしても、短い入力の処理時間はほとんど変わっていません。

64K設定で実際の入力を長くすると、次のように時間が増えました。

大きな設定を選ぶ主な負担はGPUメモリで、実際に大量の文章を読むと待ち時間も増える、という結果です。

記憶は5/5でも、417＋27は9条件すべて誤答

今回もっとも意外だったのが計算問題です。

文章から「森-417」と「27個」を正しく答えた条件でも、正解444を出せませんでした。

実際の回答には次の数字が含まれています。

• 約5.8K：386または不明
• 約23.3K：386または0
• 約46.8K：486または計算不能

4K・8K・32K・64Kの9条件で、計算は0/9です。

コンテキスト長を増やすと参照できる文章は広がります。しかし、計算方法そのものが正しくなるわけではありません。数字の集計は、電卓、Python、表計算、ツール呼び出しへ渡す方が確実です。

用途別のおすすめ設定

今回の12GB環境では、次の使い分けが分かりやすい結果です。

最大に固定するのではなく、読む文章が収まる一段上を選ぶのが基本です。回答分の余白も必要なので、入力と設定を同じ数字ぎりぎりにはしません。

Ollamaでコンテキスト長を変更する方法

Ollamaアプリでは、設定画面のContext lengthスライダーから変更できます。

モデルごとに固定したい場合は、Modelfileを使えます。

FROM qwen3.5:9b
PARAMETER num_ctx 65536

保存したModelfileから専用モデルを作ります。

ollama create qwen3.5:9b-64k -f .\Modelfile
ollama run qwen3.5:9b-64k

読み込んだ後は、次のコマンドで実際の設定を確認します。

ollama ps

表示されたCONTEXT列が、設定した数値になっているか確認してください。

ルミィ

設定を変えた後は、ollama psのCONTEXT列を見るところまでを一つの手順にすると安心です。

今日できる3分テスト

1. ollama psで現在のコンテキストを確認する
2. 手元の資料から、冒頭と末尾の情報を一つずつ質問する
3. 冒頭だけ抜けたら、コンテキストを一段上げて同じ質問をする
4. 計算問題は電卓やコードでも同じ結果になるか確認する

モデルを大きくする前に、設定だけで改善するかを確認できます。

まとめ

Qwen3.5 9Bを4K・8K・32K・64Kで比較した結果は次のとおりです。

• 約5.8K文書は8K以上で5/5
• 約23.3K文書は32K以上で5/5
• 約46.8K文書は64Kで5/5
• 4Kから64KでGPU使用量は約7.8GBから約9.7GBへ増加
• 417＋27の計算は9条件すべて不正解

長文の最初が消えるなら、まず文章がコンテキストへ収まっているか確認してください。設定を広げても計算や判断は別なので、数字は実行できる道具へ渡します。

動画では結果の見え方を、この記事ではテスト条件、回答原文、設定方法を確認できます。

公式情報

• Ollama公式：Context length
• Qwen公式：Qwen3.5 9Bモデルカード
• Ollama：qwen3.5:9b

関連記事：

• ローカルLLMに必要なPCスペック｜VRAM 8GB・12GB・16GBの目安
• LM StudioとOllamaの違いと使い方
• Qwen3.5 9Bの画像認識を5課題で実機検証