蚂蚁百灵发布 Ling-3.1-Flash：560B 总参数，1M 上下文，瞄准 Agent 与编程

蚂蚁百灵今天（2026 年 9 月 30 日）发布了新一代模型 Ling-3.1-Flash。它拥有约 560B 总参数，但每个 Token 平均只激活约 25B 参数，原生上下文窗口为 256K，最高可扩展至 1M，重点优化通用智能体、搜索、办公自动化和软件研发任务。

Ling-3.1-Flash 是一款面向长程任务执行的 MoE 模型，核心思路是用更大的专家容量承载复杂能力，再通过稀疏激活控制单次推理成本。 这也是它和传统 Dense 模型最重要的区别：模型总容量接近 560B，并不意味着每次生成都要承担 560B 参数的计算量。

蚂蚁百灵并没有把这次更新包装成单纯的参数竞赛。真正值得关注的是，Ling-3.1-Flash 把大模型的竞争重点从“能不能回答”继续推向“能不能连续完成一项工作”。对于开发者来说，这意味着模型不仅要写出一段代码，还要能理解项目上下文、调用工具、处理报错、修改文件，并在多轮操作后交付一个可运行的结果。

560B 总参数，但实际计算量只有 25B 级别

MoE（Mixture of Experts，混合专家）是一种将模型拆分为多个专家网络、并为每个 Token 动态选择部分专家参与计算的架构。 与所有参数都参与推理的 Dense 模型相比，MoE 可以在扩大模型知识容量的同时，减少单次请求需要执行的参数数量。

Ling-3.1-Flash 的约 560B 是总参数规模，约 25B 是每个 Token 的激活参数规模。简单理解，560B 更像是一座拥有大量专业部门的公司，而 25B 代表每次处理具体问题时真正被调动的团队。模型可以在不同任务间切换专家组合，推理时却不必让全部参数同时工作。

| 模型 | 总参数 | 激活参数 | 上下文能力 | 主要定位 | |---|---:|---:|---|---| | Ling-3.1-Flash | 约 560B | 约 25B/Token | 原生 256K，最高 1M | Agent、编程、搜索、办公自动化 | | Ling-3.0-Flash | 124B | 约 5.1B | 原生 256K，可扩展至 1M | 高效 Agent、工具调用、长程任务 | | Ring-2.6-1T | 约 1T 级 | 未披露统一口径 | 面向复杂推理任务 | 上一代旗舰思考模型 |

从参数比例看，Ling-3.1-Flash 的激活规模约为总参数的 4.5%。这并不能直接等同于最终成本或速度，因为推理还会受到专家路由、注意力结构、KV Cache、并行策略、量化方式和硬件利用率影响，但它至少说明模型设计目标很明确：在保持更大模型容量的同时，把单 Token 计算压到相对可控的水平。

这条路线对 Agent 尤其重要。Agent 的成本不是只由一次回答决定，而是由多次思考、检索、工具调用、观察结果和修正动作累积而成。一个任务可能要经历几十轮模型调用。如果每轮都使用完整大模型，系统很容易在延迟和费用上失去实用性；如果激活参数足够低，模型就有机会在相同预算下完成更多轮交互。

1M 上下文的价值，不只是塞进更多文本

上下文窗口是模型一次能够读取并参与推理的 Token 总量，1M 上下文意味着模型理论上可以在单次任务中处理约百万 Token 的文档、代码、对话历史或工具结果。 对长文档问答来说，这相当于把模型从“每次只看一章”推进到“可以同时阅读整本资料”；对软件工程来说，则更接近一次性理解大型代码仓库。

Ling-3.1-Flash 的免费体验期服务长度为 256K，免费体验持续两周。蚂蚁百灵表示，免费体验结束并转为付费服务后，计划开放完整的 1M 上下文，并同步推进模型开源和性能更新。

这里需要区分两个概念：模型支持 1M 上下文，不代表所有任务都应该把 1M Token 全部塞进去。长上下文更像一个更大的工作台，而不是自动变强的记忆。输入内容越长，检索噪声、重复信息和无关历史也越多。真正影响效果的，仍然包括模型能否定位关键信息、保持跨段落一致性，以及在长程任务中正确利用早期结论。

对于开发者，1M 上下文的实际价值主要体现在四类场景：

• 大型代码仓库理解：同时提供目录结构、核心模块、测试代码、构建日志和需求说明，减少反复截取上下文的工作。
• 长周期 Agent 任务：保留更完整的工具调用轨迹、网页检索结果、文件修改记录和中间决策。
• 复杂文档审查：将合同、制度、审计材料和附件放在同一任务中，适合做交叉比对和风险定位。
• 研究与知识整理：处理论文、实验记录、数据说明和阶段性结论，减少多次摘要造成的信息损失。

不过，1M 上下文也会提高系统工程要求。长上下文任务会消耗更多显存和 KV Cache，首 Token 延迟、并发能力和实际服务成本都可能受到影响。蚂蚁百灵先以 256K 形式提供免费体验，再在付费阶段开放 1M，实际上也说明完整长上下文服务需要更高的综合资源投入。

从“会生成代码”转向“能完成软件任务”

代码 Agent 是能够理解软件项目状态、调用开发工具并根据执行反馈持续修改代码的模型系统。 它和普通代码补全的区别在于，后者主要预测下一段代码，前者则需要围绕一个目标完成多步操作。

蚂蚁百灵表示，Ling-3.1-Flash 在研发过程中持续围绕软件研发和通用智能体进行优化。这个方向的重点不只是代码基准分数，还包括工具调用稳定性、指令遵循、错误恢复和长任务中的状态管理。

一个真实的编程任务通常包括：理解需求、扫描仓库、判断修改范围、编辑多个文件、运行测试、阅读报错、定位回归问题，再次修改并验证。模型只要在其中一个环节错误地调用工具，或者忘记前面已经确认的约束，最终结果就可能无法使用。

因此，Ling-3.1-Flash 的“Flash”定位并不只是追求更快输出。官方资料显示，Ling 系列支持思考和非思考模式切换：复杂任务可以开启思考，批量生成、低延迟响应或高并发场景则可以关闭思考。官方还给出了最高 1000 tokens/s、首 Token 延迟低于 100ms 的服务指标，但这类数据通常取决于硬件、批处理大小、输入长度和服务端部署方式，不能简单理解为所有用户都能稳定获得这一速度。

对编程 Agent 来说，速度的价值很直接。模型在一次工具调用后越快拿到结果，就越能在单位时间内完成更多“观察—决策—执行—验证”循环。代码任务中，模型输出速度并非唯一指标，但较低延迟可以明显改善交互体验，尤其适合实时修改、终端操作和多轮调试。

工具调用稳定性，决定 Agent 能否进入生产环境

工具调用稳定性是指模型能否持续、准确地按照约定格式选择工具、填写参数，并根据工具返回结果决定下一步动作。 这是 Agent 从演示走向生产时最容易暴露问题的环节。

普通问答中，模型偶尔答错一个细节，用户还可以追问；但在 Agent 工作流中，错误可能会被放大。一次错误的文件路径会导致后续修改全部失效，一次错误的数据库查询可能污染分析结论，一次没有等待任务完成的操作可能让模型基于过期状态继续执行。

蚂蚁百灵在 Ling 系列资料中强调了工具调用和强化学习训练。其思路是通过更严格的任务检查，提升长程工具调用过程中的指令遵循能力。对于编程、搜索和办公自动化场景，这类能力比单纯增加回答长度更重要。

但需要保持现实判断：模型声称具备 Agent 能力，不等于它可以直接替代成熟的工作流编排系统。生产环境仍然需要权限控制、工具沙箱、超时重试、状态持久化、人工确认和结果审计。Ling-3.1-Flash 更适合作为高能力执行核心，周围仍需要完整的工程系统约束它的行动边界。

与 Ling-3.0-Flash 相比，升级重点在哪里

Ling-3.1-Flash 相比 Ling-3.0-Flash 的主要升级，体现在模型容量、激活规模和面向长程任务的综合能力上，而不是简单扩大上下文数字。

Ling-3.0-Flash 于 2026 年 7 月发布，总参数约 124B，激活参数约 5.1B，原生支持 256K 上下文，并可扩展至 1M。蚂蚁百灵当时强调，该模型围绕 Agent、工具调用和真实生产力任务优化，并公布了 MiniAppBench 25.3% 的通过率；该评测要求模型根据一句需求生成完整可用的应用，参与评测的 16 个主流模型平均通过率为 17%。

Ling-3.1-Flash 将总参数提升到约 560B，激活参数提升到约 25B。单看激活规模，它并不是上一代的简单放大版，而是选择用更大的单次计算预算换取更强的复杂任务处理能力。对于简单分类、批量改写和低难度抽取任务，25B 激活未必有明显优势；但对于需要规划、工具调用、代码修改和结果验证的任务，更高的激活规模可能带来更强的推理余量。

| 对比维度 | Ling-3.0-Flash | Ling-3.1-Flash | |---|---|---| | 发布时间 | 2026 年 7 月 24 日 | 2026 年 9 月 30 日 | | 总参数 | 124B | 约 560B | | 激活参数 | 约 5.1B | 约 25B | | 原生上下文 | 256K | 256K | | 最高上下文 | 1M | 1M | | 重点能力 | Agent、工具调用、长程任务 | Agent、编程、搜索、办公、科研 | | 开放计划 | 后续开源 | 付费服务阶段计划开源 |

这个升级也带来一个需要验证的问题：25B 激活参数能否在速度、价格和并发量上保持 Flash 系列的优势。模型参数越大，服务端部署和通信压力通常越高，即使采用稀疏激活，也不能保证所有负载下都比更小的模型更便宜。最终竞争力要等正式服务价格、实际吞吐、长上下文延迟和开源权重发布后才能判断。

对开发者意味着什么

对开发者而言，Ling-3.1-Flash 最值得测试的不是普通聊天，而是完整任务链路。可以优先关注以下几类用法：

1. 长代码库修改：给出仓库结构、构建方式和验收标准，测试模型是否能跨文件完成修改并通过测试。
2. 检索增强 Agent：让模型同时处理搜索结果、网页内容和历史任务，观察它能否过滤重复信息并引用正确证据。
3. 办公自动化：将表格、邮件、会议纪要和内部规则放入同一工作流，测试它能否完成分类、提取、汇总和复核。
4. 数据审查：提供大批量结构化与非结构化数据，关注模型是否能保持字段一致性、发现异常并解释判断依据。
5. 科研辅助：让模型处理论文、实验记录和材料数据，验证它能否区分原始事实、推测结论与不确定信息。

测试时不要只记录最终答案是否正确，还应记录首 Token 延迟、完整生成速度、工具调用成功率、重试次数、上下文长度、任务完成率和人工修正时间。对于 Agent，任务完成率通常比单轮问答的主观观感更有参考价值。

免费体验值得用，但别把免费等同于长期成本

蚂蚁百灵计划为 Ling-3.1-Flash 提供两周免费体验，体验期间服务长度为 256K。这个安排对开发者来说是一个低门槛测试窗口，足以验证代码 Agent、长文档分析和多轮工具调用等核心能力。

但免费期的测试结果不能直接推导出上线后的成本。第一，256K 和 1M 上下文的资源消耗不同；第二，免费体验期间的并发限制、排队策略和服务规格可能与正式商业服务不同；第三，Agent 任务的真实消耗取决于工具调用轮数，而不是单次输入长度。

更稳妥的评估方式，是准备一组固定任务集，分别记录短上下文、长上下文、开启思考和关闭思考时的效果，再与现有模型进行同口径对比。尤其要测试失败恢复：如果工具返回错误、代码无法编译、检索结果冲突，模型能否识别问题并采取正确的下一步动作。

结论：大模型竞争进入“智能密度”阶段

Ling-3.1-Flash 的发布，说明国内模型厂商仍在沿着“更大总容量、更低激活比例、更长上下文、更强 Agent 执行”的路线推进。560B 总参数和 25B 激活参数给了它更大的能力上限，1M 上下文则为大型代码库、长文档和长期任务提供了基础设施。

但参数和上下文都不是结果本身。Ling-3.1-Flash 最终能否成为开发者愿意长期使用的模型，取决于四个指标：复杂编程任务的完成率、长程工具调用的稳定性、1M 上下文下的实际延迟，以及正式服务后的价格和并发能力。

我的判断是，Ling-3.1-Flash 更像一款为 Agent 工作流准备的高规格基础模型，而不是面向所有场景的通用“聊天模型”。简单问答和批量文本处理未必需要 25B 激活参数，但对于代码仓库级修改、复杂搜索、办公协作和科研资料整理，它的模型容量与上下文设计具备明确吸引力。两周免费体验期适合用来验证任务完成能力；真正的行业竞争，要等 1M 上下文正式开放、模型开源和完整性能数据发布后才会开始。

参考来源

• IT之家：蚂蚁百灵发布 Ling-3.1-flash 模型 —— 提供 Ling-3.1-Flash 的发布时间、总参数、激活参数、上下文窗口及免费体验安排。
• 蚂蚁百灵 Ling-3.0-Flash 介绍 —— 介绍 Ling 系列上一代模型的定位与技术路线，可用于理解 Ling-3.1-Flash 的迭代背景。
• Ling-3.0-Flash 发布信息 —— 作为 Ling 系列 Agent 能力、长上下文和模型演进方向的公开讨论入口。