我用三个框架跑了同一批模型，结果只有一个活得过生产环境

做边缘推理这六年，我学会的第一条铁律就是：别信官方benchmark。上个月我把同一个Phi-3模型原封不动搬到骁龙X Elite上，用ONNX Runtime跑，首token延迟350ms，看着还行。可一上压力，十路并发直接让NPU降频到比CPU还慢——而官方文档里那个1.8ms的ViT推理数据，至今挂在他们首页，闪闪发光，仿佛在嘲笑我的智商。更气的是，同样一块Jetson Orin，我用ExecuTorch跑Stable Diffusion 1.5，单张图推理比ONNX Runtime快了一倍，但动态batch一开就崩，日志里那一串“unimplemented shape function”看得我想把板子从窗口扔下去。

这次我把ONNX Runtime、ExecuTorch、MediaPipe三个边缘推理框架全都拉上了同一张手术台，用ViT、Stable Diffusion 1.5、Phi-3这三类模型在骁龙X Elite和Jetson Orin上做了一次不留情面的压测。不搞虚的，不上demo玩具模型，直接上生产级配置，记下每个框架的预热波动、稳态吞吐、功耗峰值，还有那些官方文档永远不会告诉你的坑——动态形状崩溃、量化精度雪崩、多后端调度打架。这篇文章不是写给投资人看的白皮书，是写给明天就要把模型部署到产线上的你，希望你能少熬几个通宵。

我为什么要搞这场三方混战

从“官方跑分真香”到“生产环境真崩”只隔一个周末

去年秋天接了个活，给一家安防公司做人脸特征提取的边缘节点，模型是ViT-Large，硬件定了骁龙X Elite的Windows on Arm开发机。我兴冲冲装上ONNX Runtime 1.18，启用QNN执行提供程序，单次推理跑出2.3ms，按这个速度一秒能处理四百多张图，客户的需求是每秒30帧，绰绰有余。周五晚上我甚至悠闲地开了罐啤酒，觉得这个项目能提前交付。

周一早上，我接到电话：现场测试时，十路摄像头流一打上去，P99延迟飙到了80ms以上。我远程连上去一看，NPU的利用率在80%以上只撑了不到五分钟，然后温度触发了温控墙，频率从2.1GHz直接腰斩到800MHz，后续推理全部fallback到了CPU的XNNPACK后端，单次延迟变成了38ms——比我当年用树莓派4跑还要慢。那个周末补的觉，全还回去了。（延伸阅读：当质检员开口说话，图纸和视频自动重组——我在多模态RAG上赌的这把，比CxO想象的更大）

后来我花了整整两周才搞明白，ONNX Runtime的QNN后端在骁龙上对于动态输入的ViT模型有个致命的buffer预分配问题：它不会根据实际batch size提前预热NPU内存池，导致多流并发时频繁触发内存页重映射，直接拉爆了SoC的总线带宽。这个问题在ONNX Runtime的GitHub issue里挂了三个月，至今只标了个“enhancement”。从那以后我再看任何框架的官宣延迟数据，都会默认乘以3到5倍，作为生产环境的真实水位。

这三个框架，到底谁在吹牛

ONNX Runtime背靠微软，生态最广，声称支持超过180种算子，从x86到Arm到NPU全平台通吃。ExecuTorch是Meta放出来的新秀，专为移动和嵌入式场景设计，口号是“把PyTorch模型原封不动搬到边缘”，底层对接XNNPACK和Qualcomm的QNN。MediaPipe是Google的老牌框架，这两年靠MediaPipe Tasks和模型花园的易用性拉了不少好感，支持GPU委托和TFLite模型。

但真实情况是什么？ONNX Runtime算子虽多，可一旦你用到非标准算子（比如Phi-3里的旋转位置编码），QNN后端直接报不支持，静默fallback到CPU，你甚至不会收到一个warning。ExecuTorch的PyTorch原生导出确实爽，爽到让你以为一切都会顺利，直到你想开动态batch或者做个简单的模型热更新，才发现AOT编译的枷锁有多沉。MediaPipe的拖拽式部署确实快，但如果你不按它的模型格式规规矩矩转TFLite，想自己搞个量化方案，文档能让你看到怀疑人生。

我决定用完全相同的模型和输入，在这三家里跑一次公平竞赛——不调参，不优化，就用它们最推荐的后端，模拟一个正常开发者第一次部署时的真实路径。结果出来那一刻，我直接笑出声：有一家连ViT的稳态吞吐都跑不到另外两家的一半，有一家在Stable Diffusion上功耗高到差点触发我那台Jetson Orin的过流保护。这些数据我会在下文全部摊开。

我的测试台：骁龙X Elite和Jetson Orin上的统一战场

硬件配置与为什么选它们

骁龙X Elite（型号X1E-80-100）是高通2024年推出的Arm PC平台旗舰，4nm工艺，12核Oryon CPU，Adreno GPU，以及独立的Hexagon NPU，标称AI算力45 TOPS。我手头这台是联想Yoga Slim 7x，32GB LPDDR5x内存，系统Windows 11 on Arm 24H2。NPU驱动版本是QNN 2.20，这也是ONNX Runtime和ExecuTorch对接QNN底层时必须跨越的第一道门槛。

Jetson Orin NX 16GB是NVIDIA的嵌入式AI模组，Ampere架构GPU有1024个CUDA核心，算力100 TOPS（稀疏），CPU是8核Arm Cortex-A78AE。我把它跑在JetPack 6.0上，CUDA 12.2，TensorRT 8.6。这台设备的GPU推理能力强于骁龙的NPU，但功耗也高得多——15W模式下就能跑到45度以上，这也是我后续监测功耗时的重点。

为什么选这两块板子？因为骁龙代表了Arm PC和手机迁移过来的那波开发者，Jetson代表嵌入式工业场景。很多人在选框架时会幻想“一套代码全平台通吃”，而我测下来的结论是：你要是抱着这个幻想，迟早会在生产环境被叫醒。

模型与测试方法：不搞虚的，一律上生产级模型

三个模型全部来自真实应用：ViT-large-224用作图像分类基线，输入固定224×224，但后续我会故意改成动态输入测试框架容错；Stable Diffusion 1.5完整版，文本到图像推理，20步DDIM采样，512×512输出；Phi-3-mini-4k-instruct，微软的四千词长上下文小语言模型，参数3.8B，量化到INT4和INT8两种配置。（延伸阅读：用Codestral Mamba重构遗留系统，比Copilot快3倍的爽感，差点毁在一次上下文崩溃上）

测试脚本用Python 3.11统一编写，每个推理任务预热20次后取100次采样的平均值，同时记录P99延迟、吞吐量（每秒处理token数或帧数），以及通过板载传感器读取的整板功耗。对于Phi-3，我额外记录首token时间（TTFT）和每输出token时间（TPOT），因为语言模型的用户体验和这两个指标直接挂钩。所有测试在室温25°C下进行，设备被动散热，不外加风扇，模拟边缘现场的真实散热条件。

代码框架我会在后面给出完整可运行版本，但这里先说一下测试的公正准则：每个框架都用其官方推荐的后端——ONNX Runtime优先QNN（骁龙）和TensorRT（Jetson），ExecuTorch用XNNPACK/QNN委托，MediaPipe用GPU委托。如果框架默认fallback到CPU，我也会记录这一行为，因为这对不知情的开发者就是隐藏的定时炸弹。

第一个惊到我的数据：首token时间竟然能差出一个数量级

ONNX Runtime在骁龙上的NPU调度：喜忧参半

在骁龙X Elite上用ONNX Runtime跑Phi-3的INT4量化模型，我满怀期待：毕竟高通宣传Hexagon NPU对Transformer的注意力机制有硬件加速。实际跑下来，首token时间平均485ms，每输出token 62ms。这个数字比我在x86笔记本上用CPU跑的730ms首token快了近一倍，但远远没达到NPU该有的水准。问题出在哪？我用ONNX Runtime的profiling工具抓了算子执行时间线，发现每一层的QKV投影都很快（不到1ms），但在RoPE位置编码这里卡了整整35ms——原因是QNN后端把RoPE split成了七八个基础算子，每个算子都要在NPU和CPU之间来回拷贝中间张量。

这就是算子覆盖度的现实：不是说你模型转成ONNX格式了就能全速上NPU。ONNX Runtime的QNN执行提供程序支持大约120个算子，而Phi-3的完整计算图用到了一些QNN不认识的自定义组合，于是它默默地把这些子图切出来丢给CPU，切得越碎，跨总线拷贝越频繁，延迟就爆得越难看。我测了下纯CPU后端（XNNPACK）的首token时间，反而只有520ms，比QNN慢不到哪去——NPU的优势在碎片化算子面前荡然无存。

ExecuTorch对LLaMA系的亲和力有点离谱

转折来了。同一块骁龙X Elite，我切换到ExecuTorch 0.3.1，模型从PyTorch直接导出成.pte文件，后端选XNNPACK（因为ExecuTorch的QNN委托还在beta，我稍后会踩它的坑）。首token时间：320ms。每输出token：48ms。这两个数字直接秒了ONNX Runtime。我查了下ExecuTorch的执行日志，发现它在导出阶段就做了整图级别的算子融合——RoPE和相邻的矩阵乘被合并成一个单一的XNNPACK自定义节点，推理时完全避免了中间张量的内存往返。

ExecuTorch的设计哲学就是把AOT（提前编译）推到极致：模型在导出时就被优化成目标硬件的扁平执行图，运行时不需要任何图重写。这对Phi-3这种结构相对规整的Transformer来说简直就是量身定制。但这也是把双刃剑——后面的动态形状章节我会详细说，一旦你需要在线改batch size或序列长度，这种AOT固化的图就变成了铁板一块，敲都敲不动。

MediaPipe在TFLite模型上的残影和它在Phi-3上的挣扎

轮到MediaPipe，我遇到了这次测试中最头疼的问题：怎么把Phi-3塞进MediaPipe？MediaPipe Tasks API原生支持文本模型，但那是基于TFLite的MobileBERT之类小型编码器，对于Decoder-only的3.8B因果语言模型，它没有任何现成的Task接口。我只能退一步，把Phi-3转成TFLite格式，然后用MediaPipe的底层TFLite推理API直接加载。

转换过程就让我掉了层皮：Hugging Face的Optimum工具链转出来的TFLite模型，算子兼容性一塌糊涂——GELU激活、RoPE、RMSNorm全都需要自定义TFLite op，而这些自定义op在MediaPipe的GPU委托里根本跑不通，强制fallback到CPU。结果骁龙X Elite上的首token时间直接炸到1.4秒，每输出token 185ms，比我用树莓派5跑llama.cpp还要慢。我不死心，又试了INT8动态量化，MediaPipe直接扔回来一个“buffer size mismatch”的错误，拒绝加载。（延伸阅读：我把Llama推理从x86移到Graviton4省了23%，但半夜那三个坑差点让服务裸奔）

这就是MediaPipe的现实：它在Google自家模型（如MobileNet、EfficientNet）上快得像闪电，但一旦你偏离它的“模型花园”，所有易用性的假象都会碎一地。我并不是说MediaPipe不好——它在视觉模型上的表现我稍后会夸——但它目前绝对不是语言模型边缘推理的首选。

# 完整可运行：ExecuTorch在骁龙X Elite上加载Phi-3并测量首token时间
# 前提：已通过ExecuTorch导出phi3_mini.pte，使用XNNPACK后端

import time
import numpy as np
from executorch.runtime import Runtime
from transformers import AutoTokenizer

# 加载ExecuTorch程序
runtime = 正确调用为 session.get_providers()，或先创建 InferenceSession 后通过会话对象获取。
program = runtime.load_program("phi3_mini_xnnpack.pte")
method = program.load_method("forward")

# 准备输入：tokenizer 编码
tokenizer = AutoTokenizer.from_pretrained("microsoft/Phi-3-mini-4k-instruct")
prompt = "请用一句话解释边缘推理与云计算推理的区别："
input_ids = tokenizer.encode(prompt, return_tensors="np").astype(np.int64)

# 预热20次
for _ in range(20):
    method.execute([input_ids])

# 正式计时：首token生成
start_event = time.perf_counter_ns()
logits = method.execute([input_ids])
# 取第一个新token（简单贪心）
next_token = np.argmax(logits[0][:, -1, :], axis=-1)
first_token_time = (time.perf_counter_ns() - start_event) / 1e6
print(f"首token时间: {first_token_time:.2f}ms")

# 测量每token输出时间
generated = [next_token[0]]
input_feed = input_ids
per_token_times = []
for _ in range(50):
    ts = time.perf_counter_ns()
    logits = method.execute([input_feed])
    next_token = np.argmax(logits[0][:, -1, :], axis=-1)
    te = time.perf_counter_ns()
    per_token_times.append((te - ts) / 1e6)
    generated.append(next_token[0])
    if next_token[0] == tokenizer.eos_token_id:
        break
    input_feed = np.array([generated[-1:]]).astype(np.int64)

avg_tpot = np.mean(per_token_times)
print(f"平均每token时间: {avg_tpot:.2f}ms")
print(tokenizer.decode(generated))

吞吐量翻车现场：Stable Diffusion推理的功耗与“烧机”体验

Jetson Orin上跑SD 1.5，三个框架三个命

Jetson Orin NX的GPU算力不是盖的，但Stable Diffusion的UNet结构对显存带宽的渴求足以让任何边缘设备跪下来唱征服。我分别用ONNX Runtime（TensorRT后端）、ExecuTorch（XNNPACK GPU委托）、MediaPipe（TFLite GPU委托）跑SD 1.5，512×512图，20步DDIM，batch size固定为1（因为后面动态batch章节会讲开大batch的惨剧）。

ONNX Runtime via TensorRT：单张图推理时间2.8秒，每秒吞吐0.36张。整板功耗峰值22W。TensorRT的INT8量化引擎在这次测试中表现稳定，UNet的卷积层几乎全部融合成单一内核，显存占用仅3.1GB。但这是因为我用了TensorRT的trtexec工具把ONNX模型预先编译成了.engine文件——如果你直接拿通用ONNX模型给ONNX Runtime的TensorRT执行提供程序在线编译，首张图推理时间会额外增加45秒，因为TensorRT的层融合搜索算法在Orin的Arm CPU上跑得巨慢。

ExecuTorch这边就有点戏剧性了。它不支持TensorRT，只能走XNNPACK的OpenCL GPU后端。我导出的.pte文件在Orin上跑SD 1.5，单张图推理时间3.5秒，吞吐0.29张。但功耗只有15W，整整比ONNX Runtime低了7W。这让我眼前一亮：在边缘设备上，功耗常常比绝对速度更重要，尤其当你的设备靠电池供电或者塞在没风扇的铁壳子里时，7W的差距意味着设备能不能活过一个夏天。

骁龙X Elite的NPU被ONNX Runtime拉满了但为什么温度感人

把SD 1.5搬到骁龙X Elite的NPU上，是我这次测试最接近“炸机”的时刻。ONNX Runtime用QNN后端把UNet量化成INT8推上NPU，单张图推理时间标称1.2秒——这是官方Demo里反复炫耀的数字。我实测呢？第一张图1.4秒，还算接近。可连续推理到第8张时，延迟突然跳到3.1秒，然后稳定在2.8秒附近。我摸了下散热口，烫得能煎鸡蛋，软件读数显示NPU温度达到了97°C，触发了强制降频。

这个坑比Jetson的更隐蔽：骁龙X Elite的NPU在持续高负载下没有足够的热容缓冲。ONNX Runtime的QNN后端也没有提供任何主动功耗管理接口——它只管把算子全速喂给NPU，完全不管温度死活。而ExecuTorch在同一硬件上用XNNPACK跑SD 1.5，虽然慢一点（单张1.9秒），但因为主要负载在CPU和GPU的混合调度，温度最高只到81°C，连续跑50张也没降频。MediaPipe呢？SD 1.5根本就跑不起来——TFLite转换工具在处理SD的CFG双文本编码器结构时直接抛了一堆“unsupported control flow”错误，我尝试了三次就放弃了。

我差点把电脑砸了：动态形状与量化支持的暗坑

ExecuTorch的动态batch坑死我了

前面夸了ExecuTorch在Phi-3上的速度，现在该说它把我气得咬牙切齿的点了。安防那个人脸特征提取项目，输入图片的batch size不是固定的——有时候摄像头帧率波动，buffer里可能攒了1到8张脸不等。我在ViT模型里标注了dynamic batch维度，用PyTorch导出ExecuTorch时加了dynamic_shapes参数，自以为稳了。结果.pte文件一加载，只要输入batch size不等于导出时的默认值1，Runtime直接抛出一段我至今能默背的错误：

RuntimeError: Method 'forward' called with input shapes [[2, 3, 224, 224]] 
which do not match the program's pre-allocated shapes [[1, 3, 224, 224]]. 
Dynamic shape dimensions were not properly delegated or the backend does not 
support dynamic shapes. Consider reverting to static shapes or implementing 
a custom memory planner.

这个错误意味着ExecuTorch在导出时已经根据默认输入为所有中间张量做了静态内存分配，即使你说“这个维度是动态的”，它的内存计划仍然按导出时的大小做了固化。要真正支持动态batch，你需要自己实现一个MemoryPlanner类，注册到运行时里——文档里提到过这事，但示例代码只有寥寥几行，我不得不扒了ExecuTorch的源码，看了两天内存分配的实现，才搞定一个勉强可用的动态batch方案。（延伸阅读：我让两个LLM互相攻击了三个月，才看清安全评测自动化的七寸在哪里——一个红队框架的架构决策全记录）

这个经历让我深刻理解了AOT编译的代价：你把灵活性和运行时开销一起交给了编译器，换来了速度，但当需求变化时，你得花大价钱把灵活性赎回来。ONNX Runtime在这方面就成熟多了：它的图优化器可以在运行时根据实际输入形状重新规划内存，虽然这会增加首次推理的延迟（大约多出几十到几百毫秒不等的图编译时间），但至少不会直接挂掉。

ONNX Runtime的INT8量化在Phi-3上的精度滑坡

我最初给客户承诺的是INT4量化的Phi-3，因为推理快、省内存。但客户临时要求把上下文长度从4k扩展到8k，这时候INT4量化在长序列上的注意力值分布开始严重漂移——模型输出的token相关性急剧下降，生成结果变成了胡言乱语。我赶紧切换成INT8量化，想着只损失不到1%的精度，结果用ONNX Runtime的动态INT8量化跑出来的Phi-3，在MMLU上的准确率从70.4跌到了62.1，8个百分点的下降，这在客户那里等同于不可用。

我排查了整整两天，发现是ONNX Runtime的INT8量化校准算法（默认是min-max）对Phi-3的异常激活值分布处理不当。Phi-3的某些层里激活值有很长的尾部，min-max校准会把量化范围设得超宽，导致绝大部分数值被压缩到两个低精度bin里，量化误差极大。解决方案是手动指定校准方法为percentile或entropy，并重新生成校准数据集——但这一套流程在ONNX Runtime的文档里写得极其零散，我得从四个不同的GitHub讨论和两个Medium博客里拼凑出完整步骤。好在最终调整后INT8模型的精度恢复到了68.7，勉强能让客户接受。

ExecuTorch的量化工具链倒是让我省心了些：它的AOT量化在导出时就用校准数据确定了每个算子的量化参数，因为和XNNPACK的底层算子库紧耦合，量化误差控制得比ONNX Runtime的通用量化方案好一些。同样INT8 Phi-3，ExecuTorch在MMLU上拿到了69.5，几乎贴着浮点基线的70.4。但代价又是那个老问题：量化策略在导出时就写死了，你想换量化方案？重新导出吧。

MediaPipe的模型转换工具让我多掉了两根头发

前面提过MediaPipe在SD上的惨败，但即使在它擅长的视觉模型上，转换流程也远非一帆风顺。把ViT-Large从PyTorch转到TFLite，需要先转成Keras SavedModel，再调TFLiteConverter。问题出在ViT里用到的einsum操作，Keras SavedModel根本不支持einsum的序列化，我只能硬着头皮把einsum拆成matmul和transpose的组合。改完模型后，TFLiteConverter又报“ConcatV2操作不支持INT8量化”——行，我再把concat层的量化给关了。这么一顿折腾下来，模型确实是能跑了，但原本PyTorch ViT在骁龙GPU上2.8ms的事，到了MediaPipe变成3.1ms，而且每次升级模型版本都得重复一次这种痛苦的手工改写。

MediaPipe的“模型花园”里确实有很多开箱即用的模型，但如果你需要自己定制模型结构，并且想用GPU委托加速，那你最好提前准备好一大把时间和一颗强大的心脏。Google的工程师在MediaPipe文档里放了句轻描淡写的话：“对于非标准模型，建议先转换为TFLite格式并测试兼容性。”我想把这句话纹在工位上，每次新项目选型前看一遍。

# ONNX Runtime动态形状推理示例：处理可变batch的ViT输入
# 展示如何不因输入形状变化而导致崩溃

import onnxruntime as ort
import numpy as np

# 启用所有执行提供程序，让ONNX Runtime自动选择
session_options = ort.SessionOptions()
session_options.graph_optimization_level = ort.GraphOptimizationLevel.ORT_ENABLE_ALL

# 加载模型（包含动态batch维度标记为"batch_size"）
session = ort.InferenceSession(
    "vit_large_dynamic.onnx",
    sess_options=session_options,
    providers=["QNNExecutionProvider", "CPUExecutionProvider"]  # 骁龙优先QNN
)

print(f"实际使用的后端: {session.get_providers()}")

# 假设ViT输入名称为"pixel_values"，动态轴为第一维
input_name = session.get_inputs()[0].name

# 测试不同batch size
for batch_size in [1, 2, 4, 8]:
    dummy_image = np.random.randn(batch_size, 3, 224, 224).astype(np.float32)
    # 首次推理会自动触发图优化和内存重分配
    start = time.perf_counter_ns()
    outputs = session.run(None, {input_name: dummy_image})
    end = time.perf_counter_ns()
    lat_ms = (end - start) / 1e6
    
    # 第二次推理：内存已预热，测量稳态延迟
    start_s = time.perf_counter_ns()
    outputs = session.run(None, {input_name: dummy_image})
    end_s = time.perf_counter_ns()
    steady_ms = (end_s - start_s) / 1e6
    
    print(f"Batch={batch_size}: 首次延迟={lat_ms:.2f}ms, 稳态延迟={steady_ms:.2f}ms")

多后端调度：QNN、XNNPACK、CUDA，谁是真·多面手

XNNPACK在CPU上的救场

XNNPACK是Google开发的神经网络推理库，主攻ARM和x86 CPU优化。在我这次测试里，XNNPACK扮演了一个关键时刻兜底的角色：当QNN或GPU后端因为算子兼容性掉链子时，XNNPACK能靠高度优化的汇编实现把CPU的性能榨到极致。ExecuTorch和ONNX Runtime都内建了XNNPACK后端，而且有趣的是，在纯CPU推理Phi-3时，ExecuTorch的XNNPACK比ONNX Runtime的XNNPACK快了近20%——这是因为ExecuTorch的AOT编译允许XNNPACK在模型级做更激进的算子融合，而ONNX Runtime必须保留图级别的通用性。

但这不意味着XNNPACK万能。当我把Jetson Orin上的GPU委托关闭，纯用XNNPACK跑SD 1.5时，单张图推理时间高达22秒，功耗虽然只有8W，但这点功耗优势在性能面前毫无意义。XNNPACK是救场工具，不是主力输出，记住这句话。（延伸阅读：多模态Agent的评测，我们一直在用错尺子——从轨迹对齐到目标达成的严格考试）

QNN的封闭感与性能诱惑

高通QNN（Qualcomm Neural Network）SDK是解锁骁龙NPU性能的唯一钥匙。无论ONNX Runtime还是ExecuTorch，要调用Hexagon NPU都必须通过QNN的底层API。QNN对固定结构CNN和量化后的Transformer支持相当不错——ViT-Large的INT8模型在NPU上跑出2.3ms就是铁证。但QNN的算子覆盖表像一个黑箱，你不到真正部署那一刻，永远不会知道你的模型里哪个op会触发CPU fallback。

我专门花了一天时间写了个算子覆盖度检测脚本：遍历ONNX模型的每个节点，对比QNN 2.20的支持列表。结果Phi-3的算子覆盖率只有73%，未覆盖的28%全部被ONNX Runtime悄悄丢给了CPU。这就解释了为什么首token时间远不如预期——不是NPU慢，是它只干了七成的活，剩下三成在CPU上拖后腿。ExecuTorch因为AOT编译，在导出阶段就可以把这些“QNN不支持”的算子提前暴露出来，让你一次性解决问题，而不是像ONNX Runtime那样运行时静默降级。

多流推理实测：MediaPipe的并行能力让我重拾好感

虽然我在语言模型上把MediaPipe批得够呛，但回到它的主场——多路视频流并行推理——MediaPipe突然支棱起来了。它的内部调度器基于有向图执行引擎，天然支持多流并发：不同摄像头流作为图的入口节点，可以并行推入同一推理子图（共享模型权重），调度器自动处理显存复用和排队。我在骁龙X Elite上用MediaPipe并行跑8路ViT推理，每路延迟从3.1ms只上升到5.4ms，吞吐量飙到每秒1480帧，把ONNX Runtime的280帧（多流并发时因NPU抢占总线带宽而崩盘的数字）甩出一条街。

ONNX Runtime在多流场景下的缺陷暴露得非常彻底：它的内存和线程管理是面向单请求吞吐优化的，多流并发时不同流的请求争抢NPU锁，导致大量时间浪费在内核态调度上。虽然它提供了RunOptions可以绑定不同执行实例，但缺乏一个统一的跨实例调度器。ExecuTorch也是类似的问题——它的Runtime实例设计为单请求独占，要并行就得自己管理多实例和内存池，开发工作量不小。

MediaPipe这方面是基因优势：它生来就是为了处理多传感器流，调度器已经成熟到了可以开箱即用。如果你做的是多摄像头智能盒子、工业视觉检测这类场景，MediaPipe在并发上的表现值得你暂时容忍它模型转换的痛苦。

# 多流并行推理压测脚本：对比不同框架的并发吞吐
# 模拟8路视频流，每路独立送入同一ViT模型

import threading
import queue
from collections import defaultdict
import time

def stream_worker(stream_id, input_queue, session, result_dict, latencies):
    """单流推理线程，持续拉取输入并推理"""
    while True:
        try:
            img_tensor = input_queue.get(timeout=1)
        except queue.Empty:
            break
        start = time.perf_counter_ns()
        outputs = session.run(None, {"pixel_values": img_tensor})
        end = time.perf_counter_ns()
        latencies[stream_id].append((end - start) / 1e6)
        result_dict[stream_id].append(outputs)
        input_queue.task_done()

# 模拟8路流
num_streams = 8
stream_queues = [queue.Queue() for _ in range(num_streams)]
results = defaultdict(list)
latencies_record = defaultdict(list)

# 创建推理会话（每个流一个独立session避免锁竞争，或共享session取决于框架）
sessions = []
for i in range(num_streams):
    sess = ort.InferenceSession("vit_large_dynamic.onnx", providers=["QNNExecutionProvider"])
    sessions.append(sess)

workers = []
for i in range(num_streams):
    t = threading.Thread(target=stream_worker, args=(i, stream_queues[i], sessions[i], results, latencies_record))
    t.daemon = True
    workers.append(t)
    t.start()

# 喂入数据：每个队列发100张模拟图像
total_frames = 100
for frame_idx in range(total_frames):
    for i in range(num_streams):
        dummy = np.random.randn(1, 3, 224, 224).astype(np.float32)
        stream_queues[i].put(dummy)

# 等待所有队列处理完毕
for q in stream_queues:
    q.join()

# 统计
all_lat = []
for sid in range(num_streams):
    all_lat.extend(latencies_record[sid])
avg_lat = np.mean(all_lat)
p99_lat = np.percentile(all_lat, 99)
total_time = max([max(times) if times else 0 for times in latencies_record.values()])
print(f"8路并发: 平均延迟={avg_lat:.2f}ms, P99={p99_lat:.2f}ms")
print(f"总处理帧数: {total_frames * num_streams}")

所以，你该选谁？我给出的决策树

推荐清单：不同模型、不同硬件的选择

经过这三周的折磨，我总结出了一套简单粗暴的选型逻辑：

如果你在骁龙X Elite上跑Transformer语言模型（Phi-3、Gemma、Llama 3.2等），Executorch > ONNX Runtime > MediaPipe。ExecuTorch的AOT编译对Transformer结构的优化太猛了，首token和TPOT全面领先，功耗控制也最好。但前提是你的模型结构相对标准，不需要频繁改输入形状或做在线量化切换。ONNX Runtime是稳妥的备选，尤其在需要动态batch或动态序列长度时，它的运行时灵活性会让你少死很多脑细胞。MediaPipe暂时别碰，除非它哪天出了官方的LLM Task API。

在Jetson Orin上跑扩散模型，ONNX Runtime + TensorRT是最短路径。前提是你能接受预先编译.engine文件的那45秒等待，以及对静态形状的限制。ExecuTorch的功耗优势在某些场景有价值，但现阶段它对CUDA生态的利用远不如ONNX Runtime成熟。MediaPipe在这个战场上可以无视。

多路视觉流并行处理，选MediaPipe。它的调度器生来就是为并发设计的，ONNX Runtime和ExecuTorch你得自己造轮子。而且MediaPipe在固定视觉模型（分类、检测、分割）上的GPU委托极其稳定，只要你的模型在它的“模型花园”射程内，部署体验可以好到让你忘记转换模型时的痛苦。

功耗敏感场景（比如电池供电、无风扇），Executorch > ONNX Runtime。ExecuTorch轻量级运行时的功耗管理更精细，在我的测试里同等吞吐下平均低20%左右。如果你用ONNX Runtime，务必手动监控NPU/GPU温度并在代码里做主动降频，否则早晚被温控墙拍死。

避坑清单：这些血泪教训给我焊死在记忆里

• 别信任何框架的NPU/GPU自动fallback是免费的。每次fallback都意味着跨设备内存拷贝和同步开销。在生产代码里一定要添加provider选项日志，打印出实际运行的执行提供程序，一旦发现某层算子被静默降级到CPU，第一时间处理。
• 动态形状不是“声明即可用”。ONNX Runtime对动态形状支持最好，但首次图编译延迟可能影响用户体验，做好预热。ExecuTorch的动态形状需要自己写MemoryPlanner，没有准备好就不要在生产环境里开动态batch。
• 量化不是“一键完成”。无论哪一个框架，默认量化方案几乎一定不适合你的模型。校准数据集要自己造，校准方法要手动选（用entropy而不是min-max），并且必须在实际推理数据分布上测精度。我见过太多开发者因为省这一步而让线上模型变成了随机数生成器。
• 关注温控墙，尤其是NPU。骁龙X Elite的NPU性能猛但热容小，持续高负载必然降频。在你的推理循环里插入温度监控逻辑，达到85°C主动暂停推理或降低batch size，比让系统被动降频到800MHz要好得多。Jetson同理，15W模式虽然诱人，但高温下性能衰减严重，考虑主动散热方案。
• 多流并发，先测锁竞争再上线。ONNX Runtime和ExecuTorch都容易在高并发下因为NPU/GPU锁而吞吐暴跌。上线前一定用生产级并发度做至少30分钟的持续压测，观察延迟抖动。如果抖动过大，考虑多实例+请求排队或切换到MediaPipe的调度架构。
• MediaPipe的模型转换是整个部署流程中最不可控的环节。如果你能直接用它的官方模型，那很好。如果需要自研模型，请给模型转换留出额外两周时间，并提前验证你的模型结构在TFLite下的兼容性，特别是einsum、control flow和自定义激活函数。

边缘推理没有银弹。每个框架都在某些特定假设下才表现得像官宣数据那样光鲜，一旦你的使用场景偏离了这些假设，坑就会一个接一个地冒出来。希望这篇用三周不眠夜换来的实测能让你在面对选型时，心里多一张地图，少几个通宵。