跳到内容
FrontierDot

Ling-3.1-flash：560B 参数、25B 激活，这对你的硬件意味着什么

持续更新的时间线 · 最后更新于 · 更新记录共 1 条

每个词元只动用 25B 参数，听起来不多。可全部权重仍然得放在某个地方，而推荐的部署配置是一整个机架的规模。

Ling-3.1-flash 总参数 560B、激活 25B，在 Ling-3.0-flash 之后约十周发布；它需要多 GPU 服务器，所有基准数字都出自作者自己。

读自 2026-10-17 Hugging Face 上 inclusionAI/Ling-3.1-flash 的模型卡；仓库日期来自 Hugging Face 的元数据。所有基准数字均为厂商自报，我们没有复现。

时间线

  1. Ling-3.0-flash 仓库出现在 Hugging Face 上。3.1 的模型卡后来称自己是在这个模型的基础上，对架构和真实任务上的表现做了改进。

    inclusionAI/Ling-3.0-flash (Hugging Face metadata)

  2. Ling-3.1-flash 仓库出现。模型卡把它介绍为面向复杂真实任务、经过升级的原生混合推理模型，总参数 560B，每个词元激活 25B，上下文窗口 1M 词元，并在首日（day-0）就提供了 SGLang 和 vLLM 的部署方案。

    inclusionAI/Ling-3.1-flash model card

从智能体出发的发布，聊天排在后面

Ling-3.1-flash 模型卡的第一段，就交代了作者希望它被用来做什么。他们称它是一个升级后的原生混合推理模型，为复杂的真实任务而设计，举的例子和对话无关：通用智能体、搜索、办公效率和软件工程。介绍里点名的基准也沿着同一条线：办公任务用 GDPVal-AA V2.1，医疗用 HealthBench Professional，软件工程用 FrontierSWE，基于终端的工具使用用 Terminal-Bench 4.0。模型卡还说，模型在金融和材料科学等专业领域也有提升，但没有给出数字。

它的前代很近。Ling-3.0-flash 仓库出现在 8 月 2 日，Ling-3.1-flash 在 10 月 13 日跟上，间隔约十周，模型卡说新模型在旧模型的基础上，改进了架构和真实任务上的表现。对关注开放权重发布节奏的人来说，这个间隔就是新闻本身：一个 560B 参数的模型，在两个多月里改了一版。

读规格表

模型卡的概览表，是模型从口号变成实物的地方。Ling-3.1-flash 是一个混合线性专家混合（MoE）模型：总参数 560B，每个词元激活 25B，63 层 KDA 和 9 层带门控的 MLA，按 7:1 的比例排列，4 层稠密层，512 个路由专家外加 1 个共享专家，每个词元激活 8 个专家，64 个注意力头，隐藏维度 4096，词表 157,184。模型卡没有展开 KDA 和 MLA 这两个缩写，我们也不去猜。这些数字能说明的只是算术：560B 里激活 25B，每个词元只触及约 4.5% 的参数，由 512 个路由专家中的 8 个，加上共享专家来完成。

有一处出入，我们宁可标出来也不想藏着。Hugging Face 页面自己的元数据显示的是 572B 参数，比模型卡的 560B 略高。这个差别在我们能看到的地方都没有解释，所以我们采用模型卡的数字，同时注明平台统计的数值更高。

“激活 25B”说的是速度，与内存无关

混合专家模型的新闻标题里，最容易丢掉的就是这句话。每个词元的计算量跟着激活参数数量走，所以激活 25B 的模型，每个词元的运行成本可以比 560B 的稠密模型低得多。内存却不按这个规律算。路由器可以把下一个词元送给任何一个专家，所以全部专家都得常驻在高速内存里随时待命。权重因此跟着总量走，与激活数量无关。按每个参数 16 比特算，5600 亿个参数在计入 KV 缓存之前大约是 1.1 TB。这是我们自己的算术，不是模型卡里的数字，也解释了下一节的内容。

很长的上下文窗口只会让内存问题更糟。1M 词元的上下文是个很大的说法，留在上下文里的每个词元，都会在权重之外再增加 KV 缓存的内存。模型卡没有给出长上下文使用时的内存数字，所以应当实际测量，不要想当然。对这种体量的任何模型，有一个简单的习惯很管用：下载体积只是下限，不是预算。

推荐的部署配置透露了什么

模型卡推荐的部署路径是 SGLang，它首日（day-0）发布的镜像包含对 Ling-3.1-flash 的支持、基于 MTP 并采用 NEXTN 算法的推测解码，以及针对 Hopper 的解码优化。服务器命令面向 8 × H200，张量并行和专家并行都设为 8；如果是 4 × GB300，则并行度设为 4。卡里补充说，两个可选的环境变量开关，能让 Hopper 上 batch-1 的解码快大约 10%。模型卡链接的一份 cookbook 列出了在 H200、GB300、H800、H100 和 B200 上验证过的方案，另有以 Mooncake 作为第三级缓存的 HiCache、推理开关、工具调用，以及实测的准确率和速度数字。这是一个为数据中心设计的模型该有的样子。

vLLM 这条路线给出的信号同样清楚。模型卡要求你从一个指定分支构建 vLLM，然后以张量并行 8、GPU 显存利用率 0.85 启动服务，开启前缀缓存和专家并行，设定 mamba 缓存模式，加上自动选择工具的开关以及 ling3 工具调用解析器和 ling3 推理解析器，并使用三个 MTP 词元的推测解码。两条路线的采样建议一致：temperature 1.0、top-p 0.95、top-k 20，为获得最佳表现要开启思考模式。

我们的判断很简单：这不是给游戏显卡准备的模型。如果你想为自己打算运行的模型估算内存，有两个习惯有帮助：假定运行时内存比文件更大，并加上你实际使用的上下文长度所需的 KV 缓存。对这个模型来说，更实际的问题是，有没有托管端点以合理的价格提供它。模型卡指向了 OpenRouter，并把 Novita 列为推理提供方，所以托管访问是存在的，只是价格没有写在模型卡里。

作者称它能做什么

模型卡说 Ling-3.1-flash 在有代表性的编程和智能体基准上表现强劲：Terminal-Bench 4.0、SWE-bench Pro、FrontierSWE、GDPVal-AA V2.1、Automationbench、MCP-Atlas 和 SkillsBench 等。页面上的评测区列出了其中几项的成绩：SWE-bench Pro 68.74、Deep SWE 59.7、Terminal-Bench 2.1 81.18、Humanity’s Last Exam 37.44、SWE-bench Multilingual（已解决）88.5、Terminal-Bench 46.03、SkillsBench v1.1 68.7。其中几项在页面上带有星号，页面上我们能读到的文字里没有解释。这些都是厂商自报的数字，我们没有复现，也不应把它们当作与任何其他模型的排名。

模型卡还说，这个模型在 Claude Code、Kilo Code、Qwen Code、Hermes Agent、OpenClaw 等框架里体验良好，这说的是兼容性，与质量无关。它还介绍了 LingCode，一个建立在开源编程智能体 Pi 之上的运行框架，针对要运行数小时、包含数百轮工具调用、需要反复压缩上下文的长程编程任务做了增强。作者说正在考虑开源，这意味着它尚未发布。这个细节容易被忽略，也值得记住：作者描述的长编程任务上最强的成绩，用的是一个你目前还下载不到的框架。

文书部分

模型卡的结尾有一样对模型页面来说不常见的东西：一份公开的训练内容摘要，以 PDF 提供，外加一个文档索引。它说明了涵盖的模型版本、训练内容的范围、摘要的版本和更新日期，并明确表示这份摘要只涉及训练内容披露，不能取代技术文档、使用条款或许可证。我们没有读这份 PDF。页面还显示最近一个月的下载量是 1,904 次，相对模型的体量来说很少，这与一个主要靠托管服务来使用的发布相符。

我们的看法

基准清单可以当作作者的自述，说明他们认为模型强在哪里，也就是智能体编程和终端工作；在把任何一个分数当成定论之前，先等独立的复测。规格表则提醒我们，稀疏性节省的是计算，不是内存。对多数读者来说，模型卡里最有用的数字出在那条服务器命令上：8 × H200 已经说明了这次发布是给谁的。对其他人来说，问题不在于你能不能运行它，而在于有没有人以合理的价格给你提供访问。

继续阅读

全部文章按时间倒序排列在 Front 博客首页。

常见问题

Ling-3.1-flash 有多少参数？

模型卡写的是总参数 560B，每个词元激活 25B，上下文窗口 1M 词元。页面上 Hugging Face 的元数据显示为 572B。

我能在单块 GPU 上运行 Ling-3.1-flash 吗？

消费级 GPU 不行。模型卡推荐的配置是 8 × H200 或 4 × GB300，因为即使每个词元只激活 25B 参数，所有专家的权重也都必须常驻。

Ling-3.1-flash 擅长什么？

作者报告它在智能体编程和终端类基准上成绩强劲，如 SWE-bench Pro 和 Terminal-Bench。这些是厂商自报的数字，我们这里没有独立验证。

更新记录

  • — 首次发布。

来源