大模型网摘1M 上下文使用指南：什么时候塞满窗口，什么时候交给检索
1M 上下文不再是稀有规格：DeepSeek 现役的 V4.1-Flash-1017 与 V4-Pro-0813 官方标称上下文长度均为 1M token、输出上限 384K（详见本站开放权重深读），Kimi K3.1 Pro 同为 1M。窗口够大之后，问题从"塞不塞得下"变成了"该不该塞满"。这篇指南给出一条务实的分界线。
先算一笔填充成本
按官方定价页（截至发稿），以缓存未命中填满 1M 输入：deepseek-flash 谷时约 $0.15、峰时约 $0.30；deepseek-v4-pro 为 $0.66/$1.32（峰谷机制见专文解释）。单次全窗填充看似不贵，但如果这个窗口每次请求都要重建——例如每轮对话都从头贴文档——成本会按请求次数线性放大。缓存命中价才是分水岭：Flash 谷时命中价 $0.003 与未命中 $0.15 之间约 50 倍的差距，意味着重复前缀必须命中缓存，本站的 API 省钱指南对此有展开。
该进窗口的，与不该进窗口的
适合整段进窗口的：一次性深度分析的长文档（合同、研报、长代码库的集中审查）、需要全局结构的任务（跨章节改写、全库重构评审）。不适合的：高频重复的固定指令与知识（应沉淀为稳定前缀吃缓存）、可检索的事实性内容（交给 Search & Fetch 或自建检索按需拉取）。把"万金油内容"塞进窗口，买到的是 token，浪费的是钱和延迟。
三个实操习惯
一、前缀稳定：把系统提示、工具定义、格式要求放在提示开头并保持逐字一致，动态内容放后面——这是命中缓存的前提。二、分段摘要加按需展开：先让模型输出各章摘要，再针对相关章节贴原文，比一次性全量输入便宜且往往更准。三、监控用量：响应里的 usage 字段会标明缓存命中 token 数，拿它对账就能发现"窗口被反复重建"这类隐形浪费。推理侧的优化也在跟上，DeepInfer 的 SWA 有界回放等机制说明长上下文的解码成本可以用工程手段压低。模型名与价格速查见接入速查。
一句话总结：1M 窗口是能力上限，不是预算目标。结构化的上下文管理，比"能塞多少塞多少"省得多，也更可控。