flux-dev-fp8需要多少显存

很多人拿到 flux-dev 的 fp8 权重就往本地塞，结果加载到一半爆显存，或者勉强跑起来一出图就崩。问题不在模型本身，而在没把「加载占用」和「出图峰值占用」分开算。这篇给一套能自己动手核对的估算口径：先算权重底噪，再叠文本编码器和 VAE 的开销，最后按你的分辨率和并发往上加。算完能直接判断手上的卡要不要降分辨率、换更低的量化档，或者干脆走线上。

很多人拿到 flux-dev 的 fp8 权重就往本地塞，结果加载到一半爆显存，或者勉强跑起来一出图就崩。问题通常不在模型本身，而是没把「加载占用」和「出图峰值占用」分开算。这两件事性质完全不同，混在一块估，十有八九会翻车。下面给一套能自己动手核对的估算口径。

思路很简单：先算权重加载这个常驻底噪，再叠文本编码器和 VAE 的开销，最后按你的分辨率、批量、并发往上加。算完你就能判断手上的卡要不要降分辨率、换更低的量化档，还是干脆走线上接口。所有具体数字都以站内当期页面为准，别拿社区流传的截图当标准。

先把「加载占用」和「出图峰值」拆开算

权重加载占用是常驻底噪，只要模型还挂在显存里就一直在。fp8 大致是按参数量折算的，但不同框架、不同切分方式差异不小，别用一句「大概几个 G」糊弄过去。具体到某个模型、某种量化档的数字，去 /models/deploy 的部署测算页核对当时的数值，那里的口径和自己实测更接近。

出图峰值是瞬时叠加出来的，它可能是底噪的好几倍。解码阶段分辨率越高、batch 越大，叠加越猛。你按底噪去配卡，加载没问题，一出图就崩，就是这个原因。显存要按峰值来卡，而不是按加载那一刻卡的。

还有个容易忽略的点：推理框架不同，常驻策略不一样。有的工具倾向用完就卸，显存占用曲线起起伏伏；有的框架倾向常驻换速度，底噪一直压在那。同一份 fp8 权重，换个跑法所需显存就不一样。所以估之前先确定你打算用什么框架跑。

按分辨率和批量往上叠：三个必须自己量的变量

分辨率是第一变量。方图、竖图、横图三条路径的显存曲线并不重合，横竖图的像素量不一样，峰值当然不同。只测一种尺寸就下结论，是最常见的误判来源。建议把你常用的两三种尺寸各跑一遍，记下峰值再比。

• 分辨率：方图、竖图、横图分别跑，别只测一种就认定够用
• 批量与并发：同时出几张图基本是线性叠加，画图服务要按峰值并发预留，不是按单人测试值
• 附加组件别漏：文本编码器、VAE、LoRA 或 ControlNet 类附加权重都是额外常驻，挂两个以上就得重算
• 提示词长度：长提示词会让文本编码阶段多占一点，量不大但别在临界点上忽视

批量这一项特别容易低估。单人测试时出一张，看着刚好；上了服务，三个人同时点，就直接爆。判断标准很简单：你打算让几个人同时用，就按那个数量的峰值去算，而不是按「我只出一张」去算。如果只是自己一个人偶尔用，那可以按单张峰值配，但也要留一点余量给系统和桌面环境。

按卡型分档自查：先判断够不够，再谈快不快

判断顺序是显存容量、显存带宽、算力。容量不够是直接崩，跑不起来；容量够但带宽低，只是慢，图还是能出。很多人把这两件事混在一起，以为慢就是不够，其实完全是两个问题。先确认容量够不够，再谈快不快。

要对照卡型规格，去 /compute/gpus 的加速卡规格库看单卡显存和板卡形态。消费卡和专业卡的可用显存口径不一样，系统占用、驱动开销也不同，别把标称容量直接当可用容量。下面这张对照表帮你分档自查，具体数字以站内页面为准。

什么情况下这套分档不适用？如果你只是偶尔出几张图、不做批量、不挂附加组件，那么显存差一档也可能跑得动，只是要接受更长的等待和更频繁的重试。反过来，只要涉及并发服务，就得按峰值重新算，不能套用单机自测的结论。

显存不够时的降配顺序与验证动作

显存不够，别急着换卡。降配是有优先级的，先把零成本的动作做完，再考虑花钱的。顺序建议：先降分辨率和批量，这两步不花钱、立竿见影；再下量化档位，用精度换显存；最后才考虑换框架或加卡。很多人一上来就想加卡，其实降个分辨率就解决了。

1. 第一步：降分辨率与批量先把输出尺寸往下调一档、批量降到一，重跑一次看还崩不崩，这是零成本验证。
2. 第二步：下量化档位分辨率降了还不够，再换更低的量化档。权重精度相关的底层概念去 /ai-dict/category/tech 查，低比特省显存但细节和稳定性有代价。
3. 第三步：固定变量复测同一提示词、固定随机种子跑一轮，记录显存峰值和耗时，别凭感觉说「好像快了点」。
4. 第四步：统一口径比对去 /tools 里的换算检测工具做统一口径复测，避免不同工具报的数没法横向比。

量化档位的取舍要看你的任务。出图对细节敏感的时候，低比特可能让脸部、文字、细线变形，省了显存却丢了可用性。这时候建议自己出一组对照图，同一提示词跑不同档，肉眼比一比再定。别人说够用，不代表对你的场景够用。

算完再决定：本地跑还是直接调接口

决策分界线是持有成本能不能摊平。出图频率低、峰值需求偶发，本地卡的持有成本很难摊平，走接口往往更划算；出图频率高、模型固定、提示词模板稳定，本地才容易回本。别只看单次出图的快慢，要看你一个月到底出多少张。

• 频率低且偶发：接口更省心，不用管环境、驱动和显存
• 频率高且固定：本地容易回本，但要按峰值并发配卡
• 涉及商用交付：先看许可证与商用边界，去 /safety 的合规条目确认
• 本地只是偶尔用：可以按「底噪装得下、峰值降分辨率」来配，接受折损
• 拿不准：两套都跑小规模对比，再去 /rankings 看同类方案的实际评价

如果你的场景是本地偶尔用，比较务实的配法是让底噪能装下、峰值时主动降分辨率，接受一点画质或速度的折损，而不是硬上更大参数。这种折中的前提是你清楚自己在牺牲什么。要是对外交付、对细节有要求，就别省这一步。