2. 推理框架选型：主流边缘推理框架对比

好，咱们进入第二个章节。说实话，选推理框架这事儿，我见过太多人一上来就拍脑袋。有人觉得TensorRT天下第一，有人迷信OpenVINO是Intel亲儿子。嗯，这种心态我特别理解——我刚入行那会儿也干过类似的事。

但你要知道，边缘设备千差万别。一个跑在Jetson上的模型，跟一个跑在树莓派上的模型，选型逻辑完全不同。今天我就把四个主流框架掰开揉碎，讲讲它们各自的脾气秉性。

2.1 四大框架的定位与基因

先给个总览，你心里有个谱。

框架	亲爹	核心优势	典型场景
TensorRT	NVIDIA	GPU极致加速	Jetson、自动驾驶
ONNX Runtime	微软	跨平台、开放生态	多硬件混用、快速部署
OpenVINO	Intel	CPU/VPU深度优化	Intel CPU、Movidius
TFLite	Google	移动端、轻量化	手机、MCU、IoT

你看，每个框架背后都有明确的硬件绑定。这不是巧合，是商业策略。我建议你选型时先问自己一个问题：我的目标硬件是什么？

2.2 TensorRT：GPU上的性能怪兽

如果你用的是NVIDIA的硬件，比如Jetson Nano、Xavier，或者带CUDA的显卡，那TensorRT基本是首选。

它厉害在哪？说白了就是三板斧：

• 层融合：把多个小算子合并成一个，减少显存读写
• 精度校准：INT8量化时，用KL散度找最佳阈值，损失极小
• 动态张量：运行时自动选择最优kernel

我在一个智慧安防项目里用过TensorRT。当时一个YOLOv5s模型，在Jetson Nano上从30ms优化到12ms。你想想看，这提升可不是一点半点。

2.3 ONNX Runtime：跨平台的瑞士军刀

ONNX Runtime，简称ORT。它的定位很明确——做一个中间层，让你写的模型能在各种硬件上跑。

为什么需要它？你想想看，今天用PyTorch训练，明天想部署到ARM Linux上，后天客户又要求支持Windows。每个平台都重写一遍推理代码？那不得累死。

ORT的玩法是这样的：

# 用ORT跑一个ONNX模型
import onnxruntime as ort

sess = ort.InferenceSession('model.onnx')
input_name = sess.get_inputs()[0].name
output = sess.run(None, {input_name: input_data})

代码就这么几行。但要注意，ORT的性能取决于你选的执行提供者（Execution Provider）。

• CPU上：用OpenVINO EP（Intel CPU）或DirectML EP（Windows）
• GPU上：用CUDA EP或TensorRT EP
• ARM上：用ArmNN EP

我曾经在一个项目里，客户要求同时支持Intel NUC和Jetson。我直接用了ORT，底层切换EP就搞定了。省了至少两周的开发时间。

2.4 OpenVINO：Intel生态的护城河

OpenVINO，全称Open Visual Inference & Neural Network Optimization。名字很长，但核心就一句话：让Intel的CPU和VPU跑AI跑得更快。

它的优化思路跟TensorRT不太一样。TensorRT靠GPU的并行计算，OpenVINO靠CPU的向量化指令集（AVX-512、VNNI）和专用硬件（VPU）。

举个例子，一个ResNet-50模型：

• 在Intel i7-1185G7上，用OpenVINO推理只要8ms
• 用原生PyTorch，要35ms

差距就是这么明显。但OpenVINO有个硬伤——它只认Intel的硬件。你换个AMD的CPU，性能直接打回原形。

2.5 TFLite：移动端的轻骑兵

TFLite，TensorFlow Lite的简称。它专为移动端和嵌入式设备设计，目标是在资源受限的环境下跑推理。

它的核心优势是：

• 模型小：量化后可以压缩到原来的1/4
• 延迟低：手机端推理通常在10ms以内
• 硬件加速：支持Android的NNAPI、iOS的Core ML

但TFLite也有局限。它主要支持TensorFlow训练的模型。你用PyTorch训练，得先转成ONNX，再转成TFLite。多了一层转换，有时候会出问题。

我记得有一次，一个客户要在树莓派上跑人脸识别。我试了ORT和TFLite两种方案。最后发现TFLite的量化模型更小，只有2MB，而且推理速度也够用。ORT虽然灵活，但模型大了30%。

2.6 选型方法论：四步决策法

讲了这么多，你可能会问：到底怎么选？我总结了一套四步法，你照着做就行。

1. 锁定硬件：先确定你的目标设备是什么。GPU、CPU、VPU、MCU？
2. 评估算子：你的模型里有没有自定义算子？如果有，ORT或TFLite可能更友好。
3. 测试性能：别光看benchmark。拿你的模型，在真实设备上跑一遍。延迟、吞吐量、内存占用，全测一遍。
4. 考虑生态：团队里谁熟悉哪个框架？后续维护成本高不高？

举个例子。假设你有一个Jetson Orin，模型是YOLOv8。那TensorRT就是最优解。为什么？因为Jetson的GPU就是为TensorRT设计的。你非要用ORT，性能至少打八折。

再比如，你有一个Intel NUC，模型是BERT。那OpenVINO更合适。因为BERT的矩阵运算在CPU上优化得更好。

2.7 实战对比：一个案例

最后，我拿一个真实案例给你看看。一个MobileNetV2模型，部署在三种设备上：

设备	框架	延迟（ms）	模型大小（MB）
Jetson Nano	TensorRT (FP16)	8.2	5.6
Jetson Nano	ONNX Runtime (CUDA)	12.5	8.9
Intel NUC i5	OpenVINO (FP32)	15.3	13.4
Intel NUC i5	ONNX Runtime (CPU)	28.7	13.4
树莓派4B	TFLite (INT8)	45.0	2.1
树莓派4B	ONNX Runtime (CPU)	78.3	13.4

你看，同样的模型，在不同框架下差距很大。TensorRT在Jetson上比ORT快了35%。OpenVINO在Intel CPU上比ORT快了47%。TFLite在树莓派上虽然慢，但模型小，适合存储受限的场景。

所以，选型不是拍脑袋，是数据说话。我建议你每次做选型决策前，都拉一张这样的对比表。一目了然。

好，这一章就到这里。下一章我们聊聊模型转换的那些坑。你准备好了吗？