Pipette 的端侧 AI 结果是部署测试，而不是芯片排名
Pipette 发布了许多配置下的延迟、吞吐量、内存和质量结果，但不同手机、运行时和量化方式并不能组成一个干净的排名。
Liquid AI 与 Artificial Analysis 于 8 月 24 日发布了 Pipette，这是一个面向在手机和电脑上运行的小型语言模型的开放基准。它有用的单位不是模型名称，而是完整的部署：模型、量化方式、运行时、设备、运行时设置和工作负载。
这种设计解决了端侧 AI 对比中的一个常见问题。服务器上的全精度质量分数并不能说明量化模型是否装得进手机、能否在用户失去耐心前作出响应，或者是否会随着提示词变长而显著变慢。Pipette 将这些维度放在一个仪表盘中，但把它们并列展示并不会让每一行都能直接比较。
核心限制很简单：跨设备图表是部署观察结果，不是芯片排名；而显示在手机性能旁边的质量分数来自一条独立的评估路径。
Pipette 衡量的是一种部署配置
Pipette 发布公告称，首个公开数据集包含 1,000 多种组合，覆盖 30 多个模型、多种量化方式、面向 macOS、iOS、Windows 和 Android 的多个 llama.cpp 构建版本，以及从 256 到 8,192 个 token 的提示词长度。它在目标设备上报告延迟、提示词处理速度、token 生成速度和峰值内存，然后将兼容的行与任务质量评估配对。
找到模型后，其他维度并不是可以忽略的元数据。它们会改变结果：
| 维度 | 它会改变什么 | 要进行干净比较必须保持不变的内容 |
|---|---|---|
| 模型产物和量化方式 | 权重内存、输出质量，有时还包括速度 | 确切的模型产物和量化格式 |
| 运行时 | 内核、加速器使用情况、测量边界和支持的功能 | 运行时名称、构建版本、后端以及相关标志 |
| 设备和操作系统 | 可用内存、处理器路径、计数器和功耗行为 | 确切的设备类别和操作系统构建版本 |
| 工作负载形态 | 预填充工作、生成工作、上下文压力和键值缓存内存 | 输入 token、输出 token、基准定义和上下文分配 |
| 设备条件 | 温控降频和后台负载 | 电源、散热、就绪门槛和可比的空闲状态 |
| 质量评估 | 分数代表哪种能力 | 数据集版本、评分器、思考模式、模型和量化方式 |
Pipette 的结果比较指南比浏览排行榜更加严格：运行时标志、Flash Attention、线程数、GPU 层数、思考模式、量化方式和 token 配置都属于配置的一部分。设置发生变化，实验就发生了变化。
这就是为什么“模型 A 每秒生成 80 个 token”并不完整。有用的表述更像是：“在记录的实验室条件下，这个量化产物在这台设备和这个运行时构建版本上，在处理 2,048 个 token 的提示词后，以这一速率生成了 100 个输出 token。”
延迟、预填充和解码回答的是不同问题
语言模型推理有两个主要阶段。预填充在第一个生成 token 之前处理输入提示词。解码逐个 token 生成响应。长文档和短回答会给预填充带来压力；短提示词和长回答则更强调解码。
Pipette 的性能方法分别报告这两个阶段。其标准解码基准生成 100 个输出 token，而端到端延迟测试生成 256 个。计时运行使用贪心解码，丢弃启动和预热行为，并报告五次测量重复的均值和样本标准差。
选择与产品问题相匹配的指标：
| 产品问题 | Pipette 指标 | 应结合什么来阅读 |
|---|---|---|
| 系统吸收提示词的速度有多快？ | 预填充吞吐量，以每秒输入 token 数计 | 确切的输入长度和运行时路径 |
| 生成开始后，文字出现得有多快？ | 解码吞吐量，以每秒输出 token 数计 | 输出长度和模型的响应行为 |
| 完整的固定请求需要多长时间？ | 端到端延迟 | 两种 token 数量以及包含的客户端开销 |
| 部署是否装得下？ | 峰值内存 | 平台特定的计数器和上下文长度 |
| 该产物是否保留了有用的能力？ | IFBench、GPQA Diamond 或 MATH-500 | 所代表的任务和独立的评估路径 |
不要通过相加两个四舍五入后的吞吐量数字来估算用户可见的响应时间。Pipette 提醒说，端到端路径可能包括 token 化和本地请求开销，而隔离的阶段速率不包含这些开销。如果启动、模型加载、提示词构造、流式传输或界面工作很重要，也要测量实际应用。
方差也应纳入决策。Pipette 建议，如果标准差超过均值的 5%，就将其视为运行嘈杂或不稳定的证据。五次接近的重复并不能证明总体性能，但它们比一个掩盖了某次温控降频运行的四舍五入平均值更有信息量。
手机分数和质量分数来自不同的机器
Pipette 图表中最容易出现的误读，是以为每个绘制的数值都来自选定的手机。性能是在图表显示的设备上测量的。当前发布的质量结果则是在 NVIDIA H100 80GB 系统上通过 llama.cpp 单独生成，然后在模型和量化方式兼容时与设备结果匹配。
这种匹配很有用。它让团队可以询问：更小的量化方式是否节省了足够的内存和时间，同时又没有损失过多的任务性能。但它并不能证明手机以性能轴上显示的速度运行了 MATH-500、GPQA Diamond 或 IFBench。Pipette 的发布方法还说明，改变性能设备并不会选择新的质量行。
质量覆盖范围比“擅长移动端 AI”要窄。发布版本测试指令遵循、竞赛数学和科学推理。Pipette 的已记录限制称，它并不全面覆盖代理行为、知识密集型任务、多模态工作或其他面向设备的用途。要上线摘要、抽取、工具调用、语音或视觉功能，团队仍需要根据该功能的输入和失败成本构建评估。
量化让保持这种区分变得很有必要。量化降低了存储模型权重所使用的精度，通常会降低内存占用，有时还会提高速度，但质量损失取决于产物和任务。应在同一模型和目标部署内比较量化方式，然后测试应用任务。通用基准是证据，而不是对产品承诺的验收测试。
跨设备图表不是处理器对决
Pipette 明确建议在同一设备内进行比较。最初的 Android 和 iOS 路径并不是受硬件控制的等价路径。覆盖范围方法称，公开 Android 结果使用仅 CPU 的 llama.cpp 命令行路径，禁用 Flash Attention 且不使用 GPU 层。公开的 iOS 测量在应用内使用 Metal 和 Android 没有对应项的设置运行。
平台还会影响测量。峰值内存计数器在不同平台上并不代表完全相同的东西，而 iOS 的公开温度信号对于 Pipette 的实验室流程来说过于粗糙。发布的 iOS 运行使用能够读取芯片温度的内部温控感知构建版本，而公开应用无法精确复现这一能力。
Pipette 控制了部分环境噪声。其设备条件方法会在计时重复前检查温度和负载信号，让设备组中的手机接入市电，并使用外部散热。这些控制改善了其实验室内的比较。但散热仍由操作员管理，而且没有存储在每一条结果记录上，因此数据集本身无法证明任意两条手机记录具有相同的物理条件。
一份独立的 GIGAZINE 体验报告显示，公开的 iPhone 应用可以下载模型并运行本地基准工作负载。这是对客户端体验的有用确认，但不是对 Liquid AI 完整实验室数据集或私有 iOS 温度仪器的独立复现。
如果问题是“我们的 iPhone 应用应该使用哪种配置？”，就筛选出受支持的 iPhone，并在其中比较配置。如果问题是“哪款手机芯片更快？”，Pipette 当前的跨平台路径并没有将芯片与运行时、后端、标志、操作系统、电源、散热和计数器差异隔离开来。更大的数字可以描述完整的已发布部署，却不能指出是哪个组件造成了这个数字。
Pipette 今天能够确立什么
Pipette 通过发布有版本记录的工作负载、配置级结果、方差和可追溯的提交，让端侧模型选择更容易审计。它可以显示，在记录的条件下，一个经过测试的配置在所覆盖的评估上比另一个配置更快、更小或更强。
它无法把不同平台路径变成受控的处理器排名，也无法让三个服务器运行的质量测试代表所有移动端功能。而且，由于当前验证结果来自 Liquid AI 的实验室，社区发布仍处于 beta 阶段，它目前还不能描述普通用户那些发热、繁忙且使用电池供电的设备的分布。
下一批有意义的证据将是带有清晰条件标签、可由他人独立复现的提交，以及更广泛的设备覆盖。在那之前，Pipette 是一个强大的候选筛选和比较界面，但其中的每一行描述的仍是完整部署，而不是孤立的模型或处理器。