蚂蚁开源 Ling-3.1-flash-1019：智能指数涨 3 分，单任务账单涨 48%

10 月 28 日，蚂蚁百灵开源了 Ling-3.1-flash-1019。跑分很好看：Artificial Analysis 智能指数从 41 涨到 44，同规模开放权重模型排第 4。

但同一份评测里还有另一组数字：单任务平均输出 token 涨了 40%，平均成本从 $1.01 涨到 $1.49。

能力涨 3 分，账单涨 48%。这篇不写"国产又开源了一个好模型"，而是从这 1.49 美元出发，一路倒推回架构——这 3 分值不值这 48%，要看你在哪个场景付这笔钱。

零、先看这张账单

把两代模型的账并排放，是最快的切入点：

两代之间只隔了 28 天。

这就是第一个值得注意的点：这不是一次"出新版本"，是一次"同一个底座再压一轮后训练"，而这一轮后训练买了 3 分，代价是 48% 的账单。

三个数字之间的关系，比任何单个数字都重要。下面拆四笔账。

第一笔账：这 3 分是从哪来的

先说清楚 1019 版做了什么——它没有换架构，也没有换底座。

官方给的信息很明确：1019 版和 base 版沿用 Ling-3.1-flash 系列的混合线性 MoE 架构，这次开源的 1019 是面向 Personal Agent 场景进一步后训练的版本，同时开放了后训练前的 Ling-3.1-flash-base 基础权重。

这是两个不同的东西，得分开看：

开 base 权重这件事，比开 1019 更值得关注。 因为 1019 的后训练是冲"个人 Agent"这个场景去的——这个场景的具体形态（跨会话记忆、长程任务调度）和蚂蚁自家产品灵光 2.0 强绑定。如果你的业务形态不一样，1019 的后训练可能不是最优起点，base 才是。

而 1019 的后训练方向也很清楚，它跟产品节奏是咬合的：

• 10 月 27 日，蚂蚁发布灵光 2.0，新增跨会话记忆、长程任务调度、独立云主机
• 10 月 28 日，开源 1019——专门加强"复杂工作流和多步骤任务"的能力

官方说法是：此前发布的 Ling-3.1-flash 已结合灵光等应用的需求和反馈开展对齐训练。

这是一条值得记住的产品-模型协同路径：先有产品跑出真实任务分布，再用这些任务的反馈做后训练，再把后训练的模型开源。比起"先训模型再找场景"，这条路的后训练信号要真实得多。

代价也一样清楚：后训练用的任务分布是灵光的，不是你的。

这就带来一个必须先回答的问题：这 3 分，你的场景能不能拿到？ 不能凭感觉判断，得测。下面是三步评估法，跑一遍大概两小时：

第 ③ 步的算法值得解释一下，因为它经常反转结论：

模型 A：成功率 92%，每任务 $1.49  →  有效成本 = 1.49 / 0.92 = $1.62
模型 B：成功率 85%，每任务 $1.01  →  有效成本 = 1.01 / 0.85 = $1.19

在这个例子中，1019 的有效成本比上一代高 36%，而不是表面上的 48%——因为它把一部分原本要重试的任务一次做对了。重试也是有成本的：一次失败的任务如果重跑一次，实际花了两个 $1.01。

反过来也成立：如果你的场景成功率从 70% 涨到 74%（涨 4 个点），有效成本反而是降的：

旧：1.01 / 0.70 = $1.44
新：1.49 / 0.74 = $2.01   ← 还是涨的

这个例子里涨了 40%。所以结论是：成功率的提升必须真实存在，且幅度够大，才能抵消 token 涨幅。 具体能不能抵消，只有那 20 个任务能告诉你。

一个可以提前预判的信号：如果你的任务形态和"跨会话个人助理"接近——需要记忆、需要多步跟进、需要自己判断下一步做什么——那 3 分大概率能拿到，甚至更多。如果你的任务是"固定输入 → 固定输出"的转换类工作（抽取、格式化、分类），那后训练买的泛化能力对你是无效的，直接看 base 权重更划算。

代价也写在明面上：后训练用的任务分布是灵光的，不是你的。 如果你的场景和"个人助理跨会话干活"差得远，这 3 分你未必拿得到。

第二笔账：为什么 token 会涨 40%

这是全文最关键的一笔，因为它解释了一个反直觉现象——能力提升，往往不是"更聪明"，而是"想得更久"。

每任务平均输出从约 10.4 万 token 涨到约 14.5 万，涨了 40%。这个增幅不能用"输出变啰嗦"来解释。想想看：一个正常问答的回答能有多长？几百到几千 token。14.5 万是什么概念——相当于一本 20 万字中文书的四分之三。

要看懂这个量级，得先明白"输出 token"在 Agent 任务里到底指什么：

一次 Agent 任务（AA 智能指数的计法）

用户提问
  ↓
第 1 轮  模型输出思考 + 工具调用  ← 计入输出 token
         工具返回结果              ← 计入输入 token
  ↓
第 2 轮  模型看到「历史 + 工具结果」重新思考  ← 又一轮输出
         ...
  ↓
第 N 轮  给出最终答案

也就是说，14.5 万 token 不是一次回答的长度，是这整个任务里所有轮次的思考 + 工具调用参数的总和。 单任务 14.5 万 ÷ 假设 20 轮 ≈ 每轮 7000 多 token 的思考。这个数字就非常合理了。

那为什么涨 40%？只有一个解释：后训练把模型训得"更愿意多想"。 更多轮次、更长的推理链、更多次的工具尝试和纠错。

这是一次有意的取舍，不是缺陷。在正确率敏感的 Agent 任务里，"多想一会儿"确实能换来更高的成功率——3 分的智能指数提升就是这么来的。

但账要算清楚：

后训练优化的是"每任务正确率"，不是"每任务成本"。这两件事在 Agent 场景里天然对立。 模型学得越会"再检查一遍"，token 就越多，账单就越贵。而模型的训练目标里，从来没有"省钱"这一项。

这条规律对所有做 Agent 产品的团队都成立：你升级模型版本时，如果只对比跑分，账单会悄悄涨 40%。 这个涨幅不会出现在任何版本公告里，它只出现在你的月度账单和下游的毛利表上。

第三笔账：架构在省，后训练在花

这笔账是最容易被混淆的，因为两个力量方向相反。

先看架构。Ling-3.1-flash 系列的混合线性 MoE 干了两件省钱的事：

这两个设计加起来，让"5600 亿参数"这个体量的推理成本，接近一个 250 亿的稠密模型。

注意 7:1 这个比例。 纯粹换线性注意力会掉能力，纯粹用全注意力则长文本开销爆炸。7 层线性配 1 层全注意力的比例，是在"省算力"和"保能力"之间找的一个工程平衡点。这个比例不是随便定的——它决定了模型在长上下文下的能力衰减曲线，是这一代架构最核心的超参之一。

再看后训练。它干的是相反的事：让每个 token 更贵——不是单价贵，是"需要的 token 变多"。

关键在于这两个力量乘在一起：

单任务总成本 = 每 token 单价 × 每任务 token 数
                ↑                ↑
            架构在压        后训练在推
           （线性注意力、    （更长的思考链、
            稀疏激活）        更多轮工具调用）

架构省下的是乘号左边，后训练花掉的是乘号右边。而这一次，右边涨了 40%，左边没变。

这就解释了一个很常见的误判：看到"混合线性注意力省了多少算力"的架构宣传，就以为推理成本会降。架构优化决定的是"每次计算的效率上限"，但真实账单由"要计算多少次"决定。 后者是后训练和产品形态决定的，跟架构无关。

一个具体的例子：如果 1019 在一个需要反复试错的编码 Agent 里，跑了 30 轮才收敛，那它的架构再省，总成本也高过跑 5 轮就结束的朴素模型。在 Agent 场景，"轮数"是比"单价"更大的成本变量。

第四笔账：单价便宜，不等于总价便宜

看一眼 API 定价，很容易得出"这个模型很便宜"的结论：

这里有一个值得自己算一遍的推算，它能揭示 Agent 任务的真实成本结构。

拿输出单价粗算：14.5 万 token × $0.90/百万 = 约 $0.13。

但 AA 报的单任务成本是 $1.49。差了 11 倍。

这 11 倍的差额去哪了？只能来自输入 token。反推一下（按输入全价 $0.30/M 估算）：

($1.49 - $0.13) ÷ $0.30/百万 ≈ 4.5 百万输入 token
4.5M 输入 ÷ 14.5万 输出 ≈ 31 : 1

输入输出比约 31:1。

这个比例不是异常，它就是 Agent 任务的常态：每一轮都要把完整历史重新送进去，20 轮下来，历史被重复计费 20 次。

由此得到三条实操结论：

结论一：Agent 场景的真实成本由输入主导，不是输出。 看到"输出 $0.90"就估成本，会低估一个数量级。

结论二：缓存读取价 $0.06 是这代模型最重要的一个数字。 它是输入价的 1/5。在 31:1 的输入输出比下，缓存命中率每提一档，省的钱远超任何其他优化。一个粗略估算：如果那 4.5M 输入里有 80% 能命中缓存，成本会从 $1.49 掉到约 $0.50，降 2/3。

结论三："每百万 token 多少钱"是目前最容易被误用的模型对比指标。 因为真实成本 = 单价 × token 数，而 token 数由模型"想多久"决定，不同模型之间差 40% 是常态。两代模型单价一样，实际账单可以差 48%。

所以正确的比价方式是：拿你自己业务里的 10 个真实任务，跑两个模型，比"每个任务跑完花了多少钱"加"成功率"。 前者除以后者，才是可比的价格。

第五笔账：什么场景该用 1019，什么场景别用

把前面几笔账合起来，能划出一条相当清楚的分界。判断标准只有一条：这个任务"想错了"的代价，比"想久了"的代价大吗？

建议用 1019 的场景：

不建议用 1019 的场景：

一个反直觉但实用的建议：如果你的场景是"任务形态稳定、量大、答案有明确判据"，那 1019 不是好选择，但 base 可能是。因为 1019 花钱买的那 3 分，主要花在"泛化到陌生任务"上——如果你的任务不陌生，这 3 分是白付的。

部署：两条路径与三个必须知道的参数

官方模型卡列了 SGLang 和 vLLM 两条部署路径。两个后端都能跑，选择取决于你的技术栈：

三个必须提前算清楚的参数：

① 1M 上下文是"能力上限"，不是"日常配置"。 开启 100 万上下文时，KV cache 的显存占用会随长度线性甚至更快增长。实际生产里，先把 max_model_len 设成业务真实需要长度的 1.5 倍，不要直接拉到 1M。 拉满只会让你的并发数掉到个位数。

② 250 亿激活 ≠ 250 亿权重。 5600 亿总参数的权重文件仍然要全部放进显存（或做专家卸载）。稀疏激活省的是计算，不是显存。按 BF16 粗估，5600 亿参数约需 1.1 TB 权重空间——这必须靠多卡或多机张量并行，不是单机能解决的。

具体不要照抄别人的数字，按你实际下载的权重文件大小 + KV cache 预留算。

③ 缓存命中率要监控，不要假设。 前一条结论说缓存价是 1/5，但那是命中时的价格。未命中就是全价。生产里必须有缓存命中率的监控指标，否则你会以为在省钱，实际一分没省。

怎么验证缓存真的在工作？不要看仪表盘，看账单字段。一次请求的用量对象里会明确区分两类输入：

usage.prompt_tokens                 全部输入 token
usage.prompt_cache_hit_tokens       其中命中缓存的部分
usage.prompt_cache_miss_tokens      未命中的部分

做一个最简单的自检：把同一个前缀的请求连发两次，对比第二次的 cache_hit_tokens 是不是等于第一次的 prompt_tokens。

第三条是最容易踩的：缓存是按实例存的，扩容后新实例上什么都没有。所以命中率曲线在扩缩容时会呈现锯齿状。如果你的架构是"高峰期自动扩 5 个实例"，那么新实例的前几批请求必然是全价——这部分成本要在容量规划时就认下来，而不是等问题发生后再去查。

一个相关的实操建议：前缀的顺序决定命中率。 把变化最慢的内容排最前、变化最快的排最后，是提高命中率最有效的一招，而且它不需要任何配置，只是请求体里字段顺序的问题：

[系统提示]  →  [工具定义]  →  [固定知识库]  →  [对话历史]  →  [本轮用户输入]
   最稳定                                        最易变

许可证是 MIT，可商用、可修改，没有地域限制。这是这代国产开源模型里最宽松的一档，对要私有化部署的团队是好消息。

怎么把涨上去的 40% 省回来

前面几笔账讲的是"为什么贵"。这一节讲"能省回多少，怎么省"。

手法一：思考预算控制——收益最大，风险也最大

后训练把模型训得更愿意"多想"，但并不是每个任务都需要多想。

这一条的收益量级是最大的——如果 14.5 万 token 里有 60% 花在思考上，而你的任务根本不需要，那关掉就是直接省 60%。但风险也在这：关思考一定掉成功率，掉多少得自己测。 建议在自己的 10 个真实任务上做 A/B，记录"成功率"和"每任务成本"两个数，取性价比最高的那一档。

手法二：前缀稳定化——零风险，收益确定

就是上面说的字段顺序问题。把系统提示、工具定义、固定文档全部前置且完全一致，让每一次请求的前缀字节级相同。

这件事的收益有多确定？回到那条 31:1 的输入输出比——输入侧 4.5M token 里，绝大部分是重复的历史上下文。 只要前缀稳定，这部分就能按 1/5 的价格计费。

手法三：任务分流——不是所有任务都配得到 1019

这是最容易被忽略、但效果最直接的一招。

请求进来
  ↓
先用规则/小模型判断：这个任务需要复杂推理吗？
  ├─ 不需要（占比往往 60-80%）→ 小模型 / 更便宜的模型
  └─ 需要                      → 1019

大多数生产系统里，大部分请求是简单的。如果所有请求都走 $1.49 的模型，那 48% 的成本涨幅会均匀地摊到每一笔上——而那些简单任务本来只需要几分钱。

这三招的收益不是相加的，是相乘的。 思考预算砍一半（×0.5）、缓存命中 80%（×0.4）、任务分流掉 70%（总体 ×0.3）——组合起来的节省幅度，远大于单独任何一项。

但也必须说清楚代价：每一招都在拿"确定性"换"成本"。你要接受"某些情况下质量会掉一点"，并且有指标能监控到掉了多少。如果没有这个监控，省下来的钱迟早会以另一种方式还回去。

结论：这次发布真正值得记住的三件事

第一，"能力涨、账单涨"不是这一家的问题，是后训练的固有性质。

1019 用 28 天、一轮后训练，把智能指数推高 3 分，代价是 token 多 40%。这条曲线在可见的未来不会反转——越是主打"长程任务""自主执行"的模型，这个特征越明显。因为让模型"多想"永远是提升正确率最有效的手段。

所以真正的工程能力不在于"选到分数最高的模型"，而在于知道自己的场景该为哪一分付钱。

第二，架构优化和真实成本之间，隔着一个"要算多少次"。

混合线性注意力 7:1、512 专家激活 8 个、250 亿激活——这些设计确实把"每 token 单价"压下来了。但真实账单是"单价 × token 数"，而后一个变量由后训练和产品形态决定。

只看架构宣传就预估成本，会系统性低估一个数量级的输入成本。 这次推算出的 31:1 输入输出比，就是那个被藏起来的数量级。

第三，开 base 权重比开 1019 更有长期价值。

1019 是"为灵光 2.0 定制过的后训练版本"，它的 3 分提升有明确的目标域。对大部分团队来说，base + 自己的领域数据做后训练，可能比直接用 1019 更划算——因为你要的 3 分，和它买的 3 分，大概率不在同一个方向上。

顺带一提：这次发布最容易被忽略的数字不是 44 分，是**“28 天”。上一代 9 月 30 日发布，10 月 28 日就出了升级版。这个迭代节奏说明国产开源模型的竞争，已经从"谁先追平"进入"谁后训练转得更快"——而后训练转得快的直接后果，就是 token 数和账单的持续上涨**。