QEngine RTX 5090 基准测试报告 504 Tok/s，优势形如缓存

QEngine RTX 5090 基准测试显示，Qwen3.8-Flash-Next 达到每秒 504 个 token，但这一峰值附带的条件会改变竞争格局。一位 LocalLLaMA 用户在两张 RTX 5090 显卡上测试了 QEngine 1.3.1，并报告称其在单流解码方面显著领先，即单个对话的生成速度。同一对比显示，在代理提示词延迟测试中，QEngine 与 Strata 大致持平；而在处理更长的基准提示词时，Strata 更快。

测试者以 Relative-Ant-9249 的用户名发帖，将功劳归于开发者 bpx03，并明确表示 QEngine 是他人的项目。他们的本地推理基准测试在同一台工作站上比较了多个引擎。这使报告具有参考价值，不过它仍是一项由用户自行运行、未经独立复现的对比。

核心权衡已经很清楚：最快的输出流并不必然意味着整个对话中的等待时间最短。重复提示词有利于 QEngine 的自适应缓存；在报告的测试中，长输入有利于 Strata；保留空闲对话则会以另一种方式改变延迟。在这些引擎之间做选择的开发者，需要先识别究竟是哪一种等待真正打断了工作。

QEngine RTX 5090 基准测试实际测量了什么

504 tok/s 的结果属于特定工作负载、内存配置和软件版本。它既不是整项对比的平均值，也不能保证适用于每一次响应。

该工作站配备两张 RTX 5090 显卡，每张拥有 32 GB 显存，并搭载一颗 Threadripper PRO 3975WX 处理器。测试者报告称，系统拥有 251 GB 内存，配置上下文约为 262,000 个 token。Token 是模型处理和生成的文本单位，并不直接等同于词数。

QEngine 使用 Flash-Next 的 INT4 AutoRound 构建版本，即采用四位整数权重的压缩模型表示。测试者表示，他们将 CUDA 编译目标从架构 86 改为 120，使用 nvcc 13.3 和 g++-13。他们称未作其他源代码修改，从启动到开始提供请求服务间隔 53 秒。

这是一份令人鼓舞的可移植性报告，但成功编译并不能证明广泛的硬件支持。它证明的是该用户让这个构建版本在这台机器上运行起来，并不能证明其在不同主板、驱动程序、内存配置或操作环境中会有等效表现。

测试将叙述性输出和代码输出分开，这一区别贯穿结果。默认配置下，QEngine 据称以 370 tok/s 生成叙述文本，以 439 tok/s 生成代码。将其对话缓存移至系统内存后，这两个数值分别提升至 406 和 504 tok/s。

Strata 的 ISTA IQ3_S 配置据称在叙述性输出中达到 214 tok/s，在代码输出中达到 293 tok/s。其 UD-IQ4_XS 配置则为 180 和 239 tok/s。这些是不同的压缩模型构建版本，因此不能将这一对比视为对引擎实现的纯粹衡量。

经调优的 bucko vLLM 配置在叙述性输出中达到 135 tok/s，在代码输出中达到 141 tok/s。其随附配置测得 120 和 118 tok/s。测试者还列出了一项 Infernix 配置，速度为 14–18 tok/s，但没有给出相应的提示词处理测量结果。

这些数字表明，在这台工作站上存在显著的报告差异。它们也说明了标题的局限：504 tok/s 是列出的最高代码生成结果。同一引擎的叙述性输出结果更低，其默认内存配置也慢于 RAM 配置。

报告称，所有引擎都使用了相同的基准脚本和提示词。所链接的社区服务配置方案提供了测试生态背景，但链接到一个基准测试项目并不能独立验证提交的结果。

因此，最站得住脚的描述应当具体：QEngine 1.3.1 在该用户测试的配置中领先于单流生成，其最高报告速率出现在代码生成时。若要更广泛地宣称它是现有最快引擎，则需要更完整的参测范围和可重复的独立测试。

重复提示词让生成优势更难泛化

QEngine 报告的优势很有意义，但该基准测试同样奖励了常规流量未必能复现的行为。测试者直接指出了这一局限，因此它是解读结果的关键。

根据帖子，QEngine 的专家缓存会适应近期使用情况。专家缓存会保留模型中经常需要的部分，使引擎无需反复从其他位置获取它们。重复相同的提示词会为这一机制提供有利的工作负载。

这很重要，因为基准测试会在多次运行中重复其提示词。近期使用于是成为未来使用的有效预测因素，从而可以减少模型数据的移动。由此产生的生成速率描述的是有利的运行条件，而非每一种可能的对话。

测试者将此与 Strata 的缓存作对比，并称后者已保留了约 99.5% 的路由专家权重。在他们的说法中，重复提示词因此给 Strata 带来的额外收益更小。这一解释来自测试者，尚未在此得到独立证实。

帖子还提供了一项来自多样化流量的早期观察：单流速度约为 300–400 tok/s。测试者代理工作负载中的请求据称范围为 330–470 tok/s。这些数字依然很快，但它们使 504 tok/s 的标题更像是一种有利情形，而不是典型预期。

标题将其描述为相较于下一个最佳受测引擎约 1.5–1.9 倍的优势。正文在考虑工作负载差异后，采用了更宽泛的估计，即相较于 Strata 约 1.4–1.9 倍。这两个范围都不应成为套用于无关硬件或提示词的通用倍率。

这正是 QEngine 与 Strata 成为工作负载问题的地方。反复生成类似代码的开发者，可能受益于与在无关文档之间切换的人不同的缓存模式。来源并未说明任一模式需要持续多久，测得的优势才会改变。

一项有用的独立对比应保留这两种条件。重复提示词揭示了当近期活动能够预测未来需求时，引擎可以达到的表现。多样化提示词则揭示了它处理不那么配合的请求序列的能力。

在每一种评估中，任何一种条件都不应自动获得优先权。重复可以代表具有共享指令和重复任务的真实应用。多样性可以代表在编码、研究、文档审阅和陌生项目之间切换的个人助手。

实际问题出现在有利条件从标题中消失时。只看到 504 tok/s 的读者，可能会期待切换任务后立即获得这一速度。现有证据并不支持这种预期。

因此，QEngine RTX 5090 基准测试促使竞争引擎解释其在可比缓存条件下的行为。它也促使基准测试作者清楚披露这些条件。缺乏这种披露，性能排名可能会掩盖排名存在的原因。

对买家和开发者而言，相关问题是其实际工作在多大程度上类似于重复基准测试。答案决定了应赋予峰值多大权重。相比波动更大的高速度，略低但表现稳定的速率可能更适合某些工作流。

在回答开始前，Strata 仍具竞争力

QEngine 的生成优势并未转化为整个请求流程中的明确领先。随着输入变长，报告的提示词处理结果让 Strata 处于更有利的位置。

Prefill 指模型开始生成响应之前对输入进行处理。在约 10,000 个输入 token 时，QEngine 的默认配置据称处理速度约为 5,700 tok/s。其 RAM 缓存配置在该输入长度下达到约 6,200 tok/s。

Strata 的 ISTA IQ3_S 配置据称在较短输入长度下处理速度约为 5,100 tok/s。不过，在约 90,000 个 token 时，它达到约 10,000 tok/s。QEngine 的默认配置在该较长输入下测得约 7,300 tok/s。

帖子没有给出 QEngine RAM 配置在 90,000 个 token 下的对应 prefill 数据。这一缺失结果应保持缺失，而不应根据其较短输入表现加以推断。现有测量支持一种分化结果：QEngine 在较短提示词上领先，Strata 在较长提示词上领先。

这一区别可直接应用于编码助手。基于近期小段交流工作的助手，与审阅大型代码仓库上下文的助手，在阅读上花费的时间占比不同。更快的生成对两者都有帮助，但不能消除处理输入所需的时间。

代理测试增加了另一项重要边界。它涵盖一个 12 轮工具使用序列，上下文增长至约 35,000 个 token。在前缀缓存正常工作的情况下，QEngine 1.3.1 据称在 1.75 秒内读取了最后一轮的提示词。

前缀缓存指复用提示词中未变化开头部分的计算。Strata 的对应结果为 1.7–1.9 秒，使 QEngine 落在这一报告范围内。测试者恰当地将两款引擎描述为在该测量中持平。

在同一项报告对比中，经调优的 bucko 配置耗时 4.36 秒。这表明这些受测配置之间存在差异，但并不能证明每一种 vLLM 部署都会得出这一结果。配置、模型表示和工作负载仍是对比的一部分。

还应注意，报告的数字衡量的是提示词读取阶段。它并不衡量执行工具、检查结果、生成后续指令并完成任务所需的总时间。快速的一个阶段可以改善代理表现，却不能决定代理的整体完成时间。

因此，QEngine 与 Strata 在已披露测量中没有唯一胜者。QEngine 在生成方面领先，而 Strata 在缓存代理提示词上仍具竞争力，并在报告的长输入 prefill 测试中更强。这比将一切压缩为每秒输出 token 更有价值。

对于维护本地助手的团队而言，压力是运营层面的。他们需要确定用户主要等待的是输入处理、回答生成还是外部工具。引擎更换只能改善该引擎实际控制的等待部分。

这一结果也挑战了本地推理演示的呈现方式。快速涌现的代码流很容易展示，也很容易理解。而在代码流开始前较为安静的延迟，在重复工具交互中可能同样重要。

将空闲对话保留在 RAM 中改变的是另一种等待

最实用的结果或许是恢复旧对话，而非最高生成速率。QEngine 的 RAM 配置据称能够在中间流量之后保留有用状态。

KV 缓存存储与注意力相关的键和值，使模型能够复用早先 token 的计算结果。在这项测试中，QEngine 可将该缓存保留在固定系统 RAM 中，即为可预测传输预留的主机内存。测试者称，一个 13.5 GB 的池可提供约 100 万 token 的聚合缓存容量。

该池大小不同于单个对话配置的上下文上限。聚合容量描述的是该池可跨会话保留多少对话状态，并不意味着基准测试了一个包含 100 万 token 的单一对话。

闲置会话实验以八个约 58,000 token 的对话开始。随后，测试者发送了约 400,000 token 的其他流量，再回到原来的对话。这一序列考察机器处理其他任务后，先前的工作是否仍保持就绪。

当缓存位于 RAM 中时，据称八个对话均以热状态恢复，意味着其保留状态仍可复用。它们首次回复时间介于 1.56 至 2.01 秒。这衡量的是用户重新打开工作时遇到的延迟，而非输出流最终的生成速度。

当缓存位于显存中时，据称仅有两个对话保持热状态。其余六个需要再次处理输入，耗时 8.7–9.4 秒。测试者报告的冷启动参考值为 8.85 秒，因此实际影响一目了然。

在持续进行的项目之间切换的开发者会熟悉这种模式。一个对话保存调试调查，另一个包含实现审查，还有一个跟踪独立功能。相关优势在于：当注意力转向其他事项时，已处理的工作仍被保留。

同样的区别也适用于可搜索知识库。找到正确资料与恢复模型此前的计算是两个不同问题，尽管两者都会影响人们多快能重新投入有效工作。

消息来源称，当显存配置不得不再次处理旧输入时，答案仍然正确。其观察到的代价是延迟，而非有记录的答案正确性损失。这一区别避免将每一次缓存未命中都视为推理失败。

还存在并发权衡，其中并发是指同时服务多个流。对于八个并发流、每个 64,000-token 上下文，RAM 配置据称每流达到 124 tok/s。显存配置则达到每流 139 tok/s。

测试者将其概括为：尽管单流表现提升约 10%，但在这一并发工作负载下速度约慢 10%。他们还披露每种模式只启动一次、只运行一轮。这足以发现一个值得研究的权衡，但不足以确立其完整分布。

更广泛的技术问题不限于该引擎。混合缓存文档描述了 Flash-Next 专用处理方式，并将其声明的验证范围限定为文本生成。模型支持、状态保留和工作负载覆盖范围需要明确关注，而不能仅根据产品名称作出假设。

对于个人助手而言，保留闲置工作可能比降低并发输出速度更重要。对于共享服务，平衡则可能相反。报告结果使两种可能性都值得评估，但并未确立任何一种为默认选择。

质量检查和竞争引擎限制了“胜利”结论

该报告支持进一步测试 QEngine，而不是宣称它能产生更好的答案或胜过所有替代方案。其自身的质量检查和讨论帖明确了这些限制。

据称，助手测试在 QEngine 1.3.1 上完成了 44 项任务中的 44 项。早期的 1.3 运行在低推理强度下完成了 44 项中的 42 项。测试者谨慎看待这一微小差异，而未将其表述为已确立的质量提升。

编码对比需要更谨慎地归属版本。一项候选发布版本在测试者的编码集上完成了 30 项任务中的 26 项。Strata 配置分别完成 24 项和 25 项，而其中一个配置的重复结果介于 24 至 26 项。

测试者明确表示，编码检查尚未在 1.3.1 上重新运行。因此，它不能作为标题所依据确切版本的直接质量认证。它提供的是早期构建的背景，以及对比中观察到的波动性。

合理的结论是：这些有限检查未发现 QEngine 压缩模型存在明显的编码劣势。但这并不能证明其在所有任务上质量相当，也不能证明生成速度提升保留了生产应用所需的每一种行为。

量化，即对数值模型权重进行压缩，进一步增加了引擎比较的复杂性。不同的压缩构建可能同时改变性能和输出。比较完整部署配置的基准测试回答了一个实际问题，但无法隔离每一个促成因素。

竞争范围同样并不完整。在讨论中，Basalt 的开发者建议测试一款专为 NVIDIA Blackwell 硬件设计的引擎。该开发者报告的性能来自另一台机器和另一项基准测试，因此这些数据不能纳入原始排名。

不过，在理解“最快引擎”这一说法时，Blackwell 推理支持的存在仍然重要。QEngine 在发帖者测量的配置中领先。未经测试的替代方案仍是未经测试，无论其开发者是否在其他地方报告了有前景的数据。

来源讨论帖还包含热情的用户反馈和配置协助请求。这些回应表明了兴趣，但无论热情还是个案经历，都无法独立复现该基准。第二台工作站需要经过记录的测试，其所有者的体验才能支持同样的性能主张。

版本漂移带来了另一项验证问题。在核查时，QEngine 源代码仓库描述的是 1.3.2 版本及额外的 Flash-Next 功能。这些当前描述不应被追溯性地附加到已测试的 1.3.1 构建上。

该仓库称该项目为 source-available，并记录其重点面向 RTX 3090 硬件。其构建说明仍指定架构 86，并将其他 GPU 型号描述为未经测试。这使发帖者在 5090 上的编译成为单个结果的有用证据，而非普遍兼容性承诺。

因此，独立复现应保留实际的软件修订版、模型文件、编译器选择和启动配置。将所有内容更新到最新版本或许会产生有趣结果，但那回答的是另一个问题。可复现性取决于保留实际被测量的内容。

QEngine 当前面临的压力，是将一份有前景的用户报告转化为可靠的运行模式。竞争者面临的压力，是以可比的工作负载和透明配置作出回应。无关硬件上发布一个更大的数字，并不能完成其中任何一项任务。

三项结果将使下一次比较更有价值

下一项有价值的证据，应是跨工作负载、可复现性更高的比较，而非又一个孤立峰值。三个具体信号将增强或削弱对本报告的解读。

首先，关注另一台双卡 RTX 5090 工作站上的独立复现。有价值的结果应明确 QEngine 的确切修订版和模型构建，然后同时报告重复提示和多样化提示。若能在两种条件下复现显著的生成领先优势，将增强该优势能够超越原始机器的论据。

若在多样化提示上的优势较小，则会缩小这一论据，但不会使原始测量失去意义。这会显示近期工作负载历史在观察结果中占据更大作用。这些信息将帮助用户根据自己的流量选择引擎。

独立测试还应保留叙述性输出与代码输出之间的区别。将二者合并为一个平均值，会掩盖原始报告已揭示的差异。分别报告结果，能让读者更有机会将基准与其应用相匹配。

其次，关注在同一台机器上纳入 Basalt 等面向 Blackwell 的替代方案的比较。原始发帖者的结果并未确立该引擎在排名中的位置。在相同条件下测试它，将弥补讨论中提出的具体缺口。

可信的比较应披露压缩模型构建和质量设置上的差异。它还应在生成速度之外，包含提示处理延迟和恢复会话行为。否则，新的赢家将继承旧标题同样的模糊性。

如果 QEngine 在这一扩展竞争范围中保持领先，其竞争性主张将更有说服力。如果另一引擎在生成速度相当的同时改善长输入或恢复会话延迟，选择将更取决于应用行为。无论哪种结果，都比比较不兼容的截图更有信息价值。

第三，关注针对闲置会话保留和并发生成的重复混合工作负载测试。报告中的 RAM 结果颇具吸引力，因为它解决了工作会话之间的中断问题。其并发速度下降也说明，这项优势需要在持续使用下进行评估。

重复运行将揭示，随着对话累积和活动变化，热会话恢复是否仍保持一致。它们还将显示引擎重新处理旧输入、遇到故障或降低每流速度的频率。这些测量将检验该内存配置背后的实际价值。

若能保持一致恢复并具备可接受的并发表现，将强化支持由 RAM 支撑对话状态的论据。频繁波动或更大的速度下降，则会将其吸引力限制在较轻的工作负载上。无论哪种结果，都不需要假装每个本地助手服务的请求模式相同。

对于考虑变更的开发者而言，QEngine RTX 5090 基准提供了一个可信的调查理由，同时也给出了异常明确的限制。其最强贡献在于表明：生成速度、提示延迟和对话恢复可能朝不同方向变化。

在替换现有引擎之前，请比较用户实际经历的等待。保留一段有代表性的长对话，引入无关流量，并测量原始工作恢复时发生的情况。除了重复提示，也应纳入多样化任务，并保留反映所需完成工作的质量检查。记录测试版本和配置，以免后续更新抹去比较的意义。QEngine RTX 5090 基准为这类评估提出了有说服力的理由，同时最终选择仍取决于来自你自身工作负载的证据。你的助手花费更多时间是在生成答案、读取不断增长的提示，还是恢复它本应记住的对话？