長文本唔再是傳說：2026 本地長上下文 LLM 實戰指南
由 8K 到 10M token：點樣喺自己部機餵成本書、成個 codebase 入模型
AI 教學AI 生成
重點整理
- 長上下文點解難：KV cache 記憶體爆炸同「中間失憶」兩大問題一文講清
- 2026 主流長文本開源模型盤點：Llama 4 Scout（10M context）、GLM-5.2（1M）、Qwen3.8 系列點揀
- 實戰技巧：RAG vs 長上下文唔係二選一，混合策略先係王道
- Ollama 實測：邊啲型號喺 16GB／32GB 機真係跑到長文本
長上下文點解咁難？
模型處理長文本有兩大障礙：第一係記憶體——KV cache 隨 context 長度線性增長，128K token 嘅 cache 可以食你幾 GB VRAM；第二係**「中間失憶」（lost in the middle）**——模型對開頭同結尾記得清，中間內容就好易忽略。
2026 長文本開源模型盤點
Llama 4 Scout：Meta 2026 年頭出嘅 MoE 模型，10M token context window 係開源界紀錄，單張 H100 跑得到。適合「成個資料庫掟入去」嘅場景。
GLM-5.2：智譜出品，754B MoE（40B active），1M context，MIT license 任用。長文本推理效率好，配合 Sparse Attention 省計算。
Qwen3.8 系列：中小型長文本首選，128K context 對九成日常任務夠用，消費級卡都跑到。
RAG vs 長上下文：唔使二選一
好多人問「有咗 1M context 仲使唔使 RAG？」——實際答案係混合策略最抵：
- 先用 embedding 檢索縮細範圍（慳 token 慳錢）
- 再將候選段落餵入長上下文模型做精讀（保質素）
- 全文 10M context 留俾「真係唔知邊度有答案」嘅極端情況
純長上下文每次查詢都成個 corpus 入模型，慢同貴；純 RAG 就會漏跨段落嘅線索。
Ollama 實測
# 16GB 機：Qwen3.8 8B 長文本版，Q4 量化
ollama run qwen3.8:8b-128k
# 32GB+ 機：可以諗 Llama 4 Scout 量化版
ollama run llama4-scout:17b-q4_K_M
實測重點：設定 num_ctx 先會真開長 context（預設往往只得 4K！）：
ollama run qwen3.8:8b-128k
>>> /set parameter num_ctx 131072
忘記調 num_ctx 係 90% 人「長文本跑唔動」嘅真正原因——模型靜靜哋截斷咗你嘅文件都唔會出 warning。
總結
2026 年本地跑長文本已經好成熟：8B 級模型 + 128K context + Q4 量化，一部普通遊戲機就處理到成本書。記住三件事：調 num_ctx、用混合策略、揀啱模型級別。