蚂蚁百灵把 Ling-3.1-flash 的参数摆上台面时，真正值得琢磨的不是 560B 这个总参数，而是那个 25B。激活比例压到 4% 出头，再把上下文窗口顶到 1M，这两件事放在同一个模型里，才是这次发布的核心信息。它瞄准的不是榜单分数，是推理成本这条命脉。
稀疏激活这门手艺，越做越细
512 选 8，分母才是关键
MoE 架构早就不新鲜了。从早期的 8 选 2，到后来的 64 选 2、256 选 8，业界一路在做同一件事——把分母撑大，把分子摁住。Ling-3.1-flash 用的是 512 个路由专家里选 8 个，再加 1 个共享专家。分母翻到 512 的意义在于，模型的总容量可以堆得很高，但每个 Token 走过的计算路径依然很窄。
25B 激活意味着什么？一张推理卡就能扛住大部分请求，部署门槛直接往下掉一个台阶。这对做 to B 生意的团队是实打实的诱惑：你不必为了跑一个 560B 级别的模型去凑一整个机柜。
共享专家不是补丁，是稳定器
那个额外的共享专家容易被忽略，但它承担的角色不轻。路由专家是按 Token 动态挑的，挑得越细，波动越大；共享专家每次都参与计算，等于给整个网络的输出提供一个锚点。这种"动态 + 固定"的搭配，在 DeepSeek 系模型里已经被验证过一轮，如今成了稀疏架构的常见配置。蚂蚁百灵把它写进配置表，说明这套思路在工程上已经趋于成熟，而不是实验性尝试。
线性 Attention 的账，得换个算法
7 层 KDA 配 1 层 Gated MLA
标准 Attention 的计算量随序列长度平方增长，这是长上下文最大的拦路虎。Ling-3.1-flash 的做法是提高线性 Attention 层的占比——7 层 KDA 夹 1 层 Gated MLA。KDA 这类线性注意力机制把复杂度压到接近线性，代价是表达能力的损失；而 Gated MLA 这类带门控的注意力层负责把关键信息捞回来。
7 比 1 这个比例很讲究。线性层太多，模型在长依赖上的精度会掉；注意力层太多，成本又压不下来。蚂蚁百灵显然是在这两端之间反复找过平衡点才定下这个配比。
1M 上下文，是成本问题不是技术问题
把窗口做到 1M，技术上并非做不到。真正难的是让 1M 上下文跑起来不心疼——每一次推理的显存占用、每一百万 Token 的账单，都是硬约束。混合线性架构的意义正在这里：它让长上下文从"能跑"变成"跑得起"。对做代码仓库级理解、长文档分析、多轮 Agent 记忆的团队来说，这是能直接换算成钱的改进。
flash 这个后缀，透露了什么
速度优先，但不止于速度
蚂蚁百灵给模型起名 flash，指向很明确：快。但快的方式不止一种。可以让模型变小，也可以让模型变大而只激活其中一小块。Ling-3.1-flash 选了后者——总参数照样堆到 560B，靠稀疏化和线性注意力把每个 Token 的实际开销压下来。这条路更难走，天花板也更高。
从产品定位看，这个模型更像是冲着高并发、长输入、低延迟的场景去的。它不追求单次对话的极致智能，追求的是在真实业务流量下能不能稳住。
国产模型的路线分歧正在显形
把 Ling-3.1-flash 放到当前的时间点上看，会发现国产大模型在架构选择上已经开始分叉。有的往极致稠密走，用规模换能力；有的往稀疏加线性的方向走，用结构换效率。蚂蚁百灵显然站在后一阵营，而且把稀疏比例和线性层占比都推到了比较激进的位置。这种选择短期内在通用榜单上未必占便宜，但在成本和吞吐这两项上，账会算得越来越清楚。
该盯的不是参数表，是落地数据
架构漂亮不等于跑得漂亮
7 层 KDA 加 1 层 Gated MLA、512 选 8 加 1 个共享专家——这套配置在纸面上是自洽的。但混合线性架构在超长序列上的实际精度衰减曲线、稀疏路由在训练后期的负载均衡情况、1M 窗口下的真实吞吐，这些都要等第三方复现和线上数据出来才能下判断。架构设计是一回事，工程调优是另一回事，两者之间的差距，行业里已经见过太多次。
谁最该关注这个模型
如果你的业务里有大量长文档处理、代码库级检索、多轮 Agent 记忆这类需求，同时又被现有模型的推理账单压得难受，Ling-3.1-flash 这组数字值得认真算一遍。它给出的不是能力上限的承诺，是单位成本下的吞吐承诺。在模型能力逐渐趋同的当下，后者的分量只会越来越重。
蚂蚁百灵这次没有把力气花在讲能力故事上，而是把参数结构、激活比例、注意力配比这些硬指标直接摊开。这种表达方式本身就说明，他们想吸引的是会看账本的人。
