六引擎横评作者自家模型小30%，质量分几乎全满分

有人拿 Qwen3.8-27B 对比了六个本地推理引擎。测的不只是速度，还有输出质量、长上下文表现，以及 GGUF 和 NInfer 两种模型配置。

速度拆得比较细：首 token 延迟、prefill 吞吐、decode 吞吐、并发请求下的表现，以及跨任务的端到端延迟。质量那侧用自动检查打分，看的是这些性能优化有没有把模型弄坏。

上下文一长，排名就换人

64K、128K、256K 三档都跑了。上下文越长，引擎之间的差距越大。有些在短提示下表现不错的配置，到 128K–256K 就不太有竞争力。

一位评论者的用法可以对照：他自己的会话里超过 30% 用了 128K 以上上下文，约 15% 压缩过两次以上，256K 对他是刚需。按这个比例，短提示下的领先很难代表日常体验。

端到端延迟覆盖编码、推理和 agent 式任务。作者的判断是，把任务做完往往比拿到最高峰值 tokens/sec 更重要。decode 吞吐、首 token 延迟、端到端延迟三项给出的排名可能相差很大。只盯一个数字选引擎，容易选到不适合自己那类工作的那个。

写基准的人，也是参评引擎的作者

基准的作者就是 TensorSharp 的开发者。这个引擎本身也在参评的六个里。他写明，目标是给本地 LLM 社区提供有用数据，不是宣布某个引擎全面获胜。他还提醒，这些比较反映的是完整的引擎加模型配置，模型格式本身没有被单独测量。

讨论里被顶得最高的一条指向体积：TensorSharp 用的量化版本比其他引擎小约 30%，15GB 对约 21GB。这条信息在原帖里出现得靠后。量化大小不一样，速度对比的前提就不一样。

另一条高票评论说，质量对比里几乎所有分数都是 100%，这样的对比区分不出质量差异。也有人追问测试是不是用了 greedy、thinking off 这类设置。

缺的参数，别人补不上

有人直接问每个引擎的运行参数和可复现的技术细节在哪。缺了这些，别人没法把结论搬到自己机器上。还有人指出，openjet megakernel 和 strata 这两个引擎根本没出现在对比里。

另一位评论者用发布节奏和贡献者规模衡量可持续性。vllm 有 100 个版本、9k 贡献者，sglang 是 64 个版本、2k 贡献者。TensorSharp 只有 6 个版本、11 个贡献者。同类工具都在关键路径上，维护人力是选型时要算的实际成本。

还有人把质量放在速度前面：跑得很快但很笨的模型没多少意思。

一类测不到的失败

有人建议补一个场景：让 prices.json 返回权限错误。agent 该说算不出总价，而不是自己编一个价格。吞吐和延迟基准看不到这类失败。

评论区里还有人对 TensorSharp 支持图像、视频生成感到意外。

作者同时是写基准的人和参评引擎的作者，这件事本身不算问题。但两件事叠在一起值得留意：量化版本小了约 30%，质量对比又几乎全是满分。后者等于没有检验速度优势是不是靠降低精度换来的。

量化拉到同一水平之后，速度排名会变成什么样，现在还没有这组数据。