模型量化部署到底值不值：INT8 与 FP8 推理的成本、吞吐和精度账

业务现场：7B 到 70B 模型上线推理时卡在哪

先说一个我几乎每周都能在客户群里看到的场景。算法团队把模型训完了，评测分数也漂亮，转头要上线推理服务，第一件事不是写接口，而是对着显存发愁。一个 7B 模型用 FP16 加载就要占掉 14GB 上下，13B 直接奔着 26GB 去，等到了 70B，光权重就 140GB，没四张 A100 根本起不来。很多中小团队账上没那么多卡，于是问题从「模型效果行不行」变成了「这张卡到底塞不塞得下」。

这还不是最难受的。长上下文一开，KV cache 这个隐形吞金兽比权重还狠。一个 70B 模型跑 8K 上下文的单轮对话，光 KV cache 就能吃掉 20GB 显存，对话一长、并发一上来，显存直接爆炸，服务要么 OOM 崩溃，要么被迫把批大小压到 1，吞吐惨不忍睹。说白了，推理上线卡住的从来不是算力够不够算，而是显存够不够装。量化这件事，本质就是冲着「装不下」和「装下了也跑不快」这两个痛点去的。

所以本篇不聊训练、不聊微调，就盯着一件事：把训好的模型从 FP16 压成 INT8 或 FP8 之后上线推理，显存到底能省多少、月成本能降多少、精度又得付出多大代价。账算明白，你才知道自己的 7B、13B、70B 到底该走哪条路。

先把账算清楚：显存为什么是推理部署的硬瓶颈

量化省钱的底层逻辑特别朴素，就是「用更少字节表示一个权重」。FP32 一个参数占 4 字节，FP16/BF16 占 2 字节，INT8 占 1 字节，INT4 只占 0.5 字节。同一份权重，从 FP16 压到 INT8，体积刚好砍半；再压到 INT4，又砍半。这就是 70B 模型为什么在 FP16 下要 140GB、INT8 下只要 70GB、INT4 下只剩 35GB 的原因——数字不是拍脑袋，是参数量乘字节数乘出来的。

但这里有个老运维都踩过的坑：量化能省容量，不一定省带宽，更不一定省时延。权重字节少了，总线传输量是降了，可如果你的量化方案让某些算子变低效，实际推理速度未必跟着涨。所以每次量化完，不能只盯着「模型文件小了」，得跑基准看吞吐和首 token 时延。我只信自己压测出来的数，不信卡片上写的「最高加速倍数」。

再补一句关于 KV cache 的。权重量化解决的是「模型本身占多少显存」，KV cache 量化解决的是「生成时随着上下文变长吃掉多少显存」，这两件事独立、可叠加。一个 7B 模型在批次 32、上下文 128K 时，KV cache 能到 64GB；INT8 量化 KV cache 后直接砍到 32GB，再叠权重 INT8，整体显存压力能降一大截。后面讲选型时我会反复回到这两个维度，因为它们决定了你选 INT8 还是 FP8 的根本理由。

INT8 和 FP8 到底是什么：从数值格式讲省钱的底层逻辑

INT8 是 8 位整型，数值范围固定、等间距。把权重从 FP16 映射成 INT8，本质是找一个缩放因子把浮点区间线性压进 -128 到 127。好处是几乎所有带 Tensor Core 的卡都认，包括 T4、V100、A100、H100；坏处是「线性等分」对付不了激活值里的离群点——大模型推理里总有少数特别大的激活值，INT8 的固定范围会被这些离群点撑爆，要么精度掉、要么得靠 SmoothQuant 这类校准把离群点先搬一搬。

FP8 是 8 位浮点，有 E4M3 和 E5M2 两种尾数/指数分配，关键在它带指数位。浮点的指数间距意味着它对离群激活的容忍度天然比 INT8 高，很多在 INT8 下要翻车的敏感任务，换 FP8 能稳住。代价是 FP8 需要原生支持它的硬件：NVIDIA 的 Hopper（H100、H200）和 Ada Lovelace（L40S、L4）原生带 FP8 Tensor Core，Blackwell（B200/B300）更进一步带 FP4；而 Ampere 架构的 A100 没有原生 FP8，硬上只能走软件模拟，反而掉 10% 到 20% 性能，所以 A100 上我一律建议老老实实用 INT8。

一句话区分：INT8 是「通用卡都能跑的均衡解」，FP8 是「新架构卡上又快又稳的进阶解」。两者都把权重从 2 字节压到 1 字节，显存收益同量级，真正的分野在吞吐上限和精度风险，而不是在「能不能装进去」。

怎么看这张表：前三列是「能不能装、装下能扛多少」，后三列是「跑起来快不快、稳不稳、给谁用」。INT8 和 FP8 在显存占用上几乎一致，所以选谁不看省多少显存，而看后三列——你手上是 A100 这类无原生 FP8 的卡，INT8 是唯一稳的解；手上是 H100/H200/L40S，FP8 在吞吐和离群激活稳定性上更占优。70B 那一行最直观：FP16 要 4 张 A100，量化后 2 张甚至 1 张 H100 就够，GPU 数量对半砍，月费跟着对半砍。别被「相对吞吐」那列迷惑，它是在你硬件原生支持该格式时的上限，A100 上硬跑 FP8 反而比 INT8 慢，格式和硬件必须配对看。

两套配置怎么摆：单卡跑 7B 与 70B 的实际选法

落到真金白银的配置，我按两种典型规模给选法。7B 到 13B 这类模型，FP16 下权重 14GB 到 26GB，INT8 后 7GB 到 13GB，单张 A100 40G 甚至 T4 16G 都轻松装下，瓶颈反而变成 KV cache 和并发。这种规模我的建议是：先上 INT8 权重量化，再把 KV cache 也量化，省出来的显存全拿去堆批大小和上下文，吞吐能涨一截还不怎么掉点。

70B 才是量化真正显威力的地方。FP16 下 140GB 权重，意味着最少两张 80GB 的 H100 才装得下，还没算 KV cache；压到 INT8 或 FP8，权重掉到 70GB，单张 80GB 卡就能塞进去，GPU 数量直接对半砍。这对成本的含义很直接：原本要包两台机器，现在一台就够了。但 70B 上我更偏向 FP8（前提是你手上是 H100/H200/L40S），因为 FP8 对离群激活更友好，长思维链和复杂推理任务的掉点比 INT8 更小。

部署链路这块也得提一句。单卡装不下要上多卡时，走的是 tensor parallel 把权重切片分到各卡，这时候量化让每张卡分到的切片更小，卡间通信量也跟着降，等于量化顺手把多卡通信压力也卸了一部分。所以「上不上多卡、上几张」不是孤立决定的，它和「量化成什么格式」绑在一起算才准。

精度风险别装看不见：哪些任务量化后会翻车

量化不是免费午餐，掉点是真实存在的，只是多少的问题。INT8 在 A100 上不做校准能掉 1% 到 3%，上了 SmoothQuant 这类标准校准后能压到 0.04% 左右，基本是噪声；FP8 在 H100 上多数任务掉点小于 0.5%。但「多数任务」不等于「所有任务」，有几类活儿量化后特别容易露怯，我列给你避坑。

第一是代码生成和调试。低精度会让结构化推理出现细微语法错和逻辑飘，生成的代码看着像那么回事，一编译就挂。第二是数学、金融、科学计算类查询，这些要精确数值，四舍五入的累计误差会放大。第三是评测和回归基准——你本来就要用精度差异来区分模型版本，自己先量化了，对比就失效了。第四是长链路 Agent，多步推理里每步那一点点误差会累积，到最后任务完成率明显往下掉。

反过来，通用对话、文本分类、信息抽取、客服问答、RAG 的检索召回这类任务，对一两分点的精度漂移容忍度很高，量化基本无损体验。所以我的判断方法很简单：先把你的任务分成「精度敏感」和「精度钝感」两摞，钝感的闭眼量化，敏感的要么保 FP16，要么只在钝感层量化、敏感层留高精度（混合量化）。

成本账怎么拆：显存省下来对应的是实打实的月费

讲完技术该算钱了。显存省下来的每一 GB，背后都是少租一张卡、少包一台机器。以一万网络自营 GPU 实例的公开报价口径为例：人工定制 GPU 月付含 100M BGP 的 T4 16G 约 ¥900、V100S 32G 约 ¥1500、A100 40G 约 ¥2800；AI 算力云里 A100 整卡 40G 月付约 ¥2500，A100 1/20 切片 4G 约 ¥900。H100 8 卡整机月付约 ¥8 万到 12 万（年付 85 折）。这些数字以官网实时价为准，促销和配置加减会有浮动。

一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。对中小团队来说，量化最现实的意义就是：原本 70B 要两张 H100 才跑得动，压成 FP8 一张就够，月费从十几万直接掉到单机几万的量级，省下的就是净利润。

这里要分清 A 类和 B 类报价的边界。上面这些是一万网络官网已经挂出的确定报价，可以放心写；但 L40S、L4 这类同样原生支持 FP8 的卡，若官网未列明具体型号与地区价格，一律按「需询价 / 以官方实时报价为准」处置，我不替你编一个数。成本测算时最稳的做法是：先用权重字节数算清要几张卡，再拿对应卡型的官网价乘月数，量化带来的卡数减半就是成本减半的硬账。

还有一笔容易被忽略的账是带宽和电力。量化后单卡能扛更高并发，意味着同样流量下机器更少、机房机位和电力更省；液冷比风冷省电 20% 到 40% 这类经验值可以写区间，但别编具体电价。我一般给客户做个三年总拥有成本的表，把卡租、机位、带宽、电力都摊进去，量化省下的卡数会在每一项上同时起作用，叠加效应比单看卡租更可观。

要上多卡之前，先想明白三件事

很多团队一上来就想「不够就加卡」，但加卡前有三件事不想清楚，钱花得冤。第一，你的瓶颈到底是权重装不下，还是 KV cache 撑爆，还是单纯并发太高？权重装不下就量化或加卡，KV cache 爆就量化 KV cache 或降上下文，并发高就调批大小和 continuous batching——这三件事解法完全不同，加卡只能解决第一种。

第二，多卡走 tensor parallel 还是 pipeline parallel？70B 这种大模型 tensor parallel 更常见，但卡间用 NVLink 还是普通互联，时延差一个量级，量化让切片变小能缓解但不能消除通信开销。我建议先在单卡 FP8 下测满并发，真顶不住再加卡，别为了「显得专业」直接上八卡。

第三，你的服务框架吃不吃量化格式。vLLM 一条 --dtype fp8 就能开 FP8，TensorRT-LLM 对 Hopper/Ada 的 FP8 自动转换支持得很顺，Hugging Face Transformers 配合 bitsandbytes 或 optimum 也能做。框架不支持你硬压，要么跑不起来要么退化成软件模拟，那点加速全吐回去了。框架选型我放在下一节避坑里展开。

量化算法怎么挑：SmoothQuant、AWQ 还是 GPTQ

格式（INT8/FP8）和算法（怎么把浮点映射成低精度）是两路独立的旋钮，别混为一谈。同样是 INT8，裸映射不做校准能掉 1% 到 3%，上了 SmoothQuant 把激活离群点先平摊到权重上，A100 上掉点能压到 0.04%，这是生产环境 INT8 的标配做法。FP8 一般走框架原生 W8A8，Hopper 上 vLLM 一条 --dtype fp8 就行，不需要额外校准。如果精度预算允许往 4 位压，AWQ 和 GPTQ 是两条主流训练后量化路线。

AWQ 用激活感知思路保住对激活敏感的「关键通道」，Vicuna-7B 上相对 FP16 平均只掉 0.54 分，质量比同位的 GPTQ 稳；GPTQ 是老牌方案、出权重快，部分场景略逊 AWQ。两者都靠校准集补偿误差，所以同是 4bit，量化质量差异能很大，优先选官方或社区验证过的量化权重，别自己随手压。算法选错比格式选错更隐蔽——格式不对顶多跑不起来，算法不对是悄悄掉精度，上线才发现就晚了。

我的选法一句话：有 H100/L40S 跑大模型服务就上 FP8 W8A8；通用卡（A100 及更老）求稳选 INT8 配 SmoothQuant；想进一步把 70B 塞进单卡又容得下掉点，再考虑 AWQ/GPTQ 的 4bit。这条线把「硬件代次、精度预算、卡数目标」三个约束一次收敛，比盲目追更低位宽实在。

上线流程与回滚：量化权重怎么产出、压测、出问题怎么退

量化不是改个参数就上线，我给客户的标准流程是六步。第一步，准备取自线上真实分布的校准集，别拿通用语料糊弄。第二步，用对应工具产出量化权重（SmoothQuant 出 INT8、llm-compressor 或框架原生出 FP8、AWQ/GPTQ 出 4bit），校验文件完整性。第三步，在测试环境用业务评测集跑精度，确认掉点在可接受线内，并记录量化前后的指标差值作为回归基线。

第四步，做真实并发压测，记录吞吐、首 token 时延、显存峰值三件事，对比量化前同口径数据，三个指标都涨或持平才算合格。第五步，灰度切 5% 到 10% 流量，盯人工抽检和错误率，跑够一个完整业务周期再放大。第六步，全量或回退——这一步必须有回退预案：量化权重和原始 FP16 权重并存，出问题一键切回 FP16 服务，绝不让量化实验拖垮线上。

最容易出生产事故的是「跳了灰度直接全量」。量化后的细微掉点在小流量看不出，全量后长尾任务、边缘输入才会暴露。我的经验是灰度期至少覆盖一轮完整业务高峰，再把回退开关留在配置里一周，确认没长尾异常再摘掉。故障定位也分两层：若是整体掉点，多半是校准集或算法不对，重做校准；若是偶发错乱，多半是离群激活被截断，INT8 换 FP8 通常能解。

容量规划：按 QPS 和上下文长度反推要几张卡

很多人容量规划拍脑袋「先来两张 A100」，正确做法是反推。先定两个输入：目标 QPS（或并发用户数）和平均上下文长度。权重维度前面算过，70B FP16 要 140GB、INT8/FP8 要 70GB；KV cache 维度用公式：批大小 × 序列长度 × 层数 × 每头维度 × 注意力头数 × 2 × 精度字节数。一个 32 层、32 头、每头 128 维的 7B 模型，单请求 4K 上下文 FP16 下 KV cache 约 8.6GB，并发 16 就奔 137GB，比卡本身还大。

所以容量公式要同时装下「权重 + KV cache + 激活余量」。量化把权重和 KV cache 同时砍半后，同样一张卡能扛的批大小和上下文直接翻倍，等价于同样的 QPS 下少租卡。我一般给客户做张表：列出目标 QPS、平均/峰值上下文、选 INT8 还是 FP8，反推单卡可扛并发，再除以总需求得卡数，最后乘官网卡价得月费。量化前后的卡数差，就是这份规划里最实在的省钱数字，比任何加速倍数的宣传都靠谱。

峰值要单独留余量。业务高峰并发往往是均值三到五倍，KV cache 随上下文线性增长，所以规划不能按均值卡显存，得按峰值上下文和峰值批大小算，否则高峰一来就 OOM。量化在这里的价值是「把峰值余量也量化掉」——同样留 30% 余量，量化后绝对显存更小，机器更省，机房机位和电力也跟着省。

给个可直接套用的实例。假设要上线 70B 模型，目标并发 8、平均上下文 4K、峰值上下文 16K。FP16 下权重 140GB 至少两张 80GB H100，KV cache 在并发 8、4K 上下文按 70B 的 80 层、8 个 KV 头、每头 128 维估算约 11GB，叠加权重后单卡放不下、必须两张；量化成 FP8 后权重 70GB、KV cache 约 5.5GB，单张 80GB H100 即可容纳，卡数从 2 降到 1。按 H100 8 卡整机月 ¥8 万到 12 万折算单卡约 ¥1 万到 1.5 万，这一刀直接省出一台机器的月费，一年就是十几万。若你的并发涨到 32，FP16 要四张、FP8 两张，省钱倍数不变，只是基数变大、绝对值更可观。这个例子也说明：量化省的不是「按比例」的虚账，是实打实的卡数减法，容量规划里先把这道减法做对，比纠结加速倍数有用得多。

场景化打法：对话、检索、代码三类业务量化策略不同

别拿一套量化打法套所有业务，我按三类常见场景给不同策略。通用对话和客服这类钝感任务，INT8 配 SmoothQuant 几乎无损，直接整模型量化，把省出的显存全堆并发，性价比最高；要上 H100 就换 FP8，吞吐还能再涨。这类场景是量化收益最稳、风险最低的地方，中小团队该从这儿起步。

RAG 类业务要分两层看：检索召回那一段对精度敏感，向量和重排模型别乱量化，否则召回质量掉一点、最终答案就偏；大模型生成那一段是钝感的，可以放心量化。所以 RAG 的量化策略是「检索侧保 FP16、生成侧量化」，别整链路一刀切。代码生成和数学推理这两类敏感任务，我建议保 FP16 或只做混合量化——敏感层留高精度，钝感层压 INT8，既控显存又不伤核心能力。

长上下文场景（法律、文档分析）另有打法：权重量化之外必开 KV cache 量化，否则上下文一拉长 KV cache 先把显存吃爆，权重省的那点全填回去还不够。这类场景 FP8 的 KV cache 比 INT8 更稳，H100 上建议 KV cache 也走 fp8。一句话总结：钝感任务整模型量化，敏感任务混合量化，长上下文任务权重量化加 KV cache 量化三件套，三层策略对应三类不同的省钱与风险账。

补一句迁移账：从现有 FP16 服务切到量化服务，别一次性全切，按前面说的灰度流程走，迁移本身几乎零成本——模型文件换一份、框架参数改一项即可，业务代码不动。真正要算的是回退准备金：保留一份 FP16 权重占的存储可以忽略，但包卡模式下若不为释放的备用卡及时退订，灰度期会出现「量化版和 FP16 版两份卡时同时计费」的双重成本。建议灰度一通过立即释放备用卡，别让回退预案变成长期闲置开销，否则省下的量化收益会被这段重叠期吃掉一部分。

按 token 计费下量化怎么直接变省钱：加速倍数就是降本倍数

前面算的都是包卡月费的逻辑，如果你的推理走的是按 token 计费（serverless 推理或模型 API），账本换了个算法，但结论更狠：量化带来的吞吐提升会直接变成单位 token 成本下降，几乎是一比一。包卡模式下，加速倍数只帮你「同样的卡多扛并发」，省的是隐性机会成本；按 token 计费下，加速倍数直接压低每千 token 的单价，是显性降本。

举个具体账。H100 上 FP8 相对 FP16 在 Mixtral-70B 这类模型能到接近 2 倍吞吐，同样一百万 token 的请求，FP8 占用的 GPU 秒数约为 FP16 的一半，账单就约为一半。INT8 在 A100 上 1.2 到 1.6 倍吞吐，对应每 token 成本也按同比例降。所以选型时要看清你的计费模型：包卡就盯「卡数能不能砍半」，按 token 就盯「吞吐倍数能不能翻倍」，两种口径下 FP8 的优先级都比 INT8 高。

还有个容易被忽略的点：量化让单卡能扛更高并发，意味着同样流量下峰值卡数更少，按 token 计费平台的「并发上限」也更难触顶，突发流量不会被限流或排队。对做 C 端产品的团队，这种「峰值不被掐」的稳定性价值，往往比单价那几个百分点更值钱。我一般建议先拿一周真实流量跑 A/B，量化版和 FP16 版同口径比单 token 成本和尾延迟，数据出来再决定全量，别凭倍数宣传拍板。

避坑：量化部署里最容易踩的五个坑

坑一：A100 上硬上 FP8。Ampere 没有原生 FP8，vLLM 里强行 fp8 走软件模拟反而掉 10% 到 20% 性能。判断方法很简单，看架构代次——A100 认 INT8，H100/H200/L40S 才认 FP8，别被「FP8 更快」的笼统说法带偏。

坑二：只看模型文件大小不测吞吐。权重砍半不代表时延砍半，某些量化算子拖后腿时吞吐原地踏步甚至倒退。怎么避：上线前跑一遍真实并发下的基准，记录吞吐和首 token 时延，两个指标都涨才算真省。

坑三：校准集和业务分布脱节。INT8 不校准掉 1% 到 3%，用错校准集一样翻车。怎么避：校准集必须取自你线上的真实输入分布，别拿通用语料糊弄；SmoothQuant 这类方法对 A100 上的 INT8 几乎是把掉点压到噪声级的关键。

坑四：KV cache 忘了量化。很多人只量化权重，长上下文一开 KV cache 把省出来的显存又吃回去。怎么避：权重量化之外，顺手把 KV cache 也压到 INT8 或 FP4，长上下文场景能再省一半到四分之三的 cache 显存，这部分和权重量化独立可叠加。

坑五：把精度敏感任务当钝感任务量化。代码生成、数学计算、评测基准、多步 Agent 这些量化后容易露怯，一刀切量化会出生产事故。怎么避：先按任务分敏感到钝感两摞，敏感的保留 FP16 或只做混合量化，钝感的才整模型压。

几个被问得最多的量化问题

INT8 和 FP8 到底差在哪？核心差在数值表示。INT8 是 8 位等距整型，范围固定，遇到大模型激活里的离群值容易被撑爆，得靠校准搬离群点；FP8 是 8 位浮点带指数位，对离群激活天然更友好，敏感任务掉点更小。两者都把权重从 2 字节压到 1 字节、显存收益同量级，分野在吞吐上限和精度风险。硬件上 INT8 通用卡都认，FP8 要 Hopper 或 Ada 原生支持。

量化后精度下降多少算可接受？得看任务。INT8 配 SmoothQuant 校准在 A100 上相对 BF16 掉点约 0.04%，基本可忽略；FP8 在 H100 上多数任务小于 0.5%。通用对话、分类、抽取这类钝感任务，1% 到 3% 的漂移用户根本感知不到。但代码生成、数学计算、评测基准这类敏感任务，哪怕 0.5% 也可能导致可复现性问题，这类就该保 FP16。可接受线不是固定值，是「你的任务容不容得下」。

哪些模型不适合量化？不是模型不适合，是任务不适合。小模型本身参数少，量化收益有限还容易伤精度；精度敏感任务（代码、数学、科学计算、评测回归、长链路 Agent）不应当对全模型量化。另外已经用 GQA/MQA 把 KV 头砍过、或原生就 INT4 权重的模型，再叠权重量化边际收益小。判断逻辑是先分任务敏感到钝感，再决定量不量化、量化哪几层。

量化要改推理框架吗？多数情况不用重写业务代码，但要选对推理栈。vLLM 用 --dtype fp8 开 FP8、用量化版权重直接加载；TensorRT-LLM 对 Hopper/Ada 的 FP8 做自动转换；Hugging Face Transformers 配合 bitsandbytes、optimum 或 quantization 工具（如 llm-compressor）也能产量化权重。框架不原生支持时硬压会退化成软件模拟甚至跑不起来，所以「框架吃不吃这个格式」是量化前必查的一项。

INT8 显存能省多少？权重维度，每个参数从 FP16 的 2 字节降到 INT8 的 1 字节，刚好砍半：7B 从约 14GB 降到 7GB，13B 从 26GB 降到 13GB，70B 从 140GB 降到 70GB。若再把 KV cache 也量化成 INT8，长上下文场景还能再省一半到四分之三的 cache 显存。但要注意省的是「容量」不是必然的「带宽和时延」，得跑基准确认。

FP8 需要什么硬件？原生 FP8 要 NVIDIA Hopper（H100、H200）或 Ada Lovelace（L40S、L4）这类带 FP8 Tensor Core 的卡，Blackwell（B200/B300）更进一步带 FP4。Ampere 的 A100 没有原生 FP8，强行上走软件模拟反而掉性能，所以 A100 上用 INT8 更合适。注意 Ada 上的 W8A16 是「仅权重 FP8」、和 Hopper 的完整 W8A8 不是一回事，吞吐上限有差距。

量化推理怎么测精度？别只看公开榜单平均分，要在你自己的任务评测集上测，而不是通用榜。三件事必测：一是你业务指标的精度（如准确率、BLEU、人工抽检），二是对实际并发下的吞吐，三是离群激活有没有被量化截断——这点 INT8 比 FP8 风险高。还要做量化前后同输入输出的 diff 抽检，敏感任务加长链条回归测试，确认没引入可复现性偏差再锁卡数。

小模型值得量化吗？7B 以下的小模型权重本来就不大，量化省出的显存有限，反而容易伤精度，通常不优先整模型量化。但两类情况例外：一是你要在 T4、边缘卡这种小显存设备上塞模型，量化是「能不能跑」的问题不是「省多少」的问题；二是长上下文高并发，KV cache 量化对小分子模型一样有效，这部分和小模型大小无关，该量就量。

量化不是万能钥匙，先算显存和精度两本账

写到最后给个收尾判断。量化值不值，不靠感觉，靠两本账：第一本是显存账，算清你的模型权重加 KV cache 在 FP16 下要几张卡，压成 INT8/FP8 后能砍到几张，卡数对半就是月费对半；第二本是精度账，把任务分成敏感到钝感，钝感的大步量化、敏感的保高精度或混合量化。两本账都算完，你的 7B、13B、70B 该走 INT8 还是 FP8、该不该上多卡，结论自然就出来。

给一句可落地的经验：手上是 A100 这类老架构卡，闭眼选 INT8 配 SmoothQuant；手上是 H100/H200/L40S 这类新卡又跑 70B 以上的大模型服务，优先 FP8，离群激活更稳、吞吐更高；KV cache 量化无论如何都顺手加上，尤其长上下文。至于一万网络这类自营 GPU 实例能给你什么卡、什么价，按官网实时报价核对最稳，别拿估算当合同。

数据来源

NVIDIA 官方技术文档：TensorRT-LLM 量化说明与 H100 数据手册，明确 FP8（E4M3/E5M2）原生支持见于 Hopper（H100/H200）与 Ada Lovelace（L40S/L4）架构，A100（Ampere）无原生 FP8、需走 INT8 或 BF16；H100 SXM FP8 Tensor Core 算力相对 FP16 约 2 倍。

Hugging Face Transformers 量化相关文档与 vLLM 文档：覆盖 AWQ、GPTQ、INT8、FP8、KV cache 量化（--kv-cache-dtype / --dtype fp8）的启用方式与精度验证流程，确认权重量化与 KV cache 量化相互独立、可叠加。

各云厂商 GPU 实例规格页与一万网络官网 GPU 实例公开报价（T4 16G、V100S 32G、A100 40G、H100 8 卡整机等月付口径），用于本篇成本拆解的卡数与月费换算；未列明型号与地区的卡型按「需询价 / 以官方实时报价为准」处置。

公开技术基准资料（A100 INT8 配 SmoothQuant 相对 BF16 掉点约 0.04%、H100 FP8 多数任务掉点小于 0.5%、70B 模型 FP16 权重约 140GB / INT8 约 70GB 的字节数测算），用于精度风险与显存账的估算区间，具体以你自身业务评测为准。