MasterLee's Tech Blog

从美团 LongCat-2.0 看国产芯片算力集群的训练效率

围绕美团 LongCat-2.0 的训练流程与公开工程指标，拆解五万卡国产芯片集群的 MFU、吞吐、稳定性与产业含义。

21 分钟阅读 马斯特李

1. 摘要

2026 年 6 月 30 日，美团发布并以 MIT 协议开源 LongCat-2.0。这是一个总参数 1.6T、平均每 token 激活约 48B（动态范围 33B–56B）的 MoE 模型，原生支持 1M 上下文，并面向 Agentic Coding 深度优化。官方称，其从预训练到推理部署的全流程均在五万余张国产算力芯片上完成。若这一表述成立，这将是国产芯片集群首次跑通万亿参数 MoE 的从零预训练。

本文不复述发布信息，而是围绕官方公开的四个工程指标做定量拆解：预训练 30T+（GitHub 口径 35T+）tokens、稳态日吞吐超 1T tokens/day、训练 MFU 提升 1.5 倍、月均日故障率降低 70% 以上。文章试图回答一个核心问题：

这个五万卡国产集群的真实训练效率，处于什么水平？

主要结论：按 6ND 估算，在基准情形（48B 激活参数、35T tokens）下，预训练总计算量约为 1.008×1025 FLOPs1.008 \times 10^{25} \text{ FLOPs} 。由 1T tokens/day 的稳态吞吐反推，集群有效算力约为 3.3 EFLOPS 3.3 \text{ EFLOPS} 。假设LongCat 2.0使用的是昇腾 910B（按320 TFLOPS计）同级的国产算力芯片，则MFU约为 21%。

这一水平低于 Nvidia 集群的最佳实践（35%–55%），但结合“全程无回滚、无不可恢复 loss 突刺”的稳定性表现，工程含金量依然很高。

2. LongCat-2.0 模型与训练背景

2.1. 发布时间与开源情况

LongCat-2.0 于 2026 年 6 月 30 日正式发布并启动开源 [765]。模型代码托管于 GitHub（meituan-longcat/LongCat-2.0），模型主页同步上线 Hugging Face、ModelScope 和官方平台 longcat.ai [1399]。

2.2. 参数规模与MoE架构

LongCat-2.0采用混合专家（Mixture of Experts, MoE）稀疏架构，其核心参数指标如下：

参数维度数值说明
总参数量1.6T（1.6万亿）所有专家参数与共享参数之和 [765]
平均激活参数约48B（480亿）每个token实际参与计算的平均参数量 [765]
动态激活范围33B–56B通过零计算专家实现token级动态调度，简单token消耗更少，复杂token获得更多资源 [774]
MoE稀疏度约97%仅约3%的总参数在每个token上被激活，大幅降低推理算力需求 [907]
N-gram Embedding135B参数独立于MoE专家的嵌入层，将嵌入空间扩展约100倍，增强局部上下文建模与推理效率 [1069]

架构核心特征：

  • ScMoE（Shortcut-connected MoE）： 在标准MoE基础上引入短路连接，通过扩大计算-通信重叠窗口来提升训练和推理效率，该设计继承自LongCat-Flash [774]。
  • 零计算专家（Zero-Computation Experts）： 专家池中包含恒等映射专家，路由器根据token的重要性动态分配真假专家比例，使激活参数从固定值变为一个区间（33B–56B），实现“简单token不耗算力，复杂token自动获得更多资源” [774]。
  • MOPD多专家融合： 在后训练阶段融合三组专家——Agent专家（工具调用/API解析/自主纠错）、Reasoning专家（多跳推理/STEM推理）、Interaction专家（指令遵循/幻觉抑制），由门控网络根据任务类型动态调度，使单一模型在编程、推理、交互三个维度均衡表现 [818]。

2.3. 原生1M Token超长上下文

LongCat-2.0原生支持 100万token(1M) 超长上下文窗口，可一次处理百万字级输入 [765]。这意味着模型并非通过位置编码外推等技巧“扩展”上下文，而是从预训练阶段就使用1M长度的数据进行了专项训练 [792]。

这一能力通过 LongCat Sparse Attention(LSA) 稀疏注意力机制实现。LSA是DeepSeek Sparse Attention（DSA）的演进版本，通过三项正交优化——流式感知索引、跨层KV共享、层次化索引——将长文本的注意力计算从平方级复杂度降至近线性级，大幅缓解了长上下文场景下的显存与计算瓶颈 [768]。

2.4. 任务定位：Agentic Coding（智能体编程）

LongCat-2.0的核心定位并非通用聊天机器人，而是面向Agentic Coding(智能体编程) 深度优化。官方明确表述：“其架构设计自始至终围绕一个核心目标——让模型在真实的Agentic Coding任务中，更高效、更稳定地完成代码理解、生成与执行” [830]。

关键评测表现（官方内部评测）：

基准LongCat-2.0GPT-5.5Claude Opus 4.6Gemini 3.1 Pro
SWE-bench Pro59.558.657.354.2
SWE-bench Multilingual77.3—77.8—
Terminal-Bench 2.170.8———
τ²-Bench88.2———
FORTE73.2———
BrowseComp79.9———

来源：美团官方新闻稿及技术文档 [805]

⚠️ 注意： 以上基准均来自美团官方内部评测，截至2026年7月1日，第三方独立评测机构（如Artificial Analysis、LMSYS）尚未发布对LongCat-2.0的完整评测结果 [960]。SWE-bench Pro上与GPT-5.5的差距仅0.9分，属于统计学上较窄的领先区间 [1401]。在更广泛的Agent基准（如FORTE、BrowseComp）上，LongCat-2.0仍落后于Claude Opus 4.8 [822]。

OpenRouter 匿名验证： 预览版（Owl Alpha）在 OpenRouter 上运行近两个月，总调用量跻身全球前三；月调用量在 Hermes Agent 框架上全球第一，在 Claude Code 上全球第二（仅次于 Claude Opus 4.8）；月 token 吞吐量超过 10T [1164]。这类匿名灰度结果不能替代独立基准，但能说明模型已在真实 Agent 工作流中接受过一定规模的外部验证。

2.5. 与LongCat前代模型的关系

LongCat是美团自研大模型系列的品牌名称，其演进脉络清晰：

时间模型定位关键参数
2025.09.01LongCat-Flash-Chat第一代旗舰对话基座560B总参，~27B激活 [1295]
2025.09.22LongCat-Flash-Thinking推理增强模型基于Flash-Chat后训练 [1440]
2025.11LongCat-Flash-Omni全模态实时交互文本/图像/视频/语音 [1438]
2025.10–12LongCat-Video / Image视频/图像生成独立模型线 [1311]
2026.01LongCat-Flash-Thinking-2601推理模型升级版Agentic Search/工具调用SOTA [1440]
2026.02LongCat-Flash-Lite轻量级MoE68.5B总参，首次引入N-gram Embedding [1313]
2026.03–04LongCat-Next原生多模态基座视觉/语音token化，离散统一建模 [1019]
2026.04LongCat-2.0-Preview2.0预览版（Owl Alpha）1.6T/48B，OpenRouter匿名测试 [1447]
2026.06.30LongCat-2.0第二代旗舰Agentic Coding1.6T/48B，1M上下文，MIT开源 [2]

关键继承关系：

  1. 架构继承自LongCat-Flash： 官方明确表述“Our architecture design builds on LongCat-Flash, pushing further on parameter efficiency and long-context training and inference speed” [1079]。LongCat-2.0继承了Flash的ScMoE和零计算专家两大核心创新，并将动态激活范围从Flash的18.6B–31.3B扩展至33B–56B [774]。

  2. N-gram Embedding的规模化： 该技术最早在LongCat-Flash-Lite中引入（68.5B模型，embedding参数约30B），在LongCat-2.0中被扩展至135B参数规模，成为独立于MoE专家的嵌入层，将embedding空间扩展约100倍 [1069]。

  3. 定位的变化： 从Flash的“通用对话基座”（560B/27B），到Flash-Lite的“轻量级Agent/代码模型”（68.5B），再到2.0的“万亿参数Agentic Coding旗舰”（1.6T/48B），LongCat系列完成了从通用对话到专用Agentic Coding的定位转变 [1207]。

3. LongCat-2.0 最可能使用的国产芯片推断

美团官方并未披露 LongCat-2.0 使用的具体芯片厂商和型号。因此，关于芯片平台的判断只能作为公开信息基础上的推断，不能视为确定结论。

从现有线索看，LongCat-2.0 使用华为昇腾 Ascend 910B/C 系列的可能性较高，但证据链仍然是间接的。

线索维度具体证据推断指向
美团官方表述“AI ASIC superpod” [2]排除GPGPU路线（如寒武纪MLU），指向ASIC架构
社区硬件反推“48 node超节点，不到80GB HBM”，“每die 64GB HBM” [550]与昇腾910B/C（每die约64GB HBM）高度吻合
通信协议DoNews报道提及“HCCL异常处理” [750]HCCL是华为昇腾的集合通信库，与NVIDIA的NCCL对应

注： 美团官方公告中仅提及“国产算力芯片”和“AI ASIC superpod”，未确认任何芯片厂商 [620]。社区推断为昇腾910B/C主要基于HCCL协议名称、硬件规格反推等间接证据，而非官方确认 [550]。

4. 训练数据、训练流程与工程指标

LongCat-2.0 的训练规模和工程效率指标，是理解其产业意义的另一关键维度。美团官方公布的核心指标包括：预训练数据超 30T tokens（实际可能达 35T+）、稳态日吞吐超 1T tokens/day、训练 MFU 提升 1.5 倍、月均日故障率降低 70% 以上。以下从数据规模、算力估算、吞吐效率、MFU 优化和集群稳定性五个维度展开分析，并明确标注各类估算的假设与不确定性。

4.1. 预训练数据规模：30T+ tokens 意味着什么

4.1.1. 数据量级定位

美团官方新闻稿称 LongCat-2.0”预训练数据规模超过 30T tokens，覆盖中文、英文、多语言和代码等多类数据”[2]。但 GitHub 和 Hugging Face 仓库的 README 则表述为”Pre-training spans millions of accelerator-hours across more than 35 trillion tokens”[2667]。这一差异（30T vs 35T+）可能源于不同统计口径：30T 可能仅指纯文本预训练，35T+ 可能包含了长上下文扩展训练（数千亿 tokens 的 1M 上下文数据[2622]）和代码专项训练。

在行业语境中，30–35T tokens 的数据规模处于什么水平？下表给出对比：

模型预训练 Token 量总参数/激活参数架构类型
LongCat-2.030T–35T+1.6T / ~48BMoE
DeepSeek-V4-Pro~32T+1.6T / 49BMoE
DeepSeek-V314.8T671B / 37BMoE
Llama 3.1 405B15.6T405B（Dense）Dense
Qwen 2.5~18T72B（Dense）Dense
LongCat-Flash20T+560B / 27BMoE

LongCat-2.0 的 token 量（30T+）是 DeepSeek-V3 的约 2 倍，是 Llama 3.1 405B 的约 2 倍，且与 DeepSeek-V4-Pro 的 ~32T 处于同一量级。

4.1.2. 数据构成与质量

美团官方指出数据覆盖”中文、英文、多语言和代码等多类数据”[2]。考虑到 LongCat-2.0 的核心定位是 Agentic Coding，其训练数据中代码数据占比很可能显著高于通用大模型 [2380]。对于 Agentic Coding 任务，代码数据不仅包括源代码，还涉及代码执行轨迹、工具调用序列、交互式调试日志等结构化数据，这类数据的获取和清洗难度远高于自然语言文本。

4.2. 训练算力需求估算

4.2.1. 估算方法

对于 Transformer 架构的 MoE 模型，训练总 FLOPs 的经典估算公式为 [2591]：

FLOPs≈6×Nact×D\text{FLOPs} \approx 6 \times N_{\text{act}} \times D

其中 NactN_{\text{act}} 为每 token 激活的参数量，DD 为训练 token 总数。系数 6 来源于：前向传播约 2×（一次乘法 + 一次加法），反向传播约 4×（梯度计算约 2× 前向计算量）。若使用激活重计算（activation recomputation），则需额外增加约 1× 前向计算量，总系数提升至约 8× [2654]。LongCat-Flash 技术报告中明确使用了激活重计算来节省显存 [2512]，因此 LongCat-2.0 很可能也采用了类似策略。

4.2.2. 估算结果

假设 1（保守）：不使用激活重计算，系数 = 6，N_act = 48B，D = 30T

FLOPs=6×48×109×30×1012=8.64×1024 FLOPs\text{FLOPs} = 6 \times 48 \times 10^9 \times 30 \times 10^{12} = 8.64 \times 10^{24} \text{ FLOPs}

假设 2（基准）：不使用激活重计算，系数 = 6，N_act = 48B，D = 35T

FLOPs=6×48×109×35×1012=1.008×1025 FLOPs\text{FLOPs} = 6 \times 48 \times 10^9 \times 35 \times 10^{12} = 1.008 \times 10^{25} \text{ FLOPs}

假设 3（含重计算）：系数 = 8，N_act = 48B，D = 35T

FLOPs=8×48×109×35×1012=1.344×1025 FLOPs\text{FLOPs} = 8 \times 48 \times 10^9 \times 35 \times 10^{12} = 1.344 \times 10^{25} \text{ FLOPs}

横向对比：

模型估算总 FLOPs训练 GPU 小时集群规模
LongCat-2.0（假设 2）~1.0×10²⁵未知（见下文）50K 国产芯片
DeepSeek-V3~3.3×10²⁴2.79M H800 小时2,048 H800
Llama 3.1 405B~3.8×10²⁵30.8M H100 小时16,000 H100
DeepSeek-V4-Pro~9.4×10²⁴（估算）未公开未公开

LongCat-2.0 的总训练 FLOPs 约为 DeepSeek-V3 的 3 倍，但仅为 Llama 3.1 405B（Dense 模型）的约 1/4。这体现了 MoE 架构在计算效率上的巨大优势——尽管总参数是 Llama 3.1 405B 的约 4 倍，但训练计算量反而更小 [2591]。

4.2.3. 训练周期估算

基于公开信息，LongCat-2.0 预训练”在 5 万余国产算力芯片上耗时月余完成”[2622]。假设训练周期为 35–45 天，可以反推集群的有效算力利用情况：

以 35T tokens、35 天、50K 加速卡计算：

  • 每天需处理 35T / 35 = 1T tokens/day（与官方公布的”稳态日吞吐超 1T tokens/day”吻合 [2390]）
  • 每天所需 FLOPs（假设 2）：1.008×10²⁵ / 35 ≈ 2.88×10²³ FLOPs/day
  • 折算为每秒：2.88×10²³ / 86400 ≈ 3.33×10¹⁸ FLOPS（即 3.33 EFLOPS）

若假设国产芯片单卡 FP16/BF16 峰值算力为 320 TFLOPS（接近昇腾 910B 水平 [2547]），则 50K 卡集群峰值总算力为：

50,000×320×1012=1.6×1019 FLOPS=16 EFLOPS50,000 \times 320 \times 10^{12} = 1.6 \times 10^{19} \text{ FLOPS} = 16 \text{ EFLOPS}

此时 MFU 约为：

MFU=3.33×10181.6×1019≈20.8%\text{MFU} = \frac{3.33 \times 10^{18}}{1.6 \times 10^{19}} \approx 20.8\%

两点口径说明：

  1. 其一，以上按惯例只计模型理论 FLOPs（系数 6），即严格意义的 MFU；若 LongCat-2.0 使用激活重计算，硬件实际执行的 FLOPs 更高（系数约 8），对应的 HFU（硬件算力利用率）在 910B 假设下约 27.8%。
  2. 其二，6ND 公式忽略 attention 项，在包含 1M 长上下文训练数据的场景下会系统性低估计算量，因此上述 MFU 数值可视为下界估计。

4.3. 稳态日吞吐超 1T tokens/day 的工程含义

4.3.1. 指标解读

“稳态日吞吐超过 1T tokens/day”是美团官方对 LongCat-2.0 训练效率的核心表述 [2390]。这一指标的工程含义可以从多个维度解读：

（1）与 DeepSeek-V3 的对比。 DeepSeek-V3 在 2,048 张 H800 GPU 上训练 14.8T tokens，耗时约 57 天 [2563]，平均日吞吐约为 14.8T / 57 ≈ 0.26T tokens/day，平均每卡时吞吐为 0.26T/2048/24 ≈ 5.28M tokens/gpu/hr.

DeepSeek-V3 技术报告指出，每T tokens 仅需 180K H800 GPU 小时 [2566]，换算下来也差不多约 5.41M tokens/gpu/hr。

LongCat-2.0 的 1T tokens/day 在 50K 卡上实现，意味着平均每卡时吞吐约 0.81M tokens/gpu/hr — 仅为 DeepSeek-V3 的效率1/6~1/7，但考虑到国产芯片单卡算力（~320 TFLOPS）约为 H800（~989 TFLOPS BF16）的 1/3，且集群规模大 25 倍，这一差距也算在预期之内。

（2）每卡每秒处理 token 数。 1T tokens/day 在 50K 卡上意味着每卡每天处理约 20M tokens，或每秒约 231 tokens。对于一个 48B 激活参数的 MoE 模型，每 token 前向推理约需 2×48B = 96B FLOPs，即每秒需要 231 × 96×10⁹ ≈ 2.22×10¹³ FLOPS ≈ 22.2 TFLOPS。在 320 TFLOPS 峰值算力下，利用率约 6.9%（仅前向）。但训练包含了前向 + 反向，实际有效利用率（MFU）在 20% 左右，说明前向传播占总计算的比例与上述估算一致。

（3）与 LongCat-Flash 的对比。 LongCat-Flash 技术报告显示，其 560B/27B 激活的 MoE 模型在 20T+ tokens 上训练，30 天内完成 [2503]，日吞吐约 0.67T tokens/day。LongCat-2.0 的 1T tokens/day 相比前代提升了约 50%，但模型激活参数也从 27B 增加到 48B（增长 78%），实际训练效率的提升幅度需要考虑模型规模增长。

4.3.2. 吞吐量对训练周期的影响

在 1T tokens/day 的稳态吞吐下，完成 30T–35T tokens 的预训练需要 30–35 天。这与 OSCHINA 报道的”预训练在 5 万余国产算力芯片上耗时月余完成”[2622]一致。如果加上长上下文扩展训练（数千亿 tokens 的 1M 上下文数据 [2622]）和后训练（SFT、RL），总训练周期可能在 45–60 天左右。

4.4. MFU 提升 1.5 倍：含义、基线与实现路径

4.4.1. MFU 的定义与计算

MFU（Model FLOPs Utilization，模型算力利用率）是大模型训练效率的核心指标，定义为 [2404]：

MFU=模型实际 FLOPS硬件峰值 FLOPS=理论 FLOPs / 迭代时间设备数 × 单卡峰值算力\text{MFU} = \frac{\text{模型实际 FLOPS}}{\text{硬件峰值 FLOPS}} = \frac{\text{理论 FLOPs / 迭代时间}}{\text{设备数 × 单卡峰值算力}}

MFU 不同于简单的 GPU 利用率（如 nvidia-smi 显示的百分比）。GPU 利用率仅反映设备是否在”忙”，而 MFU 衡量的是设备实际执行的有效浮点运算占理论峰值的比例。即使 GPU 利用率显示 100%，实际 MFU 也可能只有 30%–50%，因为大量的时间被通信等待、kernel 启动开销、内存访问延迟等占用 [2404]。

4.4.2. “提升 1.5 倍”的含义分析

美团称”训练 MFU 提升 1.5 倍” [2395]。

在给出解读前必须先指出汉语表述本身的歧义：“提升 1.5 倍”在严格语义下指增加了 150%（终值为基线的 2.5 倍），但在工程口语中也常被用来表示”提升到 1.5 倍”（终值为基线的 1.5 倍）。官方未给出基线和终值的绝对数，两种读法都无法排除。

结合前文估算的终值 MFU（910B 假设下约 20.8%），可以分别反推基线：

  • 按 ×2.5 读（严格语义）： 基线 MFU ≈ 20.8% / 2.5 ≈ 8.3%。这对应集群搭建初期、算子和通信尚未深度优化的状态，对于国产芯片上首次万亿参数 MoE 训练的冷启动阶段是可信的。
  • 按 ×1.5 读（口语语义）： 基线 MFU ≈ 20.8% / 1.5 ≈ 13.9%。这对应一个已完成基础适配、但流水线气泡和通信重叠尚未调优的中间状态，同样合理。

两种读法下的基线（8%–14%）均显著低于业界成熟实践——华为盘古 Ultra MoE 在 6,000+ 昇腾 NPU 上优化后 MFU 为 30% [2406]，基于国产 NPU 的 405B Dense 模型在 16,384 卡上达 45.13% [2403]——但考虑到 50K 卡规模是上述实践的 3–8 倍、且 MoE 的 All-to-All 通信随规模恶化，这个基线区间也不算意外。

另一种解读——“1.5 倍”指相对某外部参考系（如 Nvidia 集群）的绝对倍数——可能性较低：跨软件栈的 MFU 横向对比缺乏工程意义，官方更可能是在描述自身集群上的优化前后对比。

4.4.3. MFU 优化的可能方向

根据已有的公开信息，推测美团从以下方向提升了 MFU [2395]：

优化方向具体措施对 MFU 的影响
流水线调度优化优化 pipeline 气泡，减少设备空闲等待直接提升计算时间占比
显存优化通过激活重计算、显存 offload 等释放显存以支持更大 batch size提升计算密度，降低通信频率
算子级核心控制自研确定性算子，针对国产芯片优化 GEMM、Attention 等核心算子提升单算子执行效率
计算-通信重叠ScMoE 架构将前一层 Dense FFN 与 MoE 通信并行隐藏通信延迟，提升有效 MFU
通信库优化集成 HCCL（华为集合通信库），优化 All-to-All 和 All-Reduce降低通信占比

4.4.4. 与国内外实践的对比

模型 / 系统集群规模硬件架构类型精度MFU
LongCat-2.0（估算）50K国产芯片（910B 假设）MoEBF16~20%（估算）
华为盘古 Ultra MoE6,000+昇腾 NPUMoEBF1630.0% [2406]
DeepSeek-V32,048H800MoEFP8/BF16~34.7% [2570]
Llama 3.1 405B16,000H100DenseBF16~40% [2444]
字节 MegaScale12,288A100/A800DenseBF1655.2% [2414]

LongCat-2.0 的估算 MFU（~20%）低于 Nvidia 集群上的最佳实践，但在国产芯片上训练万亿参数 MoE 模型的语境下，这一水平已属不易。随着国产芯片软件栈的成熟和算子优化的深入，未来 MFU 有进一步提升空间。

4.5. 月均日故障率降低 70% 以上：集群稳定性挑战

4.5.1. 指标含义

“月均日故障率降低 70% 以上”是美团官方公布的另一关键稳定性指标 [2389]。

在万卡集群中，硬件故障是常态而非异常。蚂蚁集团在 GPU 训练集群中的数据显示，一个月内单卡故障率约为 8%，即每天单卡故障率约 0.27% [2463]。对于 50K 卡的集群，这意味着每天可能有约 135 张卡发生故障。如果每次故障导致整个训练任务中断并需要回滚到上一个 checkpoint，则训练效率将受到严重影响。业界超万卡集群稳定运行仅数日的情况并不罕见 [2474]。

4.5.2. 故障率降低的实现手段

美团通过以下手段将故障率降低 70% 以上 [2389]：

（1）HCCL 异常处理 / 卡间通信异常处理。 HCCL（Huawei Collective Communication Library）是华为昇腾生态的集合通信库，相当于 Nvidia 的 NCCL。在大规模 MoE 训练中，通信异常（如链路抖动、超时、丢包）是导致训练中断的主要原因之一。通过 HCCL 层面的异常检测与自动重试，可以在不中断训练的情况下恢复通信 [2391]。

（2）弹性扩缩卡。 当部分节点故障时，系统可以动态地将故障节点剔除出训练拓扑，并将剩余健康节点重新组织为有效的并行配置，训练任务继续运行而无需完全重启 [2390]。这要求训练框架支持动态的并行度调整（如数据并行维度的动态变化），技术难度较高。

（3）自动故障恢复。 包括自动检测故障节点、自动隔离故障链路、自动从最近的 checkpoint 恢复训练。百度百舸的实践表明，万卡集群中大部分训练异常场景的恢复时间可以从 30 分钟缩短至 30 秒以内 [2464]。华为昇腾集群也实现了万卡可用度 98%、秒级快恢 [2473]。美团在国产芯片上可能借鉴了类似的技术路线。

（4）确定性算子与 Bitwise 验证。 美团自研了确定性算子，确保相同输入产生完全相同的输出，并通过 Bitwise 一致性验证快速检测计算结果异常 [2391]。这在大规模分布式训练中尤为关键——浮点运算的非确定性可能导致不同设备上的结果出现微小偏差，累积后引发 loss 突刺，而确定性算子可以消除这一问题。

4.5.3. “全程无回滚、无不可恢复的 loss 突刺”的意义

LongCat-2.0 的 GitHub README 特别强调”with no rollbacks or irrecoverable loss spikes”[2667]。在大模型训练中，loss 突刺（loss spike）是最令人头疼的问题之一——即使训练看似稳定运行，loss 可能在某个时刻突然飙升，且无法通过回滚到之前 checkpoint 恢复。DeepSeek-V3 技术报告同样自豪地宣称”在整个训练过程中，我们没有遇到任何不可恢复的损失峰值，也没有进行任何回滚操作”[2563]。

对于在国产芯片上进行的大规模训练，这一成就尤为显著。原因在于：国产芯片的软件栈（算子库、编译器、通信库）成熟度低于 CUDA 生态，出现数值不稳定或计算错误的风险更高 [2399]。LongCat 团队通过自研确定性算子、Bitwise 验证等手段，在国产芯片上实现了与 Nvidia 集群相当的训练稳定性，这本身就是一项重要的工程突破。

总结

LongCat-2.0 的训练规模与效率指标共同描绘了一幅具有说服力的工程图景：在 50K 国产芯片集群上，以约 20% 的 MFU 和 1T tokens/day 的稳态吞吐，完成了 30T–35T+ tokens 的预训练，训练周期约一个多月，且全程无回滚。这一成就的工程意义在于：

  1. 数据规模对齐前沿。 30T–35T tokens 的预训练数据量与 DeepSeek-V4-Pro 等国际前沿模型处于同一量级，体现了 LongCat 团队在数据工程上的投入。

  2. 吞吐量达到实用门槛。 1T tokens/day 的吞吐意味着万亿参数 MoE 模型可以在 1–2 个月内完成一轮完整预训练，使模型迭代周期进入可管理的范围。

  3. MFU 在国产芯片上处于合理水平。 ~20% 的 MFU 虽然低于 Nvidia 集群上的最佳实践（30%–55%），但对于国产芯片上首次万亿参数 MoE 训练而言，已属可接受的水平。1.5 倍的 MFU 提升表明团队在训练过程中持续优化。

  4. 稳定性是最大工程亮点。 在 50K 卡规模下实现”全程无回滚、无不可恢复的 loss 突刺”，并将故障率降低 70% 以上，是国产芯片训练基础设施成熟度的重要标志。这比单纯的 MFU 指标更能说明美团在国产 AI Infra 上的深耕程度。

  5. 估算的不确定性需正视。 由于芯片型号未确认，MFU 的绝对估算值（~20%）高度依赖芯片算力假设。如果实际芯片算力更高（如 910C 的 752 TFLOPS），则 MFU 会更低（~9%）；如果芯片算力更低，则 MFU 会更高。后续需等待芯片型号确认后重新校准估算。