大模型推理显存攻坚：从 FP16 到 FP8 的工程机理、算力账本与避坑全景- 1. 计算机存储换算本质(https:/

一、引言：算力账本背后的物理现实

在大型语言模型（LLM）与企业级检索增强生成系统（如 Aegis-RAG）落地过程中，工程团队最常遭遇的生产事故并非模型“智商不够”，而是服务被长文本或并发请求瞬间打穿——伴随着终端中那一行令人绝望的报错：

Plaintext 明文

torch.cuda.OutOfMemoryError: CUDA out of memory. 
Tried to allocate 224.00 MiB (GPU 0; 23.69 GiB total capacity; ...)

在系统上线前的容量规划（Capacity Sizing）中，一个合格的架构师不能依靠“开几台机器试试看”的盲目试错，而必须在白板上用基础物理公式精确推演出：

模型静态权重需要吞噬多少显存？
动态上下文（KV Cache）每增加一个 Token、并发上升一个台阶，会吃掉多少兆？
选用标准 FP16、BF16 还是运行时的 FP8 量化？其背后的算力账本收益与潜在精度塌陷风险分别是什么？

本文将从最底层的计算机二进制表示出发，完整拆解大模型推理阶段的显存物理机理，建立起从数学公式到工程部署的闭环决策体系。

二、显存第一大户：模型静态权重容量测算

1. 计算机存储换算本质

计算机无法凭空理解大模型的“智能”，大模型的本质是存储在显存当中的海量浮点数（Floating-Point Numbers）。

$1 \text{ Byte（字节）} = 8 \text{ bits（二进制位）}$ 。
精度（Precision）定义了在计算机中存储一个浮点数所消耗的二进制位长。

数据类型	格式名称	所占位数 (bits)	所占字节数 (Bytes)	硬件存储特征
FP32	单精度浮点数 (Float)	32	$32 \div 8 = \mathbf{4}$	传统科学计算基石，显存开销极大
FP16 / BF16	半精度浮点数	16	$16 \div 8 = \mathbf{2}$	当前主流大模型权重与激活默认格式
INT8 / FP8	8 位整数 / 浮点数	8	$8 \div 8 = \mathbf{1}$	推理加速与显存减半的主流格式
INT4	4 位整数 (AWQ/GPTQ)	4	$4 \div 8 = \mathbf{0.5}$	边缘设备与消费级显卡部署核心格式

2. 静态权重核心计算公式

大模型行业常用参数量单位 B（Billion，十亿） 来标识规模：

$1\text{B} = 10^9 \text{ 参数}$

模型加载至 GPU 显存后，静态权重占用的理论物理大小为：

$\text{Weight VRAM (Bytes)} = P \times \text{Bytes per Parameter}$

以行业基准模型规格为例：

标准半精度（FP16 / BF16，每个参数 2 Bytes）

7B 模型：

$7 \times 10^9 \times 2 \text{ Bytes} = 14 \times 10^9 \text{ Bytes} \approx \mathbf{14.0 \text{ GB}}$
8B 模型（如 Llama-3-8B）：

$8 \times 10^9 \times 2 \text{ Bytes} = 16 \times 10^9 \text{ Bytes} \approx \mathbf{16.0 \text{ GB}}$
14B 模型（如 Qwen2.5-14B）：

$14 \times 10^9 \times 2 \text{ Bytes} = 28 \times 10^9 \text{ Bytes} \approx \mathbf{28.0 \text{ GB}}$
70B / 72B 旗舰模型：

$72 \times 10^9 \times 2 \text{ Bytes} \approx \mathbf{144.0 \text{ GB}}$

4-bit 离线量化（INT4，每个参数 0.5 Bytes）

7B 模型：

$7 \times 10^9 \times 0.5 \text{ Bytes} = 3.5 \times 10^9 \text{ Bytes} \approx \mathbf{3.5 \text{ GB}}$
14B 模型：

$14 \times 10^9 \times 0.5 \text{ Bytes} = 7.0 \times 10^9 \text{ Bytes} \approx \mathbf{7.0 \text{ GB}}$

3. 理论值与生产实际显存的偏差（驱动与运行时冗余）

在生产实践中，千万不能按纯理论数字卡死显存。当框架（vLLM、TGI、Ollama 等）拉起服务时，存在以下固定刚性开销：

CUDA Context 开销：PyTorch 初始化驱动核心和显卡通信上下文，需静态占用 0.5 GB ~ 1.0 GB。
非矩阵参数与 Embedding / LayerNorm 层：部分层不参与量化（或保持 FP32/FP16 高精度）。
量化 Scale 缩放因子开销：INT4 算法（如 AWQ）需要按分组（Group Size 128）存储 FP16 的缩放矩阵，带来约 10%~15% 的显存额外负担。

工业界速算安全冗余经验法则：

7B/8B (FP16)：理论 14~16 GB $\to$ 生产预留至少 16~18 GB。

7B/8B (INT4)：理论 3.5~4 GB $\to$ 生产预留至少 4.5~5.5 GB。

三、自回归解码的隐形杀手：KV Cache 与 GQA 机制

如果显存开销仅包含静态权重，大模型的服务容量将是极易预测的固定常量。然而，让显存变成“无底洞”的罪魁祸首是自回归生成机制下的动态 KV Cache。

1. 为什么自回归生成必须保留 K 和 V，而 Q 阅后即焚？

在自注意力机制（Self-Attention）中，每一个 Token 的计算依赖于三个核心向量：

$\text{Attention}(Q, K, V) = \text{softmax}\left(\frac{Q K^T}{\sqrt{d\_k}}\right)V$

$Q$ （Query，查询向量）：“当前最新生成的这个词，想要寻找什么样的上下文特征？”
$K$ （Key，键标签向量）：“历史上的词包含了哪些属性特征，供后续查询匹配？”
$V$ （Value，实质信息向量）：“若与当前查询匹配成功，该词能贡献出怎样的语义内容？”

历史缓存区 (KV Cache，永久驻留显存，随 Token 递增线性膨胀):
[ Token_1: K1, V1 ] ── [ Token_2: K2, V2 ] ── ... ── [ Token_{t-1}: K_{t-1}, V_{t-1} ]
        ▲                      ▲                               ▲
        └──────────────────────┴───────────────────────────────┤ (矩阵点乘与加权累加)
                                                               │
                                                   [ 最新 Token_t 的 Qt ]
                                                               │
                                                               ▼
                                                  【计算出 Token_{t+1} 后，Qt 立即丢弃】

为什么不需要缓存 $Q$ ？

自回归生成是“逐字吐出”的。当模型预测第 $t+1$ 个词时：

只有最新出现的第 $t$ 个词需要充当主动发起查询的探针（ $Q\_t$ ）。
一旦第 $t$ 个词与所有历史的 $K\_{1..t}$ 完成了点乘、并加权汇聚了历史的 $V\_{1..t}$ 、最终解码出第 $t+1$ 个词后，历史上的 $Q$ 永远不会再被任何未来的计算所复用。因此， $Q$ 是瞬时计算、阅后即焚的。

为什么必须拼命保留 $K$ 和 $V$ ？

只要生成还在继续，未来吐出的第 $t+2$ 、第 $t+100$ 个词，在回头寻找注意力上下文时，必须全量访问前文所有词的 $K$ 和 $V$ 。

如果不把历史的 $K$ 和 $V$ 缓存到显存中，模型每吐出一个新词，前面的几千个历史词就要从第 1 层网络到最后 1 层完整重新做一次 Projection 矩阵乘法，计算复杂度退化为灾难性的 $O(N^2)$ 。

KV Cache 的本质，就是极度纯粹的“以空间（显存）换时间（算力）”。

2. MHA、MQA 到 GQA 的架构演进

早期的大模型为了追求极致的多头特征表征能力，采用全量多头注意力机制（MHA），导致 KV Cache 过于庞大。随后业界经历了由繁至简的演进：

MHA (Multi-Head Attention)        GQA (Grouped-Query Attention)        MQA (Multi-Query Attention)
  Q Heads    KV Heads               Q Heads      KV Heads                Q Heads    KV Heads
  [Q1] ───► [K1, V1]               [Q1] ┐                               [Q1] ┐
  [Q2] ───► [K2, V2]               [Q2] ┼───► [Group 1: K, V]           [Q2] │
  [Q3] ───► [K3, V3]               [Q3] ┘                               [Q3] ┼───► [Only 1: K, V]
  [Q4] ───► [K4, V4]               [Q4] ┐                               [Q4] │
  [Q5] ───► [K5, V5]               [Q5] ┼───► [Group 2: K, V]           [Q5] │
  [Q6] ───► [K6, V6]               [Q6] ┘                               [Q6] ┘
(1:1 配比，显存开销极大)             (多对一分组共享，显存/精度最佳平衡)    (全量共享单一头，极省显存但微损精度)

MHA： $H\_Q = H\_{KV}$ 。每个 Query 头配一个专属 KV 头。显存占用极高。
MQA： $H\_{KV} = 1$ 。所有 Query 头强行共用一组 KV。极省显存，但长文本复杂逻辑容易退化。
GQA：将 Query 头划分为 $G$ 个组，每组共享一个 KV 头。LLaMA-3、Qwen-2.5 等当前顶流开源模型已全量标配 GQA，实现了显存开销与长文精度的最佳折中。

3. GQA 单 Token KV Cache 物理公式推导

要在白板上推算出单 Token 的 KV Cache 物理开销，需要将 Transformer 网络在空间维度逐层剖开。

$\text{KV Cache per Token (Bytes)} = 2 \times L \times H\_{KV} \times d\_{head} \times B$

这 5 个因子的物理意义构成了严密的几何模型：

因子 2：由于同时独立缓存 Key 矩阵与 Value 矩阵两套完整向量，天然必须乘 2。
因子 L（Layers）：模型网络深度（Transformer 块层数）。每一层提取的抽象语义特征彼此独立，因此每一层都必须维持专属的 KV 缓存。
因子 H_KV（KV Heads）：网络在 GQA 机制下每一层实际存在的 KV 头数（注意绝不是 Query 头数 $H\_Q$ ）。
因子 d_head（Head Dimension）：每个注意力头负责的向量维度长度，满足 $d\_{head} = \frac{d\_{model}}{H\_Q}$ 。在现代开源架构中普遍收敛并固定为 128。
因子 B（Bytes per Element）：KV 缓存所采用的浮点数据类型精度字节数。在 FP16 / BF16 下 $B=2$ ；在 FP8 下 $B=1$ 。

4. 主流模型参数与单 Token 显存实测表

从模型发布仓库的 config.json 中，可直接提取核心参数，套入公式计算其在 FP16 下的单 Token KV Cache 容量：

模型架构	层数 (L)	隐层维度 (dmodel)	Q 头数 (HQ)	KV 头数 (HKV)	dhead	单 Token KV Cache (FP16, B=2)	单 Token KV Cache (FP8, B=1)
Qwen2.5-7B	28	3584	28	4	128	$2 \times 28 \times 4 \times 128 \times 2 = \mathbf{57,344 \text{ B}} \approx \mathbf{56 \text{ KB}}$	$\mathbf{28 \text{ KB}}$
Llama-3-8B	32	4096	32	8	128	$2 \times 32 \times 8 \times 128 \times 2 = \mathbf{131,072 \text{ B}} = \mathbf{128 \text{ KB}}$	$\mathbf{64 \text{ KB}}$
Qwen2.5-14B	48	5120	40	8	128	$2 \times 48 \times 8 \times 128 \times 2 = \mathbf{196,608 \text{ B}} \approx \mathbf{192 \text{ KB}}$	$\mathbf{96 \text{ KB}}$
Qwen2.5-72B	80	8192	64	8	128	$2 \times 80 \times 8 \times 128 \times 2 = \mathbf{327,680 \text{ B}} \approx \mathbf{320 \text{ KB}}$	$\mathbf{160 \text{ KB}}$

四、精度降维：将 FP16 改为 FP8 的技术底牌与收益

当长文档（如 RAG 注入 4000~8000 Tokens 的参考规约）涌入系统，高并发会迅速耗尽 GPU 显存。将存储精度从 FP16（2 Bytes） 降维至 FP8（1 Byte），是工业级推理框架（如 vLLM）中最强大的高杠杆手段。

1. 权重离线量化 vs 运行时 KV Cache 量化

必须在架构层面区分这两者的物理阶段差异：

权重离线量化（Offline Weight Quantization）：在部署前通过 AWQ、GPTQ 等算法重写权重文件（如转为 INT4/FP8）。它固定削减的是静态显存空间，模型开机后大小不再改变。
运行时 KV Cache 量化（Runtime KV Cache Quantization）：模型主权重可以继续保持全精度（FP16/BF16），仅在推理引擎动态生成 $K$ 和 $V$ 向量、将其写入 PagedAttention 显存池的那一瞬间，调用专用 CUDA Kernel 将 16-bit 浮点数即时压为 8-bit（FP8）。在后续 Attention 计算时，由硬件在 Tensor Core 或寄存器内瞬时反量化解包。

2. 为什么是 FP8 而不是 INT8？（离群值与浮点动态范围）

在 Transformer 的注意力矩阵中，某些固定位置（如开头的分隔符、句号）或具有极强逻辑转折作用的 Token，其注意力特征值往往呈现出极其极端的高峰——即所谓的离群值（Outliers）。

数值轴分布对比：
[ 0.001   0.003   0.008   0.012 ] ──────────────────────────────► [ 89.5 (离群值) ]

若采用 INT8 均匀量化：
步长必须强行拉大以容忍 89.5，导致 [0.001 ~ 0.012] 的大量细微特征被全部归零压碎，破坏语义。

若采用 FP8 (E4M3 / E5M2) 浮点量化：
指数位提供非线性的阶梯分布，既能表达极小的微弱概率，又能以宽泛的动态范围包裹 89.5 离群值。

早期 INT8 的硬伤：INT8 属于均匀整数切分。当特征向量中出现高达几十的离群值时，量化网格（Grid）被迫极大拉伸，导致占整体 99% 的微小浮点数被粗暴四舍五入为同一数值甚至直接截断归零，导致模型输出乱码或逻辑崩溃。
现代 FP8 的救赎：FP8（特别是主流的 E4M3 格式：1 位符号 + 4 位指数 + 3 位尾数）依然维持了浮点数“非均匀、非线性对数分布”的核心特性，能够以极其出色的保真度同时保留微弱语义特征与极端离群值。

3. 生产级收益：打破显存墙、吞吐翻倍与缓解 Memory-Bound

将参数因子 $B$ 由 2 变成 1，在生产环境会引发三大连环物理收益：

显存容量占用腰斩，极限并发直接翻倍：

以单卡 RTX 4080 (12GB) 部署 Qwen2.5-7B (INT4 权重占 4.5G，留给 KV 池约 6.5G) 处理 4000 Tokens 上下文为例：
- FP16 KV Cache：单请求吃掉 $4000 \times 56\text{ KB} = 0.224\text{ GB}$ ，极限并发仅为 $\lfloor 6.5 \div 0.224 \rfloor = \mathbf{29}$ 。
- FP8 KV Cache：单 Token 砍到 28 KB，单请求降至 $0.112\text{ GB}$ ，极限并发跃升为 $\lfloor 6.5 \div 0.112 \rfloor = \mathbf{58}$ 。
击碎显存读写瓶颈（Memory-Bound）：

在自回归的 Decode 阶段，系统瓶颈往往不在于 GPU 浮点计算能力，而在于显存读写带宽（HBM/GDDR Bandwidth）被数据搬运彻底塞满。精度减半意味着每一步 Attention 运算从显存读取到计算核心的数据搬运量直接骤降 50%，显著提升长文本长尾生成的吐字帧率（Tokens/s）。
消除长尾抢占（Request Preemption），稳定 P99 延迟：

当显存池水位因突发长请求而见底时，推理框架无需再频繁将排队中的序列换出（Swap-out）到宿主机内存，避免了因显存争抢导致的 P99 延迟断崖式跳涨。

五、技术妥协：FP8 隐藏的 4 大暗坑与工程代价

任何极致的性能榨取，本质上都是工程权衡。在盲目开启 FP8 之前，必须对以下 4 大隐患建立防范意识：

1. 硬件架构代差与“假加速真减速”（Tensor Core 支持陷阱）

FP8 的底层加速高度依赖硬件支持。

原生支持架构：NVIDIA Ada Lovelace 架构（RTX 4080 / 4090 / L40S）与 Hopper 架构（H100 / H800）。其第四代 Tensor Core 原生具备 FP8 矩阵乘加硬件指令集，速度极快。
不支持架构：Ampere 架构（A100 / A800 / RTX 3090）及其前代硬件，在物理硅片层面完全不存在 FP8 张量计算核心。

⚠️ 踩坑事故场景：

若在 A100 上强行配置 --kv-cache-dtype fp8，虽然显存账面确实缩小了一半，但当 GPU 执行 Attention 计算时，硬件根本无法直接消费 FP8 数据。驱动被迫在每次算子调用前，先插入额外的 CUDA 软件指令，把显存里的 FP8 实时反解（De-quantize）成 FP16，再塞进 Tensor Core 计算。

结果：多出的反解计算开销完全抵消了带宽红利，导致计算延迟恶化，整体吞吐不升反降！

2. 特定场景的精度钝化与长文本“弱信号截断”

FP8（E4M3）的有效精度仅有 3 位尾数位（Mantissa），这意味着其尾数精度只有 $2^{-3} = 0.125$ 步长，离散精度分辨率极度粗糙。

在通用长文本对话中，少量的精度扰动不会改变宏观语义。
但在像 Aegis-RAG 所面向的高合规垂直业务（如：医保清单结算对账、复杂法条前置排除条款）中，某些关键制约往往取决于长文档深处一个微弱的注意力权重（例如“但不包含三级甲等医院门诊自费药”）。
精度下溢灾难：在 FP8 的粗粒度网格下，这些微弱的相关性信号非常容易直接发生下溢（Underflow）而被硬件强制截断为 0。最终导致模型在通篇润色上依然流畅，但在极端例外条款判别、数值关联上发生不可预测的漏检与幻觉漂移。

3. 缩放因子（Scaling Factor）校准与运维排障黑盒

为了避免将数据压缩进 FP8 极窄区间时频繁溢出，所有 FP8 算子都必须配合缩放因子（Scale Factor）使用：

动态量化（Dynamic Scaling）：在线实时计算每一批 Token 的最大值来决定缩放比。虽然精度较好，但每次 Attention 都必须增加额外的规约求最大值算子，拉高调度开销。
静态校准（Static Calibration）：离线跑一段样本定死 Scale。如果线上实际流量的 RAG 上下文中突然出现大量未见过的特殊字符、密集长代码或超大数额财务数字，静态 Scale 无法容纳突增峰值，会导致整批数据发生数值溢出（Overflow），模型瞬间开始输出乱码或陷入死循环。
这种偶发性 bug 具有不可复现的“幽灵特征”，极难在线上实时定位。

4. 对底数概率与 Logprobs 测谎仪的隐性干扰

在 Aegis-RAG 等先进高可靠架构中，通常会挂载 Logprobs 测谎仪与全文困惑度（PPL）监控引擎，通过提取模型底层未被污染的原始对数似然：

$P = \exp(\text{logprob})$

来无模型成本地探查大模型在吐出关键数字时的“心虚程度”。

当 Attention 全链路的历史 KV 被压入粗粒度的 FP8 之后，最后通过 Softmax 投射出的 Logits 概率分布会出现不可避免的数值轻微平滑化与熵增抖动。

这会导致置信度原本在 0.85 临界线摇摆的关键词，在 FP8 噪声下发生微小数值抖动，进而引发测谎仪误报率（False Alarm）或漏报率上升，对下游精细化防御系统的阈值判定产生负面干扰。

六、深度拓展：FP16 与 BF16 的殊死之争（被遗漏的核心基础）

在讨论将 FP16 改为 FP8 之前，生产环境中还有一个更为基础、但也最容易被混淆的重要选型：FP16 与 BF16（Bfloat16）到底有何本质区别？ 为什么绝大多数现代大模型在预训练和推理时，都强制推荐使用 BF16？

1. 浮点数结构解剖：符号位、指数位与尾数位

在 IEEE 754 计算机浮点标准中，一个浮点数由三个部分组成：

Sign (S)：符号位，代表正负号。
Exponent (E)：指数位，决定该数据类型能够表达的“动态范围”（能表达多大多小的数字）。
Mantissa / Fraction (M)：尾数位，决定该数据类型的“数值精度”（能切分得有多细腻）。

我们可以把 FP32、FP16 和 BF16 的 32 位与 16 位物理结构横向对齐对比：

FP32 (标准单精度，32 bits):
┌───┬──────────────────────┬───────────────────────────────────────────────────────┐
│ S │  8 bits Exponent     │  23 bits Mantissa                                     │
└───┴──────────────────────┴───────────────────────────────────────────────────────┘

FP16 (IEEE 半精度，16 bits):
┌───┬──────────────┬───────────────────────────────┐
│ S │ 5 bits Exp   │  10 bits Mantissa             │
└───┴──────────────┴───────────────────────────────┘
(指数位仅 5 位，动态范围极窄；尾数位 10 位，局部精度较高)

BF16 (Brain Floating Point，16 bits):
┌───┬──────────────────────┬───────────────┐
│ S │  8 bits Exponent     │ 7 bits Man    │
└───┴──────────────────────┴───────────────┘
(完全继承了 FP32 的 8 位指数位！动态范围与 FP32 完全一致；牺牲了尾数精度)

2. FP16 的最大死穴：动态范围窄与下溢/溢出（Underflow/Overflow）

仔细观察 FP16 的结构就会发现其致命死穴：指数位仅有 5 位。

动态数值范围： $2^{-14} \approx 6.1 \times 10^{-5}$ 到 $2^{15} \approx 65504$ 。
死穴爆发机制：

在深度神经网络中，信息流经数十层 Transformer。在计算长序列 Attention 时， $Q \times K^T$ 的点积数值很容易累加超过 65504。
- 一旦超过 65504，FP16 就会直接遭遇数值溢出（Overflow），在显存中瞬间变成 NaN（Not a Number）或 Inf。一个 NaN 会在下一层的矩阵乘法中像病毒一样瞬间污染整张计算图，导致整个服务输出彻底报废！
- 反之，在梯度回传或微弱概率计算时，一旦数值小于 $6.1 \times 10^{-5}$ ，就会发生数值下溢（Underflow），直接被抹杀归零。
为了让 FP16 跑起来，工程上被迫发明了极其繁复的 Loss Scaling（动态损失缩放） 技术，运维维护成本极高。

3. BF16 的降维打击：保留 FP32 动态范围的架构创新

Google Brain 在设计 TPU 时，针对深度学习的物理特性提出了开创性的 BF16（Brain Floating Point 16）：

设计哲学：在深度学习中，对“数值范围（动态跨度）”的容忍度，远比对“局部切分精度（有效数字位数）”重要得多！
BF16 直接完整保留了与 FP32 丝毫不差的 8 位指数位，只把尾数从 23 位粗暴截断到了 7 位。
降维打击效果：
- BF16 的最大可表示数值高达 $\approx 3.39 \times 10^{38}$ ，与标准的 FP32 完全同等宽广！
- 它在物理层面几乎绝不可能发生数值上溢变成 NaN，也不需要任何 Loss Scaling 补偿逻辑。
- 从 FP32 转换到 BF16，硬件甚至不需要进行复杂的浮点缩放换算，只需在位级别上“直接扔掉低 16 位”即可完成截断，硬件执行代价极低。

4. 混合精度推理（Mixed-Precision Accumulation）机制

无论是 FP16 还是 BF16，在现代 GPU 底层执行矩阵乘加（Matrix Multiply-Accumulate, MMA）时，英伟达的 Tensor Core 均采用混合精度累加（Mixed-Precision Accumulation）机制：

输入的两个操作数张量（Tensor A 与 Tensor B）是以 FP16 或 BF16 格式从显存中读入。
但是，在 Tensor Core 内部执行逐点乘积累加时，其中间求和累加器（Accumulator）使用的是完整的 32 位单精度（FP32） 寄存器。
算完最终点积和后，再写出（Down-cast）回指定的输出精度。这一机制在物理上最大限度地兜底了半精度在多层累加过程中的舍入误差累计。

七、企业级工程实战：不同显卡与业务场景的选型决策树

基于上述软硬件物理层面的推导，可以提炼出如下一份可直接指导企业生产部署的系统级选型决策树：

                                  【启动推理服务显存与精度规划】
                                                │
                                    硬件核心架构是什么代次？
                                   ┌────────────┴────────────┐
                        [Ada Lovelace / Hopper]     [Ampere / 早期架构]
                       (RTX 4080/4090, L40S, H100)  (A100, A800, RTX 3090)
                                   │                         │
                     该业务是否为高合规严格判别场景？        【坚决禁用 FP8 KV Cache】
                     (如医保清算、财务审计、法律规约)        (避免触发反量化导致吞吐倒挂)
                                   │                         │
                          ┌────────┴────────┐                │
                        [是]               [否]              │
                          │                 │                ▼
              并发容量是否已达极限？   【放开限制开启 FP8】    硬件是否支持 BF16？
                (显存池面临溢出排队)    (并发翻倍，带宽收益拉满)    ┌────┴────┐
                  ┌───────┴───────┐                          [是]      [否]
                [是]             [否]                         │         │
                 │                │                          ▼         ▼
     【受控开启 FP8 KV Cache】  【保持原汁原味 BF16】       【标配 BF16】 【被迫选用 FP16】
     - 必须挂载 Tier-1 代码质检   - 保证长文微弱特征无损        - 无溢出风险  - 必须配置严密
     - 线下跑黄金集回归复验       - 维持测谎仪底数敏感度                      监控防止 NaN

生产级关键总结备忘表

决策维度	生产首选建议	严禁/踩坑行为
基础半精度选型	全面标配 BF16（兼顾动态范围与数值稳定性）	在无动态缩放保护下裸跑 FP16 导致 `NaN` 击穿
KV Cache FP8 量化	仅在 Ada (40系) / Hopper (H100) 硬件上开启	在 A100 / RTX 3090 上开启导致计算吞吐反向暴跌
高合规业务约束	业务容错低时优先保留 BF16 全精度 KV	在涉及严肃法律与财务对账系统中盲目开启静态 FP8
算力账本快速心算	$2 \times L \times H\_{KV} \times d\_{head} \times B$ ，三步定出单 Token 开销	仅按模型参数量计算显存，忽略长文本并发海啸

大模型推理显存攻坚：从 FP16 到 FP8 的工程机理、算力账本与避坑全景

目录