一、背景：参数规模竞赛撞上“算力墙”

大模型的能力在很大程度上遵循规模定律：参数越多、数据越足，模型的知识容量与推理上限就越高，且在达到一定规模后会出现“能力涌现”。过去几年，业界模型参数从百亿、千亿一路推进到万亿级。

但对传统稠密架构而言，参数量与计算量是绑定的：一个万亿参数的稠密模型，处理每个 token 都要调动全部权重参与计算，训练与推理成本线性放大，落地几乎不可行。核心矛盾由此产生：既想要万亿级的“知识库”，又只愿意支付几十亿参数的“电费”。

混合专家架构（MoE, Mixture of Experts）给出的答案是稀疏激活：把“存了多少知识”与“每次算多少”彻底解耦。也正因如此，当前公开的万亿级体量模型几乎清一色采用 MoE 路线。

顺带一提命名文化：业内不少团队喜欢以高峰为模型命名，寓意攀登最难攀登的那座山。对大模型技术而言，“万亿参数 MoE”与“可靠的智能体能力”正是公认的两座高峰，本文就把这两条登山路线拆开来看。

二、MoE 架构核心机制拆解

2.1 用“专家委员会”替换单一前馈网络

标准 Transformer 结构中，每个 block 由注意力层和前馈网络（FFN）组成，FFN 承担了模型的大部分参数。MoE 的做法是：将 FFN 替换为 N 个结构相同、参数各异的“专家”FFN，并新增一个门控网络（Router）。

每个 token 流经该层时，Router 计算它与各专家的匹配得分，只把 token 交给得分最高的少数专家处理，其余专家完全不参与计算。可以用医院分诊类比：全院有上千名医生（总参数），但每位病人只需挂两三个科室（激活专家），而不是全院会诊——知识总量巨大，单次诊疗成本却很小。

2.2 稀疏激活：万亿容量，几十亿的算力账单

业界主流的万亿级 MoE 配置通常呈现如下特征：

• 总参数量在万亿量级（约 1T），决定模型的知识上限；
• 每个 token 推理时仅激活数百亿参数（常见为 20B～40B 量级），激活比例约 3%；
• 路由到少量选中专家（如 6～8 个）与 1 个共享专家协作处理。

这意味着：单 token 的计算开销与一个几十 B 的稠密模型相当，而可学习的知识容量放大了几十倍。同样的推理预算，可以“装下”多得多的世界知识与技能。

2.3 共享专家：公共知识不重复劳动

不同 token、不同任务之间存在大量共性计算——基础语法、通用语义、常见推理模式。若每个专家都各自学一遍这些公共能力，参数会大量冗余。引入共享专家后：

• 共享专家对所有 token 生效，负责沉淀公共模式；
• 选中专家专注差异化知识，如代码、数学、多语言、工具调用模式等。

这种“公共 + 专精”的分工显著提高了参数利用率，是近年来 MoE 设计的重要演进方向。

2.4 路由与负载均衡：决定 MoE 成败的细节

• Top-K 路由：得分取前 K 名，其余专家零参与，这是稀疏性的直接来源；
• 路由崩塌：若不加约束，Router 会把流量集中到少数“明星专家”，其余专家得不到训练，模型能力退化；
• 负载均衡：训练时通常引入辅助均衡损失，惩罚专家间负载不均，并配合容量因子、溢出策略等工程手段，保证专家们“忙而不乱”；
• 专家并行：训练与推理时将不同专家分布到不同设备，跨卡 all-to-all 通信是主要系统开销之一。

一段示意性伪代码，帮助直观理解路由与加权合并过程：

# 示意性伪代码：极简 MoE 前馈层（Top-K 路由 + 共享专家）
def moe_ffn(x, experts, shared_experts, gate, top_k=8):
    # x: [batch, seq_len, d_model]
    scores = softmax(gate(x), dim=-1)              # 每个 token 对所有专家的匹配得分
    topk_score, topk_id = topk(scores, k=top_k)    # 只保留得分最高的 K 个专家
    topk_score = topk_score / sum(topk_score)      # 归一化门控权重
    out = zeros_like(x)
    for e, expert in enumerate(experts):
        pos = where(topk_id == e)                  # 找到选中该专家的 token
        if pos is empty: continue
        y = expert(x[pos])                         # 仅对这部分 token 做前向计算
        out[pos] += y * topk_score[pos]            # 按门控权重加权合并
    for se in shared_experts:                      # 共享专家对所有 token 生效
        out += se(x)
    return out

2.5 从第几层开始引入 MoE？这是个工程权衡

并非所有层都适合稀疏化。常见做法有两种：全量 MoE，或浅层保持稠密、从第二个 block 开始引入 MoE。后者的逻辑在于：浅层更接近通用特征提取，保持稠密有利于底层表示稳定；中高层承担更多语义分化，尽早在此引入稀疏结构，既能吃满“专家分工”的收益，又能控制整体计算量。具体从哪一层开始并没有金标准，本质是容量、稳定性与算力预算之间的权衡。

三、训练与推理的工程现实

3.1 训练侧的三个难点

1. 稳定性：路由是离散选择，梯度只能经门控权重回传，训练容易抖动，需要精细的学习率策略、均衡损失系数与初始化方案；
2. 通信：专家并行带来 all-to-all 通信，对互联带宽极其敏感，集群拓扑直接影响吞吐；
3. 显存：虽然激活参数少，但总参数都要驻留显存（或做分层卸载），“存放成本”并不低。

3.2 推理侧的两本账

评估 MoE 推理成本要算两笔账：显存账看总参数，算力账看激活参数。由此可得两个推论：

• 高并发、大 batch 的服务端场景中，不同 token 激活不同专家，硬件利用率高，MoE 优势被充分放大；
• 极低并发、单请求场景下，稀疏带来的算力节省会被显存成本部分抵消。

因此，万亿级 MoE 模型尤其适合大规模在线服务与智能体长链条调用这类吞吐敏感型负载。

四、从“会答题”到“会做事”：智能体范式转变

4.1 基础模型与智能体模型的分工

一个完整的模型体系通常包含两个层次：

• 基础模型：通过大规模预训练获得语言、知识与通用推理能力，是整个体系的“大脑”；
• 智能体/对话模型：在基础模型之上，用海量智能体轨迹数据（任务分解、工具调用、自我校验与反思）继续训练，并叠加强化学习，最终得到“边思考边使用工具”的模型。

两者是“底座”与“行为”的关系：只有底座，模型博学但不会做事；只有行为模板而没有足够的知识与推理深度支撑，智能体也只是空壳。

4.2 思维链不等于智能体

• 思维链（CoT）：推理在模型内部静态展开，“想好了再回答”，全程不与外部世界交互；
• 智能体范式：思考 → 行动 → 再思考的闭环循环。模型在动态环境中感知反馈、规划步骤、调用工具（检索、计算、代码执行、业务接口等），并根据观察结果修正下一步策略。

关键差别在“闭环”二字。思维链的正确性完全依赖参数内知识，遇到实时信息、私有数据或精确计算就无能为力；智能体则能借助工具获取新信息、执行真实操作，突破静态训练数据在时间与范围上的限制。

4.3 强化学习教模型“何时想、何时做”

智能体训练中，奖励信号来自任务是否真正完成，而非某句话是否措辞流畅。这迫使模型学到策略层面的能力：什么时候值得多想几步，什么时候直接调工具，工具报错后如何重试或更换路径。这类“过程性能力”很难靠人工标注数据穷举，恰是强化学习的用武之地。

4.4 极简智能体执行循环

# 示意性伪代码：极简智能体执行循环
def agent_loop(task, tools, llm, max_steps=20):
    history = [build_system_prompt(task)]
    for step in range(max_steps):
        thought = llm.think(history)               # 思考：拆解问题、规划下一步
        action  = llm.propose_action(history)      # 行动：选择工具并生成调用参数
        if action.name == "finish":
            return action.answer
        observation = tools[action.name].run(action.args)   # 与环境交互
        history += [thought, action, observation]           # 再思考：反馈进入上下文
    return llm.summarize(history)                   # 达到步数上限时的兜底输出

真实系统会在此基础上增加记忆管理、多智能体协作、沙箱执行、结果校验等模块，但核心循环不变。

4.5 为什么万亿级 MoE 天然适配智能体

一次复杂任务动辄包含几十轮“思考 + 调用”，token 消耗可达普通问答的十倍以上。稀疏激活让长链条任务的成本可控；万亿级参数容量则让模型“见过”更丰富的工具组合与领域模式。一个负责算得省，一个负责想得深，二者组合构成了当前高性能智能体的事实标准。

五、给开发者的选型与实践建议

1. 任务匹配：简单分类、抽取、短文本生成，几十 B 稠密模型即可胜任；多步推理、工具编排、代码生成等复杂任务，优先评估 MoE 智能体模型；
2. 成本估算：按“单 token 激活成本 × 任务总 token 消耗”建模，而不是只盯着参数规模；智能体场景务必把多轮调用计入预算；
3. 集成路径：自建万亿级推理集群门槛极高，更现实的路径是通过云端大模型服务接入。例如百度智能云提供的大模型服务、智能体开发平台、模型微调与部署工具链等通用能力，可直接完成模型调用、工作流编排与效果评测，把工程精力留在业务本身；
4. 评测先行：用自己业务的真实任务集验证工具调用成功率与多步任务完成率，榜单分数只能作为参考，不能替代业务评测。

六、结语

万亿参数 MoE 回答的是“如何知道得多、算得省”，智能体范式回答的是“如何想得深、做得到”。前者通过稀疏激活与专家路由重塑了模型架构的成本曲线，后者通过“思考—行动—再思考”的闭环重新定义了模型与世界的交互方式。以高峰为模型命名寄托的是攀登雄心，但真正决定模型高度的，是稀疏架构、路由细节、负载均衡与强化学习这些脚踏实地的工程功课。对开发者而言，理解这些机制，才能在模型选型、成本控制与智能体应用设计中做出更专业的判断。