简介：本文面向大模型基础读者，系统梳理 MoE 架构中总参数、激活参数、上下文窗口与工程实现之间的关系。通过统一口径、拆解注意力机制与缓存策略、对比不同参数路线，帮助读者理解“参数大”不等于“推理贵”，“激活小”也不等于“能力弱”，从而更准确评估模型能力与部署成本。
过去一年，开放权重模型与 API 大模型的参数表越来越像一份“工程账单”。671B、1T、1.6T 这些数字看上去都极具冲击力，但真正决定每个 token 推理成本的，往往不是总参数，而是每个 token 实际激活了多少参数。注意力机制如何省、缓存怎么设计、长上下文如何实现、工具调用与代码环境如何训练——这些工程取舍，比单纯的总参数量更能反映一个模型的实际能力边界与部署门槛。
本文不把任何一个模型系列当作主角，而是把多个 MoE 模型放在同一张表中，从架构路线、参数口径与工程取舍三个维度进行横向审视。我们需要先建立一个基本直觉：MoE 模型的“规模”至少有两层含义。总参数代表模型拥有多大的专家池和记忆容量；激活参数代表每个 token 实际参与计算的前向预算。一个 1T/32B 的模型，不等于每个 token 都跑 1T 参数；一个 80B/3B 的模型，也不能简单理解为“只有 3B 能力”。
讨论 MoE 模型时，开发者最容易混淆三个基础概念：总参数、每 token 激活参数、上下文窗口。三者描述的是完全不同的维度，但经常被放在同一句话里比较，导致认知偏差。
总参数是指模型仓库中所有专家、注意力层、embedding 矩阵、路由器以及各类辅助模块的参数总量。它更像是一个“容量指标”：总参数越大，模型通常拥有更大的专家空间与更丰富的知识存储能力。但代价同样明显——权重加载时间更长、分布式部署的显存/内存占用更高、专家并行时的通信复杂度也更大。
需要注意的是，总参数并不直接等于前向计算量。在 MoE 架构中，大量专家参数处于“待命”状态，只有被路由器选中的少数专家才会参与当前 token 的计算。因此，总参数更适合用于评估模型的“知识广度”和“专家多样性”，而不是推理延迟的直接预测变量。
MoE 的关键设计是：每个 token 不跑完整模型，而是由路由器动态选择部分专家。例如，某系列模型常见口径是 1T 总参数、32B 激活参数；另一系列是 671B 总参数、37B 激活；还有一类极致压缩路线，将激活量控制在 3B 级别。这个“激活参数”数字，更接近单 token 前向计算的实际预算。
但它并不等价于真实推理延迟。真实延迟还受专家并行策略、通信拓扑、batch 大小、KV cache 长度、量化精度以及 serving 框架调度效率等多重因素影响。激活参数是一个“理论前向计算量”的粗略代理指标，用它来估算算力需求可以，用它来精确预测延迟则会失真。
256K、262K、1M 这样的上下文窗口数字，表面上是“能塞多少 token”，但工程上真正棘手的是注意力计算与缓存管理。长上下文场景下，prefill 阶段的计算量随序列长度呈超线性增长，decode 阶段的 KV cache 显存占用可能远超模型权重本身。很多最新模型并不是单纯扩大上下文窗口，而是在注意力结构上做稀疏化、压缩和混合策略，以降低长序列场景下的计算与存储压力。
理解上述三个指标后，再看 MoE 模型的工程路线时，关注点就会从“谁的总参数更大”转向“谁的架构取舍更适合目标场景”。
MoE 模型在设计时需要做一个基础选择：是使用大量小专家，还是少量大专家。大量小专家意味着路由选择更灵活，但单个专家的表达能力有限；少量大专家则相反，单个专家能力更强，但路由选择的颗粒度更粗。不同模型系列在这个维度上的选择差异，直接影响了它们的总参数/激活参数比值，以及下游任务的适配难度。
路由器是 MoE 模型的核心组件之一。一个常见工程问题是专家负载不均衡——某些专家被频繁选中，另一些专家几乎闲置。这会导致两个后果：其一，计算资源利用率下降；其二，训练过程中部分专家得不到充分梯度更新。工程上通常需要引入辅助损失来鼓励负载均衡，但这又可能对模型表达能力产生轻微约束。不同模型在“路由自由度”与“负载均衡约束”之间的平衡点选择，是影响最终效果的关键因素之一。
长上下文场景下，标准注意力机制的复杂度是序列长度的平方级，这在 256K 甚至 1M 上下文中几乎是不可接受的。因此，MoE 大模型通常会在注意力层引入稀疏化、局部窗口、线性注意力近似或 latent cache 压缩等策略。这些策略在降低计算量的同时，也可能牺牲一定的远程依赖建模能力。如何在“省算”与“保持注意力质量”之间做权衡，是当前 MoE 架构演进的重要方向。
现代大模型不仅仅是文本生成器，还需要具备工具调用、代码执行、结构化输出等能力。这些能力的训练方式与纯文本预训练有明显差异：工具调用需要模型理解 API schema 与调用时机，代码环境需要模型具备执行反馈学习能力。在 MoE 架构下，这些能力往往集中在部分专家中，路由策略需要能够根据任务类型准确地将 token 分发到具备相应能力的专家上。这对路由器的训练数据分布与奖励信号设计提出了更高要求。
将多个 MoE 模型放在同一张表中观察，可以发现几条清晰的参数路线。
大池小激活路线：总参数规模在 500B 到 1T 以上，激活参数控制在 30B 到 40B 区间。这种路线的优势是知识容量大，适合作为通用底座模型；挑战在于分布式部署的复杂度较高，且专家通信开销在低延迟场景下可能成为瓶颈。
中等池中等激活路线：总参数在 200B 到 300B 区间，激活参数在 20B 左右。这种路线在能力与部署成本之间寻求平衡，适合对推理延迟有一定要求但又不愿牺牲太多知识广度的场景。
小池极低激活路线：总参数在 80B 以下，激活参数压缩到 3B 到 5B 级别。这种路线追求极致的单 token 计算效率，适合端侧或边缘部署场景。其核心挑战在于如何在极小激活预算下保持足够的表达能力与知识覆盖。
需要强调的是，参数路线本身没有绝对优劣之分。评价的维度应该是“目标场景下的综合收益”：一个在云上大规模部署的通用模型，适合走大池路线；一个需要在资源受限环境中运行的模型，则必须走极低激活路线。
基于以上分析，开发者在评估 MoE 模型时，建议从以下维度出发，而不是只看总参数或单一 benchmark 分数。
第一，明确目标场景的约束条件：是云上部署还是边缘部署？对首 token 延迟更敏感还是对吞吐量更敏感？上下文需求是 8K 还是 256K？这些约束会直接决定哪些参数路线是可行的。
第二，同时关注总参数与激活参数：总参数决定了知识广度，激活参数决定了单 token 前向预算。两者之间的比值在一定程度上反映了 MoE 架构的稀疏程度。稀疏比越高，单 token 计算越省，但对路由质量的要求也越高。
第三，关注注意力机制与缓存策略：长上下文场景下，注意力实现方式对性能的影响可能超过参数量本身。要关注模型是否采用了 KV cache 压缩、稀疏注意力或 latent cache 机制，以及这些机制在目标上下文长度下的表现。
第四，关注工具调用与代码能力的训练深度：如果目标场景涉及 Agent 或代码生成，需要考察模型在工具调用准确率、结构化输出一致性、多轮工具调用状态管理等方面的表现，而不是只看通用对话能力。
MoE 大模型的参数表从来不是一道简单的算术题。总参数、激活参数、上下文窗口、注意力实现、路由策略、工具能力训练——这些维度交织在一起，共同决定了一个模型在真实场景中的表现与成本。理解这些工程取舍，才能避免被“1T 参数”或“3B 激活”这样的数字误导，做出更理性的技术选型。