NVFP4 把本地部署重新绑回英伟达国产卡与 AMD 的量化生态怎么办【免费下载链接】GEV-26B-Decide-NVFP4项目地址: https://ai.gitcode.com/hf_mirrors/autotrust/GEV-26B-Decide-NVFP42026 年 10 月AutoTrust AI 放出了 GEV-26B-Decide 的 NVFP4 量化版同样一套基于 Gemma-4-26B-A4B 的决策权重从 bf16 的 49.5 GB 下载体积、51.1 GiB 显存占用压到 18 GB / 17.1 GiB——一张 24 GB 消费卡就能本地跑起带视觉的决策模型System 1 单次决策约 45 ms见 README.md。表面看这是本地部署普惠化的又一里程碑把仓库拆开看则会发现硬币的另一面NVFP4 是一份写在 NVIDIA 硬件 IP 上的格式从数值表示、张量布局到 kernel 选择都贴着 Blackwell 架构设计量化普惠的另一重身份是生态锁定的又一次加固。本文以这个仓库为解剖样本拆解 NVFP4 的硬件绑定机制盘点国产卡与 AMD 在低比特量化上的替代路径并讨论模型适配硬件还是硬件适配模型的路线之争。NVFP4 不是4-bit 通用格式是一套 NVIDIA 专属协议先看这份量化到底做了什么。GEV-26B-Decide-NVFP4 只量化了一个部分3,840 个路由专家 MLP30 层 × 128 专家的权重投影。打开 config.json 里的quantization_config可以看到完整的排除名单lm_head、视觉塔、每一层的 dense MLP、router、self-attention 全部保持 bf16 原样只有experts.*落入量化目标。原因很实际——MoE 的路由专家占了大头权重26B 参数里约 22 GB 属于可量化的专家权重而 attention、dense MLP 要么承载 LoRA、要么体量太小量化它们省不下多少内存反而要付出精度与 Kernel 兼容的双重成本。System 1 的 LoRA 适配器完全不触碰专家权重因此量化后连决策头都不需要重训adapter_vllm/adapter_config.json 与 bf16 版完全一致。NVFP4 的具体格式由 NVIDIA 定义权重以 FP4 E2M11 位符号、2 位指数、1 位尾数存储每 16 个值一组每组配一个 FP8 E4M3 的 scale整个张量再配一个 FP32 的 scale。这在 model.safetensors.index.json 的权重清单里一目了然——每个experts.*.gate/up/down_proj.weight都跟着weight_scale、weight_scale_2、input_scale三个配套张量前者是组级 FP8 scale后者是张量级 FP32 scaleinput_scale则是静态激活 scale。激活的量化范围不是实时统计的而是在 3,072 条 System 1 校准 prompt 上预先标定结果沉淀在 nvfp4_activation_amax.json。gate 与 up 投影还共享同一个 tensor scale因为 vLLM 把二者融合成了单个 kernel。这套布局直接来自 NVIDIA 的 ModelOpt 工具链hf_quant_config.json 标注 producer 为jev-judge scripts/export_nvfp4_experts.pyquant_method: modeloptvLLM 读 config.json 的quantization_config就能无 flag 加载。方便是方便但格式定义权也因此握在 NVIDIA 手里——FP4 的存储格式、组内 scale 语义、kernel 选择全部是英伟达主导制定的技术栈而不是 OCP 这类开放标准组织定义的通用格式。一张支持矩阵暴露的硬件门槛这份权重在不同硬件上能跑出什么效果仓库里写得毫不含糊README.md硬件架构/SMNVFP4 运行方式状态B200 / B300 / GB200SM100原生 W4A4FlashInfer TRT-LLM NVFP4 MoE kernel已实测B200RTX PRO 6000 / RTX 5090 / DGX SparkSM12x原生 W4A4CUTLASS / FlashInfer CUTLASS FP4 MoE kernel未实测H100 / H200 / A100SM80–90Marlin W4A16权重 FP4、激活 bf16未实测V100 及更老SM70无对应 kernel不支持注意两个关键点。其一FP4 张量核是 Blackwell 引入的硬件能力H100/A100 只有 FP8 张量核NVFP4 权重在它们上面只能以存储省内存、计算反量化回 bf16的 W4A16 方式跑——内存红利保住了速度红利没了。其二原生 W4A4 只存在于 SM100 与 SM12x即 Blackwell 数据中心卡和最新的 Blackwell 消费卡RTX 5090、RTX PRO 6000。这份权重是一鱼多吃的格式但真正兑现45 ms 决策 低显存完整价值的只有最新的英伟达硬件。这还只是 NVIDIA 自家产品线的兼容层级对 AMD 与国产加速卡目前的主流开源推理发行版里根本没有对应的 NVFP4 MoE kernel 可谈。更隐蔽的锁定在软件依赖里。这个仓库的部署需要 vLLM 的 2026 年 9 月开发版构建外加打上 patches/vllm-gemma4-lm-head-lora.patch 才能跑一个 patch 把 LoRA 的词表上限从 258,048 抬到 262,144 以适配 Gemma-4 的 tiedlm_head另一个 backport 了上游 vLLM 的 #39816 修复解决 Gemma-4 别名模块在 LoRA 激活时被静默重置的问题。也就是说格式与框架是同步演进的用户要持续跟踪 dev 分支而对 vLLM 的 AMD/国产卡移植分支来说跟进这类 formatkernelLoRA 三重耦合的改动成本比跟进纯数据格式高得多。国产卡与 AMD 的低比特替代路线盘点在 NVFP4 覆盖不到的平台上低比特量化生态事实上分化成了几条并行路线。从社区情报与部署实践看主要有五条整数 4-bitAWQ / GPTQ。这是目前兼容面最广的低比特路线。AWQ 走 W4A16依赖的是老架构也普遍支持的 INT4 权重 16 位激活计算路径社区里V100 单卡部署 Qwen3.8-27BAWQ的实战就是典型例证——在 Volta 这样连 FP8 都没有的老卡上整数量化几乎是唯一可行的低比特方案。代价是激活不压缩内存收益弱于 NVFP4但胜在哪里有 INT 张量核哪里就能跑。FP8 路线。H100 起成为 NVIDIA 数据中心卡的主流而 AMD 的 ROCm 与国产昇腾的 CANN 生态对 FP8 的支持广度明显优于 FP4。FP8 密度不如 4-bit但它是当前跨厂商兼容性最好的浮点量化档位也是不少国产框架的默认量化格式。三进制ternary表示。这是绕过厂商格式最彻底的一类。社区近期出现了把 Qwen3.8-27B 压到 7 GB 部署的三进制模型权重取值只有 -1/0/1的实测手记——它不依赖任何厂商的专用张量核指令纯粹靠模型结构本身的稀疏性与表示效率变轻因此对硬件平台天然中立被视为下一代边缘部署格式的有力候选。开放标准 MXFP4。由 OCP 定义的可缩放格式MX 系列AMD 是参与推动的重要一方。它提供与 NVFP4 同级的 4-bit 密度但格式定义开放理论上任何硬件厂商都能实现 kernel——这是FP4 级压缩但不受制于人的最直接答案也是 AMD 对抗英伟达 FP4 生态锁定的关键棋。国产自研栈。华为昇腾、摩尔线程、寒武纪等平台的推理栈主流做法仍以 INT8/INT4 为主接入方式多是让 llama.cpp、vLLM 等开源框架读取 GGUF、GPTQ、AWQ 这类开放格式再做自家 kernel 适配。国产卡的 FP4 原生支持尚处于早期短期内很难指望厂商为 NVIDIA 定义的 NVFP4 布局投入工程资源。路线数值表示硬件绑定度生态成熟度NVFP4ModelOptFP4 E2M1 浮点极高绑定 Blackwell SM100/SM12x英伟达全栈力推AWQ / GPTQINT4 整数低W4A16老卡可用成熟跨框架FP8FP8 浮点中H100ROCm/CANN 覆盖较好成熟三进制-1/0/1极低硬件中立新兴MXFP4OCP可缩放 FP4低开放标准待 kernel标准制定期国产栈INT4/INT8整数为主低跟随开放格式平台各自为战模型适配硬件还是硬件适配模型路线之争的本质这两条路线在 GEV-26B-Decide-NVFP4 仓库里恰好都能找到实证。模型适配硬件的最优解是发布即绑定。模型发布方直接用 ModelOpt 工具链把权重裁剪成 NVFP4 布局vLLM 读quant_method: modelopt自动匹配 kernel用户零配置拿到为英伟达准备好了一切的成品。这是最极致的便利也是生态锁定的最高效形式权重格式、张量布局、kernel 选择、推理框架版本全链条拧成一股绳。对一个只想5 分钟跑起来的本地部署者这是无可辩驳的最佳体验。但模型适配硬件的成本没有消失只是转移了。看 serve.sh 和 patches/vllm-gemma4-lm-head-lora.patch为了把决策头作为lm_headLoRA 挂上 NVFP4 专家仓库必须捆绑一个未发布的 vLLM dev 构建和两个手工 patch为了在旧架构上兼容vLLM 又得为同一份权重维护 W4A4SM100、CUTLASS W4A4SM12x、Marlin W4A16SM80-90三套 kernel——这正是硬件适配模型推理框架替各代硬件兜底让一份权重尽量多跑几代卡。代价是兼容是有损的A100 上 FP4 权重最终反量化回 bf16 参与计算速度红利归零AMD 与国产卡则连这条有损路径都尚未进入主流发行版。反例同样在社区里生长。三进制模型和 AWQ 部署的走红说明当模型发布方选择硬件中立的数值表示时谁家的卡问题就被降级成谁的 kernel 实现得更好——竞争回到工程层面而非格式主权层面。这条路牺牲了一点发布即最优的便利换来了权重资产的长期可移植性。所以这场路线之争的实质是**在哪一层做标准化**。NVIDIA 选择在硬件指令集 工具链层标准化FP4 ModelOpt TRT-LLM vLLM kernel 矩阵把兼容成本转嫁给其他平台与旧硬件开源推理框架则试图在格式解析层做平权让开放格式跑遍各家卡。对 AMD 与国产卡用户而言现实的选择是押注 INT4、FP8、MXFP4、三进制这类可移植表示而不是等待 NVFP4 的适配——后者不仅依赖 NVIDIA 的 kernel 开源意愿还依赖 ModelOpt 布局本身的开放程度。值得一提的是GEV-26B-Decide 的发布策略本身给了一个相对健康的示范bf16 权重仓库完整保留NVFP4 只是作为可选加速档存在README.md 里也如实标注了未实测的硬件与量化后的精度变化GPQA Diamond 44.9% vs bf16 的 43.9%HLE 9.7% vs 8.4%均在 ±7 点的运行噪声内。量化从来不只是位宽问题——NVFP4 用 66% 的显存压缩换回了 Blackwell 的生态优先权这份性能账背后还压着一份生态账。当 17 GB 的诱惑摆在面前时值得先问一句这份权重五年后还能在你的下一张卡上跑吗【免费下载链接】GEV-26B-Decide-NVFP4项目地址: https://ai.gitcode.com/hf_mirrors/autotrust/GEV-26B-Decide-NVFP4创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
