qwen4上下文窗口翻近4倍，一次对话能装100万token

一个已合并的 PR 把 qwen4 系列模型的上下文窗口从 262,144 token 提到 1,000,000 token。合并提交是 9ef52e153606e4e4c3bbe704fb3db0628e27818b，时间 2026 年 10 月 28 日。

对用 AI 编程助手的人来说，变化落在很具体的地方。以前一次对话能装下大约 26 万 token 的代码和文件，现在按配置能装 100 万。整个项目的目录结构、几个相关文件、一长串报错日志，可以一次性丢进去。中间不太容易被截断，前面聊过的内容也不会那么快被挤掉。

变的是输入，不是输出

窗口抬了，配套的阈值跟着抬。自动压缩阈值从 222,822.4 提到 850,000，硬阈值从 239,144 提到 977,000。这两个数决定助手什么时候开始压缩、丢掉旧对话；往上挪，等于它能多撑一阵才动手。

输出上限没动，两边都是 32,768 token。模型一次回复的长度和以前一样，变的是它在开口之前能看到多少东西。qwen4 沿用 Qwen 家族 32K 的输出默认值，这次只处理输入窗口的大小。

改动覆盖八种 qwen4 写法：不带后缀的主版本、-max、-plus、带点的 4.5、coder。带日期的快照、带 provider 前缀的 id，以及 omni 的夹具 id 也在里面。qwen3-max 和 qwen3.5-plus 作为对照保持不变，分别是 256K 和 1M。omni 模型的四个输入模态没有改动。

1M 是推出来的

这个 1M 不是从哪个 qwen4 端点读出来的。没有调用过真实的 qwen4 端点，内置目录（抓取于 2026-10-03）和本地 models.dev 缓存（抓取于 2026-10-27）里都不含任何一个 qwen4 id。它是推断出来的、面向整个世代的默认值。

最不确定的是 qwen4-omni-120b-think，没有来源写明它的上下文窗口。

还有一层覆盖关系：只要存在 model-registry.json，目录里的值就优先于家族规则。测试里给 qwen4-max 设 400.0k、给 qwen4 设 512.0k，读出来就是这两个数，家族那一行让位。实际看到的窗口大小会因配置而不同。

如果某个成员实际窗口小于 1M，主动压缩会按 1M 来跑。可能有一个请求先因超长被拒，之后才靠被动压缩恢复。

合并之前查过什么

验证结论是没有阻塞性发现。36 个 dev-entry CLI 单元、24 个编译产物 CLI 单元、7 个变异单元，还有那个 106 项测试的单元文件，行为都符合 PR 描述。CI 在验证时的 head 上，18 个 check run 成功，0 失败，其余是 80 个跳过和 1 个 review-pr 取消。

这些测试证明的是代码按规格执行，不是 Qwen4 的真实窗口就是 1M。仓库和 models.dev 现在都证实不了这个数值。实际窗口多大，omni 那个成员是不是也是 1M，都还没有答案。