1M 上下文 + 4K 图片：免费全模态的能力上限到底划在哪？

"全模态"这个词，过去总跟昂贵的订阅套餐绑定在一起：既要有百万级的上下文窗口撑起长文档，又要有能吞下高分辨率图片甚至视频的视觉通道，还要不心疼 token 烧钱。Agnes 3.0 Flash 的出现让这三件事同时变了味——文本、图像、视频三模态 API 无限期免费，标称 1M token 上下文，图像输入上探到 4K 量级。本文从仓库源码与社区实测两条线出发，把"免费全模态的能力上限"拆开来看：标称数字里哪些是真实的工程能力，哪些是宣传口径，以及免费档与付费档之间到底隔着一道什么样的墙。

1M 上下文与 4K 图片的实测表现

首先要厘清一个关键事实：仓库里这份开放权重与线上 API 跑的不是同一个 checkpoint。仓库模型卡在 README.md 中明确声明，本仓库发布的是Agnes-3.0-Flash Preview（33B 参数 dense 模型，上下文 262,144 token），而线上 production/API 版本使用不同的 checkpoint 与配置，拥有1M token 上下文窗口。也就是说，"1M 上下文"是 API 的能力上限，本地开放权重能拿到的是 256K 档。这条边界本身就值得玩味：开源版本卡在 256K，正是社区实测中"最稳"的档位。

社区的实际测试也印证了这种梯度。有测试者用 106 次调用把标称 512K 的上下文"测穿"，发现在超长序列下模型行为开始不稳定；而另一路实测结论是"256K 上下文最稳"。这类测试的价值不在于否定标称参数——1M 窗口的服务端确实能受理百万 token 的输入——而在于揭示了免费档的真实体验边界：窗口是能力上限，稳定性才是可用性上限。对绝大多数真实负载（一部小说、一整个代码仓库、几十份 PDF）而言，256K 已经覆盖了 95% 的场景，1M 更像为"整库喂给模型"这种极端用例预留的余量。

图像侧的证据来自源码。在 image_processing_agnes.py 中，fit_to_grid函数把像素预算钳制在min_pixels = 256*256与max_pixels = 4096*4096之间——这正是"4K 图片"的工程含义：不是强制把图缩到 4096×4096，而是允许最大 4096×4096 像素的图以接近原比例的方式进入视觉编码器。处理器先把长宽对齐到 32 的倍数，再在像素预算内按原宽高比缩放，同时限制了极端宽高比（长宽比超过 200 直接报错）。配套的 preprocessor_config.json 把longest_edge设为 16777216（即 4096²），从配置层固定了这一上限。

为什么 4K 图片可行而不会撑爆上下文？答案藏在 config.json 的架构里：72 层解码器中只有 18 层持有随序列长度增长的 KV cache，其余 54 层是带独立于序列长度的循环状态的 delta-rule 层，4 层一组按 3:1 交替。一张 4K 图经 16×16 patch 切分、2×2 空间合并后产生的视觉 token 数以千计，若全部落到全局注意力层，KV cache 会以二次方速度膨胀；而循环层把长序列的负担压缩成了固定大小的状态，这让"高分辨率图像 + 长上下文"不必在显存上互相挤兑。

免费档与付费档能力上限对照

免费策略是这次讨论绕不开的核心。社区情报中反复出现"全球首个全模态 API 开放""三款核心模型 API 无限期免费""一周烧出 3.12 万亿 Token"等描述，佐证了 Agnes 免费 API 的真实体量——不是限时试用，而是把文本、图像、视频三条通道全部放开。与之对照的是，社区实测中提到 4 美元包月的档位，用于换取更稳定的服务和更高的上下文保障。

付费与免费之间真正拉开差距的不是生成质量，而是三个工程维度：

上下文稳定性。免费档的 1M 是受理上限，但 512K 以上序列在实测中开始出现不稳定；4 美元档实测中 256K"最稳"的背后，是服务端对长序列调度与内存分配的差异化处理。对生产应用而言，与其追求标称的 1M，不如锚定实测稳定的档位来设计业务。

并发与速率。免费 API 存在 RPM 限制，图像与视频生成走独立端点且为异步响应——社区接入教程（如 OpenCode、Codex++ 的集成方案）都明确标注了这一约束。免费档适合个人开发与原型验证，高并发商用流量仍需评估限速。

能力本身。从仓库评测看，Preview 权重在 IFBench 上拿到 74.20、GPQA Diamond 85.05、SciCode 38.08，与 27B~35B 量级的同期模型同一梯队，这在"免费"语境下已是超预期的表现。评测图的完整对比见 README.md 中的基准表格：

需要强调的是，上述成绩归属于开放权重 Preview checkpoint，线上 API 版本的成绩不在本仓库数据范围内，也不应混用。这张图的价值在于给出"免费能拿到什么水平"的下限参照：即便按保守口径，33B 量级的免费模型也已经覆盖了推理、代码、指令遵循的日常需求。

对多模态应用开发的启发

对开发者而言，免费全模态最有价值的启发不是"白嫖"，而是重新设计应用时对能力边界的正确建模。

其一，上下文不再是稀缺资源的假设可以成立。仓库的 transformers 接入极其轻量，README.md 给出的标准流程只需四行：加载模型后直接走apply_chat_template，多模态输入通过AutoProcessor的 processing_agnes.py 完成图像/视频 token 替换与动态分辨率适配。256K 乃至 1M 的窗口意味着"整库检索"可以从 RAG 退化为直接灌入，长文档分析、代码库级重构、多文件上下文这类过去需要分块处理的任务，现在可以单次完成。

其二，视觉管线的动态分辨率设计值得抄作业。fit_to_grid的逻辑（对齐 32 倍数 → 像素预算内保比例 → 限制宽高比）在 image_processing_agnes.py 中完整可读，视频侧 video_processing_agnes.py 的fit_video_to_grid则是同样的思路加上时间维 patch。这种"按输入分辨率动态分配 token"的策略，是当前多模态模型平衡细节保真与上下文消耗的标准答案，可以作为自建视觉应用的参考范式。

其三，混合注意力架构正在成为长上下文模型的主流选择。仓库通过 sglang_patch/README.md 里三个文件的补丁，把 Agnes 的权重映射到 sglang 内建的混合注意力实现上：delta 层权重映射到linear_attn.*、全局注意力映射到self_attn.*、每层的并行 FFN 分支合并进主投影，serve.sh 一键拉起 OpenAI 兼容服务。这套方案的工程价值在于：只有 25% 的层需要 KV cache，长上下文推理的显存成本被结构性压低，这正是"免费 API 敢放开 1M"的底气来源。对自建推理服务的团队，这组补丁本身就是一份可复用的混合注意力部署样板。

最后回到"免费全模态的能力上限"这个问题。答案不是一个数字，而是一条斜线：能力上限由架构决定（4K 图像、256K~1M 上下文），体验上限由稳定性决定（256K 最稳、512K 以上需自测），而商业上限由限速与异步策略划定。对应用开发者，正确的姿势是把这条斜线画进自己的架构里——在免费档的稳定区间内做产品，把 1M 与 4K 当作极端场景的保险丝，而不是日常负载的基准线。