Liquid AI 与 Artificial Analysis 发布端侧基准测试平台 Pipette
Introducing Pipette: A benchmarking suite for on-device intelligence
Liquid AI 与 Artificial Analysis 联合发布开源端侧基准测试平台 Pipette,用于在边缘设备上评测基础模型。
Pipette 把端侧部署拆成模型、量化、运行时、设备四要素并公开可复现数据,读者可据此理解端侧选型为何不能只看模型卡。
今天,我们与 Artificial Analysis 合作,发布 Pipette,一个用于在边缘设备上对基础模型进行基准测试的开源平台。Pipette 建立在一个简单的前提之上:设备端行为是已部署系统的属性,而非孤立模型的属性。它将边缘部署转变为一个实证性的系统问题,使决定真实世界行为的各种交互变得可见且可测试。
今天发布的内容:
- 一个公开数据集,包含在已发布的可复现性协议下生成的、经实验室验证的结果。 它包含超过 1,000 个模型 × 量化 × 运行时 × 设备 × 上下文配置的五项设备端性能指标。当前数据涵盖 30 多个模型、多种量化格式、适用于 macOS、iOS、Windows 和 Android 的 llama.cpp 构建,以及从 256 到 8,192 个 token 的上下文长度。首批发布的结果涵盖搭载 M5 Max 的 MacBook Pro、iPhone 17 Pro 和 Galaxy S26 Ultra,AMD Ryzen AI Max+ 395 和 Radeon 8060S 的结果即将推出。在此处查看覆盖范围详情。
- 适用于 macOS、Windows、iOS 和 Android 的开源 基准测试客户端。 其中包括原生 iOS 和 Android 应用,可直接在目标设备上执行性能基准测试。社区提交结果的发布目前处于测试阶段。
- 一个用于分析部署配置的 交互式仪表板。 它将质量评估与在受支持设备上测得的吞吐量、延迟、上下文扩展和内存使用情况关联起来。更多模型已在筹备中。
- Artificial Analysis 将 Pipette 的设备端性能 数据与等权重的质量评估相结合,这些评估旨在代表真实世界的移动使用场景。
- 用于运行完整基准测试流水线的 Apache 2.0 许可基础设施。 本次发布包括 pipette-mgmt、pipette-clients 和 pipette-scores。

探索我们的排行榜
在 GitHub 上查看客户端
探索 Artificial Analysis 移动基准测试结果申请你的模型、运行时、处理器和设备
模型发布通常包含在服务器级、全精度条件下生成的能力评分。这些结果提供了有用的基线,但它们不一定能预测模型在其预期部署环境中的表现。设备端部署引入了不同的约束,包括模型是否能装入内存、响应速度有多快,以及其运行时在特定处理器上的行为方式。
Pipette 通过版本化的基准测试定义和已发布的测量协议来解答这些问题,这些协议专为可复现性而设计。
“要理解设备级模型的真实性能,需要同时细致关注能力、速度、延迟、内存、运行时以及处理器或设备类型等多个维度。现有的大多数基准测试套件并未涵盖这些方面。考虑到数据中心之外的移动设备、运行时、量化配置、设备状况和基准测试设置的多样性,为设备级模型设计一套无偏见且公平的基准测试套件绝非易事。这就是我们决定构建 Pipette、将其开源,并与独立专家验证机构 Artificial Analysis 合作的原因,以确保我们的方法和结果在大规模下的公平性和可复现性。”
为什么端侧基准测试需要部署上下文
模型卡通常报告原始全精度权重的质量,而端侧部署通常使用量化后的产物。量化可能影响输出质量,且影响因模型、格式和任务而异。Pipette 在 IFBench、GPQA Diamond 和 MATH-500 上评估量化产物,并在可用时以 FP16 或 BF16 结果作为参考。这揭示了量化后参考产物所评估能力的保留程度。
在 Pipette 中,每次测量都始于一个经过测试的部署配置:
模型 + 量化 + 运行时 + 设备
随后,基准测试定义要测量的指标和 token 形态,为该配置生成延迟、吞吐量或内存结果。质量结果则按模型、量化、评估版本、思考模式和评估权威单独标识。当前发布的质量分数来自在 NVIDIA H100 80GB 参考系统上运行的 llama.cpp 评估。这些质量值与仪表板中兼容的端侧性能测量结果配对呈现。
云部署通常可以增加容量,或将工作负载迁移到更大或更专用的硬件上。小型语言模型运行在手机、笔记本电脑和嵌入式设备上,通常需要经过大幅定制、专用化和量化才能装入内存。因此,运行时行为、处理器架构、内存压力、电源状态和散热余量可能决定哪种配置可行。
数据显示了这些相互作用能在多大程度上影响部署决策:
两个 350M 模型随上下文扩展的表现可能截然不同。在 Galaxy S26 Ultra 上以 Q4_K_M 运行时,Granite-4.0-H-350M 从 256 到 4,096 个输入 token 保留了 78.4% 的解码吞吐量,而 Granite-4.0-350M 仅保留 33.8%。比较 Granite 上下文扩展
稀疏激活可以在不增加小模型内存占用的情况下实现小模型速度。在 Galaxy S26 Ultra 上处理 2,048 个输入 token 时,LFM2.5-8B-A1B 的解码速度比 Qwen3.5-4B 快 2.4 倍,比 Ministral-3B-Instruct-2512 快 2.6 倍。尽管每个 token 仅激活其 8.5B 参数中的 1.5B,但由于所有专家权重都计入模型的内存需求,其峰值内存仍达到 5.29 GiB。比较稀疏与稠密配置
两款尺寸相近的 iPhone 机型呈现出直接的“速度—质量”取舍。在 Q4_K_M 下,MiniCPM5-1B 以 2,048 个输入 token 和 256 个输出 token 在 3.47 秒内完成该工作负载,而 LFM2.5-1.2B-Instruct 为 4.12 秒,耗时减少 15.8%。在对相同 Q4_K_M 产物的质量评估中,LFM 在 MATH-500 上高出 9.0 分。两种配置均未在两个维度上同时占优。打开 iPhone Pareto 对比
几乎相同的 8B 部署画像可能掩盖任务层面的反转。在 M5 Max 上以 Q4_K_M 和 2,048 个输入 token 运行时,Granite-4.1-8B 与 Ministral-3-8B-Instruct-2512 的解码吞吐量仅相差 2.4%,峰值 RAM 仅相差 1.2%。在对相同 Q4_K_M 产物的质量评估中,Granite 在 IFBench 上领先 7.3 分,而 Ministral 在 GPQA Diamond 上领先 14.0 分。比较性能与任务质量
Pipette 将这些取舍分开呈现并保持可检视,而不是把部署就绪度压缩成单一排名。
Pipette 的工作原理
Pipette 围绕可复现性和透明度进行设计。性能基准遵循 Pipette 已发布的测量方法:计时和内存运行使用固定的 token 形状、贪心解码、丢弃一次预热、五次测量重复以及就绪度门控。Pipette 的方法论已由 Artificial Analysis 审阅并验证。评估遵循另一套已发布的协议,使用标准数据集、通过参考运行器生成补全,以及确定性的、模型盲评的评分。
三个开源组件实现了该流水线:
- pipette-mgmt:提供带版本的基准目录并接收基准提交。
- pipette-clients:在目标设备上运行基准并生成评估补全。
- pipette-scores:提供评估提示并对补全评分,且无法访问其生成来源。
客户端从 pipette-mgmt 获取带版本的基准定义,并在目标设备上运行推理。客户端将性能测量结果直接返回给 pipette-mgmt。在每次计时重复之前,平台特定的就绪度检查会验证热和负载条件是否可接受。Pipette 仅发布通过该检查的运行结果。手机的电力和散热条件记录在我们的设备条件方法论中。
对于评估,pipette-mgmt 将生成的补全转发给 pipette-scores 进行模型盲评评分,然后将分数与其生成来源一起存储。每次提交都会记录基准和 token 形状、模型产物和量化、运行时版本和设置,以及设备硬件和操作系统。Pipette 使用这些元数据将不同条件下的结果分开,并使每次比较的依据都明确可见。已记录的范围和测量边界阐明了应如何解读当前结果。
仪表盘内部
仪表盘围绕三个互补的界面组织:用于部署决策的按设备排行榜、用于配置级表格的结果浏览器,以及用于底层记录的提交浏览器。在这些界面中,用户可按模型、量化、运行时、设备、基准、上下文长度以及适用时的思考模式来缩小数据范围。
真实约束下的帕累托前沿。将 IFBench、GPQA Diamond 或 MATH-500 与首 token 时间、端到端延迟、预填充吞吐量、解码吞吐量或峰值 RAM 进行绘图。连线连接同一模型的量化变体,而约束面板则按最低质量或吞吐量以及最大延迟或内存来筛选结果。
上下文扩展与量化权衡。 专用视图按参数层级对模型进行分组,追踪从 256 到 8,192 token 的上下文长度下的吞吐量和内存,并将速度与峰值 RAM 进行映射。量化视图将每个产物的评估分数与其全精度参考(如有)进行比较。
可追溯至原始记录。 结果页面列出每个已发布的模型、量化、设备和运行时配置。提交页面公开这些结果背后的记录,包括基准版本、token 形状、测量值以及适用时的标准差。一个覆盖浏览器报告在运行时、设备、量化、基准和模型之间有多少提交被呈现。
可分享、有文档且带版本。 排行榜上的每个图表都会生成一个可分享的链接,并保留其筛选条件。我们的文档涵盖测量方法、基准定义、评估协议和术语表。我们的记录保留了对每个结果如何产生进行审计所需的客户端和运行时版本。有关实现细节和设置说明,请参阅 GitHub 上的 pipette-mgmt、pipette-clients 和 pipette-scores。
局限性与未来方向
Pipette 才刚刚起步。覆盖范围正通过 Liquid AI 的设备实验室不断扩大,随着提交流程的成熟,计划引入社区贡献的配置。
NPU:NPU 支持取决于特定模型的 kernel 和算子覆盖范围。在此初始版本中,没有任何 NPU 路径能支持足够多的已发布模型集,以在模型类别之间提供一致的比较,因此未包含 NPU 结果。我们正在积极努力扩大这一覆盖范围,并欢迎硬件和运行时合作伙伴的贡献。
Android GPU 覆盖:在当前基准设置和模型覆盖范围下,在 Android 上测试的所有稳定 GPU 后端,在完整模型集上均未能持续优于所选 CPU 路径。因此,当前的 llama.cpp Android 路径以 CPU 为主,而 iPhone 路径则使用 Metal 后端。
跨设备对比:我们目前不建议将跨设备结果解读为受控的硬件对比。Android 和 iOS 运行在 flash-attention 支持、线程数、加速器使用和执行环境方面存在差异。Android 运行使用基于 CPU 的 CLI 路径,而 iOS 在应用内使用 Metal 运行。当前 Pipette 结果最可靠的用途是在同一设备内比较不同配置。
面向设备级应用的质量评估:当前测试套件涵盖指令遵循、科学推理和竞赛数学,但尚未全面覆盖智能体行为、知识密集型任务、多模态工作负载或其他面向设备的用例。本次发布中,Artificial Analysis 报告了为代表真实移动使用场景而选取的常见评估的平均值。我们欢迎反馈,以了解应纳入哪些能力和基准测试,从而更好地代表端侧模型质量。
开始使用
探索 Pipette 仪表盘 ,在你计划面向的设备上比较模型、量化方式、运行时和上下文长度。每个筛选后的图表都有可分享的 URL,因此可以逐一检查并讨论各个部署对比。
使用 开源客户端、原生 iOS 应用或 Android 应用在你自己的硬件上运行 Pipette。社区提交结果的发布目前处于测试阶段,我们鼓励模型提供商、运行时开发者、硬件团队和应用构建者帮助测试这一工作流程。
如果你需要的模型、运行时、设备或基准测试缺失,请 提交 issue 或 联系 Liquid AI 以请求覆盖范围或分享反馈。更多配置将在完成测量和发布流程后陆续添加。
附录
Pipette 发布时包含以下模型和量化格式:
LFM2.5-230M: Q4_0、Q4_K_M、Q5_K_M、Q8_0。 Hugging Face
LFM2.5-350M: Q4_0、Q4_K_M、Q5_K_M、Q8_0。 Hugging Face
LFM2.5-1.2B-Instruct: Q4_0、Q4_K_M、Q5_K_M、Q8_0。 Hugging Face
LFM2.5-2.6B: Q4_0、Q4_K_M、Q5_K_M、Q8_0。 Hugging Face
LFM2.5-8B-A1B: Q4_0、Q4_K_M、Q5_K_M。 Hugging Face
Qwen3.5-0.8B: Q4_0、Q4_K_M、Q5_K_M、Q8_0。 Hugging Face
Qwen3.5-2B: Q4_0、Q4_K_M、Q5_K_M、Q8_0。 Hugging Face
Qwen3.5-4B: Q4_0、Q4_K_M、Q5_K_M、Q8_0。 Hugging Face
Qwen3.5-9B: Q4_K_M。 Hugging Face
Qwen3.5-27B: IQ1_M。 Hugging Face
Qwen3.6-27B: IQ1_M。 Hugging Face
Gemma 4 E2B Instruct: Q4_0、Q4_K_M、Q5_K_M、Q8_0。 Hugging Face
Gemma 4 E4B Instruct: Q4_0、Q4_K_M、Q5_K_M、Q8_0。 Hugging Face
Gemma 4 12B Instruct: Q4_K_M。 Hugging Face
Granite 4.0 350M: Q4_0、Q4_K_M、Q5_K_M、Q8_0。 Hugging Face
Granite 4.0 H 350M: Q4_0、Q4_K_M、Q5_K_M、Q8_0。 Hugging Face
Granite 4.0 H 1B: Q4_0、Q4_K_M、Q5_K_M、Q8_0。 Hugging Face
Granite 4.0 H Micro: Q4_0、Q4_K_M、Q5_K_M、Q8_0。 Hugging Face
Granite 4.1 8B: Q4_K_M。 Hugging Face
Ministral 3 3B Instruct 2512: Q4_0、Q4_K_M、Q5_K_M、Q8_0。 Q4_0 source。 Q4_K_M, Q5_K_M, and Q8_0 source
Ministral 3 8B Instruct 2512: Q4_K_M。 Hugging Face
Llama 3.2 1B Instruct: Q4_0、Q4_K_M、Q5_K_M、Q8_0。 Hugging Face
Llama 3.2 3B Instruct: Q4_0、Q4_K_M、Q5_K_M、Q8_0。 Hugging Face
Falcon-H1R-7B: Q4_K_M。 Hugging Face
Olmo-3-7B-Think: Q4_K_M。 Hugging Face
Ornith-1.0-9B: Q4_K_M。 Hugging Face
Ornith-1.5-9B: Q4_K_M。 Hugging Face
Nanbeige4.2-3B: Q4_K_M。 Hugging Face
Ling-3.0-tiny: Q4_K_M。 Hugging Face
MiniCPM5-1B: Q4_K_M。 Hugging Face
NVIDIA Nemotron Nano 9B v2: Q4_K_M。 Hugging Face
ai9stars G9v3 3B: Q4_K_M。 Hugging Face
Bonsai-27B: Q1_0。 Hugging Face
Ternary-Bonsai-27B: Q2_g64。 Hugging Face
来源:Liquid AI Blog · liquid.ai