企业官网建设流程全解析

这篇博文主要围绕“同一个模型，该用什么精度、配什么硬件”来展开。模型部署里精度选择和硬件匹配是绕不开的坎，很多人在这一步踩坑：要么显存不够直接爆掉，要么精度选错导致速度反而不如低配机器，要么量化后质量明显下降又找不到原因。这篇文章会把精度、显存、带宽、算力这几件事彻底讲清楚，从原理到实操都给到可以直接用的判断方法和步骤。

1. 先把精度这件事彻底掰开

1.1 模型里的数字，从FP32到INT4到底差在哪

先说个基本认知：神经网络本质是一堆数字在不同层之间做乘加运算。这些数字怎么存、怎么计算，就是“精度”的核心。主流的精度格式按存储大小排下来，大约是下面这一串。

FP32（32位浮点）：1位符号、8位指数、23位尾数。这是训练时的“默认标准”，精度最高、范围最大，但占空间也最大，推理时基本不会直接用。

FP16（16位浮点）：1位符号、5位指数、10位尾数。体积只有FP32的一半，但是指数只有5位，表示范围小，数值一大就溢出。它的一个典型问题是在训练时容易梯度溢出，需要配合损失缩放。

BF16（16位浮点，Brain Float）：1位符号、8位指数、7位尾数。指数跟FP32完全一样，所以数值范围跟FP32几乎相同，不需要担心溢出，代价是尾数少了，精度更低，小数细节会丢。

INT8（8位整数）：范围是-128到127。本身不直接存浮点，而是把权重映射到整数区间，计算的时候再反量化回浮点，或者用整数运算直接加速。

INT4（4位整数）：范围通常是-8到7。压缩比极高，权重直接压到FP32的1/8，这也是为什么一堆大模型能用几十GB显存跑起来的核心原因。

一句话总结：指数决定范围，尾数决定精度。范围不够怕溢出，尾数不够怕误差累积。BF16牺牲尾数保范围，所以它特别适合大模型的训练和推理；FP16范围小，在旧架构上反而容易出问题；INT8/INT4靠量化和反量化把浮点运算“伪装”成整数运算，换来的是成倍的体积缩减。

1.2 体积心算法：拿到模型先算显存

部署前最重要的第一件事，就是估算模型权重要占多少显存。有一个特别简单的算法，任何模型都能秒算：权重显存 = 参数量 × 每参数字节数。

各精度的每参数字节数列出来就是下面这张表：

这张表是纯权重的大小。实际运行的时候，还有三块东西要额外占显存：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 一份主流硬件的带宽和容量速查

下面是几类常见部署平台的硬件参数速查，重点看“带宽”和“显存/内存容量”两列。

这里要特别注意一点：纯看容量也不行，还要看带宽和容量是否匹配。比如某张卡有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/s，M2 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，能凑合用；如果跑FP16（14GB），理论最快约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

市面上主流量化方案主要三大类，别选错：

我的经验是：本地个人用，首选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_TYPE=Release 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. 量化到INT4（q4_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. 常见问题速查表

整理一下我平时被问到最多的问题，做成一张速查表。

列出来之后，大多数问题都能归到根上：不是精度不够就是带宽不够，要不就是框架没吃满硬件能力。排查的时候不用急着动模型，先看是显存、带宽还是算力的问题，对症下药。

6. 一段个人的经验补充：别做“跑分党”，要建自己的基准

最后分享一点我自己的操作习惯。很多人拿到新模型先看跑分表格，什么每秒多少token、首字延迟多少，这些数字有参考价值，但未必贴合你的场景。我的做法是给自己建一套固定的评测基准。

把同一个模型的不同精度，放在固定的几个任务里跑：一段长文档摘要、一段代码补全、一个有追思链条的逻辑推理、一轮多轮对话。然后把每个精度下的回答质量、速度、显存峰值都记到一张表里。这样每次换硬件、换量化时，都能用同一把尺子对比。前几次记录你会意外发现，优化空间往往不是来自换个更好的卡，而是来自“换个更合适的精度”。

还有一个容易被忽略的点：精度不是孤立的，它和上下文长度、batch大小、模型结构（比如注意力头数不同）都会互相影响。同样INT4，一个支持长上下文的模型和一个只支持4K上下文的老模型，KV Cache的开销天差地别。所以任何结论都应该贴着你的具体模型去找，别套万能公式。

这个内容后续再扩展的话，可以往两个方向走：一是深入量化原理，看懂校准集、贪心压缩和误差重建算法；二是研究多卡并行方案，把大模型拆到几张卡上跑。但无论怎么扩展，最核心的判断框架就是本文这套“容量→带宽→算力→质量”的四步决策法，先把这把尺子握在手里，后面探索什么方向都不会跑偏。