一、评测概述

近期，某主流开源大模型团队在完成新一代基座架构升级后，一口气发布了四款端侧小模型，参数规模分别为0.8B、2B、4B和9B。与许多“先做大再裁剪”的端侧产品不同，这批模型全系原生支持视觉模态，从最小的0.8B到最大的9B均具备图文理解能力，并统一支持256K超长上下文，这在端侧小模型中并不多见。加上该家族此前已有32B级推理模型面向服务端复杂推理场景，整体形成了“云端大模型+端侧小模型”的完整梯度。

本文的评测对象就是这四款端侧多模态小模型。需要说明的是，端侧模型评测不是简单回答“好不好用”，而是要结合目标设备档位、业务任务复杂度、内存与功耗预算、长期维护成本来综合判断。通过本文，读者可以获得三方面信息：这批模型在架构层面的核心亮点是什么；如何在真实设备上科学地验证这些亮点；不同参数规模分别适合承接哪类业务任务。

本文适合的读者包括：需要在手机、平板、IoT设备上落地AI能力的端侧开发者；负责技术选型的架构师与技术负责人；以及需要评估“端侧部署 vs 云端调用”成本收益的企业技术团队。

二、评测目标

结合端侧场景的特点，本次评测重点回答以下五个问题：

1. 功能完整性：图文理解能力是否在全部四个尺寸上真实可用，长上下文能力是否可以达到标称量级；
2. 资源效率：混合注意力架构带来的内存节省，在真实设备上是否可观测、可复现；
3. 性能表现：不同尺寸在典型设备上的首字延迟、稳态生成速度、内存峰值处于什么水平，如何测量；
4. 量化可行性：采用4-bit权重量化后，模型能力衰减是否在可接受范围内；
5. 场景适配：哪些任务适合下沉到端侧，哪些任务应保留在云端，端云如何分工。

围绕这些问题，下文先拆解评测对象的架构，再给出评测维度、测试环境、测试方法与结果解读框架。

三、评测对象解析：三个值得关注的架构亮点

3.1 统一架构、差异化缩放

四款模型虽然参数量差异超过十倍，但使用了完全相同的条件生成架构，主要通过层数与隐藏维度做差异化缩放。根据官方公布的配置信息整理如下：

配置项	0.8B	2B	4B	9B
Transformer层数	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层，但2B的隐藏维度直接翻倍，属于“同深不同宽”的扩容路线；4B与9B则加深到32层，整体表达能力上了一个台阶。其二，视觉侧的配置在2B及以上明显加强（视觉层数从12层提升到24层），说明该家族并非把多模态当作大模型的专属能力，而是希望小尺寸模型也保持一致的图文理解体验。

对评测的启示：由于四款模型共享同一套架构与词表，业务迁移时提示词模板、预处理流程、推理代码可以高度复用，这本身就是“易用性”维度上的加分项，评测时应把“跨尺寸迁移成本”列为观察点。

3.2 混合注意力：端侧场景的“省存”红利

全系列保持了约75%线性注意力加25%标准注意力的混合设计。其原理可以概括为：传统全注意力结构在自回归生成时需要为每个历史token维护KV Cache，上下文越长，缓存占用越大；而线性注意力层以固定大小的状态递推历史信息，无需维护随长度线性增长的KV Cache。

由此带来的直接收益是：在长上下文场景下，内存占用相比同规模全注意力结构可降低约75%。对于只有4GB甚至8GB内存的手机或IoT设备，这意味着中等长度乃至更长的文档分析、多模态理解任务，有机会真正在本地跑起来，而不是全部依赖云端。

需要注意的是，这是一个由架构推导出的理论性收益，评测时必须设计专门实验加以验证，而不能直接采信，具体方法见第六节。

3.3 原生多模态与256K长上下文全系下放

全系共享统一的视觉-语言基座，意味着多模态能力不是外挂式的“阉割版”，这一点在0.8B这种极小尺寸上尤为难得。评测意义在于：可以在完全相同的图像样本与问题集下，横向对比四个尺寸的多模态能力衰减曲线，为“最小可用尺寸”的选择提供依据。而256K上下文全系可用，则为端侧长文档场景（合同摘要、会议记录整理、代码库理解）提供了可能性，但“标称支持”与“全长稳定可用”是两回事，需要实测有效上下文长度。

四、评测维度设计

端侧模型评测应至少覆盖以下九个维度，每个维度都要落到可观察、可验证的指标上：

维度	关键指标	验证手段	解读要点
功能完整性	多模态输入支持、长上下文加载、流式输出	用例集逐项验证	缺项直接影响可用性
准确性	图文问答正确率、摘要质量、指令跟随	固定评测集横向对比	分任务看，不看单一平均分
性能	首字延迟、稳态生成速度	多轮计时取中位数	对输入长度与量化方式敏感
资源占用	内存峰值、存储占用、功耗、发热	系统监控全程采样	混合注意力优势主要看内存峰值曲线
稳定性	长时间运行、异常输入容错	连续生成与边界测试	关注热降频后的表现
兼容性	量化格式、推理框架、芯片平台适配	多平台交叉部署	决定落地工程量
易用性	接入流程、文档质量、调试便利性	新人上手计时	跨尺寸配置复用度是重点
安全与隐私	数据是否出端、内容安全策略	流量检查与合规评估	本地推理天然具备数据不出端优势
成本	一次性适配成本、单次推理功耗成本	综合统计	端侧省的是调用费用，付的是适配与维护成本

五、评测环境与前提

端侧评测对环境极为敏感，测试前必须先固定前提条件：

1. 设备分档：建议划分三档——入门档（约4GB内存的手机或开发板）、主流档（约8GB内存的手机）、高性能档（笔记本级SoC平台）。同一尺寸模型至少在两档设备上测试，避免结论只对某类设备成立。
2. 软件栈：统一使用某端侧推理框架的较新版本，统一采用4-bit权重量化方案；如需评估量化影响，再增加一组更高精度的对照实验。
3. 控制变量：相同提示词模板、相同图像样本、相同上下文长度档位、相同采样参数；每轮测试前清理后台进程与缓存，固定设备温度起点，关闭无关网络活动。
4. 明确边界：所有结论只在“同档设备+同量化方案+同推理框架”内比较，跨环境数据不具备直接可比性。

六、评测方法与流程

推荐按“先基线、再功能、后性能与稳定性”的顺序执行：

1. 建立基线：记录设备空载内存、电池电量与温度，作为后续数据的参照。
2. 功能验证：图文理解准备OCR识别、图表问答、界面截图理解、文档问答等典型用例；长上下文采用“大海捞针”式测试——在长文本的不同位置埋入关键信息，检验模型能否准确召回，以此标定有效上下文长度。
3. 性能测试：分别记录首字延迟、稳态生成速度、内存峰值，每项多轮取中位数；同时扫描上下文长度（如1K、8K、32K、128K档位），绘制内存峰值随长度增长的曲线——若曲线增长明显平缓于同规模全注意力模型，混合注意力的省存红利即得到实证。
4. 稳定性测试：连续一小时以上的循环生成，观察热降频后的速度衰减；构造异常输入（超大分辨率图片、被截断的文本、恰好达到上下文上限的输入），验证容错与报错行为。
5. 记录与分析：全程保留日志、系统指标与异常样本，形成可复现的评测记录。

评测流程可以用如下示意性伪代码概括：

# 通用端侧推理评测伪代码（示意，非任何具体工具的接口）
for size in ["0.8B", "2B", "4B", "9B"]:
    model = load_model(size, quant="4bit")
    for ctx in [1024, 8192, 32768, 131072]:
        prompt = build_long_prompt(ctx)          # 按长度档位构造输入
        for _ in range(ROUNDS):                  # 多轮取统计量
            mem0, t0 = current_memory(), now()
            stream = model.generate(prompt, stream=True)
            ttft = now() - t0                    # 首字延迟
            speed = measure_speed(stream)        # 稳态生成速度
            mem_peak = peak_memory() - mem0      # 内存峰值
            log(size, ctx, ttft, speed, mem_peak)

七、结果解读框架

拿到数据后，建议按以下逻辑解读，避免“只看一个分数”：

• 首字延迟：直接决定交互体验。它通常随输入长度增长而上升，因为长上下文的预填充计算量更大；若某尺寸在短输入下延迟可接受、长输入下明显劣化，应结合业务输入长度分布判断。
• 稳态生成速度：决定长文本生成体验，主要受内存带宽、量化方案与硬件算力影响。同一模型在不同档位设备上的速度差异，反映的是硬件瓶颈而非模型能力差异。
• 内存峰值：这是本次评测最值得关注的指标。混合注意力架构的理论优势，应体现为内存峰值随上下文长度增长更平缓；如果实测曲线在长上下文档位仍快速上升，则需检查推理框架是否完整支持了该架构的缓存优化。
• 准确性：小尺寸模型在复杂推理任务上的能力衰减通常比简单任务更明显，应按任务难度分层统计，而不是只报告平均正确率。
• 量化影响：4-bit量化能显著降低内存与存储占用，但可能带来能力衰减。正确做法是用同一评测集对比量化前后的表现，把衰减幅度控制在业务可接受范围内，而不是默认“量化无损”。

所有结论都应保持条件化表述，例如“在8GB内存、4-bit量化条件下，某尺寸模型可流畅完成某类任务”，而不是无条件的绝对判断。

八、适用场景分析

结合四款模型的定位与端侧场景特点，可以做如下场景映射：

• 0.8B / 2B：适合内存预算极低、任务高频且复杂度可控的场景，如输入辅助、意图识别、简单图文理解、设备端指令跟随。这类场景对响应速度和离线可用性要求高，对模型能力上限要求相对宽松。
• 4B：主流手机档位的主力选择，可承接截图理解、文档摘要、多模态问答等中等复杂度任务，是能力与资源的平衡点。
• 9B：适合旗舰设备或笔记本级平台，面向端侧长文档分析、复杂图文推理等接近云端体验的任务，可作为端云协同架构中端侧侧的主力模型。
• 云端补充：对于超出端侧能力边界的请求——例如深度推理、超长文档、高峰并发——应回落到云端大模型服务完成。企业可以借助百度智能云上的大模型推理服务等通用云侧能力，搭建“端侧优先、云端兜底”的分级架构，在时延、成本与能力之间取得平衡。

九、风险与限制

评测与落地过程中，需要正视以下限制：

1. 样本偏差：评测集与真实业务数据分布不一致，可能出现“评测表现好、线上表现一般”；
2. 环境差异：不同芯片平台、系统版本、后台负载都会影响结果，跨环境数据不可直接比较；
3. 长上下文有效性：标称256K不等于全长稳定可用，有效上下文长度应以实测为准；
4. 量化精度：不同量化方案、不同量化粒度的能力衰减差异明显，选型时必须实测；
5. 热与功耗约束：移动设备长时间高负载会触发降频，性能数据应区分冷启动与热稳定状态；
6. 时效性：模型与推理框架迭代速度快，评测结论具有时效性，重大版本更新后应复测。

十、选型与使用建议

基于上述评测逻辑，给出几条中立的落地建议：

1. 先定义任务，再选尺寸：从业务清单出发标注每类任务的复杂度与输入长度，用最小可行模型起步，能力不足再逐级上调，避免一开始就选最大尺寸；
2. 用同一评测集横向对比：四个尺寸共享架构与词表，横向对比成本低，应充分利用这一点建立自己的“能力-资源”曲线；
3. 关注内存峰值而非只看参数量：混合注意力架构下，参数量与内存占用的对应关系被改变，较大尺寸模型在长上下文下的内存占用可能低于直觉预期，需实测确认；
4. 设计端云协同：把端侧模型定位为“低时延、保隐私、可离线”的第一道防线，复杂请求回落云端，并统一两端的提示词与输出规范，降低维护成本；
5. 建立回归评测机制：模型或推理框架每次升级后，用固定评测集复测核心指标，防止升级引入隐性回退。

十一、总结

本文以某开源家族新发布的0.8B/2B/4B/9B四款端侧多模态小模型为评测对象，梳理了其三项核心亮点：全系原生图文理解、全系256K长上下文、以线性注意力为主的混合注意力架构（理论长上下文内存占用可降低约75%）。在此基础上，本文给出了一套覆盖功能、性能、资源、稳定性、兼容性、易用性、安全与成本的端侧评测框架，并提供了从设备分档、控制变量到内存峰值曲线分析的具体测试方法。需要强调的是，端侧模型选型没有普适答案：从0.8B到9B的每一档都有其适配场景，最终决策应来自“业务任务定义+真实设备实测+端云协同设计”三者结合，本文提供的评测框架与方法，正是为了让这一决策过程可复现、可解释、可迭代。