教程 · 2026-10-31

1M 上下文长文档工作流：上下文缓存与峰谷定价的组合用法（Python）

把一整份合同、一整套代码库或一本书投进模型再反复追问，已经不需要检索增强凑合——deepseek-flash 提供 100 万 token 上下文与 38.4 万 token 输出上限。但长上下文的账单容易失控，这篇教程把两个省钱开关讲清楚：上下文缓存怎么命中、峰谷定价怎么错峰。接入参数速查见本站的 API 接入速查，1M 窗口的使用策略另见 1M 上下文使用指南。

前置：两分钟接入

DeepSeek API 提供 OpenAI 兼容端点，用官方 openai SDK 换一个 base_url 即可：

from openai import OpenAI

client = OpenAI(api_key="YOUR_KEY", base_url="https://api.deepseek.com")

resp = client.chat.completions.create(
    model="deepseek-flash",
    messages=[
        {"role": "system", "content": "你是合同审阅助手，引用原文回答。"},
        {"role": "user", "content": DOC_TEXT + "\n\n请列出所有风险条款并说明理由。"},
    ],
    max_tokens=4000,
)
print(resp.choices[0].message.content)

DOC_TEXT 可以长到几十万 token——只要总长不超过 1M 窗口即可。首次请求的输入全部按「缓存未命中」计价，整条工作流里高成本的调用只有这一次。

缓存规则：前缀完全匹配才命中

磁盘缓存对所有用户默认开启，不用改代码，但命中条件比直觉严格：受滑动窗口注意力机制影响，每个缓存前缀是一个独立完整单元，后续请求必须完全匹配某个单元才算命中。前缀单元在三种时机落盘：请求边界（用户输入结尾与模型输出结尾各一个）、跨请求公共前缀检测、以及长输入/长输出按固定 token 间隔切分。举例：首轮请求是 A+B，第二轮是 A+B+C，则 A+B 部分命中缓存；若第二轮是 A+C，与缓存单元不完整匹配，A 部分也不命中。这决定了提示词的组装顺序——稳定不变的指令与文档放前面，每轮变化的问题放最后，追问时复用同一 messages 列表追加即可。

峰谷定价：把重活排进谷时

deepseek-flash 每百万 token 计价：输入缓存命中 $0.003（谷）/ $0.006（峰），未命中 $0.15 / $0.30，输出 $0.60 / $1.20。峰时段只有 UTC 周一至周五的 01:00-04:00 与 06:00-10:00（中国法定节假日除外），其余全是谷时——整个周末都是半价。多轮追问集中在谷时做，输出与未命中输入直接省一半；批量审阅类任务排到周末跑，成本差距相当可观。

组装：一条追问成本怎么算

假设文档 30 万 token，首轮全量输入 + 4000 token 输出，此后每次追问只追加几百 token 问题与 4000 token 输出。谷时首轮输入 $45 左右（30 万 × $0.15），之后每轮输入几乎全走 $0.003 的命中价、可忽略不计，主要成本变成每轮 $2.4 的输出。轮次越多，缓存摊薄越明显——这正是「一次投喂、反复追问」比「每轮重塞文档」便宜两个数量级的原因。并发上限 2500 也足够整组文档并行审阅。若负载对质量要求更高，可对照 V4-Pro 与 V4.1-Flash 的档位对比再决定；首次跑通的更多细节可回看 Python 快速上手。