模型端侧部署最头疼的是什么不是模型本身效果不好而是“换一块硬件、换一个推理框架、换一种量化方式结果就完全不一样”。同一个 2B 模型在 A 手机芯片上跑 30ms到了 B 边缘设备上可能变成 120ms精度还会掉一截。更麻烦的是团队里每个人用的评估口径还不一样有人看首 token 延迟有人看峰值内存有人只看量化后的困惑度最后得出的结论很难横向对比。Liquid AI 开源的 Pipette正是为了解决这个“评测碎片化”问题而设计的一套可复现基准套件。它把端侧模型、量化方案、运行时、硬件四个关键变量放到同一个评测框架里让开发者可以在统一口径下做对比实验。本文会用工程视角拆解 Pipette 的设计思路、核心概念、评测维度以及如何把它接入自己的端侧模型评测流程中。如果你是做端侧 AI 应用、模型部署、推理框架选型或者正在为量化方案纠结这篇文章会比较适合你。1. 为什么端侧评测这么难四个变量互相影响在深入 Pipette 之前先理解它要解决的核心问题——端侧推理评测为什么比服务端评测复杂得多。服务端的评测相对简单GPU 型号固定、CUDA 版本固定、批量大小可调跑一个 benchmark 脚本就能得到比较稳定的吞吐数据。但到了端侧场景变量一下子增加了第一个变量是模型本身。同样是 7B 参数稠密模型和 MoE 模型在不同硬件上的表现差异巨大同样是 2B 模型不同网络结构对算力、带宽的敏感度完全不同。第二个变量是量化方案。W8A8 量化、W4A16 量化、GPTQ、AWQ、GGUF 的 Q4_K_M每种量化方法对精度的影响不同对硬件的适配程度也不同。有些量化格式在 GPU 上表现很好拿到端侧 NPU 上反而因为算子不支持而降级成 CPU 推理。第三个变量是运行时。同一个模型可以用 ONNX Runtime、TensorRT、llama.cpp、MNN、TFLite、Core ML 等多个框架加载。不同运行时对算子融合、内存复用、多线程调度的策略差异很大直接决定推理效率。第四个变量是硬件。手机 SoC、嵌入式开发板、边缘盒子、笔记本 CPU它们的算力、内存带宽、缓存大小、NPU 架构都不同。同一份量化模型在不同硬件上的表现可能完全不在一个量级。关键在于这四个变量不是独立的而是互相耦合。量化方式会影响运行时的算子选择运行时又决定硬件算力的利用率硬件反过来又限制量化格式的支持范围。单独测某一个变量得出的结论是片面的。Pipette 的思路是把这四个变量放到一个可组合的评测框架里通过固定其他变量、改变目标变量的方式给出可横向对比的结果。2. Pipette 项目定位与核心设计2.1 Pipette 是什么Pipette 是 Liquid AI 开源的一套端侧模型评测框基准套件。它专注于端侧模型、量化、运行时、硬件这四个维度的交叉评测强调“可复现”和“标准化”。“可复现”是 Pipette 最核心的追求。端侧评测场景中很多实验都是“跑完就没了”环境变了、依赖版本变了、硬件调度策略变了结果就对不上了。Pipette 通过统一评测流程、统一指标采集、统一环境描述让同一个评测任务在不同时间、不同机器上尽量得到一致的结果。2.2 评测对象与热词中“量化”的区别这里需要先澄清一个容易混淆的概念。在端侧 AI 领域“量化”指的是模型量化Model Quantization即把神经网络中的浮点参数和激活值用较低比特数表示以减少内存占用、加速计算是端侧部署的关键技术。它跟金融领域的“量化交易”是两个完全不同的概念本文讨论的全部是模型量化相关的内容。模型量化的核心权衡是精度损失 vs 性能收益。Pipette 的评测目标之一就是让这种权衡变得可度量、可比较。2.3 核心设计理念四维矩阵式评测Pipette 的评测思路可以这样理解它定义了一个四维矩阵每个维度内可以配置不同的选项。评测维度可配置选项示例评测关注点模型不同参数量、不同架构Dense/MoE、不同任务类型推理质量、资源占用量化FP16/BF16、W8A8、W4A16、GPTQ、AWQ、GGUF 等精度损失、显存/内存节省、推理加速比运行时ONNX Runtime、llama.cpp、MNN、TensorRT、TFLite算子兼容性、延迟、吞吐硬件手机 SoC、ARM 开发板、x86 边缘设备、NPU算力利用率、功耗、发热实际评测时通常采用控制变量法固定三个维度改变一个维度观察指标变化。例如固定模型、量化方案、运行时切换不同硬件评估硬件对延迟的影响固定模型、硬件、运行时切换不同量化方案评估量化对精度和速度的影响固定模型、量化方案、硬件切换不同运行时评估框架的优化水平。这种矩阵式的评测方式比单独跑一两个 benchmark 脚本更能反映生产环境的真实情况。3. 环境准备与版本注意事项在开始使用 Pipette 之前需要明确一点由于端侧评测涉及多个不同生态的组件环境差异会导致结果偏差所以环境标准化本身就是评测的一部分。一般建议从以下几方面做准备操作系统Linux 和 macOS 是端侧评测最常用的系统。Windows 在部分工具链上兼容性不佳但通过 WSL2 也能运行部分评测。需要根据你实际的目标部署环境来选择。Python 环境建议使用 Python 3.9 或 3.10 版本。评测框架的依赖库如 PyTorch、ONNX、numpy在不同版本下行为有差异。推荐使用虚拟环境或 conda 管理依赖避免污染系统环境。推理引擎根据你要评测的运行时需要预装对应引擎。以 ONNX Runtime 和 llama.cpp 为例# 安装 ONNX RuntimeCPU 版示例 pip install onnxruntime # 安装 llama.cpp需要从源码编译这里只是示意编译选项 git clone https://github.com/ggerganov/llama.cpp cd llama.cpp mkdir build cd build cmake .. -DCMAKE_BUILD_TYPERelease cmake --build . --config Release -j硬件环境如果需要评测 NPU 或其他专用加速单元需要安装对应厂商的 SDK 和驱动。这一步通常是最容易出问题的环节不同版本的驱动对算子的支持差异很大。版本注意事项由于 Pipette 及相关依赖迭代较快本文不写死具体版本号。配置环境中遇到问题请以官方文档的版本说明和兼容性矩阵为准。4. 核心概念拆解评测维度的技术细节在跑评测之前需要理解每个评测维度的关键技术点。这样才能正确解读评测结果。4.1 端侧模型参数量不等于实际资源占用端侧模型的选择直接影响评测结果。同样推理一个 7B 模型如果硬件内存带宽不够即使算力达标也会因为带宽瓶颈而变慢。端侧场景常用的模型权衡标准包括参数量、激活值大小、序列长度、注意力机制类型。例如长文本场景下KV Cache 的内存占用会随序列长度线性增长这在小内存硬件上可能比模型本身更占资源。评测时如果只测固定长度输入可能会低估实际部署的内存压力。4.2 模型量化精度和性能的权衡工具量化是端侧部署的重要优化手段目的是降低模型体积和推理时的内存带宽压力。常见量化方案包括PTQ训练后量化训练完成后对权重和激活值进行量化无需重新训练。优点是成本低缺点是精度可能下降。QAT量化感知训练在训练过程中模拟量化效果让模型适应低比特表示。精度更高但需要训练资源和数据集。GPTQ、AWQ针对大模型的训练后量化方法通过优化量化误差来减少精度损失。GGUF 格式的量化等级llama.cpp 生态中的 Q4_K_M、Q5_K_S、Q8_0 等不同等级在精度和体积之间取不同平衡点。评测量化方案时需要同时关注两类指标一类是精度指标如困惑度PPL、任务准确率、输出相似度另一类是性能指标如模型体积、推理延迟、内存占用。只报精度不报性能或者只报速度不报精度都是不完整的。4.3 运行时同一模型不同框架表现差异巨大运行时Runtime是连接模型与硬件的中间层。不同类型的运行时侧重点不同ONNX Runtime跨平台支持好算子覆盖面广适合需要灵活切换硬件的场景。llama.cpp针对 LLM 推理做了深度优化支持 GGUF 格式量化在 CPU 和 Apple Silicon 上表现优秀。MNN阿里巴巴开源的轻量级推理引擎移动端优化好。TensorRTNVIDIA GPU 上的高性能推理引擎算子融合和精度校准能力强。TFLite/Core ML分别面向 Android 和 iOS 生态系统集成度高。运行时评测要特别注意算子支持边界。同一个模型在某个运行时中可以被 NPU 加速在另一个运行时中可能只能回退到 CPU。这种“隐性回退”往往不会报错但性能差异巨大是评测中需要重点关注的坑点。4.4 硬件算力、带宽、缓存三者缺一不可端侧硬件的评测维度不只是峰值算力更关键的是内存带宽和缓存层级。处理器理论算力再高如果内存带宽不足读取权重参数的时间会远大于计算时间形成带宽瓶颈。这在 LLM 推理中特别明显因为 LLM 是典型的 memory-bound 任务——每生成一个 token都需要把整个模型权重读取一遍。不同硬件的带宽差异很大。同一模型在同一量化格式下高频内存的旗舰手机 SoC 可能比低端嵌入式板卡快数倍这个差距主要来自内存带宽而不只是 CPU/GPU 频率。因此评测硬件时不能只看单一指标要同时关注延迟、吞吐、内存峰值、功耗和发热。4.5 关键评测指标定义评测指标要统一否则结果无法对比。核心指标包括延迟Latency从输入到输出第一个 token 的时间首 token 延迟和完整生成过程的时间。端侧更关注首 token 延迟因为用户感知最明显。吞吐Throughput单位时间内处理的 token 数tokens/s。批量场景下更关注服务端吞吐单设备端侧通常用单流吞吐。内存峰值Peak Memory推理过程中的最大内存占用包括模型权重、KV Cache、中间激活值。这个指标决定了模型能否在目标硬件上运行。精度指标任务专用指标如准确率、BLEU或通用指标如困惑度 PPL用于量化量化方案和运行时对模型输出质量的影响。功耗与温度端侧设备对功耗敏感评测时建议记录平均功耗、峰值功耗和温度变化。5. 实战搭建一个端侧评测流程接下来进入实操环节。由于 Pipette 项目的具体命令和配置文件可能随版本更新而调整下面我会给出评测流程的通用实现思路你可以结合 Pipette 官方文档进行适配。这套流程的核心思想是把评测分成准备、运行、采集、对比四步每一步都做严格记录。5.1 准备评测清单先定义一个评测清单文件记录本次评测的模型、量化、运行时和硬件信息。建议使用 JSON 或 YAML 格式便于后续自动解析和结果对比。# eval_config.yaml 示例 experiment: name: demo_eval model: name: Qwen2.5-1.5B-Instruct source: huggingface quantization: method: gptq bits: 4 runtime: engine: onnxruntime version: 1.17.0 hardware: device: RK3588 cpu: 4x Cortex-A76 4x Cortex-A55 memory: 8GB LPDDR4这个配置文件的核心作用是可以让另一个人拿到相同配置后在相同条件下复现你的结果。可复现的前提就是把每一项变量都记录清楚。5.2 导出与转换模型评测前需要把模型转换成目标运行时支持的格式。不同运行时需要的格式不同这一步通常是最耗时的。以 ONNX Runtime 为例# 示例将 HuggingFace 模型导出为 ONNX 格式 from transformers import AutoModelForCausalLM, AutoTokenizer import torch model_name Qwen2.5-1.5B-Instruct model AutoModelForCausalLM.from_pretrained(model_name, torch_dtypetorch.float16) tokenizer AutoTokenizer.from_pretrained(model_name) dummy_input tokenizer(Hello, return_tensorspt) torch.onnx.export( model, (dummy_input[input_ids],), model.onnx, opset_version17, input_names[input_ids], output_names[logits], dynamic_axes{input_ids: {0: batch, 1: seq}}, ) print(导出完成)这里需要注意动态轴dynamic_axes对于端侧部署非常重要。固定序列长度的模型无法处理变长输入在真实场景中会很受限。但动态轴也意味着运行时需要额外的内存分配逻辑可能影响性能。评测时应该分别测试固定长度和动态长度场景。5.3 执行推理并采集性能数据推理执行的代码要尽量干净排除无关干扰。核心思路是先 warmup再正式测试取多次测试的中位数而非平均值以排除偶然波动。# 示例使用 ONNX Runtime 执行推理并测延迟 import onnxruntime as ort import numpy as np import time sess ort.InferenceSession(model.onnx, providers[CPUExecutionProvider]) input_ids np.random.randint(0, 10000, (1, 128), dtypenp.int64) inputs {input_ids: input_ids} # Warmup for _ in range(5): sess.run(None, inputs) # 正式测试 latencies [] for _ in range(50): start time.perf_counter() sess.run(None, inputs) end time.perf_counter() latencies.append((end - start) * 1000) latencies.sort() median_latency latencies[len(latencies) // 2] print(fMedian latency: {median_latency:.2f} ms)注意这里统计的是单次推理的端到端延迟。如果你想统计“首 token 延迟”和“生成速度”需要使用流式解码接口逐 token 计时逻辑会复杂一些。5.4 采集精度指标性能数据之外还需要采集精度数据。以量化前后的困惑度对比为例# 示例使用 lm-evaluation-harness 风格评估困惑度 # 这里仅示意核心逻辑 from transformers import AutoModelForCausalLM, AutoTokenizer import torch def compute_ppl(model, tokenizer, texts): total_nll 0.0 total_tokens 0 for text in texts: inputs tokenizer(text, return_tensorspt, max_length512, truncationTrue) with torch.no_grad(): outputs model(**inputs, labelsinputs[input_ids]) loss outputs.loss total_nll loss.item() * inputs[input_ids].size(1) total_tokens inputs[input_ids].size(1) return torch.exp(torch.tensor(total_nll / total_tokens)).item()精度评测需要固定数据集跨实验之间不能更换测试集否则结果不可比。这也是 Pipette 强调可复现的原因之一。5.5 结果汇总与对比评测完成后推荐将结果汇总成一张对比表。建议格式如下方案量化方式运行时延迟(ms)吞吐(tokens/s)峰值内存(MB)PPLA无(FP16)ONNX Runtime851232008.1BW8A8ONNX Runtime422417008.4CW4A16ONNX Runtime31329008.9DW4A16llama.cpp27388508.8这张表格能让决策者直接看到相同硬件和模型下量化带来的性能收益和精度损失到底是多少相同量化下不同运行时之间的差距有多大。6. 常见问题与排查思路在实际评测过程中会遇到各种问题。下面整理一些高频场景和排查方法。问题现象常见原因解决思路模型在不同的运行时下输出差异较大量化方法对算子敏感运行时存在未实现的算子导致回退检查回退日志尝试更新运行时版本对比中间层输出量化后延迟没有明显下降权重已经很小但内存带宽仍受限激活值未量化算子未融合使用性能分析工具如 perf、Tracy定位瓶颈开启内存带宽监控运行时报错“找不到算子”模型包含运行时暂不支持的算子确认算子版本考虑更换运行时或调整模型结构同一硬件多次评测延迟波动大系统调度、温度降频、后台进程干扰固定 CPU 频率关闭后台进程多次取中位数内存直接溢出模型权重KV Cache激活值超出硬件内存减小批量大小降低序列长度换更低比特量化精度指标下降过多量化方案不适合当前模型/数据集尝试混合精度、QAT、或更高比特量化如 W8A16某些硬件上 NPU 推理比 CPU 还慢模型太小、算子未在 NPU 上完整实现调度开销大于计算收益尝试更大的模型检查 NPU 算子支持率评估任务是否适合 NPU排查时建议遵循“先定位、再修复”的原则先确认问题是出在模型层、运行时层还是硬件层再针对性调整。不要一上来就换方案否则每次都在盲调。7. 最佳实践与工程建议结合端侧部署的工程经验这里给出几条比较实用的评测规范建议。7.1 环境锁定与依赖冻结评测环境必须“锁定”。建议使用 Docker 容器或独立的 conda 环境并导出完整的依赖清单pip freeze requirements_lock.txt同一个评测结果必须能对应到一份明确的依赖版本记录。否则三个月后你很难回答“这个结果是用哪个版本跑出来的”这个问题。7.2 建立统一的评测数据集精度评测的数据集要提前固定。建议包含三类数据标准公开数据集如 WikiText 用于 PPL 评测、领域专用数据、真实业务脱敏数据。每类数据都要明确切分方式禁止在评测过程中动态修改数据集。7.3 控制变量法与重复实验每次只改变一个维度。比如评估量化方案时固定模型版本、运行时版本、硬件设备、线程数、批量大小评估硬件时固定其他所有参数只换硬件。每组实验至少重复 3 次取中位数或平均值。如果两次实验之间结果差异超过 10%需要排查环境因素而不是直接采信。7.4 关注端到端链路而非单点指标不要只看模型推理延迟。端侧应用是完整链路输入预处理、模型推理、后处理、渲染每一环都可能成为瓶颈。Pipette 的定位是评测推理环节但你在做最终方案选型时要有整链路视角。7.5 安全与合规提醒在评测和部署过程中需要注意使用模型和数据集时确认许可证和合规要求涉及生产环境变量调整时先在测试环境验证保留回滚方案涉及账号、权限、日志时遵循最小权限原则不评测、不部署来源不明的“精调”模型防止供应链风险。8. 从评测到选型一套可迁移的决策框架有了 Pipette 这个评测框架之后你得到的不是一张“谁快谁慢”的排名表而是一套可迁移的决策框架。这里分享一个比较通用的选型思路先明确业务约束再反推评测重点。如果业务对首 token 延迟敏感比如交互式对话就给延迟指标更高权重如果业务运行在 8GB 内存设备上就把峰值内存设为一票否决指标如果业务对输出质量要求很高就要在量化精度和速度之间谨慎权衡。评测的目的不是寻找“最好”的配置而是寻找“在约束条件下最合适”的配置。这也是我认为 Pipette 这类工具最大的价值它不会替你做决策但它帮你把决策需要的数据以可复现、可对比的方式呈现在你面前。如果你正在做端侧模型选型或推理框架调研不妨从一个小实验开始固定一个模型准备两到三种量化方案在两套硬件上跑一轮延迟和精度对比。拿到结果之后你会发现之前很多“据说”的经验在自己环境里可能完全不成立。动手跑一轮永远比看十篇评测文章更有参考价值。 Pipette：端侧模型评测基准套件，量化与硬件耦合下的可复现方案
模型端侧部署最头疼的是什么不是模型本身效果不好而是“换一块硬件、换一个推理框架、换一种量化方式结果就完全不一样”。同一个 2B 模型在 A 手机芯片上跑 30ms到了 B 边缘设备上可能变成 120ms精度还会掉一截。更麻烦的是团队里每个人用的评估口径还不一样有人看首 token 延迟有人看峰值内存有人只看量化后的困惑度最后得出的结论很难横向对比。Liquid AI 开源的 Pipette正是为了解决这个“评测碎片化”问题而设计的一套可复现基准套件。它把端侧模型、量化方案、运行时、硬件四个关键变量放到同一个评测框架里让开发者可以在统一口径下做对比实验。本文会用工程视角拆解 Pipette 的设计思路、核心概念、评测维度以及如何把它接入自己的端侧模型评测流程中。如果你是做端侧 AI 应用、模型部署、推理框架选型或者正在为量化方案纠结这篇文章会比较适合你。1. 为什么端侧评测这么难四个变量互相影响在深入 Pipette 之前先理解它要解决的核心问题——端侧推理评测为什么比服务端评测复杂得多。服务端的评测相对简单GPU 型号固定、CUDA 版本固定、批量大小可调跑一个 benchmark 脚本就能得到比较稳定的吞吐数据。但到了端侧场景变量一下子增加了第一个变量是模型本身。同样是 7B 参数稠密模型和 MoE 模型在不同硬件上的表现差异巨大同样是 2B 模型不同网络结构对算力、带宽的敏感度完全不同。第二个变量是量化方案。W8A8 量化、W4A16 量化、GPTQ、AWQ、GGUF 的 Q4_K_M每种量化方法对精度的影响不同对硬件的适配程度也不同。有些量化格式在 GPU 上表现很好拿到端侧 NPU 上反而因为算子不支持而降级成 CPU 推理。第三个变量是运行时。同一个模型可以用 ONNX Runtime、TensorRT、llama.cpp、MNN、TFLite、Core ML 等多个框架加载。不同运行时对算子融合、内存复用、多线程调度的策略差异很大直接决定推理效率。第四个变量是硬件。手机 SoC、嵌入式开发板、边缘盒子、笔记本 CPU它们的算力、内存带宽、缓存大小、NPU 架构都不同。同一份量化模型在不同硬件上的表现可能完全不在一个量级。关键在于这四个变量不是独立的而是互相耦合。量化方式会影响运行时的算子选择运行时又决定硬件算力的利用率硬件反过来又限制量化格式的支持范围。单独测某一个变量得出的结论是片面的。Pipette 的思路是把这四个变量放到一个可组合的评测框架里通过固定其他变量、改变目标变量的方式给出可横向对比的结果。2. Pipette 项目定位与核心设计2.1 Pipette 是什么Pipette 是 Liquid AI 开源的一套端侧模型评测框基准套件。它专注于端侧模型、量化、运行时、硬件这四个维度的交叉评测强调“可复现”和“标准化”。“可复现”是 Pipette 最核心的追求。端侧评测场景中很多实验都是“跑完就没了”环境变了、依赖版本变了、硬件调度策略变了结果就对不上了。Pipette 通过统一评测流程、统一指标采集、统一环境描述让同一个评测任务在不同时间、不同机器上尽量得到一致的结果。2.2 评测对象与热词中“量化”的区别这里需要先澄清一个容易混淆的概念。在端侧 AI 领域“量化”指的是模型量化Model Quantization即把神经网络中的浮点参数和激活值用较低比特数表示以减少内存占用、加速计算是端侧部署的关键技术。它跟金融领域的“量化交易”是两个完全不同的概念本文讨论的全部是模型量化相关的内容。模型量化的核心权衡是精度损失 vs 性能收益。Pipette 的评测目标之一就是让这种权衡变得可度量、可比较。2.3 核心设计理念四维矩阵式评测Pipette 的评测思路可以这样理解它定义了一个四维矩阵每个维度内可以配置不同的选项。评测维度可配置选项示例评测关注点模型不同参数量、不同架构Dense/MoE、不同任务类型推理质量、资源占用量化FP16/BF16、W8A8、W4A16、GPTQ、AWQ、GGUF 等精度损失、显存/内存节省、推理加速比运行时ONNX Runtime、llama.cpp、MNN、TensorRT、TFLite算子兼容性、延迟、吞吐硬件手机 SoC、ARM 开发板、x86 边缘设备、NPU算力利用率、功耗、发热实际评测时通常采用控制变量法固定三个维度改变一个维度观察指标变化。例如固定模型、量化方案、运行时切换不同硬件评估硬件对延迟的影响固定模型、硬件、运行时切换不同量化方案评估量化对精度和速度的影响固定模型、量化方案、硬件切换不同运行时评估框架的优化水平。这种矩阵式的评测方式比单独跑一两个 benchmark 脚本更能反映生产环境的真实情况。3. 环境准备与版本注意事项在开始使用 Pipette 之前需要明确一点由于端侧评测涉及多个不同生态的组件环境差异会导致结果偏差所以环境标准化本身就是评测的一部分。一般建议从以下几方面做准备操作系统Linux 和 macOS 是端侧评测最常用的系统。Windows 在部分工具链上兼容性不佳但通过 WSL2 也能运行部分评测。需要根据你实际的目标部署环境来选择。Python 环境建议使用 Python 3.9 或 3.10 版本。评测框架的依赖库如 PyTorch、ONNX、numpy在不同版本下行为有差异。推荐使用虚拟环境或 conda 管理依赖避免污染系统环境。推理引擎根据你要评测的运行时需要预装对应引擎。以 ONNX Runtime 和 llama.cpp 为例# 安装 ONNX RuntimeCPU 版示例 pip install onnxruntime # 安装 llama.cpp需要从源码编译这里只是示意编译选项 git clone https://github.com/ggerganov/llama.cpp cd llama.cpp mkdir build cd build cmake .. -DCMAKE_BUILD_TYPERelease cmake --build . --config Release -j硬件环境如果需要评测 NPU 或其他专用加速单元需要安装对应厂商的 SDK 和驱动。这一步通常是最容易出问题的环节不同版本的驱动对算子的支持差异很大。版本注意事项由于 Pipette 及相关依赖迭代较快本文不写死具体版本号。配置环境中遇到问题请以官方文档的版本说明和兼容性矩阵为准。4. 核心概念拆解评测维度的技术细节在跑评测之前需要理解每个评测维度的关键技术点。这样才能正确解读评测结果。4.1 端侧模型参数量不等于实际资源占用端侧模型的选择直接影响评测结果。同样推理一个 7B 模型如果硬件内存带宽不够即使算力达标也会因为带宽瓶颈而变慢。端侧场景常用的模型权衡标准包括参数量、激活值大小、序列长度、注意力机制类型。例如长文本场景下KV Cache 的内存占用会随序列长度线性增长这在小内存硬件上可能比模型本身更占资源。评测时如果只测固定长度输入可能会低估实际部署的内存压力。4.2 模型量化精度和性能的权衡工具量化是端侧部署的重要优化手段目的是降低模型体积和推理时的内存带宽压力。常见量化方案包括PTQ训练后量化训练完成后对权重和激活值进行量化无需重新训练。优点是成本低缺点是精度可能下降。QAT量化感知训练在训练过程中模拟量化效果让模型适应低比特表示。精度更高但需要训练资源和数据集。GPTQ、AWQ针对大模型的训练后量化方法通过优化量化误差来减少精度损失。GGUF 格式的量化等级llama.cpp 生态中的 Q4_K_M、Q5_K_S、Q8_0 等不同等级在精度和体积之间取不同平衡点。评测量化方案时需要同时关注两类指标一类是精度指标如困惑度PPL、任务准确率、输出相似度另一类是性能指标如模型体积、推理延迟、内存占用。只报精度不报性能或者只报速度不报精度都是不完整的。4.3 运行时同一模型不同框架表现差异巨大运行时Runtime是连接模型与硬件的中间层。不同类型的运行时侧重点不同ONNX Runtime跨平台支持好算子覆盖面广适合需要灵活切换硬件的场景。llama.cpp针对 LLM 推理做了深度优化支持 GGUF 格式量化在 CPU 和 Apple Silicon 上表现优秀。MNN阿里巴巴开源的轻量级推理引擎移动端优化好。TensorRTNVIDIA GPU 上的高性能推理引擎算子融合和精度校准能力强。TFLite/Core ML分别面向 Android 和 iOS 生态系统集成度高。运行时评测要特别注意算子支持边界。同一个模型在某个运行时中可以被 NPU 加速在另一个运行时中可能只能回退到 CPU。这种“隐性回退”往往不会报错但性能差异巨大是评测中需要重点关注的坑点。4.4 硬件算力、带宽、缓存三者缺一不可端侧硬件的评测维度不只是峰值算力更关键的是内存带宽和缓存层级。处理器理论算力再高如果内存带宽不足读取权重参数的时间会远大于计算时间形成带宽瓶颈。这在 LLM 推理中特别明显因为 LLM 是典型的 memory-bound 任务——每生成一个 token都需要把整个模型权重读取一遍。不同硬件的带宽差异很大。同一模型在同一量化格式下高频内存的旗舰手机 SoC 可能比低端嵌入式板卡快数倍这个差距主要来自内存带宽而不只是 CPU/GPU 频率。因此评测硬件时不能只看单一指标要同时关注延迟、吞吐、内存峰值、功耗和发热。4.5 关键评测指标定义评测指标要统一否则结果无法对比。核心指标包括延迟Latency从输入到输出第一个 token 的时间首 token 延迟和完整生成过程的时间。端侧更关注首 token 延迟因为用户感知最明显。吞吐Throughput单位时间内处理的 token 数tokens/s。批量场景下更关注服务端吞吐单设备端侧通常用单流吞吐。内存峰值Peak Memory推理过程中的最大内存占用包括模型权重、KV Cache、中间激活值。这个指标决定了模型能否在目标硬件上运行。精度指标任务专用指标如准确率、BLEU或通用指标如困惑度 PPL用于量化量化方案和运行时对模型输出质量的影响。功耗与温度端侧设备对功耗敏感评测时建议记录平均功耗、峰值功耗和温度变化。5. 实战搭建一个端侧评测流程接下来进入实操环节。由于 Pipette 项目的具体命令和配置文件可能随版本更新而调整下面我会给出评测流程的通用实现思路你可以结合 Pipette 官方文档进行适配。这套流程的核心思想是把评测分成准备、运行、采集、对比四步每一步都做严格记录。5.1 准备评测清单先定义一个评测清单文件记录本次评测的模型、量化、运行时和硬件信息。建议使用 JSON 或 YAML 格式便于后续自动解析和结果对比。# eval_config.yaml 示例 experiment: name: demo_eval model: name: Qwen2.5-1.5B-Instruct source: huggingface quantization: method: gptq bits: 4 runtime: engine: onnxruntime version: 1.17.0 hardware: device: RK3588 cpu: 4x Cortex-A76 4x Cortex-A55 memory: 8GB LPDDR4这个配置文件的核心作用是可以让另一个人拿到相同配置后在相同条件下复现你的结果。可复现的前提就是把每一项变量都记录清楚。5.2 导出与转换模型评测前需要把模型转换成目标运行时支持的格式。不同运行时需要的格式不同这一步通常是最耗时的。以 ONNX Runtime 为例# 示例将 HuggingFace 模型导出为 ONNX 格式 from transformers import AutoModelForCausalLM, AutoTokenizer import torch model_name Qwen2.5-1.5B-Instruct model AutoModelForCausalLM.from_pretrained(model_name, torch_dtypetorch.float16) tokenizer AutoTokenizer.from_pretrained(model_name) dummy_input tokenizer(Hello, return_tensorspt) torch.onnx.export( model, (dummy_input[input_ids],), model.onnx, opset_version17, input_names[input_ids], output_names[logits], dynamic_axes{input_ids: {0: batch, 1: seq}}, ) print(导出完成)这里需要注意动态轴dynamic_axes对于端侧部署非常重要。固定序列长度的模型无法处理变长输入在真实场景中会很受限。但动态轴也意味着运行时需要额外的内存分配逻辑可能影响性能。评测时应该分别测试固定长度和动态长度场景。5.3 执行推理并采集性能数据推理执行的代码要尽量干净排除无关干扰。核心思路是先 warmup再正式测试取多次测试的中位数而非平均值以排除偶然波动。# 示例使用 ONNX Runtime 执行推理并测延迟 import onnxruntime as ort import numpy as np import time sess ort.InferenceSession(model.onnx, providers[CPUExecutionProvider]) input_ids np.random.randint(0, 10000, (1, 128), dtypenp.int64) inputs {input_ids: input_ids} # Warmup for _ in range(5): sess.run(None, inputs) # 正式测试 latencies [] for _ in range(50): start time.perf_counter() sess.run(None, inputs) end time.perf_counter() latencies.append((end - start) * 1000) latencies.sort() median_latency latencies[len(latencies) // 2] print(fMedian latency: {median_latency:.2f} ms)注意这里统计的是单次推理的端到端延迟。如果你想统计“首 token 延迟”和“生成速度”需要使用流式解码接口逐 token 计时逻辑会复杂一些。5.4 采集精度指标性能数据之外还需要采集精度数据。以量化前后的困惑度对比为例# 示例使用 lm-evaluation-harness 风格评估困惑度 # 这里仅示意核心逻辑 from transformers import AutoModelForCausalLM, AutoTokenizer import torch def compute_ppl(model, tokenizer, texts): total_nll 0.0 total_tokens 0 for text in texts: inputs tokenizer(text, return_tensorspt, max_length512, truncationTrue) with torch.no_grad(): outputs model(**inputs, labelsinputs[input_ids]) loss outputs.loss total_nll loss.item() * inputs[input_ids].size(1) total_tokens inputs[input_ids].size(1) return torch.exp(torch.tensor(total_nll / total_tokens)).item()精度评测需要固定数据集跨实验之间不能更换测试集否则结果不可比。这也是 Pipette 强调可复现的原因之一。5.5 结果汇总与对比评测完成后推荐将结果汇总成一张对比表。建议格式如下方案量化方式运行时延迟(ms)吞吐(tokens/s)峰值内存(MB)PPLA无(FP16)ONNX Runtime851232008.1BW8A8ONNX Runtime422417008.4CW4A16ONNX Runtime31329008.9DW4A16llama.cpp27388508.8这张表格能让决策者直接看到相同硬件和模型下量化带来的性能收益和精度损失到底是多少相同量化下不同运行时之间的差距有多大。6. 常见问题与排查思路在实际评测过程中会遇到各种问题。下面整理一些高频场景和排查方法。问题现象常见原因解决思路模型在不同的运行时下输出差异较大量化方法对算子敏感运行时存在未实现的算子导致回退检查回退日志尝试更新运行时版本对比中间层输出量化后延迟没有明显下降权重已经很小但内存带宽仍受限激活值未量化算子未融合使用性能分析工具如 perf、Tracy定位瓶颈开启内存带宽监控运行时报错“找不到算子”模型包含运行时暂不支持的算子确认算子版本考虑更换运行时或调整模型结构同一硬件多次评测延迟波动大系统调度、温度降频、后台进程干扰固定 CPU 频率关闭后台进程多次取中位数内存直接溢出模型权重KV Cache激活值超出硬件内存减小批量大小降低序列长度换更低比特量化精度指标下降过多量化方案不适合当前模型/数据集尝试混合精度、QAT、或更高比特量化如 W8A16某些硬件上 NPU 推理比 CPU 还慢模型太小、算子未在 NPU 上完整实现调度开销大于计算收益尝试更大的模型检查 NPU 算子支持率评估任务是否适合 NPU排查时建议遵循“先定位、再修复”的原则先确认问题是出在模型层、运行时层还是硬件层再针对性调整。不要一上来就换方案否则每次都在盲调。7. 最佳实践与工程建议结合端侧部署的工程经验这里给出几条比较实用的评测规范建议。7.1 环境锁定与依赖冻结评测环境必须“锁定”。建议使用 Docker 容器或独立的 conda 环境并导出完整的依赖清单pip freeze requirements_lock.txt同一个评测结果必须能对应到一份明确的依赖版本记录。否则三个月后你很难回答“这个结果是用哪个版本跑出来的”这个问题。7.2 建立统一的评测数据集精度评测的数据集要提前固定。建议包含三类数据标准公开数据集如 WikiText 用于 PPL 评测、领域专用数据、真实业务脱敏数据。每类数据都要明确切分方式禁止在评测过程中动态修改数据集。7.3 控制变量法与重复实验每次只改变一个维度。比如评估量化方案时固定模型版本、运行时版本、硬件设备、线程数、批量大小评估硬件时固定其他所有参数只换硬件。每组实验至少重复 3 次取中位数或平均值。如果两次实验之间结果差异超过 10%需要排查环境因素而不是直接采信。7.4 关注端到端链路而非单点指标不要只看模型推理延迟。端侧应用是完整链路输入预处理、模型推理、后处理、渲染每一环都可能成为瓶颈。Pipette 的定位是评测推理环节但你在做最终方案选型时要有整链路视角。7.5 安全与合规提醒在评测和部署过程中需要注意使用模型和数据集时确认许可证和合规要求涉及生产环境变量调整时先在测试环境验证保留回滚方案涉及账号、权限、日志时遵循最小权限原则不评测、不部署来源不明的“精调”模型防止供应链风险。8. 从评测到选型一套可迁移的决策框架有了 Pipette 这个评测框架之后你得到的不是一张“谁快谁慢”的排名表而是一套可迁移的决策框架。这里分享一个比较通用的选型思路先明确业务约束再反推评测重点。如果业务对首 token 延迟敏感比如交互式对话就给延迟指标更高权重如果业务运行在 8GB 内存设备上就把峰值内存设为一票否决指标如果业务对输出质量要求很高就要在量化精度和速度之间谨慎权衡。评测的目的不是寻找“最好”的配置而是寻找“在约束条件下最合适”的配置。这也是我认为 Pipette 这类工具最大的价值它不会替你做决策但它帮你把决策需要的数据以可复现、可对比的方式呈现在你面前。如果你正在做端侧模型选型或推理框架调研不妨从一个小实验开始固定一个模型准备两到三种量化方案在两套硬件上跑一轮延迟和精度对比。拿到结果之后你会发现之前很多“据说”的经验在自己环境里可能完全不成立。动手跑一轮永远比看十篇评测文章更有参考价值。