2.4 主流模型的上下文能力对比
2.4.1 主流模型概览
模型参数和可用性变化非常快。具体型号、窗口与访问状态统一维护在 附录 E：快变事实核验表，并由 30 天 TTL 检查阻止过期快照继续发布。本节只保留选型所需的稳定解释；生产决策还必须核对官方模型页、价格页和实际账号可用区。
OpenAI GPT 系列
当前快照中官方目录首推 GPT-6 Astra（标为 Default，已全量可用）、GPT-6.1 Sol（兼顾能力与成本）与 GPT-6 Luna（成本敏感的大批量负载）；上一代 GPT-5.6 Sol、GPT-5.6 Terra、GPT-5.6 Luna 仍在目录中；面向编码智能体的 GPT-5.3-Codex 已宣布弃用
通用推理、代码与工具生态成熟
按 Astra、Sol、Luna 的能力与成本边界分层评估；价格和可用性按模型 ID、账号层级、缓存、区域与服务层级核验
Anthropic Claude 系列
当前快照的阵容是 Claude Fable 5.1、Claude Opus 5.5、Claude Sonnet 5.5 与 Claude Haiku 4.5（Mythos 5.1 与 Mythos 5 非普遍可用，仅通过 Project Glasswing 向获批客户受限开放）；Claude Fable 5、Claude Opus 5 与 Claude Sonnet 5 已移入 legacy（官方模型页的 legacy 区间现含 Fable 5、Opus 5、Opus 4.8/4.7/4.6/4.5、Sonnet 5 与 Sonnet 4.6）
长文理解、代码与写作稳定性
同时核验能力规格、访问状态、区域路由、缓存、批处理和实际账号可用区
Google Gemini 系列
当前快照中稳定 Flash 序列的最新一档是 Gemini 3.8 Flash，此前的 Gemini 3.5 Flash 仍在目录中；具体 token limits 由附录引用的官方模型页维护
多模态与长上下文任务
区分 stable 与 preview，并在部署前确认模型字符串、弃用计划和区域可用性
Meta Llama 系列
Meta 官方模型卡显示 Llama 4 Scout 为 10M context、Llama 4 Maverick 为 1M context；实际托管服务可能给出更低上限
私有化与可定制能力
需要自行评估部署、显存、量化和服务商限制
Qwen / DeepSeek 等开源或开放 API 系列
上下文窗口、价格和工具能力随具体模型、服务商和部署方式变化
中文、多语言或推理性价比突出
需结合官方文档、模型卡和本地压测确认
注：价格、上下文窗口、工具能力、区域可用性和弃用状态都属于高波动信息。方案文档应记录“查询日期 + 具体模型 ID + 模型页/价格页链接”，并在上线或迁移前重新核验；本书快照以附录 E 为准。
图 2-4：模型选型象限图
这张图不是替代表格，而是把选型时最常见的两类张力显式化：一类是任务复杂度与质量要求，另一类是成本和延迟约束；真正落地时还要把上下文窗口、工具能力和部署方式一起纳入判断。
2.4.2 选择模型的考量因素
选择模型时需要综合考虑多个因素：
上下文需求
根据应用场景的上下文需求选择：
简单对话：8K-32K 通常足够
文档问答：64K-128K 较为适合
大规模代码库分析：需要 200K 以上
超长文档处理：考虑 1M 级别模型
任务类型
不同模型在不同任务上表现各异：
代码生成：优先看代码基准、工具调用稳定性和长代码编辑能力
中文处理：优先看中文任务集、专业术语覆盖和事实一致性
推理任务：优先看复杂推理基准与失败样例分析
多模态：优先看图文/语音端到端效果和延迟
成本因素
上下文长度直接影响成本：
更长的上下文意味着更高的 Token 费用
需要权衡上下文丰富度与成本效益
考虑是否有批量折扣、缓存机制、区域处理溢价或长上下文溢价
延迟要求
上下文长度影响响应速度：
长上下文增加首 Token 延迟
实时应用可能需要限制上下文规模
Flash 系列模型在延迟上有优势
2.4.3 长上下文性能评测
评估模型长上下文能力的常用基准：
Needle in a Haystack (NIAH)：在长文档中插入特定信息，测试模型能否准确检索。现代长上下文模型在简单单针任务上可能接近饱和，因此还应结合多针、聚合、多跳和干扰证据任务
RULER：更全面的长上下文评测基准，包含多种任务类型：检索、聚合、跟踪等
LongBench：中英文双语长上下文基准，覆盖问答、摘要、代码等多种场景
2.4.4 实际应用建议
分层策略
为不同场景配置不同模型：
简单查询：使用小规模快速模型
复杂任务：调用大规模高能力模型
超长文档：选择长上下文专用模型
混合架构
组合使用多个模型：
用小模型做初步筛选和分类
用大模型处理复杂推理
用专业模型处理特定任务
上下文优化优先
无论选择哪个模型，都应该先优化上下文：
减少冗余信息
提高信息密度
结构化组织内容
单纯依赖更大的上下文窗口并非最佳策略。研究表明，经过优化的短上下文往往比未优化的长上下文效果更好。上下文工程的核心价值正在于此。
2.4.5 未来趋势
上下文窗口将继续扩大，但更值得关注的是：
1. 有效利用率提升
让模型更好地利用长上下文。当前模型在超长上下文中的信息利用效率仍有提升空间，尤其是中间位置的信息容易被“遗忘”。未来的架构改进可能缓解这一问题，但生产系统仍需要通过任务级评测确认模型是否真的利用了关键证据。
2. 成本效率改善
长上下文的计算成本降低。稀疏注意力、线性注意力、KV cache 优化和分块预填充等技术会持续改善成本曲线，但实际经济性仍取决于显存、内存带宽、批处理、缓存命中率和延迟目标。
3. 动态上下文技术
按需加载和卸载上下文。未来模型可能支持在推理过程中动态管理上下文，不再是一次性全部加载。这类似于操作系统的虚拟内存，只有需要的部分才占用计算资源。
4. 上下文缓存
复用公共上下文，减少重复计算。系统提示、知识库等固定内容可以预先计算并缓存其表示，多次请求之间复用。这将大幅降低延迟和成本，尤其适合高频调用场景。
这些技术进展将与上下文工程紧密结合，共同推动 AI 应用能力的提升。
2.4.6 官方信息入口（用于参数核验）
最后更新于