刚开源就冲上魔搭第2！Ling-3.1-flash 发布24小时全解读：560B MoE、1M上下文、限时白嫖

2026 年 9 月 30 日，蚂蚁百灵团队正式发布 Ling-3.1-flash：约 560B 总参数、每 Token 仅激活 25B 参数的混合线性 MoE 架构，官方宣称上下文窗口上限达 1M Token，同时宣布"限时两周免费体验"。发布后不到 24 小时，该模型便冲上 ModelScope（魔搭社区）热门榜单第 2 位，社区随即涌现大量接入实测与部署教程。本文基于 ModelScope / Hugging Face 上架的官方权重仓库（即 hf_mirrors/inclusionAI/Ling-3.1-flash），逐层拆解这批参数的真正含义、源码中的架构证据，以及"限时免费"这一定价打法背后的商业逻辑。

一、发布 24 小时：时间线、热度与首批实测反馈

先对齐时间线：

• 2026-09-30：百灵官方发布 Ling-3.1-flash，公布 560B 总参数 / 25B 激活参数、1M 上下文窗口上限，并开启为期两周的免费体验；
• 2026-09-30 前后：模型权重与推理服务同步上架 ModelScope 与 Hugging Face（仓库提交时间戳显示最新更新为 2026-10-15），OpenRouter 同步提供接入入口；
• 发布次日：模型热度迅速攀升至魔搭社区榜单第 2 位；
• 2026-10-14：社区开始出现面向"免费期实测"的接入调优文章，覆盖信息抽取、代码生成、长文本摘要三类任务，以及 JSON 输出稳定性、响应延迟波动、token 级成本测算与免费期迁移预案等内容。

从社区实测反馈看，开发者关注的核心不是 benchmark 分数，而是三个工程问题：免费期结束后的迁移成本、长上下文下的推理延迟、以及 MoE 路由在真实业务负载下的稳定性。这恰恰说明这次发布的定位不是"刷榜模型"，而是"面向 Agent 与生产场景的基座模型"。

二、560B / 25B / 1M 到底指什么：从仓库拆解真实架构

2.1 总参数 560B，激活 25B：MoE 的"规模"与"成本"分离

Ling-3.1-flash 是一个 Hybrid-linear MoE（混合线性专家混合）模型。所谓 560B 总参数，指全部专家、注意力、嵌入层权重加总；而 25B 激活参数，指每个 Token 前向推理时真正参与计算的权重量。后者才是决定推理算力成本与延迟的关键数字。

从 config.json 可以读出完整专家配置：

"num_experts": 512,
"num_shared_experts": 1,
"num_experts_per_tok": 8,
"first_k_dense_replace": 4,
"num_hidden_layers": 72,
"layer_group_size": 8,
"topk_method": "noaux_tc",
"score_function": "sigmoid",
"routed_scaling_factor": 2.5

也就是说：512 个路由专家 + 1 个共享专家，每个 Token 仅激活其中 8 个专家，且前 4 层使用稠密 MLP（first_k_dense_replace=4）。路由算法采用 noaux_tc 分组 Top-K——在 modeling_bailing_moe_v3.py 的 BailingMoeV3Gate.group_limited_topk 中可以看到实现细节：先把 512 个专家分成 8 组，每组内部取 Top-2 得分求和选出 topk_group=4 组，再在选中的组内做 Top-8，配合 sigmoid 打分与 routed_scaling_factor=2.5 的缩放，最终权重归一化输出：

group_scores = scores.view(num_tokens, self.n_group, -1).topk(2, dim=-1)[0].sum(dim=-1)
group_idx = torch.topk(group_scores, k=self.topk_group, dim=-1, sorted=False)[1]
...
masked_scores = scores.masked_fill(~score_mask.bool(), float('-inf'))
probs, top_indices = torch.topk(masked_scores, k=self.top_k, dim=-1)

这种"先选组、再选专家"的两级路由，配合 norm_topk_prob 与 sigmoid 路由分数，是 MoE 训练中抑制路由坍缩（router collapse）的常见工程手段，也是 560B 规模下仍能把激活参数压到 25B 的关键。

2.2 混合线性架构：63 层 KDA + 9 层 Gated MLA（7:1）

Ling-3.1-flash 的注意力部分并不全是传统 Transformer 自注意力，而是 "线性注意力 + 多头潜在注意力（MLA）"的混合：

• 63 层 KDA（Kimi Delta Attention，线性注意力变体）：短卷积 + 门控线性递归，显存占用与序列长度基本无关，是"1M 长上下文"的物理基础；
• 9 层 Gated MLA（带门控的多头潜在注意力）：负责局部高精度建模，通过低秩 KV 压缩降低 KV Cache 开销。

在 modeling_bailing_moe_v3.py 的 BailingMoeV3DecoderLayer 中，层类型分配逻辑一目了然——每 8 层一组，组内最后一层用 MLA，其余用 KDA，72 / 8 = 9，于是恰好 9 层 MLA、63 层 KDA：

self.attention_layer_type = (
    "attention"
    if (layer_idx + 1) % config.layer_group_size == 0
    or layer_idx >= config.num_hidden_layers // config.layer_group_size * config.layer_group_size
    else "linear_attention"
)

KDA 层基于 fla 库的 chunk_kda / fused_recurrent_kda 算子实现（类名 BailingMoeV3KimiDeltaAttention），并内置了 q/k/v 的短卷积（short_conv_kernel_size=4）与门控归一化（FusedRMSNormGated，sigmoid 激活）。MLA 层则是典型的低秩压缩结构：q_lora_rank=1536、kv_lora_rank=512、64 个注意力头、qk_head_dim=192，并支持 head_wise 粒度的门控投影。

2.3 MTP / NextN 投机解码：解码速度的隐藏武器

仓库中还藏着一个容易被忽略的组件：MTP（Multi-Token Prediction）层。config.json 中 num_nextn_predict_layers=1，对应 modeling_bailing_moe_v3.py 中的 BailingMoeV3MTPLayer——在 72 层 decoder 之上追加一层 MTP，通过 eh_proj 融合上一层隐状态与输入嵌入，一次预测多个后续 Token：

self.eh_proj = nn.Linear(config.hidden_size * 2, config.hidden_size, bias=False)
...
hidden_states = self.eh_proj(torch.cat([input_embeds, hidden_states], dim=-1))

这一层直接对应推理框架中的 NEXTN 投机解码：SGLang 官方 day-0 镜像即内置 --speculative-algorithm NEXTN 支持，vLLM 侧则对应 --speculative-config '{"method":"mtp","num_speculative_tokens":3}'。对 25B 激活参数的 MoE 而言，投机解码是摊薄"总参大、激活小"优势、把单 Token 延迟打下来的关键一环。

2.4 关于"1M 上下文"的严谨表述

这里有一个值得注意的细节：宣传口径是"上下文窗口上限 1M"，但本仓库 config.json 中 max_position_embeddings 为 262144（256K），且 rope_scaling 为 null。这与官方公告完全自洽——免费体验期间，为控制综合服务成本，模型服务上下文长度限定为 256K；免费期结束转为付费后，才开放 1M 上下文。也就是说，"1M"是模型的长期能力上限，当前权重原生的 RoPE 位置编码窗口为 256K（rope_theta=6e6），1M 需要后续通过位置插值或新版本权重解锁。开发者做容量规划时，应以"当前 256K、后续 1M"两档来设计。

2.5 FP8 量化出厂：仓库本身就是"半成品部署方案"

另一个值得注意的事实：本仓库发布的权重是 FP8 量化版（config.json 中 quant_method: "fp8"、fmt: "e4m3"、动态激活量化），并显式排除了 lm_head、word_embeddings 以及各 KDA 层 g_proj 等对精度敏感的张量。这意味着 54 个分片、约数百 GB 的权重并不需要开发者自行量化，开箱即可部署——这正是"Flash"定位的体现。

三、限时两周免费：为什么是"免费"而不是"降价"

Ling-3.1-flash 的定价策略有三个明显特征，把它和常规"上新促销"区分开：

3.1 用"免费额度"换"生态占位"

两周免费体验的本质，是一次开发者心智的收割窗口。对 Agent 开发者和企业来说，把推理链路从一个模型迁到另一个模型的成本远高于 API 调用费本身——Prompt 适配、工具调用协议、JSON 输出稳定性、错误重试策略都要重新验证。官方显然清楚这一点：免费期的目标不是卖 Token，而是让开发者把 Ling-3.1-flash 接入自己的工作流、跑通 tool calling、沉淀评测数据。一旦两周后转为付费，迁移成本会形成天然留存。

3.2 "免费"但限制 256K：把成本曲线留给付费期

免费不等于无限额度。官方明确"考虑到综合服务成本，免费体验期间模型服务长度为 256K"。这个设计很精妙：免费期开放的是一个足够展示能力（长文档、长代码、Agent 长任务）但不至于击穿成本的档位；而"1M 上下文"这个最有吸引力的卖点，被刻意留到付费期作为升级理由。换句话说，免费期是 1M 能力的"预告片"。

3.3 开源节奏与透明度配合

值得注意的是，官方对开源的表述是"免费期结束转为付费后，同步开源"。但模型权重实际已经随发布上架 ModelScope 与 Hugging Face（本仓库即其 HF 镜像，git 提交记录显示 2026-10-15 最新更新），并附带了训练内容披露（TDS）文档索引，覆盖训练数据规模、混配比例等透明度信息。这种"服务收费 + 权重开源 + 训练披露"的组合，与 Ling-2.6-flash、Ring-2.6-1T 等前代产品的打法一脉相承：权重开源换社区影响力，API 收费换商业回报，两者并行不冲突。

四、魔搭第 2 的含金量：为什么是这个生态位

"冲上魔搭第 2"的含金量，要从两个维度看：

一是上新节奏。 2026 年以来，蚂蚁百灵保持着"旗舰 + Flash"双线高频迭代：2 月发布万亿级 Ring-2.5-1T / Ling-2.5-1T，随后是 Ling-2.6-flash、Ring-2.6-1T、Ling-3.0-flash / 3.0-flash-VL，再到 9 月 30 日的 Ling-3.1-flash。在魔搭这样一个每周都有国产模型上新的平台上，能够在新模型密集轰炸中冲上前三，说明热度并非"上新即榜首"的惯性，而是确实踩中了社区对"国产、大参数量、开源、限时免费"四要素叠加的关注峰值。

二是榜单结构。 魔搭热门榜向来被"大而全的基座模型"与"小而精的端侧模型"两极占据。Ling-3.1-flash 恰好卡在中间：560B 总参数让它具备旗舰级的知识密度，25B 激活参数又让它有接近轻量模型的单 Token 成本；1M 上下文与工具调用能力瞄准的正是 2026 年最热门的 Agent 工作流。README 中专门强调其在 Claude Code、Kilo Code、Qwen Code、Hermes Agent、OpenClaw 等框架下的使用体验，并披露了面向长时编码任务（数百轮工具调用、反复上下文压缩）的 LingCode harness——这是一份写给 Agent 开发者而非普通评测读者的"需求说明书"。

五、上手实测：从仓库出发的部署路线

最后给出可直接照做的两条部署路线（均出自 README.md 官方 Quickstart）。

5.1 SGLang（官方推荐，8×H200 或 4×GB300）

Day-0 镜像已内置 Ling-3.1-flash 支持、NEXTN 投机解码与 Hopper 解码优化：

docker pull lmsysorg/sglang:dev-ling-3.1-flash

docker run --gpus all --network host --ipc=host --rm \
  lmsysorg/sglang:dev-ling-3.1-flash \
  python3 -m sglang.launch_server \
    --model-path inclusionAI/Ling-3.1-flash \
    --tp 8 --ep 8 \
    --speculative-algorithm NEXTN \
    --host 0.0.0.0 --port 30000

其中 --tp 8 --ep 8 为张量并行 + 专家并行；4×GB300 时改用 --tp 4 --ep 4。可选开启 SGLANG_ENABLE_FP8_BLOCK_GEMV=1 与 SGLANG_ENABLE_FUSED_KDA_OUTPUT_QUANT=1 获得约 10% 的 batch-1 解码加速——这两项正是针对 FP8 权重与 KDA 层的定制优化。

5.2 vLLM（分支安装 + MTP 投机 + 工具调用解析）

vllm serve "$MODEL_PATH" \
    --port "$PORT" \
    --trust-remote-code \
    --tensor-parallel-size 8 \
    --gpu-memory-utilization 0.85 \
    --enable-prefix-caching \
    --enable-expert-parallel \
    --mamba-cache-mode align \
    --enable-auto-tool-choice \
    --tool-call-parser ling3 \
    --reasoning-parser ling3 \
    --speculative-config '{"method":"mtp","num_speculative_tokens":3}'

注意两个细节：--trust-remote-code 必须开启（模型依赖仓库内 configuration_bailing_moe_v3.py 与 modeling_bailing_moe_v3.py 的自定义代码）；--tool-call-parser ling3 与 --reasoning-parser ling3 对应 chat_template.jinja 中内建的工具调用与思维链协议。

5.3 Chat Template：thinking 开关与工具调用

chat_template.jinja 是理解模型行为的关键文件。它支持通过 chat_template_kwargs 传入 enable_thinking: true/false 控制思维链输出，生成阶段以 <think></think> 标签区分推理与最终回答；工具调用采用 role/HUMAN/ASSISTANT/OBSERVATION 的 XML 化协议，支持多轮工具响应合并。官方建议使用 temperature=1.0、top_p=0.95、top_k=20 并开启 thinking，以取得更好的 Agent 任务表现。推理端只需在请求中携带：

{
  "model": "Ling-3.1-flash",
  "messages": [{"role": "user", "content": "..."}],
  "chat_template_kwargs": {"enable_thinking": true},
  "stream": true,
  "temperature": 1.0,
  "top_k": 20,
  "top_p": 0.95
}

结语

Ling-3.1-flash 的发布，是 2026 年国产开源大模型"规模竞赛"与"成本竞赛"交汇的典型样本：用 560B 总参数量守住旗舰叙事，用 25B 激活参数守住推理经济性，用 1M 上下文与工具调用能力锚定 Agent 生态，再用两周免费期完成开发者心智收割。对工程团队而言，真正需要关注的不是榜单数字，而是三个可验证的事实：当前开源权重为 FP8 量化、原生 256K 上下文（1M 待付费期解锁）、以及仓库内已具备完整的 SGLang/vLLM 双引擎部署路径。免费期的两周，恰好是评估这三件事的最佳窗口期。