コンテキスト長
コンテキスト長とは、モデルが一度に「見て」いられるテキストの長さ(単位: トークン)です。会話の履歴も、読み込ませた文書も、生成中の回答も、すべてこの枠の中に収まっている必要があります。そして見落とされがちですが、コンテキストはVRAMを消費します。
「忘れる」の正体
長い会話でモデルが前半の内容を忘れるのは、コンテキスト枠から押し出されたからです。枠の上限はモデルごとに決まっており(例: 128Kトークン対応など)、実行時にはそのうちいくらを確保するかを設定します。Ollamaでは num_ctx がこの設定です。既定値は控えめに絞られがちで(旧版は2048〜4096固定、現行版は空きVRAMに応じて自動決定)、「128K対応モデルなのにすぐ忘れる」の原因はたいていここにあります。
なぜVRAMを食うのか
モデルは読んだトークンの中間表現をKVキャッシュとして保持します。これはコンテキスト長に比例して増えるため、確保する枠が大きいほどVRAMが必要です。実例(当サイトの計算・8Kトークン時):
- Qwen2.5 14B — KVキャッシュ約1.6GB(モデル本体8.9GBに追加で)
- Llama 3.3 70B — 約2.7GB
これを32Kに広げれば単純に約4倍です。「モデルは載るのに長文を入れると落ちる」の原因はこれです。
当サイトの判定との関係
当サイトの必要VRAMは8Kトークン確保を基準に計算しています。△判定に付く「コンテキストを約2Kトークンまで絞れば動きます」という注記は、KVキャッシュを1/4に減らせば収まる、という意味です — 短い質問応答なら実用になります。逆に長文読解・長い対話が主目的なら、判定が◎のモデルでも一段小さいモデルを選んで余白を作るのが賢い構成です。
実用の指針
- まず既定設定で使い、「忘れる」と感じたら
num_ctxを増やす(VRAM余裕と相談) - 長文用途でVRAMが苦しい → 量子化を一段下げて空きをKVに回す手もあります
- 最近のモデルはKVを圧縮する設計(MLA・ハイブリッド注意)を持つものがあり、同じ32Kでも消費が桁で違います — 詳細はKVキャッシュへ
関連用語
- KVキャッシュ — 会話の文脈を保持する作業メモリ。GQA・MLA・ハイブリッド注意でサイズが数十倍変わる
- VRAM(ビデオメモリ) — GPUに載っている専用メモリ。ローカルLLMで動くモデルの大きさを決める最重要スペック
- トークンとトークナイザー — LLMが文章を数える単位。日本語は英語よりトークン効率が悪く、体感速度にも効く
参考資料(出典)
▶ あなたのPCで動くモデルを自動判定する(スペック送信なし・ブラウザ内完結)
上記はアフィリエイトリンクです。経由して課金された場合、当サイトに紹介料が入ります。