蚂蚁开源 Ling-3.0-tiny，7.9B MoE 把推理搬到 Mac 上

8月11日，蚂蚁百灵在 Hugging Face 开源了轻量级混合推理模型 Ling-3.0-tiny。它的总参数量为 7.9B，但每个 Token 实际只激活约 1.3B 参数，并提供 BF16、FP8、INT4 三种权重版本，目标不是继续堆大模型规模，而是把更低成本的推理能力带到个人电脑上。

Ling-3.0-tiny 是一款面向本地部署的稀疏 MoE 混合推理模型。 官方披露，该模型已经在英伟达 DGX Spark、Apple Silicon MacBook 和 Mac mini 等设备上完成验证；在搭载 M4 Pro 芯片的 MacBook 上，推理速度约为 86—90 Token/s，在 8K 上下文长度下峰值内存占用约 8.34 GiB。

这个定位很明确：它不打算和数百亿、数千亿参数的云端旗舰模型正面比拼通用能力，而是瞄准本地代码助手、文档问答、结构化信息提取和轻量级多步骤推理等场景。对开发者来说，真正有吸引力的地方也不只是“7.9B”这个数字，而是它试图在 模型能力、响应速度、内存占用和本地隐私 之间做一个更实际的平衡。

参数不大，但不是传统意义上的 1.3B 模型

稀疏 MoE 是一种只激活部分专家参数的模型架构。 Ling-3.0-tiny 的总参数量为 7.9B，意味着模型完整权重的规模接近 80 亿参数；但在生成每个 Token 时，路由机制只选择一部分参数参与计算，单 Token 激活参数量约为 1.3B。

这两个数字需要分开理解。总参数量更多决定模型需要存储多少权重，激活参数量则更接近单步推理时的计算负担。可以把它看成一座拥有 128 个专科诊室的医院：模型里保留了全部诊室，但每个问题只会被分诊到其中一小部分，而不是让所有医生同时参与会诊。这样做有机会在保留较大模型容量的同时，降低每一步的计算量和延迟。

不过，MoE 并不意味着它可以像 1.3B dense 模型一样轻松运行。完整权重仍然需要加载或映射到内存，路由、专家调度和内存访问也会带来额外开销。因此，Ling-3.0-tiny 的优势更准确地说是：在接近 8B 总参数容量的前提下，将每 Token 计算量压缩到约 1.3B 激活规模，而不是把一个 7.9B 模型完全变成了 1.3B 模型。

按照官方给出的 8K 上下文峰值内存数据，M4 Pro MacBook 运行该模型时约占用 8.34 GiB。这个数字对拥有 16GB 或 24GB 统一内存的 Apple Silicon 设备比较友好，也意味着本地用户不一定需要独立显卡才能尝试。但实际可用性仍取决于权重精度、推理框架、上下文长度、KV Cache 管理以及系统后台占用，不能简单把 8.34 GiB 当作所有配置下的固定内存需求。

KDA 与 MLA 按 3:1 交替，重点是降低长上下文成本

混合线性架构是将不同注意力机制组合到同一个模型中，以兼顾长上下文效率和信息建模能力。 Ling-3.0-tiny 采用 KDA 与 MLA 按 3:1 比例交替堆叠的设计。

其中，KDA 即 Kimi Delta Attention，可以理解为一种更强调线性计算效率的注意力机制；MLA 即 Multi-Head Latent Attention，中文通常称为多头潜在注意力，核心思路是通过潜在表示压缩注意力相关状态，减少长上下文推理时的缓存和计算压力。

传统 Transformer 注意力机制的主要问题之一，是上下文变长后，计算与缓存开销会快速上升。对于本地设备来说，瓶颈往往不是模型能不能回答问题，而是聊天记录一长，内存开始吃紧，生成速度持续下降。KDA 和 MLA 的混合，实际上是在尝试把不同注意力机制的优点拆开使用：多数层采用更高效的线性注意力，少数层保留更强的全局信息交互能力。

3:1 的交替比例也透露出一个工程取舍。模型并没有完全押注某一种注意力机制，而是用四层为一个节奏，其中三层偏向效率，一层承担更充分的信息混合。这样做的目的不是让每一层都做到最强，而是控制整个网络的平均计算成本，同时避免长文本建模能力过度缩水。

对于本地部署用户，这类结构比单纯宣传上下文窗口上限更有意义。因为真正影响体验的，往往是模型在 4K、8K 或更长上下文下是否还能维持稳定速度，以及 KV Cache 是否会把设备内存迅速占满。官方目前披露了 8K 上下文下约 8.34 GiB 的峰值内存占用，但尚未在参考资料中给出更长上下文下的完整曲线，开发者仍需要结合自己的推理框架实测。

128 个路由专家：容量与成本的另一种折中

路由专家是 MoE 中负责处理不同类型输入的稀疏前馈网络分支。 Ling-3.0-tiny 的 FFN 部分包含 128 个 routed experts，也就是 128 个可被路由器选择的专家模块。

专家数量越多，并不自动等于模型能力越强。关键还在于训练数据、路由策略、每个 Token 选择多少专家，以及不同专家之间是否形成了有效分工。128 个专家带来的主要价值，是给模型提供更多参数容量和更细的功能分工；而稀疏激活则避免每次推理都把这 128 个专家全部算一遍。

在实际任务中，某些专家可能更擅长代码模式，某些专家偏向自然语言表达，另一些专家可能承担数学或结构化推理。理想状态下，路由器会把输入分发给最合适的专家。但如果路由不稳定、专家负载不均，或者大量请求集中到少数专家，理论上的计算优势就可能被调度开销抵消。

这也是 Ling-3.0-tiny 后续最值得观察的地方：它在单机推理上是否真的能把 MoE 的稀疏性转化为速度优势。尤其是在 Apple Silicon 这类统一内存架构上，计算单元并不是唯一瓶颈，权重访问、专家切换和内存带宽同样会影响 Token 生成速度。

快速响应与多步骤推理，覆盖两种本地使用方式

混合推理模型是同时提供低延迟回答和更深层多步骤推理模式的模型。 Ling-3.0-tiny 支持快速响应模式和多步骤推理模式，说明它并非只把本地部署当作聊天功能，而是试图覆盖“马上给答案”和“花更多计算完成复杂任务”两种使用方式。

快速响应模式适合代码补全、命令解释、短文本改写、即时问答等任务。这类场景更在意首 Token 延迟和连续输出速度，用户通常不希望模型为了一个简单问题进行长时间思考。

多步骤推理模式则更适合数学题、代码调试、任务拆解和需要多轮验证的工作流。它的代价是输出前可能需要更多计算，响应时间也可能更长。对于本地模型而言，这种模式的价值在于：用户可以用设备本地算力换取更完整的推理过程，而不必把敏感代码、企业文档或个人资料上传到远程服务。

但需要注意，官方目前公布的是模式支持和设备速度，并没有在参考资料中提供 Ling-3.0-tiny 与 Qwen、Llama、Gemma 或其他同尺寸模型在代码、数学、中文理解、长上下文等基准上的横向成绩。因此，现阶段更适合把它看作一款 部署效率导向的模型上新，而不是已经被公开数据证明全面领先的 8B 级模型。

三种权重版本，分别对应不同硬件取舍

Ling-3.0-tiny 提供 BF16、FP8 和 INT4 权重版本。不同精度版本的核心区别，是用更少的数值位宽换取更低的显存或内存占用，但通常需要在精度、兼容性和推理速度之间做权衡。

| 权重版本 | 主要特点 | 更适合的场景 | 需要注意的问题 | |---|---|---|---| | BF16 | 数值精度相对完整，权重占用较高 | 有较大显存或统一内存的设备、质量优先测试 | 内存压力更高，对硬件和框架支持要求更高 | | FP8 | 以 8 位浮点表示权重，兼顾压缩与数值范围 | 支持 FP8 的新一代 GPU 或服务端设备 | 不同硬件、推理框架的支持程度可能不同 | | INT4 | 以 4 位整数压缩权重，内存占用最低 | Mac mini、轻薄本、低显存 GPU 的本地推理 | 量化误差可能影响复杂推理和代码任务表现 |

量化是将模型权重从高精度数值压缩为低位宽表示的技术。 对本地用户而言，INT4 版本通常是最容易落地的选择，尤其适合内存有限的 Mac mini 或普通消费级显卡；BF16 则更适合先确认模型原始表现，FP8 位于两者之间，更多取决于硬件和软件栈是否成熟。

不过，不能只看权重文件大小判断最终体验。推理时还需要为 KV Cache、运行时缓冲区、专家调度和上下文内容预留空间。上下文越长，额外内存占用通常越高；如果同时运行浏览器、编辑器和其他本地模型，实际可用内存也会明显低于设备标称值。

86—90 Token/s：Mac 本地速度已经够用，但要看任务类型

在 M4 Pro MacBook 上，Ling-3.0-tiny 的推理速度约为 86—90 Token/s。Token/s 是模型每秒生成的文本片段数量，常用来衡量连续输出速度，但不等同于完整请求延迟。

这个速度对交互式使用已经相当充裕。普通中文文本中，一个 Token 不一定对应一个汉字，实际换算会受到分词方式影响；但以体验而言，86—90 Token/s 足以让短回答近似即时显示，代码补全也不会明显拖慢编辑节奏。对比云端模型时，还需要把网络往返、排队和首 Token 延迟纳入考虑，本地推理在断网或隐私敏感场景下尤其有优势。

但连续生成速度并不能说明模型在所有任务上都更快。一个复杂问题如果触发多步骤推理模式，可能需要更长的准备时间；较长输入还会增加提示词预填充阶段的耗时。换句话说，86—90 Token/s 更像是模型进入生成阶段后的“跑速”，而不是从点击发送到最终答案的总耗时。

同时，官方给出的数据是在 M4 Pro MacBook 上取得的，不能直接外推到所有 Apple Silicon 设备。M4、M4 Pro、M4 Max、不同内存容量的 Mac mini，以及不同版本的推理框架，都可能带来差异。DGX Spark 的具体吞吐、延迟和显存占用数据，参考资料中也没有进一步展开，因此开发者在选型时仍应以自己的设备实测为准。

它最适合哪些人？

Ling-3.0-tiny 的第一批用户，大概率不是追求排行榜最高分的人，而是希望在本地稳定运行一个“够聪明、够快、成本低”的模型的开发者和深度用户。

• 本地代码助手：在编辑器中完成函数补全、解释报错、生成测试用例，不上传代码仓库。
• 个人知识库问答：配合本地文档检索，对笔记、PDF、项目文档进行摘要和问答。
• 轻量级 Agent：执行任务拆解、调用本地工具、生成结构化结果，但不承担高风险自动决策。
• 离线设备：在网络不稳定或数据不宜外传的环境中进行文本分析和内容处理。
• 模型开发与评测：利用 BF16、FP8、INT4 三种版本，对比不同量化精度和推理框架的实际表现。

它不太适合的场景也很明确：需要顶级复杂推理、极长上下文、强视觉理解、严苛事实准确率，或者希望直接替代最强云端模型的任务。Ling-3.0-tiny 的优势是效率和可部署性，不是参数规模或公开基准上的绝对统治力。

和同尺寸本地模型相比，优势在“结构与设备适配”

当前本地模型市场已经从“能不能跑起来”进入“能不能在普通设备上稳定工作”的阶段。7B—9B 级模型是一个重要甜蜜点：它们比 1B—3B 模型拥有更强的语言和代码能力，又比 30B 以上模型更容易在个人设备上运行。

Ling-3.0-tiny 的差异化并不只是参数量，而是把几项设计放在了一起：7.9B 总参数、1.3B 激活参数、128 路由专家、KDA 与 MLA 的混合注意力，以及快速响应和多步骤推理模式。它更像是在做一台经过调校的本地推理设备，而不是单纯发布一个缩小版大模型。

当然，这种路线的最终效果高度依赖软件生态。模型是否能顺利转换为主流格式，是否被 llama.cpp、MLX 或其他 Apple Silicon 推理框架支持，MoE 专家路由是否能被充分优化，都会决定用户实际拿到的是 90 Token/s，还是一个需要反复调参的实验项目。官方已经验证 MacBook、Mac mini 和 DGX Spark，这是一个积极信号，但生态兼容性仍需要社区进一步补齐。

OpenAI Hub 观点：本地模型的竞争，正在从参数转向“每瓦性能”

蚂蚁百灵这次发布 Ling-3.0-tiny，最值得关注的不是又多了一个 8B 左右模型，而是它把竞争焦点进一步推向了 每瓦性能、每 GB 内存能完成多少有效工作，以及本地部署的实际交互体验。

对普通用户来说，7.9B 总参数和 1.3B 激活参数的组合，意味着模型可能在不追求庞大硬件的情况下获得更高的容量效率；对开发者来说，BF16、FP8、INT4 三种权重则提供了从质量验证到低成本落地的选择空间。尤其是在 M4 Pro MacBook 上达到约 86—90 Token/s、8K 上下文峰值内存约 8.34 GiB，这组数据已经足以让它进入“值得亲自部署测试”的名单。

但现阶段不宜过度拔高。没有公开的系统基准、长上下文曲线和与主流竞品的统一评测，就不能据此判断它在综合能力上领先。更合理的判断是：Ling-3.0-tiny 是一款针对本地低成本推理做了明确工程取舍的开源模型，速度和硬件适配是卖点，通用能力上限则需要社区实测。

如果你手里有 M 系列 Mac、DGX Spark 或其他支持低精度推理的设备，这款模型值得优先测试 INT4 和 BF16 两个版本：前者观察实际部署门槛，后者观察模型能力上限。对于希望把模型放进桌面应用、离线工具或个人 Agent 的开发者，它比又一个只强调参数规模的模型更有现实意义。