做模型部署和推理优化这些年，我见过太多人卡在同一步：模型训练好了，也验证过了，一到落地阶段就开始纠结——同一个模型，到底该用什么精度跑？该配什么硬件才合适？这个问题看起来简单，实际上牵扯到浮点数的存储规则、显存的斤斤计较、带宽和算力的匹配关系。选错精度，要么模型跑不快，要么显存直接爆掉；选错硬件，轻则卡顿，重则压根跑不起来。

这篇文章我想把这条线的完整思考逻辑讲清楚：精度是怎么影响模型大小和推理速度的，硬件哪些参数真正决定你能跑什么规格的模型，以及怎么根据不同场景搭配出一套足够稳的方案。不管你是做本地大模型部署，还是在搞嵌入式边缘设备，这套方法都适用。

1. 精度选择的底层逻辑：先搞清楚你花的每一分显存都在哪里

1.1 模型参数的存储原理：FP32、FP16、BF16到底差多少

先说个最基础的换算关系，这个账算不清楚，后面全是糊涂账。一个模型参数按字节数换算：FP32精度占4字节，FP16和BF16各占2字节，INT8占1字节，INT4一个参数只要半个字节（实际量化后是打包存储的）。转成我们熟悉的说法，一个70亿参数的模型，FP32权重大概28GB，FP16和BF16是14GB，INT8是7GB，INT4大概是3.5GB到4GB。

这几个数字意味着什么？假设你手里只有一张24GB显存的消费级显卡，跑13B模型用FP16需要26GB，直接装不下；但如果你把精度降到INT8，只需要13GB，瞬间就宽裕了。很多人上来就问“这张卡能跑多大的模型”，其实问题不是“多大”，而是“什么精度”。

FP32、FP16、BF16之间的区别不只是字节数。FP32是完整的单精度浮点，动态范围和有效精度都最好，但显存占用实在太大。FP16精度够用但动态范围窄，训练时很容易梯度溢出，所以现在训练场景更多人用BF16——它的指数位和FP32一样多，动态范围大，尾数位少一些，对深度学习来说这个取舍很划算。但有个坑：BF16的计算支持不是所有硬件都有，老显卡可能只支持FP16不支持BF16，选错了轻则性能下降，重则直接报错。

1.2 量化精度：INT8和INT4是怎么把模型塞进小显存的

量化是另一条路。INT8就是把每个权重值映射到一个8位整数空间，背后的原理是浮点数相邻的数值分布有规律，可以通过缩放因子和零点把一个区间映射到整数坐标上。直观理解就是：原来四个字节记一个小数，现在一个字节记一个近似的整数，精度降了，但体积缩了四倍。

INT4更狠，单个参数只用4位，相当于半个字节。但INT4量化不能像FP16转BF16那样直接截断，一般需要做分组量化——比如按64个参数为一组，共享一组缩放因子和零点偏移。这种做法的代表技术就是GPTQ、AWQ这类，它们能在大模型上做到4比特量化后损失很小。

这里我特别提醒一句：量化不是简单的“精度换体积”，还牵涉到硬件支持。如果你的卡不支持INT8或INT4的加速指令，量化后的模型反而可能更慢，因为推理框架要先把整数权重解量化成浮点数再计算，多了一道开销。这个问题后面会详细说。

1.3 更本质的追问：精度决定的不只是体积

我早期做部署的时候也犯过蠢，以为精度只是显存问题。后来在工程现场被“教做人”的次数多了才明白，精度选择实际影响的是三个维度：显存占用、推理速度、精度损失。这三者构成一个三角关系，你把任何一边压到极限，另外两边都会付出代价。

举个具体例子。同一个7B模型，在消费级显卡上，FP16推理每个token大概30到40毫秒，INT8可能做到25毫秒左右，INT4也许能到20毫秒出头。但模型输出质量会有细微下降，尤其在长文本生成、逻辑推理这类任务上表现更明显。我实测过不少模型，INT8在很多任务上几乎无损，但INT4在代码生成、数学推理这类场景上，错误率会肉眼可见地上升。

所以结论很明确：精度不是一个“越低越好”或“越高越好”的单选题，而是你根据硬件条件和使用需求做出的折中方案。

2. 硬件匹配的思考框架：算力、显存、带宽的三角关系

2.1 一张显卡真正需要看的三个数字

很多朋友选硬件只盯着显存容量，这是最常见的误区。我自己的经验是，评估一张卡能不能胜任某个模型的推理任务，要看三个数字：显存容量、显存带宽、计算能力（FP16或INT8的算力）。

显存容量决定你装不装得下模型，这个最直观。显存带宽决定你推理的速度上限——尤其对大语言模型而言，因为生成每个token都要把全部权重读一遍，如果带宽不够，算力再强也白搭。计算能力则决定你实际做矩阵乘法的上限速度，但除非你跑超高并发或者超大batch，否则它往往不是第一瓶颈。

可以打个比方：显存容量像仓库面积，决定你能囤多少货；显存带宽像仓库门口的道路宽度，决定你每小时能运多少货出去；算力像叉车数量和速度，决定货从货架上搬下来有多快。对大语言模型推理来说，道路宽度才是真正的生死线。

2.2 为什么带宽往往比算力更先卡脖子

我遇到过一个很典型的案例：有人用一张理论算力很高的计算卡跑7B模型，结果每秒只能生成十几个token，跑得更慢。查了半天发现，问题出在显存带宽上——那张卡主打算力，但带宽相对平庸，而LLM推理恰恰是带宽敏感型任务。

具体算一下你就有概念了。7B模型FP16是14GB权重，每生成一个token就要完整读一遍。假设你想达到每秒30个token，那么显存带宽至少需要14GB乘以30，大概是420GB/s。这只是理论最低值，还没算KV cache和中间激活的开销，实际需求会比这个高30%以上。

反过来看INT4，7B模型约3.5GB权重，同样每秒30个token只需要105GB/s带宽，门槛一下子低了很多。这也是为什么同一张卡，INT4跑大模型可能比FP16流畅很多的核心原因。带宽这个参数，在选型的时候建议把它放在显存容量之后第二位考虑。

2.3 多卡协同的性价比账

还有一个绕不开的话题：单卡装不下怎么办？很多人第一反应是上多卡，用并行方案把模型切到两张卡上。这个方案技术上没问题，但一定要算清楚性价比账。

多卡并行不是免费的。两张卡之间通信要走PCIe或者NVLink，每走一次通信都有延迟和带宽开销。如果你的卡只支持PCIe连接，模型切分后通信开销往往大得惊人——层间并行还能接受，张量并行的话通信量会爆炸式增长。我见过有人用两张中端卡拼起来跑一个中等模型，结果速度还不如一张老旗舰卡直接跑INT4。

我的建议是：先尝试把精度降一档，把模型塞进单卡，实在塞不进去再考虑多卡。能用单卡解决问题，绝不轻易上双卡。多卡方案适合的场景是：显存差距不大、模型层数很深、量化后精度损失已经不可接受。

3. 不同场景下的精度与硬件搭配方案

3.1 大模型本地部署：FP16还是INT8/INT4怎么选

大模型本地部署是目前最多人踩坑的领域。我的经验是分三档看：卡富余、卡刚好、卡很紧张。

显卡显存完全够的情况下，优先用FP16或BF16，不折腾量化。比如24GB显存跑7B模型，FP16占14GB，还有10GB余量给KV cache和上下文窗口，这是最稳的配置。BF16和FP16在本机推理上感知不出差别，但要注意老些的卡不支持BF16，跑不起来的时候先换FP16试。

显存刚好够或者差一点，上INT8。7B模型INT8占7GB，加上KV cache，12GB到16GB的卡就能跑得很舒服。INT8精度损失在大模型上通常很小，我对比过很多任务，个别case有细微差别，但整体可用性很高。

显存明显不够，比如只有8GB显存甚至核显，那就只能INT4 + 大幅限制上下文长度。4GB起始占用加上KV cache，8GB的卡也能跑7B小量化模型，但速度和质量都要接受妥协。另外还要限制上下文长度，比如从默认的4096降到2048，不然KV cache会把剩余的显存空间吃光。

3.2 视觉与多模态模型的推理优化

视觉模型和多模态模型跟纯文本大模型有个关键区别：除了权重，还要吃高分辨率的图像输入，激活值占用远高于文本任务。我跑过一些视觉-语言模型，固定权重用INT8很稳，但图像编码器部分一旦量化，从图片里提取特征的精度会明显下降，进而影响整体输出质量。

所以我的建议是分开处理：权重部分可以量化到INT8，图像编码器尽量保持FP16或FP32。好在主流推理框架都支持按模块单独设置精度，不用整模型一刀切。

另外视觉模型推理对算力要求也比纯文本高不少，因为图像特征提取的卷积操作不像自回归那样严重依赖带宽。这时候同样是INT8，算力高和算力低的卡差距就非常明显了。选卡的时候要综合看算力和带宽，不能只看一个指标。

3.3 边缘与嵌入式设备的INT8现实

嵌入式场景是另外一个极端。我调试过不少基于ARM架构的边缘盒子和开发板，它们的算力跟桌面显卡完全不是一个量级，显存/内存也少得可怜，但推理实时性又有硬要求。在这样的设备上，INT8几乎不是选择题而是必选项，关键要选对推理引擎。

不同推理引擎对INT8的优化程度差别很大。主流的方案中，TensorRT对NVIDIA系列硬件支持最好，OpenVINO适合Intel平台，ONNX Runtime的CPU后端通用性最强但优化相对保守。同一个INT8模型，在支持硬件指令优化的引擎上跑，速度可能比通用引擎快两三倍。

嵌入式还有一个大坑：硬件加速单元的驱动和算子支持不完整。你量化好模型，结果发现某些层没有对应的INT8加速算子，被回退到CPU算浮点，速度瞬间掉到不可用。我的排查习惯是在实机上一层层跑，看每层的推理耗时，找出来到底哪些算子在拖后腿。

3.4 训练与微调场景的混合精度与硬件搭配

训练和微调的精度策略与推理完全不同。推理追求的是速度和显存压缩，训练更看重精度稳定性与梯度更新的可靠性。现在主流的做法是混合精度训练，即权重和梯度用FP32保存，计算过程用FP16或BF16加速，关键步骤用FP32做校对更新。

微调阶段有个非常容易踩的问题：直接载入INT8/INT4量化后的权重做微调。做法上虽然可行，但你实际上微调的是量化误差体系，模型收敛到真正最优解的概率很低，效果往往不如用FP16权重微调后再量化。我的经验是：训练、微调用FP16/BF16，部署再用INT8/INT4，这是最佳实践路径。

硬件方面，训练场景除了显存容量，还要重点看算力精度支持。部分低精度优化指令只存在于特定架构上，例如某些卡对FP16有专门加速单元，对BF16的加速就弱一些。训练卡选型时记得查架构的白皮书，别只看显存。

4. 实操：从“不知道选什么”到“明确方案”的四个步骤

4.1 显存需求估算的数学方法

很多人问“这个模型要多少显存”，我给一个可以照着算的方法。先看模型参数，假设是P亿参数，那么FP16权重占用就是2P×10^8字节，也就是2GB乘以P。一个13B模型，FP16约26GB。然后加KV cache：2 × batch_size × 层数 × 每层KV维度 × 序列长度 × 2字节（FP16情况）。最后加激活值和框架开销，一般预留20%余量。

实际操作中，不用算得特别精确，有个粗估公式就够用了：总显存需求 ≈ 权重占用 × 1.3 + 2 × batch_size × 序列长度 × 隐藏层维度 × 层数 × 精度字节数。这个公式对主流Transformer架构都适用，至少在选卡阶段足够准确。

我建议你有条件的话，直接在本机用小脚本打印模型的参数量分布，逐一对应到显存占用。实测比任何估算公式都准，因为有些模型带额外的embedding层、多个专家模块，这些不会从表面参数量上看出来。

4.2 精度损失的可接受度评估方法

在动手量化之前，先构建一个“质量评估基线”。我的做法是：用FP16模型跑一组固定测试题（包含摘要、代码、数学推理、中文理解四类），记录每一类的输出质量分数。然后用量化后的模型跑同样的题目，对比分数差。这个差值就是精度损失的量化体现。

关键点是测试题的数量要均衡，不要只测10道题就下结论。我一般至少跑50到100道，否则噪声太大，很难判断是量化的锅还是生成随机性的锅。另外，对比的时候建议固定随机种子，并关掉采样参数，让输出尽量可复现，不然误差会淹没真实差异。

如果评估结果显示可接受，再上量化方案。不可接受，就退回更高精度的档位，或者考虑混合精度——比如只量化网络中不太敏感的部分（通常是MLP层），保留注意力层为FP16。

4.3 实测对比方法论：延迟、吞吐、显存峰值

硬件方案敲定后，真正的考验才开始。我实测每个候选方案时，记录三个指标的统一口径：单token延迟（首token延迟）、稳态吞吐（每秒生成token数）、显存峰值占用。这三个指标的测量方法不能乱，不然数据没法对比。

单token延迟要测“从发送prompt到产出第一个token的时间”，这个指标决定用户感知的响应速度。稳态吞吐要测连续生成64或128个token的平均耗时，反映长文本生成能力。显存峰值用监控工具全程记录，看它是不是真的在限定范围内，避免上线后突然OOM。

我自己有个习惯：每种精度与硬件组合至少跑三轮，取中位数而非平均值，因为平均值容易被偶发的调度波动污染。三轮跑完数据一对比，选哪个方案一目了然。

4.4 一个典型的选型案例拆解

分享一个我经手的真实案例。需求方的目标是在一台已有设备上，本地部署一个13B模型做企业内部的文档摘要。设备是一张16GB显存的显卡，CPU和内存都一般。一开始他们想直接上官方FP16版本，但16GB根本装不下26GB权重。目标明确后，我们还是按老路子先估算：13B模型INT8权重13GB，INT4权重约7GB，加上KV cache都要占用空间。

我先在INT4档位跑了一遍质量评估，50道文档摘要题，输出可读性还是可以的，但数字类事实存在张冠李戴现象。于是调整方案，使用AWQ直接对原模型做4位量化，再用一组来自目标领域文档的语料做校准。这一改动明显提升了摘要的准确率，代价是准备校准集多花了两天时间。

最终方案确定为：AWQ量化到INT4，上下文长度限制在4096，实测吞吐约每秒18个token，显存峰值9GB左右，留了足够余量。这套方案稳定运行三个多月，没有出现OOM，输出质量用户也认可。这个案例再次验证了我的结论：大多数时候问题不是“硬件不够”，而是“精度方案没选对”。

5. 常见问题与排查技巧实录

5.1 常见问题速查表

我把实际调试中高频出现的问题整理成了一张表，方便你直接对照排查。

这个表格排查我踩坑无数才整理出来，每次在新设备上部署模型，我都会先看这张表再动手。

5.2 避坑经验分享

第一坑：把“模型能加载”当成“模型能跑”。我遇到过不少案例，模型加载进了显存，但一旦生成token显存就暴涨直接崩溃。原因是推理时的激活值、KV cache会动态申请显存，而很多人没留这部分余量。建议加载前先算好静态余量，至少保留20%以上空余。

第二坑：量化校准集随意选。INT4量化虽然已经比较成熟，但校准数据跟目标领域偏差太大，效果一样会崩。比如你用中文法律文本做校准，却去跑英文代码生成，calibration就是一个严重失真的过程。校准数据不要求多，但一定要与真实使用场景接近。

第三坑：优先考虑官方或成熟第三方提供的量化版本，再考虑自行量化。现在很多模型发布时会同时提供FP16和量化版本，这些版本经过广泛测试，比自己从零量化省很多事。自行量化更适合那些冷门模型，或者是目标领域敏感、需要单独校准的场景。如果模型已经有稳定可用的量化版本，别浪费时间重复造轮子。

最后聊两句实在的。我做了这么久的模型部署和硬件适配，最大的体会是，精度和硬件选择从来不是一个可以一劳永逸的答案。同样的模型，在不同时期、不同预算、不同使用场景下，最优方案完全不一样。关键是掌握一套能从“目标倒推参数”的思路，先想清楚自己最不能牺牲什么——是响应速度、是输出质量、还是部署成本——然后再去对照精度档位和硬件规格做选择。下次再有人问你“这个模型该用什么精度、配什么硬件”，至少你能直接反问他一句：你手上是什么卡，你打算花多少电费跑它，你每天要处理多少条请求？答案往往就在这三个问题里。