FP8和GGUF量化被普遍用来把14B模型塞进24 GB甚至12 GB卡，但有用户明确指出GGUF在图像/视频生成模型上“没有速度提升、矩阵乘法仍在16 bit、显存节省小、画质还不如int8/fp8”——当社区默认推荐GGUF、但它在视频模型上可能是一个次优解时，用户到底该按什么信号判断“这次该用FP8还是GGUF”？

一、问题的提出：一个被误置的等价关系

在消费级显卡上运行 14B 参数级别的扩散模型，显存是第一道硬门槛。以 FP16 存储计，14B 权重约需 28 GB，加上文本编码器、VAE、激活值与注意力中间张量，24 GB 卡已相当紧张，12 GB 卡则几乎不可能。社区由此形成两条常见路径：其一是把模型转成 FP8，其二是导出为 GGUF 并选择 Q4/Q5/Q8 等量化档位。二者在讨论中经常被并列成“两种压缩选项”，仿佛只是压缩率与画质的不同权衡。

但这一并列隐含了一个被误置的等价关系：把“文件变小”等同于“计算变快、显存变省”。实际观察中，有用户明确指出 GGUF 在图像/视频生成模型上“没有速度提升、矩阵乘法仍在 16 bit、显存节省小、画质还不如 INT8/FP8”。这一反馈并非孤例，它指向一个结构性事实——GGUF 的设计目标与扩散模型的推理负载之间存在错配。笔者认为，要回答“这次该用 FP8 还是 GGUF”，不能停留在“哪个压缩率高”的表层比较，而应回到一个更本质的问题：这次量化是否真正改写了计算路径？

这条主线将贯穿全文。所谓“计算路径”，指从权重加载、反量化、矩阵乘法到注意力的完整数据通路，包括每一步实际执行的数值精度与算子实现。若量化只改变了存储格式，而计算时仍需反量化回 16 bit，那么它带来的收益主要落在显存与带宽，而非算力；若量化能让矩阵乘法直接以低精度张量核心执行，则收益同时覆盖算力与带宽。FP8 与 GGUF 的分野，本质上就在这条线上。

判断量化方案是否值得，先问三个问题：权重以什么精度存储？计算以什么精度执行？反量化发生在算子内部还是算子之前？三个答案决定了它是“省显存的压缩”还是“省算力的加速”。

二、背景与概念澄清：格式、容器与计算路径

2.1 FP8：一种数值格式，而非文件格式

FP8 是 8 位浮点数的统称，主流有两种变体：E4M3（4 位指数、3 位尾数）与 E5M2（5 位指数、2 位尾数）。E4M3 动态范围较窄但精度更高，适合前向权重与激活；E5M2 动态范围更宽，常用于梯度。NVIDIA 在 Hopper 架构（H100）中引入原生 FP8 张量核心，Ada Lovelace 架构（RTX 40 系）亦提供 FP8 支持，使得矩阵乘法可以直接以 FP8 输入执行并累加到更高精度。本文评述：FP8 的关键不在“8 位”这个数字，而在“原生”二字——只有当硬件与算子库同时支持 FP8 输入、FP8 乘法、FP16/FP32 累加时，它才同时兑现显存与算力两重收益。

在扩散模型上，FP8 通常以训练后量化的形式落地：对权重做逐通道或逐张量缩放（scaling），对激活做动态缩放，再以 FP8 参与线性层与注意力的矩阵乘法。腾讯混元等团队公开的图像/视频生成模型 FP8 版本，即采用此类方案，在保持较高视觉质量的同时显著降低显存占用。需要强调的是，FP8 的可用性强依赖 GPU 架构：在缺乏原生 FP8 支持的硬件上，FP8 往往被反量化回 FP16 再计算，收益退化为纯存储压缩。

2.2 GGUF：一个容器，一套量化家族

GGUF（GPT-Generated Unified Format）是 llama.cpp 项目推出的模型文件格式，用于替代早期的 GGML/GGJT。它本身是一个容器规范：定义张量元数据、分词器、超参数与量化类型的组织方式。真正决定数值行为的是其内部的量化类型，如 Q4_K_M、Q5_K_S、Q8_0 等。GGUF 的设计初衷是让大语言模型能在 CPU、Apple Silicon、消费级 GPU 乃至混合卸载场景下高效运行，其核心优化对象是内存带宽受限的解码（decode）阶段。

本文评述：把 GGUF 理解为“一种量化算法”是常见误解。它更像一个“分发与加载层”，其量化家族中包含分块量化、k-quant 混合精度等技巧，这些技巧在自回归解码中收益明显，因为解码阶段每生成一个 token 只需读取全部权重一次，带宽是瓶颈。但扩散模型的推理形态截然不同——它是一次性处理整张 latent（或整段视频 latent）的并行计算，算力与显存容量才是主约束。负载形态的差异，是 GGUF 在视频模型上“水土不服”的根源。

2.3 计算路径：本文的分析主线

为把上述差异操作化，本文引入“计算路径”作为分析主线，并将其拆为四个可观测环节：存储精度（权重在显存/内存中的位宽）、反量化位置（在算子外预处理还是在算子内融合）、乘法精度（张量核心实际执行的输入位宽）、累加精度（部分和的位宽）。四个环节共同决定一个量化方案的真实收益结构。后文的所有对比，都将落回这四个环节。

三、原理拆解：量化误差如何在扩散模型中传播

3.1 扩散模型对量化误差的敏感度分布

扩散模型通过多步去噪逐步生成样本，每一步都是一次完整的网络前向。量化误差在单步内被引入，又在多步间累积。经验与公开研究表明，误差敏感度并非均匀分布：文本编码器与 cross-attention 的 K/V 对语义对齐敏感，低比特量化易导致提示词遵循度下降；VAE 解码器对高频细节敏感，量化噪声会被放大为可见的块状伪影；而主干 DiT/UNet 的多数线性层相对鲁棒。本文评述：这意味着“整模型统一比特”是粗糙做法，分层混合精度才是扩散模型量化的合理形态，这也解释了为何 k-quant 这类混合精度家族在语言模型上有效——但它的混合策略是为解码负载设计的，未必匹配扩散模型。

从数值角度，量化可写为 w_q = round(w / s + z)，其中 s 为缩放因子、z 为零点。误差来源有二：舍入误差与截断误差。分块量化（如 GGUF 的块大小 32）通过局部缩放降低离群值影响，但块内共享缩放也限制了表达力。FP8 的浮点表示则在动态范围上更有优势，尤其对激活中长尾分布更友好。

3.2 时间维度的误差累积

视频扩散模型在时间维度上引入了额外的注意力（temporal attention）与 3D VAE，序列长度可达数万 token。长序列带来两个后果：其一，注意力矩阵的数值动态范围扩大，FP16 累加更易溢出，需 BF16 或 FP32 累加；其二，误差在时间步之间传播，单帧的轻微伪影会在相邻帧间形成闪烁（flicker）。笔者认为，视频模型对量化的容忍度低于图像模型，原因不在单步误差更大，而在误差的时空耦合更强——这也是“画质还不如 INT8/FP8”这一反馈在视频场景更突出的机制解释。

3.3 反量化开销的隐藏成本

当矩阵乘法以 16 bit 执行时，低比特权重需先反量化。若反量化在算子外进行，会生成一份 16 bit 的临时权重，显存峰值反而上升；若在算子内融合（如 llama.cpp 的 dequant+matmul 内核），则避免了临时张量，但计算仍是 16 bit 吞吐。本文评述：这正是“显存节省小、速度无提升”的技术根源——存储省了，但计算路径没变，反量化的额外指令还可能吃掉部分收益。FP8 若走原生路径，则跳过了这一环，权重直接以 FP8 进入张量核心。

四、显存账本：为什么 GGUF 在视频模型上“省得不多”

4.1 权重、激活与缓存的三角关系

显存占用可粗略分解为：权重 + 激活 + 注意力缓存 + 框架开销。以 14B 模型、FP16 为例，权重约 28 GB；若量化为 Q4_K_M（约 4.5 bit/权重），权重降至约 8 GB。表面看节省 20 GB，但视频模型的激活与注意力缓存随分辨率与帧数增长迅速：720p、49 帧的 latent 序列在 3D VAE 与 DiT 中产生的中间张量可达数 GB 量级。本文评述：当权重被压到 8 GB 后，激活与缓存成为新的主约束，继续压低权重位宽的边际收益递减，而画质损失却在上升——这是“显存节省小”的相对性来源。

4.2 分块卸载与混合推理的代价

GGUF 的一大卖点是支持把部分层卸载到 CPU。但在扩散模型中，每一步去噪都要完整前向一次，若部分层在 CPU 上执行，PCIe 传输与 CPU 计算会显著拖慢单步耗时，而视频模型动辄数十步采样，累积延迟可观。本文评述：卸载策略在“一次性生成、可接受分钟级等待”的场景尚可，但在交互式或批量生成场景，其吞吐劣势会被放大。FP8 方案通常要求全模型驻留 GPU，反而避免了这一抖动。

4.3 量化档位与显存的实际映射

注：位宽与显存为按公开量化规格的估算值（整合数据），实际因模型结构、分词器与元数据略有差异。计算路径一列为机制描述，非性能承诺。

从表中可见，Q8_0 与 FP8 的权重体积接近，但计算路径不同：前者反量化后仍走 16 bit 乘法，后者可走原生 FP8。这解释了为何在支持 FP8 的硬件上，FP8 往往同时胜在速度与画质；而在不支持 FP8 的硬件上，二者都退化为“存储压缩”，此时 GGUF 的档位灵活性反而成为优势。

五、性能边界：矩阵乘法到底跑在什么精度上

5.1 张量核心的吞吐阶梯

以 NVIDIA 公开的架构规格为参照，FP8 张量核心的峰值吞吐约为 FP16 的两倍（同代同功耗档位下），这是 FP8 速度优势的硬件基础。但峰值吞吐的兑现需要满足三个条件：输入为 FP8、算子被融合、累加精度配置得当。任一条件不满足，实际吞吐会回落到 FP16 水平。本文评述：很多“FP8 没快多少”的反馈，根源在于所用推理框架未启用原生 FP8 内核，而是走了“FP8 存储 + FP16 计算”的折中路径，此时它与 GGUF 的性能结构并无本质区别。

5.2 扩散模型的计算构成

扩散模型单步前向中，线性层（含 QKV 投影、FFN）占多数 FLOPs，注意力中的 QK^T 与 AV 乘法占比较小但访存密集。FP8 对线性层的加速最直接；注意力部分因 softmax 与长序列，往往保留 BF16/FP16 以保证稳定性。这意味着 FP8 的整体加速比通常低于 2 倍，实际落在 1.2–1.7 倍区间（视模型与实现而定，属工程经验区间，非精确基准）。GGUF 若全程 16 bit 计算，则加速比接近 1，仅靠带宽节省在访存受限环节获得有限收益。

5.3 一个可复现的测速思路

与其争论，不如测量。建议在目标硬件上固定随机种子、固定分辨率与帧数、固定采样步数，分别测三种配置的单步耗时与端到端耗时：FP16 基线、FP8（原生内核）、GGUF Q8_0。若 FP8 相对基线的加速比显著大于 GGUF，则说明计算路径被改写；若二者接近，则说明瓶颈在别处（如 VAE 解码或注意力）。可用如下伪代码组织测试：

for cfg in [fp16, fp8, gguf_q8]:
    model = load(cfg)
    warmup(model, 3)
    t = benchmark(model, steps=20, seed=42)
    peak = torch.cuda.max_memory_allocated()
    print(cfg, t, peak)

说明：warmup 用于排除首次编译与缓存分配的影响；peak 需在每轮前重置统计。该脚本为方法示意，非特定框架代码。

六、画质对比：PSNR 之外该看什么

6.1 全参考指标的局限

PSNR 与 SSIM 是像素级全参考指标，对扩散模型的感知质量解释力有限。量化引入的误差常表现为局部纹理退化、色彩偏移与时间闪烁，这些在 PSNR 上可能只体现为微小下降，却在主观观看中明显。LPIPS 等感知指标更贴近人眼，但对时间一致性无能为力。本文评述：视频模型应补充时间一致性指标，如帧间光流残差或基于视频质量评估模型的分数，否则“画质还行”的判断容易失真。

6.2 低比特档位的画质断崖

公开的量化实践普遍显示，Q8_0 与 FP16 的差异较小，Q5 档位开始出现可感知退化，Q4 及以下在图像细节与文本渲染上退化明显，视频场景因时间累积更易暴露。FP8 在支持原生路径时，画质通常接近 FP16，部分模型需对敏感层保留更高精度。笔者认为，画质比较必须在“同显存预算”下进行才有意义：若 FP8 用 14 GB 达到接近 FP16 的画质，而 GGUF Q4 用 8 GB 达到可用画质，二者服务的是不同显存档位的用户，不应简单判优劣。

七、选型信号表与可操作验证流程

7.1 五个决策信号

把前文机制转化为可操作的判据，笔者归纳为五个信号，按优先级排列：

7.2 四步验证流程

信号给出方向，验证给出结论。建议按以下四步执行：第一步，确认框架与硬件的 FP8 支持状态，查阅框架文档与 GPU 架构说明；第二步，在目标分辨率与帧数下做单步与端到端测速，记录峰值显存；第三步，用固定种子生成对照样本，做主观盲评并辅以 LPIPS 与时间一致性指标；第四步，若 FP8 未达预期，回退到 GGUF 高比特档，并检查瓶颈是否转移到 VAE 或注意力。

为便于读者拓展，以下外部资源可作为验证参考（均在新窗口打开）：llama.cpp 项目主页、Hugging Face 量化文档、NVIDIA Transformer Engine 文档、ComfyUI 仓库。视频教程可参考各框架官方频道的量化实践讲解，注意甄别版本时效。

八、案例与工程实践：三类典型硬件的决策路径

8.1 24 GB Ada 卡：FP8 的主场

24 GB 显存足以容纳 14B 模型的 FP8 权重（约 14 GB）并留出激活空间。在支持 FP8 的 Ada 架构上，若框架提供原生内核，FP8 通常能同时获得速度与画质优势。工程上建议对文本编码器与 VAE 保留 FP16，仅对主干线性层启用 FP8，以平衡稳定性与收益。若实测加速不明显，应优先排查内核是否真正启用，而非直接否定 FP8。

8.2 12 GB 卡：GGUF 的现实妥协

12 GB 显存放不下 14B 的 FP8 权重，此时 GGUF Q4/Q5 是可行路径，但需接受画质退化与无速度增益的事实。工程上可通过降低分辨率、减少帧数、启用 VAE 分块解码来缓解显存压力；若必须保留画质，可考虑更小参数模型而非强行低比特量化。本文评述：在 12 GB 档位，“选 GGUF”不是因为它更优，而是因为 FP8 不可行——这是约束下的次优解，应明确其边界，避免被误读为普适推荐。

8.3 无 FP8 支持的旧卡：按带宽与容量决策

在缺乏原生 FP8 的硬件上，FP8 与 GGUF 都走 16 bit 计算，差异主要在存储格式与生态成熟度。此时应优先选择框架支持更好、档位更灵活的一方，并用实测显存峰值决定档位。笔者认为，这类硬件的用户不必追逐 FP8 标签，把精力放在分辨率、帧数与采样步数的联合调优上，收益更确定。

九、局限、反例与前沿预判

9.1 反例：GGUF 并非一无是处

必须承认反例的存在。在 CPU 或 Apple Silicon 统一内存场景，GGUF 的跨平台能力无可替代；在显存极度受限且可接受较慢速度的离线批处理场景，GGUF 的低比特档位能跑起 FP8 跑不动的模型。本文评述：判断的关键不是“哪个更好”，而是“当前约束下哪个约束是硬的”。若显存是硬约束且低于 FP8 门槛，GGUF 就是唯一解；若算力与画质是硬约束且硬件支持 FP8，则 FP8 更合理。

9.2 前沿方向

FP8 训练与推理的生态正在扩展，NVIDIA Transformer Engine 等工具链降低了启用门槛；MXFP4、NVFP4 等更低位宽的微缩放格式在语言模型上已有公开研究，其在扩散模型上的适用性仍在验证中。本文评述：更低位宽的价值取决于硬件是否提供原生支持与累加精度保障，否则只是把反量化开销前移。对视频模型而言，时间一致性的量化感知训练可能是比单纯降比特更值得投入的方向。

9.3 方法论的边界

本文的“计算路径”主线适用于以矩阵乘法为主的稠密模型，对 MoE 稀疏激活、状态空间模型等结构的解释力有限；文中的显存与加速区间为工程经验与公开规格的整合估算，具体数值随模型、框架与驱动版本变化，读者应以自测为准。所有引用以原始文献为准，本文不替代基准测试。

十、结论：把选型还原为可验证的工程问题

回到开头的问题：当社区默认推荐 GGUF，而它在视频模型上可能是次优解时，用户该按什么信号判断？本文的答案是——看计算路径是否被真正改写。硬件是否支持原生 FP8、框架是否提供融合内核、显存档位是否落在 FP8 可容纳区间、任务是否对时间一致性敏感、生态是否成熟，这五个信号构成一张可操作的决策表。GGUF 不是“错的”，它是在特定约束下的合理工具；FP8 也不是“万能”，它依赖硬件与内核的配合。

笔者建议读者把本文的信号表当作假设，把四步验证流程当作检验，用自测数据替代社区口号。量化选型的终点不是“哪个格式更流行”，而是“在目标硬件、目标分辨率、目标画质下，哪条计算路径的边际收益最高”。这个问题的答案会随硬件迭代而变化，但提问的方式可以稳定复用。