Infermeld：在 AMD + NVIDIA 显卡上用 llama.cpp 运行同一 GGUF 的 Linux 工具包

继 club-5060ti 和 club-rdna16 之后，我整理了 Infermeld：一个小巧的开源 Linux 辅助工具包，用于在同一张 AMD 显卡和一张 NVIDIA 显卡上运行同一个 GGUF 模型，底层由 llama.cpp 驱动。我是这个项目的维护者。这是一个实验性的 v0.1.0 版本，我正在寻找拥有其他混合 GPU 组合的人，帮助复现这一配置并找出其中的问题。 思路很实际：如果你手头已经有两家厂商的显卡，是否可以不买一对同型号的卡，就让它们协同工作？ ### Infermeld 提供了什么 推理引擎是 llama.cpp。Infermeld 不是一个新的后端，我也没有声称发明了混合 GPU 推理。它只是封装了围绕这一配置的支持组件： - 明确的 AMD/Vulkan + NVIDIA/CUDA 设备选择和运行时预检。 - 可复现的构建说明和可查看的启动参数。 - 一个只读的热保护机制，关机操作仅限于它启动的服务器进程。 - 文档和结果站点，让配置、失败和限制都保持透明。 ### 当前的已测试配置 | 组件 | 已测试配置 | | --- | --- | | AMD GPU | RX 6900 XT，16GB | | NVIDIA GPU | RTX 3080，10GB | | 模型 | Qwen3.6-35B-A3B，UD-Q4_K_M GGUF | | 后端 | Vulkan + CUDA | | 分层模式 | Layer | | 上下文预留 | 8,192 tokens | 验收检查包括在 MTP 关闭和开启两种情况下的加载和短文本生成。这是针对一组硬件的窄范围结果，而非广泛的兼容性测试。8K 上下文预留并不等同于测试了一个填满 8K 的 prompt，一次简短的成功响应也不是持续的性能基准。 ### 重要限制 持续的 Q4 吞吐量和完整长上下文结果尚未通过验证。历史测量数据标注的是它们当时的原始配置，不应被解读为当前 Q4 配置的性能数据。 我们不承诺组合显卡一定比使用单卡更快。将宣传的显存容量相加，并不能保证全部显存都能被模型及其运行时分配所使用。 我宁愿把这些边界讲清楚，也不愿把一次成功的加载包装成一个完整的基准测试。 ### 寻找其他 AMD/NVIDIA 组合 成功的运行和失败同样有价值。如果你尝试了，请包含以下信息： - 两张 GPU 的型号及其显存大小。 - 操作系统、驱动版本和 llama.cpp 修订版本。 - 模型及量化方式。 - 启动设置，包括分层模式和上下文预留。 - 进展到哪一步：预检、加载、首次生成，还是更长时间的工作负载。 仓库中有一个硬件/结果问题表单。请对路径做脱敏处理，不要在报告中包含凭据和私有日志。 仓库及安装说明：https://github.com/5p00kyy/infermeld 结果与证据：https://5p00kyy.github.io/infermeld/ 是否有人已经在使用 AMD/NVIDIA 组合进行本地推理？我很想了解什么配置对你有效，以及这套方案在不同硬件上会在哪里失效。