RTX 2080 Ti 推理提速近50%：vLLM SM75 Turbo3 外部插件安装教程

摘要：RTX 2080 Ti 虽然已经不是最新显卡，但其 22GB 显存版本依然适合本地运行中大型多模态模型。针对这张卡所属的 Turing SM75 架构，本站开发了 caovan vLLM SM75 Turbo3 v0.1.3 外部插件：它不覆盖 vLLM 源码、不写死模型路径、不依赖 NVLink，用户仍使用自己的 vllm serve 命令，只需增加启用参数即可在匹配的 GatedDeltaNet（GDN）+ MTP 解码路径上尝试加速。目前，该插件已经在全新安装的官方稳定版 vLLM 0.21.0、Qwen3.6-27B-AWQ-INT4、2 × RTX 2080 Ti 22GB 环境中完成真实服务验证：保留 262144 上下文、FP8 KV Cache、FlashInfer、多模态 warmup 与 MTP=2 的情况下，请求成功返回，日志中也实际出现了 Turbo3 的两个专用 kernel。

Table of Contents

一、2026-05-29 重要兼容性更新

推荐基础环境：vLLM==0.21.0 官方稳定版。

已实测模型：Qwen3.6-27B-AWQ-INT4，2 × RTX 2080 Ti 22GB。

暂不推荐版本：0.21.1rc1.dev387+g5d126dd15 开发构建。该开发构建在未启用 Turbo3 的基础测试中，也曾出现 FP8 KV / FlashInfer 请求失败，因此不作为当前公开教程推荐环境。

这次验证非常重要：早期内核开发是在特定开发版 vLLM 与 AutoRound 模型实例中完成的，而公开发布必须面对普通用户“新建环境、安装正式版 vLLM、运行自己的模型”的场景。v0.1.3 已经完成这一步的首次真实验证。

二、这个插件解决什么问题？

本地部署大模型时，很多人的第一反应是换显卡、减小上下文或更换更激进的量化模型。但同样重要的一件事是：推理框架底层执行方式是否真正适合你的显卡架构。

RTX 2080 Ti 属于 Turing 架构，计算能力为 7.5，也就是常说的 SM75。很多新框架功能首先围绕更新的显卡架构优化，老旗舰显卡虽然仍能运行模型，但部分解码环节并不一定处于最佳性能状态。

caovan vLLM SM75 Turbo3 的目标是：不替换模型、不强制缩短上下文、不关闭多模态入口，在满足条件的文本生成阶段，用更适合 RTX 2080 Ti 的底层计算路径替代其中一段通用实现。

一句话理解：你的模型、上下文长度、API 服务和多模态入口都不变；Turbo3 只在匹配的 GDN + MTP 解码步骤中，换上一段针对 SM75 调整过的高速 GPU 内核。

三、为什么必须做成“外部插件版”？

研发早期，为了快速证明思路是否有效，我们曾经直接修改 vLLM 内部源码。这样做便于实验，却不适合发布给其他用户：每个人使用的 vLLM 版本、模型目录、量化格式和启动参数都可能不同，覆盖源码会造成安装门槛和回滚风险。

从公开版本开始，Turbo3 已整理为独立的 Python wheel 外部插件包：

通过 vLLM 的 vllm.general_plugins 插件入口加载；
通过 vLLM 原生的 --additional-config 参数显式启用；
不覆盖用户安装目录中的 vLLM 源码文件；
不绑定用户的模型路径、端口、量化格式或上下文参数；
卸载只需执行 pip uninstall，无需恢复源码备份。

外部插件并不等于所有模型都会获得同样收益。Turbo3 只会在运行时进入兼容的 GDN + MTP 解码链路时发挥作用，因此用户仍需通过自检、启动日志与真实任务测试确认效果。

四、Turbo3 的加速原理

1. 大模型生成回答，是不断重复“算下一个词”

大模型输出一段回答，不是一次性写完整篇内容，而是一步一步决定接下来输出哪个 token。生成越长，同一类底层运算就要重复执行越多次。因此，某个小环节每一步只节省一点时间，累计到数百甚至数千个 token 时，就可能带来明显的整体速度提升。

2. MTP 可以理解为“提前多猜几步”

MTP（Multi-Token Prediction） 会让模型在生成时尝试提前预测后续 token。如果提前猜测的内容能够被主模型接受，生成过程就有机会更快推进。

但提前猜测也会带来额外成本：需要准备状态、执行卷积、更新缓存。如果底层实现不够高效，MTP 的收益就会被这些附加开销部分抵消。

3. GDN 像一份不断更新的短期工作记忆

部分 Qwen3.5 / Qwen3.6 架构中包含 GatedDeltaNet（GDN） 层。可以把它通俗理解为：模型每向后生成一步，都要更新一份内部短期状态，以便下一步继续使用。

在 MTP 解码阶段，原始通用路径中存在频繁的小型 kernel 调度和中间数据读写。Turbo3 针对 RTX 2080 Ti 的 SM75 架构，重点做了两件事：

Q/K 卷积准备共享：尽量减少重复计算，让可以复用的中间结果不必重复生成；
V 与 GDN 状态更新融合：将适合合并执行的步骤放进专门调整的 Triton kernel，减少中间显存搬运与小 kernel 调度开销。

当前验证配置中使用的 Turbo3 内核参数为：

QK = (num_warps=2, num_stages=1)
VGDN = (num_warps=2, num_stages=1, BV=32)

4. 为什么回答可能不会逐字等同于未优化版本？

底层 kernel 融合后，浮点计算顺序可能产生极小差异。语言模型每一步都在多个候选 token 之间选择结果；当候选分数很接近时，细小数值变化有可能让模型改用另一种措辞。

因此，本项目的验收标准不是“优化前后全文哈希必须一致”，而是检查真实任务中的回答能力、稳定性、工具调用、长上下文能力和多模态入口是否保持有效。

核心原则：我们追求的是模型解决实际问题的能力和推理速度，而不是强行复制原版每一次浮点舍入轨迹。

五、已完成的实际验证与性能说明

1. 当前公开插件版的真实运行验证

项目	已验证配置
GPU	2 × NVIDIA RTX 2080 Ti 22GB，Compute Capability 7.5
系统	Ubuntu 22.04
vLLM	`0.21.0` 官方稳定版
PyTorch / CUDA	`PyTorch 2.11.0+cu130` / CUDA 13.0
模型	`Qwen3.6-27B-AWQ-INT4`，运行时识别为 `compressed-tensors` / Marlin 路径
插件	`Caovan vLLM SM75 Turbo3 v0.1.3` 外部插件版
上下文	`--max-model-len 262144`
KV Cache	`--kv-cache-dtype fp8`
Attention	自动选择 `FLASHINFER`
推测解码	`method=mtp`，`num_speculative_tokens=2`
多模态	多模态 warmup 正常完成，本版保留入口但不专门优化视觉编码器

2. 如何确认插件确实进入了真实推理路径？

本次验证中，服务能够启动，请求返回 200 OK，并且在首次真实生成请求期间，日志中出现了以下两个 Caovan 专用 kernel：

_caovan_sm75_prepare_qk_conv_spec_decode_kernel
_caovan_sm75_fused_v_gdn_spec_decode_kernel

这说明插件并非“安装了但没有生效”，而是已经真实接管了匹配的 GDN + MTP 解码计算路径。

3. 性能数据应怎样理解？

目前有两类性能证据，需要区分表述：

数据类型	测试结果	说明
研发阶段固定请求 A/B 测试	约 40.027 → 59.958 tokens/s，参考提升约 +49.8%	同一 Turbo3 内核路线的历史验证数据，测试模型为 AutoRound INT4 实例，基础运行栈与当前公开验证环境不同。
公开插件版真实服务验证	官方 vLLM 0.21.0 + AWQ 模型已成功生成；运行日志中启用插件后可观察到约 60+ tokens/s 的持续生成区间	证明外部插件可实际运行并具备明显加速表现；正式百分比仍应以同条件固定 A/B 脚本结果为准。

请注意：不同模型、不同提示词、MTP 接受率、显卡频率、缓存状态和 vLLM 版本都会影响速度。本站不会承诺所有用户都获得相同百分比提升，建议安装后使用自己的实际任务进行验收。

六、当前兼容矩阵

环境	验证状态	建议
`vLLM 0.21.0` + RTX 2080 Ti + `Qwen3.6-27B-AWQ-INT4` + FP8 KV + FlashInfer + MTP=2	已实机验证成功	当前公开教程推荐组合
`vLLM 0.20.2rc1.dev118+g10ebb40d6` + AutoRound INT4 实例	研发阶段已完成固定测速	用于历史性能参考，不作为普通用户首选安装方式
`vLLM 0.21.1rc1.dev387+g5d126dd15` 开发构建	无插件基础路径亦出现异常	暂不建议使用
其他 AWQ / GPTQ / AutoRound / 非量化的 GDN + MTP 模型	兼容候选	先运行自检，再做实际任务与速度验证
没有 NVLink 的 RTX 2080 Ti 环境	支持当前插件设计	当前公开版不依赖 NVLink

七、插件下载

本教程对应版本：

caovan vLLM SM75 Turbo3 v0.1.3 外部插件版

点击下载

八、准备 vLLM 运行环境

如果你已经拥有能够正常运行目标模型的 vLLM 环境，可以直接进入下一节安装插件。若希望按本文已经验证成功的普通用户安装路线测试，建议新建独立环境并安装官方稳定版 vLLM==0.21.0：

conda create -n vllm_caovan python=3.10 -y
conda activate vllm_caovan

python -m pip install --upgrade pip
pip install "vllm==0.21.0"

检查显卡与环境：

python - <<'PY'
import torch
import vllm

print("vLLM:", vllm.__version__)
print("PyTorch:", torch.__version__)
print("CUDA:", torch.version.cuda)

for i in range(torch.cuda.device_count()):
    p = torch.cuda.get_device_properties(i)
    print(i, p.name, f"capability={p.major}.{p.minor}", f"VRAM={p.total_memory / 1024**3:.2f} GiB")
PY

RTX 2080 Ti 正常应显示 capability=7.5。

九、安装 caovan Turbo3 插件：以下步骤请按顺序执行

注意：下面的解压、进入目录、激活 vLLM 环境与安装 wheel 是一套连续流程，并不是几种可选安装方法。

1. 解压插件发布包并进入目录

unzip -o caovan-vllm-sm75-turbo3-v0.1.3-external-plugin.zip
cd ~/caovan-vllm-sm75-turbo3-v0.1.3

2. 激活你用于运行模型的 vLLM 环境

conda activate <你的vllm环境>

例如按照本文新建环境的用户执行：

conda activate vllm_caovan

3. 安装 wheel 插件包

pip install ./dist/caovan_vllm_sm75_turbo3-0.1.3-py3-none-any.whl

十、安装后检查与安全验证

1. 检查插件入口与 vLLM 接口

caovan-sm75-doctor

在本文实测的 vLLM 0.21.0 中，应能够识别到：

GDN 接口检查：PASS family=legacy-gdn-linear-attn-v020
插件入口发现：PASS (caovan_sm75_turbo3)

2. 使用合成张量验证 SM75 kernel

CUDA_VISIBLE_DEVICES=0 caovan-sm75-verify

正常应看到：

PASS: Caovan SM75 Turbo3 外部插件内核通过结构安全门禁。

该步骤不会加载你的真实模型，不会修改模型文件。

3. 检查本地模型结构是否属于候选范围

caovan-sm75-check-model /你的模型目录

该命令仅检查模型配置是否具备当前 Turbo3 所需的结构字段。静态检查通过代表模型属于兼容候选，最终是否真实生效仍以服务日志中的 Caovan kernel 与实际任务验证为准。

十一、在你自己的 vLLM 启动命令中启用插件

Turbo3 不要求用户使用固定启动脚本。你原来如何运行模型，安装插件后仍然使用自己的 vllm serve 命令；只需要增加插件启用项，并确保启用 MTP=2：

--additional-config '{"caovan_sm75_turbo3":true}' \
--speculative-config '{"method":"mtp","num_speculative_tokens":2}' \

通用形式

vllm serve <你的模型路径或模型标识> \
  <你原来的全部启动参数> \
  --additional-config '{"caovan_sm75_turbo3":true}' \
  --speculative-config '{"method":"mtp","num_speculative_tokens":2}'

本文已验证成功的参数示例

下面命令仅用于展示一套已实测配置。模型路径与服务名称请改成你自己的内容：

export CUDA_VISIBLE_DEVICES=0,1
export OMP_NUM_THREADS=12
export PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True

vllm serve /你的/Qwen3.6-27B-AWQ-INT4模型目录 \
  --host 0.0.0.0 \
  --port 8000 \
  --served-model-name 你的模型服务名称 \
  --tensor-parallel-size 2 \
  --dtype half \
  --max-model-len 262144 \
  --max-num-seqs 4 \
  --max-num-batched-tokens 4096 \
  --gpu-memory-utilization 0.96 \
  --kv-cache-dtype fp8 \
  --disable-custom-all-reduce \
  --enable-prefix-caching \
  --mamba-cache-mode align \
  --enable-flashinfer-autotune \
  --compilation-config '{"cudagraph_mode":"PIECEWISE"}' \
  --additional-config '{"caovan_sm75_turbo3":true}' \
  --speculative-config '{"method":"mtp","num_speculative_tokens":2}' \
  --reasoning-parser qwen3 \
  --enable-auto-tool-choice \
  --tool-call-parser qwen3_coder

如果你已有 `--additional-config`

不要重复添加两次该参数，应把插件开关合并进同一个 JSON：

--additional-config '{"gdn_prefill_backend":"auto","caovan_sm75_turbo3":true}'

如果你设置过 `VLLM_PLUGINS`

如果你主动限制了 vLLM 只加载指定插件，需要将本插件加入列表：

export VLLM_PLUGINS="${VLLM_PLUGINS:+${VLLM_PLUGINS},}caovan_sm75_turbo3"

十二、如何确认插件真正启用？

在 v0.1.3 当前版本中，最可靠的确认方式不是只看安装是否成功，而是在实际生成请求后检查日志中是否出现以下 kernel：

_caovan_sm75_prepare_qk_conv_spec_decode_kernel
_caovan_sm75_fused_v_gdn_spec_decode_kernel

例如，你将服务日志保存到文件后，可执行：

grep -E "_caovan_sm75_prepare_qk_conv_spec_decode_kernel|_caovan_sm75_fused_v_gdn_spec_decode_kernel" /你的/vllm服务日志文件.log

如果日志中出现这两个名称，说明 Turbo3 已经进入真实 GDN + MTP 解码路径。若模型结构不匹配、没有启用 MTP=2，或者使用的 GPU 不是 SM75，则插件不会在对应路径中发挥作用。

首次启动提示：在 RTX 2080 Ti + 262K 上下文配置下，首次启动及首次生成请求期间可能需要较长时间完成 torch.compile、CUDA Graph warmup 与 Triton kernel JIT 编译；首次请求日志中的速度不适合直接用作最终测速结果。

十三、如何进行公平测速？

测速必须保持同一模型、同一 vLLM 版本、同一启动参数、同一提示词、同一输出长度，并尽量让首次编译预热状态相近。不能仅比较某一个瞬时峰值。

1. 测试未启用插件的 baseline

用原启动参数启动服务，但不要加入 caovan_sm75_turbo3:true；然后执行：

caovan-sm75-benchmark \
  --model <你的served-model-name> \
  --max-tokens 768 \
  --repeats 2 \
  --output ~/vllm_logs/baseline_result.json

2. 测试启用 Turbo3 后的速度

关闭 baseline 服务，确认显存已释放后，再用加入 Turbo3 参数的同一套命令启动服务，并执行：

caovan-sm75-benchmark \
  --model <你的served-model-name> \
  --max-tokens 768 \
  --repeats 2 \
  --output ~/vllm_logs/turbo3_result.json

3. 不要只验收速度

建议使用自己的真实任务继续检查：

长回答是否完整、逻辑是否正常；
工具调用是否能够正确输出与执行；
长上下文信息召回是否正常；
多模态模型的图片理解入口是否正常；
持续运行是否存在崩溃、NaN、乱码或明显能力异常。

十四、卸载插件

v0.1.3 是外部插件，不会覆盖 vLLM 源码，因此卸载非常简单：

conda activate <你的vllm环境>
pip uninstall caovan-vllm-sm75-turbo3

卸载后重新启动 vLLM 服务，即恢复为 vLLM 自身的默认推理路径，不需要执行任何源码恢复脚本。

十五、常见问题解答

1.为什么插件可以实现推理加速的效果？

大模型在生成文字的时候，并不是一次性把整段回答全部写出来，而是一个 token、一个 token 地往后生成。

你可以把 token 简单理解成文字片段。

比如模型要输出一大段回答，它实际上需要不断重复执行“下一步应该输出什么”的计算过程。

也就是说，生成内容越长，底层的某些计算就要重复执行越多次。

而 Qwen3.5、Qwen3.6 这类模型中，有一部分层会走一种叫做 GatedDeltaNet，简称 GDN 的计算路径。

通俗来说，这部分计算就像是模型在一边生成文字，一边不断维护和更新自己的短期状态。

与此同时，我们还启用了一个叫做 MTP 的功能。

MTP 可以简单理解成：模型在生成当前文字的时候，会顺便提前猜后面几个 token。猜得准的话，就可以一次向前推进更多内容，从而提高整体生成速度。

但是，MTP 也不是没有代价的。

因为它在提前猜测 token 的过程中，也会重复进行一些状态准备、卷积计算和内部数据更新。

如果这些重复计算在 RTX 2080 Ti 上执行得不够高效，那么原本应该用于提速的 MTP，也会被额外开销拖慢一部分效果。

而 caovan vLLM SM75 Turbo3 做的事情，就是针对这段 GDN + MTP 的解码计算路径，重新写了一套更适合 RTX 2080 Ti 的底层 kernel。

简单来说，它主要做了两件事情：

第一，将原本可能重复执行的一部分 Q/K 卷积准备计算进行共享和复用，尽量避免重复劳动。

第二，将 V 相关计算和 GDN 状态更新合并到专门针对 SM75 调整的高速 kernel 中，减少大量细碎任务反复启动所浪费的时间，也减少中间数据在显存中的来回搬运。

大家可以把它理解成：

原来大模型每往后写一步，都要让显卡来回跑好几趟，拿好几次东西，做几次零散的计算。

而 Turbo3 的作用，就是把其中适合一起做的工作重新整理、合并，让 2080 Ti 每一步都跑得更加顺畅。

2.它会不会牺牲上下文、多模态或者模型能力？

这一点非常重要。

因为有一些所谓的“提速方案”，实际上是通过缩短上下文、关闭多模态、降低模型精度，或者减少功能来换取速度。

但这不是我想要的方向。

我开发这个插件的前提就是：我不接受为了速度，把原来已经能够使用的能力直接砍掉。

在我目前验证通过的环境中，我依然保留了：

262144，也就是 262K 的上下文长度；
FP8 KV Cache；
多模态模型入口；
工具调用能力；
MTP 等于 2 的推测解码能力。

也就是说，这个插件优化的是显卡执行底层计算的方式，而不是简单地通过关闭功能来“刷速度”。

当然，我也需要很诚实地说明一点：

底层 kernel 被重新融合和优化之后，模型每一步计算中的极小浮点数差异，可能会影响后面的文字选择。

所以，开启插件后的回答，不一定会和不开启插件时逐字逐句完全一样。

比如原版可能回答“这个方法可以使用”，加速版可能回答“这个方案可以采用”。

但是，对于实际使用来说，我们真正关心的，应该是它能不能正确解决问题，逻辑是否正常，工具调用是否可用，长上下文和多模态能力是否正常，而不是要求两个版本生成出来的每一个字都必须完全相同。

这也是我在整个开发过程中最终确定的验收原则：

只要实际解决问题的能力没有明显下降，而速度获得了足够明显的提升，这样的底层优化就是有价值的。

3. 这个插件只能用于作者测试的某一个模型吗？

不是。插件不会根据作者的模型文件名或路径启用。当前已经验证成功的公开组合是 Qwen3.6-27B-AWQ-INT4；其他运行时进入兼容 GDN + MTP=2 路径的模型属于候选范围，需要自行检查与测试。

4. AWQ、GPTQ、AutoRound 或非量化模型都能用吗？

Turbo3 优化的是 GDN + MTP 解码步骤，而不是某一个量化格式。当前已经实际验证了 AWQ/Compressed-Tensors 路径；研发阶段验证过 AutoRound INT4 实例。GPTQ 与非量化模型应在结构匹配后自行进行速度与质量验收。

5. 推荐使用哪个 vLLM 版本？

当前公开教程明确推荐 vLLM==0.21.0 官方稳定版，因为它已经在全新环境中配合本插件与 AWQ 模型完成真实启动和生成验证。0.21.1rc1.dev387+g5d126dd15 属于开发构建，在本文测试配置下无插件基础路径也曾失败，暂不建议普通用户使用。

6. 没有 NVLink 能使用吗？

可以。当前公开版本不包含 NVLink 专属通信优化，不以 NVLink 作为使用条件。

7. 它会提升图片理解速度吗？

本版本不专门优化视觉编码器。对于多模态模型，它保留图片理解入口，主要加速匹配条件下的文本 / MTP 解码阶段。

8. 为什么首次启动非常慢？

在 262K 长上下文与多模态模型配置下，vLLM 首次启动可能需要进行模型加载、编译、缓存规划、多模态 warmup 与 CUDA Graph 捕获；插件首次真实调用时还可能触发 Triton JIT 编译。完成缓存后，后续启动或请求通常会明显改善。

十六、参考项目 / 致谢 / References

[1] vLLM Project. vLLM: high-throughput LLM serving engine.

https://github.com/vllm-project/vllm

[2] Qwen Team, Alibaba Group. FlashQLA: Flash Qwen Linear Attention.

https://github.com/QwenLM/FlashQLA

https://qwen.ai/blog?id=flashqla

[3] FlashInfer Team. FlashInfer: GPU kernels for LLM serving.

https://github.com/flashinfer-ai/flashinfer

[4] Qwen Team, Alibaba Group. Qwen / Qwen3 / Qwen3.6 model family.

https://github.com/QwenLM/Qwen

https://github.com/QwenLM/Qwen3

https://github.com/QwenLM/Qwen3.6

[5] PyTorch Contributors. PyTorch.

https://github.com/pytorch/pytorch

[6] Triton Contributors. Triton.

https://github.com/triton-lang/triton

[7] Flash Linear Attention Contributors. Flash Linear Attention.

https://github.com/fla-org/flash-linear-attention

[8] Hugging Face. Transformers.

https://github.com/huggingface/transformers

[9] vLLM Project. compressed-tensors.

https://github.com/vllm-project/compressed-tensors

[10] Dao-AILab. FlashAttention.

https://github.com/Dao-AILab/flash-attention

[11] NVIDIA. CUDA Toolkit.

https://developer.nvidia.com/cuda-toolkit

[12] weicj. vLLM-2080Ti-Definitive.

https://github.com/weicj/vLLM-2080Ti-Definitive

[13] weicj. 2080Ti-LLM-Toolbox.

https://github.com/weicj/2080Ti-LLM-Toolbox

[14] weicj. FlashQLA-SM70-SM75.

https://github.com/weicj/FlashQLA-SM70-SM75

[15] vLLM Project. FlashQLA integration discussion.

https://github.com/vllm-project/vllm/issues/43089

特别感谢@SPOTLITE 贡献：