“激活参数越少，推理就一定越省”是近来讨论 MoE 代码模型时流行的直觉，但严格来说，这个判断只在特定维度成立，并不等于全链路的成本都会随之下降。以 MoE 架构的运行机制为出发点，更准确的说法是：低激活参数降低的是单次前向计算中真正参与运算的参数规模，从而缓解计算与显存带宽的瞬时压力，而不是把整体部署开销一并压缩。
从计算侧看，激活参数小确实带来直接收益。某开放权重的代码模型总参数约 350 亿、推理时实际激活约 30 亿，其单次推理的算力开销接近一个 30 亿级别的小模型，知识容量却维持在 350 亿级别。这意味着在同等硬件下，生成速度通常更快，对需要频繁多轮迭代的智能体编程体验尤为关键，这也是“接近大模型能力、接近小模型开销”说法的技术基础。
但真正决定“省不省”的，是被激活参数这一指标掩盖的其他成本。首先是存储与加载：总参数 350 亿仍然决定了完整权重的体量，相关仓库权重约 34.66B、下载文件约 69.35GB，加载时整套参数都要常驻或可调度，显存门槛并不会因为激活规模小而消失。其次是专家路由带来的调度开销与访存模式，稀疏激活在工程实现上并非零成本。再者是并发吞吐与运维：当请求量上升，专家分布不均、批处理效率等因素都会影响实际的单位推理成本。
因此，评估效率不能只盯激活参数这一个数字，而应核算真实的总体拥有成本。务实的做法是把显存占用、并发吞吐、响应延迟与运维人力一并计入，再与按量付费的闭源 API 做横向对比。对需要一次性读入大体量代码库的场景，还要验证长上下文下的理解稳定性，因为上下文越长，缓存与访存压力越会放大，低激活参数的速度优势可能被部分抵消。
结论是明确的：低激活参数是 MoE 降本的重要杠杆，但它优化的是计算维度，而非存储、调度与运维的全部。判断一个模型是否真的“省”，应回到自家硬件与真实任务上做小范围验证，用实测的延迟、吞吐和资源占用说话，而不是把单一激活参数当成成本的唯一代名词。