同一份模型在服务器上跑得好好的切到边缘盒子就卡成幻灯片换成 INT8 之后显存和延迟双双降下来了但精度也跟着掉了业务方直接过来拍桌子。这两年我反复被同一个模型该用什么精度、配什么硬件这个问题找上门。问的人从算法工程师到硬件工程师都有方向却出奇一致大家都默认精度和硬件是两个独立环节先训练收敛、后买机器部署结果就是两头难受。实际工作中精度选择与硬件配置必须放在一起决策而不只是把模型导出成 ONNX 就完事。这篇文章我想把这件事拆开讲清楚精度的本质是什么精度如何反过来决定硬件档次以及当你手头已经有一个训练好的模型时应该按怎样的顺序去定精度、选硬件、做实测。内容偏向实际部署场景包括云端推理、边缘盒子和嵌入式设备适合正在做模型落地部署的算法工程师、硬件工程师以及准备搭一套本地推理环境但不知道从哪里入手的开发者。文章里不会有太多公式更多是经验和踩坑记录。1. 精度不是玄学弄懂数据类型才知道硬件在忙什么1.1 FP32、FP16、BF16、INT8到底差在哪精度这个词在模型部署语境里指的是权重和激活值在计算机里的存储格式也就是用多少个 bit 表示一个数。最常见的是这几种FP32 用 32 位存一个浮点数FP16 用 16 位BF16 也是 16 位但指数位更多INT8 用 8 位存整数。我习惯用一个类比来理解FP32 像一张未压缩的 RAW 照片细节完整、文件巨大FP16 和 BF16 像是高质量 JPEG肉眼几乎看不出区别但体积减半INT8 更像是压缩过度的网络图体积只剩四分之一细节有损失但轮廓还在。这里的损失不是随机的。FP16 用更少的位去表示浮点数它的指数范围和尾数精度都缩水了对于像 1e-8 这种很小的数值直接就没法精确表达训练时梯度回传容易出现下溢。BF16 是把尾数位砍掉保留和 FP32 一样的指数范围所以大数不会溢出小数的精度则变差这正好适配训练场景中梯度的范围比精度更重要这件事。INT8 则彻底放弃小数把连续的浮点数值按照一定缩放因子映射到 -128 到 127 的整数区间这个映射过程就是量化也是部署时精度波动的主要来源。这些不同格式不只是文件大小的区别它们直接影响硬件内部的运算单元。GPU 里的 TensorCore 对 FP16 和 INT8 做了专门优化算力往往是 FP32 的好几倍甚至十几倍。同样的一个卷积算子数据从 FP32 换成 FP16显存传输量减半换成 INT8减到四分之一。传输带宽在很多场景下是比算力更先触顶的瓶颈所以精度降一级效率提升是实实在在的。1.2 精度直接决定硬件“跑不跑得动”很多人以为硬件选型就是看 GPU 型号、看算力数字大小实际上更要紧的是看你需要的精度格式是否被硬件原生支持。不同硬件对精度的支持差异极大这是选型中最容易被忽略的一点。拿 NVIDIA 的 GPU 举例消费级的 RTX 系列对 FP16 支持得不错但对 BF16 的支持就要看具体架构专业卡 A100 对 FP16、BF16、INT8 都有专门优化的 TensorCore但真正跑 FP32 的算力反而只有 FP16 的十几分之一。也就是说如果你希望用 FP32 跑训练买 A100 并不会比买一块便宜的消费卡快多少因为 A100 的强项根本不在这里。反过来如果模型被量化成 INT8 再去做推理一张支持 INT8 TensorCore 的专业卡能把吞吐推到很高的水平但同一张卡如果用 CPU 去跑同样的量化模型反而比 FP32 原生计算还慢因为 CPU 对 INT8 的 SIMD 指令优化和 GPU 完全不同。嵌入式设备上这个差异更明显。很多边缘盒子用的是带 NPU 的 SoCNPU 通常只接受 INT8 或者 INT16 的输入如果你准备了一个 FP16 的模型塞进去要么跑不起来要么被编译器在后台悄悄转成 INT8精度怎么样你完全不知道。所以模型是什么精度和硬件支持什么精度这两条线必须对齐否则再好的卡、再准的模型都是空中楼阁。1.3 三把尺子量精度需求显存、吞吐、精度损失我在给模型定精度时只看三个指标显存占用、推理吞吐、精度损失。这三项不是并列关系而是互相制约的最后要回到你的业务场景去权衡。显存占用最直接一个 FP32 的权重占 4 字节FP16 占 2 字节INT8 占 1 字节。一个 70 亿参数的模型FP32 光权重就要 28GB 显存FP16 降到 14GBINT8 只要 7GB。如果目标设备只有 8GB 显存那你不用纠结INT8 基本是唯一选择或者需要配合模型分片和 CPU offload。推理吞吐方面精度越低单位时间处理的数据量越大这在在线服务场景里直接决定你能不能扛住并发流量。精度损失则是最难量化的它取决于模型本身对数值扰动的敏感程度需要实测校准集才能知道。这三把尺子没有统一标准答案但有一个大原则带宽吃紧、算力有冗余的时候压精度效果立竿见影算力是短板、带宽充足的时候调精度帮助有限这时应该换硬件。我见过一个项目模型从 FP16 切到 INT8 后吞吐涨了三倍因为那个部署环境卡在了显存带宽上也见过一个场景切了 INT8 后性能几乎没变化因为瓶颈是 GPU 核心算力这时候就需要重新考虑硬件档次。2. 典型场景搭配方案按精度推硬件才能少走弯路2.1 云端训练BF16/FP16混合精度成标配训练场景的第一目标是模型收敛所以精度选择首先要保证数值稳定性其次才是速度。现在主流方案是混合精度训练权重保持 FP32 主副本前向和反向计算用 FP16 或 BF16梯度累积和更新则回到 FP32 完成。这套逻辑听上去复杂实际工程里通常只需要在训练框架里打开 AMP 开关剩下的由框架自动处理。BF16 在 Ampere 架构之后的 GPU 上特别好用因为它保留 FP32 的指数范围训练时不需要像 FP16 那样频繁做损失缩放。如果你的 GPU 不支持 BF16那就用 FP16 配合动态损失缩放绝大多数场景也能稳定收敛。硬件选型上训练卡一定要看 FP16/BF16 的混合精度算力而不是 FP32 的纸面数字。举个例子A100 的 FP32 算力是 19.5 TFLOPS但 BF16 TensorCore 算力能到 312 TFLOPS差距超过 15 倍。你花同样的钱如果只跑 FP32其实就是买了一台速度平庸的机器。所以做训练的同学选卡时别只盯着显存大小TensorCore 的混合精度指标才是关键。H100 上 FP16/BF16 的算力比 A100 翻倍但如果你模型小、训练数据量不大实际训练收益未必明显这时候把预算投到更多卡上做数据并行也许更划算。2.2 云端在线推理适合用FP16打底再按需压成INT8推理场景与训练不同模型已经收敛我们追求的是「在保证业务指标的前提下让延迟和成本尽可能低」。云端在线推理我通常从 FP16 起步而不是直接上 FP16。原因有两点FP16 直接使用 TensorCore吞吐可观部署零成本模型的精度损失微乎其微一般不会触发业务告警。之后再根据实际压测结果决定要不要压成 INT8。压 INT8 的收益在显存带宽高、单次推理 batch 较大的场景里特别明显。比如同一个 BERT 类模型FP16 在 L4 卡上可能跑到 50ms 延迟INT8 能压到 20ms 以内同时并发能力翻倍。这时候要做的不是全模型一刀切量化而是先 pprofile 一下哪些层对量化敏感哪些层可以安全转 INT8做混合精度部署。云端推理卡选择上T4 是一个很经典的入门方案FP16 算力和 INT8 算力都够用价格便宜适合中小流量。L4 是 T4 的继任者INT8 算力提升明显。如果流量特别大、成本敏感可以考虑专门为推理设计的卡往往在 INT8 和稀疏化上有额外优化。选卡的核心指标除了算力还有显存带宽和 PCIe 带宽因为在线推理通常是小 batch 高并发输入数据搬运开销占比高。2.3 边缘盒子与工控机算力、功耗、成本一起卡边缘部署的约束条件比云端复杂得多。工控机、边缘盒子往往要面对有限的散热条件、固定的功耗上限还有每台设备几百到几千元的成本预算。这时候精度越高越好是行不通的因为 FP16 或 FP32 在低功耗设备上很难发挥优势反而是「INT8 专用 NPU」的组合更能兼顾实时性与功耗。以 Jetson 系列为例Orin Nano 的 INT8 算力标称 40 TOPS跑 YOLOv5s 级别的检测模型能做到几十毫秒一帧功耗却只有 7W 到 15W。如果换成 FP16同等功耗下吞吐量会掉不少虽然精度更高但很多业务场景根本不需要那么高的精度。相比之下用普通 x86 工控机的核显跑同一个模型性能差距会非常明显这也是为什么边缘设备在部署 CV 模型时普遍选择量化模型 NPU 路线。在工控机上用 CPU 推理也是常见场景这时 OpenVINO 这类工具链能把 INT8 模型变成 CPU 上效率还不错的部署方案。但要注意CPU 的 INT8 加速依赖 AVX-512 VNNI 等指令集老旧的工控机 CPU 如果指令集不支持量化模型反而更慢。所以选工控机之前先把指令集支持情况查清楚再决定是走 GPU、NPU 还是纯 CPU 方案。2.4 MCU级嵌入式精度要给编译器让路再往下走就是单片机层面的部署比如 STM32、ESP32 这类资源以 KB 计的 MCU。这个层级做深度学习部署INT8 都不算小很多场景要用 INT4、INT8 混合以及极端权重裁剪。精度的选择不再完全由你决定更多是编译器工具链决定比如 CMSIS-NN 对 FP16 和 INT8 的支持就很不一样某些算子只提供了 INT8 的优化汇编实现。在这个层级选硬件最核心的是看两个指标Flash/RAM 容量和算力是否匹配你的模型压缩后的大小。一个典型的语音唤醒词模型量化到 INT8 后大概几十 KB可以在主流 MCU 上流畅运行但如果你为了保精度坚持用 FP16模型体积翻倍可能就塞不进 Flash 了还可能出现推理一帧耗时超过实时要求的场面。MCU 选型通常需要在模型结构设计阶段就并行开展先跑通一个小模型验证算子支持情况再逐级加大模型规模而不是最后突然丢一个完整模型给硬件工程师。3. 实操流程给一个模型选精度、配硬件的完整步骤3.1 先量化模型的“底子”我接手的第一个部署项目上来就直接用默认配置把模型转了 INT8测完发现精度崩了才回头去查模型结构。后来我养成了先做模型体检的习惯先统计参数量、FLOPs、每个算子的占比再跑一次标准推理看各层输出的数值分布。这一步的意义在于不同模型对量化的容忍度相差极大。以 YOLOv5s 为例参数量约 7.2MFP32 权重约 28MBFLOPs 约 16G。这种模型结构里 Conv 层占比高量化友好但如果模型里存在大量 LayerNorm、Softmax、SiLU 激活这类非线性和归一化操作INT8 量化后误差可能被放大。具体判断标准是看各层输出的均值和方差如果某个特征图的数值跨度过大就需要保留 FP16 混合层。跑这种体检不需要写复杂代码用 PyTorch 的 hook 把每层输出记录下来算一下 min、max、mean、std 就够了。重要的一步是在多个真实样本上统计别用网上随便下载的测试集因为部署后的数据分布一旦和训练集差异大校准出来的量化参数完全不可用。3.2 用业务容忍度反推目标精度模型体检完成后下一步是明确业务能承受的精度底线。我一般会先和业务方约定一个可接受的指标衰减范围比如某个视觉检测任务的 mAP 下降不能超过 0.5%或者 PTQ 之后错误率不能超过 1%。有了这个公差才能确定能不能压到 INT8还是必需保留 FP16。如果指标衰减在可接受范围内优先用训练后量化 PTQ如果 PTQ 精度损失超标再考虑量化感知训练 QAT。QAT 需要把量化误差前向模拟进训练流程成本高但往往能把精度拉回甚至超过 PTQ 的水平。不过 QAT 也不是万能的有些模型结构本身就对量化极不友好比如包含大动态范围的 attention 权重即使 QAT 也救不回来这时候只能做混合精度部署敏感层保持 FP16非敏感层用 INT8。我在实际操作中还会做一个反向验证把目标设备选好之后先跑一版全 FP16 的模型作为性能基线再跑一版全 INT8两者对比。这样既能看出精度损失也能看出性能提升再根据业务侧重点取一个中间组合。别一口气把模型压到底给自己留一点调整余地。3.3 预算算力从FLOPs到TOPS模型确定之后就可以粗算部署所需的硬件算力了。以一次前向推理的 FLOPs 为基数乘以目标帧率或吞吐要求再加上约 20% 的冗余可以得到所需的算力总量。比如 YOLOv5s 一次推理约 16 GFLOPs如果要求实时处理 30 FPS那么算力需求约为 16 × 30 480 GFLOPS也就是 0.48 TFLOPS。听起来不高任何一块专业卡都能满足。但这只是理想情况。实际部署要考虑内存带宽、I/O 开销、后处理耗时以及多路并发时的资源竞争。我测算时会先定一个目标时延比如单帧 30ms然后反推需要多大算力和带宽。更可靠的方法是直接在小规模硬件上做原型测试用 Profiler 看算子耗时分布找出瓶颈算子再决定是换硬件还是调整模型。表格对照一下不同精度下的算力需求这里 GFLOPs/TOPS 均为峰值指标实际效率不同精度显存占用/权重相对吞吐典型硬件示例适合场景FP324 字节/参数1xCPU、普通 GPU训练主副本、CPU 调试FP162 字节/参数2x 以上T4/L4/A100云端推理、混合精度训练BF162 字节/参数2x 以上Ampere/Hopper 系列大规模训练INT81 字节/参数4x 以上Jetson Orin、L4、A100 TensorCore边缘推理、高吞吐在线推理INT40.5 字节/参数更高但支持有限专用 NPU、部分 ARM 平台极致边缘场景3.4 实测验证的两组关键数据纸上算完不代表完事最终决策要靠实测。我特别建议把硬件借来或租来跑一周而不是只看厂商规格表。重点记录两组数据单次推理时延含预处理和后处理和持续吞吐batch1 和 batch32 各一组。时延决定用户体验吞吐决定成本两者往往不可兼得。实测时一定要做热身和多次采样因为很多硬件存在冷启动阶段第一次推理包含模型加载和 CUDA 上下文初始化耗时会异常高。持续吞吐测试要跑够 5 分钟关注性能是否随时间衰减。如果性能逐秒下滑多半是撞上了功耗墙或温度墙这时需要关注散热设计和降频策略而不能只看峰值帧率。我还会顺便测一下 CPU 占用和内存带宽。很多项目换了加速卡之后性能上去了但 CPU 成了新的瓶颈尤其在做视频解码、预处理、后处理时CPU 占用率直接飙满导致整体延迟不降反升。部署方案里要把 CPU 侧的开销一并考虑进去。3.5 现场部署时的三个隐形约束算力、精度都对得上之后现场部署仍然会出问题我总结出三个特别容易忽略的约束。第一个是功耗和散热工业现场经常是密闭机柜夏天温度高盒子如果散热设计不到位模型推理性能下降可高达 30%我见过因为过热导致反复重启的项目。第二个是供电稳定性边缘设备经常接的是非标准电源功率不够时 NPU 或 GPU 会频繁降频性能波动非常明显。第三个是驱动和固件版本同一个 ONNX 模型配合不同的推理引擎版本性能差异可以达到 20% 以上。这些约束在实验室里都测不出来必须到现场跑一轮长时间稳定性测试至少连续运行 48 小时并且把性能曲线、温度曲线、功耗曲线都记录下来。别等到上线前一天才做压力测试那种情况下一旦出问题只能临时改方案代价极大。4. 常见问题与排查技巧实录4.1 量化后精度掉得离谱问题多半出在校准被问得最多的就是为什么我的模型一量化就崩。这类问题十有八九是校准集不对。校准集需要贴近真实部署场景的数据分布数量也不能太少我通常至少用 500 到 2000 张真实场景图片。如果只用 32 张网上找来的图片去做校准量化后的缩放因子根本不准个别层输出直接溢出精度掉得莫名其妙。还有一种情况是模型里有对动态范围特别敏感的层比如检测头的输出层量化误差被放大到最后的结果里。这时候不要整网量化把敏感层标记出来保持 FP16其余层用 INT8通常能把精度救回来。PyTorch 和 ONNX Runtime 都支持逐层设置精度类型步骤是先用校准集逐层记录输出范围找出可疑层再单独实验该层在 INT8 和 FP16 下的输出偏差最后选定混合精度方案。真遇到怎么调都救不回来的模型就考虑 QAT 或者直接换一个数值更稳定的模型结构别在部署阶段死磕。部署阶段改模型结构是最昂贵的选择所以模型训练前就要把量化友好的设计纳入考虑。4.2 硬件“支持”某种精度为什么还是跑不起来规格表上写着支持 FP16、INT8实际推理时却发现有些算子被强制跑在 CPU 上或者整个模型直接报错。这类问题的根源通常是算子支持矩阵差异。同样的精度不同框架、不同版本、不同硬件后端能跑的算子集合完全不同。排查方法三步走第一步把模型里的算子种类全部列出来第二步对照所选推理后端的支持矩阵第三步对不支持的算子做替换或拆分。常见的元凶包括动态形状、非标准激活函数、自定义算子。遇到这种情况我会先试着把动态维度固定比如把 batch 固定为 1通常能避开大量限制再不行就把自定义算子改写为框架内置算子的组合比如把 GELU 拆成乘法和 tanh。在嵌入式设备上这类问题更常见因为 NPU 的算子支持列表比 GPU 短得多。拿到盒子开发文档后第一件事就是查算子支持表必要时在模型结构设计阶段就避开不支持的算子比如某些设备不支持 softmax需要用乘法和 exp 改写。这些限制越早发现返工成本越低。4.3 Windows设备驱动签名与“硬件无法启动”类问题的处理边缘部署很多还是用 Windows 工控机常见的一个坑是驱动数字签名问题。在设备管理器里看到Windows 无法验证此设备所需的驱动程序的数字签名或Windows 无法启动这个硬件设备的提示通常发生在驱动安装不完全、系统更新导致驱动签名失效或者驱动版本和硬件不匹配的时候。这种情况不是模型选型错而是系统层面的驱动问题需要先解决硬件识别再谈推理性能。排查步骤一般是先在设备管理器里找到异常设备查看其状态码和错误详情然后在「高级启动」里选择「禁用驱动程序强制签名」模式安装带测试签名的驱动安装完成后重启看设备状态是否恢复。如果依然无法启动就要检查设备是否被其他程序占用或者是否有旧驱动实例残留在内存中卸载旧驱动、清理注册表残留再重装新版驱动。值得注意的是某些硬件加速卡在 Windows 系统下的驱动更新频率远不如 Linux生产环境稳定性反而不如 Linux所以我在做长时间无人值守部署时会优先考虑 Linux 发行版。驱动问题解决之后还要确认推理框架是否正确识别了设备。如果 CUDA、TensorRT 或 OpenVINO 报找不到设备多半是 SDK 版本和驱动版本不匹配升级驱动或降级 SDK对齐版本号就能解决。4.4 显存/内存不够用不一定是硬件买小了部署后出现显存溢出或为硬件保留的内存太大之类的问题我的第一反应不是换大显存卡而是看看显存和内存是怎么分配的。很多推理框架默认会为显存缓存预留大块空间多个进程同时跑时显存被瓜分殆尽CPU 侧频繁做内存拷贝也会造成大量内存占用。优化手段有几类一是复用显存缓存设置进程内缓存池避免每次推理都重新分配二是减小推理 batch把显存峰值降下来三是使用精度更低的模型四是关闭其他进程的 GPU 占用用 nvidia-smi 看看是不是有残留进程占着显存。云服务器上尤其常见之前跑的进程崩了但显存一直没释放新进程上来了就报 OOM把残留进程清掉就恢复正常了。如果确认模型本身太大显存真的不够可以考虑模型分片或 CPU offload把不参与当前计算的部分权重放在内存里按需搬运到显存。这样延迟会升高但模型总量可以远超显存容量。适合离线批处理场景不适合在线实时推理。4.5 并发一高就报“模型繁忙”先查这几处在线服务上线后并发一高就出现模型繁忙的报错这个问题的根源通常不在模型精度而在推理框架的资源管理设置。常见原因有GPU 显存被多个请求争抢推理服务设置了固定的最大并发数单次推理占用的线程数过多导致 CPU 核心被打满。排查思路是先看监控把时延曲线、GPU 利用率和请求失败率放到同一张图里对比。如果 GPU 利用率高但请求失败是算力不足考虑动态 batch 或增加实例如果 GPU 利用率不高但请求失败多半是 CPU 线程池不足或显存分配排队调整推理框架的并发参数就能解决。动态 batch 是一个很实用的优化技巧把多个请求合并成一个大 batch 推理GPU 吞吐能提升好几倍但要注意控制最大等待时间否则单个请求的时延会变高。推理服务的压测要模拟真实流量特征而不是简单打满固定请求数。真实流量有波峰波谷有不同输入尺寸缓存命中率也不同。我的习惯是先在测试环境用 1 倍峰值流量连续压测 12 小时确认各类指标都稳定再逐步放开线上流量。5. 最后说个实在的体会回头看我经手过的部署项目凡是顺顺利利上线的几乎都是提前把精度和硬件绑在一起做了规划。最顶不住的是那些模型已经训好、硬件已经买好只能硬凑的项目不是精度牺牲太多就是性能差强人意。所以我现在的习惯是训练阶段就预演一遍部署链路把目标精度、目标设备、目标时延都写下来训练时顺手做量化友好设计比如控制动态范围、避免过多非标准算子后面部署会省掉很多返工。另外一个容易被低估的点是精度和硬件的匹配不是一锤子买卖而是持续调优的过程。硬件驱动、推理框架、算子实现都在更新同一个模型同一个设备半年之后的性能表现可能和现在完全不同。建议每隔一段时间重新做一次精度-性能-场景三者的校准把新的收益及时吃进来。这个内容还可以继续扩展的方向是多模态模型、大模型的 KV Cache 压缩、投机采样等新技术对精度和硬件要求的变化但那是另一个话题了以后有机会再写。