跳到主内容
@wquguru
精选88r/LLMDevs(Reddit)技巧与观点

TensorSharp作者实测6大LLM推理引擎速度与质量对比

We benchmarked 6 LLM inference engines on speed AND quality — including 64K–256K contexts, concurrency, and GGUF vs NInfer

原文
发到 X
推荐理由

做推理部署的同学必看,这篇把速度和质量放在一起测,还覆盖了256K长上下文和并发场景,比只看tokens/sec的跑分更有实战参考价值。

Most LLM inference benchmarks focus on tokens/sec, TTFT, or throughput.

大多数大语言模型推理基准测试关注的是每秒令牌数(tokens/sec)、首 token 延迟(TTFT)或吞吐量。

But faster inference doesn't necessarily mean better inference, especially when quantization, speculative decoding, long contexts, and concurrency enter the picture.

但更快的推理速度并不一定意味着更好的推理效果,尤其是在引入量化、推测解码、长上下文和并发场景时。

So we ran a comprehensive benchmark of Qwen3.8-27B across six inference configurations, measuring not just speed, but also output quality.

因此,我们对 Qwen3.8-27B 在六种推理配置下进行了全面的基准测试,不仅测量速度,还评估输出质量。

Full disclosure: I'm the author of TensorSharp, one of the engines being benchmarked.

完全披露:我是 TensorSharp 的作者,而 TensorSharp 是被测试的引擎之一。

What makes this benchmark different?

这项基准测试有何不同?

1. Speed AND quality, measured together

1. 速度与质量同时测量

We compared:

我们比较了:

  • Time to First Token (TTFT)
  • Prefill throughput (tokens/sec)
  • Decode throughput (tokens/sec)
  • End-to-end task latency
  • Concurrent request performance
  • Answer quality against automated checks
  • 首 token 延迟(TTFT)
  • 预填充吞吐量(每秒令牌数)
  • 解码吞吐量(每秒令牌数)
  • 端到端任务延迟
  • 并发请求性能
  • 针对自动化检查的答案质量

A fast engine isn't particularly useful if its optimizations introduce incorrect outputs.

如果一个引擎的优化引入了错误的输出,那么它再快也没有太大用处。

That's why we included quality validation alongside performance measurements, rather than assuming that every engine produces equivalent results.

这就是为什么我们在性能测量的同时加入了质量验证,而不是假设每个引擎都能产生等效的结果。

2. Ultra-long contexts: 64K, 128K, and 256K tokens

2. 超长上下文:64K、128K 和 256K 令牌

Many benchmarks use relatively short prompts, but real-world agentic workloads can be very different.

许多基准测试使用相对较短的提示词,但现实世界中的智能体工作负载可能截然不同。

Think about coding agents processing entire repositories, RAG pipelines handling large documents, or multi-agent systems maintaining extensive histories.

想象一下代码智能体处理整个代码库、RAG 管道处理大型文档,或多智能体系统维护大量历史记录的场景。

We tested long-context inference at 64K, 128K, and 256K, including concurrent workloads.

我们在 64K、128K 和 256K 的上下文长度下测试了长上下文推理,包括并发工作负载。

At these context lengths, KV-cache management, memory pressure, prefill efficiency, and scheduling become critical.

在这些上下文长度下,KV 缓存管理、内存压力、预填充效率和调度变得至关重要。

An engine that wins at 4K or 8K doesn't necessarily win at 256K.

在 4K 或 8K 上下文中表现优异的引擎,不一定能在 256K 上下文中胜出。

3. GGUF vs NInfer model formats

3. GGUF 与 NInfer 模型格式对比

Another interesting aspect is comparing inference configurations using GGUF and NInfer model representations.

另一个有趣的方面是比较使用 GGUF 和 NInfer 模型表示的推理配置。

The goal isn't just to compare engines, but also to understand how model format, quantization, and inference optimizations affect performance and quality.

目标不仅仅是比较引擎,还要理解模型格式、量化和推理优化如何影响性能和质量。

This matters because developers often choose a model format based on compatibility or memory requirements without fully understanding its performance implications.

这很重要,因为开发者通常基于兼容性或内存需求选择模型格式,而未能充分理解其性能影响。

4. Real-world task latency, not just synthetic throughput

4. 真实任务延迟,而非仅合成吞吐量

We also measured end-to-end latency across different task scenarios, including coding, reasoning, and agent-oriented workloads.

我们还测量了不同任务场景下的端到端延迟,包括编码、推理和面向代理的工作负载。

For production applications, the fastest tokens/sec number doesn't always translate into the fastest completed task.

对于生产应用而言,每秒最快 token 数并不总是意味着完成任务的速度最快。

Why this matters

为什么这很重要

I think inference benchmarks should answer three questions together:

我认为推理基准测试应共同回答三个问题:

  • How fast is it?
  • Does it still produce correct answers?
  • Does it remain practical at long context lengths and under concurrency?
  • 它有多快?
  • 它是否仍能产生正确的答案?
  • 在长上下文长度和高并发情况下,它是否仍具实用性?

Optimizing only one of these can be misleading.

仅优化其中一项可能会产生误导。

The attached poster includes the engine rankings, speed/quality comparisons, 64K–256K context results, task-level latency, and test configurations.

附带的海报包含了引擎排名、速度/质量对比、64K–256K 上下文结果、任务级延迟以及测试配置。

I'd love feedback from other LLM developers

我很期待其他 LLM 开发者的反馈

  • Do you consider quality validation mandatory when comparing inference engines?
  • How important is 128K–256K context support for your production workloads?
  • Have you observed meaningful differences between GGUF and other model formats?
  • Which matters more in your applications: TTFT, decode speed, concurrent throughput, or end-to-end agent latency?
  • 在比较推理引擎时,你认为质量验证是必须的吗?
  • 128K–256K 上下文支持对你的生产工作负载有多重要?
  • 你是否观察到 GGUF 与其他模型格式之间存在显著差异?
  • 在你的应用中,以下哪项更重要:首 token 延迟(TTFT)、解码速度、并发吞吐量,还是端到端代理延迟?

I'm particularly interested in what additional tests would make benchmarks like this more useful and reproducible for the community.

我特别感兴趣的是,哪些额外的测试能让这类基准测试对社区更有用且更具可复现性。

Project: https://github.com/zhongkaifu/TensorSharp

项目:https://github.com/zhongkaifu/TensorSharp

Benchmark details and results are in the attached poster.

基准测试详情和结果见附带海报。

更进一步:量化金融体系

看懂新闻只是起点——沿量化金融路径,把它变成能交付的工程能力

进入量化体系 →

相似阅读

关联信息,但可能不是同一事件