数字齐得可疑
前两天我在 OpenRouter 上翻模型列表，想挑几个长上下文的模型备着。翻完发现一个现象：2026 年 11 月 6 日这一天，列表里 454 个模型，202 个的上下文窗口标着 1M 起步，排在最前面的已经标到 2M。把窗口从大到小排个序，前几页几乎全是七位数。
数字这么齐，不像巧合。这篇文章把我翻列表翻出来的东西整理一下：这个数字是怎么来的，标 1M 和用 1M 差在哪，以及同样标 1M 的模型，价格能差出多少。
1M 到底是个什么数
打开 Kimi 的模型文档，写的是 1,048,576 tokens。这个数不是随手填的，它是 2 的 20 次方。训练和推理框架里的显存分配、KV 缓存都按 2 的幂对齐，窗口定在 1048576，框架不用做任何特殊处理。宣传页写「1M」，只是把这个数念得顺口一点，就像硬盘标 1TB，精确值还得看文档。
所以「满屏 1M」的第一层原因很朴素：大家用的是同一套底层框架习惯，取的都是 2 的幂。
第二层原因是内卷。2023 年主流窗口还在 8K 和 32K 打转，2024 年跳到 128K，同年 Gemini 把旗舰窗口推到百万级。到了 2026 年，1M 成了旗舰和轻量模型的公共地板。窗口已经不是卖点，是入场券，没有它连列表都排不进前列。
窗口大小回答的是「塞不塞得下」
先说清楚概念。上下文窗口是模型一次能处理的 token 上限，历史消息加本次回复都算在内。Kimi 官方文档的原话是 API 本身没有记忆功能，每次请求都要把历史消息手动带上，窗口就是这段历史加本次问题能占用的最大额度。具体账怎么算我之前写过一篇，这里不展开。
窗口标 1M，意思是 100 万 token 能塞进去。塞进去之后用得好不好，是另一件事。中间内容被略过、开头结尾记得牢这类问题，我之前专门写过 Lost in the Middle 那篇，结论放在今天依然成立：报 1M 的模型，在 1M 长度上的实际表现，和当年报 128K 的模型在 128K 上的表现，是同一性质的问题。NVIDIA 的 RULER 基准早就测过一轮：声称支持 32K 以上的模型，只有一半能在 32K 长度上保持合格成绩。
所以看窗口数字的时候，心里要有个换算：窗口是「塞得进」，有效长度可能短一截。
同样标 1M，价格差出一百倍
先纠正一个直觉：窗口大小和价格是两回事，决定账单的是输入和输出两个单价。还是 OpenRouter 当天的数据：GLM-5.3 输入 0.07 美元、输出 1.40；Kimi K3 输入 0.19、输出 16；Sonnet 5.5 输入 2、输出 10；GPT-5.5 Pro 输入 30、输出 180。输出对输入的倍率，便宜档能拉到 20 倍、80 倍，旗舰档一般是 5 到 6 倍。材料放在输入里比让模型复述便宜，能用输入解决的事，别让模型写长文。
窗口趋同之后，竞争全挪到了单价上，而单价的差距远比窗口大。按当天数据把 1M 档的模型按输入价排个队：
- 免费档：NVIDIA 的 nemotron-3 系列，1M 窗口，0 元
- 一毛档：GLM-5.3 每百万 token 0.07 美元，Kimi K3 是 0.19，Gemini 2.5 Flash 是 0.30
- 两三块档：Claude Sonnet 5.5、Gemini 3.1 Pro、Kimi K3.1 Pro，都收 2 美元
- 十块档：Claude Fable 5.1 和 GPT-6 Astra，收 10 美元
- 天花板：GPT-5.5 Pro，30 美元
注意 OpenRouter 的标价一般含平台加价，落地前以各家官方定价页为准。
差距有多夸张，算笔账就明白。拿一本 20 万汉字的小说喂给模型，按 1 个汉字约 0.6 个 token 算，大约 12 万 token。GLM-5.3 收 0.0084 美元，合人民币六分钱；Sonnet 5.5 收 0.24 美元，一块七；Fable 5.1 收 1.2 美元，八块六；GPT-5.5 Pro 收 3.6 美元，二十六块。
同样是那本小说，同样塞进 1M 的窗口，最贵和最便宜差 400 多倍。窗口人人都有，差别全在单价上。输出价里还藏着一笔账：Kimi K3 读这本书只收 0.02 美元，让它写两千 token 的书评，输出反收 0.03 美元，比读全书还贵。
还有一个容易被忽略的细节：窗口最大的不是最贵的。列表里标 2M 的是 Grok 4.20，输入 1.25 美元、输出只要 2.50，输出价只有 Kimi K3 的六分之一。窗口和价格之间没有必然关系，别用「窗口大所以贵」的直觉去猜。
三步选型，把钱花在刀刃上
第一步，先问自己材料是否必须一次性全给。合同、代码库这类要模型通读的，直接选大窗口，但先用一毛档的便宜模型跑一遍。质量够了就停手，不够再升两三块档的旗舰。很多人上来就用最贵的，其实八成的活便宜模型就能干。
第二步，多轮对话别指望窗口大就一劳永逸。窗口再大也有满的一天，历史消息每轮都在累积。Kimi 官方文档的建议很直白：保留最新 20 条左右的消息，更早的截断或者总结。裁剪、压缩、缓存这几个动作我之前写过一篇实操，照着做就行。
第三步，长期知识库别硬塞。100 万 token 听起来能装下一个资料库，但每次请求都全量计费，越塞越贵，中间内容还容易被略过。正经做法是检索：资料切块入库，每次只把相关的几段塞进上下文。切块怎么切我写过，向量库是什么也写过，两条路都通向同一个结论。
另外补一个省钱开关：如果你的请求前缀重复度高（同一段系统提示词反复用），上下文缓存能把这部分的钱省下来，Kimi 现在对重复前缀自动启用缓存，默认保留 5 分钟。
小结
满屏 1M 不是巧合，一半是 2 的 20 次方这个工程惯例，一半是内卷到头之后的公共地板。2026 年选模型，窗口数字基本可以跳过不看，该看的是有效长度和单价，再加上你打算怎么用它。
我的习惯是先便宜后贵，先小窗后大窗，先检索后硬塞。顺序反了，账单会教你重排。