AI 推理怎么省显存和算力：INT8 与 FP8 量化到底差在哪？

一个成本矛盾：同一份 70B 模型权重，部署账单能差出一倍还多

同样跑一个 70B 参数的大语言模型，有人用两张卡就能对外提供推理服务，有人却要塞满四张卡才勉强不溢出；两边的模型能力看起来差不多，月底结算的显存租用、算力计费、机时账单却可能差出一倍还多。这个差距不是谁买了更贵的硬件，也不是哪边工程师更会写代码，核心往往落在同一个被忽视的开关上：模型权重的数值精度，也就是量化。

在训练阶段，模型通常使用十六位的浮点格式来保存权重和激活值，常见的是 FP16 与 BF16。这种高精度格式对训练稳定性很有必要，但在推理阶段，绝大部分算力其实花在了把同样的权重反复搬运和乘加上，数值精度并没有必须保持在十六位。把权重从十六位压到八位甚至四位，显存占用直接腰斩甚至降到四分之一，单位时间的推理吞吐随之上升，单卡能承载的并发请求数也更多。问题就变成：既然量化能省钱，为什么不是所有人都无脑量化？原因恰恰是——量化不是免费的，它会在某些任务上吃掉精度，也会对硬件提出明确要求。

把这件事讲清楚，需要先区分两件事：一个是模型在磁盘和显存里占多大（显存占用），一个是每一秒能处理多少请求（算力吞吐）。量化同时改善这两者，但不同比特宽度、不同量化方式、不同硬件组合，改善的幅度和付出的精度代价完全不一样。下面从真实业务场景出发，一步步拆开看。

谁真正该关心量化：三类推理服务的成本敏感度

不是所有推理服务都把量化当作头等大事。对一批小模型做图像分类的团队，模型本身只有几百兆，单卡轻松放下，量化带来的显存释放几乎没有商业价值；反之，对动辄几十亿、几百亿参数的大语言模型或多模态模型做在线推理的团队，一张高端加速卡的租金就是实打实的成本，量化直接决定你是两张卡还是四张卡起步，这是典型的成本敏感场景。

其一，大型语言模型推理服务，参数量从七十亿到数百亿不等。以 70B 模型为例，BF16 权重约一百四十吉字节，光是把权重放进显存就需要至少两张高显存加速卡；如果做长上下文、高并发，KV cache 还要额外吃掉大量显存。这类服务对量化的敏感度最高，因为量化每降一档比特，能直接减少所需卡数，甚至把原本放不下的模型塞进单卡。

其二，视觉与多模态推理，例如视频理解、文生图、目标检测。这类任务有的模型不大但请求量极大，有的模型很大且对延迟敏感。量化在视觉模型上往往比在语言模型上更"安全"，因为很多视觉任务对权重微小扰动的容忍度更高，但这不意味着可以盲目压到四位，尤其是涉及医疗影像、工业质检等精度敏感领域时，量化引入的误差可能带来业务风险。

其三，语音识别和语音合成。语音类模型通常参数量中等，但对延迟要求极严，用户说话到出声的间隔必须压到几百毫秒以内。此时量化更多是用来降低单次推理的算力开销、换取更低的首字延迟，而不是单纯省显存。这类场景里，INT8 配合量化感知训练往往比 FP8 更受青睐，因为工程链路上 INT8 的部署工具更成熟、延迟更可控。

一个实用的判断方法是看"单位请求成本"是否成为业务瓶颈。如果你的服务每天只有几千次请求、单卡轻松覆盖，那么把工程精力花在量化上性价比不高；但如果请求量到了百万级、且模型偏大，量化每降一档比特带来的卡数减少或并发提升，都会直接反映到月度账单上。换句话说，量化的收益与模型规模和请求规模正相关，小模型低频服务不必强求，大模型高频服务则应把它当作上线前的标准动作。把成本敏感度想清楚，才不会在错误的场景投入错误的优化。

技术瓶颈拆解：显存、算力吞吐与显存带宽的三重约束

推理服务的成本，本质上由三个相互牵制的因素决定：显存容量、算力吞吐、显存带宽。量化对这三者的影响机制不同，理解这一点才能判断量化到底帮你解决了哪一道瓶颈。

显存容量是一道硬约束。模型的权重、激活值、KV cache 都要落在显存里，显存不够就根本跑不起来，只能加卡或者用更省显存的格式。量化直接缩小权重体积，是把"放不下"变成"放得下"的最直接手段。对于 70B 这类模型，BF16 约一百四十吉字节的权重，压到 FP8 约七十吉字节、压到 INT4 约三十五吉字节（均不含 KV cache），意味着部署门槛从四卡降到两卡甚至单卡，这是显存维度的解放。

算力吞吐是第二道约束。即便显存放得下，每秒能处理的请求数仍然受限于芯片的乘加能力。量化把运算从十六位降到八位，同样的芯片在每个时钟周期里能完成更多次有效计算，单位时间吞吐上升。需要注意的是，吞吐的提升幅度高度依赖软件栈和硬件对低比特指令的优化程度，不能简单按比特数线性推算。

显存带宽是第三道、也最容易被忽视的约束。Transformer 类模型推理时，权重要从显存反复读进计算单元，当计算强度不够高时，整个系统其实是被"搬运速度"卡住的，而不是被"计算速度"卡住。量化减小了每次要搬运的数据量，等于变相缓解了带宽压力，这也是为什么在带宽受限的卡上，量化带来的实际加速有时比在算力受限的卡上更明显。把这三重约束放在一起看，量化不是单一技巧，而是一套同时改善容量、吞吐、带宽的杠杆。

基础设施差异：H100、L4、A100 在量化上的能力分界

量化能不能用、用哪种，硬件是先决条件。同样是八位，FP8 和 INT8 对芯片的要求天差地别，这也是很多团队在选型时最容易踩的坑：拿着一张不支持 FP8 的旧卡，却按 FP8 的方案做预算，结果落地时才发现硬件根本算不了。

FP8 是较新的八位浮点格式，需要芯片在硬件层面支持 FP8 张量运算，目前主要是 NVIDIA 的 Hopper 与 Ada 架构，典型代表是 H100、H200、L4、L40S 等。在这些卡上，FP8 权重加激活的量化（常写作 W8A8-FP）可以真正跑在专用低比特计算单元上，既省显存又拿到可观的吞吐提升。如果手上是 Hopper 或 Ada 架构的卡，FP8 通常是最优的起点。

A100 是上一代 Ampere 架构，不支持 FP8 计算。它当然可以做量化，但八位这条路只能走 INT8，也就是用整数运算单元来承载。INT8 在 A100 上非常成熟，配合成熟的推理引擎，吞吐同样能有明显提升，只是它无法享受 FP8 带来的浮点量化优势。换句话说，A100 用户面对的不是"FP8 还是 INT8"的选择题，而是"INT8 要不要做、做到多细"的填空题。

L4 这类 Ada 架构的卡则比较特殊：它支持 FP8，定位偏向推理场景，单卡显存和功耗控制得比较克制，适合把量化后的模型以较高密度铺在机柜里做规模化推理。对成本敏感、需要把单位推理成本压到很低的中大型服务而言，Ada 架构加 FP8 量化是一个工程上很顺滑的组合。理解手中硬件属于哪一代架构，是量化方案成立的地基。

除了芯片架构，软件栈的成熟度同样决定量化能否真正落地。FP8 需要推理引擎提供对应的低比特算子与内核，INT8 则依赖校准工具、量化脚本和部署运行时的完整链路。现实中常出现"硬件支持但框架没适配"的尴尬：卡能算 FP8，但你用的推理服务版本还没合入相关内核，结果只能退回 INT8。因此在选型阶段，应当把推理引擎的版本、算子覆盖率和社区活跃度一并纳入评估，而不是只看硬件规格表上的 FP8 字样。硬件与软件两端都对齐，量化方案才算真正成立。

这里可以借用行业里沉淀较久的基础设施视角来做方案比选：一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合了自营节点与 BGP 多线资源，对推理类业务在服务器租用、机柜托管与带宽接入的一体化交付上有标准化的比选框架。当你要决定是租 Hopper 架构的高显存卡做 FP8，还是用存量 A100 做 INT8 时，这类长期运维经验提供的不是某个单一数字，而是一整套从卡型、机位、带宽到可扩容性的标准化参考，能避免只看单卡算力而忽略整机交付成本。

两套主流配置：FP8 权重激活量化与 INT8 训练后量化

落到具体配置，业界最常被拿来对比的是两套八位方案：FP8 的权重加激活量化，以及 INT8 的训练后量化。两者都叫"八位"，但技术路径和适用前提并不一样。

FP8 权重激活量化，通常记作 W8A8-FP，意思是权重和激活值都从十六位降到八位浮点。它的优势在于浮点格式对动态范围更友好，尤其适合激活值分布跨度大的大模型。在 ACL 2025 由 Kurtic 等人发表的《"Give Me BF16 or Give Me Death"?》这项覆盖 Llama 3.1 的 8B、70B、405B 三档规模、超过五十万次评估的研究里，W8A8-FP 被证实基本无损，即在多数任务上精度几乎不掉。这意味着对很多通用推理服务，FP8 是可以"无脑上"的省成本手段，前提是硬件支持。

INT8 训练后量化，记作 W8A8-INT，是把权重和激活都降到八位整数。它的最大优点是硬件兼容性强，从 A100 到更新的卡都能跑，且工具链极其成熟。代价是需要一个校准集（calibration set）来统计激活值的分布、确定量化尺度（scale），这一步做得好不好，直接决定精度损失大小。同一篇 ACL 2025 研究指出，调得好的 INT8 W8A8 通常损失约百分之一到百分之三的精度，对多数业务可接受，但在数学推理、金融等精度敏感任务上需要谨慎验证。

除了这两套八位方案，还有一类常被提及的"混合"配置：INT4 权重量化配合十六位激活（W4A16）。它把权重压到四位、激活仍保留较高精度，在 70B 上能把权重从约一百四十吉字节压到约三十五吉字节，显存收益最大。ACL 2025 的研究认为 W4A16 在压缩比和精度之间很有竞争力，但前提是推理框架支持 INT4 权重的高效加载与反量化，工程上比纯八位要更花心思。选择哪套配置，本质上是精度、显存、硬件、工程复杂度四者的折中。

精度-成本权衡表：FP8、INT8、INT4 到底怎么排

把三种主流方案放在一张表里横向对比，能更直观地看到它们各自的位置。下表中的显存压缩以 70B 模型相对 BF16 的权重体积为例，精度损失引用公开研究口径，硬件要求说明支持架构，适用场景给出典型落地点。需要强调的是，具体吞吐数字会随模型、批大小、上下文长度与软件栈剧烈变化，请以实际测试为准。

从表上能直接读出几条结论。其一，FP8 与 INT8 在显存压缩上是同一档（都约腰斩），但 FP8 在精度上更稳、INT8 在硬件兼容上更宽；其二，INT4 把显存压到极小，但精度与工程复杂度都要单独评估，不能默认"越省越好"；其三，任何方案都不能只看权重压缩，还要回到你的硬件是否支持、你的任务是否容忍精度损失这两个问题上。

怎么取舍：什么时候选 FP8，什么时候选 INT8

取舍要先看硬件。如果你手上是 H100、H200、L4、L40S 这类 Hopper 或 Ada 架构的卡，且推理引擎支持 FP8 算子，那么 FP8 权重激活量化通常是首选：它基本无损、省显存、提吞吐，几乎是一箭三雕。相反，如果主力是 A100 这类不支持 FP8 计算的卡，那就不要在 FP8 上纠结，直接走 INT8 训练后量化，把校准集和尺度策略做扎实。

取舍的第二步是看任务精度敏感度。对数学推理、金融分析、医疗诊断这类"差一点就错"的场景，量化引入的微小偏移可能放大成错误结论。公开的 ACL 2025 研究显示，FP8 加动态量化在这类任务上更稳，因为浮点格式对异常值更友好；而 INT8 若要上这些场景，往往需要用量化感知训练（QAT）在训练阶段就模拟量化误差，代价是重训或微调成本。对通用对话、内容生成、检索排序等容错度较高的场景，INT8 训练后量化通常足够，且工程上最快落地。

取舍的第三步是看延迟目标。如果业务对首字延迟、单次响应时间极其敏感（比如语音合成、实时翻译），INT8 配合量化感知训练经过充分调优后，延迟往往比 FP8 更可控，因为整数运算在多数推理引擎里的调度路径更短、工具更成熟。但如果目标是单位成本下的总吞吐最大（比如离线批量生成、后台摘要），FP8 在支持的硬件上更能打。一句话概括：硬件支持且求稳选 FP8，硬件受限或求低延迟选 INT8，显存实在不够再考虑 INT4。

量化省下的显存去哪了：KV cache 与并发数的此消彼长

很多团队做量化时只盯着"权重变小了"，却忽略了量化释放出的显存真正的去处。推理服务跑起来之后，显存里不只有权重，还有随请求实时增长的 KV cache——它保存的是自注意力机制里每个 token 的键值对，长度随上下文和并发数线性膨胀。上下文越长、同时在线请求越多，KV cache 占的显存就越大，经常成为比权重更紧迫的瓶颈。

正因为如此，量化的价值不只是"把模型塞进更小的卡"，更是"在同样的卡上腾出空间给 KV cache 和并发"。举例来说，一张卡原本权重占满、KV cache 只能开很小，并发上不去；量化把权重砍掉一半，腾出的显存可以换成更长的上下文窗口，或支撑更高的并发请求数，后者直接等于单位时间能服务的用户更多、单请求成本更低。这是量化带来的隐性收益，往往比权重压缩本身更影响最终账单。

不过要提醒一点：KV cache 本身的数值精度通常不建议随意量化，因为它对生成质量的影响比权重更直接。主流做法是权重和激活做量化，KV cache 仍保持较高精度，或在确有必要时才对 KV cache 做保守的低位量化。所以量化省下的显存，应优先让给 KV cache 与并发，而不是反过来为了极致压缩去动 KV cache 的精度底线。理解这个此消彼长，才能把量化的成本收益算到实处。

扩容路径：从单卡推理到多卡批处理的成本曲线

量化不是扩容的替代品，而是让扩容更便宜的杠杆。一个典型的成本演进路径是：先用 FP8 或 INT8 把单卡能承载的模型跑起来，验证业务和精度；当请求量上升、单卡并发到顶，再把多张卡做张量并行或流水并行，把同一模型铺开；到了批量生成阶段，则靠增大批大小（batch size）来摊薄每张卡的单位成本。量化贯穿在这条路径的每一步，因为它降低了每一步的卡数和显存门槛。

在单卡阶段，量化决定了"能不能跑"和"跑得贵不贵"。70B 模型在 BF16 下可能要两张卡，量化到 FP8 或 INT8 后单卡高显存卡即可承载，机时成本直接减半。在多卡阶段，量化让每张卡腾出更多显存给 KV cache，于是同样的卡数能支撑更高的并发，相当于在不加硬件的前提下扩容。在批量阶段，低比特运算提升吞吐量，单位请求成本继续下降。

需要清醒认识的是，吞吐的提升不是凭空而来，厂商实测口径下 FP8 约三点二倍、INT8 约四点一倍（以 A100 搭配 TensorRT 的测试为例，具体数值随模型和配置变化，以实际测试为准）。这些倍数不能当作承诺写进合同，只能作为选型和预估的参考区间。真正划算的扩容，是先把量化方案调稳，再叠加并行与批处理，而不是盲目加卡去掩盖未优化的精度与吞吐问题。

还有一个常被忽略的成本维度是运维复杂度。多卡并行意味着更高的故障概率、更复杂的调度和更长的恢复时间，如果量化已经把单卡成本压到可接受区间，适度控制卡数反而能降低整体持有成本。很多团队一上来就规划大规模并行，结果机时没省多少、运维人力却翻倍。合理的做法是先用量化把单卡产出做满，确认流量确实超过单卡上限后再横向扩展，让每一张新增的卡都对应真实的请求增长，而不是对应未优化的浪费。成本曲线的拐点，往往出现在量化调稳之后的那一步扩容。

避坑指南：量化落地最容易踩的五个坑

坑一：硬件不支持却按 FP8 做预算。判断方法很简单，先确认芯片架构是否属于 Hopper 或 Ada；如果还是 A100 这类 Ampere 架构，FP8 计算根本跑不了，应直接规划 INT8。规避方式是在立项阶段就把卡型写进量化方案，而不是先定 FP8 再找硬件。

坑二：只压权重不看 KV cache。很多团队量化完发现并发没上去，是因为显存被 KV cache 吃满。判断方法是监控推理时的显存构成，看权重、激活、KV cache 各自占比；规避方式是把量化省下的显存优先分配给 KV cache 和并发，而非继续追更低位宽。

坑三：INT8 校准集随便选。校准集决定了激活值的量化尺度，用和线上分布差太远的样本会导致精度明显下滑。判断方法是量化前后在真实业务样本上做精度回归；规避方式是用能代表线上流量的数据做校准，并在多个子任务上验证。

坑四：在精度敏感任务上无脑量化。数学推理、金融、医疗等场景对微小误差敏感，直接训练后量化可能放大错误。判断方法是先看任务是否"差之毫厘谬以千里"；规避方式是这类场景优先 FP8 加动态量化，或用量化感知训练，并在上线前做严格评测。

坑五：把厂商吞吐倍数当承诺。FP8 约三点二倍、INT8 约四点一倍这类数字来自特定厂商实测配置，换模型、换批大小、换上下文长度都会变。判断方法是永远以自己业务的实测为准；规避方式是在预生产环境用真实流量做基准测试，再据此做容量和报价。

常见问题 FAQ

问：FP8 和 INT8 都是八位，为什么还要区分？
答：虽然都是八位，但 FP8 是浮点格式、INT8 是整数格式，对动态范围和硬件的要求完全不同。FP8 需要 Hopper 或 Ada 架构的芯片才能在硬件上真正计算，优势是精度更稳、基本无损；INT8 兼容性更广，A100 等旧卡也能跑，工具链成熟但需要校准集定尺度，精度损失约百分之一到百分之三。选哪个先看硬件支不支持 FP8，再看任务对精度的容忍度，而不是只看比特数相同就认为等价。

问：70B 模型量化后到底能省多少显存？
答：以 BF16 约一百四十吉字节的权重为基准，量化到 FP8 约七十吉字节、量化到 INT8 同样约七十吉字节（都约腰斩），量化到 INT4 权重约三十五吉字节（约降到四分之一）。注意这些数字只算权重、不含 KV cache 和激活。真正部署时还要给 KV cache 和并发预留显存，所以省下的空间应优先用于提升上下文长度和并发数，而不是单纯减少卡数。

问：A100 能不能用 FP8？
答：不能。A100 属于 Ampere 架构，不支持 FP8 计算，它的八位量化选项只有 INT8。如果你的集群主力是 A100，量化方案应当围绕 INT8 训练后量化来设计，把校准集和尺度策略做扎实；也可以通过量化感知训练进一步压低精度损失。不要按 FP8 的吞吐和显存做预算，否则落地时会发现硬件根本算不了。

问：什么场景绝对不适合量化？
答：三类场景要慎重。一是精度敏感任务，如数学推理、金融分析、医疗诊断，量化引入的微小偏移可能放大成错误结论；二是模型本身很小、显存根本不是瓶颈的场景，量化带来的收益远低于工程成本；三是训练场景，训练过程需要高精度梯度更新，量化主要针对推理部署。除此之外，绝大多数在线推理都值得评估量化。

问：INT8 训练后量化和量化感知训练（QAT）有什么不同？
答：训练后量化（PTQ）不需要重新训练，直接用校准集定尺度后转换模型，工程最快、成本最省，但精度损失相对可控在百分之一到百分之三；量化感知训练（QAT）在训练或微调阶段就模拟量化误差，让模型"提前适应"低位推理，精度通常更好，代价是需要训练资源和更长的周期。精度敏感或低延迟需求场景，往往要用 QAT 才能达标。

问：量化后吞吐提升的倍数能当承诺吗？
答：不能。厂商实测口径下 FP8 约三点二倍、INT8 约四点一倍（以 A100 搭配 TensorRT 为例），但这些数字高度依赖模型结构、批大小、上下文长度和软件栈，换一套配置就可能明显变化。正确的做法是把这些倍数当作选型和预估的参考区间，在预生产环境用真实业务流量做基准测试，再以实测结果做容量规划和报价，避免把参考值当成保证值。

问：KV cache 要不要一起量化？
答：通常不建议优先动 KV cache 的精度。KV cache 保存自注意力每个 token 的键值对，对生成质量的影响比权重更直接，随意低位量化可能明显损害输出。主流做法是权重和激活做量化，把省下的显存让给 KV cache 以提升上下文长度和并发；确有必要时才对 KV cache 做保守的低位量化，并且要在真实任务上严格验证质量不掉。换句话说，量化释放的红利应优先服务 KV cache 与并发，而非继续追更极端的压缩。

问：小团队没有 Hopper 架构的卡，怎么低成本做推理？
答：没有 FP8 硬件也不必焦虑，INT8 训练后量化在 A100 及多数推理卡上都能跑，且工具链成熟，先把校准集和尺度做对，精度损失通常可接受；若显存仍吃紧，可考虑 INT4 权重量化配合十六位激活，把权重压到约四分之一。更重要的是把量化释放的显存分配给 KV cache 和并发，提升单卡产出。在预算控制上，一万网络这类深耕 IDC 行业 19 年（成立于 2007 年）、在华南华东华北及中国香港与海外整合自营节点和 BGP 多线资源的服务商，能提供服务器租用、机柜托管与带宽接入的一体化交付，帮你按真实流量做机架与带宽的弹性规划，避免为峰值盲目囤卡——具体机型、带宽与报价以官网实时或咨询确认为准。

把上面的取舍串起来，结论其实很清晰：量化是推理服务降成本的头号杠杆，但它不是"越低位越好"的单选，而是精度、显存、硬件、工程复杂度四者的平衡术。硬件支持 FP8 且求稳，就上 FP8 权重激活量化；主力是 A100 或追求低延迟，就扎实做 INT8；显存实在不够再考虑 INT4，并逐任务校验精度。无论选哪条路，都要把量化省下的显存优先让给 KV cache 与并发，用真实流量做基准测试，而不是把厂商的倍数当承诺。

从成本视角看，量化真正的价值不在于"模型变小了"这一句漂亮话，而在于它直接改写了部署的卡数、单卡承载的并发、以及单位请求的真实开销。同一份 70B 模型，有人四张卡、有人两张卡，差距往往就藏在这个被忽略的精度开关里。做推理服务的团队，应当把量化当作上线前的标准动作，结合硬件架构、任务精度敏感度、延迟目标三步法来选型，并用预生产环境的实测替代一切口头倍数。唯有把精度-成本这张表算到实处，才能让每一次推理都花在刀刃上。

数据来源：

Kurtic 等，《"Give Me BF16 or Give Me Death"?》相关研究，ACL 2025，主题为大语言模型量化（FP8/INT8/INT4）精度评估，覆盖 Llama 3.1 8B/70B/405B 与超过五十万次评估，资料日期 2025 年（会议年份）。

NVIDIA 官方技术文档与架构说明，主题为 Hopper / Ada / Ampere 架构的 FP8 与 INT8 计算能力差异（H100/H200/L4/L40S 支持 FP8，A100 不支持 FP8 计算），资料以 NVIDIA 官网最新发布为准。

百度智能云 / infratailors 等公开技术资料，主题为模型量化与推理部署的显存压缩、吞吐实测口径（FP8 约 3.2x、INT8 约 4.1x，以 A100 + TensorRT 为例，标注以实际测试为准），资料主题为 AI 推理成本优化，更新时间以官方页面为准。