Long Context Extensions & Scaling: 解释上下文长度与推理成本的关系，以及经济性权衡。

Core Concept: 注意力成本 ∝L²（prefill）、KV 显存 ∝L；故长上下文的成本远高于'检索 + 短上下文'。

数学机理：<strong>成本结构</strong>——一次请求的推理成本可分解为：(1) <strong>prefill 成本</strong>——处理输入 prompt 的算力，注意力的 FLOPs ∝L²（虽然 FFN ∝L）；故 <strong>C_prefill ≈ a·L² + b·L</strong>（a 为注意力系数、b 为 FFN/其他系数）；(2) <strong>decode 成本</strong>——每步生成一个 token，需读取整个 KV cache（∝L）；若输出 M 个 token，则总读取 ∝M·L；(3) <strong>显存成本</strong>——KV cache ∝L×batch，限制并发数（吞吐）。<strong>经济性对比</strong>——把 100k token 全放进上下文 vs 检索出 4k 相关片段：(a) prefill 成本比约 (100k)²/(4k)² = 625 倍；(b) KV 显存比约 25 倍；(c) 但检索需额外成本（向量检索、rerank）。故<strong>在'只需少数相关片段'的任务上，检索的成本远低于长上下文</strong>（可能低 1~2 个数量级）。<strong>何时长上下文更划算</strong>——(a) 任务需要<strong>全局整合</strong>（检索无法保证覆盖所有相关信息）；(b) 上下文本身不长（如 8k~16k，此时检索的收益小）；(c) 检索质量差（漏检导致错误，成本更高）。<strong>盈亏平衡的量化</strong>——设长上下文的额外成本为 ΔC，检索的成本为 C_r + 漏检损失；当'漏检导致的业务损失 > ΔC − C_r'时，长上下文更划算。实践中需按任务测量（A/B 测试）。

深度剖析与工程权衡：① <strong>'prompt caching' 对经济性的改变</strong>——若多个请求共享长前缀（系统提示、few-shot、文档），前缀缓存使 prefill 只算一次，长上下文的边际成本大幅下降；这是'长上下文可经济使用'的关键工程手段。② <strong>与 batch 的交互</strong>——prefill 是 compute-bound，故增大 batch 可提升算力利用率、摊薄单位成本；但 KV 显存 ∝L×batch 限制了大 batch 下的长度。故'长上下文 + 高并发'受显存约束。③ <strong>分层策略（cascade）</strong>——先用廉价手段（小模型/检索）处理，只对'难样本'升级到长上下文 + 大模型；这是成本优化的常见架构。④ <strong>与输出长度的关系</strong>——若输出很短（如分类、抽取），则 decode 成本低、prefill 主导；若输出长（如摘要），则 decode 的 KV 读取成本也显著。⑤ <strong>与'上下文压缩'的关系</strong>——另一条路线是'压缩上下文'（如用 LLM 摘要长文档、或用专门的压缩器把长文档压成少量 token），在保持信息的同时降低长度；这是长上下文与检索之外的第三条路（如 Gist token、AutoCompressor）。⑥ <strong>面试要点</strong>——被问'长上下文是否划算'，应给出'<strong>C ≈ a·L² + b·L 的成本结构</strong>'与'<strong>检索 vs 长上下文的数量级对比（可能差 1~2 个数量级）</strong>'，并说明'何时长上下文更优（全局整合/上下文不长/检索质量差）'；能提到'prompt caching 与上下文压缩'是深度理解的标志。