这篇博文主要围绕“同一个模型该用什么精度、配什么硬件”来展开。模型部署里精度选择和硬件匹配是绕不开的坎很多人在这一步踩坑要么显存不够直接爆掉要么精度选错导致速度反而不如低配机器要么量化后质量明显下降又找不到原因。这篇文章会把精度、显存、带宽、算力这几件事彻底讲清楚从原理到实操都给到可以直接用的判断方法和步骤。1. 先把精度这件事彻底掰开1.1 模型里的数字从FP32到INT4到底差在哪先说个基本认知神经网络本质是一堆数字在不同层之间做乘加运算。这些数字怎么存、怎么计算就是“精度”的核心。主流的精度格式按存储大小排下来大约是下面这一串。FP3232位浮点1位符号、8位指数、23位尾数。这是训练时的“默认标准”精度最高、范围最大但占空间也最大推理时基本不会直接用。FP1616位浮点1位符号、5位指数、10位尾数。体积只有FP32的一半但是指数只有5位表示范围小数值一大就溢出。它的一个典型问题是在训练时容易梯度溢出需要配合损失缩放。BF1616位浮点Brain Float1位符号、8位指数、7位尾数。指数跟FP32完全一样所以数值范围跟FP32几乎相同不需要担心溢出代价是尾数少了精度更低小数细节会丢。INT88位整数范围是-128到127。本身不直接存浮点而是把权重映射到整数区间计算的时候再反量化回浮点或者用整数运算直接加速。INT44位整数范围通常是-8到7。压缩比极高权重直接压到FP32的1/8这也是为什么一堆大模型能用几十GB显存跑起来的核心原因。一句话总结指数决定范围尾数决定精度。范围不够怕溢出尾数不够怕误差累积。BF16牺牲尾数保范围所以它特别适合大模型的训练和推理FP16范围小在旧架构上反而容易出问题INT8/INT4靠量化和反量化把浮点运算“伪装”成整数运算换来的是成倍的体积缩减。1.2 体积心算法拿到模型先算显存部署前最重要的第一件事就是估算模型权重要占多少显存。有一个特别简单的算法任何模型都能秒算权重显存 参数量 × 每参数字节数。各精度的每参数字节数列出来就是下面这张表精度每参数字节数7B模型权重72B模型权重FP324字节28GB288GBFP16 / BF162字节14GB144GBINT81字节7GB72GBINT40.5字节约3.5GB约36GB这张表是纯权重的大小。实际运行的时候还有三块东西要额外占显存KV Cache缓存注意力计算中的键值对上下文越长占越多激活值前向传播时的中间张量以及框架自身的缓冲区和CUDA context。我通常的估法是实际显存需求模型权重 × 1.3到1.5上下文短、batch小的时候接近下限如果是长对话、高并发翻倍也可能。举个例子你有一张16GB的卡跑7B模型的FP16版本权重14GB算上额外开销基本擦边刚加载完可能就15.5GB了对话一长KV Cache一涨直接OOM。这时候降到INT8权重7GB余量一下就出来了。这就是“同一个模型、不同精度、不同硬件”的第一层关系精度直接决定能不能装进去。1.3 量化到底损失了什么哪些场景不能忍很多人一听量化就担心质量问题。实际上现代量化算法做得相当好了。INT8量化在绝大多数任务里跟FP16几乎没有可感知的差距INT4在对话任务上差距也很小但代码生成、数学推理这类对精确数值敏感的任务INT4的退化会更明显。我自己实测过同一批模型在FP16和INT4下的表现结论大概是这样开放域对话、文案、摘要感知差异很小最稳。代码补全、函数调用缩进、括号、参数名偶尔会抽风需要小心。长逻辑链、数学题推理越来越长的时候误差累积会更明显结果就可能崩。多轮长对话上下文一长低位宽的量化误差会随着KV Cache累积回复质量下滑比FP16快。所以我的原则很简单机器能扛得住FP16/BF16就用高位宽显存吃紧再考虑INT8实在塞不下才上INT4。同时不要只看理论损失实际任务里测一测才知道。后面我会说具体怎么测。2. 硬件上真正卡脖子的不是算力是显存和带宽2.1 推理速度的真相Transformer在反复读自己这是一个很多人一开始不太理解、但极其关键的机制。大模型生成每个token时需要把模型的所有参数从头到尾过一遍。这意味着每生成一个token整个模型权重都要从显存里读一遍。所以推理速度有一个理论下限就是“模型权重大小 ÷ 显存带宽”。比如7B模型的FP16权重是14GB你的显卡带宽是1TB/s那么最快也就大约14毫秒出一个token换算成每秒大约70个token这已经是最理想的上限了。实际还要减去KV Cache读取、计算延迟、调度开销所以实测往往只有理论的五六折到七八折。这也解释了一个非常反直觉的现象为什么你的4080跑同一个模型可能还不如别人的3090快因为RTX 4080的显存带宽是736GB/s而RTX 3090是936GB/s。带宽高每秒钟能从显存里抠出来的权重就多token生成速度自然更快。算力在单卡小并发场景下的重要性远不如带宽来得实在。2.2 一份主流硬件的带宽和容量速查下面是几类常见部署平台的硬件参数速查重点看“带宽”和“显存/内存容量”两列。平台典型型号带宽容量适合跑的模型规模消费级NVIDIARTX 4090约1.0TB/s24GB7B-14B高位宽32B INT470B靠Offload很勉强消费级NVIDIARTX 3090约936GB/s24GB同上带宽略低消费级NVIDIARTX 4080 Super约736GB/s16GB7B高位宽13B/14B INT4消费级NVIDIARTX 4070约504GB/s12GB7B INT8/INT4数据中心A100 80G约2.0TB/s80GB70B INT434B FP16高并发服务数据中心H100 80G约3.35TB/s80GB70B INT4/FP8高并发低延迟Apple SiliconM2 Ultra约800GB/s最高192GB70B INT4印象流但实测能跑Apple SiliconM2 Max约400GB/s最高96GB32B/34B INT470B勉强CPU内存DDR5双通道约60-80GB/s64GB以上7B-14B INT4速度较慢但能跑边缘设备RTX 2000 Ada约256GB/s16GB7B INT4功耗低这里要特别注意一点纯看容量也不行还要看带宽和容量是否匹配。比如某张卡有16GB但带宽只有288GB/s跑7B FP16能装下但慢得让人怀疑人生因为每个token要把14GB的权重过一遍288GB/s的带宽意味着最快也要约50毫秒一个token实际体验远不如带宽更高、容量小一点的配置。2.3 显存、带宽、算力到底先看哪个很多人挑硬件只看显存这是一个误区。显存只决定“能不能装下”带宽决定“生成token的速度上限”算力决定“文件吞吐和并发处理能力”。三者的优先级在不同的场景下压根不一样。单用户聊天、本地呼模型带宽 显存 算力。因为生成token是权重密集型的串行读取算力经常闲着。你开个模型问一句、答一句GPU算力占用可能只有20%但显存带宽已经拉满了。多人并发API服务算力 显存 带宽低延迟时。多个用户同时请求时GPU可以把一批请求聚合在一起算一次性读取的权重可以服务多个序列算力利用率上来了算力就变主导了。这也是为什么同样是70B INT4单卡个人用A100很爽高并发商用就必须上H100这种高算力卡。离线批量推理比如一次跑几万条数据算力 带宽 ≈ 显存。批量推理本身就是计算密集型的算力越高总吞吐越高。所以选硬件前先问自己我是个人聊天体验优先还是多人服务吞吐优先还是离线批量跑任务。场景不同结论天差地别。3. 几种典型配置的实战拆解3.1 消费级显卡的甜点位16GB和24GB怎么选到2025年的今天消费级显卡在本地模型圈子里24GB是相当舒服的甜点容量典型就是RTX 4090和RTX 3090。这两个卡的逻辑是14GB以内的模型用FP16/BF16无压力跑32B、34B级别的模型用INT4刚好上下文还能开个几千到上万。带宽都在1TB/s上下7B模型的反应速度快到几乎没有感知延迟。16GB的卡比如4080 Super、4070 Ti Super定位就微妙一些。它能跑7B的FP16但余量不大跑14B的INT4很稳跑32B的INT4就要看模型装不下就得到CPU内存做offload速度直接掉到十几甚至几token每秒体感很差。所以如果你的核心需求是“本地最舒服地跑7B-14B模型”16GB够用如果还想碰32B、34B直接上24GB。这里必须提醒一件事照着你买显卡的用途来。如果还兼顾游戏、渲染这些优先看算力和显存如果基本就是跑本地模型那就别光看颜值和算力把带宽排到选择标准的第一位。RTX 4060 Ti的16GB版本就是个反面教材显存够但带宽只有288GB/s跑LLM简直是慢性毒药。3.2 数据中心卡与多人场景A100还是H100如果目标是给团队或者线上业务跑一个模型服务情况就完全不同了。这时候决定体验的是“每秒能处理多少个并发请求”和“每个请求首字延迟多少”而不是一张卡单跑一个模型有多快。A100 80G的经典用法是70B/72B模型做INT4量化权重36GB左右一张卡轻松装下带宽2TB/s单请求生成速度的理论上限大约在55 token/s级别几十B的模型则可以FP16直接跑精度无损失。这个配置非常适合中小团队用vLLM或者SGLang开一个API服务并发十几到几十路基本无压力。H100 80G更猛但它的优势主要体现在大批量并发上。同样跑70B INT4单路速度不一定比A100快太多但在同样的延迟容忍下能扛的并发数高出一截因为它的算力是A100的数倍。如果你的业务并发峰值很高H100的性价比才真正体现出来如果只是几十人用的小服务A100甚至两张3090做张量并行都够了。再补充一个容易被忽视的点显存足够时优先用更高位宽而不是更低量化。A100跑70B INT4很爽但如果任务对质量敏感有条件就上FP8甚至BF16的70B代价是需要更大显存或两张卡做并行。别因为“INT4能装下”就固守INT4硬件有余量时精度该升级就升级。3.3 Apple Silicon的统一内存看起来很大但别被数字带偏Mac上的M系列芯片是个很有意思的特例。它的最大优势是“统一内存”也就是说CPU和GPU共享同一块内存不像NVIDIA那样显存和系统内存分开。买一台96GB或者128GB统一内存的Mac跑大模型的“显存”就真的有这么多这对部署70B以上的大模型非常友好。但两个坑要认清。第一Mac统一内存的带宽做了分层M2 Max约400GB/sM2 Ultra约800GB/s但普通MacBook Air的基础款只有约68GB/s。跑7B FP16时理论最快速度甚至不到10 token/s完全不可用。第二Mac的显存带宽再高也远低于A100的2TB/s所以即便内存容量大到能装下70B INT4生成速度也就二三十token每秒适合资料离线推理和轻度对话不适合高交互场景。如果你确实想在Mac上跑模型我的建议是用MLX框架或者llama.cpp的Metal版本不要用PyTorch原生的MPS后端的LLM代码前者针对Apple Silicon做过大量优化实测速度快很多。量化层面依然是老套路容量不够就降精度但注意Mac的QUIC融合在INT4下常见质量损失能跑INT8尽量INT8。3.4 CPU和边缘设备量化还是量化有些场景摆明了没有独立显卡比如公司老服务器、工控机、嵌入式板子。这时候能不能跑模型能但必须老老实实走低精度路线。CPU推理有一个特点算力一般还行但内存带宽非常有限。以双通道DDR5为例带宽大约60-80GB/s跑7B模型的INT4权重约3.5GB理论最快约50毫秒一个token也就是每秒20个token能凑合用如果跑FP1614GB理论最快约200毫秒一个token每秒5个token等得崩溃。所以CPU场景INT4几乎是必选项。边缘设备我比较常用的是Jetson系列比如Orin Nano、Orin NX和带NPU的开发板。这类硬件往往把神经网络算子做成了固定精度的IP核比如只支持INT8。说白了不是你想用FP16就能用而是硬件只认INT8这就需要在训练时做量化感知训练QAT或者在部署时做合理的后训练量化PTQ精度损失控制得好推理效果依然可用。边缘设备部署精度策略完全由硬件算子支持清单决定买板子之前一定要看官方文档里的算子精度支持表。4. 实操流程从选精度到跑起来4.1 第一步估算显存和带宽先过一遍账拿到任何模型我建议先花五分钟做一次预算。查参数量Hugging Face模型卡上通常会写比如7B、14B、32B、72B。用我前面给的表算权重体积。加上30%-50%的额外开销得到最低建议显存。看你这张卡/这台机器的带宽用“权重体积 ÷ 带宽”粗算每秒token生成上限。这个上限就是你的体感速度天花板。如果算出来每秒只有七八个token那不管调什么参数都救不回来该换硬件或者换更小模型了。先算账再动手能避免大量无意义的折腾。4.2 第二步怎么选量化工具GPTQ、AWQ还是GGUF市面上主流量化方案主要三大类别选错方案适用场景特点GPTQNVIDIA GPU为主配合vLLM、AutoGPTQ稳定生态成熟适合部署API服务INT4质量好AWQNVIDIA GPU为主硬核优化适合高吞吐服务低bit量化下质量好但拼装和推理框架支持略复杂GGUFllama.cpp量化全平台特别是Mac、CPU、低内存环境灵活可随时调节量化级别q2_k到q8_0llama.cpp、Ollama都基于它bitsandbytes的8bit/4bitHugging Face生态快速验证简单粗暴但速度、质量和对多GPU的适配都不是最优我的经验是本地个人用首选GGUF因为它几乎能在任何地方跑llama.cpp的优化也很好量化级别丰富正经部署API用GPTQ或AWQ配vLLM吞吐和并发能力更强。bitsandbytes更多是用来做实验验证不适合线上。具体实操步骤我用GGUF举例。先从Hugging Face找一个已经量化好的GGUF文件或者自己用llama.cpp对完整模型做量化。后者适合那些官方没提供量化版的模型# 1. 克隆llama.cpp并编译 git clone https://github.com/ggerganov/llama.cpp cd llama.cpp cmake -B build -DCMAKE_BUILD_TYPERelease cmake --build build --config Release -j # 2. 把Hugging Face格式的模型转成FP16的GGUF python convert_hf_to_gguf.py /path/to/model --outfile model-f16.gguf --outtype f16 # 3. 量化到INT4q4_k_m是最常用的平衡点 ./build/bin/llama-quantize model-f16.gguf model-q4_k_m.gguf q4_k_m量化完直接用Ollama或者llama.cpp加载就行。我习惯把q4_k_m作为基准先试质量不够再往上调q5、q6、q8够用就好。4.3 第三步跑起来之后怎么判断瓶颈在哪儿模型跑起来之后别光凭感觉“快一点慢一点”。NVIDIA显卡用nvidia-smi能看两件关键事GPU利用率注意不是显存占用和显存带宽利用率不同驱动版本显示的字段不一样有的叫“Memory Utilization”有的看nvidia-smi -l 1里的相关行。最典型的两种状态显存占用高但GPU算力利用率不高说明卡在带宽上。模型权重读取不过来。解决办法是降精度、压缩上下文、减小batch让每次从显存里搬的字节变少。GPU算力利用率持续拉满说明运算量是真的大。可能你开高了并发或者batch开太大AI画图之类的任务也类似。这时候降精度未必有太大帮助反而要调整并发数和推理框架参数。另外还有一个小技巧对比不同精度的实测速度把“权重体积 ÷ 实测每秒token数”算一下得到的就是“每token实际读取的数据量”。这个值越接近你的显卡带宽说明推理框架优化得越好、越接近理论极限。如果这个值只有带宽的三四成那要么换框架要么检查是不是KV Cache和激活值拖了后腿。5. 常见问题速查表整理一下我平时被问到最多的问题做成一张速查表。现象原因处理建议模型加载时CUDA out of memory权重太大显存不够换INT4/INT8、降低上下文长度、用Offload到CPU或换更小模型卡上能装下但是生成很慢带宽不足权重读取太慢降精度缩小权重体积、减小batch、关掉长上下文的KV Cache缓存策略考虑换更高带宽卡量化后质量明显下降低位宽或量化校准集质量差换Q6/Q8量化、用AWQ/GPTQ替代简单量化、对敏感任务测试4090跑了一个小时GPU利用率才30%单请求推理算力本来就不是瓶颈正常现象别焦虑如果要提吞吐加并发BF16在2080/3080上反而慢老架构不支持BF16的Tensor Core加速换FP16或者直接上INT8量化Mac上显存明明够用还是崩溃统一内存被系统占用太多关掉其他大内存应用、用Ollama自动管理显存、降低KV Cache跑批处理时快时慢数据长度差异大GPU pad开销调整batch内的最大长度策略做长度分组列出来之后大多数问题都能归到根上不是精度不够就是带宽不够要不就是框架没吃满硬件能力。排查的时候不用急着动模型先看是显存、带宽还是算力的问题对症下药。6. 一段个人的经验补充别做“跑分党”要建自己的基准最后分享一点我自己的操作习惯。很多人拿到新模型先看跑分表格什么每秒多少token、首字延迟多少这些数字有参考价值但未必贴合你的场景。我的做法是给自己建一套固定的评测基准。把同一个模型的不同精度放在固定的几个任务里跑一段长文档摘要、一段代码补全、一个有追思链条的逻辑推理、一轮多轮对话。然后把每个精度下的回答质量、速度、显存峰值都记到一张表里。这样每次换硬件、换量化时都能用同一把尺子对比。前几次记录你会意外发现优化空间往往不是来自换个更好的卡而是来自“换个更合适的精度”。还有一个容易被忽略的点精度不是孤立的它和上下文长度、batch大小、模型结构比如注意力头数不同都会互相影响。同样INT4一个支持长上下文的模型和一个只支持4K上下文的老模型KV Cache的开销天差地别。所以任何结论都应该贴着你的具体模型去找别套万能公式。这个内容后续再扩展的话可以往两个方向走一是深入量化原理看懂校准集、贪心压缩和误差重建算法二是研究多卡并行方案把大模型拆到几张卡上跑。但无论怎么扩展最核心的判断框架就是本文这套“容量→带宽→算力→质量”的四步决策法先把这把尺子握在手里后面探索什么方向都不会跑偏。