人工智能大模型推理引擎本地部署模型量化模型优化【免费下载链接】ik_llama.cppllama.cpp fork with additional SOTA quants and improved performance项目地址https://gitcode.com/GitHub_Trending/ik/ik_llama.cpp点击查看免费下载导读随着 DeepSeek、Qwen 等厂商开始直接发布 FP8E4M3格式的原生权重推理引擎面临一个新问题如何不经过 BF16/FP16 中间环节直接读取并处理 FP8 原生模型。本文以 ik_llama.cpp 仓库中编号 454 的 PRAdd support for FP8 GGUF creation and re-quantizationWIP为核心复盘该 PR 的目标、实现思路weight_scale_inv与 FP8_E4M3 量化方法、关键设计讨论FP8 矩阵乘法的两种实现路径并结合当前仓库中的转换脚本与量化工具源码进行佐证。读完本文你将理解 FP8 原生模型进入 GGUF 生态所需的技术拼图以及该 PR 最终被关闭的原因与后续启示。一、背景FP8 原生模型与 E4M3 格式FP8 是 8 位浮点格式常见两种变体E4M34 位指数 3 位尾数精度较高是权重存储的主流选择E5M25 位指数 2 位尾数动态范围更大常用于激活值。PR #454 的目标明确限定在E4M3直接处理 FP8E4M3原生模型——先创建一个 FP8 GGUF再进一步量化成可用于推理的 GGUF。PR 作者saood06明确指出对 FP8 权重直接推理不在该 PR 范围内类似于 #169 的做法。该 PR 最初用 Qwen/Qwen3-0.6B-FP8 这个微型模型验证成功创建 GGUF 并能够 dump。作者选择该模型的理由是它「与 DeepSeek 使用相同的 scale 方式」且体积小。而 RedHatAI/Mistral-Nemo-Instruct-2407-FP8 这类模型对 scale 的处理方式不同作者认为若要支持所有 FP8 原生模型这一点必须在后续解决。注本 PR 为 WIP 草稿创建于 2025-05-24最终于 2025-06-15 因实现代码错误被作者主动关闭Closed。二、PR 目标一条「FP8 GGUF → 再量化」的管线该 PR 提出的管线分两步创建 FP8 GGUF把 HF 上以 FP8E4M3原生存储的权重直接打包为 GGUF保留其 FP8 表示而不是先反量化到 FP16/BF16 再存储再量化把 FP8 GGUF 作为中间产物量化为可供推理引擎直接加载的常规量化格式如 Q8_0 或各 IQ 系量化。从当前仓库源码可以确认这条管线的可行性基础convert_hf_to_gguf.py 中LazyTorchTensor._dtype_str_map已经映射了F8_E4M3: torch.float8_e4m3fn和F8_E5M2: torch.float8_e5m2说明转换脚本具备识别 safetensors 中 FP8 dtype 的能力examples/quantize/quantize.cpp 是仓库内完成「再量化」环节的成熟工具llama-quantize其量化类型表中包含 Q8_0、Q6_0、MXFP4、IQ4_XS 等一系列目标格式。也就是说PR #454 所设想的「创建 FP8 GGUF 再量化」两步在仓库现有工具链中分别对应转换脚本识别 FP8 输入与量化工具产出推理格式两大环节。三、实现细节weight_scale_inv 与 FP8_E4M3PR 目前只实现了第一步FP8 GGUF 创建涉及两个关键组成部分weight_scale_invFP8 原生模型尤其 DeepSeek 系通常为按块存储的逆缩放因子张量用于把 FP8 整数位型还原为真实浮点值。该 PR 需要把这一张量一并纳入 GGUF 的张量集合并正确映射FP8_E4M3 量化方法在 GGUF 类型体系中新增一个表示 FP8 E4M3 的量化类型入口。作者在 PR 中特别说明FP8_E4M3的枚举值暂时设为 999因为作者不确定它应该插入到枚举的哪个位置。这一细节侧面反映了给 GGUF 新增一种存储类型的「命名与编号」成本。作为参照当前仓库中 GGUF/ggml 的类型体系可以印证这一点gguf-py/gguf/constants.py 中的GGMLQuantizationType枚举按编号管理如F16 1、BF16 30ggml/include/ggml.h 中ggml_type枚举同样按编号排列GGML_TYPE_F16 1、GGML_TYPE_Q8_0 8、GGML_TYPE_BF16 30并已扩展到 200 号段的 R 系列变体。可见在枚举中插入新类型会影响 GGUF 文件头解析、块大小表GGML_QUANT_SIZES与量化工具的类型表等多处代码这也是 PR 作者以 999 占位、等待上游确认槽位的原因。四、关键设计讨论FP8 矩阵乘法的两条实现路径PR 讨论区中项目作者 ikawrakow 在 2025-05-25 提出了 FP8 权重矩阵乘法实现的核心设计问题这是整个讨论中最具技术价值的部分路径 A先乘 scale 再做 FP8 乘加在乘以 FP8 张量之前需要先用 fp8 的 scale 去乘激活值。即把weight_scale_inv从权重侧转移到激活侧让 FP8 的块级缩放体现在激活上之后直接做 FP8 位型之间的乘加。PR 作者表示这正是他打算采用的方案「这是对我来说最有意义的做法即便另一种方案可能更好」。路径 B直接转换为 Q8_0把 scale 折进 Q8_0 的量另一种选择是直接把 FP8 张量转换为 Q8_0把 scale 折叠进 Q8_0 的量中。Q8_0 在 ggml 中是 32 元素一块、带一个 fp16 scale 的经典量化类型见 ggml/include/ggml.h 与 gguf-py/gguf/constants.py 中GGML_QUANT_SIZES对 Q8_0 的(32, 34)定义。由于 FP8 E4M3 只有 3 位尾数其数值集合有限完全可以无损映射到 8 位整数再配以合适的 scale 表达从而复用 ggml 中成熟的 Q8_0 内核无需为 FP8 编写新的 CPU 内核。作者最终仍然选择了路径 A先乘 scale 再做 FP8 乘加但该 PR 后续因实现代码本身存在错误而被关闭两条路径的取舍最终未在该 PR 内收敛为可合并代码。五、衍生讨论FP4 与 IQ4 的等价性PR 关闭前夕2025-06-15社区成员whatever1983带来了 NVIDIA 官方 FP4 版 DeepSeek-V3-0324 的消息并据此提出「FP8 还没做完就已被 FP4 淘汰」的观点。ikawrakow 的回应澄清了一个关键技术事实FP4 转成其他 4 位表示如 IQ4_K、IQ4_XS是绝对无损的。只需要使用一张与 NVIDIA 的 16 个不同 fp4 值匹配的替代查找表你就得到了 fp4 实现……4 位就是 4 位可以直接使用无需等待 Zen6 或 AMX-FP4也无需 Chitu 内核只需很小的改动即可工作。这与仓库中 IQ4 系量化如 examples/quantize/quantize.cpp 中的IQ4_XS、IQ4_NL、IQ4_KT等的设计理念一致IQ4 系列本身就基于 16 值查找表恰好能容纳 FP4 的 16 个离散值因此从 FP4 原生模型到 IQ4 是「表示级无损」的搬运而不是有损再量化。ikawrakow 还补充了两个观点其一从 FP4 模型出发做 2/3 位量化质量可能高于从 FP8/BF16 出发的同类量化其二NVIDIA 该 FP4 模型约 420GB更接近 5 bpw 而非 4 bpw原因可能是部分张量不是 FP4或采用了 block8 fp8 scale 的方案。这些讨论为后续 FP4/IQ4 工作提供了方向但与 FP8 无关的细节此处不再展开。六、PR 结局与复盘2025-06-15作者saood06主动关闭了该 PR理由非常直白关闭它因为尽管这个方案理论上可行但我的实现是错的……这是一个代码有误的 PR除了作为实现思路的参考外几乎没有在其基础上继续开发的价值。作者同时回应了对 NVIDIA FP4 量化「有推理增益」的猜测基准数字存在误差区间与测试方法差异且没有任何证据表明 NVIDIA 做了量化感知训练或量化后微调DeepSeek 的约 425GB FP4 量化表现与未量化版本大致相当并不算惊艳——仓库讨论区 #477 中展示的曲线在约 370GB 规模就已接近零损失。至于成本与功耗之争作者也指出讨论已偏离 PR 本身的技术主题。七、给后续实现者的启示综合 PR 正文、讨论与当前仓库源码可以提炼出几条可复用的结论FP8 GGUF 创建是可行的第一步转换脚本 convert_hf_to_gguf.py 已具备读取 F8_E4M3 dtype 的能力weight_scale_inv的映射是打通「FP8 原生权重 → FP8 GGUF」的关键FP8 推理矩阵乘法有两条清晰路线先乘 scale 再 FP8 乘加或折叠 scale 为 Q8_0 复用现有内核。后者实现成本更低但前者更能保留 FP8 原生计算路径为未来支持 FP8 硬件加速留出空间GGUF 新增类型存在系统性成本从类型枚举编号参考 ggml/include/ggml.h 与 gguf-py/gguf/constants.py到量化类型表参考 examples/quantize/quantize.cpp 起的类型列表都需同步扩展枚举编号占位如 999只是临时手段FP4 与 IQ4 表示级等价FP4 的 16 个离散值可无损映射到 IQ4 查找表这条路径为未来处理 FP4 原生模型提供了比 FP8 更直接的思路。该 PR 虽已关闭但其提出的「FP8 GGUF 创建 再量化」管线框架、weight_scale_inv处理思路以及关于 FP8/FP4 矩阵乘法的设计讨论仍可作为在 ik_llama.cpp 中接入 FP8/FP4 原生模型的重要参考。赞分享人工智能大模型推理引擎本地部署模型量化模型优化【免费下载链接】ik_llama.cppllama.cpp fork with additional SOTA quants and improved performance项目地址https://gitcode.com/GitHub_Trending/ik/ik_llama.cpp点击查看免费下载相关推荐【亲测免费】 ComfyUI-GGUF为原生ComfyUI模型提供GGUF量化支持ComfyUI GGUF为原生ComfyUI模型提供GGUF量化支持 项目介绍 ComfyUI GGUF 是一个开源项目旨在为原生的 ComfyUI 模型提人工智能模型量化本地部署1Panel 文件管理完整指南不碰 SSH 也能管好服务器文件1Panel 文件管理完整指南不碰 SSH 也能管好服务器文件 半夜要往生产机丢一个配置补丁你还得先开 SSH、翻路径、敲一串 cp 和 scp 。1Pan人工智能大模型推理引擎本地部署模型量化模型优化ik_llama.cpp 对 Microsoft BitNet I2_S 模型的重新量化支持把三元 GGUF 重铸为 IQ2_BNik_llama.cpp 对 Microsoft BitNet I2_S 模型的重新量化支持把三元 GGUF 重铸为 IQ2_BN 导读 本篇技术指南围绕 i人工智能大模型推理引擎本地部署模型量化模型优化创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 FP8 原生模型支持探索：ik_llama.cpp 中 FP8 GGUF 创建与再量化方案复盘（PR 454）
人工智能大模型推理引擎本地部署模型量化模型优化【免费下载链接】ik_llama.cppllama.cpp fork with additional SOTA quants and improved performance项目地址https://gitcode.com/GitHub_Trending/ik/ik_llama.cpp点击查看免费下载导读随着 DeepSeek、Qwen 等厂商开始直接发布 FP8E4M3格式的原生权重推理引擎面临一个新问题如何不经过 BF16/FP16 中间环节直接读取并处理 FP8 原生模型。本文以 ik_llama.cpp 仓库中编号 454 的 PRAdd support for FP8 GGUF creation and re-quantizationWIP为核心复盘该 PR 的目标、实现思路weight_scale_inv与 FP8_E4M3 量化方法、关键设计讨论FP8 矩阵乘法的两种实现路径并结合当前仓库中的转换脚本与量化工具源码进行佐证。读完本文你将理解 FP8 原生模型进入 GGUF 生态所需的技术拼图以及该 PR 最终被关闭的原因与后续启示。一、背景FP8 原生模型与 E4M3 格式FP8 是 8 位浮点格式常见两种变体E4M34 位指数 3 位尾数精度较高是权重存储的主流选择E5M25 位指数 2 位尾数动态范围更大常用于激活值。PR #454 的目标明确限定在E4M3直接处理 FP8E4M3原生模型——先创建一个 FP8 GGUF再进一步量化成可用于推理的 GGUF。PR 作者saood06明确指出对 FP8 权重直接推理不在该 PR 范围内类似于 #169 的做法。该 PR 最初用 Qwen/Qwen3-0.6B-FP8 这个微型模型验证成功创建 GGUF 并能够 dump。作者选择该模型的理由是它「与 DeepSeek 使用相同的 scale 方式」且体积小。而 RedHatAI/Mistral-Nemo-Instruct-2407-FP8 这类模型对 scale 的处理方式不同作者认为若要支持所有 FP8 原生模型这一点必须在后续解决。注本 PR 为 WIP 草稿创建于 2025-05-24最终于 2025-06-15 因实现代码错误被作者主动关闭Closed。二、PR 目标一条「FP8 GGUF → 再量化」的管线该 PR 提出的管线分两步创建 FP8 GGUF把 HF 上以 FP8E4M3原生存储的权重直接打包为 GGUF保留其 FP8 表示而不是先反量化到 FP16/BF16 再存储再量化把 FP8 GGUF 作为中间产物量化为可供推理引擎直接加载的常规量化格式如 Q8_0 或各 IQ 系量化。从当前仓库源码可以确认这条管线的可行性基础convert_hf_to_gguf.py 中LazyTorchTensor._dtype_str_map已经映射了F8_E4M3: torch.float8_e4m3fn和F8_E5M2: torch.float8_e5m2说明转换脚本具备识别 safetensors 中 FP8 dtype 的能力examples/quantize/quantize.cpp 是仓库内完成「再量化」环节的成熟工具llama-quantize其量化类型表中包含 Q8_0、Q6_0、MXFP4、IQ4_XS 等一系列目标格式。也就是说PR #454 所设想的「创建 FP8 GGUF 再量化」两步在仓库现有工具链中分别对应转换脚本识别 FP8 输入与量化工具产出推理格式两大环节。三、实现细节weight_scale_inv 与 FP8_E4M3PR 目前只实现了第一步FP8 GGUF 创建涉及两个关键组成部分weight_scale_invFP8 原生模型尤其 DeepSeek 系通常为按块存储的逆缩放因子张量用于把 FP8 整数位型还原为真实浮点值。该 PR 需要把这一张量一并纳入 GGUF 的张量集合并正确映射FP8_E4M3 量化方法在 GGUF 类型体系中新增一个表示 FP8 E4M3 的量化类型入口。作者在 PR 中特别说明FP8_E4M3的枚举值暂时设为 999因为作者不确定它应该插入到枚举的哪个位置。这一细节侧面反映了给 GGUF 新增一种存储类型的「命名与编号」成本。作为参照当前仓库中 GGUF/ggml 的类型体系可以印证这一点gguf-py/gguf/constants.py 中的GGMLQuantizationType枚举按编号管理如F16 1、BF16 30ggml/include/ggml.h 中ggml_type枚举同样按编号排列GGML_TYPE_F16 1、GGML_TYPE_Q8_0 8、GGML_TYPE_BF16 30并已扩展到 200 号段的 R 系列变体。可见在枚举中插入新类型会影响 GGUF 文件头解析、块大小表GGML_QUANT_SIZES与量化工具的类型表等多处代码这也是 PR 作者以 999 占位、等待上游确认槽位的原因。四、关键设计讨论FP8 矩阵乘法的两条实现路径PR 讨论区中项目作者 ikawrakow 在 2025-05-25 提出了 FP8 权重矩阵乘法实现的核心设计问题这是整个讨论中最具技术价值的部分路径 A先乘 scale 再做 FP8 乘加在乘以 FP8 张量之前需要先用 fp8 的 scale 去乘激活值。即把weight_scale_inv从权重侧转移到激活侧让 FP8 的块级缩放体现在激活上之后直接做 FP8 位型之间的乘加。PR 作者表示这正是他打算采用的方案「这是对我来说最有意义的做法即便另一种方案可能更好」。路径 B直接转换为 Q8_0把 scale 折进 Q8_0 的量另一种选择是直接把 FP8 张量转换为 Q8_0把 scale 折叠进 Q8_0 的量中。Q8_0 在 ggml 中是 32 元素一块、带一个 fp16 scale 的经典量化类型见 ggml/include/ggml.h 与 gguf-py/gguf/constants.py 中GGML_QUANT_SIZES对 Q8_0 的(32, 34)定义。由于 FP8 E4M3 只有 3 位尾数其数值集合有限完全可以无损映射到 8 位整数再配以合适的 scale 表达从而复用 ggml 中成熟的 Q8_0 内核无需为 FP8 编写新的 CPU 内核。作者最终仍然选择了路径 A先乘 scale 再做 FP8 乘加但该 PR 后续因实现代码本身存在错误而被关闭两条路径的取舍最终未在该 PR 内收敛为可合并代码。五、衍生讨论FP4 与 IQ4 的等价性PR 关闭前夕2025-06-15社区成员whatever1983带来了 NVIDIA 官方 FP4 版 DeepSeek-V3-0324 的消息并据此提出「FP8 还没做完就已被 FP4 淘汰」的观点。ikawrakow 的回应澄清了一个关键技术事实FP4 转成其他 4 位表示如 IQ4_K、IQ4_XS是绝对无损的。只需要使用一张与 NVIDIA 的 16 个不同 fp4 值匹配的替代查找表你就得到了 fp4 实现……4 位就是 4 位可以直接使用无需等待 Zen6 或 AMX-FP4也无需 Chitu 内核只需很小的改动即可工作。这与仓库中 IQ4 系量化如 examples/quantize/quantize.cpp 中的IQ4_XS、IQ4_NL、IQ4_KT等的设计理念一致IQ4 系列本身就基于 16 值查找表恰好能容纳 FP4 的 16 个离散值因此从 FP4 原生模型到 IQ4 是「表示级无损」的搬运而不是有损再量化。ikawrakow 还补充了两个观点其一从 FP4 模型出发做 2/3 位量化质量可能高于从 FP8/BF16 出发的同类量化其二NVIDIA 该 FP4 模型约 420GB更接近 5 bpw 而非 4 bpw原因可能是部分张量不是 FP4或采用了 block8 fp8 scale 的方案。这些讨论为后续 FP4/IQ4 工作提供了方向但与 FP8 无关的细节此处不再展开。六、PR 结局与复盘2025-06-15作者saood06主动关闭了该 PR理由非常直白关闭它因为尽管这个方案理论上可行但我的实现是错的……这是一个代码有误的 PR除了作为实现思路的参考外几乎没有在其基础上继续开发的价值。作者同时回应了对 NVIDIA FP4 量化「有推理增益」的猜测基准数字存在误差区间与测试方法差异且没有任何证据表明 NVIDIA 做了量化感知训练或量化后微调DeepSeek 的约 425GB FP4 量化表现与未量化版本大致相当并不算惊艳——仓库讨论区 #477 中展示的曲线在约 370GB 规模就已接近零损失。至于成本与功耗之争作者也指出讨论已偏离 PR 本身的技术主题。七、给后续实现者的启示综合 PR 正文、讨论与当前仓库源码可以提炼出几条可复用的结论FP8 GGUF 创建是可行的第一步转换脚本 convert_hf_to_gguf.py 已具备读取 F8_E4M3 dtype 的能力weight_scale_inv的映射是打通「FP8 原生权重 → FP8 GGUF」的关键FP8 推理矩阵乘法有两条清晰路线先乘 scale 再 FP8 乘加或折叠 scale 为 Q8_0 复用现有内核。后者实现成本更低但前者更能保留 FP8 原生计算路径为未来支持 FP8 硬件加速留出空间GGUF 新增类型存在系统性成本从类型枚举编号参考 ggml/include/ggml.h 与 gguf-py/gguf/constants.py到量化类型表参考 examples/quantize/quantize.cpp 起的类型列表都需同步扩展枚举编号占位如 999只是临时手段FP4 与 IQ4 表示级等价FP4 的 16 个离散值可无损映射到 IQ4 查找表这条路径为未来处理 FP4 原生模型提供了比 FP8 更直接的思路。该 PR 虽已关闭但其提出的「FP8 GGUF 创建 再量化」管线框架、weight_scale_inv处理思路以及关于 FP8/FP4 矩阵乘法的设计讨论仍可作为在 ik_llama.cpp 中接入 FP8/FP4 原生模型的重要参考。赞分享人工智能大模型推理引擎本地部署模型量化模型优化【免费下载链接】ik_llama.cppllama.cpp fork with additional SOTA quants and improved performance项目地址https://gitcode.com/GitHub_Trending/ik/ik_llama.cpp点击查看免费下载相关推荐【亲测免费】 ComfyUI-GGUF为原生ComfyUI模型提供GGUF量化支持ComfyUI GGUF为原生ComfyUI模型提供GGUF量化支持 项目介绍 ComfyUI GGUF 是一个开源项目旨在为原生的 ComfyUI 模型提人工智能模型量化本地部署1Panel 文件管理完整指南不碰 SSH 也能管好服务器文件1Panel 文件管理完整指南不碰 SSH 也能管好服务器文件 半夜要往生产机丢一个配置补丁你还得先开 SSH、翻路径、敲一串 cp 和 scp 。1Pan人工智能大模型推理引擎本地部署模型量化模型优化ik_llama.cpp 对 Microsoft BitNet I2_S 模型的重新量化支持把三元 GGUF 重铸为 IQ2_BNik_llama.cpp 对 Microsoft BitNet I2_S 模型的重新量化支持把三元 GGUF 重铸为 IQ2_BN 导读 本篇技术指南围绕 i人工智能大模型推理引擎本地部署模型量化模型优化创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考