模型在开发机上的速度和部署到用户手机后的速度经常是两套完全不同的叙事。你在 A100 上跑得挺流畅稍微量化一下放到某款国产开发板上结果连启动都费劲就算勉强能跑同一个“Q4 量化”在不同运行时里产出的效果和延迟也常常对不上。这个时候你会开始怀疑到底是不是模型选错了实际上模型选错的情况很少真正的问题往往出在评测维度太少。端侧模型的好坏从来不是模型参数单独决定的而是由“模型架构 × 量化方式 × 运行时后端 × 硬件平台”四个变量共同决定的。只改其中一个变量结论就可能反转。正因如此Liquid AI 开源的 Pipette 才会值得关注——它不是又造了一个新跑分脚本而是把“评测过程”本身变成了一套可复现、可配置、可对比的工程资产。这篇文章会先说明为什么端侧模型评测必须把模型、量化、运行时和硬件绑在一起看再拆解 Pipette 的核心设计理念然后给出一套通用的配置化评测思路帮你理解这类工具到底解决了什么问题以及在实际项目中怎么用、有哪些坑要避开。1. 为什么“端侧模型 量化 运行时 硬件”不能分开谈1.1 端侧模型的前提是算力受限端侧模型之所以存在是因为推理场景不是永远都有一张满血显卡在等你。手机、智能摄像头、机器人、车载盒子、开发板这些设备的共同点是算力有限、内存带宽有限、功耗预算有限。要在这种环境里跑大语言模型第一件事就是降低计算和存储开销。最常见的做法就是量化。把 FP16 权重压缩成 INT8、INT4 甚至更低可以显著减少内存占用和访存开销。模型变小之后不仅加载速度变快推理时的单位 token 成本也会下降。对于端侧场景量化不是可选项而是必选项。但量化也不是免费午餐。精度损失、算子兼容性、激活值溢出都是实际部署时要面对的问题。更关键的是同样的模型、同样的量化位宽在不同运行时里走的是完全不同的优化路径最终效果和速度会有肉眼可见的差异。1.2 量化不是一种“无损压缩”很多人会把“INT4 量化”理解成一种统一格式好像同一个模型量化成 INT4 后无论用什么推理引擎加载结果都应该一致。这个理解是错的。先看最常见的三种格式GGUF由 llama.cpp 生态推广适合 CPU 设备最常见的文件格式之一。它的量化方案更多不同量化级别之间差异很大。MLXApple 生态的机器学习框架利用统一内存架构适合 Apple Silicon 设备的 GPU/CPU 协同推理。ONNX中间表示格式生态较完善配合 ONNX Runtime 可以在多种硬件后端上运行。同样是“4-bit 量化”在 GGUF 和 MLX 里对应的是不同算子实现和不同的缩放策略。即使位宽一致两者的激活值处理和反量化方式也可能不完全一样。所以当你比较“量化是不是变笨了”时必须先说明是用哪个运行时测的否则结论没有意义。1.3 同一份模型不同运行时表现差异巨大我印象很深的一次排错经历同一个 Qwen 小模型在 llama.cpp 的 GGUF 版本里能跑出 50 token/s但换到另外一个只做了 ONNX FP16 的工程里速度只有 8 token/s。模型没变硬件没变变的是运行时对算子、缓存、线程调度和内存分配的优化程度。运行时决定了计算图如何被切分、哪些算子会被融合、哪些量化层可以走硬件加速、KV Cache 怎么分配。它远比“调包”“换动态库”复杂。这也意味着评测结果如果不写清运行时版本、编译选项和后端配置基本就无法复现。在端侧场景里运行时还决定了能否利用 NPU、DSP 这类专用单元。同一个模型在 CPU 上用默认运行时跑和在 NPU 上加速跑延迟完全不是一个量级。所以评测端侧模型时把运行时列在结果表里不只是“严谨”而是决定结论是否可信的前提。1.4 硬件平台会改变瓶颈位置端侧硬件不像服务器 GPU 那样规格统一。以内存带宽为例LLM 推理是典型的 memory-bound 场景token 生成速度高度依赖内存带宽而不是峰值算力。开发板用 LPDDR4和笔记本上的 LPDDR5 差距完全可能带来数倍速度差异。除了内存带宽还有 CPU 微架构、GPU 核心数、NPU 算力、缓存层级、散热功耗墙等变量。同一段代码在树莓派上跑和在 RK3588 上跑表现完全不同。开发者在 x86 服务器上做了很漂亮的推理延迟优化放到 ARM 设备上可能直接失效。所以端侧模型评测不是“单点调试”而是一张多维矩阵。这个矩阵里的四个轴正是模型、量化、运行时、硬件。这也是 Pipette 这类工具想标准化的东西。2. Liquid AI 与 Pipette 是什么Liquid AI 是一家以非 Transformer 架构为特色的 AI 公司团队背景来自 MIT 等研究机构主打液态神经网络Liquid Neural Networks和对应的基础模型 LFM 系列。过去一两年里他们陆续开源了 LFM-1B、LFM-3B、LFM-3.6B 等一系列面向端侧和高效推理的模型权重。做开源模型的公司通常也会面临一个很现实的工程问题模型开源出去用户会用自己的硬件、自己的运行时去跑跑出来的结果千差万别。有人反馈“模型质量不错但速度太慢”有人反馈“量化之后质量下降明显”也有人反馈“我这个设备跑不起来”。这些问题不一定都出在模型本身但很难向用户解释清楚。Pipette 就是在这种背景下出现的。从公开的设计思路来看它是一套“计算与运行时无关”的模型质量基准框架。核心目标是把模型的评估过程做成可复现的配置让同一个模型可以在不同的量化方式、运行时后端、硬件设备上用同一套评测脚本跑出可对比的结构化结果。直白一点说Pipette 想当那个“标准答案输入器”。它不只会告诉你“模型准确率是多少”还会告诉你在哪台机器上用哪个运行时、哪个量化级别、哪个评测任务上得出的准确率。以后你再看到“某个模型效果不错”时可以去追问一句它是在什么运行时、什么量化条件下测出来的如果这句话无法回答那个结论可能就是不可复现的。3. Pipette 的核心设计理念3.1 配置驱动而不是脚本驱动传统评测脚本的写法是写一个 Python 文件内部定义加载模型的路径、调用推理的 API、跑任务集的逻辑。换一个模型就要改代码换一个运行时又要改代码。结果就是评测脚本和具体项目强耦合很难复用。Pipette 更偏向配置驱动。模型、运行时、硬件、评测任务、输出指标都用配置来描述。评测流程是从配置里生成出来的而不是埋死在代码里。配置文件的本质是“把评测意图记录下来”任何人拿到同一份配置理论上就能复现同一组结果。这种设计带来的好处是工程化的。你可以把评测配置提交到 Git跟随项目版本一起演进可以在 CI 里自动跑可以在不同机器上重复执行。评测不再是某个同学本地的一堆脚本而是团队资产。3.2 模型、运行时、硬件三层解耦配置驱动最难的地方不是“用 YAML 写参数”而是把不同类型的变量拆开管理。Pipette 的做法倾向于把模型、运行时、硬件分成独立维度。这意味着你可以在不改动任何评测任务的前提下把同一个模型的 GGUF 版本换成 MLX 版本然后对比结果。也可以在同一个模型、同一个运行时下分别用 M 系列芯片的设备跑一次再用 x86 CPU 跑一次。每一层的变化都只影响需要改的那一层配置其他部分保持不变。三层解耦的另一个好处是不同设备可以共享一套“任务逻辑”。评测任务是模型无关的它关心的是“给定输入模型给出的输出是否正确、是否足够快”。模型层和运行时层替换后任务层完全不用动。3.3 可复现的核心是记录所有关键变量如果把评测结果看成一个公式的输出那这个公式里的变量远不止“模型权重”和“硬件型号”。至少包括模型权重的来源和 hash 值量化脚本或量化配置量化后文件的具体格式运行时版本、编译选项、后端配置采样参数temperature、top_p、seed评测任务的具体版本和样例集合硬件型号、驱动版本、运行状态。这些变量里只要有一个没锁定结果就可能无法复现。Pipette 的意义就在于提醒你把它们固化下来而不是每次都靠口头沟通“环境差不多”。3.4 面向自动化输出评测结果不能只打印在终端里还要能被后续分析工具消费。因此面向自动化的工具通常会输出 JSON、CSV 这类结构化结果。Pipette 的设计也符合这个思路评测输出带上足够的元信息包括配置组合、硬件信息、任务名、指标名等等。有了结构化输出才能进行横向对比、绘制趋势图、生成报告也才能把评测链路接入自动化流水线。否则评测一次就要人工记录一次做不了规模化对比。4. 用配置化思路组织一次端侧评测示例为了让概念更具体下面我给出一个通用示例。先说明这是为了展示“配置化评测”的组织思路字段名和命令示例不一定与你安装到手的 Pipette 版本完全一致实际使用前一定要核对你所下版本的官方 README 或 schema。4.1 一个最小配置示例假设我们要在 Apple 设备上评测一个 3B 级别模型使用 MLX 运行时量化位宽用 4-bit评测任务用 HellaSwag。配置大致会长成下面这样# pipette-example.yaml # 通用示例实际字段名以官方文档为准 model: name: liquidai/LFM-3B source: huggingface format: mlx quantization: bits: 4 runtime: backend: mlx options: max_tokens: 512 temperature: 0.0 hardware: device: mac-mini-m4 memory: 16 tasks: - name: hellaswag limit: 100这个配置表达了一个完整的评测单元用什么模型、什么量化格式、什么运行时、什么硬件、跑什么任务。其中temperature: 0.0是为了让采样确定性更强这一点在做可复现评测时非常关键。如果你想对比 GGUF 版本只需要另写一份配置把format改为ggufruntime改为llama.cpp对应的后端其余部分保持不变# pipette-example-gguf.yaml model: name: liquidai/LFM-3B source: huggingface format: gguf quantization: kind: q4_k_m runtime: backend: llama.cpp options: n_ctx: 4096 n_gpu_layers: -1 hardware: device: mac-mini-m4 memory: 16 tasks: - name: hellaswag limit: 100两份配置之间的差异正好量化了“不同运行时 不同量化格式”带来的影响。4.2 命令行入口配置化工具通常只需要一个很薄的命令入口。假设你安装的 CLI 支持类似下面这样的用法# 示意命令实际子命令请以安装版本的帮助为准 pipette run --config pipette-example-mlx.yaml pipette run --config pipette-example-gguf.yaml如果你连命令行名字都不确定可以先运行帮助命令pipette --help这个命令一般会列出所有支持的子命令例如“run”“evaluate”“report”等。在接入手动实践前先看帮助信息是永远正确的第一步。4.3 结构化输出理想情况下评测结果会带着完整配置信息输出比如[ { config: lfm-3b-mlx-4bit, hardware: mac-mini-m4, task: hellaswag, accuracy: 0.5010, tokens_per_second: 64.2, peak_memory_mb: 2816 }, { config: lfm-3b-gguf-q4_k_m, hardware: mac-mini-m4, task: hellaswag, accuracy: 0.4985, tokens_per_second: 58.7, peak_memory_mb: 2740 } ]注意这里config字段不只是模型名而是“模型 运行时 量化方式”的组合标识。否则两行结果都叫“LFM-3B”你根本分不清是哪一组配置跑出来的。如果你接手的项目没有输出这种结构化数据建议自己也按这个思路去补一份结果表把 model、quantization、runtime、hardware 作为独立列记录。5. 怎么把评测结果读透5.1 准确率和速度要分开看评测结果里有两类完全不同、不能混为一谈的指标任务质量指标accuracy、F1、perplexity衡量“模型输出答不对题”。性能指标tokens_per_second、首 token 延迟、峰值内存衡量“模型跑得够不够快”。一个模型可能是质量很高但慢到没法用也可能是快但笨到不能用。把这两类指标混成一个大分除了制造焦虑没有任何工程价值。Pipette 这类工具把它们分开输出恰恰是希望大家分别分析。5.2 不要只看 token/s在端侧场景里tokens_per_second 是一个容易误导人的指标。它受上下文长度、KV Cache 命中率、批处理大小、是否预热、是否降频等因素影响很大。一个更完整的性能视图应该包含首 token 延迟TTFT用户开始感知到输出的等待时间平均生成速度稳定生成阶段每秒产出的 token 数峰值内存运行时的最大内存占用稳定性多次运行结果的标准差。比较两个配置时建议把同一行的 token/s 和峰值内存一起看。如果一个配置保存了非常多的内存但速度只快了一点点那它在真实设备上可能并不划算。5.3 建议的对比矩阵实际做评测时不必一上来就跑满所有组合建议优先做以下四组对比维度固定变量改变变量你能看出什么量化位宽模型、运行时、硬件INT8 / INT4 / FP16量化对质量的损失和速度收益运行时后端模型、硬件GGUF / MLX / ONNX哪个引擎最适合当前设备硬件平台模型、运行时不同 CPU / 开发板硬件迁移后的性能余量采样参数模型、运行时、硬件temperature / seed结果是否稳定是否能复现这个矩阵跑完之后你对“某个模型能不能用”的判断会从“感觉还行”升级成“在哪个配置下达到什么表现”这就是评测工程化的意义。5.4 只有同一套配置矩阵结论才公平经常有人直接拿“某论坛的跑分”和“自己本地的结果”对比然后得出“这个模型很拉”的结论。这是典型的不可比对比。要对比就必须保证模型、量化、运行时、硬件、任务集、采样参数全部对齐。只要其中一项不同结果差异就无法归因。Pipette 对复现性的强调本质上是在帮你建立这种“对比合法性”。它输出的不只是数值而是让每个数值都有上下文、有来源、可被质疑和验证。6. 端侧模型评测常见问题与排查思路评测过程中遇到的问题往往比评测本身还多。下面这些是我在类似工作中见过的高频问题你可以对照排查。问题现象可能原因排查方式解决方案模型加载后直接报“算子不支持”运行时版本过旧或量化后的算子无法映射到当前后端查看运行时完整日志确认报错算子名称升级运行时或切换量化格式/位宽换一个设备后速度差异巨大硬件内存带宽不同或运行时没有启用硬件加速使用性能分析工具查看 CPU/GPU/NPU 占用更新运行时配置确认后端的设备设置token/s 忽高忽低设备温度墙、后台任务、未做预热先跑一次 warmup多次运行取中位数固定设备状态关闭后台任务增加重复次数评测结果无法复现依赖版本、编译选项、采样参数未锁定对比两次运行的环境信息锁版本固化配置记录 hashGPU 显存/统一内存溢出上下文长度过大量化位宽不够低查看峰值内存指标降低n_ctx或换用更低 bit 量化准确率和别人报告的对不上任务集版本不一致比如用了不同的采样样本对比任务集文件 hash 和数量统一评测数据集版本命令运行到一半就卡死任务集过大模型加载过慢查看进程资源占用先用 100 条样本冒烟测通量化后模型明显变笨量化位宽过低或校准数据集不匹配对比同任务下 INT8 与 INT4 结果换量化方案或跳过低比特量化排查时有个核心原则永远从“最新、最全的日志”入手。不要凭经验去猜先把模型加载日志、推理日志、错误栈完整打出来再逐条比对。大多数问题都能在日志里找到线索。7. 端侧模型评测最佳实践7.1 先跑通最小样例再跑完整矩阵端侧设备编译慢、加载慢、运行慢一次全量评测可能要好几个小时。建议任何评测开始前先用很小的任务集例如 10 到 100 条样本确认配置能跑通再无限放大。一边调配置一边全量跑是在浪费生命。7.2 统一锁定版本和环境评测代码、运行时版本、Python 依赖、Docker 镜像、编译选项只要有一项版本漂移结果就不能对比。最稳的做法是把依赖写进 requirements 或 environment.yml用固定 tag 的镜像记录编译命令和硬件固件版本必要时锁定运行时动态库的 hash。7.3 严格固定采样参数语言模型推理有随机性。如果不固定 temperature、top_p 和 seed同一份配置两次跑出来的结果就会不同。可复现评测的最低要求就是固定 temperature0 或锁 seed。某些框架还要关闭 beam search 等随机策略否则准确率指标会产生不可控波动。7.4 记录权重 hash 和文件大小模型权重文件可能悄悄变化。你今天评测的 LFM-3B和下周重新下载的 LFM-3B可能是不同版本的权重。建议在评测配置和结果输出中记录权重文件 hash 和文件大小。变更任何权重都必须重新评测而不是沿用旧结果。7.5 评测环境与日常开发环境分离评测机器上不要跑其他高负载任务。后台编译、浏览器视频、其他容器调度都会干扰推理速度。尤其是端侧设备CPU 频率和散热状态很容易受外部影响。最好在评测脚本里加入 system load 检测负载过高就中途退出或重新跑。7.6 把评测写进 CI如果团队长期在迭代端侧模型部署建议把“最小评测集”做实并接入 CI。这样每次 PR 修改运行时配置或量化脚本时都会自动触发一次冒烟评测能在早期发现“模型效果退化”或“性能回退”的问题而不是等问题进到真实设备上才发现。7.7 不要把单一结果当成全量结论一个模型在 mac-mini 上跑得快不代表它在某个 Android 设备上也快在 HellaSwag 上的准确率也不能代表它在代码生成任务上的表现。任何单一结果都只是矩阵中的一个坐标点。真正有价值的是把评测配置组合成一份可扩展、可回归的矩阵持续积累数据。8. 总结与后续实践方向从表面看Liquid AI 开源 Pipette 只是多了一个“跑分工具”。但它的设计思路真正值得学习的地方是把模型、量化、运行时、硬件这四个容易混在一起的维度拆开用配置驱动的方式固定评测流程再用结构化输出保证结果是可追溯、可对比、可复现的。如果你正在做端侧模型选型、量化对比、运行时切换或软硬件适配建议按这篇文章里的思路先去组一份最小评测配置一个模型、一个运行时、一个量化级别、一个任务、一个硬件。把它完整跑通保存配置和输出再逐步扩展成矩阵。你会比大多数人更早发现真正的性能差异往往不在模型名上而在那些你看不见的运行时选项和设备内存带宽里。把这个能力沉淀成团队的评测基线之后下一步自然就会延伸出更复杂的问题模型在不同上下文长度下的表现如何变化极低比特量化对特定任务的鲁棒性如何NPU 编译后的模型和 CPU 后端版本差距有多大这些方向都有一个共同前提——先有一份可复现的评测底座。Pipette 这类工具正好提供了这样一个起点。