今天在用 CodeBuddy 里的免费混元3模型时，看到它的上下文窗口只有 256k，而 DeepSeek V4 Pro 等模型已经能做到 1M。实际编程能力，体验上混元3明显要优于 DeepSeek V4 Pro。可能 deepseek 这个版本只是预览版吧。题外话，昨天 DeepSeek V4 Flash 正式版号称已经超越了 GLM 5.2 等能力。我的疑问来了，为何有的模型上下文能到 1M，而有的只有 100k？为何小上下文的模型，在实际使用中反而更好用？问了一下 AI，还是学到了不少东西。现在工作严重依赖于模型，还是有必要了解一下。
1M（百万级）和100k（十万级）的差距，本质不是“谁技术更先进”，而是“谁更愿意为这个能力买单”以及“为谁设计”的问题。
你可以把上下文窗口想象成一个会议桌——桌子越长，能同时摊开的文件越多，但找资料（推理）的速度越慢，租用场地（算力成本）也越贵。
注意力机制的“智商”差异
传统模型（如早期Llama）用的是“全注意力”机制，意思是桌上每份文件都要和所有其他文件互相“对视”一遍。上下文翻倍，计算量直接翻4倍（平方级增长）。所以100k基本是传统架构的算力天花板。而能做到1M的模型（如Gemini、DeepSeek、Qwen），通常引入了“稀疏注意力”或“线性注意力”。它们不再强制每份文件互相对视，而是先筛选出“关键联系人”进行交流。这打破了计算量的平方律，让窗口可以暴力拉长。
GPU 硬件“钱”的问题
在推理时，1M上下文需要存储的Key-Value缓存（KV Cache）极其庞大。
- 一个100k的模型，推理时大概需要占用 20GB-40GB 显存。
- 一个1M的模型，如果用传统方法，显存需求会飙到 200GB-400GB 以上，这远超单张显卡（H100的80GB）的承载能力。
所以，敢于开放1M的厂商，要么采用了极致的量化压缩技术，要么使用MoE（混合专家）架构（每次只激活部分参数），把显存开销硬生生压下来。这背后是巨额的工程优化成本，小厂根本烧不起。
位置编码的“外推”能力（算法“视力”）
模型在预训练时通常只看了几千到几万token的“短文章”。想让它看懂“长篇小说”，必须给它配一副“变焦眼镜”——即位置编码（RoPE等）。
如果编码设计得不好，模型看到超过训练长度的文本时，就会像近视眼看远处一样“失焦”，产生胡言乱语。能做到1M的模型，往往在算法上做了“长度外推”优化（如调整基频），让模型天生具备看长文的潜力；而做不到的模型，可能直接放弃治疗，把训练长度就定在100k。
不同使用场景的选择
- 如果你需要总结几十页财报、检索整部小说细节，优先选1M的（如Gemini或Qwen长上下文版）；
- 如果你需要逻辑推理、数学解题、代码逻辑纠错，选那个100k但推理能力极强的模型，效果往往比硬塞1M垃圾数据要好得多。
当然也有使用成本上的考虑，Token 成本随上下文大小增长。例如，codebuddy 官方文档中的说明：
CodeBuddy Code 处理的上下文越大，消耗的 Token 越多。CodeBuddy Code 通过 Prompt 缓存（减少重复内容如系统提示的成本）和自动压缩（在接近上下文限制时压缩对话历史）自动优化成本。
差异大吗
90%的模型在处理超过70%窗口长度的内容时，性能都会急剧下降。
所以，1M和100k在日常使用体验上的差距，远没有数字对比那么夸张。如果你用它分析一本50万字的小说（约500k），1M模型能放进去但可能记混配角名字，100k模型放不进去但放进去了就记得很准。
未来
我觉得随着硬件成本下降、算法优化和模型架构的进步，未来大部分模型都能达到 1M 上下文的能力。
关于作者 🌱
我是来自山东烟台的一名开发者，有感兴趣的话题，或者软件开发需求，欢迎加微信 zhongwei 聊聊，或者关注我的个人公众号“大象工具”， 查看更多联系方式