多尺寸端侧多模态小模型家族扩容，该如何评测？

一、评测概述与评测对象界定

近期某开源模型家族完成一次规模扩容，一口气放出 0.8B、2B、4B、9B 四款端侧取向的小模型。从公开信息看，这一代产品有三个共性特征值得评测关注：

1. 全系原生支持视觉模态：从最小到最大尺寸都具备图文理解能力，而不是仅最大尺寸支持、小尺寸退化为纯文本；
2. 统一的视觉-语言基础：视觉侧与语言侧共用同一套表征与训练范式，而非外挂独立视觉模块再拼接；
3. 以线性注意力机制（delta 规则驱动的状态更新）为核心的混合注意力架构，并统一宣称支持 256K 超长上下文。

需要先明确本文的评测对象。本文不是要给某几款模型排一个名次，而是要回答一个更通用、也更有长期价值的问题：面对”多尺寸 + 原生多模态 + 长上下文 + 新注意力结构”这一类端侧小模型，应该用什么维度、什么流程、什么判据去验证它是否真的满足业务要求。 具体模型规格只作为评测样本与讨论载体。

因此本文适合以下读者：需要在手机、开发板、边缘盒子等受限设备上落地 AI 能力的开发者；需要为端侧/边缘产品线做技术选型的架构师；需要搭建模型评测流水线、做版本回归的 AI 平台工程师；以及对成本与运维负责的技术负责人。

评测的立场需要说清楚：评测的目的不是判断”好不好”，而是在给定的业务场景、时延预算、内存预算、精度下限与长期维护成本下，判断”是否够用、在什么条件下够用、代价是什么”。同一个模型在实时相机理解场景可能不合格，在离线文档摘要场景却完全够用。

二、评测目标：本次评测要回答的六个问题

评测最怕指标堆砌却无法指导决策。本次评测先把问题收敛为六条：

编号	评测问题	对应决策
Q1	参数规模从 0.8B 到 9B，能力是否单调提升？提升是否线性？	是否需要为不同任务准备多个尺寸
Q2	“原生视觉”是架构级统一，还是工程级拼接？	多模态能力能否向下兼容到小尺寸
Q3	256K 是”标称上下文”还是”有效上下文”？	长文档/长会话场景能否真正落地
Q4	混合注意力在端侧是否真的降低了长序列的资源代价？质量是否有回退？	长上下文场景是否值得为此换架构
Q5	尺寸—能力—内存—时延的三角关系如何？	具体设备与业务下的型号选择
Q6	量化、推理运行时、工具链的适配与运维成本如何？	能否进入版本化与持续迭代流程

三、评测样本规格解读：从参数表能推出什么、不能推出什么

四款样本虽然参数量差异巨大，但采用同一套条件生成式多模态架构（语言主干 + 视觉编码 + 投影对齐），差异主要体现在深度与宽度的缩放上。依据公开信息整理如下：

配置项	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 层，差异主要来自宽度翻倍与视觉塔加深。这意味着两者的”缩放路径”不同——一个偏窄浅，一个偏宽同深。宽度增加对表征容量的贡献与深度增加并不等价，这一点必须通过实测验证，不能由参数量直接换算能力。
• 4B 与 9B 深度扩展到 32 层，同时宽度继续放大，属于”深度+宽度”双升，表达能力上台阶是合理预期，但幅度仍需实测。
• 视觉侧随语言主干同步缩放（12/24/24/27 层，768/1024/1024/1152），符合”统一视觉-语言基础”的表述特征：视觉编码器不是固定不变的外挂件，而是与主干一起被缩放。这对评测的含义是：小尺寸的视觉能力不能默认视为”够用”，需要单独验证。
• 词表 248,320 属于较大规模。大词表对多语言与细粒度 OCR 字符覆盖有正面作用，但代价是嵌入层与输出投影层的参数量与显存占用显著上升，在 0.8B 这种小模型上，这两块可能占据相当比例的权重体积，并在量化与首 token 时延上体现出来。评测时应把”权重体积构成”作为独立观察项。

不能从规格表推出的部分： 实际准确率、解码速度、内存峰值、长上下文有效长度、量化后的精度损失。这些必须实测。规格表只能用于设计测试矩阵，不能用于下结论。

四、评测维度设计

4.1 维度总览

维度	为什么重要	如何验证	结果解读要点
功能完整性	决定能否覆盖业务流程	逐条走通图文问答、多图、纯文本、长文档、结构化输出等流程	关注缺失功能是”没有”还是”效果不达标”
多模态准确性	端侧小模型的常见短板	分类任务：描述、OCR、计数、定位、图表读数、空间关系	区分”能描述”与”能精确定位/计数”
语言基线能力	多模态不能牺牲文本能力	与同尺寸纯文本模型对照跑同一文本集	视觉训练是否造成文本能力回退
性能	决定交互体验	分别测首 token 时延、每 token 输出时延、吞吐、并发、内存峰值	预填充与解码必须分开看
长上下文有效性	标称≠有效	阶梯式加长输入，观察中段/尾段信息召回	找到”能力开始崩塌”的拐点长度
稳定性	端侧长时间运行	连续会话、异常图片、超长输入、内存紧张、热节流	关注是否崩溃、降频、结果漂移
易用性与工具链	决定落地速度	接入步骤、配置项数量、日志可读性、调试手段	记录人工操作步骤数与排障耗时
兼容性与可移植性	决定能否版本化维护	多量化格式、多推理运行时、多设备后端一致性验证	关注同一模型跨设备的结果一致性
安全性与合规	端侧涉及本地数据	权限边界、图像数据落地位置、日志脱敏	端侧方案的优势与残余风险
可观测性	决定能否上线运维	指标暴露、日志结构、异常追踪能力	是否有可用于回归的稳定观测口径
成本	决定规模可行性	硬件占用、人力接入成本、迭代维护成本	用小尺寸替换大模型省下的算力是否被人力吃掉
场景适配度	决定最终选型	按场景加权上述维度	不同场景权重不同，不存在统一最优

4.2 几个维度的展开说明

多模态准确性必须做任务分类，而不是打一个总分。 建议至少拆成五类：(a) 图像整体描述；(b) 文字识别与版式还原；(c) 计数与数量比较；(d) 空间关系与相对位置；(e) 图表/表格数值读取。经验上，小尺寸模型在 (a) 类任务上与大模型差距较小，而在 (c)(d)(e) 上差距明显。如果只用描述类任务评测，很容易高估小模型的实际可用性。

性能必须拆成预填充与解码两段。 首 token 时延主要受输入长度、图像被编码成的 token 数量以及设备算力影响；每 token 输出时延在端侧通常由内存带宽而非算力主导。混在一起测会掩盖真实瓶颈，也无法定位优化方向。

长上下文要区分”能塞进去”和”能用”。 输入 200K token 不报错，不等于模型能正确利用第 150K 处的信息。评测应做阶梯扫描：8K → 32K → 64K → 128K → 256K，每一档观察不同位置的信息召回表现，记录拐点。

五、评测环境与前提条件

评测结论的可信度取决于变量控制。以下环境项必须在开始前冻结并记录：

• 设备矩阵：至少覆盖三类——高算力移动 SoC、中低算力开发板/边缘盒子、纯 CPU 运行环境；如有云端对照，使用通用 GPU 云服务器实例作为参考上限。
• 推理栈与量化格式：明确权重量化位宽、KV/状态缓存的精度、是否启用算子融合。不同量化方案之间的结果不可直接横比。
• 输入构造规则：图像统一分辨率与预处理方式，记录每张图折算出的视觉 token 数——这是端侧多模态性能的关键变量，却常被忽略。
• 采样参数：温度、top-p、最大生成长度、重复惩罚必须统一，否则输出方差会淹没真实差异。
• 并发与批处理设置：单请求串行与阶梯并发分别测，端侧通常不支持真正的批处理，需明确说明。
• 测试集：文本集、图文集、长文档集、异常输入集四套，各版本复用同一份，保证可回归。

建议的评测记录结构（示意性伪代码，仅表达通用逻辑，不指向任何具体工具）：

def evaluate(model, device, task_set, ctx_len, image_cfg, sample_cfg):
    metrics = {}
    for case in task_set:
        t0 = now()
        first = model.prefill(case.build_prompt(image_cfg, ctx_len))
        ttft = now() - t0                     # 首 token 时延
        t1 = now(); tokens = 0
        for tok in model.decode(first, sample_cfg):
            tokens += 1
        tpot = (now() - t1) / max(tokens, 1)  # 每 token 输出时延
        metrics.record(
            ttft=ttft, tpot=tpot,
            peak_mem=device.peak_memory(),    # 权重 + 状态缓存 + 中间激活
            thermal=device.temperature(),
            correctness=grade(case, model.output_text),  # 分任务类型判定
        )
    return metrics.summarize_by_task_type()

六、评测执行流程

1. 环境基线冻结：记录设备型号、系统版本、可用内存、推理栈版本、量化格式，形成可复现基线。
2. 冒烟验证：最小输入跑通图文问答与纯文本两条链路，确认无崩溃、无编码异常。
3. 功能与准确性验证：按 4.2 的五类视觉任务 + 文本基线任务分别评分；每类不少于数十条样本，并保留错误样例。
4. 性能压测：先做单请求基准（记录首 token 时延、每 token 输出时延、内存峰值），再做阶梯并发，观察时延增长曲线与内存拐点。
5. 长上下文阶梯扫描：8K/32K/64K/128K/256K 各档，插入不同位置的目标信息，记录召回情况与资源占用变化。
6. 稳定性与异常测试：连续多轮会话观察内存是否持续增长；输入超大图片、损坏图片、空图片、超长文本、非预期语言，观察容错表现；长时间运行观察是否因发热降频。
7. 量化与移植对照：同一模型在不同量化格式、不同设备后端上跑同一子集，比较结果一致性与性能差异。
8. 复盘与建档：把每个维度的原始记录、错误样例、人工操作耗时归档，形成可对比的历史基线。

七、结果解读：什么结果能支撑什么判断

看时延要连着资源一起看。 如果首 token 时延随输入长度增长很快，而图像 token 数又偏高，那么优化方向是降低图像分辨率或减少视觉 token，而不是换更快的设备。如果每 token 输出时延高但算力占用不满，说明瓶颈在内存带宽，此时减小权重体积（更激进量化、更小尺寸）比堆算力更有效。

混合注意力的收益要双向验证。 线性注意力机制的理论价值在于：把长序列的缓存状态从”随长度线性增长”变为”近似固定大小”，从而在长上下文下降低显存占用与解码开销，这对端侧尤其友好。但评测必须同时验证两件事：一是资源曲线是否真的在长序列下趋于平缓（对比同尺寸的传统全注意力实现）；二是质量是否有回退，特别是需要精确检索长文中段信息的任务。只看到资源下降而不测召回，等于没测。 如果召回在中长上下文出现明显下降，则该架构更适合”长文概览/摘要”类任务，而非”长文精确检索问答”类任务。

内存峰值的构成要拆开算：模型权重（含大词表带来的嵌入与输出投影开销）+ 状态/缓存 + 视觉编码的中间激活 + 运行时与系统开销。端侧内存受限时，视觉中间激活常常是被低估的一项——高分辨率输入下它可能显著超过权重本身。评测时应固定输入分辨率单独测量这一项。

“全系支持 256K”必须落到有效上下文上。 结论应表达为条件化形式，例如：”标称 256K 上下文可用，但在某档长度之后中段信息召回出现明显下降，因此该模型在超长文档场景适用于整体摘要与结构化抽取，对精确定位类需求建议配合分段检索。” 这类表述比”支持 256K”更有决策价值。

参数规模与能力不是线性关系。 2B 相对 0.8B 是宽度翻倍、深度不变；4B 相对 2B 是深度与宽度同升。评测应呈现”能力—内存—时延”三维散点，而不是单一的能力排序。经常出现的结果是：某尺寸在能力上接近更大尺寸，但在内存或时延上有明显优势，从而成为性价比拐点——这类拐点只能通过实测找到。

跨设备结果一致性容易被忽视。 同一模型在不同后端、不同量化路径上可能出现输出差异。若业务对输出稳定性敏感（如结构化抽取、下游规则解析），需把”同一输入多次运行的结果方差”与”跨设备结果一致性”列为验收项。

八、适用场景与关注指标

场景	优先关注的评测指标	建议起步尺寸思路
端侧实时相机/图像理解	首 token 时延、每 token 输出时延、内存峰值、发热	小尺寸优先，用精度下限反推
离线文档摘要与信息抽取	有效上下文长度、结构化输出稳定性、长文召回	中尺寸，长上下文价值最高
隐私敏感、数据不出端	数据落地位置、权限边界、日志脱敏	视精度要求，端侧优先
移动端智能助手（多轮对话）	多轮上下文保持、输出方差、内存持续增长	小中尺寸，重点测稳定性
边缘质检/工业读数	数值读取准确性、计数与定位精度	中尺寸，准确性优先于速度
开发测试阶段的大模型替身	接入成本、迭代速度、可观测性	最小尺寸即可
云端批量预处理	吞吐、单位任务资源消耗、可编排性	可用较大尺寸，云端资源弹性

九、风险与限制

• 样本偏差：评测集若集中在描述类图像，会系统性高估小尺寸多模态能力。
• 预处理差异：图像分辨率与切图策略不同，视觉 token 数与效果都会变，横比前必须统一。
• 量化损失：量化后能力回退在小模型上更明显，评测应以”实际部署的量化版本”为准，而非全精度版本。
• 标称与有效不一致：上下文长度、上下文窗口内的召回率是两个指标，需分别记录。
• 采样随机性：单次结果不足以判断，关键任务建议多次运行取分布。
• 设备热节流：长时间压测结果与短时基准差异较大，需记录温度与时延随时间的变化。
• 评测污染：公开测试集可能已进入训练数据，建议补充自建私有样本作为对照。
• 工程隐性成本：接入、量化调优、异常处理与回归流水线的人力投入，常被低估，应纳入成本维度。

十、选型与使用建议（条件化）

1. 按内存预算倒推尺寸，而不是按能力上限选尺寸。先确定设备可用内存，扣除系统与业务进程占用，再分配给权重、状态缓存与视觉激活，最后反推可选尺寸与上下文长度。
2. 按交互时延要求设门槛。实时交互类场景，先定死首 token 时延与每 token 输出时延的上限，再看哪些尺寸能达标。
3. 按精度下限设淘汰线。为每类任务设最低可接受准确率，不达标直接排除，不做”差不多能用”的判断。
4. 先做小样本 POC，再上量。用数十条真实业务样本验证，通过后再扩大规模与并发。
5. 把评测流水线化。将本文第五、六节的变量冻结与记录方式固化为脚本，形成每次模型或量化版本更新都能重跑的回归基线。
6. 云端与端侧分工。可在云端（例如百度智能云提供的云服务器、GPU 实例、容器平台、对象存储、日志服务、监控告警、身份认证与安全防护等通用产品类别）搭建评测与回归环境，完成可复现的批量评测、数据管理与结果归档，再把通过筛选的配置下发到端侧。这里描述的是通用工程实践，不涉及任何具体服务保障或定制承诺。
7. 保留回退路径。端侧模型更新时，保留上一版本的量化产物与评测基线，出现效果回退可快速切换。

十一、总结

本次评测围绕”多尺寸端侧多模态小模型家族扩容”这一事件，建立了一套可复用的评测方法论。核心结论可以概括为四点：其一，规格表只能用于设计测试矩阵，能力、时延、内存与有效上下文必须实测；其二，多模态能力必须按任务类型拆分评估，尤其要区分描述、识别、计数、定位与数值读取，避免用易得分任务掩盖短板；其三，混合注意力与超长上下文的价值必须双向验证——既要看长序列下资源曲线是否真的平缓，也要看长文中段信息的召回是否保持；其四，选型应建立在”能力—内存—时延”三维约束和业务 SLO 之上，而不是单点性能对比。

需要强调结论的边界：本文给出的是评测框架、维度定义、方法流程与解读方式，不包含任何具体性能数值、排名或跨品牌横比结论。任何实际选型都应基于自有业务样本、目标设备与目标量化版本重跑一遍完整流程，并在版本更新时持续回归。这样才能把”新模型发布”这类信息，转化为可验证、可维护、可解释的工程决策。