1. 从 FP32 到 FP8精度这件事到底在卡谁的脖子最近不少读者来问模型部署相关的问题翻来覆去的几个热搜词让我印象挺深int8、fp16、fp32、fp64的区别和算力需求ollma部署模型后如何可视化docker部署vllm模型教程。看起来很多人已经走到了部署这一步但卡在了同一个地方模型明明在训练时跑得好好的部署之后不是变慢就是效果变差甚至直接出现NaN。要搞清楚这些问题绕不开今天这个主题——数值精度。先直接给结论模型部署与推理优化本质是在内存带宽、计算吞吐和输出质量之间找平衡点。而精度格式的选择就是这个平衡点最核心的调节旋钮。从 FP32 聊到 FP8不是简单地换个数据类型而是在理解一个完整的链路模型文件在磁盘上占多少空间、加载到显存里占多大容量、每个张量在计算单元里要用多少次浮点运算、推理结果会不会因为舍入误差而偏离“正确答案”。这篇文章适合谁正在做模型服务化部署的工程同学、用 Ollama/vLLM 跑本地大模型的爱好者、准备把模型压到边缘设备上的算法工程师还有那些想搞懂精度差异但不知道从哪下手的入门者。我不会堆一堆手册术语而是站在“我实际部署了一个模型、遇到了问题、最后是怎么解决的”这个角度来写。文中的配置和参数都来自真实项目可以参考着直接抄。如果你要在不同框架之间迁移模型比如从 PyTorch 导成 ONNX再转成 TensorRT或者在 GPU 上跑推理时发现显存带宽吃紧再或者你在树莓派、Jetson 这类资源受限设备上跑 YOLO 类模型——精度格式的选择直接决定项目能不能落地。这不夸张。2. 各种精度格式的底层结构记住“范围”和“步长”两个词就够了2.1 FP32 是基准不是标配FP32单精度浮点很多教程里都默认是“标准配置”这其实有历史原因。它用 32 个 bit 来表示一个数1 位符号位8 位指数位23 位尾数位。它能表示的最大数值大概到 3.4e38足够覆盖绝大多数场景的数值范围。但在部署环节FP32 的成本是隐形的。首当其冲就是显存。一个 7B 参数的模型用 FP32 存储权重相当于 28GB 显存7B x 4字节一块 4090 的 24GB 显存根本放不下。其次GPU 在 FP32 下的 FLOPS每秒浮点运算次数通常只有 FP16 的一半甚至更低——因为半精度能让 SIMD 单元一周期处理更多数据。举一个直观的对比在 A100 上FP32 的稠密矩阵乘法算力大约 19.5 TFLOPS而 FP16 借助 Tensor Core 能达到 156 TFLOPS差了 8 倍。这就是为什么现如今的推理框架几乎没人再默认开 FP32 跑大模型。还有一个被忽略的痛点是内存带宽。推理过程中每个参数都要从显存读取一次读取 FP32 数据比读取 FP8 数据多花 4 倍带宽。在 7B 模型上一次前向传播就要读取 28GB 数据按 2TB/s 的带宽算光是读权重就要 14ms。如果换成 FP8这个时间能压到 3.5ms 以内——但带宽瓶颈还受其他因素影响这里只是让你直观感受一下量级差异。2.2 FP16 的坑范围小容易“爆”FP16半精度用 1 位符号、5 位指数、10 位尾数。它的最大表示范围约 65504听起来够用但做矩阵乘法时中间结果很容易超过这个数。举个例子两个 300 左右的数相乘结果就到 90000直接超出 FP16 的表示上限变成 Inf无穷大。之后再往后传梯度或者中间激活值就全变成 NaN模型推理结果就是一堆乱码。这个“溢出”问题在推理阶段相对少见因为权重和激活值通常被归一化到比较小的范围但在训练阶段非常致命所以当年的混合精度训练才需要加入“损失缩放”Loss Scaling这一招。不过推理阶段也有自己的坑当激活值在 FP16 下精度不够时某些敏感层比如 LayerNorm、Softmax 这类对数值分布敏感的算子输出会漂移。用个生活化的类比FP16 像用厘米刻度的尺子量一座山的高度量到 655 米上限后尺子不够长了而且你只能精确到小数点后两位FP32 则像一把能同时量出微米级刻度和几十公里量程的游标卡尺又长又细。2.3 BF16聪明的折中大模型的最爱BF16Brain Floating Point是 Google 为深度学习发明的一种格式1 位符号、8 位指数、7 位尾数。它的指数范围和 FP32 完全一样所以表示范围一样大只是尾数精度被砍掉了不少。这意味着什么BF16 几乎不会出现 FP16 那种“溢出到 Inf”的问题因为指数范围大。代价是精度低——只有 7 位尾数相当于在“毫米”刻度上还有“厘米”刻度精度比不上 FP16。但对于 Transformer 这类模型权重和激活值的数值分布通常很“规矩”研究人员在实践中发现 BF16 的精度损失往往小于 FP16。我用一个 W8A8 量化项目测过对比把 LLaMA-7B 用 BF16 推理和 FP16 推理相比输出文本的困惑度perplexity几乎没有变化而 FP16 在长序列场景下偶尔出现数值异常。因此如果你用的是 NVIDIA A100、H100、H200 这些支持 BF16 的卡推理默认优先选 BF16。它可以选但前提是你的 GPU 硬件支持 BF16 的原生计算老卡比如 V100、T4 就不一定支持。下表把几种格式的关键参数总结一下方便你选型时对照格式符号位指数位尾数位最大范围约最小正常精度约典型用途FP3218233.4e381.2e-38精度基准、CPU训练FP64111521.8e3082.2e-308科学计算深度学习几乎不用FP161510655046.1e-5混合精度训练/推理BF161873.4e389.2e-41大模型训练/推理FP8 E4M31434486.0e-2推理加速、低比特量化FP8 E5M2152573447.8e-4梯度/误差回传INT81—7含符号±1271量化推理W8A8这个表多看几眼你就能明白为什么说“精度格式的选择”不是拍脑袋——每个字段的长度就是一组权衡指数位多覆盖范围大尾数位多小数精度高总位数少内存占用低、算得快。2.4 算力需求差异为什么半精度能翻倍INT8能再翻倍这里要给一个重要的硬件背景现代 GPU 里的 Tensor Core 是专门为低精度矩阵运算设计的。A100 的 Tensor Core 支持 FP16算力约 156 TFLOPSH100 增加了 FP8 支持算力直接拉到 662 FP8 TFLOPS 以上稠密计算对应 790 TFLOPS 的稀疏值。相比 FP32 的 67 TFLOPS提升接近 10 倍。这意味着你只要把精度从 FP32 降到 FP8在算力利用充分的前提下推理吞吐量就有数量级的提升空间。但这里有个容易被忽略的前提——算力要“利用充分”。如果你的推理过程中有大量小矩阵、频繁的 kernel launch 或者 CPU 与 GPU 的数据搬运那 FLOPS 翻倍也只是纸面数字。实际吞吐提升可能只有一点点。这也就是为什么部署框架TensorRT、vLLM、TensorRT-LLM都在做算子融合和 continuous batching目的就是把计算密度做上去让低精度优势真正落地。3. 混合精度为什么不是“所有层一视同仁地降精度”3.1 模型内部对精度的敏感度差异极大初学者最容易犯的一个错误是为了提速把整个模型一股脑从 FP32 转成 FP16 或 INT8然后发现输出质量下降明显于是得出“低精度不可用”的结论。这其实是把问题做粗了。真实情况是Transformer 结构里的不同模块对数值精度的敏感度差异很大Embedding 层和输出层词汇表通常很大Embedding 的数值分布跨度极大。如果降低精度高频词和低频词的区分度会模糊直接损害模型的语言生成质量。LayerNorm / RMSNorm 层要做除法、平方根这类运算中间结果动态范围大对精度要求高。FP16 在这种小数值上反而容易出现舍入误差。Attention 的 Q、K 点积在长序列下点积结果会随序列长度增大而线性增大低精度下容易溢出或丢失尾部细节。MLP 层FNN这是最“耐造”的部分权重分布相对均匀对精度不敏感也是量化时最先“动刀”的对象。所以在实际部署中混合精度mixed precision的正确姿势是该用高精度的地方用高精度该砍精度的地方果断砍。这个经验不是拍脑袋是无数量化论文和实际项目验证过的事实。3.2 训练阶段的混合精度Loss Scaling 是怎么救场子的很多人在部署阶段接触混合精度以为这个概念是部署专属。其实混合精度最早火起来是在训练阶段PyTorch 的 AMPAutomatic Mixed Precision。了解它对理解部署期为什么某些层要保留高精度非常有帮助。混合精度训练的原理是权重保持 FP32 主副本前向和反向计算用 FP16/BF16 加速梯度更新前把损失值放大Scale防止梯度在 FP16 下变成 0因为小梯度 6e-8 时直接下溢为 0。每迭代若干步后调整缩放因子如果出现 Inf/NaN就调小缩放因子重来。你可能奇怪这和部署有什么关系关系在于如果你打算把训练好的 FP32 模型直接转成 FP16 推理但训练过程中某些层本身就存在数值不稳定的历史问题比如梯度爆炸过的层、对 Loss Scale 特别敏感的层那么在推理阶段用 FP16 通常也会在这些层上出现异常。所以真正成熟的部署流程不是拿训练完的模型直接切精度而是要在转精度后逐层做数值检查。3.3 推理阶段混合精度哪些算子该捞一手我做一个实际项目时把一个 BERT 类模型的权重直接转成 FP16 后在下游任务的 F1 上掉了 0.7 个点。逐层排查后发现问题出在 LayerNorm 的 gamma/beta 参数上——这些参数数值本身特别小FP16 表示时精度损失相对严重。解决办法也简单把 LayerNorm、Softmax、部分残差连接的输入保留在 FP32 精度下执行其余大部分算子用 FP16 跑。这就是推理阶段的混合精度。老一点的 GPU 上TF32 也常被用来做“准 FP32”的矩阵乘——TF32 是 NVIDIA 专门搞的格式用 19bit 存储8 位指数 10 位尾数在 Ampere 架构上用 Tensor Core 跑 TF32 能达到比 FP32 快 8 倍的速度而且精度损失比 FP16 小得多。具体能节省多少时间、会不会有额外开销取决于算子融合的粒度、框架实现以及目标 GPU 架构。你的 GPU 只要不是太老基本都能用。框架层面PyTorch 的torch.backends.cuda.matmul.allow_tf32在 1.12 以后默认 True但在部署推理路径上TensorRT 会自动选择最合适的精度策略。3.4 落地配置参考PyTorch AMP 的推理侧写法虽然 AMP 主要面向训练但推理时你也会用到类似的 API 来对特定模块局部提升精度。这里给一个常见的 PyTorch 推理混合精度片段import torch # 模型和输入都转成 FP16 是可接受的基础操作但要注意特定模块 model MyModel().half().cuda() model.eval() # 对于需要高精度的模块可以单独保持 FP32 # 比如自定义 LayerNorm 时保守起见可以让它在 FP32 下计算 class MixedPrecisionLayerNorm(torch.nn.Module): def __init__(self, normalized_shape, eps1e-5): super().__init__() self.ln torch.nn.LayerNorm(normalized_shape, epseps) def forward(self, x): orig_dtype x.dtype x x.float() # 先升到 FP32 x self.ln(x) return x.to(orig_dtype) # 再转回原精度但说实话直接手写这种模块容易出问题而且性能未必好。更推荐的做法是在训练好模型后把 LayerNorm 的权重提取出来转到 FP32然后在推理框架中配置“某些算子用 FP32、其他用 FP16”。TensorRT 里对应的是set_precision接口实际操作可参考各框架的官方示例ONNX Runtime 里可以用OrtSessionOptions搭配GraphOptimizationLevel和算子类型配置来指定精度。# ONNX Runtime 示例设置推理时使用 ORT_ENABLE_EXTENDED_GRAPH_OPTIMIZATION 并配合混合精度执行 import onnxruntime as ort sess_options ort.SessionOptions() sess_options.graph_optimization_level ort.GraphOptimizationLevel.ORT_ENABLE_ALL # 部分 CPU 算子可以保持高精度GPU EP 则自动利用 TF32/FP16 sess_options.execution_mode ort.ExecutionMode.ORT_SEQUENTIAL sess ort.InferenceSession(model.onnx, sess_options, providers[CUDAExecutionProvider, CPUExecutionProvider])这里的核心经验是别怕混合精度但要有手段去定位哪一层掉点。后面第 5 节我会专门讲验证流程。4. FP8 实战E4M3 和 E5M2 怎么选以及推理框架支持现状4.1 FP8 为什么在这两年爆发FP8 不是一个新概念NVIDIA 从 Hopper 架构开始把 FP8 列为 Tensor Core 的原生支持格式H100、H200、B200 都支持 FP8 矩阵运算。紧接着 FP8 训练和推理的论文就出了一批DeepSeek-V3 用 FP8 混合精度训练就是典型案例。爆发的原因说白了就两个字带宽。大模型推理是一个“内存带宽饥饿型”任务每生成一个 token 都要把所有权重从显存走一遍。7B 模型用 FP32 是 28GB用 FP16 是 14GB用 FP8 只要 7GBINT4 只要 3.5GB。显存占用直降带宽需求直降推理延迟自然就降下来了。更关键的是服务器端推理常常是多用户并发显存容量直接决定你能同时塞下多少个模型副本、batch size 能拉到多大。用 FP8 的模型7B 参数可以塞进单张 24GB 的消费级显卡实际上 7B FP8 大小为 7GB 左右加上 KV Cache 后多用户也仍可行这在 FP16 时代是做不到的。这就是为什么大家一窝蜂开始研究 FP8。4.2 FP8 的两种格式E4M3 vs E5M2FP8 实际上有两种主流格式E4M34 位指数 3 位尾数最大表示范围约 448尾数精度相对高。适合模型权重和激活值这种数值范围可控的场景。E5M25 位指数 2 位尾数最大表示范围约 57344动态范围大但精度低。适合梯度和需要较大动态范围的中间结果可惜推理阶段基本用不上它因为它只有 2 位尾数靠谱精度太低。所以推理量化时你听到的“FP8 量化”绝大多数是指动态量化/权重量化到 E4M3。需要注意的是E4M3 在数值超过 448 时会溢出因此如果某个层的激活值本身数值分布很散比如没有做 LayerNorm 的层用 FP8 之前需要先观察数值范围必要时对权重做 per-channel 缩放让最大绝对值对齐到可表示区间。一个常见的误区是——不少初学者会问“FP8 就是 INT8 吗”不是。INT8 是整数只有均匀精度没有指数。FP8 每个数都有指数缩放能力所以小数值附近的相对误差比较均匀能更好地保留小权重和大权重之间的相对关系。这也是为什么在部分模型上FP8 效果优于 INT8尤其在像 KV Cache 量化这类需要删除参数分布长尾的场景里优势更明显。4.3 FP8 部署的实操路径如果你想在 GPU 上跑 FP8 模型目前的主流路径是下面四条TensorRT-LLM英伟达官方对 Llama、Qwen、DeepSeek 这类主流架构的模型做了大量 FP8 kernel 优化支持权重 FP8 和 KV Cache FP8。部署时通常先用convert_checkpoint.py或llm-api的--quantize fp8选项量化权重再编译成 TensorRT engine。vLLM社区活跃度极高对 FP8 支持也越来越好。vLLM 支持在启动时直接加载 FP8 权重前提是权重已经转换好比如 Hugging Face 上的 FP8 版本模型。对于不支持的算子vLLM 会自动回退到高精度。Hugging Face Transformers PEFT/Quanto/AutoFP8适合研究调试生产负载少。Ollama / llama.cpp这两者更像“本地跑模型”入口。llama.cpp 当前原生支持 GGUF 的 Q4_0、Q8_0 等整数量化对 FP8 的原生 GGUF 支持仍在迭代中要确认你用的版本是否支持。不管走哪条路常见操作顺序是先做权重量化、再做激活量化最后做 KV Cache 量化。能不动激活就别先动激活往往收益小、风险大。切勿贪多求全。以一个 7B 模型用 TensorRT-LLM 部署的简化流程为例# 1. 下载/转换 HF 模型为 TensorRT-LLM 格式 python convert_checkpoint.py --model_dir ./Llama-7B \ --output_dir ./tllm_checkpoint_fp8 \ --dtype float16 \ --use_fp8_quant \ --quantize_mode fp8 # 2. 编译 TensorRT engine trtllm-build --checkpoint_dir ./tllm_checkpoint_fp8 \ --output_dir ./trt_engines_fp8 \ --gemm_plugin fp8 \ --kv_cache_quant_mode fp8 # 3. 启动服务 python run_server.py --engine_dir ./trt_engines_fp8 \ --max_batch_size 32 --max_input_len 2048 --max_output_len 512这里有个实用的经验如果你发现 FP8 权重加载后显存占用没明显下降大概率是量化根本没生效比如代码里 fallback 到了 BF16。检查方式是在服务日志里看 engine 是不是真的标注了 FP8或者直接对比量化前后权重文件的大小。4.4 FP8 的坑第一波吃螃蟹的人踩过的雷我总结了几个真实项目里最常见的坑供你避雷校准数据选得不对。做 FP8 权重量化时如果用来统计数值范围的数据集和模型业务数据分布差异过大缩放因子就算错了推理效果会崩。建议用一段有代表性的业务采样数据做校准而不是随便拿 dev set 充数。部分算子根本不支持 FP8。TensorRT-LLM 对 MoE 架构Mixtral、DeepSeek-V3 这类的支持就比 Dense 架构晚很多。所以如果你在 MoE 模型上强行开 FP8最后有些专家层算子会静默回退到 FP16/BF16性能提升有限。排查方法是看 profiling 日志里的 kernel 类型看有没有不该出现的 FP16 kernel。长上下文下 KV Cache 数值位移。FP8 的 KV Cache 量化在长序列超过 4K时误差会累积。建议先用短序列测试精度再逐步加长序列观察是否出现质量下降。如果业务场景就是长上下文KV Cache 最好保守用 FP16 或 INT8。TP 推理时的通信开销。用 FP8 权重做张量并行时通信量确实减少了但如果你的并行策略中全规约all-reduce开销占比大总体收益可能不如预期。部署前先用 ncu 或 Nsight 看清瓶颈在哪。5. 部署侧怎么验证精度损失是否可接受5.1 不要只看“跑起来没报错”很多同学部署模型能输出就认为“部署成功”了。但输出“内容相似”不等于“精度无损”。在生产系统里精度损失的评价要看你下游任务的指标比如生成式任务Perplexity 变化分类/抽取任务F1、Accuracy检索/排序任务RecallK数值回归任务MAE、RMSE更关键的是如果上述 benchmark 数据量不够就用一小批业务线上真实数据做对比测试跑出“量化前 FP32 输出”和“量化后 FP8 输出”两种结果计算两者的语义差异度或指标差异。5.2 逐层对比的实操方法如果你定位到模型整体掉点但不知道是哪些层带来的那就得逐层排查。下面是一个比较实用的做法以 PyTorch 为例import torch def trace_activation_stats(model, sample_input): stats {} hooks [] def make_hook(name): def hook(module, input, output): if isinstance(output, torch.Tensor): stats[name] { shape: output.shape, mean: output.float().mean().item(), std: output.float().std().item(), max: output.float().max().item(), min: output.float().min().item(), nan_count: torch.isnan(output).sum().item(), inf_count: torch.isinf(output).sum().item(), } return hook for name, module in model.named_modules(): hooks.append(module.register_forward_hook(make_hook(name))) with torch.no_grad(): model(sample_input) for h in hooks: h.remove() return stats # 分别在 FP32 模型和 FP8/FP16 模型上跑同一个样本然后对比 stats对比时重点看几点max 和 min 是否漂移了几个数量级、有没有 NaN 或 Inf、方差是不是异常变大。如果某个层 max/min 变化超过 5 倍基本可以断定精度问题就出在这一层附近。5.3 数值指标怎么定QuantEval 里的余弦相似度与 KL 散度除了逐层统计通常还会算一下量化前后激活值分布的相似度指标一般用 KL 散度或余弦相似度。经验阈值余弦相似度 0.999 以上算合格0.99~0.999 需要警惕0.99 以下基本不可接受。KL 散度建议控制在 0.1 以内超过 0.5 说明分布已经严重偏离这个阈值在语言模型任务中较常见具体还要结合任务调整。当然最可靠的还是直接看下游任务指标指标合格分布相似度低一些也可以接受。5.4 一个真实案例从“差一点”到“完全可用”的调优过程前阵子把一个原文是小语种的 3B 对话模型从 FP16 切到 FP8 部署跑在线评测时发现生成结果的 BLEU 掉了 3 个点。按上面流程逐层查发现Embedding 层最大激活值从 0.8 变到了 2.1说明该层在 FP8 下没对齐。第 17 层的 LayerNorm 前激活值出现了 3.4% 的 NaN。处理方法是Embedding 层回退到 FP16LayerNorm 前做一次显式的数值缩放把激活值预先乘以系数让 FP8 量化步长更匹配。改完后再测BLEU 只掉了 0.4 个点速度提升了 1.7 倍。你看精度问题不是“只能选一刀切”而是可以精细调控的。6. 选型决策树从业务需求逆推应该用哪种精度6.1 我先列出不同场景的推荐配置根据这几年部署的项目经验我给出一份从实际效果反推的默认配置建议你可以按应用场景对号入座场景硬件约束推荐精度原因云端大模型服务7B-70BA100/H100 多卡FP8权重量化 FP16 Attention吞吐优先FP8 节省带宽云端中小模型1B-7B单张 4090/3090BF16 或 FP16 KV Cache INT8显存刚好放下损失可控边缘设备Jetson/树莓派内存 8GBINT8W8A8内存是最大瓶颈CPU 部署无 GPUINT8/INT4Q8/Q4 GGUFCPU 低精度计算收益最大金融/医疗等高精度场景任意FP32 或 BF16绝不降精度数值异常代价太大研究/快速验证任意FP16/BF16 起步再逐步降迭代期求快上线前再压精度6.2 做决定前先问自己三个问题业务对数值误差的容忍度有多高如果下游是代码生成、算术计算这类对精确值敏感的任务精度损失会被放大。代码里一个 token 错了整个结果就错了。部署环境是 GPU 还是 CPUGPU 看重计算吞吐和显存带宽CPU 更看重内存带宽和缓存命中。GPU 上 FP8/BF16 收益大CPU 上 INT8/INT4 往往是更务实的选择也是 GGUF 之所以流行的原因。你能不能接受“部分层高精度 大部分层低精度”的复杂度如果不能接受宁愿选 BF16 这样整体降精度但几乎无损的方案也不要一刀切切到 FP8。记住一个简单公式精度选的越低你对数值分布的掌控要求就越高。FP32 时代你不用关心数值范围和步长因为表示范围足够宽掉到 FP16 你要开始防溢出掉到 FP8 和 INT8 你要开始做校准和逐层检查。这是“免费午餐”结束后的自然代价。6.3 从 GGUF 到 vLLM不同框架里的精度概念不完全等价搜索热词里有很多关于 Ollama、GGUF、vLLM 的问题这里专门提醒一句GGUF 里的 Q4_K_M、Q8_0 这些量化名和 GPU 量化框架里的 FP8、INT8 不完全是一回事。GGUF 的量化格式是面向 CPU/GPU 混合推理设计的很多是整数量化特别是有对称/非对称的 Q 系列。而 TensorRT-LLM 里的 FP8 是浮点量化。如果你在 Ollama 里拉了一个 Q8_0 的模型又跑去用 vLLM 加载 FP8 权重两个“量化”的效果和计算路径都不一样不能直接对比“都是 8bit 吗”就完事。模型文件的选型规律如下QQ系列Q2_K、Q3_K_S常用于小内存设备但质量损失在语言生成中比较明显。Q5_K_M 是头牌均衡性最好适合普通本地用户。Q8_0 精度接近 FP16文件体积较大。FP8 是 GPU 专属格式主要在 vLLM/TensorRT-LLM 生态里用。如果你用的是树莓派这类 ARM 设备一般就是 CPU 跑 INT4/INT8想清楚再上车。我见过不止一个用户在 vLLM 上试图加载 Ollama 的 GGUF 模型结果不支持。这两个生态的模型格式转换路径完全不同。7. 我的一点实操心得精度调试的“最后一公里”最后分享三个我在实际项目中反复验证过的经验算是这篇文章的彩蛋。第一改精度之前先确认你模型的导出链路是干净的。有些人发现降低精度后效果变差其实是 ONNX 导出时损失了某些自定义算子或者 TensorRT 的 engine 和权重版本不匹配。至少先用 FP32 跑一遍同一个推理脚本确认和原始模型输出一致再动精度。这一条能帮你避免至少一半的“假精度问题”。第二保存一份“数值黄金基线”。在模型上线前用 FP32 模型固定一批测试样本把每一层的激活值统计量保存为 JSON 文件。之后每次切换精度格式或升级推理框架都自动跑一遍对比脚本。这个成本很低但能让你在模型悄悄变“笨”时第一时间发现。这类流程维护起来也简单一个脚本就能搞定。第三善用框架的 profiling 工具。TensorRT-LLM 里--profiling可以导出 per-layer 的耗时PyTorch 里就是torch.profiler。运行时哪一层耗时异常高到底是带宽瓶颈还是算子没融合一目了然。很多时候你以为“用 FP8 会变快”结果发现瓶颈是 CPU 侧的 tokenizer 或 Python 推理循环精度格式根本没影响。先 profiling再优化不冤枉任何一次改动。模型部署的精度选择说到底是一个工程决策而不是学术问题。没有人能替你回答“FP8 够不够”你需要用自己的数据、自己的指标、自己的硬件去实测。但你可以通过系统性的方法和工具把决策过程从“玄学”变成“科学”。希望这篇从 FP32 到 FP8 的梳理能帮你少踩几个坑——尤其是那些“看起来能跑上线就崩”的坑。
