百万上下文模型怎么选：37 个长上下文模型的取舍
目前站内支持 100 万 token 级上下文的模型有 37 个，覆盖 Claude、GPT、Gemini、Kimi、GLM、DeepSeek、Qwen 等系列；选型时先按任务实际需要的长度筛，再看单价与缓存支持。
更新于 2026-11-14 · SageLib 团队 · 标签：long-context、selection
结论要点
- 先把任务真实需要的长度量出来，再按长度筛模型，不要一律选最长的
- 同系列模型往往共享上下文长度，但单价差别很大
- 长文档重复提问时，选支持缓存的模型能明显省钱
「上下文多长」是选型里最容易被放大的一个参数。先量任务，再选模型。
当前在架的长上下文模型（截至本文更新）
站内 68 个模型中，37 个支持 100 万 token 级上下文，按系列看：
| 系列 | 上下文 | 代表模型标识 |
|---|---|---|
| Claude 5.x 全系 | 1,000,000 | claude-sonnet-5-5、claude-opus-5-5、claude-haiku-5-5 |
| GPT 5.6 / 6 系 | 1,050,000 | gpt-6-sol、gpt-6-astra、gpt-5.6-terra |
| Gemini 3.5–4 系 | 1,000,000 起 | gemini-3.7-flash、gemini-4-argon |
| Kimi K3 系 | 1,048,576 | kimi-k3、kimi-k3.1-pro |
| GLM 5.3 | 1,000,000 | glm-5.3、glm-5.3-flash |
| DeepSeek V4 / V4.1 | 1,000,000 | deepseek-v4.1-flash、deepseek-v4-pro-0813 |
| Qwen 3.8 | 1,000,000 | qwen3.8-max、qwen3.8-flash |
具体单价见 模型价格表，能力与端点见各模型详情页。
三个判断顺序
- 量长度：把真实任务（一次对话 + 附带的文档/代码）用 tokenizer 估一遍， 大多在 2 万以内，这时候长上下文并无用武之地；
- 看单价：同系列里「长上下文 + 低价」的组合通常有取舍（速度、能力、缓存支持）；
- 看缓存：重复提问同一份长文档时，支持缓存写入的模型能把重复部分的成本压下来。
什么时候不该用长上下文
- 只是问答一次：直接裁剪到相关片段，答案往往更准；
- 需要检索：先做向量检索或关键词过滤，再交给模型；
- 成本敏感：长输入按 token 计价，百万级输入的开销会明显高于分段处理。
参考来源
常见问题
上下文长就能一次塞进整个代码库吗？
能塞进去，但输入按 token 计费，百万 token 的输入单价乘上去并不便宜；常见做法是配合缓存，把稳定不变的部分缓存起来。
长上下文会不会更容易丢失细节？
会。模型在超长上下文里的检索精度普遍下降，长文档建议先摘要或分段检索，再让模型回答。