夜雨聆风
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。
一、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. 当前公开插件版的真实运行验证
| Ubuntu | |
0.21.0 | |
PyTorch 2.11.0+cu130 | |
Qwen3.6-27B-AWQ-INT4compressed-tensors / Marlin 路径 | |
Caovan vLLM SM75 Turbo3 v0.1.3 | |
--max-model-len 262144 | |
--kv-cache-dtype fp8 | |
FLASHINFER | |
method=mtpnum_speculative_tokens=2 | |
2. 如何确认插件确实进入了真实推理路径？
本次验证中，服务能够启动，请求返回 200 OK，并且在首次真实生成请求期间，日志中出现了以下两个 Caovan 专用 kernel：
_caovan_sm75_prepare_qk_conv_spec_decode_kernel_caovan_sm75_fused_v_gdn_spec_decode_kernel
这说明插件并非“安装了但没有生效”，而是已经真实接管了匹配的 GDN + MTP 解码计算路径。
3. 性能数据应怎样理解？
目前有两类性能证据，需要区分表述：
请注意：不同模型、不同提示词、MTP 接受率、显卡频率、缓存状态和 vLLM 版本都会影响速度。本站不会承诺所有用户都获得相同百分比提升，建议安装后使用自己的实际任务进行验收。
六、当前兼容矩阵
vLLM 0.21.0Qwen3.6-27B-AWQ-INT4 + FP8 KV + FlashInfer + MTP=2 | 已实机验证成功 | |
vLLM 0.20.2rc1.dev118+g10ebb40d6 | ||
vLLM 0.21.1rc1.dev387+g5d126dd15 | 暂不建议使用 | |
七、插件下载
本教程对应版本：
caovan vLLM SM75 Turbo3 v0.1.3 外部插件版
下载资源
八、准备 vLLM 运行环境
如果你已经拥有能够正常运行目标模型的 vLLM 环境，可以直接进入下一节安装插件。若希望按本文已经验证成功的普通用户安装路线测试，建议新建独立环境并安装官方稳定版 vLLM==0.21.0：
conda create -n vllm_caovan python=3.10 -yconda activate vllm_caovanpython -m pip install --upgrade pippip install "vllm==0.21.0"
检查显卡与环境：
python - <<'PY'import torchimport vllmprint("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.zipcd ~/caovan-vllm-sm75-turbo3-v0.1.3
2. 激活你用于运行模型的 vLLM 环境
conda activate <你的vllm环境>例如按照本文新建环境的用户执行：
conda activate vllm_caovan3. 安装 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,1export OMP_NUM_THREADS=12export PYTORCH_CUDA_ALLOC_CONF=expandable_segments:Truevllm 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 编译。完成缓存后，后续启动或请求通常会明显改善。
