本地大模型选型指南：MoE与密集架构如何评测

一、为什么本地部署要先看架构

在本地或私有化环境跑大模型，硬件预算通常是硬约束。同一个模型系列往往会同时提供混合专家（MoE）规格和密集（Dense）规格。两者在显存、速度和效果上的差别很大，选错会浪费硬件投入，或者让服务无法满足延迟要求。

本文以某系列大模型的三个代表性规格为例，讲解评测思路：

• 35B-A3B：MoE架构，总参数约350亿，每个token推理时激活约30亿。
• 397B-A17B：MoE架构，总参数约3970亿，每个token激活约170亿。
• 27B：密集架构，总参数约270亿，每次前向计算动用全部参数。

这里的B表示十亿，因此35B是350亿，397B是3970亿。对照其他资料时，先统一换算单位，避免把参数数量读错一个数量级。

二、两种架构的根本差异

MoE模型包含大量专家子网络，推理时每个token只经过路由选中的少数专家。它的资源压力分成两部分：

• 显存或内存压力取决于总参数量，因为所有专家都要加载到内存中。
• 计算压力取决于激活参数量，因为每次计算只动用其中一小部分。

密集模型没有这种拆分。全部参数既要常驻内存，每次计算也要全部参与。

据此可以得出两条判断规则：能不能加载，看总参数；跑得快不快，主要看激活参数。这两条规则是解读后续所有测试数据的基础。

规格	架构	总参数	激活参数	显存压力来源	计算压力来源
35B-A3B	MoE	约350亿	约30亿	总参数	激活参数
397B-A17B	MoE	约3970亿	约170亿	总参数	激活参数
27B	密集	约270亿	约270亿	总参数	全部参数

推理速度还受框架实现、内存带宽、批大小和缓存策略影响。激活参数能说明速度的大致方向，但不能替代实测。

三、评测前要回答的四个问题

动手测试之前，先把问题定义清楚。否则会得到很多数字，却无法据此做决定。

1. 能不能跑：加载后的内存或显存占用，是否在目标硬件预算内。
2. 跑得快不快：tokens/s和首token延迟，能否满足交互或批处理需求。
3. 效果够不够用：输出质量与业务要求相比差距多大，能否接受。
4. 代价是什么：量化带来的质量损失、冗余输出带来的后处理成本，以及部署和运维的人力投入。

四、评测维度设计

评测不能只写”速度快、效果好”，要拆成可观察、可验证的指标。

评测维度	验证重点	验证方法
资源占用	加载内存、峰值显存、推理时的资源水位	加载后记录系统监控读数
推理性能	tokens/s、首token延迟、长输出的速度衰减	固定输入输出长度，多次采样取统计值
输出质量	基准任务得分、业务样本通过率、逻辑正确性	公开基准集加自建业务样本双轨评估
稳定性	长时间运行、长上下文、异常输入下的表现	持续压测与边界输入测试
易用性	部署步骤、配置复杂度、文档完整度	记录从零到跑通的部署耗时
兼容性	推理框架、量化格式、硬件后端	跨环境交叉验证
成本结构	硬件、能耗、运维、迁移成本	汇总一次性成本和长期成本

每个结果都要能回答”为什么”。速度差异可能来自激活参数量、量化位宽、缓存策略或硬件后端，不能简单归因于模型大小。

五、固定评测环境

任何一项条件变化，都会让数据失去可比性。测试前应固定以下内容，并写入环境记录表：

• 硬件：GPU型号、显存容量、CPU型号、内存容量。纯CPU环境和GPU环境应分别跑一轮。
• 软件：推理框架及版本、驱动版本、操作系统版本。
• 量化：Q4与Q8分别测试，不混用。同时记录量化工具和版本。
• 采样与长度：温度、top-p、输入长度、最大输出长度保持一致。
• 预热：排除首次加载和编译对计时的影响。
• 并发与批大小：说明是单请求还是多请求，并写明批大小。

没有记录环境的速度数字，只能用于内部参考，不宜对外引用。

六、评测流程

1. 锁定第三节的四个问题。
2. 设计测试样本：公开基准集、自有业务样本，以及少量简单逻辑题。简单逻辑题用于检查模型是否”小题大做”。
3. 建立基线：选一个参照规格跑出基准数据，后续所有对比都以它为准。
4. 分维度验证：资源、速度、质量、稳定性分开测，避免相互干扰。
5. 控制变量：每次只改一个条件，例如只换量化档位。
6. 保留原始日志，便于回溯。
7. 写清结论的适用边界。

性能测试的基本结构如下：

加载模型(规格, 量化档位)
预热(固定prompt × 3次)
for i in 1..N:
    记录开始时间
    生成(固定输入, 固定最大输出长度)
    记录结束时间与输出token数
统计 tokens/s 的均值与分位数

N应取足够的次数，并同时报告分位数，不能只报平均值。质量评估建议同时使用自动指标、人工盲评和任务通过率。

七、如何解读测试结果

本节给出解读方法。具体数值需要读者在自己的环境中测得后再使用，本文不提供可直接引用的速度或质量百分比。

第一，速度差异先看激活参数。 如果一个MoE模型的总参数远大于某个密集模型，但激活参数更小，它在单请求场景下的速度可能更快。这一趋势在多组测试中较常出现，但幅度取决于硬件和框架。

第二，量化通常能提速，但质量损失要分任务看。 降低位宽后，每次解码需要读取的权重变少，速度往往明显提升。提速倍数因硬件和后端而异，不能套用固定值。平均分下降不大，不代表数学和代码等精确性任务也受影响小。应在这类任务上单独测试，并查看失败样本是否集中出现。

第三，基准分数不能代替业务验证。 某模型在公开基准上接近旗舰水平，不代表它在你的业务上也能达到同样效果。先确认基准与业务分布的差异，再决定是否采信结论。

第四，负面结果同样重要。 在简单逻辑任务上，模型可能思考时间偏长，回复中也可能