1200万上下文模型亮相，大模型竞赛开始从参数转向效率-速维云

SubQ 的出现，把大模型竞争里一个长期被忽视的问题重新推到了台前：上下文窗口越做越长之后，真正决定可用性的，已经不只是“能塞多少 token”，而是长文本读写、推理速度和调用成本能不能一起扛住。Subquadratic 发布的 SubQ 号称支持 1200 万 token 上下文，并在 100 万 token 场景里把速度拉到传统方案的数十倍，这类架构突破如果能稳定落地，长文档分析、代码仓库理解、企业知识库和复杂 Agent 工作流都会被重新估价。

长上下文进入效率战

过去一年，大模型厂商频繁把上下文窗口做大，从几十万 token 到百万 token，卖点通常是“能读更多”。但真实业务里，长上下文并不等于好用：资料越长，响应越慢、费用越高，模型还可能在海量上下文中遗忘关键细节。SubQ 这次最值得关注的地方，恰恰是它没有只强调窗口长度，而是把速度和成本放在同一个故事里。

据 AITNT 最新资讯，SubQ 基于新的 SSA 架构，号称在 100 万 token 场景下速度提升 52.2 倍，成本只有 Claude Opus 级模型的一小部分。这个数字本身仍需要更多真实任务验证，但方向很清楚：长上下文模型正在从“参数和窗口竞赛”，转向“架构、吞吐和单位任务成本竞赛”。

架构创新比堆料更关键

Transformer 仍然是大模型的主流底座，但它在超长上下文下的计算和内存压力一直很重。业界因此不断探索稀疏注意力、状态空间模型、混合架构、检索增强和推测解码等路线。SubQ 被强调为“领先于 Transformer”的新架构，不一定意味着 Transformer 会很快退场，但说明厂商已经开始在底层结构上寻找更激进的解法。

配图依据=文章核心新闻点：SubQ 与 Gemma 等模型新闻共同指向大模型底层架构、推理效率和算力成本竞争，电路板视觉更贴近芯片、架构与计算基础设施主线。

同一批资讯里，谷歌也为 Gemma 4 推出 Multi-Token Prediction 推测解码方案，在不改变模型、不降低输出质量的前提下把推理速度最高提升 3 倍，并按 Apache 2.0 协议开源。一个是新架构试图解决超长上下文瓶颈，一个是推理侧优化让本地模型更快，两者放在一起看，说明大模型进入成熟竞争后，“更便宜地跑起来”已经和“更聪明”同样重要。

企业落地会更现实

长上下文和低成本推理对企业应用尤其关键。企业资料往往不是几段文本，而是合同、工单、代码仓库、内部制度、客户记录和历史邮件的组合。如果每次处理都要高价调用顶级模型，很多场景只能停留在演示；如果模型既能读得更长，又能以更低成本完成稳定推理，企业才更容易把 AI 接入日常流程。

这也解释了为什么 Claude、OpenAI、谷歌和一批新团队都在围绕算力、架构和 Agent 工作流加速布局。Claude 一边被曝与亚马逊锁定大规模 AWS 算力，一边继续扩展主动助手能力；OpenAI 则在免费模型、实时语音和企业部署层持续加码。模型能力当然重要，但谁能把能力压到更低单位成本，谁就更可能进入真实生产系统。

Agent 的门槛被重新定义

对 Agent 来说，长上下文的意义不只是“多读几份文件”。一个真正能处理复杂任务的 Agent，需要理解长期项目背景、代码结构、工具调用结果和多轮决策记录。如果上下文窗口足够大但调用成本过高，Agent 仍然会被限制在短任务里；如果底层模型能用更低成本维持长程记忆和推理链路，Agent 才可能更稳定地完成跨系统任务。

这也是 TRAE SOLO、Multica、DeepSeek TUI 等工具受到关注的原因。前者强调移动端、桌面端和网页端协同，后者聚焦多 Agent 协作或本地终端编程体验。应用层看起来在拼产品形态，底层其实仍然离不开模型效率、上下文管理和调用成本。