Liquid AI 开源 Pipette一套同时评测端侧模型、量化、运行时与硬件的可复现基准套件做端侧 AI 的人几乎都被同一个问题折磨过同一个 3B 模型在别人的手机上跑得飞快到自己手里却卡成 PPT。你很难断定是模型的问题因为换一个推理引擎之后表现可能立刻翻倍你也不好说是硬件不行因为同一个芯片在跑某个专用模型时效率又能高得惊人。于是团队内部开始争论“到底哪个模型更快”“要不要换运行时”最后往往演变成谁嗓门大谁说了算。这时候大多数人会去查排行榜。但榜单给到的通常是一个“模型 设备 推理配置”的特定组合回到你自己的场景里模型要换、量化位宽要调、运行时也不一样结果几乎没有参考价值。真正缺的不是“谁最强”的排名而是一套能复现、可比较、能落到自己项目里的评测流程。Liquid AI 开源的 Pipette正好切中了这个痛点。它不是再发一份“XX 模型超越 XX”的榜单而是把模型、量化、运行时、硬件放进同一套基准套件里让开发者在一个统一的配置体系下跑出可复现的数字再基于这些数字做选型。这篇文章会拆解它到底解决了什么问题、端侧评测的四个维度分别是什么、怎么用类似思路搭一套自己的最小评测以及哪些坑是你大概率会踩到的。先澄清一个容易混淆的点这里说的“量化”不是金融圈常聊的量化交易而是把模型权重从 FP16/BF16 压缩到 INT8/INT4 的模型量化。很多读者搜“量化”相关文章时会大量碰到量化交易、量化策略、量化指标这些内容容易绕晕。本文只讨论模型量化并且会把它放到端侧部署的真实场景里讲清楚。1. 端侧模型评测为什么这么难端侧 AI 评测难难点不在于“跑一个 benchmark”本身而在于可比较的变量实在太多。一个端侧推理方案至少由四层组成模型结构、量化格式、推理运行时、目标硬件。每一层都有多个可选项组合起来就是指数级爆炸。假设你手上有 3 个模型、4 种量化位宽、3 个运行时、2 台测试设备那么理论上就需要跑 3 × 4 × 3 × 2 72 组实验。如果每组实验还要测不同输入长度、不同并发、不同 token 生成长度工作量会直接失控。更麻烦的是这四层之间还存在强耦合。同一个模型在 llama.cpp 上表现不错换到 ONNX Runtime 上可能因为算子实现不同而变慢同一个运行时INT4 量化在 GPU 上收益明显在 CPU 上却可能因为反量化开销而得不偿失。也就是说评测结果不是某个单一变量的“功劳”而是四层组合起来后的整体表现。这就导致很多榜单上的结论无法迁移它在测试环境里也许是对的但换一个组合后完全不适用。另一个容易被忽视的问题是测试口径不统一。A 团队测“首 token 延迟”B 团队测“生成 128 个 token 的平均速度”C 团队可能直接测“每秒多少 token”。不同指标侧重点完全不同放到一张表里比较就会出现“这个模型好像很快但真正用起来却很卡”的现象。再加上预热不足、token 输出长度不固定、设备散热状态不同等因素结果波动往往很大。所以端侧模型评测难本质上是因为评测体系没有跟上部署场景的复杂度。我们需要的不只是一台机器、一个脚本、一行分数而是一个能把四层变量固定下来、统一口径、允许二次复现的框架。Pipette 正是冲着这个问题来的。2. 四个关键维度模型、量化、运行时、硬件要理解 Pipette 这类工具先要把端侧评测的四层结构拆清楚。它们各自解决不同的问题也各自有最容易被误解的地方。模型层指的是模型本身的结构和参数量。端侧部署通常使用 0.5B 到 7B 级别的小模型结构上以 Transformer 及其变体为主也有一些新的状态空间模型尝试在长上下文和低显存上做突破。模型层的评测重点是“在有限资源下这个模型能不能完成我的任务”而不是简单看参数多少。两个参数量接近的模型由于训练数据、结构设计、上下文长度的差异实际端侧体验可能差很多。量化层指的是把权重从高精度浮点数压缩到低比特整数例如 INT8、INT4或者是 GGUF 这类打包格式下的 Q4_K_M、Q5_K_M 等具体策略。量化之所以在端侧重要是因为端侧推理通常是内存带宽瓶颈——权重要从内存搬到计算单元权重越小同样带宽下能处理的 token 就越多。但量化会带来精度损失尤其对数学推理、中文语义理解、长文本等敏感任务INT4 的掉点可能很明显。真正的难点在于不同模型对低比特的敏感度不同不能只看“量化后还能用”就拍板上线。运行时层指的是具体的推理执行引擎例如 llama.cpp、ONNX Runtime、MLC LLM、ExecuTorch、TensorRT-LLM、OpenVINO 等。每个运行时在不同硬件上的算子优化、线程调度、内存管理策略都不一样直接影响延迟和吞吐。同一个模型加同一个量化格式在 llama.cpp 上可能在 CPU 跑得不错在 ONNX Runtime 上则更适合 NPU 的算子融合。运行时选得好不好往往决定了端侧体验是“能用”还是“好用”。硬件层指的是 CPU、GPU、NPU以及各类端侧 SoC。端侧硬件最让人头疼的是 NPU 的算子支持范围有限。很多 NPU 对动态 shape、某些激活函数、自定义 attention 实现并不友好导致模型明明能跑但在 NPU 上加载失败或推理速度很慢。评测时必须区分“功能上能跑”和“性能上达标”这也是把硬件纳入评测体系的原因。评测维度主要解决的问题端侧常见选项最容易踩的坑模型层任务能力与资源占用0.5B7B 开源模型只看参数量忽略上下文和结构差异量化层压缩权重、降低带宽压力INT8、INT4、GGUF Q4_K_M 等位宽越低越好忽略精度掉点运行时层算子调度与执行效率llama.cpp、ONNX Runtime、MLC LLM 等只看一个运行时的结果忽略迁移成本硬件层底层算力与算子支持CPU、GPU、NPU、端侧 SoCNPU 不支持某个算子时无法直接运行这四个维度叠加在一起就构成了端侧评测的完整空间。Pipette 的定位就是把这个空间变成一套可配置、可执行、可复现的测试矩阵。3. Pipette 是什么定位、设计理念与核心能力Pipette 是 Liquid AI 开源的一套基准测试套件。Liquid AI 是一家由 MIT 孵化的 AI 公司研究方向偏向液态神经网络Liquid Neural Networks等非传统架构也发布过多个自研模型。Pipette 从名字上就带着“精确取样”的实验室气质——一支移液枪每次取样的体积都非常精确。这个命名暗示了工具的核心追求把基准测试做得严谨、可复现而不是跑个热闹。从定位上看Pipette 不是又一个模型能力排行榜。它更关心的是工程指标延迟、吞吐、峰值内存、量化后的实际效果。它把“模型、量化、运行时、硬件”组合成一个测试矩阵通过配置文件统一定义然后自动执行并导出结果。这样做最大的优势是你的评测配置本身可以被保存、评审、沉淀别人拿到同一份配置和同一批设备可以复现出近似的结果。这就是“可复现基准套件”的含义。Pipette 的设计思路可以直接对应到端侧评测的痛点第一用配置驱动测试矩阵避免手动一组一组跑第二统一采样口径比如固定输入长度和输出长度让不同组合可以横向比较第三支持多种运行时减少“环境不同导致结果不可比”的问题第四把结果结构化导出方便后续用脚本做分析和决策。有人可能会把它和 lm-evaluation-harness、OpenCompass 这类模型评测工具做对比。实际上它们的侧重点不同lm-evaluation-harness 更多关注模型在知识问答、推理、代码等任务上的能力分数回答的是“模型能力强不强”Pipette 更关注部署时的工程指标回答的是“在给定硬件和推理配置下模型跑得快不快、占用高不高”。两者是互补关系一个管质量一个管性能。如果只做能力评测不测部署性能上线时还是会翻车。从另一个角度看Pipette 的诞生也反映了端侧 AI 的一个变化趋势模型选择正在从“挑最强模型”变成“挑最合适的部署组合”。过去可以只看参数量和 benchmark 分数现在则必须在真实运行时、量化方案、目标硬件共同约束下做决策。谁把评测工具做得更接近真实工程环境谁就能更快把模型落地到产品里。4. 用 Pipette 跑一个最小评测思路与示例这一节用思路加示例的方式演示如何把 Pipette 的理念落地。需要说明的是Pipette 本身迭代较快具体命令、配置字段和输出格式请以官方仓库 README 和对应版本的--help为准。下面给出的是一个贴近 CLI 设计思路的演示重点是帮助读者理解“配置驱动评测”的完整流程。4.1 环境准备与版本提醒在开始之前建议先确认三件事Python 环境版本。这类工具通常需要 Python 3.10 或更高版本具体以项目文档为准。目标运行时是否已安装。例如要用 llama.cpp就需要先把对应可执行文件或 Python 绑定装好并确保能在命令行中直接调用。测试设备是否可用。CPU、GPU、NPU 的驱动和 SDK 版本要提前确认尤其是 NPU 往往还需要额外的编译工具链。如果你是在本地测试可以先运行一次帮助命令确认当前安装的版本支持哪些子命令和参数pipette --help如果版本更新导致命令变化以实际输出为准。第一次跑通不用急着追求完整矩阵能在一个硬件上跑通一个模型加一个运行时就已经成功了一半。4.2 编写评测配置Pipette 这类工具的核心是配置驱动。你需要在配置文件中定义要测的模型、运行时、量化方式、硬件以及指标口径。一个最小配置可能长这样# benchmark-demo.yaml演示配置字段以官方文档为准 project: mobile-demo models: - name: qwen2.5-3b-instruct - name: gemma-3-4b-it runtimes: - name: llama.cpp - name: onnxruntime quantizations: - q4_k_m - int8 hardware: - cpu - npu benchmark: prompt_len: 512 max_new_tokens: 128 repetitions: 5 metrics: [ttft, tokens_per_second, peak_memory]这个配置表达的意思是在 CPU 和 NPU 两台目标硬件上用 llama.cpp 和 ONNX Runtime 两个运行时分别测试 Q4_K_M 与 INT8 两种量化格式下的两个模型每种组合重复 5 次记录首 token 延迟、生成速度和峰值内存。这样一个 2 × 2 × 2 × 2 × 5 的矩阵就能初步回答“哪个模型更适合我的设备”的问题。关键点在于metrics字段。如果只测 tokens_per_second你可能会漏掉交互场景最在意的首 token 延迟如果只测延迟又可能忽略批量处理时的吞吐能力。先想清楚自己的产品是对话、流式输出还是离线批量任务再确定指标组合。4.3 运行评测配置写好后运行方式通常是一行命令加上配置文件和输出路径pipette run --config ./benchmark-demo.yaml --output ./results.csv这条命令会按照配置依次初始化各个运行时、加载模型、执行量化、预热设备然后开始正式评测。如果某个运行时没有安装工具会报错并跳过或中断日志里会有明确提示。运行过程中最需要注意的是设备状态。端侧设备很容易受到散热和后台任务影响正式评测前最好关闭无关进程让设备空闲几分钟。如果使用了 NPU还要留意 SDK 是否已经正确初始化有些型号需要在评测前单独运行一次设备初始化脚本。4.4 结果导出与简单分析Pipette 导出的结果一般是 CSV 或 JSON 格式。得到结果后可以用脚本做汇总。下面这段 Python 脚本适合做初步分析它会把每个“模型 运行时 量化 硬件”组合的中位数汇总出来并按硬件分组找出速度最快的组合# analyze_pipette_results.py import pandas as pd df pd.read_csv(results.csv) summary df.groupby( [model, runtime, quantization, hardware] ).agg( ttft_p50(ttft_ms, lambda x: x.median()), tps_p50(tokens_per_second, lambda x: x.median()), peak_memory_mb(peak_memory_mb, median), ).reset_index() # 按硬件维度分别找吞吐最高的组合 best_per_hardware summary.loc[ summary.groupby(hardware)[tps_p50].idxmax() ] print(best_per_hardware.to_string(indexFalse))脚本本身不依赖特定框架只要 CSV 列名与导出格式一致即可。建议第一次先打印df.columns确认列名后再跑分析避免因为字段名不一致而报错。运行方式python analyze_pipette_results.py这一步的作用不是直接拍板用哪个模型而是把大量组合缩小到一个候选清单然后针对候选清单做更细的验证。5. 评测结果怎么解读延迟、吞吐与内存的三角拿到结果后很多人第一反应是“找数字最大的那个”。但在端侧场景数字必须结合真实使用方式来看否则很容易选错。第一个关键指标是首 token 延迟也就是 TTFTTime To First Token。它决定用户输入 prompt 之后多久看到第一个字。聊天助手、智能客服这类交互场景TTFT 直接决定“卡不卡”。TTFT 主要受 prefill 阶段影响也就是模型一次性处理输入 token 的时间。输入越长TTFT 越长。所以评测时一定要固定 prompt 长度否则不同测试之间没有可比性。第二个关键指标是 tokens_per_second它反映的是生成阶段的速度也就是模型逐字输出的效率。长文本生成、摘要、代码补全这类场景会更关注这个指标。需要注意的是TTFT 快不代表生成速度快有些模型 prefill 优化得很好但解码很慢总体体验依然不行。只看其中一项都会误判。第三个关键指标是峰值内存。模型能不能跑起来取决于峰值内存是否超过设备可用上限。尤其在手机和嵌入式设备上内存限制非常硬哪怕推理速度快得惊人内存不够也是白搭。量化在这里的作用最明显从 FP16 压到 INT4权重体积能减少约 75%峰值内存随之下降但代价可能是精度损失和额外反量化开销。第四个容易被忽略的指标是量化后的模型质量。速度再快如果输出结果已经开始胡言乱语那也没有意义。更稳妥的做法是先用 MMLU、C-Eval、GSM8K 等通用评测集对比量化前后的准确率再在评测矩阵里加入一份与你自己业务相关的验证集。这样既能看速度也能看质量。解读结果时我建议不要只看平均值。端侧设备受频率波动、散热影响很大同样的 run 可能相差 10% 以上。更稳妥的方式是多次运行后取中位数或者 p90并记录设备温度和测试时间这样结果才有参考价值。6. 常见问题与排查思路Pipette 这类工具第一次跑通时通常会遇到不少问题。下面整理了几类高频问题按“现象、可能原因、排查方式、解决方案”列出方便直接对照。问题现象可能原因排查方式解决方案运行时报错找不到运行时可执行文件llama.cpp 或 ONNX Runtime 等引擎未安装或未加入 PATH先运行llama-cli --version等命令确认安装对应运行时并在评测配置中指定可执行文件路径模型加载失败模型格式与运行时不匹配例如 GGUF 不能被 ONNX Runtime 直接加载查看日志中加载器报错信息按运行时支持的格式准备模型或先用无量化版本打通流程NPU 上无法运行或异常慢NPU 对部分算子、动态 shape 支持不完整换 CPU/GPU 对照运行查看 NPU 编译日志先用 CPU 验证模型可用性再逐步调整算子兼容性重复运行结果波动大未预热、设备散热、后台任务占用、输出 token 长度不一致固定 prompt 和 max_new_tokens检查设备温度正式测试前多跑几轮取中位数或 p90 作为结果量化后输出质量明显下降量化位宽太低或模型对低比特量化敏感对比 FP16 输出用任务评测集算准确率换用 Q8/INT8或对关键网络层做混合精度评测组合太多跑不完测试矩阵没有收敛盲目扩大模型和量化范围查看社区是否有同设备下的现成结果先用 2 × 2 × 2 小矩阵跑通再按需扩展如果一上来就报错不要急着怀疑工具本身。按照“环境依赖 → 模型格式 → 设备 SDK → 测试口径”这个顺序排查大概率能快速定位问题。最难排查的一类问题是“结果波动”因为它不是某个配置出错而是评测环境不够干净。建议准备一个固定测试脚本把设备状态、输入长度、输出长度、轮数全部记录下来形成团队内部统一的评测基线。7. 把评测变成选型决策最佳实践与工程建议Pipette 这类评测套件真正适合的团队是那些已经经历过“模型选型靠拍脑袋”的痛苦希望把部署决策从经验判断升级为数据判断的团队。如果只是偶尔跑一次对比手工脚本也许够用但如果你需要多次迭代模型和运行时就值得把评测流程沉淀成标准化的工具链。第一条建议是先定业务场景再定评测矩阵。是对话助手、离线翻译、端侧摘要还是流式代码补全不同场景对延迟、吞吐、内存的权重完全不同。评测指标如果和业务场景脱节跑出来再漂亮的数字也是装饰品。第二条建议是固定测试口径把评测配置入库管理。prompt 长度、max_new_tokens、重复次数、预热方式、设备温度记录都要固定下来。配置文件本身要放到仓库里随代码演进。这样当团队成员质疑“为什么选这个模型”时你可以直接甩出一份可复现的配置和结果而不必反复解释。第三条建议是在评测矩阵里同时加入质量验证。速度是工程指标质量是任务指标两个维度必须同时看。可以在每个候选组合上跑一个小的业务验证集记录准确率或关键任务成功率再和性能指标一起对比。这样能避免“量化后速度快了但回答已经不靠谱了”的问题。第四条建议是生产环境切换前先灰度后回滚。即便评测数据很漂亮也不能直接全量替换生产环境。更稳妥的做法是先在部分流量上验证真实用户反馈再逐步放大。同时保留旧模型和旧运行时的部署配置一旦出现问题能快速回滚。第五条建议与安全相关运行第三方模型、推理引擎时要关注模型授权和数据处理边界不要将敏感请求直接发送到未经验证的远端服务。评测过程中产生的日志和数据也要按最小权限原则管理。这里的“安全”不只是部署安全还包括模型使用合规和数据隐私。最后一条是工程协作上的建议把评测结果做成团队内部可查询的记录而不是散落在个人电脑上的 CSV 文件。可以按“日期、硬件、模型、运行时、量化、指标”整理成一张宽表沉淀成选型知识库。时间久了这张表就是团队最值钱的部署经验资产。8. 总结与后续学习方向端侧模型评测正在从“跑个分发个榜”走向“可复现的工程决策”。Pipette 的价值不在于它比别的 benchmArark 工具“更准”而在于它把模型、量化、运行时、硬件四个变量放进了一套统一的执行框架让评测结果可以被保存、复现、比较。对开发者来说这比一个简单的排行榜有用得多。如果你是第一次接触这类工具建议下一步做三件事第一去官方仓库把 README 读完跑通一个最小示例不要急着挂大矩阵第二结合自己的业务场景定义 5 到 6 个关键指标写一份固定口径的测试配置第三把量化前后的模型质量评估加入流程形成“性能 质量”双指标选型机制。端侧模型的选型本质上是一场约束下的优化硬件预算、内存上限、延迟要求、质量底线缺一不可。工具只能帮你把数字测得准最终选择还是要回到你的产品场景里。希望这篇文章能把评测的思路讲清楚也建议你先收藏等真正开始做端侧模型选型时再对照跑一遍。欢迎在评论区分享你在端侧评测中遇到的有趣问题。 Liquid AI 开源 Pipette：可复现的端侧模型评测基准套件
Liquid AI 开源 Pipette一套同时评测端侧模型、量化、运行时与硬件的可复现基准套件做端侧 AI 的人几乎都被同一个问题折磨过同一个 3B 模型在别人的手机上跑得飞快到自己手里却卡成 PPT。你很难断定是模型的问题因为换一个推理引擎之后表现可能立刻翻倍你也不好说是硬件不行因为同一个芯片在跑某个专用模型时效率又能高得惊人。于是团队内部开始争论“到底哪个模型更快”“要不要换运行时”最后往往演变成谁嗓门大谁说了算。这时候大多数人会去查排行榜。但榜单给到的通常是一个“模型 设备 推理配置”的特定组合回到你自己的场景里模型要换、量化位宽要调、运行时也不一样结果几乎没有参考价值。真正缺的不是“谁最强”的排名而是一套能复现、可比较、能落到自己项目里的评测流程。Liquid AI 开源的 Pipette正好切中了这个痛点。它不是再发一份“XX 模型超越 XX”的榜单而是把模型、量化、运行时、硬件放进同一套基准套件里让开发者在一个统一的配置体系下跑出可复现的数字再基于这些数字做选型。这篇文章会拆解它到底解决了什么问题、端侧评测的四个维度分别是什么、怎么用类似思路搭一套自己的最小评测以及哪些坑是你大概率会踩到的。先澄清一个容易混淆的点这里说的“量化”不是金融圈常聊的量化交易而是把模型权重从 FP16/BF16 压缩到 INT8/INT4 的模型量化。很多读者搜“量化”相关文章时会大量碰到量化交易、量化策略、量化指标这些内容容易绕晕。本文只讨论模型量化并且会把它放到端侧部署的真实场景里讲清楚。1. 端侧模型评测为什么这么难端侧 AI 评测难难点不在于“跑一个 benchmark”本身而在于可比较的变量实在太多。一个端侧推理方案至少由四层组成模型结构、量化格式、推理运行时、目标硬件。每一层都有多个可选项组合起来就是指数级爆炸。假设你手上有 3 个模型、4 种量化位宽、3 个运行时、2 台测试设备那么理论上就需要跑 3 × 4 × 3 × 2 72 组实验。如果每组实验还要测不同输入长度、不同并发、不同 token 生成长度工作量会直接失控。更麻烦的是这四层之间还存在强耦合。同一个模型在 llama.cpp 上表现不错换到 ONNX Runtime 上可能因为算子实现不同而变慢同一个运行时INT4 量化在 GPU 上收益明显在 CPU 上却可能因为反量化开销而得不偿失。也就是说评测结果不是某个单一变量的“功劳”而是四层组合起来后的整体表现。这就导致很多榜单上的结论无法迁移它在测试环境里也许是对的但换一个组合后完全不适用。另一个容易被忽视的问题是测试口径不统一。A 团队测“首 token 延迟”B 团队测“生成 128 个 token 的平均速度”C 团队可能直接测“每秒多少 token”。不同指标侧重点完全不同放到一张表里比较就会出现“这个模型好像很快但真正用起来却很卡”的现象。再加上预热不足、token 输出长度不固定、设备散热状态不同等因素结果波动往往很大。所以端侧模型评测难本质上是因为评测体系没有跟上部署场景的复杂度。我们需要的不只是一台机器、一个脚本、一行分数而是一个能把四层变量固定下来、统一口径、允许二次复现的框架。Pipette 正是冲着这个问题来的。2. 四个关键维度模型、量化、运行时、硬件要理解 Pipette 这类工具先要把端侧评测的四层结构拆清楚。它们各自解决不同的问题也各自有最容易被误解的地方。模型层指的是模型本身的结构和参数量。端侧部署通常使用 0.5B 到 7B 级别的小模型结构上以 Transformer 及其变体为主也有一些新的状态空间模型尝试在长上下文和低显存上做突破。模型层的评测重点是“在有限资源下这个模型能不能完成我的任务”而不是简单看参数多少。两个参数量接近的模型由于训练数据、结构设计、上下文长度的差异实际端侧体验可能差很多。量化层指的是把权重从高精度浮点数压缩到低比特整数例如 INT8、INT4或者是 GGUF 这类打包格式下的 Q4_K_M、Q5_K_M 等具体策略。量化之所以在端侧重要是因为端侧推理通常是内存带宽瓶颈——权重要从内存搬到计算单元权重越小同样带宽下能处理的 token 就越多。但量化会带来精度损失尤其对数学推理、中文语义理解、长文本等敏感任务INT4 的掉点可能很明显。真正的难点在于不同模型对低比特的敏感度不同不能只看“量化后还能用”就拍板上线。运行时层指的是具体的推理执行引擎例如 llama.cpp、ONNX Runtime、MLC LLM、ExecuTorch、TensorRT-LLM、OpenVINO 等。每个运行时在不同硬件上的算子优化、线程调度、内存管理策略都不一样直接影响延迟和吞吐。同一个模型加同一个量化格式在 llama.cpp 上可能在 CPU 跑得不错在 ONNX Runtime 上则更适合 NPU 的算子融合。运行时选得好不好往往决定了端侧体验是“能用”还是“好用”。硬件层指的是 CPU、GPU、NPU以及各类端侧 SoC。端侧硬件最让人头疼的是 NPU 的算子支持范围有限。很多 NPU 对动态 shape、某些激活函数、自定义 attention 实现并不友好导致模型明明能跑但在 NPU 上加载失败或推理速度很慢。评测时必须区分“功能上能跑”和“性能上达标”这也是把硬件纳入评测体系的原因。评测维度主要解决的问题端侧常见选项最容易踩的坑模型层任务能力与资源占用0.5B7B 开源模型只看参数量忽略上下文和结构差异量化层压缩权重、降低带宽压力INT8、INT4、GGUF Q4_K_M 等位宽越低越好忽略精度掉点运行时层算子调度与执行效率llama.cpp、ONNX Runtime、MLC LLM 等只看一个运行时的结果忽略迁移成本硬件层底层算力与算子支持CPU、GPU、NPU、端侧 SoCNPU 不支持某个算子时无法直接运行这四个维度叠加在一起就构成了端侧评测的完整空间。Pipette 的定位就是把这个空间变成一套可配置、可执行、可复现的测试矩阵。3. Pipette 是什么定位、设计理念与核心能力Pipette 是 Liquid AI 开源的一套基准测试套件。Liquid AI 是一家由 MIT 孵化的 AI 公司研究方向偏向液态神经网络Liquid Neural Networks等非传统架构也发布过多个自研模型。Pipette 从名字上就带着“精确取样”的实验室气质——一支移液枪每次取样的体积都非常精确。这个命名暗示了工具的核心追求把基准测试做得严谨、可复现而不是跑个热闹。从定位上看Pipette 不是又一个模型能力排行榜。它更关心的是工程指标延迟、吞吐、峰值内存、量化后的实际效果。它把“模型、量化、运行时、硬件”组合成一个测试矩阵通过配置文件统一定义然后自动执行并导出结果。这样做最大的优势是你的评测配置本身可以被保存、评审、沉淀别人拿到同一份配置和同一批设备可以复现出近似的结果。这就是“可复现基准套件”的含义。Pipette 的设计思路可以直接对应到端侧评测的痛点第一用配置驱动测试矩阵避免手动一组一组跑第二统一采样口径比如固定输入长度和输出长度让不同组合可以横向比较第三支持多种运行时减少“环境不同导致结果不可比”的问题第四把结果结构化导出方便后续用脚本做分析和决策。有人可能会把它和 lm-evaluation-harness、OpenCompass 这类模型评测工具做对比。实际上它们的侧重点不同lm-evaluation-harness 更多关注模型在知识问答、推理、代码等任务上的能力分数回答的是“模型能力强不强”Pipette 更关注部署时的工程指标回答的是“在给定硬件和推理配置下模型跑得快不快、占用高不高”。两者是互补关系一个管质量一个管性能。如果只做能力评测不测部署性能上线时还是会翻车。从另一个角度看Pipette 的诞生也反映了端侧 AI 的一个变化趋势模型选择正在从“挑最强模型”变成“挑最合适的部署组合”。过去可以只看参数量和 benchmark 分数现在则必须在真实运行时、量化方案、目标硬件共同约束下做决策。谁把评测工具做得更接近真实工程环境谁就能更快把模型落地到产品里。4. 用 Pipette 跑一个最小评测思路与示例这一节用思路加示例的方式演示如何把 Pipette 的理念落地。需要说明的是Pipette 本身迭代较快具体命令、配置字段和输出格式请以官方仓库 README 和对应版本的--help为准。下面给出的是一个贴近 CLI 设计思路的演示重点是帮助读者理解“配置驱动评测”的完整流程。4.1 环境准备与版本提醒在开始之前建议先确认三件事Python 环境版本。这类工具通常需要 Python 3.10 或更高版本具体以项目文档为准。目标运行时是否已安装。例如要用 llama.cpp就需要先把对应可执行文件或 Python 绑定装好并确保能在命令行中直接调用。测试设备是否可用。CPU、GPU、NPU 的驱动和 SDK 版本要提前确认尤其是 NPU 往往还需要额外的编译工具链。如果你是在本地测试可以先运行一次帮助命令确认当前安装的版本支持哪些子命令和参数pipette --help如果版本更新导致命令变化以实际输出为准。第一次跑通不用急着追求完整矩阵能在一个硬件上跑通一个模型加一个运行时就已经成功了一半。4.2 编写评测配置Pipette 这类工具的核心是配置驱动。你需要在配置文件中定义要测的模型、运行时、量化方式、硬件以及指标口径。一个最小配置可能长这样# benchmark-demo.yaml演示配置字段以官方文档为准 project: mobile-demo models: - name: qwen2.5-3b-instruct - name: gemma-3-4b-it runtimes: - name: llama.cpp - name: onnxruntime quantizations: - q4_k_m - int8 hardware: - cpu - npu benchmark: prompt_len: 512 max_new_tokens: 128 repetitions: 5 metrics: [ttft, tokens_per_second, peak_memory]这个配置表达的意思是在 CPU 和 NPU 两台目标硬件上用 llama.cpp 和 ONNX Runtime 两个运行时分别测试 Q4_K_M 与 INT8 两种量化格式下的两个模型每种组合重复 5 次记录首 token 延迟、生成速度和峰值内存。这样一个 2 × 2 × 2 × 2 × 5 的矩阵就能初步回答“哪个模型更适合我的设备”的问题。关键点在于metrics字段。如果只测 tokens_per_second你可能会漏掉交互场景最在意的首 token 延迟如果只测延迟又可能忽略批量处理时的吞吐能力。先想清楚自己的产品是对话、流式输出还是离线批量任务再确定指标组合。4.3 运行评测配置写好后运行方式通常是一行命令加上配置文件和输出路径pipette run --config ./benchmark-demo.yaml --output ./results.csv这条命令会按照配置依次初始化各个运行时、加载模型、执行量化、预热设备然后开始正式评测。如果某个运行时没有安装工具会报错并跳过或中断日志里会有明确提示。运行过程中最需要注意的是设备状态。端侧设备很容易受到散热和后台任务影响正式评测前最好关闭无关进程让设备空闲几分钟。如果使用了 NPU还要留意 SDK 是否已经正确初始化有些型号需要在评测前单独运行一次设备初始化脚本。4.4 结果导出与简单分析Pipette 导出的结果一般是 CSV 或 JSON 格式。得到结果后可以用脚本做汇总。下面这段 Python 脚本适合做初步分析它会把每个“模型 运行时 量化 硬件”组合的中位数汇总出来并按硬件分组找出速度最快的组合# analyze_pipette_results.py import pandas as pd df pd.read_csv(results.csv) summary df.groupby( [model, runtime, quantization, hardware] ).agg( ttft_p50(ttft_ms, lambda x: x.median()), tps_p50(tokens_per_second, lambda x: x.median()), peak_memory_mb(peak_memory_mb, median), ).reset_index() # 按硬件维度分别找吞吐最高的组合 best_per_hardware summary.loc[ summary.groupby(hardware)[tps_p50].idxmax() ] print(best_per_hardware.to_string(indexFalse))脚本本身不依赖特定框架只要 CSV 列名与导出格式一致即可。建议第一次先打印df.columns确认列名后再跑分析避免因为字段名不一致而报错。运行方式python analyze_pipette_results.py这一步的作用不是直接拍板用哪个模型而是把大量组合缩小到一个候选清单然后针对候选清单做更细的验证。5. 评测结果怎么解读延迟、吞吐与内存的三角拿到结果后很多人第一反应是“找数字最大的那个”。但在端侧场景数字必须结合真实使用方式来看否则很容易选错。第一个关键指标是首 token 延迟也就是 TTFTTime To First Token。它决定用户输入 prompt 之后多久看到第一个字。聊天助手、智能客服这类交互场景TTFT 直接决定“卡不卡”。TTFT 主要受 prefill 阶段影响也就是模型一次性处理输入 token 的时间。输入越长TTFT 越长。所以评测时一定要固定 prompt 长度否则不同测试之间没有可比性。第二个关键指标是 tokens_per_second它反映的是生成阶段的速度也就是模型逐字输出的效率。长文本生成、摘要、代码补全这类场景会更关注这个指标。需要注意的是TTFT 快不代表生成速度快有些模型 prefill 优化得很好但解码很慢总体体验依然不行。只看其中一项都会误判。第三个关键指标是峰值内存。模型能不能跑起来取决于峰值内存是否超过设备可用上限。尤其在手机和嵌入式设备上内存限制非常硬哪怕推理速度快得惊人内存不够也是白搭。量化在这里的作用最明显从 FP16 压到 INT4权重体积能减少约 75%峰值内存随之下降但代价可能是精度损失和额外反量化开销。第四个容易被忽略的指标是量化后的模型质量。速度再快如果输出结果已经开始胡言乱语那也没有意义。更稳妥的做法是先用 MMLU、C-Eval、GSM8K 等通用评测集对比量化前后的准确率再在评测矩阵里加入一份与你自己业务相关的验证集。这样既能看速度也能看质量。解读结果时我建议不要只看平均值。端侧设备受频率波动、散热影响很大同样的 run 可能相差 10% 以上。更稳妥的方式是多次运行后取中位数或者 p90并记录设备温度和测试时间这样结果才有参考价值。6. 常见问题与排查思路Pipette 这类工具第一次跑通时通常会遇到不少问题。下面整理了几类高频问题按“现象、可能原因、排查方式、解决方案”列出方便直接对照。问题现象可能原因排查方式解决方案运行时报错找不到运行时可执行文件llama.cpp 或 ONNX Runtime 等引擎未安装或未加入 PATH先运行llama-cli --version等命令确认安装对应运行时并在评测配置中指定可执行文件路径模型加载失败模型格式与运行时不匹配例如 GGUF 不能被 ONNX Runtime 直接加载查看日志中加载器报错信息按运行时支持的格式准备模型或先用无量化版本打通流程NPU 上无法运行或异常慢NPU 对部分算子、动态 shape 支持不完整换 CPU/GPU 对照运行查看 NPU 编译日志先用 CPU 验证模型可用性再逐步调整算子兼容性重复运行结果波动大未预热、设备散热、后台任务占用、输出 token 长度不一致固定 prompt 和 max_new_tokens检查设备温度正式测试前多跑几轮取中位数或 p90 作为结果量化后输出质量明显下降量化位宽太低或模型对低比特量化敏感对比 FP16 输出用任务评测集算准确率换用 Q8/INT8或对关键网络层做混合精度评测组合太多跑不完测试矩阵没有收敛盲目扩大模型和量化范围查看社区是否有同设备下的现成结果先用 2 × 2 × 2 小矩阵跑通再按需扩展如果一上来就报错不要急着怀疑工具本身。按照“环境依赖 → 模型格式 → 设备 SDK → 测试口径”这个顺序排查大概率能快速定位问题。最难排查的一类问题是“结果波动”因为它不是某个配置出错而是评测环境不够干净。建议准备一个固定测试脚本把设备状态、输入长度、输出长度、轮数全部记录下来形成团队内部统一的评测基线。7. 把评测变成选型决策最佳实践与工程建议Pipette 这类评测套件真正适合的团队是那些已经经历过“模型选型靠拍脑袋”的痛苦希望把部署决策从经验判断升级为数据判断的团队。如果只是偶尔跑一次对比手工脚本也许够用但如果你需要多次迭代模型和运行时就值得把评测流程沉淀成标准化的工具链。第一条建议是先定业务场景再定评测矩阵。是对话助手、离线翻译、端侧摘要还是流式代码补全不同场景对延迟、吞吐、内存的权重完全不同。评测指标如果和业务场景脱节跑出来再漂亮的数字也是装饰品。第二条建议是固定测试口径把评测配置入库管理。prompt 长度、max_new_tokens、重复次数、预热方式、设备温度记录都要固定下来。配置文件本身要放到仓库里随代码演进。这样当团队成员质疑“为什么选这个模型”时你可以直接甩出一份可复现的配置和结果而不必反复解释。第三条建议是在评测矩阵里同时加入质量验证。速度是工程指标质量是任务指标两个维度必须同时看。可以在每个候选组合上跑一个小的业务验证集记录准确率或关键任务成功率再和性能指标一起对比。这样能避免“量化后速度快了但回答已经不靠谱了”的问题。第四条建议是生产环境切换前先灰度后回滚。即便评测数据很漂亮也不能直接全量替换生产环境。更稳妥的做法是先在部分流量上验证真实用户反馈再逐步放大。同时保留旧模型和旧运行时的部署配置一旦出现问题能快速回滚。第五条建议与安全相关运行第三方模型、推理引擎时要关注模型授权和数据处理边界不要将敏感请求直接发送到未经验证的远端服务。评测过程中产生的日志和数据也要按最小权限原则管理。这里的“安全”不只是部署安全还包括模型使用合规和数据隐私。最后一条是工程协作上的建议把评测结果做成团队内部可查询的记录而不是散落在个人电脑上的 CSV 文件。可以按“日期、硬件、模型、运行时、量化、指标”整理成一张宽表沉淀成选型知识库。时间久了这张表就是团队最值钱的部署经验资产。8. 总结与后续学习方向端侧模型评测正在从“跑个分发个榜”走向“可复现的工程决策”。Pipette 的价值不在于它比别的 benchmArark 工具“更准”而在于它把模型、量化、运行时、硬件四个变量放进了一套统一的执行框架让评测结果可以被保存、复现、比较。对开发者来说这比一个简单的排行榜有用得多。如果你是第一次接触这类工具建议下一步做三件事第一去官方仓库把 README 读完跑通一个最小示例不要急着挂大矩阵第二结合自己的业务场景定义 5 到 6 个关键指标写一份固定口径的测试配置第三把量化前后的模型质量评估加入流程形成“性能 质量”双指标选型机制。端侧模型的选型本质上是一场约束下的优化硬件预算、内存上限、延迟要求、质量底线缺一不可。工具只能帮你把数字测得准最终选择还是要回到你的产品场景里。希望这篇文章能把评测的思路讲清楚也建议你先收藏等真正开始做端侧模型选型时再对照跑一遍。欢迎在评论区分享你在端侧评测中遇到的有趣问题。