模型 Context Window 与成本：如何为长文档进行选择

为长文档任务选择模型时，不能仅仅比较标题中的上下文窗口大小，还需要权衡每个输入 token 的价格与每次调用中必须处于活跃上下文的文档量。如果每次请求都支付全额输入 token 费用，而不是通过缓存或分块来降低重复成本，那么标榜更大窗口的模型并不一定运行成本更低。

关键要点

• 上下文窗口大小和每个 token 的成本是两个独立的变量。一个大窗口但具有高额输入定价的模型，其单次文档处理成本可能高于配合缓存或分块使用的小窗口模型。
• 正如 OpenRouter 的最佳实践指南中所述，Prompt 缓存可以通过对缓存命中（cache-hit）的 token 进行折扣，从而降低重复长上下文调用的成本。但折扣率和缓存生命周期因提供商和模型而异，因此在估算支出前请务必确认当前条款。
• 对于长文档工作负载，在确定某个模型系列之前，请使用 TokenLab 的模型数据中心 (/models/data)，根据标称的上下文窗口和当前的输入/输出定价来比较候选模型。
• 对于高频的摘要或提取任务，Gemini 3.5 Flash 或 DeepSeek V4 Flash 等快速、低成本模型是合理的默认选择；而 Claude Opus 4.8 或 GPT-5.5 等旗舰模型则更适合需要对长上下文进行深度推理（而不仅仅是处理更多内容）的任务。

上下文窗口和成本并非同一杠杆

人们很容易将“上下文窗口”视为单一的购买决策：选择适合最长文档的模型，然后查看价格。这种方法忽略了窗口大小和成本是相互独立的坐标轴。

窗口大小决定了单次调用中能容纳的内容。价格决定了每次发送该内容时的成本。大窗口模型允许你避免分块，从而简化工程实现，但如果输入 token 的单价很高，且你在对话的每一轮中都发送相同的 50,000 token 文档，这种便利性就会累积成高昂的成本。相反，较小的窗口会强制要求分块或检索，这增加了工程工作量，但如果发送的块很小且模型价格低廉，则可以降低总支出。

对于长文档产品，正确的问题不是“哪个模型的窗口最大”，而是“按照我的应用程序实际调用模型的方式处理这份文档需要多少成本”。这取决于调用模式，而不仅仅是文档长度。

发送长文档时，什么才是成本的驱动因素

对于长文档工作负载，三个因素比原始窗口大小更重要：

输入 token 占主导地位。 对于摘要、提取、分类和检索增强生成（RAG），文档本身几乎总是占据了计费 token 的绝大部分。相比之下，输出通常很短。这意味着输入定价（而非输出定价）通常是首要优化的数字。

重复会成倍增加成本。 多轮对话、智能体循环或任何在每次调用时重新发送相同文档上下文的工作流，都会为该上下文反复付费。除非有某种机制降低重复成本，否则针对长文档进行的十轮对话的成本可能接近单次处理的十倍。

缓存改变了单位经济效益。 如果提供商支持 Prompt 缓存，且你的应用程序在多次调用中重复使用相同的前缀（长文档、系统提示词、工具架构），那么缓存的 token 计费方式可能与新鲜 token 不同。这是在不更换模型的情况下降低长文档成本的最有效手段。

Prompt 缓存如何改变计算方式

OpenRouter 关于 Prompt 缓存的文档 (openrouter.ai/docs/guides/best-practices/prompt-caching，观察于 2026-07-14) 将缓存描述为一种机制：重复的提示词部分（通常是稳定的前缀，如系统消息或放置在上下文开头的长文档）可以由提供商缓存，并在后续重用该前缀的调用中以不同的费率计费。该指南指出，缓存行为（包括如何写入缓存、缓存持续时间以及缓存命中相对于新鲜读取的折扣幅度）因提供商和模型而异。

这种差异对于长文档决策至关重要。两个上下文窗口相同且输入 token 标价相似的模型，在计入缓存后可能会产生截然不同的实际成本，因为一个提供商的缓存 TTL（生存时间）可能足以覆盖你的请求模式，而另一个则会在调用之间过期。在估算文档密集型工作负载的成本之前，请检查：

• 你所选的提供商是否为你想要使用的模型提供缓存支持。
• 什么触发缓存写入与缓存命中（提示词中内容的顺序通常很重要）。
• 缓存条目在必须重写之前能持续多久。
• 折扣是仅适用于输入 token，还是也会影响输出定价。

这些细节在不同提供商之间不可一概而论。请将 OpenRouter 的指南以及特定提供商的文档视为事实来源，而不是基于一般预期进行估算。

决策框架：将模型与文档工作负载相匹配

工作负载模式	最关键的因素	合理的起点
单次摘要或提取，一份文档，一次调用	输入 token 价格，窗口足以容纳文档而无需分块	Gemini 3.5 Flash、DeepSeek V4 Flash 或 /models/data 中的其他低成本路由模型
针对一份长文档的多轮对话	缓存支持和缓存 TTL，而不仅仅是窗口大小	支持 Prompt 缓存的模型；在确定前请验证当前的缓存条款
反复处理相同语料库的智能体工作流	重复调用下的成本，缓存命中定价	低成本的智能体友好型模型，如 TokenLab 智能体比较中的 低成本智能体模型
对长而复杂的文档进行深度推理（法律、技术审查）	模型在长上下文推理上的质量，次要考虑原始成本	Claude Opus 4.8、Claude Fable 5 或 GPT-5.5 等旗舰模型，首先评估任务准确性
跨多份文档的大批量处理	规模化后的总成本，而非单次调用成本	在选择前，在 /models/data 上比较各候选模型的总成本预测
在廉价模型和高级模型之间进行路由的混合工作负载	路由逻辑和回退成本，而非单一模型价格	查看 AI 模型路由基准测试 中的路由分析

将此表作为初步筛选工具，而非最终答案。在最终确定选择之前，请在 TokenLab 的模型数据中心确认任何特定模型的当前窗口大小和定价，因为这两个数字会随时间变化。

实用的请求结构示例

下方的结构展示了缓存友好型请求通常如何将稳定的、可重用的前缀（长文档）与可变后缀（用户的问题）分开，以便文档部分可以在多次调用中被缓存。确切的字段名称和缓存控制因提供商和 API 而异，因此请将其视为说明性的伪代码，并在实施前根据特定提供商的当前文档进行验证。

{
  "model": "example-model-id",
  "messages": [
    {
      "role": "system",
      "content": "You are a document analysis assistant. Answer only from the provided document."
    },
    {
      "role": "user",
      "content": "<<LONG_DOCUMENT_TEXT_HERE>>"
    },
    {
      "role": "user",
      "content": "Summarize section 3 and list any obligations with deadlines."
    }
  ]
}

针对长文档、多问题工作负载的实用模式是：将文档文本保持在多次调用中的稳定位置（以便提供商能够识别缓存的前缀），仅改变末尾的问题或指令。如果你的提供商的缓存实现需要显式缓存标记或单独的缓存控制字段，请根据该提供商的当前文档添加，而不是假设上述结构是完整的。

提交前的检查清单

• 在 /models/data 上确认模型的当前上下文窗口和输入/输出定价，而不是依赖记忆或旧的比较。
• 按预期的调用频率估算单次文档处理成本，而不仅仅是单次调用的成本。
• 检查你的目标提供商是否为你想要使用的模型记录了 Prompt 缓存，以及缓存命中折扣和 TTL 到底是多少。
• 根据你的实际重复模式，决定“分块+廉价模型”是否优于“昂贵模型+大窗口调用”。
• 如果你的工作负载混合了廉价的高频调用和偶尔的深度推理调用，请考虑路由策略而不是单一模型；参见 AI 模型路由基准测试 进行基于路由的成本比较。
• 对于反复触及长上下文的智能体密集型流水线，在默认选择旗舰模型之前，请查看 低成本智能体模型 中的选项。

局限性

上下文窗口数据和定价在不同提供商之间频繁变化，本文中提到的模型具体数字应在阅读时对照 /models/data 进行验证，而非基于本文假设。Prompt 缓存行为（包括折扣率和 TTL）是特定于提供商的，此处未详尽列出；在为生产工作负载制定预算前，请查阅 OpenRouter 的指南和相关提供商的文档。本文未对任何模型在长文档推理上的任务准确性进行基准测试；成本和窗口大小是模型选择的必要条件，但非充分条件。

常见问题解答

更大的上下文窗口是否总是意味着长文档的成本更低？ 不。窗口大小决定了单次调用能容纳的内容；它不决定每个 token 的价格。一个具有高输入定价的大窗口模型，其单次文档处理成本可能高于配合分块或缓存使用的小窗口模型。

每个模型都支持 Prompt 缓存吗？ 不一定。即使支持，折扣率和缓存生命周期也会因提供商和模型而异。请查看 OpenRouter 的 Prompt 缓存指南以及你打算使用的模型的特定提供商文档。

在发布长文档产品之前，我应该如何比较模型？ 从 TokenLab 模型数据中心 (/models/data) 的当前窗口大小和定价开始，然后根据预期的调用量和重复模式估算成本，并计入缓存（如果可用）。在最终确定选择之前，请与 /models/rankings 以及上述路由和智能体成本比较进行交叉核对。通过查看 /models/data 上的当前模型数据来构建你自己的文档工作负载成本估算，从而开始你的工作。