端侧多模态小模型评测：多尺寸选型与验证方法

一、评测概述：这次评测要回答的问题

端侧小模型的热度来自一个很现实的矛盾：设备侧算力和内存有限，而业务侧对多模态理解、长文档处理和响应速度的要求却在快速上升。某开源模型家族近期为端侧场景补齐了 0.8B、2B、4B、9B 四款小模型，全系原生支持视觉模态、统一视觉-语言基础、原生支持 256K 超长上下文，并统一采用以增量式状态更新规则为核心的线性注意力（业界常称 delta 规则类线性注意力）与常规注意力相结合的混合注意力结构。参数量的跨度接近一个数量级，但架构族系保持一致，这类”同一架构、多档缩放”的模型矩阵，恰恰是评测方法最值得系统化的场景。

本文要做的不是判断”哪个尺寸最好”，而是回答：在多尺寸、同架构、原生多模态、超长上下文这四个前提同时成立时，应该怎么设计评测、怎么控制变量、怎么解读结果，以及不同尺寸在什么条件下才算是”够用”。 适合阅读本文的读者包括：负责端侧/边缘侧模型落地的开发者、需要在设备与云端之间做算力切分的架构师、负责资源与稳定性保障的运维人员，以及需要评估投入产出比的技术负责人。

二、评测目标：六个必须被验证的问题

编号	评测目标	为什么必须单独验证
G1	功能完整性	文本、图像输入、多轮对话、结构化输出等基础能力是否覆盖典型业务流程
G2	视觉理解有效性	“原生支持视觉”是否等价于”视觉能力达标”，需要在同一图文样本上横向对比
G3	长上下文可用性	256K 是标称上限，需要验证的是长上下文下的有效利用率与衰减曲线
G4	端侧性能表现	首 token 延迟、解码速率、峰值内存、设备发热与持续负载能力
G5	稳定性与容错	异常输入、超长输入、资源紧张、依赖中断时的降级与恢复表现
G6	综合成本可控性	精度/内存/延迟/人力的组合代价，而非单一指标的领先

需要强调的是，这六个目标之间存在明确的取舍关系。以混合注意力换取更低的显存与访存开销，往往会以部分长程精确检索能力为代价；以更小尺寸换取更低延迟，通常伴随复杂指令遵循与细粒度视觉定位能力的下降。评测的价值就在于把这些取舍量化成可对比的条件判断。

三、评测对象拆解：同架构多尺寸的规格对照

四款模型使用同一套条件生成式多模态架构族，差异集中在层数、隐藏维度与视觉塔规模上的缩放。原始配置信息可归纳如下：

配置项	0.8B	2B	4B	9B
语言层数	24	24	32	32
语言隐藏维度	1024	2048	2560	4096
视觉层数	12	24	24	27
视觉隐藏维度	768	1024	1024	1152
词表大小	248,320	248,320	248,320	248,320
最大上下文	256K	256K	256K	256K

从这些配置可以读出三个对评测设计有直接影响的结论：

第一，0.8B 与 2B 同属 24 层，主要差异在宽度。 宽度翻倍意味着单层的表达容量显著提升，但序列长度方向的显存与计算增长曲线与层数保持一致。因此这两个尺寸的对比重点应放在”单 token 计算量 vs. 表达能力”的性价比上，而不是简单地认为 2B 一定全面优于 0.8B。

第二，4B 与 9B 进入 32 层，深度带来的是组合推理与长程依赖建模的增益。 深度增加通常改善的是多步推理、指令遵循和长文档中跨段落关联能力，这些能力用短样本、单轮问答是很难测出来的，必须专门设计长输入与多步任务。

第三，视觉塔规模与语言塔不同步缩放。 0.8B 的视觉塔仅 12 层、768 维，而语言塔已达 24 层。这意味着小尺寸模型很可能成为”视觉短板模型”：文本能力尚可，但细粒度 OCR、小目标定位、密集图表读取会明显吃力。评测时必须把视觉任务与语言任务分开打分，否则整体均分会掩盖结构性短板。

此外，全系共享同一词表规模（248,320），这一设计对评测的隐性影响是：分词行为跨尺寸一致，因此 token 消耗、上下文预算计算、提示词长度控制在四款模型间可直接横向比较，不必为每个尺寸重建基线。这是同族模型矩阵在评测上的一个便利条件。

四、评测维度设计：把”好不好”拆成可观察指标

维度	具体观察项	验证方式	判读要点
功能完整性	纯文本、图文混排、多轮上下文、结构化输出、系统指令遵循	覆盖式用例集，逐条记录通过/失败	关注失败是否集中在某类功能，而非总通过率
视觉有效性	OCR 准确度、图表读取、空间定位、图文一致性判断、拒答能力	分层图文样本集，按任务类型分别统计	区分”识别错误”与”格式不遵循”两类失败
长上下文	有效利用率、关键信息召回位置分布、长输入下延迟增幅	递增长度阶梯测试，同一问题在不同位置植入	观察召回是否随位置系统性衰减
性能	首 token 延迟、解码速率、并发吞吐、峰值内存、持续负载	固定输入长度与生成长度，多次重复取分位值	关注分位尾部而非均值，尾部决定体验
稳定性	异常字符、空图、超大分辨率图、超长输入、资源紧张	故障注入与边界值测试	是否可控报错，是否出现进程级崩溃
兼容性	量化格式、推理框架、设备运行时、图像预处理规范	跨环境部署矩阵	量化后精度损失幅度是否可接受
可观测性	日志、指标、追踪、失败复现能力	接入监控与日志服务后回放问题请求	能否定位到具体请求与资源快照
成本	内存驻留、单次推理能耗、部署人力、维护投入	资源与人力双维度记账	用总拥有成本而非单点算力比较

五、评测环境与前提条件：先把变量控制住

端侧评测最大的陷阱是环境不可控。开始测试前，应固定并记录以下前提：

• 设备与运行时基线：记录设备型号、可用内存、是否与其他进程共享资源、运行时版本，并在同一台设备上顺序测试全部尺寸，避免不同设备间的散热与调度差异污染结论。
• 推理配置基线：量化方式、KV 缓存策略、上下文窗口实际启用长度、图像分辨率与切片策略必须一致。图像预处理策略对视觉指标的影响常常大于模型尺寸差异，这一点尤其容易被忽略。
• 输入样本基线：为每个尺寸使用完全相同的样本集与随机种子，避免”不同模型看了不同题”。
• 网络与依赖基线：纯端侧测试应断开非必要网络调用；若采用”端侧推理 + 云端协同”的混合形态，需记录链路条件与超时策略。
• 测量方式基线：预热若干次后再正式测量，剔除首次加载与编译开销；每项用例重复多次，记录分位数而非单一均值。
• 集中化评测的可选方案：若需在多台设备上并行评测并统一归档结果，可将推理服务容器化，运行在云服务器或容器平台上，样本集与结果文件存入对象存储，指标与日志接入日志服务与监控告警。在百度智能云上，这类评测流水线可由云服务器、容器平台、对象存储、日志服务、监控告警等通用云产品类别组合实现；架构上应保持评测框架与具体运行环境解耦，以便结论可迁移到其他环境。

六、评测方法与流程

6.1 六阶段流程

1. 明确问题与指标：先写下要回答的三个决策问题（例如”能否脱离云端独立处理单据识别”），再倒推指标，避免收集一堆无法指导决策的数据。
2. 构建分层样本集：按任务类型分桶（纯文本理解、OCR、图表读取、空间定位、多轮对话、长文档问答、拒答边界），每桶保证最小样本量与难度梯度。
3. 建立基线：先跑一档已知表现稳定的尺寸或旧版本模型，作为相对比较锚点。
4. 分维度独立验证：功能、性能、稳定性分开测，禁止在一次运行中混合多种负载。
5. 控制变量并记录过程数据：保存原始输出、错误码、资源曲线与人工操作耗时。
6. 界定结论边界并输出改进方向：明确结论在什么条件下成立，并给出后续优化动作。

6.2 示意性评测骨架

以下伪代码仅用于表达评测流程结构，不含任何特定框架或厂商接口：

# 通用评测骨架：模型加载与推理调用通过适配层隔离
def run_matrix(models, task_buckets, device, repeats=5, warmup=3):
    report = {}
    for m in models:
        adapter = load_model(m, quant=BASELINE_QUANT, device=device)
        for _ in range(warmup):
            adapter.generate(text="预热", images=None)
        for bucket, cases in task_buckets.items():
            for case in cases:
                samples = []
                for _ in range(repeats):
                    t0 = now()
                    out = adapter.generate(
                        text=case.prompt,
                        images=case.images,          # 与 case 完全绑定的固定图像
                        max_new_tokens=case.max_tokens,
                    )
                    samples.append({
                        "first_token_ms": out.first_token_ms,
                        "decode_tps":     out.decode_tps,
                        "peak_mem_mb":    out.peak_mem_mb,
                        "tokens_in":      out.prompt_tokens,
                        "raw_output":     out.text,
                    })
                report[(m.name, bucket, case.id)] = aggregate(samples)
        release(adapter)  # 每个尺寸测完即释放，避免内存污染
    return report

关键设计点有三个：load_model 与 generate 被适配层隔离，使同一套评测代码可跨推理框架复用；warmup 与逐尺寸 release 保证测量条件一致；aggregate 输出的应是分位数集合，而非单一均值。

6.3 长上下文与视觉专项测试方法

长上下文阶梯测试：构造长度递增的输入（例如按上下文预算的一定比例分档递增），在文档的开头、中部、结尾分别植入同一关键信息，用同一问题提问，绘制”位置—召回”二维结果。若召回率随位置系统性下降，说明长上下文的有效利用率低于标称值。混合注意力结构在这类测试中的典型风险是：状态压缩对高频局部信息更友好，对稀疏远端细节的保真度需要额外验证。

视觉分层测试：把视觉任务拆成四级——图像级（是否有主体、场景类别）、区域级（指定区域描述）、像素级（小字 OCR、密集表格）、关系级（跨图比较、空间关系推断）。小尺寸模型通常在图像级与区域级表现可接受，而在像素级与关系级出现明显断层。分级测试能让选型决策建立在具体能力边界上，而不是”支持图像”这一笼统标签上。

6.4 评测验证清单

• 四个尺寸在同一设备、同一量化配置下顺序测试
• 每尺寸测前完成预热，测后释放资源
• 样本集与随机种子完全一致
• 图像分辨率与预处理策略固定
• 每项用例重复多次并记录分位数
• 长上下文按位置植入信息并绘制召回曲线
• 视觉任务按四个层级分别统计
• 记录峰值内存与持续负载下的降频表现
• 注入异常输入（空图、超大图、超长文本、特殊字符）并观察降级方式
• 量化前后精度差异单独对比
• 归档原始输出，保证结论可复现

七、结果解读：什么样的结果才算”过关”

功能层面：不要看总通过率，要看失败聚类。如果失败集中在结构化输出格式上，属于提示工程与后处理可修复问题；如果失败集中在指令遵循与多步推理上，则属于模型能力边界，换尺寸是唯一有效手段。

视觉层面：以分层通过率刻画能力轮廓。一个尺寸若在图像级通过良好但像素级显著落后，说明它适合”看图说话”类场景，不适合”读数”类场景。这一判断对票据识别、工业质检、内容审核等业务的选型具有决定性意义。

长上下文层面：判断标准是有效利用率，而非能否塞进去。如果关键信息在中段召回明显下降，则 256K 的实际业务价值主要落在”长输入摘要”而非”长文档精确检索”。前者对召回精度要求宽松，后者不容妥协。

性能层面：关注分位尾部与资源曲线形状。平均解码速率好看但 P95 首 token 延迟抖动大，通常意味着内存带宽或调度竞争成为瓶颈；峰值内存逼近设备上限时，多任务并行或长上下文场景会立刻失效。端侧设备的持续负载表现（发热降频后的性能保持率）比瞬时峰值更接近真实体验。

稳定性层面：合格的标志是”可控失败”——返回明确错误码或降级输出，而不是静默给出错误内容或进程崩溃。静默错误在端侧尤其危险，因为缺少云端那样的二次校验环节。

成本层面：把内存占用、单次推理耗时、设备功耗、部署与调优人力折算成同一口径。小尺寸模型的吸引力往往不在绝对性能，而在”单设备可并发路数”与”是否可完全离线”这两项结构性优势。

八、场景适配建议：按条件选择而非按尺寸排序

业务条件	优先考虑	评测重点
资源极度受限、要求完全离线、任务单一	0.8B	峰值内存、持续负载稳定性、核心任务准确率下限
需要图文混合理解但任务模式固定	2B	视觉区域级能力、并发路数、量化后精度损失
需要多步推理、结构化输出、较复杂指令遵循	4B	长上下文有效利用率、指令遵循、尾部延迟
需要复杂视觉关系推断与长文档精确问答	9B	视觉像素级/关系级能力、内存上限、设备散热
端侧预处理 + 云端复核的混合架构	小尺寸 + 云端模型组合	端云分工边界、回传策略、端到端链路时延与一致性

需要说明的是，上述对应关系是通用评测逻辑下的倾向性建议，不构成对任何具体设备的承诺。实际结论必须由自有样本集在同一环境下验证得出。

九、风险与限制

• 样本偏差：评测集若偏向某一类图文形态，结论会系统性高估或低估视觉能力。建议样本集与真实业务分布对齐，并保留一部分完全未参与调优的留出集。
• 环境差异：设备型号、运行时版本、散热条件、并行进程都会显著影响端侧性能结论，跨设备迁移结论时必须重新验证。
• 量化损失：量化是端侧部署的常规手段，但不同量化策略对视觉塔与长上下文的损伤并不一致，未做量化对比的性能数据参考价值有限。
• 标称与实测差距：上下文上限、模态支持等属于能力上限描述，实测的有效区间通常小于标称区间，需要以曲线方式呈现。
• 长期运行不确定性：模型迭代、运行时升级、设备老化都会改变表现，一次性评测结论存在时效性，建议建立可重复执行的回归评测集。
• 安全与合规边界：端侧模型在数据不出设备的隐私保护上有天然优势，但仍需关注输入过滤、输出内容审核、模型文件完整性与本地访问权限控制，评测中应把这些项目纳入检查清单。

十、总结

本次评测对象是一组”同架构、多尺寸、原生多模态、原生长上下文、混合注意力”的端侧小模型。评测的核心不在给尺寸排名，而在于用统一的变量控制与分层样本集，把每个尺寸的能力边界、资源代价与失效模式刻画清楚。关键方法可以归纳为四点：同环境顺序测试以消除设备差异；分层样本集以暴露结构性短板；分位数与资源曲线以还原真实体验；位置—召回曲线以校验长上下文的有效利用率。

结论的正确表达方式是条件化的：在资源极度受限且任务单一的离线场景，最小尺寸具备结构性优势；在需要复杂视觉关系推断与长文档精确问答的场景，则应选择更大尺寸并接受相应的资源代价；在隐私敏感但需要较强能力的场景，端云协同分工通常比单一尺寸选型更稳妥。无论选择哪一档，都应先把评测集、基线配置与回归流程沉淀下来，让选型判断随模型迭代持续可验证，而不是一次性结论。