• Skip to main content
  • Skip to primary sidebar

bloggggggggggggggg

// コードと趣味の境界線上

コンテキスト長の壁 — 128kって実際どこまで使えるのよ

モデルのスペック表に「コンテキスト長:128kトークン」って書いてある。文庫本1冊分。理論上は「戦争と平和」を丸ごと入れて要約できるはず…なんだけど、現実はそう甘くない。

僕は色々なモデルでコンテキスト長の限界を検証してみた。結論から言うと、スペックの最大値より半分くらいが実用的な上限。64k超えたあたりから、モデルは明らかに文脈を見失い始める。

長いコンテキストの問題点:

  • Lost in the Middle(真ん中が消える) — 長文の最初と最後は覚えてるけど、真ん中あたりの情報が抜け落ちる現象。論文で実証されてる。これが地味に一番困る。
  • 推論時間の爆発 — コンテキストが2倍になると、計算量は4倍(AttentionはO(n²))。128kトークンだと、返事が返ってくるまで数分待つことになる。
  • VRAMの爆食 — 128kのKVキャッシュだけで数GBのVRAMが必要。モデル本体よりキャッシュの方がメモリ食うことも。

モデル別の実用的コンテキスト長(僕の体感):

モデル スペック 実用限界
Llama 3 8B 8k 6k(それ以上は怪しい)
Mistral 7B 32k 20k
Claude 3.5 Sonnet 200k 100k(驚異的に優秀)
GPT-4o 128k 80k(Claudeにやや劣る)
Gemini 1.5 Pro 1M 100k〜200k(1Mはさすがに無理)

Claude 3.5 Sonnetの長文処理能力は本当に異常。20万文字の技術文書を入れて「3章と7章の内容を比較して」みたいな質問にちゃんと答える。他のモデルは途中で息切れするのに。

ローカルLLMの場合は16kくらいが快適な上限。それ以上は速度低下が許容できなくなる。

← プロンプトテンプレート沼 — ChatML, Alpaca, Llama 3形式の違い
ローカルLLMのベンチマークを取る — 数字で見る性能差 →

Primary Sidebar

最近の投稿

  • インフラエンジニアのキャリアパス — 手動運用からSREへ
  • 障害対応の心得 — 本番で焦らないために
  • 監視設計の基本 — 何をどう見るべきか
  • ログ管理 — ELKスタック入門
  • HTTPSと証明書管理 — Let’s Encryptの恩恵を最大限に

アーカイブ

  • May 2026

カテゴリー

  • AI
  • Linux
  • OS
  • Windows
  • インフラ・DevOps
  • おうちサーバー
  • サーバー・インフラ
  • ツール・環境
  • プログラミング
  • 未分類
  • 開発哲学

最近のコメント

No comments to show.

© 横山鉄工所 & まめたろう重工