@Oluwaphilemon1：在单张 24GB 显存的 RTX 3090 上，Qwen3.8-27B 从 82 tokens/sec 提升到 381 tokens/sec。同一张显卡，同一个模型，推理速度提升近 4.6 倍

X AI KOLs Timeline 工具
inference-optimization speculative-decoding local-llm qwen rtx3090 prefix-caching

摘要

一位开发者通过 MTP、DFlash2 投机解码、上下文查找和前缀缓存，在单张 RTX 3090 上将 Qwen3.8-27B 的吞吐量从 82 提升到 381 tokens/sec，无需升级硬件。日常聊天场景的性能约为 133 tokens/sec，说明峰值数据主要来自高度可复用的工作负载。

Qwen3.8-27B 在单张 24GB 显存的 RTX 3090 上，从 82 tokens/sec 提升到了 381 tokens/sec。 同一张显卡。同一个模型。仅通过推理优化，报告的生成速度就提升了近 4.6 倍。 无需升级 GPU。 以下是各阶段的数据变化： • 基线：82 tokens/sec • 优化 MTP：114 tokens/sec • DFlash2 + 上下文查找：138 tokens/sec • 优化的查找验证：381 tokens/sec 有意思的是，推理栈的改变如何影响了模型生成 token 的方式。 1. DFlash2 减少顺序生成 通常，自回归模型会逐个生成 token。投机解码改变了这一过程，它允许一个更快的草稿机制提议多个 token，再由主模型进行验证。 当足够多的提议 token 被接受时，系统就能用更少的顺序生成轮次产出更多输出。 2. 上下文查找复用已存在的文本 有些工作负载涉及复现、转换或续写输入中已经存在的文本。 上下文查找不会独立生成每个 token，而是识别匹配的文本序列并提议它们供验证。 在该开发者的测试中，每次检查最多 16 个 token 的块，每个块大约接受 15 个。 如此高的接受率解释了为什么该技术在文本密集型任务上表现如此出色。 在一项 25K token 的文档复现测试中，报告的吞吐量从 260 提升到约 382 tokens/sec。 这里有一个重要区别：这类工作负载比普通的开放式对话提供了更多的复用机会。 3. 前缀缓存缩短生成前的等待时间 反复发送相同的文档或指令，会迫使推理引擎处理大量重复的上下文。 前缀缓存会存储这段共享前缀中可复用的计算结果，使后续请求能够跳过已经完成的工作。 报告的首 token 延迟从 22.4 秒降到了仅 0.56 秒。 这意味着在第一个 token 出现之前，速度提升了约 40 倍。 对于编程助手和基于文档的工作流来说，这可以让多轮交互的响应速度明显改善。 但不要把峰值吞吐量与日常聊天速度混为一谈。 381 tokens/sec 这个数字来自一个高度受益于上下文复用和优化验证的工作负载。 该开发者报告的日常聊天速度约为 133 tokens/sec，这对开放式对话来说是更具参考价值的数据。 两个数字都有意义，但衡量的是不同的工作负载。 更广泛的启示是，本地推理性能不仅仅取决于 GPU 规格。投机解码、上下文查找、验证策略和前缀缓存都能改变现有硬件生成输出的效率。 一张 RTX 3090 仍然只是一张 24GB 的显卡。改变的是推理栈能从中榨取出多少有效算力。 代码：GitHub 上的 syv-ai/qwen38-27b-rtx3090。 对于所有运行本地模型的人来说，这是一个有力的提醒：在假设性能提升需要更昂贵的 GPU 之前，先优化推理管线。 https://x.com/TeksEdge/status/2090595990114037832/video/1…
查看原文
查看缓存全文

缓存时间: 2026/10/15 12:10

Qwen3.8-27B 在单张 RTX 3090（24GB 显存）上，从 82 tokens/sec 提升到了 381 tokens/sec。

同一张 GPU，同一个模型，通过推理优化，生成速度提升了近 4.6 倍。

不需要升级硬件。

以下是各阶段的数据变化：

  • 基线：82 tokens/sec
  • 优化 MTP：114 tokens/sec
  • DFlash2 + 上下文查找：138 tokens/sec
  • 优化查找验证：381 tokens/sec

最有趣的部分在于，推理栈如何改变了模型生成 token 的方式。

1. DFlash2 减少了串行生成

通常情况下，自回归模型是一个接一个地生成 token。投机解码（speculative decoding）改变了这一过程——它允许一个更快的草稿机制提出多个候选 token，再由主模型进行验证。

当足够多的候选 token 被接受时，系统就能用更少的串行生成步骤产出更多输出。

2. 上下文查找复用已有文本

某些工作负载涉及对输入中已存在文本的复现、转换或续写。

上下文查找不再独立生成每个 token，而是识别匹配的文本序列并提出以供验证。

在开发者的测试中，每次检查最多 16 个 token 的块，每块约有 15 个被接受。

如此高的接受率，正是该技术在文本密集型任务上表现出色的原因。

在一份 25K token 的文档复现测试中，吞吐量从 260 tokens/sec 提升到了约 382 tokens/sec。

这里有一个重要区别：这类工作负载比普通的开放式对话有更多的复用机会。

3. 前缀缓存减少了生成前的等待时间

反复发送相同的文档或指令，会迫使推理引擎重复处理大量相同的上下文内容。

前缀缓存存储了共享前缀部分可复用的计算结果，使得后续请求可以跳过已完成的计算工作。

报告的首 token 延迟从 22.4 秒降至仅 0.56 秒。 即第一个 token 出现前的速度提升了约 40 倍。

对于编程 Agent 和基于文档的工作流来说，这能让多轮交互的响应感大幅提升。

但不要把峰值吞吐量与日常聊天速度混为一谈。

381 tokens/sec 的数据来自一个高度受益于上下文复用和优化验证的工作负载。

开发者报告的普通聊天速度约为 133 tokens/sec，这对开放式对话来说是一个更具参考意义的数值。

两个数字都有价值，但衡量的是不同的工作负载。

更广泛的启示是：本地推理性能不仅仅取决于 GPU 规格。投机解码、上下文查找、验证策略和前缀缓存都能改变现有硬件生成输出的效率。

单张 RTX 3090 依然是一张 24GB 的 GPU。变化的是推理栈从中榨取了多少有效工作量。

代码地址：GitHub 上的 syv-ai/qwen38-27b-rtx3090。

对于任何在本地运行模型的人来说，这都是一个有力的提醒：在假设更好性能需要更昂贵的 GPU 之前，先优化推理管线。

https://x.com/TeksEdge/status/2090595990114037832/video/1…

相似文章