同一个模型该用什么精度、配什么硬件聊模型部署绕不开“精度”这两个字。我见过不少朋友拿到现成的开源模型第一反应是“直接用FP16跑”结果显卡显存不够也有朋友一拍脑袋直接量化到INT4速度是上去了但模型输出的质量肉眼可见地变差。这两个例子其实指向同一件事精度不是一个可以拍脑袋定的参数它和硬件显存、带宽、部署成本、业务延迟是绑在一根绳子上的。今天这篇文章就把这件事一次说清楚从精度档位到底是什么到显存怎么算再到不同硬件平台该怎么选组合最后落到一套可复现的验证流程上。无论你是第一次部署模型还是已经在生产环境里调过好几轮参数应该都能从里面找到用得上的方法。1. 先摆正坐标系精度选择本质是“任务约束下的权衡”1.1 三个指标决定你的精度选择同一个模型放在不同的任务里对精度的敏感度完全不同。最简单的例子用BERT做文本分类把FP32换成INT8准确率可能只掉0.1个百分点但用同一个Transformer架构做长文本生成INT8遇到一些长尾分布的表达就可能在某个片段突然崩掉。所以精度选择的起点不是“这个模型支持什么格式”而是你业务里最不能让步的那个指标。我先列三个约束条件你在选精度前得先把它们排好序质量底线任务指标允许掉多少比如分类准确率允许从98压到97.5还是完全不允许波动速度目标单次请求延迟要求多少毫秒每秒需要处理多少个请求成本边界能接受的单卡、单机成本是多少电费、云端按小时计费都算进去。这三个条件组合不同结论就不同。比如离线批量推理延迟不是主要矛盾那就可以放心上INT8甚至INT4换来相同时间内更多的任务量而实时交互、面向用户的搜索问答延迟和质量同样重要可能就要在INT8和FP16之间反复试探。1.2 训练和推理必须分开讨论很多文章讲精度喜欢把所有场景搅在一起说这是误导的最大来源。实际开发中训练、微调、推理三个阶段采用的精度和硬件逻辑是完全不同的。训练和微调阶段核心需求是梯度回传的稳定性。模型每一层都要保存激活值、梯度中间量如果数据精度太低数值很容易溢出或者截断训练就会不收敛。所以这个阶段主流选择是FP32、BF16这类浮点格式它们有足够大的动态范围来承载梯度的细小差异。推理阶段则相反权重已经固定不再需要反向传播我们只是把前向计算跑一遍。此时权重的数值范围是静态的可预测的这就为低位宽量化提供了基础。将一个FP32的权重转成INT8体积直接缩小到四分之一为什么能这么做因为神经网络对权重中不同数值的敏感度并不一样量化要做的事情就是在缩小体积的同时把最重要的数值分布保留下来。1.3 精度选择的反直觉点低精度经常带来“质变”这里有个反直觉的结论值得先讲出来在很多任务里低精度模型不是“能用就行”而是“能跑和不能跑”的分界线。举个例子。一个7B参数的模型FP16权重需要约14GB显存加上KV Cache和框架开销一张普通消费级24GB显卡可能刚好塞下;如果量化到INT4权重只要4GB左右在同样的卡上就能同时承载更大的并发批次甚至能做到长上下文的推理。CPU内存只有16GB的笔记本FP16根本加载不起来INT4量化后却能流畅跑对话模型。这种情况下精度已经不是质量取舍而是可行性本身。所以我的建议是先别问“哪个精度最好”先问“我这个硬件上哪个精度能跑起来、所需的吞吐量达不达标”再用实测去确认质量是否可接受。2. 精度全档位拆解FP32、FP16、BF16、INT8、INT4 各自的本利账2.1 一张表看懂主流精度格式的区别做部署选型至少要把下面这张表刻在脑子里精度类型存储字节动态范围特点与典型用途FP324字节约1e-38到3e38传统模型训练基线范围广但显存放不下大模型FP162字节约5.5e-5到65504范围偏窄训练时容易溢出推理速度尚可旧显卡支持最好BF162字节与FP32相同专为训练设计范围大但小数精度低适合梯度回传INT81字节-128到127推理主力体积小、速度快质量损失通常可控INT40.5字节大概-8到7极限压缩适合大模型上消费级显卡或手机端表中FP16的值上限是65504看着挺大但做训练时如果遇到Loss特别大的批次很容易出现梯度上溢。BF16把指数位拉回和FP32一样宽从根本上解决了训练中的范围问题代价是尾数位更少、有效小数位数变低。所以新一代训练框架里BF16基本成了默认选择不是因为它更准而是因为它不会让训练直接崩溃。2.2 整数量化到底在做什么很多人一听INT8就觉得“这数字小太多了肯定不准”其实整数量化不是简单把权重四舍五入到整数。量化核心是“映射”。我们把原始浮点权重中的最大绝对值作为一个缩放因子然后把所有权重按比例映射到整数范围。比如某个权重最大绝对值是2.5量化到INT8时1.0对应的整数大约就是51。推理时再把整数乘回缩放因子做反量化。整个过程涉及两个关键量一个是缩放因子scale一个是零点zero_point。这里要说清楚一个误区量化不只是针对权重还有激活值。权重是静态的可以先离线算好scale激活值却随输入变化所以更麻烦。于是又衍生了两种做法一种是权重只有INT8、激活保持FP16叫做“W8A16”另一种是权重和激活都量化成INT8叫做“W8A8”。前者容易做、兼容性高后者要做量化校准但对速度提升更明显。2.3 动态范围是精密仪器浮点范围是大平原整数则是分格子的仓库用一张图来描述FP32像一片大平原任何数值都能被高精度定位INT8像一个划分了256个格子的仓库绝大多数权重都能装进去但原本靠得很近的两个小数可能被塞进同一个格子里。神经网络对“同一格子里的小数”到底敏不敏感主要看权重分布。有的模型权重天然平缓、正态分布量化后损失很小有的模型却有明显的离群值比如某些神经元输出几千倍的异常大值这些离群值会把量化比例拉歪导致大多数普通权重被压缩到几个整数区间里信息大量丢失。这也是为什么同样一个量化方案换一个模型差别巨大的原因。处理离群值有专门的办法比如混合精度、per-channel量化、GPTQ/AWQ这类基于误差重建的量化算法。后面我会说这些工具怎么选。3. 算清硬件账显存占用、吞吐量和延迟到底从哪里开始算3.1 推理显存估算公式在选择精度和硬件搭配前至少要会估算一个模型跑起来会占多少显存。推理阶段显存主要由三部分组成显存占用 模型权重 推理中间状态KV Cache / 激活值 框架运行时开销推理时的模型权重很好算参数量乘以每个参数占用的字节数。注意参数单位是Billion要乘以10的9次方来算。举例7B参数模型INT8量化后有约70亿个参数乘以1字节约7GB权重FP16则约14GB。KV Cache是Transformer的“记忆体”。推理时每生成一个Token都要缓存前文的Key和Value参数量随序列长度线性增长公式大致是 KV Cache大小 ≈ 批大小 × 序列长度 × 层数 × 注意力头数 × 每头维度 × 2Key和Value各一份× 精度字节数这个数值动辄几个GB。如果跑长文本、大并发KV Cache甚至比权重占得更多。所以估算时别只看权重体积。下面用一段Python代码快速估算7B模型在不同精度下的显存下限def estimate_vram(params_b, dtype_bytes, kv_cache_gb0, overhead_gb1): weights_gb params_b * 1e9 * dtype_bytes / 1024**3 return weights_gb kv_cache_gb overhead_gb print(7B FP16:, round(estimate_vram(7, 2), 2), GB) print(7B INT8:, round(estimate_vram(7, 1), 2), GB) print(7B INT4:, round(estimate_vram(7, 0.5), 2), GB)运行结果是FP16约14GB权重加1GB开销约15GBINT8约7GBINT4约3.5GB。再加2GB的KV Cache三种精度对显存的需求分别是17GB、10GB、5.5GB。这一对比用什么显卡合适就一目了然了。3.2 延迟与吞吐量的真相决定速度的是带宽显存只决定“装不装得下”真正决定推理快慢的是两样东西算力FLOPs和显存带宽。自回归生成模型每一步生成一个Token都要把所有权重从显存读到计算单元里。假设7B FP16模型有14GB权重一块A100的显存带宽约每秒2TB那理论上读一次权重需要约7毫秒这7毫秒就是单次Token生成的物理下限。权重越小读得越快这就是低精度推理速度快的根本原因。如果模型权重是INT87GB权重在同样2TB带宽下读取只要约3.5毫秒速度直接翻倍。这也是为什么在同样一张卡上量化模型比高精度模型更适合做高并发服务。再强调一个关键概念Token生成是“内存带宽主导”的任务不是“算力主导”。所以一味堆一张算力极强的显卡但模型精度没降、权重没压缩延迟改善依然有限。反过来把精度从FP16降到INT4即使用较便宜的显卡也可能比原来的旗舰卡跑得更快。3.3 主流硬件平台参数对比下面列几个最常见的硬件平台我按推理场景给出参考定位。数值是公开规格的简化整理。硬件显存/内存显存带宽适合精度组合场景定位RTX 409024GB约1TB/sFP16/INT8/INT4本地开发、小规模服务RTX 309024GB约936GB/sINT8/INT4为主预算有限时的推理卡A100 80G80GB约2TB/sBF16/FP16/INT8大规模训练与高并发推理H100 80G80GB约3.35TB/sBF16/FP8/INT8顶级训练与吞吐场景中端CPU服务器几十GB~上百GB受内存通道限制INT8/INT4延迟要求不高、成本敏感的批量任务手机/嵌入式板子4GB~16GB系统内存带宽INT4/INT8端侧离线模型一个7B模型用FP16硬塞进RTX 4090可能只剩少量KV Cache空间并发只能开到1INT8后可以开更高并发或更长上下文INT4后经常能同时跑两个模型实例。选型时把精度、显存、并发这三者放一起考虑而不是单看某一项。4. 不同落地场景下的“精度硬件”组合策略4.1 数据中心高并发推理优先BF16/FP16与INT8混合在云端用A100/H100这类企业级显卡时很多人习惯直接上BF16理由是卡足够大。但这不够经济因为你真正卖的是“每秒钟能处理多少请求”。高并发推理的关键是尽可能提高GPU利用率。FP16/BF16权重计算精度高但占用带宽也高并发一旦上去KV Cache和权重加一块很快把显存打满。在实际服务里我见过不少团队采用“混合策略”入口用FP16做高敏感任务同时跑一个INT8实例做普通任务两个模型实例按请求属性分流这样能明显提升整体吞吐。如果使用vLLM这类推理框架还可以开启“量化感知的调度器”它会在同一张卡上管理不同精度的模型实例让显存碎片最小化。反正不要在A100上满怀信心地部署一个同学在4090上调好的FP16配置企业卡虽然显存更大但并发模型数、长上下文能力都需要重新压测。4.2 消费级显卡与本地工作站INT4和INT8是救命稻草本地工作站最常见的困境是一张RTX 4090想跑13B甚至几十B的开源模型。FP16肯定加载不了这时真的别硬扛。建议路径是这样先在Hugging Face模型库找GGUF格式的量化版本从INT8开始测试如果显存还是溢出就继续降到INT4甚至混合精度版本用llama.cpp或Ollama这类工具加载它能在CPU和GPU之间自动分配层。ollama跑一个示例命令ollama run qwen2.5:7b-instruct-q4_K_M这条命令会启动一个INT4量化的7B模型。大多数配置下4090跑它能达到很高的生成速度质量仅比FP16略降。你在本地做Agent、写代码辅助、处理一些只在本机运行的任务完全够用。如果太看重隐私想把模型完全放在本地又不想用云GPU那消费级卡配合INT4就是目前最实用的一条路。别总觉得量化就是“阉割版”4比特模型经过良好校准后很多任务表现和FP16几乎无差别。4.3 CPU与边缘设备把量化和算子优化一起做有些场景不允许用GPU比如金融数据安全要求高的内网或者工业现场的边缘盒子。CPU推理没有显存带宽优势内存带宽又受限必须靠极致的量化来压体积。CPU上一般用OpenVINO、ONNX Runtime或者llama.cpp。以ONNX Runtime为例如果模型导出时带动态量化就可用下面的方式在CPU上跑INT8推理import onnxruntime as ort sess ort.InferenceSession( model_int8.onnx, providers[CPUExecutionProvider] ) outputs sess.run(None, {input: input_data})关键是CPU平台对INT8支持的差异很大。有的指令集支持VNNI/AVX512走INT8会有明显加速没有这些指令集的旧CPU速度提升可能不如预期这时可以把部分层保留FP16或FP32只量化线性层、注意力层等计算密集部分。边缘场景更要看重“内存墙”。比如在树莓派、Jetson这类板卡上跑YOLO目标检测一般选INT8加TensorRT加速在手机端跑大语言模型则基本就是INT4起步。端侧硬件的内存和带宽都极有限精度每降一半意味着能加载模型的档次可能直接升一级。4.4 手机端与嵌入式INT4的天下但要注意激活值手机端的难点不只是显存更是功耗和发热。同样的模型在桌面端跑INT8就好在手机上却可能因为内存带宽太低而卡顿所以INT4通常成了唯一选择。不过手机端跑大模型时激活值最好保留为FP16也就是“W4A16”方案。穿越到一个低比特整数量化的激活层不仅速度不一定快还可能引发精度明显下降。很多开源模型跑端侧时部署框架已经默认把部分算子改成混合精度不是所有层都积极压到INT4。这类细节比单纯调一个量化等级影响大得多。5. 量化不是白给的钱实测验证与三个常见崩点5.1 量化后出现“AI味变重”的现象不是幻觉量化掉点最常见的表现不是模型完全不能用而是生成内容变得重复、割裂、或者突然冒出毫无逻辑的句子。这种问题在长文本生成里尤其明显因为某些离群权重在低比特下被截断激活值传递到堆叠层后误差逐步放大。遇到这种问题先不要否定整个量化方案而要检查三个环节是否用了合适的量化算法简单rounding直接四舍五入性能通常不如GPTQ、AWQ这类误差补偿算法校准集是否覆盖了真实业务场景如果模型要处理中文金融文本你却拿英文通用语料做校准量化scale自然偏掉是否所有层都被无差别量化了试试把敏感层比如最后的LM Head、前几层Embedding层保留FP16。5.2 校准集的选择直接影响成败量化校准的本质是用一部分真实数据来统计激活值的分布再决定scale和zero_point。因此校准集不能太小也不能和业务差异太大。我一般用500到1000条有代表性的样本涵盖真实业务里的长文本、短文本、特殊格式、边界情况。如果做代码模型就放更多复杂代码片段如果做聊天模型则要有不同语言风格、不同长度的问题。校准完成后一定要用另一组未见过的样本来做质量测试否则只优化了校准集而得出的表象根本骗不了线上流量。5.3 量化模型该怎么验证推荐“量化对比法”最稳妥的验证方法是“同源对比”用同一批输入分别跑FP16基线模型和量化模型然后对比关键指标。具体操作准备固定测试集至少一百条真实业务样例对分类模型记录准确率、F1等指标差对生成模型记录困惑度差值再看几条输出内容是否逻辑丢失判断误差是否在业务容忍范围内。对生成模型我常看两个冷门指标连续重复片段的次数、上下文一贯性。量化模型如果开始重复某些词组说明某个注意力层已经失真。还可以用这个Python片段快速计算两层模型输出之间的困惑度差距import math def perplexity(log_probs): return math.exp(-log_probs.mean()) base_ppl perplexity(log_probs_fp16) quant_ppl perplexity(log_probs_int8) print(PPL gap:, quant_ppl - base_ppl) # 一般差距在1以内可接受超过2就要谨慎这里的经验阈值是测得的困惑度差距小于1基本可放心上线超过2则建议把精度往高调一个档位或使用更复杂的量化算法。6. 我现在实际走一遍的操作顺序与踩坑记录6.1 三步决定法从硬约束到软验证我可以把这几年反复验证过的一套方法总结成“三步决定法”每次拿到新模型都走一遍。第一步确认硬件边界。查GPU显存、可用内存、CPU指令集算出各精度档位下的理论显存占用。用前面的公式填一次表格划掉装不下的选项。第二步选择默认起点。GPU够大且追求质量FP16或BF16起步GPU紧张INT8先试实在没显卡或想跑大模型INT4配合量化工具走一遍。第三步做量化对比验证。准备有代表性的业务测试集把FP16基线和量化结果跑一遍按第5.3节的方法判定是否接受。接受就上线不接受就往高精度或更复杂算法调整。这套流程看起来简单但能避免最频发的错误——直接在量化后看一眼输出“感觉还行”就上线结果线上被用户反馈说内容重复、敏感词识别漏掉。6.2 常见踩坑记录与规避方法我把部署过程中遇过的、高频出现的问题列在下面每一项背后都有过案例问题现象根因规避方法同一个INT8模型在一张卡上限并发是3另一张卡上限是7显存剩余不同KV Cache预留差异用框架的显存占用日志先测满负载量化模型输出有时莫名其妙重复离群权重被压缩改用AWQ或对敏感层保持FP16CPU推理比FP32还慢旧CPU没有向量指令集检查VNNI/AVX512或仅量化计算密集层Windows下加载模型报“数字签名”或驱动问题显卡驱动过旧无法启用新算子优先更新NVIDIA驱动并开启硬件加速计划模型在INT4下满载通过但上下文一长就OOMKV Cache被低估把最大序列长度代入公式重新估算其中“上下文一长就OOM”是最容易被忽略的坑。很多人在短文本下测出显存够用就匆匆上线一旦用户开启长文档对话KV Cache瞬间膨胀服务直接OOM崩溃。这个在正式部署前一定要用最大允许的序列长度做一次压测。6.3 我个人现在的默认配置最后分享一套我正在用的默认配置不保证适合所有场景但可以当作出发点通用文本分类/相似度任务挑模型能量化到INT8就不选FP16准确率差异通常可以控制大语言模型生成任务业务线使用A100/H100用BF16本地调试用4090跑INT8或INT4 GGUF代码生成/数学推理这类模型对精确度很敏感在同样的显存空间里我宁可把上下文缩短一点也要保持INT8以上精度端侧模型固定INT4但嵌入层和输出头保留较高精度训练微调优先BF16如果设备只支持FP16先检查损失数值范围避免scale策略导致溢出。这五条就是我在真实项目中反复验证过的主线。精度和硬件的组合不是一道只有一个标准答案的选择题而是一套需要随着成本、质量、速度调试的工程流程。你问我“同一个模型该用什么精度、配什么硬件”我的回答依然是先把参数范围算出来再把候选组合放到真实业务测试集上跑一遍然后把答案交给数据而不是交给直觉。 
长河君 · 2026/10/7 6:45:13 · 阅读 1.2k 模型部署精度选择指南：从量化原理到硬件搭配
同一个模型该用什么精度、配什么硬件聊模型部署绕不开“精度”这两个字。我见过不少朋友拿到现成的开源模型第一反应是“直接用FP16跑”结果显卡显存不够也有朋友一拍脑袋直接量化到INT4速度是上去了但模型输出的质量肉眼可见地变差。这两个例子其实指向同一件事精度不是一个可以拍脑袋定的参数它和硬件显存、带宽、部署成本、业务延迟是绑在一根绳子上的。今天这篇文章就把这件事一次说清楚从精度档位到底是什么到显存怎么算再到不同硬件平台该怎么选组合最后落到一套可复现的验证流程上。无论你是第一次部署模型还是已经在生产环境里调过好几轮参数应该都能从里面找到用得上的方法。1. 先摆正坐标系精度选择本质是“任务约束下的权衡”1.1 三个指标决定你的精度选择同一个模型放在不同的任务里对精度的敏感度完全不同。最简单的例子用BERT做文本分类把FP32换成INT8准确率可能只掉0.1个百分点但用同一个Transformer架构做长文本生成INT8遇到一些长尾分布的表达就可能在某个片段突然崩掉。所以精度选择的起点不是“这个模型支持什么格式”而是你业务里最不能让步的那个指标。我先列三个约束条件你在选精度前得先把它们排好序质量底线任务指标允许掉多少比如分类准确率允许从98压到97.5还是完全不允许波动速度目标单次请求延迟要求多少毫秒每秒需要处理多少个请求成本边界能接受的单卡、单机成本是多少电费、云端按小时计费都算进去。这三个条件组合不同结论就不同。比如离线批量推理延迟不是主要矛盾那就可以放心上INT8甚至INT4换来相同时间内更多的任务量而实时交互、面向用户的搜索问答延迟和质量同样重要可能就要在INT8和FP16之间反复试探。1.2 训练和推理必须分开讨论很多文章讲精度喜欢把所有场景搅在一起说这是误导的最大来源。实际开发中训练、微调、推理三个阶段采用的精度和硬件逻辑是完全不同的。训练和微调阶段核心需求是梯度回传的稳定性。模型每一层都要保存激活值、梯度中间量如果数据精度太低数值很容易溢出或者截断训练就会不收敛。所以这个阶段主流选择是FP32、BF16这类浮点格式它们有足够大的动态范围来承载梯度的细小差异。推理阶段则相反权重已经固定不再需要反向传播我们只是把前向计算跑一遍。此时权重的数值范围是静态的可预测的这就为低位宽量化提供了基础。将一个FP32的权重转成INT8体积直接缩小到四分之一为什么能这么做因为神经网络对权重中不同数值的敏感度并不一样量化要做的事情就是在缩小体积的同时把最重要的数值分布保留下来。1.3 精度选择的反直觉点低精度经常带来“质变”这里有个反直觉的结论值得先讲出来在很多任务里低精度模型不是“能用就行”而是“能跑和不能跑”的分界线。举个例子。一个7B参数的模型FP16权重需要约14GB显存加上KV Cache和框架开销一张普通消费级24GB显卡可能刚好塞下;如果量化到INT4权重只要4GB左右在同样的卡上就能同时承载更大的并发批次甚至能做到长上下文的推理。CPU内存只有16GB的笔记本FP16根本加载不起来INT4量化后却能流畅跑对话模型。这种情况下精度已经不是质量取舍而是可行性本身。所以我的建议是先别问“哪个精度最好”先问“我这个硬件上哪个精度能跑起来、所需的吞吐量达不达标”再用实测去确认质量是否可接受。2. 精度全档位拆解FP32、FP16、BF16、INT8、INT4 各自的本利账2.1 一张表看懂主流精度格式的区别做部署选型至少要把下面这张表刻在脑子里精度类型存储字节动态范围特点与典型用途FP324字节约1e-38到3e38传统模型训练基线范围广但显存放不下大模型FP162字节约5.5e-5到65504范围偏窄训练时容易溢出推理速度尚可旧显卡支持最好BF162字节与FP32相同专为训练设计范围大但小数精度低适合梯度回传INT81字节-128到127推理主力体积小、速度快质量损失通常可控INT40.5字节大概-8到7极限压缩适合大模型上消费级显卡或手机端表中FP16的值上限是65504看着挺大但做训练时如果遇到Loss特别大的批次很容易出现梯度上溢。BF16把指数位拉回和FP32一样宽从根本上解决了训练中的范围问题代价是尾数位更少、有效小数位数变低。所以新一代训练框架里BF16基本成了默认选择不是因为它更准而是因为它不会让训练直接崩溃。2.2 整数量化到底在做什么很多人一听INT8就觉得“这数字小太多了肯定不准”其实整数量化不是简单把权重四舍五入到整数。量化核心是“映射”。我们把原始浮点权重中的最大绝对值作为一个缩放因子然后把所有权重按比例映射到整数范围。比如某个权重最大绝对值是2.5量化到INT8时1.0对应的整数大约就是51。推理时再把整数乘回缩放因子做反量化。整个过程涉及两个关键量一个是缩放因子scale一个是零点zero_point。这里要说清楚一个误区量化不只是针对权重还有激活值。权重是静态的可以先离线算好scale激活值却随输入变化所以更麻烦。于是又衍生了两种做法一种是权重只有INT8、激活保持FP16叫做“W8A16”另一种是权重和激活都量化成INT8叫做“W8A8”。前者容易做、兼容性高后者要做量化校准但对速度提升更明显。2.3 动态范围是精密仪器浮点范围是大平原整数则是分格子的仓库用一张图来描述FP32像一片大平原任何数值都能被高精度定位INT8像一个划分了256个格子的仓库绝大多数权重都能装进去但原本靠得很近的两个小数可能被塞进同一个格子里。神经网络对“同一格子里的小数”到底敏不敏感主要看权重分布。有的模型权重天然平缓、正态分布量化后损失很小有的模型却有明显的离群值比如某些神经元输出几千倍的异常大值这些离群值会把量化比例拉歪导致大多数普通权重被压缩到几个整数区间里信息大量丢失。这也是为什么同样一个量化方案换一个模型差别巨大的原因。处理离群值有专门的办法比如混合精度、per-channel量化、GPTQ/AWQ这类基于误差重建的量化算法。后面我会说这些工具怎么选。3. 算清硬件账显存占用、吞吐量和延迟到底从哪里开始算3.1 推理显存估算公式在选择精度和硬件搭配前至少要会估算一个模型跑起来会占多少显存。推理阶段显存主要由三部分组成显存占用 模型权重 推理中间状态KV Cache / 激活值 框架运行时开销推理时的模型权重很好算参数量乘以每个参数占用的字节数。注意参数单位是Billion要乘以10的9次方来算。举例7B参数模型INT8量化后有约70亿个参数乘以1字节约7GB权重FP16则约14GB。KV Cache是Transformer的“记忆体”。推理时每生成一个Token都要缓存前文的Key和Value参数量随序列长度线性增长公式大致是 KV Cache大小 ≈ 批大小 × 序列长度 × 层数 × 注意力头数 × 每头维度 × 2Key和Value各一份× 精度字节数这个数值动辄几个GB。如果跑长文本、大并发KV Cache甚至比权重占得更多。所以估算时别只看权重体积。下面用一段Python代码快速估算7B模型在不同精度下的显存下限def estimate_vram(params_b, dtype_bytes, kv_cache_gb0, overhead_gb1): weights_gb params_b * 1e9 * dtype_bytes / 1024**3 return weights_gb kv_cache_gb overhead_gb print(7B FP16:, round(estimate_vram(7, 2), 2), GB) print(7B INT8:, round(estimate_vram(7, 1), 2), GB) print(7B INT4:, round(estimate_vram(7, 0.5), 2), GB)运行结果是FP16约14GB权重加1GB开销约15GBINT8约7GBINT4约3.5GB。再加2GB的KV Cache三种精度对显存的需求分别是17GB、10GB、5.5GB。这一对比用什么显卡合适就一目了然了。3.2 延迟与吞吐量的真相决定速度的是带宽显存只决定“装不装得下”真正决定推理快慢的是两样东西算力FLOPs和显存带宽。自回归生成模型每一步生成一个Token都要把所有权重从显存读到计算单元里。假设7B FP16模型有14GB权重一块A100的显存带宽约每秒2TB那理论上读一次权重需要约7毫秒这7毫秒就是单次Token生成的物理下限。权重越小读得越快这就是低精度推理速度快的根本原因。如果模型权重是INT87GB权重在同样2TB带宽下读取只要约3.5毫秒速度直接翻倍。这也是为什么在同样一张卡上量化模型比高精度模型更适合做高并发服务。再强调一个关键概念Token生成是“内存带宽主导”的任务不是“算力主导”。所以一味堆一张算力极强的显卡但模型精度没降、权重没压缩延迟改善依然有限。反过来把精度从FP16降到INT4即使用较便宜的显卡也可能比原来的旗舰卡跑得更快。3.3 主流硬件平台参数对比下面列几个最常见的硬件平台我按推理场景给出参考定位。数值是公开规格的简化整理。硬件显存/内存显存带宽适合精度组合场景定位RTX 409024GB约1TB/sFP16/INT8/INT4本地开发、小规模服务RTX 309024GB约936GB/sINT8/INT4为主预算有限时的推理卡A100 80G80GB约2TB/sBF16/FP16/INT8大规模训练与高并发推理H100 80G80GB约3.35TB/sBF16/FP8/INT8顶级训练与吞吐场景中端CPU服务器几十GB~上百GB受内存通道限制INT8/INT4延迟要求不高、成本敏感的批量任务手机/嵌入式板子4GB~16GB系统内存带宽INT4/INT8端侧离线模型一个7B模型用FP16硬塞进RTX 4090可能只剩少量KV Cache空间并发只能开到1INT8后可以开更高并发或更长上下文INT4后经常能同时跑两个模型实例。选型时把精度、显存、并发这三者放一起考虑而不是单看某一项。4. 不同落地场景下的“精度硬件”组合策略4.1 数据中心高并发推理优先BF16/FP16与INT8混合在云端用A100/H100这类企业级显卡时很多人习惯直接上BF16理由是卡足够大。但这不够经济因为你真正卖的是“每秒钟能处理多少请求”。高并发推理的关键是尽可能提高GPU利用率。FP16/BF16权重计算精度高但占用带宽也高并发一旦上去KV Cache和权重加一块很快把显存打满。在实际服务里我见过不少团队采用“混合策略”入口用FP16做高敏感任务同时跑一个INT8实例做普通任务两个模型实例按请求属性分流这样能明显提升整体吞吐。如果使用vLLM这类推理框架还可以开启“量化感知的调度器”它会在同一张卡上管理不同精度的模型实例让显存碎片最小化。反正不要在A100上满怀信心地部署一个同学在4090上调好的FP16配置企业卡虽然显存更大但并发模型数、长上下文能力都需要重新压测。4.2 消费级显卡与本地工作站INT4和INT8是救命稻草本地工作站最常见的困境是一张RTX 4090想跑13B甚至几十B的开源模型。FP16肯定加载不了这时真的别硬扛。建议路径是这样先在Hugging Face模型库找GGUF格式的量化版本从INT8开始测试如果显存还是溢出就继续降到INT4甚至混合精度版本用llama.cpp或Ollama这类工具加载它能在CPU和GPU之间自动分配层。ollama跑一个示例命令ollama run qwen2.5:7b-instruct-q4_K_M这条命令会启动一个INT4量化的7B模型。大多数配置下4090跑它能达到很高的生成速度质量仅比FP16略降。你在本地做Agent、写代码辅助、处理一些只在本机运行的任务完全够用。如果太看重隐私想把模型完全放在本地又不想用云GPU那消费级卡配合INT4就是目前最实用的一条路。别总觉得量化就是“阉割版”4比特模型经过良好校准后很多任务表现和FP16几乎无差别。4.3 CPU与边缘设备把量化和算子优化一起做有些场景不允许用GPU比如金融数据安全要求高的内网或者工业现场的边缘盒子。CPU推理没有显存带宽优势内存带宽又受限必须靠极致的量化来压体积。CPU上一般用OpenVINO、ONNX Runtime或者llama.cpp。以ONNX Runtime为例如果模型导出时带动态量化就可用下面的方式在CPU上跑INT8推理import onnxruntime as ort sess ort.InferenceSession( model_int8.onnx, providers[CPUExecutionProvider] ) outputs sess.run(None, {input: input_data})关键是CPU平台对INT8支持的差异很大。有的指令集支持VNNI/AVX512走INT8会有明显加速没有这些指令集的旧CPU速度提升可能不如预期这时可以把部分层保留FP16或FP32只量化线性层、注意力层等计算密集部分。边缘场景更要看重“内存墙”。比如在树莓派、Jetson这类板卡上跑YOLO目标检测一般选INT8加TensorRT加速在手机端跑大语言模型则基本就是INT4起步。端侧硬件的内存和带宽都极有限精度每降一半意味着能加载模型的档次可能直接升一级。4.4 手机端与嵌入式INT4的天下但要注意激活值手机端的难点不只是显存更是功耗和发热。同样的模型在桌面端跑INT8就好在手机上却可能因为内存带宽太低而卡顿所以INT4通常成了唯一选择。不过手机端跑大模型时激活值最好保留为FP16也就是“W4A16”方案。穿越到一个低比特整数量化的激活层不仅速度不一定快还可能引发精度明显下降。很多开源模型跑端侧时部署框架已经默认把部分算子改成混合精度不是所有层都积极压到INT4。这类细节比单纯调一个量化等级影响大得多。5. 量化不是白给的钱实测验证与三个常见崩点5.1 量化后出现“AI味变重”的现象不是幻觉量化掉点最常见的表现不是模型完全不能用而是生成内容变得重复、割裂、或者突然冒出毫无逻辑的句子。这种问题在长文本生成里尤其明显因为某些离群权重在低比特下被截断激活值传递到堆叠层后误差逐步放大。遇到这种问题先不要否定整个量化方案而要检查三个环节是否用了合适的量化算法简单rounding直接四舍五入性能通常不如GPTQ、AWQ这类误差补偿算法校准集是否覆盖了真实业务场景如果模型要处理中文金融文本你却拿英文通用语料做校准量化scale自然偏掉是否所有层都被无差别量化了试试把敏感层比如最后的LM Head、前几层Embedding层保留FP16。5.2 校准集的选择直接影响成败量化校准的本质是用一部分真实数据来统计激活值的分布再决定scale和zero_point。因此校准集不能太小也不能和业务差异太大。我一般用500到1000条有代表性的样本涵盖真实业务里的长文本、短文本、特殊格式、边界情况。如果做代码模型就放更多复杂代码片段如果做聊天模型则要有不同语言风格、不同长度的问题。校准完成后一定要用另一组未见过的样本来做质量测试否则只优化了校准集而得出的表象根本骗不了线上流量。5.3 量化模型该怎么验证推荐“量化对比法”最稳妥的验证方法是“同源对比”用同一批输入分别跑FP16基线模型和量化模型然后对比关键指标。具体操作准备固定测试集至少一百条真实业务样例对分类模型记录准确率、F1等指标差对生成模型记录困惑度差值再看几条输出内容是否逻辑丢失判断误差是否在业务容忍范围内。对生成模型我常看两个冷门指标连续重复片段的次数、上下文一贯性。量化模型如果开始重复某些词组说明某个注意力层已经失真。还可以用这个Python片段快速计算两层模型输出之间的困惑度差距import math def perplexity(log_probs): return math.exp(-log_probs.mean()) base_ppl perplexity(log_probs_fp16) quant_ppl perplexity(log_probs_int8) print(PPL gap:, quant_ppl - base_ppl) # 一般差距在1以内可接受超过2就要谨慎这里的经验阈值是测得的困惑度差距小于1基本可放心上线超过2则建议把精度往高调一个档位或使用更复杂的量化算法。6. 我现在实际走一遍的操作顺序与踩坑记录6.1 三步决定法从硬约束到软验证我可以把这几年反复验证过的一套方法总结成“三步决定法”每次拿到新模型都走一遍。第一步确认硬件边界。查GPU显存、可用内存、CPU指令集算出各精度档位下的理论显存占用。用前面的公式填一次表格划掉装不下的选项。第二步选择默认起点。GPU够大且追求质量FP16或BF16起步GPU紧张INT8先试实在没显卡或想跑大模型INT4配合量化工具走一遍。第三步做量化对比验证。准备有代表性的业务测试集把FP16基线和量化结果跑一遍按第5.3节的方法判定是否接受。接受就上线不接受就往高精度或更复杂算法调整。这套流程看起来简单但能避免最频发的错误——直接在量化后看一眼输出“感觉还行”就上线结果线上被用户反馈说内容重复、敏感词识别漏掉。6.2 常见踩坑记录与规避方法我把部署过程中遇过的、高频出现的问题列在下面每一项背后都有过案例问题现象根因规避方法同一个INT8模型在一张卡上限并发是3另一张卡上限是7显存剩余不同KV Cache预留差异用框架的显存占用日志先测满负载量化模型输出有时莫名其妙重复离群权重被压缩改用AWQ或对敏感层保持FP16CPU推理比FP32还慢旧CPU没有向量指令集检查VNNI/AVX512或仅量化计算密集层Windows下加载模型报“数字签名”或驱动问题显卡驱动过旧无法启用新算子优先更新NVIDIA驱动并开启硬件加速计划模型在INT4下满载通过但上下文一长就OOMKV Cache被低估把最大序列长度代入公式重新估算其中“上下文一长就OOM”是最容易被忽略的坑。很多人在短文本下测出显存够用就匆匆上线一旦用户开启长文档对话KV Cache瞬间膨胀服务直接OOM崩溃。这个在正式部署前一定要用最大允许的序列长度做一次压测。6.3 我个人现在的默认配置最后分享一套我正在用的默认配置不保证适合所有场景但可以当作出发点通用文本分类/相似度任务挑模型能量化到INT8就不选FP16准确率差异通常可以控制大语言模型生成任务业务线使用A100/H100用BF16本地调试用4090跑INT8或INT4 GGUF代码生成/数学推理这类模型对精确度很敏感在同样的显存空间里我宁可把上下文缩短一点也要保持INT8以上精度端侧模型固定INT4但嵌入层和输出头保留较高精度训练微调优先BF16如果设备只支持FP16先检查损失数值范围避免scale策略导致溢出。这五条就是我在真实项目中反复验证过的主线。精度和硬件的组合不是一道只有一个标准答案的选择题而是一套需要随着成本、质量、速度调试的工程流程。你问我“同一个模型该用什么精度、配什么硬件”我的回答依然是先把参数范围算出来再把候选组合放到真实业务测试集上跑一遍然后把答案交给数据而不是交给直觉。