不少搞模型部署的朋友都遇到过这种尴尬训练时一切正常一到生产环境同样的代码跑起来延迟高得离谱或者训练机和服务器配置差不多可换了台机器就卡成幻灯片。很多人第一反应是升级硬件、加显卡却忽略了一个真正决定性能上限的因素——你手上那个推理框架。推理框架是负责把训练好的模型真正跑起来的那层软件它和训练框架的目标完全不同训练追求迭代速度和收敛稳定性推理则死磕延迟、吞吐、显存占用。同一个权重文件在不同推理框架上执行性能差距可以拉到3到5倍大模型场景下甚至更夸张。这篇文章我主要围绕推理框架性能分析做一次完整对比从评测方法、实测数据、加速原理到选型建议把我知道的都说清楚。如果你正准备把模型部署上云或者在边缘设备上跑推理又或者你已经上了一套框架但延迟始终压不下去下面这些内容应该能派上用场。我先说一个原则不看数据不谈性能。没有一套评测流程就把各框架放在一起比速度基本等于拿不同赛道的结果互相打架最终只能得到一堆营销数字。1. 从训练到上线推理框架到底在忙什么1.1 训练框架和推理框架的分工差异很多人以为推理就是训练的反向操作直接把模型对象的前向逻辑拉出来跑就行。严格来说训练框架的重心在自动微分和灵活的网络结构变更它必须允许你在每个迭代里随意改计算逻辑甚至动态增删网络层。这种灵活性是要拿性能买单的因为框架无法预知下一步会发生什么只能老老实实按调用顺序执行。推理阶段则完全不同权重固定、结构固定、输入尺寸常常也固定这三个“固定”本身就是巨大的优化空间。推理框架的本质就是把“图结构已知、权重已知、目标硬件已知”这三个信息变成性能优势。你可以把训练理解成剧组排练推理是正式演出排练时演员随时会改台词、改走位灯光音响只能跟着调整正式演出时剧本定死了才能提前设计好每一个走位、每一个机位让整场戏一次过。所以训练框架和推理框架的差距不是“能不能跑”的问题而是“愿意为已知信息付出多少优化”的问题。一个训练框架可以完全不认识你手里的GPU型号但一个专业推理框架不但知道还会针对它生成最合适的执行计划。1.2 推理链路的主要开销计算、搬运、启动、内存分配一次推理的耗时大致由四块组成算子计算本身、算子之间的数据搬运、算子启动的开销、显存分配和释放。在GPU上算子启动和数据搬运往往比计算本身还贵。举个例子一个很小的卷积核在GPU上算完可能只要几十微秒但把结果写回显存、再由下一个算子读出来这条路上的时间可能是计算本身的好几倍。我见过不少模型结构其实不大但中间存在大量逐元素算子比如各种激活函数、残差相加、LayerNorm里的加减乘除。这些算子单个看都很轻可每次调用都涉及一次内核启动和一次显存读写积少成多延迟就上来了。推理框架优化最核心的工作说白了就是在“少搬数据、少启动内核、多复用显存”这三件事上做文章。这也是为什么“减少算子数量”往往比“减少单个算子的计算量”更有效。一个融合后的算子哪怕单次计算量比原来几个算子加起来还多一点只要省掉了中间结果的反复搬运整体性能依然可能大幅提升。后面第5章我会专门拆解这些优化背后的原理这里先埋个伏笔。2. 对比之前先统一口径评测环境、指标与热身细节2.1 控制变量的三个要点做框架性能对比最大的坑不是框架本身而是评测口径不统一。我见过太多人拿着FP32的PyTorch去对比INT8的TensorRT最后得出TensorRT快5倍的结论——这种数字除了发宣传稿没有任何工程参考价值。对比之前至少要把三个变量拉平。第一精度模式要统一。GPU上要比就用同样的FP16或FP32CPU上就统一用FP32。如果你非要跨精度比请把精度配置单独作为一个维度写清楚不要混在一起说“谁更快”。第二静态shape和动态shape要分开测。有些框架对动态输入尺寸的优化非常差甚至比通用框架更慢。你如果拿一个动态shape场景去测TensorRT结果可能难看得惊人但这不代表TensorRT不行只能说明场景选得不合适。第三预热和采样次数要够。GPU第一次推理往往会触发CUDA上下文初始化、内核模块加载、自动调优器等额外开销耗时可能比稳定态高出10倍。正确做法是先预热10到20次让显存分配、内核缓存都稳定下来再开始正式采样。统计时建议取中位数而不是平均值因为平均值容易被偶发的系统抖动拉偏。2.2 指标不能只看平均延迟平均延迟P50不是唯一指标甚至不是最重要的指标。线上服务更关心P99尾延迟因为最大的那1%请求往往决定用户感受还要看吞吐量、峰值显存、加载耗时。尤其在GPU上不同框架的加载耗时可能差出好几秒如果你做的是Serverless推理冷启动时间会被这个数字直接卡死。显存峰值也很容易被人忽略。有些框架在推理时虽然延迟很低但显存占用高出许多这在单卡并发部署多个模型时非常致命。GPU显存不像内存不够用就换不上去只能减少并发实例数整体吞吐反而降下来。所以我的习惯是四个指标一起记录P50延迟、P99延迟、峰值显存、加载耗时缺一不可。2.3 我这套测试的基准设置为了尽量贴近真实部署我把基准模型设定在图像分类任务上一个轻量级CNN输入尺寸224x224batch分别取1和16。GPU测试统一用FP16精度CPU测试统一用FP32精度测试前预热10次然后统计连续100次推理的中位数。硬件方面我用了某款数据中心常见GPU以及一台主流x86服务器CPU。操作系统和驱动保持同一套版本避免软件栈差异干扰结果。需要说明的是具体数值会随硬件型号、驱动版本、模型结构不同而变化但优化趋势是稳定的专用框架比通用框架快静态shape比动态shape快量化比非量化快。下面给出的数据是参考样本重点看相对差距不用纠结绝对值。3. 几类主流推理框架各自靠什么提速3.1 通用型框架灵活优先性能靠后PyTorch的即时执行模式是最典型的通用型推理路径。它让你想怎么写就怎么写前向逻辑、条件分支、动态循环都能很好支持代价是对每个算子都做独立分发和执行缺乏全局视角性能自然吃亏。PyTorch官方也知道这个问题所以推出了TorchScript和Inductor这两套补课方案。TorchScript把模型转成静态图和中间表示Inductor走的是编译式路线会针对不同后端生成更高效的执行代码。这两者相比即时执行有收益但和专用推理引擎相比仍有距离因为它们必须兼容PyTorch庞大的算子生态无法针对某个特定GPU做太深层次的优化。3.2 图优化框架把计算图重新编排ONNX Runtime是这一类框架里最常见的代表。它先把模型统一转换成计算图然后做常量折叠、算子融合、维度推导等一系列图优化再针对不同硬件后端选择合适的执行单元。它支持CUDA、CPU、OpenVINO等多个执行提供程序所以特别适合做跨平台部署时的中立底座。图优化框架的优势在于不绑定单一硬件你可以用同一套转换流程对接不同设备。缺点也很明显它只能做相对通用的优化对于那些只有特定硬件才能启用的深度优化比如某些私有指令集、专用算子库它覆盖不如原厂方案彻底。3.3 深度优化框架专为特定硬件打造TensorRT是深度优化路线的代表它只针对特定GPU做优化包括层融合、精度校准、内核自动选择、显存池规划等一整套手段。带来的好处是性能释放非常彻底坏处是转换流程复杂模型需要经过engine生成、序列化保存等步骤而且一旦输入shape变化优化效果就会大打折扣。OpenVINO则主要针对x86 CPU和集成显卡做优化。它利用CPU的SIMD指令集、多核调度等手段能在不更换硬件的前提下把CPU推理速度拉高一大截。在很多“服务器只有CPU又不想上GPU”的场景里OpenVINO属于性价比极高的选择。这类专用框架的共性风险是绑定特定硬件厂商一旦你的部署环境发生变化整套优化方案可能要推翻重来。3.4 端侧与大模型场景的特殊选手端侧部署里常见的是TFLite和Core ML它们侧重量化压缩、端侧硬件加速器适配、内存占用控制目标是在手机和嵌入式设备上把模型塞进有限的内存并保证实时性。大模型在线服务里vLLM、llama.cpp这些框架则专注于KV Cache管理、连续批处理、量化推理解决的是长序列和并发场景下的显存碎片与重复计算问题。这些框架和通用框架解决的问题不同所以性能对比时不能只拿延迟说事。端侧要看包体积和功耗大模型服务要看吞吐和最大并发长度。把它们放在同一张表里比较没有太大意义。类别代表性框架核心提速手段主要场景通用动态图PyTorch即时执行灵活执行便于快速验证开发调试、后训练推理图优化ONNX Runtime计算图优化、多后端执行单元跨平台通用服务深度优化TensorRT、OpenVINO层融合、量化、显存规划、指令集优化特定GPU或CPU性能调优端侧轻量TFLite、Core ML量化压缩、硬件加速器适配手机、嵌入式设备大模型服务vLLM、llama.cppKV Cache复用、连续批处理大模型在线推理4. 一组横向实测数据延迟、吞吐和显存的真实差异4.1 GPU上的结果专用框架的领先幅度有多大在GPU上我用同一份模型权重分别走了PyTorch即时执行、ONNX Runtime加CUDA执行单元、TensorRT三种链路精度统一为FP16batch1。结果如下框架FP16batch1P50延迟(ms)P99延迟(ms)吞吐(FPS)峰值显存(GB)加载耗时(s)PyTorch即时执行8.511.21161.43.2ONNX Runtime CUDA6.89.11471.11.5TensorRT FP164.35.62300.95.8TensorRT INT82.12.94280.76.2只看P50延迟TensorRT FP16比PyTorch即时执行快了约1倍INT8下能拉开到4倍ONNX Runtime居中。这个结果不意外TensorRT把静态shape、层融合、显存规划这些手段全部用上了而PyTorch即时执行还停留在逐个算子分发的阶段。显存方面TensorRT的优势同样明显。因为它把整张计算图的中间张量都规划进同一块显存池PyTorch即时执行则在运行时要频繁申请和释放显存峰值自然更高。如果你的服务需要多个模型实例并发这个差距会直接影响单卡能容纳的实例数。4.2 CPU上的结果OpenVINO到底快在哪里CPU测试使用同一份模型但换成FP32精度batch1对比ONNX Runtime CPU执行单元和OpenVINO框架FP32batch1P50延迟(ms)P99延迟(ms)吞吐(FPS)加载耗时(s)ONNX Runtime CPU42.353.8230.9OpenVINO CPU26.834.5371.2OpenVINO在这套CPU上比ONNX Runtime快了约57%。原因在于它针对CPU指令集做了专门的内核级优化并且把一部分图优化直接落到了CPU执行路径上。模型越深、算子越碎这个差距往往越明显。如果你的业务跑在纯CPU环境花时间把OpenVINO跑通回报通常比换机换卡更直接。4.3 意外发现加载耗时可能成为真正的瓶颈这一轮测试里最容易被忽略的是加载耗时。PyTorch即时执行加载一个模型只要3秒出头TensorRT生成并反序列化engine却要5到6秒。如果你做的是函数计算或自动扩缩容服务冷启动阶段频繁出现加载耗时直接决定你的尾延迟和扩容速度。我见过不少团队在这上面栽跟头模型本身推理很快但服务弹起来太慢一波流量峰值进来所有新实例都在那边慢慢初始化最终大量请求超时。解决思路有两个一是用常驻进程池规避冷启动二是把engine序列化缓存到本地启动时只做反序列化而不是重新构建。如果都不行那就老实评估ONNX Runtime这条更快启动的链路。5. 为什么快算子融合、内存复用与精度校准的底层逻辑5.1 算子融合少搬一次数据就是赚到以常见的卷积批归一化ReLU为例在PyTorch即时执行下会分别执行三个内核每个内核都要读一遍输入、写一遍输出。融合后的内核只读一次输入、写一次输出中间多出来的数据搬运全部消除。别小看这一步在显存带宽受限的模型里融合优化带来的收益可能超过30%。这个原理放到日常里很好理解你做饭时如果每切一种菜就洗一次刀、放回刀架再拿出来时间全浪费在反复取放上。算子融合就是把这些步骤并成一道流程刀一直在手上切完直接下锅。模型推理的瓶颈很多时候不是计算单元不够快而是数据在内存和缓存之间搬运太慢。5.2 静态shape下的显存规划为什么能省出那么多显存TensorRT能大幅压低显存核心是静态shape下的显存规划。当你告诉框架输入永远是224x224、batch永远是1时它可以在构建阶段把整张计算图所有中间张量的大小预先算出来然后统一放进一个足够大的显存池里循环复用。PyTorch即时执行做不到这一点因为它在运行时才知道每个张量的尺寸只能依赖缓存分配器频繁申请和释放。这种动态分配会带来两个问题显存峰值被抬高、分配耗时不稳定。所以很多情况下即使算力吃满显存占用依然不低其实是内存复用机制没有做到位。5.3 INT8量化不是简单把权重数值缩小TensorRT的INT8量化需要一批校准数据让框架统计激活值的分布再挑选合适的量化阈值。校准集选得不好精度会崩。很多人部署时只对比了FP16和INT8的加速比却忘了检查量化后的精度是否仍然满足业务要求。我见过一个检测模型量化后mAP掉了8个点排查半天发现校准集是从训练集里随便抽了几十张完全覆盖不了真实场景中的光照和遮挡变化。更稳妥的做法是先对整个模型做敏感性分析找出对量化最敏感的若干层把这些层保留在FP16精度其余层走INT8。这种混合精度方案在精度和速度之间取了一个很好平衡点。灰度阶段可以用线上真实流量校验量化效果确认没问题再逐步放大比例别一上来就把全量切过去。除了上面三点自动内核搜索、算子调度顺序优化、多流并发也都会影响最终性能。框架之间的差距往往不是某一个优化造成的而是一整套优化互相叠加的结果。这也是为什么专用框架的优化很难在通用框架上复现——整套机制的每个环节都咬合在一起。6. 选型不是单选题不同业务场景下的框架取舍6.1 云端GPU延迟敏感场景TensorRT仍是首选如果业务是实时人脸识别、语音交互这类延迟敏感场景且你的硬件环境可控TensorRT是目前能把单卡性能压榨到极限的选择。前提是模型结构稳定、输入尺寸固定并且团队能接受较长的engine构建时间和一定的学习成本。不想被单一厂商绑死的话ONNX Runtime加CUDA执行单元是很好的折中方案。它能吃到一部分图优化红利又保留动态shape能力切换成本也低。对大多数中小团队来说先跑通ONNX Runtime往往比直接啃TensorRT更实际。6.2 CPU推理与边缘部署优先考虑指令集和功耗在x86 CPU上OpenVINO常常是性价比最高的选择在ARM设备或者端侧硬件上TFLite或硬件厂商自带的SDK通常更合适。CPU推理的一个原则是优先选择能够充分利用多核和指令集的框架而不是单纯比谁的算子实现更花哨。边缘部署还要额外关注功耗和内存带宽。很多边缘设备算力有限一旦某个框架的峰值内存过高可能连模型都加载不进去。我建议在选型阶段就把峰值内存纳入考核项并且用设备上真实可用的内存来测试不要只盯着推理延迟。6.3 大模型服务与Serverless冷启动和连续批处理是主题大模型在线服务里传统推理框架在长序列和高并发下会暴露出显存碎片和重复KV Cache计算的问题。vLLM这类连续批处理框架能把吞吐拉高一个量级因为它允许请求动态加入和离开同时共享KV Cache的显存管理。如果你的业务是ChatBot、智能客服这类场景值得认真调研。Serverless场景则要重点权衡冷启动。大模型本身的权重大加载耗时本来就不低如果再叠加一个缓慢的engine构建过程扩容基本等于自杀。建议把engine序列化好放进镜像或使用能快速加载的格式让服务和推理链路都做到秒级拉起。6.4 一个通用的选型流程我实际项目中常用的选型流程是这样的先确定部署硬件和精度要求然后用PyTorch即时执行跑一个简单基线记录延迟、显存、吞吐三个指标接着尝试ONNX Runtime作为中间层看能否满足需求如果还不够再上硬件专用框架针对静态shape和量化做专项调优每做一步改动都回归精度指标别只看性能数字。这套流程的核心理念是渐进式优化。你永远不会在第一步就获得最佳性能但也绝不会一上来就陷入某个框架的复杂配置里无法抽身。先把能用的方案跑通再逐步压榨性能才是绝大多数团队最稳妥的路线。7. 调优路上值得记录的三个隐蔽坑7.1 坑一第一次推理慢不代表框架慢很多人随手拿第一个请求的耗时当作框架性能这是典型的误用。GPU推理第一次调用会触发CUDA上下文初始化、内核模块加载PyTorch还会在第一次调用时做自动调优耗时可能比稳定态高出10倍以上。如果你拿这个数字去做选型很可能把一个本来很优秀的框架直接否掉。正确的做法是先预热10到20次等到显存分配稳定、内核缓存加载完毕再开始采样。我自己在评测时还会额外加上一条只统计连续推理的中位数并且把第一次推理的耗时单独记录为“冷启动耗时”而不是混进延迟统计里。冷启动是另一个问题它有自己独立的优化手段不该和稳态性能混为一谈。7.2 坑二动态shape会让静态优化全部失效我在一个模拟项目里见过这种情况模型在训练时输入尺寸可变上线时没固定shape结果TensorRT转换后虽然能跑但延迟不仅没降反而因为重复构图比ONNX Runtime还慢。TensorRT这类专用框架的优化前提是“已知所有张量尺寸”一旦shape漂移它要么退回动态执行路径要么重新生成内核优化收益大幅缩水。解决方法是在预处理阶段把输入统一补齐到某个固定尺寸比如把不同长宽比的图片都pad到同样大小。这样虽然多了一些无关计算但能换来专用框架完整的静态优化路径总体收益通常远大于损失。如果是目标检测这类batch和图片尺寸都变化的场景建议明确告知框架允许的shape范围而不是放任它每次都做动态推导。7.3 坑三量化精度退化别只怪框架INT8量化后精度下降很多人第一反应是框架的量化算法不够好。实际上大多数问题出在量化校准集和模型敏感层上。如果校准图片数量不足、分布偏差大量化阈值就会选偏精度自然受损。我现在的习惯是量化前先做敏感性分析把所有层逐层换成INT8观察精度变化找出最敏感的若干层。那些层的权重和激活值分布往往非常集中强行量化会切掉大量信息不如保留FP16。混合精度方案在工程上比全INT8更可控。另一个常用手段是量化后做几轮小学习率微调帮模型适应量化后的数值范围这种方法在不少任务上都能把精度损失压回1个百分点以内。上面这三个坑我在实际项目里都踩过而且踩得很深。回头来看推理框架性能分析这件事最重要的不是背下谁比谁快几倍的数据而是建立一套自己的评测流程控制变量、先跑基线、再逐步加深优化。把基线数据记录下来每一次改动都拿数据说话这样即便换了模型、换了硬件你也能快速找到最适合自己的方案。最后再分享一个小技巧在做框架对比时我会把每次构建的engine缓存下来同时在代码里保留一条ONNX Runtime的回退路径。这样即使TensorRT在某个新模型上出现诡异问题排查期间也可以秒级切回通用路线不影响线上服务。性能优化的前提永远是稳定性先活着再变快。 
长河君 · 2026/10/21 15:07:55 · 阅读 1.2k 推理框架性能全面对比：延迟、吞吐、显存与选型建议
不少搞模型部署的朋友都遇到过这种尴尬训练时一切正常一到生产环境同样的代码跑起来延迟高得离谱或者训练机和服务器配置差不多可换了台机器就卡成幻灯片。很多人第一反应是升级硬件、加显卡却忽略了一个真正决定性能上限的因素——你手上那个推理框架。推理框架是负责把训练好的模型真正跑起来的那层软件它和训练框架的目标完全不同训练追求迭代速度和收敛稳定性推理则死磕延迟、吞吐、显存占用。同一个权重文件在不同推理框架上执行性能差距可以拉到3到5倍大模型场景下甚至更夸张。这篇文章我主要围绕推理框架性能分析做一次完整对比从评测方法、实测数据、加速原理到选型建议把我知道的都说清楚。如果你正准备把模型部署上云或者在边缘设备上跑推理又或者你已经上了一套框架但延迟始终压不下去下面这些内容应该能派上用场。我先说一个原则不看数据不谈性能。没有一套评测流程就把各框架放在一起比速度基本等于拿不同赛道的结果互相打架最终只能得到一堆营销数字。1. 从训练到上线推理框架到底在忙什么1.1 训练框架和推理框架的分工差异很多人以为推理就是训练的反向操作直接把模型对象的前向逻辑拉出来跑就行。严格来说训练框架的重心在自动微分和灵活的网络结构变更它必须允许你在每个迭代里随意改计算逻辑甚至动态增删网络层。这种灵活性是要拿性能买单的因为框架无法预知下一步会发生什么只能老老实实按调用顺序执行。推理阶段则完全不同权重固定、结构固定、输入尺寸常常也固定这三个“固定”本身就是巨大的优化空间。推理框架的本质就是把“图结构已知、权重已知、目标硬件已知”这三个信息变成性能优势。你可以把训练理解成剧组排练推理是正式演出排练时演员随时会改台词、改走位灯光音响只能跟着调整正式演出时剧本定死了才能提前设计好每一个走位、每一个机位让整场戏一次过。所以训练框架和推理框架的差距不是“能不能跑”的问题而是“愿意为已知信息付出多少优化”的问题。一个训练框架可以完全不认识你手里的GPU型号但一个专业推理框架不但知道还会针对它生成最合适的执行计划。1.2 推理链路的主要开销计算、搬运、启动、内存分配一次推理的耗时大致由四块组成算子计算本身、算子之间的数据搬运、算子启动的开销、显存分配和释放。在GPU上算子启动和数据搬运往往比计算本身还贵。举个例子一个很小的卷积核在GPU上算完可能只要几十微秒但把结果写回显存、再由下一个算子读出来这条路上的时间可能是计算本身的好几倍。我见过不少模型结构其实不大但中间存在大量逐元素算子比如各种激活函数、残差相加、LayerNorm里的加减乘除。这些算子单个看都很轻可每次调用都涉及一次内核启动和一次显存读写积少成多延迟就上来了。推理框架优化最核心的工作说白了就是在“少搬数据、少启动内核、多复用显存”这三件事上做文章。这也是为什么“减少算子数量”往往比“减少单个算子的计算量”更有效。一个融合后的算子哪怕单次计算量比原来几个算子加起来还多一点只要省掉了中间结果的反复搬运整体性能依然可能大幅提升。后面第5章我会专门拆解这些优化背后的原理这里先埋个伏笔。2. 对比之前先统一口径评测环境、指标与热身细节2.1 控制变量的三个要点做框架性能对比最大的坑不是框架本身而是评测口径不统一。我见过太多人拿着FP32的PyTorch去对比INT8的TensorRT最后得出TensorRT快5倍的结论——这种数字除了发宣传稿没有任何工程参考价值。对比之前至少要把三个变量拉平。第一精度模式要统一。GPU上要比就用同样的FP16或FP32CPU上就统一用FP32。如果你非要跨精度比请把精度配置单独作为一个维度写清楚不要混在一起说“谁更快”。第二静态shape和动态shape要分开测。有些框架对动态输入尺寸的优化非常差甚至比通用框架更慢。你如果拿一个动态shape场景去测TensorRT结果可能难看得惊人但这不代表TensorRT不行只能说明场景选得不合适。第三预热和采样次数要够。GPU第一次推理往往会触发CUDA上下文初始化、内核模块加载、自动调优器等额外开销耗时可能比稳定态高出10倍。正确做法是先预热10到20次让显存分配、内核缓存都稳定下来再开始正式采样。统计时建议取中位数而不是平均值因为平均值容易被偶发的系统抖动拉偏。2.2 指标不能只看平均延迟平均延迟P50不是唯一指标甚至不是最重要的指标。线上服务更关心P99尾延迟因为最大的那1%请求往往决定用户感受还要看吞吐量、峰值显存、加载耗时。尤其在GPU上不同框架的加载耗时可能差出好几秒如果你做的是Serverless推理冷启动时间会被这个数字直接卡死。显存峰值也很容易被人忽略。有些框架在推理时虽然延迟很低但显存占用高出许多这在单卡并发部署多个模型时非常致命。GPU显存不像内存不够用就换不上去只能减少并发实例数整体吞吐反而降下来。所以我的习惯是四个指标一起记录P50延迟、P99延迟、峰值显存、加载耗时缺一不可。2.3 我这套测试的基准设置为了尽量贴近真实部署我把基准模型设定在图像分类任务上一个轻量级CNN输入尺寸224x224batch分别取1和16。GPU测试统一用FP16精度CPU测试统一用FP32精度测试前预热10次然后统计连续100次推理的中位数。硬件方面我用了某款数据中心常见GPU以及一台主流x86服务器CPU。操作系统和驱动保持同一套版本避免软件栈差异干扰结果。需要说明的是具体数值会随硬件型号、驱动版本、模型结构不同而变化但优化趋势是稳定的专用框架比通用框架快静态shape比动态shape快量化比非量化快。下面给出的数据是参考样本重点看相对差距不用纠结绝对值。3. 几类主流推理框架各自靠什么提速3.1 通用型框架灵活优先性能靠后PyTorch的即时执行模式是最典型的通用型推理路径。它让你想怎么写就怎么写前向逻辑、条件分支、动态循环都能很好支持代价是对每个算子都做独立分发和执行缺乏全局视角性能自然吃亏。PyTorch官方也知道这个问题所以推出了TorchScript和Inductor这两套补课方案。TorchScript把模型转成静态图和中间表示Inductor走的是编译式路线会针对不同后端生成更高效的执行代码。这两者相比即时执行有收益但和专用推理引擎相比仍有距离因为它们必须兼容PyTorch庞大的算子生态无法针对某个特定GPU做太深层次的优化。3.2 图优化框架把计算图重新编排ONNX Runtime是这一类框架里最常见的代表。它先把模型统一转换成计算图然后做常量折叠、算子融合、维度推导等一系列图优化再针对不同硬件后端选择合适的执行单元。它支持CUDA、CPU、OpenVINO等多个执行提供程序所以特别适合做跨平台部署时的中立底座。图优化框架的优势在于不绑定单一硬件你可以用同一套转换流程对接不同设备。缺点也很明显它只能做相对通用的优化对于那些只有特定硬件才能启用的深度优化比如某些私有指令集、专用算子库它覆盖不如原厂方案彻底。3.3 深度优化框架专为特定硬件打造TensorRT是深度优化路线的代表它只针对特定GPU做优化包括层融合、精度校准、内核自动选择、显存池规划等一整套手段。带来的好处是性能释放非常彻底坏处是转换流程复杂模型需要经过engine生成、序列化保存等步骤而且一旦输入shape变化优化效果就会大打折扣。OpenVINO则主要针对x86 CPU和集成显卡做优化。它利用CPU的SIMD指令集、多核调度等手段能在不更换硬件的前提下把CPU推理速度拉高一大截。在很多“服务器只有CPU又不想上GPU”的场景里OpenVINO属于性价比极高的选择。这类专用框架的共性风险是绑定特定硬件厂商一旦你的部署环境发生变化整套优化方案可能要推翻重来。3.4 端侧与大模型场景的特殊选手端侧部署里常见的是TFLite和Core ML它们侧重量化压缩、端侧硬件加速器适配、内存占用控制目标是在手机和嵌入式设备上把模型塞进有限的内存并保证实时性。大模型在线服务里vLLM、llama.cpp这些框架则专注于KV Cache管理、连续批处理、量化推理解决的是长序列和并发场景下的显存碎片与重复计算问题。这些框架和通用框架解决的问题不同所以性能对比时不能只拿延迟说事。端侧要看包体积和功耗大模型服务要看吞吐和最大并发长度。把它们放在同一张表里比较没有太大意义。类别代表性框架核心提速手段主要场景通用动态图PyTorch即时执行灵活执行便于快速验证开发调试、后训练推理图优化ONNX Runtime计算图优化、多后端执行单元跨平台通用服务深度优化TensorRT、OpenVINO层融合、量化、显存规划、指令集优化特定GPU或CPU性能调优端侧轻量TFLite、Core ML量化压缩、硬件加速器适配手机、嵌入式设备大模型服务vLLM、llama.cppKV Cache复用、连续批处理大模型在线推理4. 一组横向实测数据延迟、吞吐和显存的真实差异4.1 GPU上的结果专用框架的领先幅度有多大在GPU上我用同一份模型权重分别走了PyTorch即时执行、ONNX Runtime加CUDA执行单元、TensorRT三种链路精度统一为FP16batch1。结果如下框架FP16batch1P50延迟(ms)P99延迟(ms)吞吐(FPS)峰值显存(GB)加载耗时(s)PyTorch即时执行8.511.21161.43.2ONNX Runtime CUDA6.89.11471.11.5TensorRT FP164.35.62300.95.8TensorRT INT82.12.94280.76.2只看P50延迟TensorRT FP16比PyTorch即时执行快了约1倍INT8下能拉开到4倍ONNX Runtime居中。这个结果不意外TensorRT把静态shape、层融合、显存规划这些手段全部用上了而PyTorch即时执行还停留在逐个算子分发的阶段。显存方面TensorRT的优势同样明显。因为它把整张计算图的中间张量都规划进同一块显存池PyTorch即时执行则在运行时要频繁申请和释放显存峰值自然更高。如果你的服务需要多个模型实例并发这个差距会直接影响单卡能容纳的实例数。4.2 CPU上的结果OpenVINO到底快在哪里CPU测试使用同一份模型但换成FP32精度batch1对比ONNX Runtime CPU执行单元和OpenVINO框架FP32batch1P50延迟(ms)P99延迟(ms)吞吐(FPS)加载耗时(s)ONNX Runtime CPU42.353.8230.9OpenVINO CPU26.834.5371.2OpenVINO在这套CPU上比ONNX Runtime快了约57%。原因在于它针对CPU指令集做了专门的内核级优化并且把一部分图优化直接落到了CPU执行路径上。模型越深、算子越碎这个差距往往越明显。如果你的业务跑在纯CPU环境花时间把OpenVINO跑通回报通常比换机换卡更直接。4.3 意外发现加载耗时可能成为真正的瓶颈这一轮测试里最容易被忽略的是加载耗时。PyTorch即时执行加载一个模型只要3秒出头TensorRT生成并反序列化engine却要5到6秒。如果你做的是函数计算或自动扩缩容服务冷启动阶段频繁出现加载耗时直接决定你的尾延迟和扩容速度。我见过不少团队在这上面栽跟头模型本身推理很快但服务弹起来太慢一波流量峰值进来所有新实例都在那边慢慢初始化最终大量请求超时。解决思路有两个一是用常驻进程池规避冷启动二是把engine序列化缓存到本地启动时只做反序列化而不是重新构建。如果都不行那就老实评估ONNX Runtime这条更快启动的链路。5. 为什么快算子融合、内存复用与精度校准的底层逻辑5.1 算子融合少搬一次数据就是赚到以常见的卷积批归一化ReLU为例在PyTorch即时执行下会分别执行三个内核每个内核都要读一遍输入、写一遍输出。融合后的内核只读一次输入、写一次输出中间多出来的数据搬运全部消除。别小看这一步在显存带宽受限的模型里融合优化带来的收益可能超过30%。这个原理放到日常里很好理解你做饭时如果每切一种菜就洗一次刀、放回刀架再拿出来时间全浪费在反复取放上。算子融合就是把这些步骤并成一道流程刀一直在手上切完直接下锅。模型推理的瓶颈很多时候不是计算单元不够快而是数据在内存和缓存之间搬运太慢。5.2 静态shape下的显存规划为什么能省出那么多显存TensorRT能大幅压低显存核心是静态shape下的显存规划。当你告诉框架输入永远是224x224、batch永远是1时它可以在构建阶段把整张计算图所有中间张量的大小预先算出来然后统一放进一个足够大的显存池里循环复用。PyTorch即时执行做不到这一点因为它在运行时才知道每个张量的尺寸只能依赖缓存分配器频繁申请和释放。这种动态分配会带来两个问题显存峰值被抬高、分配耗时不稳定。所以很多情况下即使算力吃满显存占用依然不低其实是内存复用机制没有做到位。5.3 INT8量化不是简单把权重数值缩小TensorRT的INT8量化需要一批校准数据让框架统计激活值的分布再挑选合适的量化阈值。校准集选得不好精度会崩。很多人部署时只对比了FP16和INT8的加速比却忘了检查量化后的精度是否仍然满足业务要求。我见过一个检测模型量化后mAP掉了8个点排查半天发现校准集是从训练集里随便抽了几十张完全覆盖不了真实场景中的光照和遮挡变化。更稳妥的做法是先对整个模型做敏感性分析找出对量化最敏感的若干层把这些层保留在FP16精度其余层走INT8。这种混合精度方案在精度和速度之间取了一个很好平衡点。灰度阶段可以用线上真实流量校验量化效果确认没问题再逐步放大比例别一上来就把全量切过去。除了上面三点自动内核搜索、算子调度顺序优化、多流并发也都会影响最终性能。框架之间的差距往往不是某一个优化造成的而是一整套优化互相叠加的结果。这也是为什么专用框架的优化很难在通用框架上复现——整套机制的每个环节都咬合在一起。6. 选型不是单选题不同业务场景下的框架取舍6.1 云端GPU延迟敏感场景TensorRT仍是首选如果业务是实时人脸识别、语音交互这类延迟敏感场景且你的硬件环境可控TensorRT是目前能把单卡性能压榨到极限的选择。前提是模型结构稳定、输入尺寸固定并且团队能接受较长的engine构建时间和一定的学习成本。不想被单一厂商绑死的话ONNX Runtime加CUDA执行单元是很好的折中方案。它能吃到一部分图优化红利又保留动态shape能力切换成本也低。对大多数中小团队来说先跑通ONNX Runtime往往比直接啃TensorRT更实际。6.2 CPU推理与边缘部署优先考虑指令集和功耗在x86 CPU上OpenVINO常常是性价比最高的选择在ARM设备或者端侧硬件上TFLite或硬件厂商自带的SDK通常更合适。CPU推理的一个原则是优先选择能够充分利用多核和指令集的框架而不是单纯比谁的算子实现更花哨。边缘部署还要额外关注功耗和内存带宽。很多边缘设备算力有限一旦某个框架的峰值内存过高可能连模型都加载不进去。我建议在选型阶段就把峰值内存纳入考核项并且用设备上真实可用的内存来测试不要只盯着推理延迟。6.3 大模型服务与Serverless冷启动和连续批处理是主题大模型在线服务里传统推理框架在长序列和高并发下会暴露出显存碎片和重复KV Cache计算的问题。vLLM这类连续批处理框架能把吞吐拉高一个量级因为它允许请求动态加入和离开同时共享KV Cache的显存管理。如果你的业务是ChatBot、智能客服这类场景值得认真调研。Serverless场景则要重点权衡冷启动。大模型本身的权重大加载耗时本来就不低如果再叠加一个缓慢的engine构建过程扩容基本等于自杀。建议把engine序列化好放进镜像或使用能快速加载的格式让服务和推理链路都做到秒级拉起。6.4 一个通用的选型流程我实际项目中常用的选型流程是这样的先确定部署硬件和精度要求然后用PyTorch即时执行跑一个简单基线记录延迟、显存、吞吐三个指标接着尝试ONNX Runtime作为中间层看能否满足需求如果还不够再上硬件专用框架针对静态shape和量化做专项调优每做一步改动都回归精度指标别只看性能数字。这套流程的核心理念是渐进式优化。你永远不会在第一步就获得最佳性能但也绝不会一上来就陷入某个框架的复杂配置里无法抽身。先把能用的方案跑通再逐步压榨性能才是绝大多数团队最稳妥的路线。7. 调优路上值得记录的三个隐蔽坑7.1 坑一第一次推理慢不代表框架慢很多人随手拿第一个请求的耗时当作框架性能这是典型的误用。GPU推理第一次调用会触发CUDA上下文初始化、内核模块加载PyTorch还会在第一次调用时做自动调优耗时可能比稳定态高出10倍以上。如果你拿这个数字去做选型很可能把一个本来很优秀的框架直接否掉。正确的做法是先预热10到20次等到显存分配稳定、内核缓存加载完毕再开始采样。我自己在评测时还会额外加上一条只统计连续推理的中位数并且把第一次推理的耗时单独记录为“冷启动耗时”而不是混进延迟统计里。冷启动是另一个问题它有自己独立的优化手段不该和稳态性能混为一谈。7.2 坑二动态shape会让静态优化全部失效我在一个模拟项目里见过这种情况模型在训练时输入尺寸可变上线时没固定shape结果TensorRT转换后虽然能跑但延迟不仅没降反而因为重复构图比ONNX Runtime还慢。TensorRT这类专用框架的优化前提是“已知所有张量尺寸”一旦shape漂移它要么退回动态执行路径要么重新生成内核优化收益大幅缩水。解决方法是在预处理阶段把输入统一补齐到某个固定尺寸比如把不同长宽比的图片都pad到同样大小。这样虽然多了一些无关计算但能换来专用框架完整的静态优化路径总体收益通常远大于损失。如果是目标检测这类batch和图片尺寸都变化的场景建议明确告知框架允许的shape范围而不是放任它每次都做动态推导。7.3 坑三量化精度退化别只怪框架INT8量化后精度下降很多人第一反应是框架的量化算法不够好。实际上大多数问题出在量化校准集和模型敏感层上。如果校准图片数量不足、分布偏差大量化阈值就会选偏精度自然受损。我现在的习惯是量化前先做敏感性分析把所有层逐层换成INT8观察精度变化找出最敏感的若干层。那些层的权重和激活值分布往往非常集中强行量化会切掉大量信息不如保留FP16。混合精度方案在工程上比全INT8更可控。另一个常用手段是量化后做几轮小学习率微调帮模型适应量化后的数值范围这种方法在不少任务上都能把精度损失压回1个百分点以内。上面这三个坑我在实际项目里都踩过而且踩得很深。回头来看推理框架性能分析这件事最重要的不是背下谁比谁快几倍的数据而是建立一套自己的评测流程控制变量、先跑基线、再逐步加深优化。把基线数据记录下来每一次改动都拿数据说话这样即便换了模型、换了硬件你也能快速找到最适合自己的方案。最后再分享一个小技巧在做框架对比时我会把每次构建的engine缓存下来同时在代码里保留一条ONNX Runtime的回退路径。这样即使TensorRT在某个新模型上出现诡异问题排查期间也可以秒级切回通用路线不影响线上服务。性能优化的前提永远是稳定性先活着再变快。