看到一个量化模型，文件很小，介绍里又有好看的运行结果参数，很容易觉得自己的显卡也能跟着受益。但换到另一套环境，可能只是终于装得下，响应速度并没有提高。
下载文件变小、运行时显存减少、用户更快拿到答案，是三件需要分别验证的事。
如果你手里是 RTX 3090，这个问题尤其值得在下载前想清楚。这篇不提供双卡实测成绩，而是给出判断顺序：模型以什么格式保存，框架选了哪个计算内核，显卡怎样执行，再用相同任务比较。文档核验日期为 2026 年 9 月 25 日，具体支持情况要以准备部署的版本为准。
4bit 只说了多宽，没有说怎么算
“4bit 模型”可能涉及量化方法、数值格式、文件封装和执行内核。这些东西有联系，但不能互相代替。
AWQ、GPTQ 是常见的权重量化方法；具体模型还会选择位宽、分组和保存配置。NVFP4 则是一种低精度浮点表示方式。看到它们都出现在量化菜单里，不能说明它们描述的是同一件事。GGUF 这样的文件封装，也不能只凭扩展名判断内部用了哪种量化类型。
还要看被压缩的是谁。W4A16 表示权重采用 4bit 表示、激活采用 16bit；W4A4 则把两者都放到 4bit。这种写法仍不能说明所有运算和累加都使用同样的精度。
对某些任务，读权重占了较多时间，减少搬运的数据可能有帮助。但执行过程中还有解码、反量化、矩阵计算和其他开销。若原本主要卡在计算，压缩带来的节省可能抵不过增加的处理。
这也解释了为什么同一个方案在不同输入长度、批量和并发下，结果可能变化。不能只问“这个模型是不是 4bit”，还要问“在这个框架里，它走哪条执行路径”。
3090 没有原生 FP4，不等于所有 FP4 模型都不能跑
NVIDIA 的计算能力列表把 RTX 3090 列为 8.6，也就是通常说的 SM 8.6。它属于 Ampere，不能把 Blackwell 的原生 NVFP4 硬件加速直接套过来。
NVIDIA 对 NVFP4 的说明介绍了 Blackwell 的对应硬件支持，以及分组缩放等设计。低位宽数值怎样存储、计算硬件怎样处理它们，都需要看清楚。
但如果顺着这个事实说“3090 完全不能运行 FP4 模型”，也说过头了。
当前 vLLM 文档展示了通过 Marlin 执行 NVFP4 权重的实现。这条路径采用 W4A16，而不是把旧显卡变成原生 FP4 显卡。源码中的提示也说得很直接：缺少原生 FP4 支持时，采用权重压缩的方式，计算密集的工作负载可能性能下降。
这里要保留条件。存在这个内核，不代表每个 NVFP4 模型、每种层结构、每个框架版本都能在 3090 上正常运行。vLLM 的兼容表可以帮助筛选方向，真正部署仍要核对模型配置和启动日志里选中的实现。
所以，遇到 FP4 模型时，先查有没有匹配的加载与计算路径。能运行后，再确认是否节省了你需要的资源。看到启动成功，还不能宣布加速成功。
两张 24GB，也不能直接按一张 48GB 来算
可以用参数量乘位宽粗估权重数据。例如，假设一个模型有 80 亿个参数，全部只按每个参数 4bit 计算，原始权重数值约占 40 亿字节，也就是 4GB，约 3.73GiB。
这只是刻意简化的算术示例，不是某个模型的实际文件大小，更不是完整显存需求。分组缩放、其他量化信息和保持较高精度的部分都会改变结果。
运行时还需要放激活、中间工作区，以及生成过程中保存历史注意力信息的 KV cache。上下文变长、同时处理更多请求，容量压力也会变化；具体占用取决于模型结构和框架实现，不能拿权重大小直接代替。
两张卡能否分担这些内容，要看模型怎样切分。即使总量没有超过两张卡显存之和，也可能某一张先装满。模型并行还会引入通信，实际连接方式和拓扑需要检查，不能因为型号支持某种连接，就假定机器已经装好或框架已经用上。
如果目标模型单卡能放下，双卡也未必会让单个请求更快。双卡可能主要帮助容量或并发，要按需求验证。看结果时保留每张卡的峰值，不要只看一个总数。
软件版本不能只看一个 CUDA 数字
显卡驱动、系统 CUDA Toolkit、PyTorch 构建所用的 CUDA 运行时，是不同的层。nvidia-smi 里的 CUDA 显示不能当成已经安装的 Toolkit 版本，PyTorch 版本后面的 CUDA 标识也不能替代驱动兼容检查。
按 NVIDIA 当前的小版本兼容说明，CUDA 12.x 家族的最低驱动范围从 525 起，CUDA 13.x 从 580 起。但小版本兼容有功能限制，涉及新特性或 PTX 的执行还可能需要更高驱动。达到最低值不等于任意新框架都能正常工作。
假设旧环境还在使用 535 系列驱动和较早的 PyTorch，不应直接安装一个要求 CUDA 13 的新包，再把失败归因于“3090 不支持量化”。硬件能力、驱动要求、框架二进制和模型格式，要分开排查。
比较稳妥的做法是保留现有环境，另建隔离测试环境，并记录模型版本、框架版本、PyTorch 构建、驱动和启动参数。Python 环境隔离不能替你隔离宿主机驱动，容器也不会凭空补齐缺失的硬件能力。
模型文件统一放到项目的 ./models，安装包和其他依赖提前准备本地副本，更适合内网迁移。这里不给出“升级到最新版”的通用命令，因为没有一个脱离目标模型的安装组合，可以保证适合所有旧环境。
用同一批任务比较，结果才有意义
准备一个短输入请求、一个长输入请求和一组并发请求。它们分别帮助观察逐步生成、输入处理和多请求服务时的表现。这里是在设计测试，不预设哪个量化方案胜出。
每轮尽量保持基础模型、输入内容、输入输出长度、采样设置和服务参数一致。预热后再计时，重复运行，并把缓存策略写清楚。若允许前缀缓存，不能让一个方案命中缓存、另一个方案冷启动，再比较响应速度。
一次测试至少记录这些信息：
- 模型与量化配置、软件版本、实际内核，以及单卡还是双卡。
- 输入和输出 token 数、并发量、上下文限制、缓存和预热方式。
- 首字延迟，即请求发出到收到第一个输出 token 的时间。
- 后续生成速率、整体吞吐，以及每张卡的峰值显存。
- 重复运行的波动、报错和答案检查结果。
这些指标不能互相替代。整体吞吐上升，用户等待第一个字的时间仍可能变长；短输入表现不错，也不能保证长文档处理一样合适。测延迟时还要说明是否包含排队和网络，否则两个数字可能根本不是一个口径。
质量也要一起检查。用可以核对的公开或虚构材料，测试信息提取、数字保持、格式遵循等你实际需要的任务。别只看模型能不能说出一段通顺的话。
如果高精度版本在同一台机器上装不下，就明确写成“量化后使这个模型在该设备上可运行”。若把高精度版本放到另一台大显存机器上比较，需要列出硬件差异，不能得出单由量化带来的加速倍数。
下载模型前要做的事
对 3090 用户，我更倾向于从已有明确支持记录的候选方案开始验证，不按格式名称的新旧排序。AWQ、GPTQ 或其他方案有没有合适实现，需要结合选定模型和框架版本判断。
下载前确认模型结构、许可证、量化配置和目标框架支持；启动后确认实际内核；跑请求时看容量、延迟和答案是否达到要求。若问题出在驱动或加载配置，先修这个问题，不要直接换一个更小的模型掩盖它。
不确定时，把模型地址与版本、量化配置、GPU 拓扑、驱动、框架版本、完整启动参数和脱敏报错整理出来。这些信息比一句“4bit 为什么很慢”更容易定位原因。
模型更小是一项收益。如果你的目标是降低延迟，还需要证明它在自己的任务上更快；如果目标是让原本装不下的模型运行起来，也没有必要为了一个不适用的加速数字反复折腾。
需要讨论具体部署组合，可以带上上述环境信息和最小复现，通过我的 GitHub交流。