🚨 融合的 HC norm 一直在浪费它已经付出的量化开销。它写出 10240 宽的数据流，然后 MMQ 在 T=8192 时再读取其中 335 MB，只是为了生成 hc_down 所需的 Q8_1 副本。现在该 kernel 直接在数值仍在寄存器中时写出这份副本。数学结果完全一致。MMQ 跳过了量化步骤。

⚡ pp8192 与 main 对比，ub 8192：1066.0 / 1062.4 → 1102.0 / 1103.0（+3.6%） ⚡ ub 2048：875.7 / 874.4 → 902.2 / 905.0（+3.2%） ⚡ ub 512：664.2 / 662.6 → 678.8 / 678.1（+2.3%）

✅ 逐位一致。两种情况下 KL 与 CPU 均为 0.009566 / 96.77%。

https://github.com/ROCmFPX/ROCmFPX/pull/48

@Italianclownz @AIatAMD

ROCmFPX/ROCmFPX

来源：https://github.com/ROCmFPX/ROCmFPX

ROCmFPX — Max Performance. Open Power.

ROCmFPX llama.cpp

这个公开的下游仓库在跟进上游 llama.cpp 当前进展的同时，为 AMD GPU 开发 ROCmFPX 权重格式系列。正常的 Vulkan 支持保持启用；HIP 和 CPU 也是受支持的构建目标。现有的 NVFP4 GGUF 张量可以原生加载，并且在使用 NVFP4 量化预设补全 NVFP4 模型时保持逐位精确。

Carlo Pasquale（Charlie12345）是 ROCmFPX 格式系列以及 ROCmFP3、ROCmFP4、ROCmFP6 和 ROCmFP8 的创建者与创始人。参见 ROCmFPX 文档、NOTICE，以及在上游 MIT 许可证条款 基础上附加 ROCmFPX 版权声明的版本。

贡献者与历史

ROCmFPX 保留了上游 llama.cpp 的血统以及公开的遗留 ROCmFPX 血统。原始提交作者和提交 ID 仍然可查。遗留血统通过仅祖先关系（ancestry-only）的合并连接，其源码树与当前 ROCmFPX 树完全相同，因此遗留代码不会替换当前实现。

• 当前 ROCmFPX 贡献者（https://github.com/ROCmFPX/ROCmFPX/graphs/contributors）
• 遗留 ROCmFPX 贡献者（https://github.com/charlie12345/ROCmFPX/graphs/contributors）
• 上游 llama.cpp 贡献者（https://github.com/ggml-org/llama.cpp/graphs/contributors）

GitHub 的贡献者显示可能滞后于仓库历史。完整的提交级作者记录也可以通过 git shortlog -sne main 获取。

当前已验证的格式为实验性。ROCmFP2/3/4/6/8 的磁盘布局已冻结以保证兼容性；新的 kernel 和量化器工作必须保持其编码大小和语义不变。

ROCmFP2 张量类型标识

规范的双缩放 S40 ROCmFP2 使用 GGUF 张量类型 111。其负载仍然严格为每 32 个权重 10 字节（2.5 bpw）；只是张量类型标签发生了变化。遗留类型 107 被保留为有歧义的类型，因为双缩放 S40 和仿射 code * scale - offset 布局曾使用相同的 ID 和块大小输出。ROCmFPX 拒绝类型 107，而不是猜测并静默损坏模型。新的量化会自动写入类型 111。

要审计旧文件，请运行：

scripts/rocmfpx/retag-legacy-rocmfp2.py MODEL.gguf

只有当文件的来源确认其使用双缩放 S40 时，才备份并原地重新标记其张量头：

scripts/rocmfpx/retag-legacy-rocmfp2.py MODEL.gguf \
  --layout s40-dual-scale-v1 --apply

该工具不会检查或推断布局，因为这两种解释无法从字节本身区分。不要将其用于仿射 ROCmFP2 文件。

可选的 Charlie Vulkan 插件

可选的 ROCmFPXVulkan 扩展 将经过验证的 Charlie 时代 ROCmFP4 Vulkan 路径保留为一个独立后端。它不会替换或修补 llama.cpp 的常规 Vulkan0 后端。该扩展默认禁用，只有在构建并显式加载后才会以 ROCmFPXVulkan0 出现。

在 Linux 上同时构建常规 Vulkan 后端和可选扩展：

cmake -S . -B build-rocmfpx-vulkan -G Ninja \
  -DCMAKE_BUILD_TYPE=Release \
  -DBUILD_SHARED_LIBS=ON \
  -DGGML_VULKAN=ON \
  -DROCMFPX_VULKAN_PLUGIN=ON
cmake --build build-rocmfpx-vulkan \
  --target llama-cli rocmfpx-vulkan-plugin -j

加载插件并选择其设备：

export ROCMFPX_PLUGIN_PATH="$PWD/build-rocmfpx-vulkan/bin/rocmfpx-vulkan-plugin.so"
build-rocmfpx-vulkan/bin/llama-cli --list-devices
build-rocmfpx-vulkan/bin/llama-cli \
  -m /absolute/path/to/model.gguf \
  -dev ROCmFPXVulkan0 -ngl 999

请将 rocmfpx-vulkan-plugin.so 及其同级文件 libggml-rocmfpx-vulkan.so 放在一起。两个文件必须来自相同的构建和 ROCmFPX 提交。--list-devices 应同时显示 Vulkan0 和 ROCmFPXVulkan0；移除 ROCMFPX_PLUGIN_PATH 即可返回常规后端。

参见扩展指南了解匹配的 ROCmFP4 基准测试和验证限制。

插件系统

ROCmFPX 插件 ABI v1 允许受信任的本地共享库注册标准的 ggml 后端，或接收模型打开和模型关闭通知，用于 PLE、KV 检查点、重打包缓存（repack-cache）和专家流式旁挂文件（expert-streaming sidecars）。在启动 ROCmFPX 工具之前，将 ROCMFPX_PLUGIN_PATH 设置为插件文件或目录。在 Linux 和 macOS 上使用 : 分隔条目，在 Windows 上使用 ;。目录只扫描一次，不递归，按排序顺序进行；当前工作目录永远不会被自动搜索。

一个最简 C 插件如下所示：

#define ROCMFPX_PLUGIN_BUILD
#include "rocmfpx-plugin.h"

static int on_load(void)
{
    return 0;
}

static const struct rocmfpx_plugin_v1 plugin = {
    ROCMFPX_PLUGIN_ABI_VERSION,
    sizeof(struct rocmfpx_plugin_v1),
    "example-sidecar",
    "0.1.0",
    ROCMFPX_PLUGIN_CAP_SIDECAR,
    on_load,
    0,
    0,
    0,
};

ROCMFPX_PLUGIN_EXPORT const struct rocmfpx_plugin_v1 *
rocmfpx_plugin_query(
    uint32_t host_abi_version,
    const struct rocmfpx_plugin_host_v1 * host)
{
    if (host_abi_version != ROCMFPX_PLUGIN_ABI_VERSION ||
        !host ||
        host->abi_version != ROCMFPX_PLUGIN_ABI_VERSION) {
        return 0;
    }
    return &plugin;
}

在 Linux 上构建并加载：

cc -shared -fPIC -I/path/to/ROCmFPX/include \
  example-sidecar.c -o example-sidecar.so
ROCMFPX_PLUGIN_PATH="$PWD/example-sidecar.so" \
  /path/to/ROCmFPX/build/bin/llama-cli --list-devices

每个插件都必须导出 rocmfpx_plugin_query、验证 ABI、返回静态的带版本描述符，并在卸载之前保持该描述符及其字符串有效。后端插件在查询期间复制 backend_load 和 plugin_path，然后从 on_load 注册其对应的 ggml 后端。旁挂插件使用 on_model_open 和 on_model_close，并按 model_id 管理其状态。ABI v1 提供发现、后端注册和生命周期通知；仅凭能力标志并不能拦截张量或 token 生成。

插件以本地代码运行，权限与 ROCmFPX 相同，因此只加载你信任的库。

参见完整的插件和旁挂 ABI 指南以及经过测试的 rocmfpx-test-plugin 示例。

Windows AMD 多 GPU 桥接

拥有两块 AMD GPU 的 Windows 用户可以试用 Charlie12345 的外部 Windows AMD Multi-GPU Bridge（https://github.com/charlie12345/windows-amd-vllm-multigpu）。对于 ROCmFPX 和 llama.cpp，请使用其专用的 Windows 安装指南（https://github.com/charlie12345/windows-amd-vllm-multigpu/blob/main/docs/install-llama-rocmfpx.md），而非单独的 vLLM 适配器说明。

该桥接不修改 ROCmFPX 源码树。它为现有的 HIP 集合通信接口提供外部的 roc::rccl CMake 包，因此构建 ROCmFPX 时设置 GGML_HIP_RCCL=ON，将 rccl_DIR 指向已安装的桥接，并使用桥接提供的 run-with-llama-plugin.ps1 启动脚本。

经过测试的 Windows 路径还需要 GGML_CUDA_NO_PEER_COPY=ON；请参照外部指南获取匹配的 ROCm 版本、GPU target、DLL 布局、健康检查以及特定模型的启动参数。

尽管启动脚本的名称如此，此传输层不通过 ROCMFPX_PLUGIN_PATH 加载，也不是 ROCmFPX ABI v1 插件。ABI v1 可以注册 ggml 后端或接收模型生命周期通知，但无法注入链接期的 RCCL 提供者或拦截集合通信。因此将 ROCMFPX_PLUGIN_PATH 指向 rccl.dll 不会起任何作用。

当前的外部包设计是上游安全的集成方式：正常更新 ROCmFPX，然后针对桥接包重新配置一次全新的 HIP 构建。该桥接是实验性的、仅源码发布，目前仅在其维护者列出的硬件和修订版本上经过验证。在加载大模型之前，请先验证其小型的 parity 和传输测试；可以选择 GPU target 并不等同于运行时已验证的配置。

llama.cpp

llama

用 C/C++ 实现的 LLM 推理

许可证：MIT（https://opensource.org/licenses/MIT）

Release（https://github.com/ggml-org/llama.cpp/releases?q=tag:v0） Nightly（https://github.com/ggml-org/llama.cpp/releases?q=b） Server（https://github.com/ggml-org/llama.cpp/actions/workflows/server.yml） Docker（https://github.com/ggml-org/llama.cpp/actions/workflows/docker.yml） Winget（https://github.com/ggml-org/llama.cpp/actions/workflows/winget.yml） ggml（https://github.com/ggml-org/ggml） / ops（https://github.com/ggml-org/llama.cpp/blob/master/docs/ops.md） / maintainer PRs（https://github.com/ggml-org/llama.cpp/issues?q=is%3Apr%20is%3Aopen%20draft%3AFalse%20(author%3Argerganov%20OR%20author%3AKitaitiMakoto%20OR%20author%3Adanbev%20OR%20author%3Aaldehir%20OR%20author%3Amax-krasnyansky%20OR%20author%3ACISC%20OR%20author%3Aggerganov%20OR%20author%3Aam17an%20OR%20author%3Ajhen0409%20OR%20author%3Abartowski1182%20OR%20author%3Anikwen%20OR%20author%3Ahipudding%20OR%20author%3Aravi9%20OR%20author%3AServeurpersoCom%20OR%20author%3Apwilkin%20OR%20author%3Areeselevine%20OR%20author%3Angxson%20OR%20author%3Ajeffbolznv%20OR%20author%3Amarty1885%20OR%20author%3A0cc4m%20OR%20author%3ATitaniumtown%20OR%20author%3Aangt%20OR%20author%3AIMbackK%20OR%20author%3Aarthw%20OR%20author%3AJohannesGaessler%20OR%20author%3AORippler%20OR%20author%3Aruixiang63%20OR%20author%3Axctan%20OR%20author%3Aallozaur%20OR%20author%3Ayomaytk%20OR%20author%3Aaendk%20OR%20author%3Awine99%20OR%20author%3Agaugarg-nv%20OR%20author%3Ataronaeo%20OR%20author%3Aforforever73%20OR%20author%3Alhez%20OR%20author%3Anetrunnereve%20OR%20author%3Afairydreaming)%20sort%3Aupdated-desc） / dev stats（https://github.com/ggml-org/llama.cpp-dev） / lib llama API（https://github.com/ggml-org/llama.cpp/issues/9289） / llama-server REST API（https://github.com/ggml-org/llama.cpp/issues/9291）

快速开始

几种将 llama.cpp 安装到你机器上的方式：

• 访问 https://llama.app 并按照说明操作
• 使用 Docker 运行——参见我们的 Docker 文档
• 从 releases 页面（https://github.com/ggml-org/llama.cpp/releases）下载预构建的二进制文件
• 克隆本仓库从源码构建——参见我们的构建指南

安装完成后：

# 直接从 Hugging Face 下载并运行模型
llama cli -hf ggml-org/Qwen3.5-0.8B-GGUF

# 启动 OpenAI 兼容的 API 服务器
llama serve -hf ggml-org/Qwen3.5-0.8B-GGUF

使用 llama cli 进行 VLM 会话

针对 llama serve 的内置 Web UI

描述

llama.cpp 的主要目标是在广泛的硬件上——包括本地和云端——以最少的配置和最先进的性能实现 LLM（以及 VLM）推理。

• 不依赖任何第三方库的纯 C/C++ 实现
• Apple Silicon 是一等公民
• 通过 ARM NEON、Accelerate 和 Metal 框架进行优化
• 支持 x86 架构的 AVX、AVX2、AVX512 和 AMX
• 支持 RISC-V 架构的 RVV、ZVFH、ZFH、ZICBOP 和 ZIHINTPAUSE
• 支持 1.5 位、2 位、3 位、4 位、5 位、6 位和 8 位整数量化，以实现更快的推理和更低的内存占用
• 为 NVIDIA GPU 运行 LLM 的自定义 CUDA kernel（通过 HIP 支持 AMD GPU，通过 MUSA 支持 Moore Threads GPU）
• Vulkan 和 SYCL 后端支持
• CPU+GPU 混合推理，可部分加速超出总显存容量的模型

llama.cpp 项目构建在 ggml（https://github.com/ggml-org/ggml）库之上。

支持的后端

文档

工具

• cli
• completion
• server
• GBNF 语法

开发

• 如何构建
• 在 Docker 上运行
• 在 Android 上构建
• 多 GPU 使用
• 性能问题排查
• GGML 技巧与窍门（https://github.com/ggml-org/llama.cpp/wiki/GGML-Tips-&-Tricks）
• XCFramework
• 补全
• 模型
• 发布流程

贡献

• 贡献者可以提交 PR
• 协作者将根据贡献情况受邀加入
• 维护者可以向 llama.cpp 仓库的分支推送并将 PR 合并到 master 分支
• 非常欢迎协助管理 issue、PR 和项目！
• 阅读 CONTRIBUTING.md 了解更多信息

致谢

• yhirose/cpp-httplib（https://github.com/yhirose/cpp-httplib）
  • 单头文件 HTTP 服务器，llama-server 使用
  • MIT 许可证
• nothings/stb（https://github.com/nothings/stb）
  • 单头文件图像格式解码器，多模态子系统使用
  • 公共领域
• nlohmann/json（https://github.com/nlohmann/json）
  • 单头文件 JSON 库，各种工具/示例使用
  • MIT 许可证
• mackron/miniaudio（https://github.com/mackron/miniaudio）
  • 单头文件音频格式解码器，多模态子系统使用
  • 公共领域
• sheredom/subprocess.h（https://github.com/sheredom/subprocess.h）
  • 用于 C 和 C++ 的单头文件进程启动方案
  • 公共领域