你让 AI 读一整套项目代码、反复调用工具，连续工作几个小时，它常会遇到两个问题：材料太长，早先的信息装不下；任务太久，中间记录越积越多。inclusionAI 新发布的 Ling-3.1-flash，瞄准的正是这类复杂真实任务。它把 560B 总参数、每个 token 激活 25B 参数和 1M-token 上下文窗口放在一起，规格很醒目。不过，目前信息全部来自官方模型卡，能力描述尚无独立复测支撑。
大模型，但不是每次全员上场
Ling-3.1-flash 是 Ling-3.0-flash 的升级版，也是一个原生混合推理模型。所谓混合推理，是指模型可以在直接回答和展开较长推理之间切换，以适应简单问答与复杂任务。
它采用 Hybrid-linear MoE 架构。MoE，也就是混合专家模型，可以理解为一个拥有许多专业小组的机构：总共有大量参数，但每处理一个 token，只调动其中一部分。token 是模型读写内容时使用的基本单位。Ling-3.1-flash 总参数量为 560B，即 5600 亿；每个 token 实际激活 25B，即 250 亿参数。大体思路是用稀疏激活控制单次计算量，同时保留更大的总体容量。
模型共有 63 层 KDA 和 9 层 Gated MLA，比例为 7:1，另有 4 个 Dense Layers。其专家系统包含 512 个 Routed Experts——由系统按输入选择的专家模块——以及 1 个 Shared Expert，每次激活 8 个专家。官方还列出了 64 个 Attention Heads、4096 Hidden Size 和 157184 Vocabulary Size 等配置，但模型卡没有进一步解释这些设计分别带来了多少收益。
百万上下文，先看“装得下”
1M-token context window，指模型一次最多可以参考 100 万个 token。上下文窗口可以看作工作台：工作台越大，越有机会同时摆下长代码库、大批文档或漫长任务记录。
但“装得下”不等于“每一处都找得准、想得清”。模型卡没有给出百万 token 条件下的检索准确率、推理稳定性或成本数据。因此，这项规格目前只能证明标称容量，不能直接推导出实际长文本质量。
这也承接了本刊 10 月 2 日的报道。当时，560B 总参数、25B 激活参数和百万上下文仍是预告信息；如今模型页面给出了正式架构和运行方式，但不少关键问题依然没有答案。
真正的野心是让智能体工作更久
官方称，新版在通用智能体、搜索、办公生产力、软件工程，以及金融、材料科学等任务上较前代有所改进，并列出 GDPVal-AA V2.1、HealthBench Professional、FrontierSWE、Terminal-Bench 4.0、SWE-bench Pro 等基准。不过，页面没有提供具体分数、对照模型和评测设置，所以这些只能视为官方定性结论，不能写成已经证实的领先。
更值得留意的是 LingCode。它基于开源编码智能体 Pi 构建，是一套让模型调用工具、组织任务和维护上下文的运行框架。官方说，它面向持续数小时、经历数百轮工具调用、还要反复压缩上下文的长程编码任务，并能在部分编码智能体任务上显著提升表现。遗憾的是，具体提升数据没有披露，LingCode 也只是“考虑未来开源”，目前不能算作已开放成果。
部署门槛同样醒目
SGLang 已提供首日支持，包括 MTP（NEXTN）推测解码——先猜出后续 token、再集中验证以加快生成——以及面向 Hopper GPU 的解码优化。官方示例使用 8 张 H200，以 TP8 加 EP8 的方式部署；另给出了 4 张 GB300 的配置。这里的 TP 和 EP 分别把模型计算与专家模块分摊到多张 GPU 上。
这说明运行方案已经相当具体，也直观展示了它面向高端多卡服务器的部署形态。但 8 张 H200 只是示例，并非官方声明的最低要求；模型卡也没有披露权重精度、实际显存占用、吞吐量和部署成本。
局限与未知
- 所有效果与架构信息目前都来自 inclusionAI 官方模型卡，尚缺第三方复测。
- 百万上下文只代表标称长度，极长输入下的质量与经济性仍未知。
- LingCode 尚未承诺开源，模型的许可证和完整技术文档也未在供稿中明确。