最近跑 Qwen3.8-27B，总觉得 5060 Ti 上的 NInfer 比 7900 XTX 上的 llama.cpp 更利索，尤其是一次塞入很长的上下文时。另一边，长对话又经常卡在输入阶段，最后报 300 秒超时。

于是拿同一份输入，把三套能在手头机器上运行的方案测了一遍，从 512 token 逐渐加到 32K、64K，再往 128K、160K、192K 走。

结果比较明确：这套 5060 Ti NInfer 在已测的 32K～160K 各档，冷输入都比 XTX Vulkan 快；160K 的等待从 506.2 秒缩短到 306.5 秒，减少约 39.4%。 不过短输入的生成速度，XTX Vulkan 仍然更高。AMD 的 NInfer 社区移植版在长输入下掉速很明显，64K 冷输入已经要 638.6 秒，后面就停了。

测试日期：2026-10-21。

测的三套配置

这里有个需要提前说明的差别：AMD 的社区移植版源自较旧的 NInfer v0.6.1，和 NVIDIA 上的 v1.5 不是同一版本。 三套权重和 KV 格式也不同，回答质量没有做对齐测试。因此这些结果比较的是手头实际能用的推理方案，不能把所有差距都算到显卡芯片头上，也不能据此认定同等回答质量下谁更快。

5060 Ti 测试时功耗上限为 180W，负载时 PCIe 链路为 3.0 ×4，使用 host embedding。三组测速统一使用 MTP-3。

怎么测的

三组喂入完全相同的整数 token ID，避免同样字数经过不同模板后变成不同 token 数。使用同一份 workflow 语料；超过原始 118001 token 的部分，将完整原序列重复后截取。这适合观察性能和容量，不用于证明长文本理解能力。

全部是单槽、单请求、greedy，关闭跨请求的前缀复用。这里的“冷输入”是指模型已加载，但这次输入没有命中前缀缓存，不包含模型从硬盘加载的时间。

基础档每档两轮，取算术均值。128K 起，NVIDIA 每档两轮，Vulkan 为节省长测时间每档一轮。基础的 512、32K、64K 档在输入处理后继续生成 512 token；118001 及以上继续生成 2048 token。首个输出统一计入输入处理阶段。

基础档统一总容量为 131072。128K 起按“输入 + 2049 个输出 token”向上取整到 4096 的倍数，作为当档总容量；同一档两套后端使用相同容量。文中的 1K = 1024 token；118001 单独列原始数值，约为 115.2K。

下表的冷输入时间是引擎 prefill 耗时。llama.cpp 另测了 HTTP 首字延迟，NInfer 用的是 bench 内部计时，所以不把两者说成完全相同口径的网络首字时间。

冷输入处理耗时

单位：秒，越低越好。

32K 时，5060 Ti NInfer 比 XTX Vulkan 少等约 26%；64K 少等约 32%；118001 token 时少等约 37%；160K 时少等约 39%。长输入下的差距，和我实际使用时的感觉基本一致。

AMD NInfer 的 64K 两轮分别是 632.4 秒、644.8 秒，平均 638.6 秒，已经超过十分钟。对我的交互用途来说，这个等待时间不合适，118001 及后面的档位就取消了。表里的“停止测试”不代表显存不足。

输入处理后的生成速度

单位：token/s，越高越好。

512 token 短输入时，XTX Vulkan 约 67.5 token/s，5060 Ti NInfer 约 56.0 token/s，XTX 更快。到 64K 及以上的已测共同档位，5060 Ti NInfer 的生成速度开始占优，160K 时约为 41.2 对 35.0 token/s。

所以只看短输入的生成 token/s，很容易忽略长上下文真正让人难受的那段等待：模型要先把整段输入处理完，才能开始正常输出。

192K 和 300 秒超时

5060 Ti NInfer 成功完成了 160K；192K 在运行时显存预留阶段失败，所需预留比可用空间多约 462 MiB。160K 是本次最大已验证档位，精确边界没有继续细分，不能把它当成所有配置下的硬上限。

XTX Vulkan 完整跑通了 192K，但冷输入用了 684.5 秒，约 11.4 分钟。后续扫描按冷输入达到 600 秒就不再加长的规则收口，这轮完成后便停止了，224K 没测。这里碰到的是我设定的实用性截止，并没有测到它的显存极限。

这也解释了之前调用端的 300 秒超时：XTX Vulkan 在 118001 token 时，两轮 HTTP 首字延迟已经达到 298.83 秒、299.23 秒。稍微增加输入、排队或其他开销，就可能超过 300 秒。5060 Ti 虽然更快，160K 冷输入也用了约 306.5 秒，同样跨过了这个等待上限。

我现在怎么用

XTX 上继续用 Vulkan，服务配置改为总容量 256K、双槽各 128K。每槽预留 8K 输出后，输入上限大约是 120K。这个数字表示装得下多少，不表示塞满后还能很快返回。

按这次冷输入成绩，XTX 的 64K 大约要两分钟，118001 token 接近五分钟。如果希望交互时少等一些，我会优先把冷输入控制在 64K 左右；日常对话如果命中前缀缓存，后续等待可能明显缩短，本次没有把缓存收益算进去。

双槽方便同时跑两个会话，不会自动加速同一条长请求；两会话同时繁忙时的速度，本次没有测。至于再加一张 7900 XTX 能提升多少，这轮也没有双卡实测，暂时不给翻倍之类的估计。

对我当前的用途，5060 Ti 上这套 NInfer 更适合长输入；XTX Vulkan 则保留了较好的短输入生成速度和更大的已验证输入容量。AMD 的这个旧版 NInfer 移植分支，现阶段我先不拿来跑长上下文。

复现信息和测试范围

• llama.cpp：a8d9a7e1e55f5b613f297504d9e159807ec3a99b。
• NVIDIA NInfer：toddballinger/ninfer-5080，commit e4edd6d5c5f9f7996de0f3d9f6c311e883452580。
• AMD NInfer：Jerry-Lee661/NInfer-AMD-ROCm，commit bab0b0d3fa1034b63cc2171eb1cb0310315663ec，gfx1100，HIP 7.15 / clang 23。
• AMD 编译时补了测速目标需要的 profiler 兼容头和 HIP 链接设置；两种 NInfer 加了计时区间外的逐轮结果保存，计算内核均未修改。
• 原始语料 SHA256：5b08da2c7b7ea5cafad2fab5699dccbcbce86040d8a37219b8c21f094d1d1eb7。
• 每档仅一到两轮；基础测试期间后台有受限 CPU 编译和模型下载，没有同一 GPU 的并行推理。结果用于本机方案选择，保留一定主机侧波动。
• 未测回答质量、双会话吞吐、双卡扩展，也未推断其他 ROCm 后端的表现。附件 CSV 为本次完成的 29 轮测量；图中连线用于阅读，不代表中间所有长度均已测试。