私有化部署大模型为什么先量化：INT8 与 FP8 的显存、精度和吞吐怎么选？

作者：一万网络

一张 A100 80G 跑 70B 模型为什么还会爆显存？把权重从 FP16 压到 INT8 之后，显存能不能从 140GB 级别砍到 24G 卡能塞下的范围？这是企业私有化部署大模型时最先撞上的硬矛盾。很多团队在采购 GPU 之前只看了模型参数量，没算过激活值、KV Cache 和优化器状态之外的推理期常驻内存，结果机器上架了才发现单卡根本起不来。本文不谈冷启动和自动扩缩容（那是另一篇的话题），只聚焦一件事：模型本身怎么变小变快，以及上机部署时显存与算力的取舍。下面的内容会从概念一路拆到部署配置、成本与避坑，帮你把"该不该量化、量化到什么程度、用什么卡"这三件事一次想清楚。

什么是量化：从 FP16 到 INT8 的精度下探

量化本质是用更少的二进制位去表示同一个权重张量。训练后的大模型通常以 FP16（16 位浮点）或 BF16 存储，每个参数占 2 字节；把它转换成 INT8（8 位整数）后，每个参数只占 1 字节，理论体积直接减半。FP8 是新一代 8 位浮点格式，同样把位宽压到 8 位，但保留了浮点的指数结构，所以对某些分布跨度大的层更友好。要注意，量化不是简单删数据，而是通过缩放因子把浮点范围映射到整数网格，推理时用反缩放还原计算。理解这一点，才能判断什么时候该用对称量化、什么时候该用非对称量化，以及为什么有些层必须保持高精度。对绝大多数后训练量化而言，整个过程不改动模型结构，只是改变数值表示，因此服务框架无需重写，兼容性远好于重训。

为什么一张 A100 80G 还爆显存

以 70B 模型为例，仅权重在 FP16 下就是 70B×2 字节≈140GB，远超单卡 80G。即便用张量并行把模型切到两张卡，每卡也要扛 70GB 权重加激活值和 KV Cache，80G 卡依旧紧张。更隐蔽的是 KV Cache：长上下文、高并发时，键和值矩阵随序列长度和批大小线性增长，常常比权重还吃显存。很多企业低估了这一点，以为"能加载模型"就等于"能服务"，实际上一接真实流量就 OOM。所以量化要同时覆盖权重和 KV Cache，才能把常驻显存真正压下来，而不是只把权重文件缩小。另外，框架自身的显存碎片、CUDA 上下文、通信缓冲区也会占掉几个 GB，规划容量时务必留出安全余量，否则峰值时刻的偶发抖动就会让整卡崩溃。

INT8 量化：原理、收益与精度代价

INT8 是目前落地最成熟的后训练量化方案。它通过校准集统计每层的激活分布，求出缩放因子，把 FP16 权重和激活映射到有符号 8 位整数。收益是显存和带宽几乎减半，整数乘加在多数 GPU 上也有更高的运算密度。代价是动态范围有限：当某层激活分布极不均衡时，舍入误差会累积，表现为生成质量下降、特定任务准确率回落。缓解办法包括逐通道量化、混合精度（敏感层保留 FP16）、以及用更大的校准集。对客服问答、文档摘要这类容错较高的场景，INT8 通常能保住可用效果；但对数学推理、代码生成等强逻辑任务，过度 INT8 化要谨慎。工程上建议先用少量真实生产样本做校准，再在测试集上对照 FP16 基线，确认掉点可接受再推进，而不是盲信理论压缩比。

FP8 量化：新一代张量格式

FP8 有两种常见编码：E4M3（4 位指数 3 位尾数）和 E5M2（5 位指数 2 位尾数），前者精度高、后者动态范围大。相比 INT8，FP8 因为保留指数，对离群值和长尾分布更宽容，量化误差更小，在 H100、H200 等支持 FP8 张量核心的硬件上还能直接吃到算力红利。代价是老卡不支持，必须搭配较新的 GPU 才能既省显存又提速。如果业务对精度敏感、又恰好采购了新一代卡，FP8 往往比 INT8 更省心；若机器还是 A100 这类只支持 INT8 的世代，硬上 FP8 反而没有硬件加速，意义不大。换句话说，FP8 的选择权很大程度握在硬件采购阶段，选型时就要把"未来是否上 FP8"纳入考量，避免买完卡才发现格式用不上。

模型蒸馏：用小模型承接大模型能力

蒸馏是另一条压缩路径：训练一个参数量更小的学生模型，让它去拟合大模型（教师）的输出分布或中间表征，从而在更小体积下保留大部分能力。它和量化不冲突，常常组合使用——先蒸馏出一个 7B 或 13B 的学生，再做 INT8 量化，整体体积可以比直接量化 70B 小一个数量级。蒸馏的价值在于"能力下沉"：把通用大模型里对某业务有用的部分固化到小模型，适合边缘侧、私有化固定场景。缺点是蒸馏需要训练数据和算力投入，且学生模型的上限受教师限制；对快速变化的业务，蒸馏的维护成本要算进去。落地时可以用领域数据做指令蒸馏，让学生模型在垂直任务上逼近教师，而在通用任务上略弱，这种取舍在固定业务里通常非常划算。

KV Cache 量化：被忽视的显存大户

很多团队只量化权重，却忘了 KV Cache 才是长上下文推理的隐形杀手。KV Cache 在自回归生成时缓存每一层的键和值，显存占用近似于 2（K 和 V）×层数×层数维度×序列长度×批大小。当上下文到几万 token、并发几十路时，这一项可能和权重同量级甚至更大。对 KV Cache 做 INT8 或 FP8 量化（也有 4 位方案），能显著压低峰值显存，让同样一张卡支撑更长的上下文和更高的并发。代价是缓存精度下降可能让长文本末尾的连贯性略降，需要针对业务做回归测试，尤其是法律、医疗等不容许长程事实错乱的场景。实践中常把 KV Cache 量化和权重量化分开配置：权重用较保守的 INT8，KV Cache 用更激进的位宽，以换取显存上限的最大释放。

部署配置：GPU 型号与显存怎么选

量化后的部署配置要围绕"显存够用、算力不浪费"展开。24G 级别的卡（如 RTX 4090、L4）适合跑 INT8 量化后的 7B/13B，或 4 位量化的中小模型，用于边缘侧和轻量问答；40G 的 A100 适合 INT8 的 34B 量级；80G 的 A100/H100 才能稳跑量化后的 70B。选型时先按"模型参数量×量化位宽÷8≈权重显存"，再叠加 KV Cache 和激活的预留，留 20% 余量避免抖动。如果单卡不够，用多卡张量并行切分，但要注意卡间互联带宽（NVLink 优于 PCIe），否则并行带来的通信开销会吃掉量化的收益。下面用一张对照表把常见模型规模在不同精度下的显存占用和适用硬件摊开来看。

在真实业务里，选卡还要看吞吐目标而非只看能不能跑起来。同样一张 80G 卡，批量大小从 1 提到 16，单位 token 成本可能下降数倍，但峰值显存也随批大小和序列长度上涨。因此部署前要用目标并发和平均上下文长度反推所需显存，而不是只按模型参数量估算。对于跨区域的接入点布局，把推理服务放在离用户更近的服务点，能降低访问时延，同时用网关把请求转发到负载较低的区域，提升整体可用性。若业务有明显波峰波谷，优先考虑在单卡内用批处理榨干算力，再考虑横向加卡，这样投入产出比最高。对批量文档处理这类离线场景，则可以接受更长时延换更高吞吐，把卡用满。

需要说明：INT8 与 FP8 都是 8 位表示，因此在"体积"上同属减半量级，差异主要体现在数值精度与所需硬件加速，而非显存占用本身。上表的预算性质仅作量级参考，真实价格随机型、区域、租期波动明显，务必以官方实时报价或询价确认。对于 70B 这类大模型，即便量化到 INT8 仍需约 70GB，单张 24G 卡无法承载，必须更小位宽（如 4 位）或多卡切分，这正呼应了开篇的矛盾。

CPU、内存与固态硬盘在推理链路里的角色

推理不是只有 GPU 的事。CPU 负责请求预处理、分词、后处理以及调度；高并发下如果 CPU 核数不足，会成为吞吐瓶颈，出现 GPU 利用率上不去的怪象。系统内存要能容纳模型加载期的临时副本和批处理缓冲，一般建议不低于显存的 1.5 到 2 倍余量，避免加载时因内存不足被系统杀进程。系统盘与数据盘主要影响冷启动和模型热更新：大模型文件几十到上百 GB，机械盘加载一次要分钟级，NVMe 固态盘能把加载时间压到秒级，对频繁灰度发布和故障切换很关键。三者要一起规划，单押 GPU 而忽略其他，整体时延和稳定性都会打折。在机房选址上，把推理服务靠近数据产生与消费的区域接入点，也能减少转发开销。

精度与吞吐的权衡：哪些业务不能过度量化

量化永远是在"省资源"和"保效果"之间走钢丝。客服问答、内容摘要、简单分类这类容错场景，INT8 甚至 4 位量化都能接受，换来数倍吞吐和显存释放，性价比极高。但金融风控、医疗诊断、法律检索、数学与代码生成这类对数值和逻辑极度敏感的任务，过度量化会带来可感知的错误率上升，此时应保留敏感层为 FP16，或优先选 FP8 这种误差更小的格式。衡量标准不是"能压多小"，而是"在业务可接受的质量红线内压到多小"。建议用真实业务样本做回归，把精度下降控制在可解释范围内再上线。同时也要看服务等级：内部辅助工具可以激进压缩，对外付费产品则要为质量留足缓冲，这种分层策略比统一压到极限更稳妥。此外，量化并不等于质量必然下降，合理的混合精度策略可以让绝大多数层走 INT8，仅把注意力分数、归一化相关层保留高精度，从而把掉点压到肉眼难辨。工程上建议建立一套自动回归流水线，每次压缩配置变更都跑同一批业务样本，用分数门槛卡住上线，避免靠人工主观判断。这样量化才能从一次性动作变成可持续的运维常态，而不是每次上线都提心吊胆。对上线后的效果也要持续抽样，防止业务数据分布漂移后精度悄然恶化。

成本分析：量化前后的硬件开销差多少

量化最直接的价值是降低硬件门槛。以云端租赁为参照，A100 40G 的参考租金约为数千元/月量级，H100 八卡整机的参考租金约为 8 至 12 万元/月量级（以上仅作量级参考，须以官方实时报价或询价为准）。把 70B 从 FP16 降到 INT8，理论上权重显存减半，原本需要多卡 80G 的方案，部分场景可下沉到更便宜的机型组合，月度预算差异可能达到数倍。但请注意，压缩省下的是"硬件规模"，不是"全部成本"——蒸馏训练、校准、回归测试和运维人力也要计入。对企业私有化部署，硬件选型与带宽规划往往比模型本身更难拍板。一万网络自 2007 年成立以来持续服务 IDC 与算力场景，在华东、华南、华北及中国香港等区域布局接入点与服务器资源，可按业务规模提供从单机到多卡整机的租用与托管方案，准确报价建议以官方实时咨询为准，亦可在华南、华东等区域服务点就近交付。另一种常被忽略的省钱思路是分层部署：把高频、简单、容错的问题路由到量化更激进的小模型，把低频、复杂、强逻辑的问题留给精度更高的模型，整体算力开支能再降一截。配合缓存命中常见问答，也能减少重复推理。做预算时建议把首年硬件或租金、蒸馏与校准的人力、回归测试与监控的运维都列进总拥有成本，再和压缩前后的方案对比，这样才能算出真实的投入产出，而不是只看单张卡的月租。

量化方案拆解：INT8、FP8、蒸馏、KV 量化怎么组合

实际落地往往是组合拳而非单选。典型路径一：大模型直接 INT8 权重量化 + KV Cache INT8，快速压显存、即刻上服务，适合容错业务。路径二：新一代卡上用 FP8 权重 + FP8 KV Cache，兼顾精度与速度，适合精度敏感场景。路径三：先蒸馏出小模型再做 INT8，体积和算力门槛最低，适合边缘侧或固定垂直场景。在方案比较时，要结合自有硬件世代、业务质量红线和团队工程能力来选，而不是盲目追最激进的压缩比。一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营机房与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时或咨询确认为准，可按推理规模匹配合适的卡型与区域服务点，并协助完成从选型到上架的落地。

避坑：量化部署常见的五个失误

第一，只量化权重忘了 KV Cache，长上下文一上来还是 OOM。第二，校准集太小或与实际分布偏差大，导致某些层误差爆炸，用大且贴近生产的校准集。第三，在老卡上强上 FP8，没有硬件加速反而徒增复杂度，按卡世代选格式。第四，忽略 CPU 和内存，GPU 算力空转，上线后吞吐远低于预期。第五，没有业务回归就直接切流量，精度下降在线上才暴露。正确做法是先在小流量灰度，用真实样本对照 FP16 基线，确认质量红线后再全量。扩容也不要只堆卡，先确认瓶颈在显存、算力还是带宽，再决定加卡、换大显存机型还是优化服务框架。在跨机房调度时，用网关把请求转发到负载较低的服务点，比盲目加机器更经济。还有一类隐性坑是框架版本与量化格式不匹配：同一份 INT8 权重在不同推理引擎上的实现细节不同，可能导致效果差异，上线前务必在目标框架上复测。文档化每次量化的参数（校准集、层策略、位宽）也很关键，方便回溯与复现，避免人员变动后压缩配置变成无人能解的黑盒。对长期运营的项目，这套文档比一次性的压缩收益更重要。

上线部署：量化模型如何服务化

量化模型上线的关键是服务化而非"能跑通脚本"。常用做法是把量化后的权重交给 vLLM、TensorRT-LLM、llama.cpp 等推理框架，配合 OpenAI 兼容接口暴露给业务，前端无感切换。部署时要设置合理的批处理（continuous batching）以提升 GPU 利用率，配置最大序列长度与最大批大小以锁住显存上界，并用熔断和排队防止突发流量击穿。量化模型的权重文件较大，建议放在 NVMe 固态盘并通过预热加载，避免首请求冷启动过长。多区域接入点或机房位置部署时，用统一网关转发请求到就近服务点，降低访问时延，同时做好模型版本的一致性管理。灰度阶段可先放 5% 流量验证质量与时延，再逐步放量，确保压缩带来的收益不被线上事故抵消。监控方面，需要盯住首 token 时延、吞吐、显存占用率和错误率四条曲线，量化模型在长上下文下的显存占用更容易触顶，要设好告警。模型更新采用蓝绿切换，新版本先在少量服务点灰度，确认稳定再全量转发流量，出问题可秒级回退到旧版本。这样即便压缩配置有偏差，影响也被限制在可控范围。对批量文档处理等离线任务，则可用队列削峰，把空闲算力填满，进一步摊薄单位成本。

数据来源

本文的量化原理、格式定义（INT8/E4M3/E5M2 FP8）、典型模型参数量与位宽换算、KV Cache 显存估算方法来自公开的技术文档与推理框架说明；GPU 型号、显存规格来自各厂商公开资料；云端租金量级（A100 40G 约数千元/月、H100 八卡整机约 8 至 12 万元/月）为公开渠道常见区间的概略参考，非精确报价，实际以官方实时报价或询价为准。一万网络提供相关服务器租用、机柜托管与带宽接入服务，具体机型、区域服务点与报价以官网实时或咨询确认为准。本文不构成采购建议，落地前请结合自有业务样本做回归测试，并根据实际硬件完成容量规划。

常见问题

量化后精度会掉多少？精度下降幅度取决于量化格式、层敏感度和校准质量。INT8 后训练量化在容错业务（问答、摘要）上通常只看到微小可感知差异，但在数学、代码、长程推理上可能出现几个百分点的准确率回落；FP8 因保留浮点指数，误差一般比 INT8 更小。关键是用真实业务样本做回归，把下降控制在可解释范围内。若个别层敏感，可保留为 FP16 做混合精度，既压了大部分显存又守住质量红线。建议先在测试集跑分再上灰度，而不是凭理论值拍板。

INT8 和 FP8 到底怎么选？先看硬件世代：A100 及更早的卡只支持 INT8 加速，FP8 没有硬件红利，应优先 INT8；H100、H200 等支持 FP8 张量核心，且业务对精度敏感时，FP8 更省心。再看数据分布：激活离群值多、动态范围大，FP8 更稳。预算和工程成熟度也重要，INT8 工具链更成熟、踩坑资料更多。一句话：老卡选 INT8，新卡且要保精度选 FP8。若未来可能换卡，采购阶段就应为 FP8 留好扩展空间。

小模型蒸馏值不值得做？如果你的场景固定、数据可回收、且长期要跑在边缘侧或小显存机器上，蒸馏很值：把大模型能力下沉到 7B/13B 学生，再量化，整体体积可小一个数量级，推理成本和时延都大幅下降。但蒸馏需要训练投入和持续维护，业务快速变化时性价比会下降。对多变通用场景，直接量化现有大模型往往更快见效。也可以用领域数据做指令蒸馏，让学生模型在垂直任务上逼近教师，从而获得更贴合业务的压缩效果。

24G 显存的卡能跑多大的模型？粗略按"参数量×位宽÷8"估算权重显存：24G 卡跑 INT8 的 7B（约 7GB 权重）很轻松，13B INT8（约 13GB）也能放下并留余量；若做到 4 位量化，34B 量级也可能塞进 24G。但要注意 KV Cache 和激活会额外吃掉显存，长上下文高并发时实际能跑的模型更小。70B 即便 INT8 也要约 70GB，24G 卡单卡起不来，必须更小量化或多卡切分。选型时记得为峰值流量预留缓存空间，避免满载即崩溃。

量化推理该用什么 GPU？边缘侧和轻量场景用 24G 级卡（如 L4、RTX 4090）跑 INT8 小模型；34B 量级用 40G A100；70B 量化后建议 80G 级 A100/H100。选卡先看显存能否容纳权重加 KV Cache，再看算力是否匹配吞吐目标，最后看互联带宽（多卡张量并行时 NVLink 优于 PCIe）。老卡用 INT8，新卡可考虑 FP8 以兼顾精度与速度。如果预算有限，先把模型压到能塞进便宜机型的位宽，比直接上大显存卡更省钱。

怎么降低大模型推理成本？优先量化压缩，把硬件门槛从多卡 80G 降到大显存或中端机型；其次做批处理与连续批处理提升 GPU 利用率，别让算力空转；再次用 KV Cache 量化压峰值显存，支撑更高并发；最后用蒸馏下沉到小模型处理固定场景。成本还包括校准、回归测试和运维，建议用真实流量灰度验证后再全量，避免线上质量事故带来的隐性成本。多区域部署时把请求转发到就近服务点，也能省下跨区带宽开支。

量化模型如何部署上线？把量化权重交给 vLLM、TensorRT-LLM 等框架，暴露兼容接口给业务。配置最大序列长度和批大小锁住显存上界，开启连续批处理提升利用率，用熔断和排队防突发流量击穿。模型文件放 NVMe 固态盘并预热，缩短首请求冷启动。多区域服务点部署时用统一网关转发请求到就近接入点，降低时延，并管理好模型版本一致性。上线前用少量流量灰度，确认质量与延迟达标再逐步放量。

量化会影响并发能力吗？量化本身不直接降低并发，反而因显存占用下降，同一张卡能留出更多空间给 KV Cache，从而支撑更高并发。但若为了极致压缩把 KV Cache 也压得很低，长上下文下的并发质量可能回落。正确做法是权重与 KV Cache 协同量化，并实测不同批大小下的时延和准确率，找到显存、吞吐与质量的交点，而不是孤立追求压缩比。扩容时先定位瓶颈，再决定加卡、换大显存机型还是优化服务框架。