从 FlashQLA 参考路线到自研 GDNCore Real Prefill 的阶段性演进

摘要

Caovan vLLM SM75 Turbo3 external plugin v0.4.33 是面向 NVIDIA RTX 2080 Ti / SM75 架构的阶段性新版本。相比 v0.4.22以及之前的版本，v0.4.33 的主要变化不只是启动参数或推理配置的调整，而是完成了一个重要的技术路线转向：从早期参考 FlashQLA / FLA / 外部 GDN kernel 的优化路线，逐步转向 caovan 自研 GDNCore Real Prefill 与 AcceptanceLock decode path。

FlashQLA 是 Qwen 团队开源的高性能 linear attention kernel library，基于 TileLang，对 GDN Chunked Prefill 的 forward / backward 路径做了算子融合和性能优化，并在 NVIDIA Hopper 等场景中展示了显著的 prefill 加速能力。它对 GDN prefill 领域具有重要参考价值，也为本项目早期理解 Qwen Linear Attention / GDN 优化方向提供了启发。

但是，caovan vLLM SM75 Turbo3 的目标并不是在 Hopper 等新架构上复现 FlashQLA 的理想性能，而是在 2×RTX 2080 Ti 22G、SM75 架构、vLLM serving、Qwen3.6-27B-AWQ-INT4、长上下文、MTP speculative decoding 等约束下，形成可安装、可复现、可维护、低依赖、低故障率的推理加速插件。这个目标决定了 v0.4.33 不能简单把 FlashQLA 作为主实现依赖，而必须建立可控的自研 GDNCore。

v0.4.33 的核心技术特征包括：继续基于 vLLM serving 框架；保留 AutoSpec、DynamicTP、AutoModelProfile、AutoMem、Elastic-KV 等自动化启动画像能力；固定 MTP=3，避免 MTP=4 在 2×2080 Ti 22G 上引发 OOM；移除 FlashQLA / TileLang / 外部 GDN runtime dependency；启用 caovan GDNCore real-prefill；采用 SDF-GDN / segmented delta fusion packed-prefill interface；通过 blockv_packed 模式接管 GDN prefill；通过 AcceptanceLock Iota 保留 split-QK + fused V/GDN decode path，保护 MTP speculative decoding 的 draft acceptance rate。

本文将系统介绍 v0.4.33 相比 v0.4.22 的技术更新，分析 FlashQLA 的贡献与适用边界，说明 caovan 自研 GDNCore 的技术特性和功能特性，并从目标硬件、软件依赖、prefill 优化、decode 路径、MTP 接受率、显存压力、工程分发、长期可维护性等多个维度比较 FlashQLA 路线与 caovan GDNCore 路线。

关键词

RTX 2080 Ti、SM75、vLLM、Qwen3.6、AWQ INT4、GDNCore、FlashQLA、Gated DeltaNet、Linear Attention、Speculative Decoding、MTP、Triton、TileLang、Elastic-KV、AutoSpec、AcceptanceLock

1. 项目背景

1.1 2080 Ti / SM75 推理优化的特殊性

RTX 2080 Ti 是 NVIDIA Turing 架构显卡，计算能力为 SM75。它在今天的大模型推理环境中属于“老架构高性价比显卡”。相比 Ampere、Ada、Hopper、Blackwell 等新架构，SM75 在以下方面存在客观限制：

1. 不支持很多新一代 attention / sampler / kernel 默认路径；
2. FlashAttention 2 等路径对计算能力存在限制；
3. Triton kernel 编译行为和新架构不同；
4. 寄存器压力、shared memory、warp 调度和 Tensor Core 使用方式与 Hopper 不同；
5. 单卡显存有限，即使是 22G 改版 2080 Ti，也需要非常谨慎地控制 KV cache、MTP cache 和临时缓冲区；
6. vLLM、FlashInfer、FlashAttention、FLA 等生态中的新优化路径通常不会优先为 SM75 调优。

因此，在 2×RTX 2080 Ti 22G 上运行 Qwen3.6-27B-AWQ-INT4 的问题，不是简单地“装上 vLLM 就可以”，而是一个综合问题：

旧架构 GPU
+ 有限显存
+ 大模型 AWQ INT4
+ 长上下文
+ GDN / Linear Attention
+ MTP speculative decoding
+ vLLM serving
+ CUDA / Triton / PyTorch / vLLM 版本差异

caovan vLLM SM75 Turbo3 插件就是为了解决这个组合问题而开发的。

1.2 v0.4.22 的阶段性价值

v0.4.22 是一个重要的外部分发版本。它已经把“SM75 上如何稳定运行 Qwen3.6-27B-AWQ-INT4”这件事做成了插件化工具。

v0.4.22 的核心能力包括：

1. 自动识别 GPU 数量和 SM 架构；
2. 自动判断 tensor parallel size；
3. 自动识别 AWQ 量化模型；
4. 自动注入 MTP speculative decoding 参数；
5. 自动设置 gpu_memory_utilization；
6. 自动保留 Elastic-KV 安全显存；
7. 自动注入 PIECEWISE CUDA Graph 配置；
8. 自动启用 CKV-PAC V-only Sidecar；
9. 在 SM75 上规避不安全的 FlashInfer sampler 路径；
10. 通过 caovan-vllm-serve 降低用户手动配置成本。

v0.4.22 的价值可以概括为：

让 2×2080Ti 22G + Qwen3.6-27B-AWQ-INT4 从“能折腾出来”变成“可以插件化交付”

但是，v0.4.22 仍然存在一个重要问题：它的底层 GDN / Linear Attention 优化方向尚未完全自主可控。早期版本参考过 FlashQLA、FLA、FlashInfer、FlashAttention、weicj 相关项目等外部生态。外部参考对项目早期非常重要，但随着插件进入真实用户环境，依赖外部 GDN kernel 生态的风险逐渐暴露出来。

2. FlashQLA 的贡献与技术定位

2.1 FlashQLA 是什么

FlashQLA 是 Qwen 团队开源的 high-performance linear attention kernel library。它基于 TileLang，对 GDN Chunked Prefill 的 forward / backward 路径进行算子融合和性能优化。根据公开介绍，FlashQLA 在 NVIDIA Hopper 场景中，相比 FLA Triton kernel 可以实现明显的 forward / backward 加速。

从技术定位看，FlashQLA 的价值主要体现在：

1. 证明 Qwen Linear Attention / GDN Chunked Prefill 存在很大的 kernel 优化空间；
2. 通过 TileLang 展示了 GDN prefill 的高性能融合实现方式；
3. 为 Qwen 系列 linear attention 模型的训练、预训练、边缘 agentic inference 等场景提供了高性能参考；
4. 推动了社区对 GDN / Linear Attention kernel 的关注；
5. 对本项目早期理解 GDN Chunked Prefill 的计算结构具有重要启发。

因此，FlashQLA 是 Qwen GDN / Linear Attention 优化生态中的重要贡献。

2.2 FlashQLA 的适用场景

从公开资料和项目定位看，FlashQLA 更适合以下场景：

1. 目标硬件较新，例如 Hopper；
2. 软件栈可以接受 TileLang 依赖；
3. 主要优化目标是 GDN Chunked Prefill；
4. 关注 forward / backward kernel 性能；
5. 环境由研发团队或训练团队统一控制；
6. 对第三方 kernel 编译链可控；
7. 目标是最大化 prefill 或训练相关 kernel 性能。

对于这类场景，FlashQLA 的设计是合理的。它更像是一个高性能 GDN / linear attention kernel library，而不是一个专门为 2080 Ti / SM75 普通用户分发设计的 vLLM 外部插件。

2.3 FlashQLA 对本项目的启发

FlashQLA 对 caovan vLLM SM75 Turbo3 的启发主要有三点：

第一，GDN prefill 值得优化。
在 Qwen3.6 这类结构中，GDN / Linear Attention 不是边缘路径，而是真实推理中的重要路径。FlashQLA 证明了 GDN Chunked Prefill 不是“只能接受上游默认实现”的黑盒，而是可以通过专门 kernel 设计获得显著性能收益。

第二，算子融合有价值，但必须结合目标场景。
FlashQLA 通过 operator fusion 提升 GDN prefill 性能，说明融合思路在一定场景中是有效的。但 caovan 后续测试也说明，融合不是越多越好，尤其在 speculative decoding 场景中，某些中间边界会影响 draft acceptance。

第三，外部 kernel 生态可以启发方向，但不能替代自研可控路径。
FlashQLA 提供了方向启发，但我们最终需要面向 2080 Ti / SM75 的真实约束，开发自己的 GDNCore。

3. FlashQLA 路线在 caovan v0.4.33 场景中的适用边界

FlashQLA 的设计目标、依赖结构和优化重点，与 caovan vLLM SM75 Turbo3 v0.4.33 的交付目标并不完全一致。

这种不一致主要体现在以下几个方面。

3.1 目标硬件不同：Hopper 优化思路不能直接等价于 SM75 最优路径

FlashQLA 的公开性能收益主要面向 NVIDIA Hopper 等较新架构。而 caovan vLLM SM75 Turbo3 的目标硬件是 RTX 2080 Ti / SM75。

这两个硬件平台在以下方面差异明显：

1. Tensor Core 能力不同；
2. shared memory 与寄存器资源不同；
3. warp 调度行为不同；
4. Triton / TileLang 编译结果不同；
5. kernel fusion 的最优粒度不同；
6. memory-bound 与 compute-bound 的平衡点不同；
7. 对旧架构 fallback 的需求不同。

因此，即使 FlashQLA 在 Hopper 上表现很好，也不能直接推出它就是 SM75 上的最优方案。

对于 caovan v0.4.33 来说，关键目标不是“复用 Hopper 上表现最好的方案”，而是：

在 SM75 上找到真实服务场景下 tokens/s、稳定性、显存安全、用户可安装性之间的最优平衡点

3.2 优化重点不同：FlashQLA 主要面向 GDN Chunked Prefill，而 v0.4.33 必须同时考虑 decode 和 acceptance

FlashQLA 的核心关注点是 GDN Chunked Prefill。这个方向非常重要，但它并不能覆盖 vLLM serving 中的全部瓶颈。

在 v0.4.29 到 v0.4.33 的测试过程中，我们已经观察到一个关键现象：当 caovan GDNCore real-prefill 接管成功后，prefill 不再是唯一瓶颈，整体生成速度更多受到 decode 和 speculative acceptance 的影响。

真实推理吞吐可以粗略理解为：

真实 tokens/s
≈ prefill 效率
+ decode kernel 效率
+ draft token 生成速度 × draft acceptance rate
- 验证 / 回滚 / state commit 成本

这意味着，单独提升 prefill kernel 并不必然提升最终生成速度。如果某个 decode fusion 改动导致 draft acceptance 下降，那么即使 kernel launch 数减少，最终 tokens/s 也可能下降。

v0.4.32 的 single-launch decode 实验就是反例。它减少了 kernel launch，但降低了 speculative acceptance，最终速度反而下降。v0.4.33 因此恢复 split-QK + fused V/GDN 的 AcceptanceLock 路线。

这说明 caovan GDNCore 的目标不仅是 prefill kernel 加速，而是：

prefill 接管
+ decode 路径保护
+ speculative acceptance 保护
+ state commit 顺序控制
+ 显存安全

这比 FlashQLA 的单点 prefill kernel 优化目标更工程化，也更贴近 2080 Ti / vLLM serving 的真实问题。

3.3 依赖结构不同：FlashQLA 基于 TileLang，而 caovan v0.4.33 需要降低用户环境复杂度

FlashQLA 基于 TileLang。TileLang 作为 kernel 编程模型本身具有价值，但对 caovan 插件公开分发来说，它也意味着额外依赖。

普通用户的环境可能存在大量差异：

CUDA 版本不同
PyTorch 版本不同
Triton 版本不同
vLLM 版本不同
ptxas 路径不同
驱动版本不同
Conda 环境不同
GPU 数量不同
GPU 架构不同
TileLang 是否正确安装不同

如果插件的核心能力依赖 TileLang + FlashQLA + 外部 GDN kernel，那么用户环境中的任何一个环节出问题，都可能导致插件无法启动、无法编译、autotune 卡住、运行时异常或者性能不可预测。

caovan v0.4.33 的原则是：

能不增加外部依赖，就不增加外部依赖；
能把核心路径收回插件内部，就收回插件内部；
能使用 Triton 自研 kernel，就不要再依赖额外外部 GDN runtime。

这也是为什么 v0.4.33 明确显示：

external_gdn_kernel_dependency=none
tilelang=not required
runtime_cuda_extension=not required

这出于公开插件分发、旧架构适配和用户环境可控性的工程取舍。

3.4 接口稳定性不同：FlashQLA 不是 vLLM 内部 GDN 接口的长期稳定抽象层

vLLM 内部的 GDN / Mamba / Linear Attention 相关路径并不是对外长期稳定的插件 API。实际日志中已经出现过 modular 路径不存在、legacy 路径接管等情况。

这说明不同 vLLM 版本之间，相关模块路径、类名、函数签名、metadata 组织方式都可能变化。

如果主线依赖外部 FlashQLA 接入方式，就会遇到一个问题：每次 vLLM 内部接口变化，都可能导致外部 kernel 适配失效。

caovan v0.4.33 的路线是自己做兼容层：

检测 vLLM GDN 候选路径
识别 legacy / modular GDN 接口
确认 GatedDeltaNetAttention signature
通过 Caovan 插件入口接管
通过 GDNCore real-prefill 进入真实路径
通过 strict / fallback 控制失败行为

这让项目能够独立适配 vLLM 内部变化，而不是把兼容性完全交给外部 kernel 项目。

4. 为什么必须启用自研 caovan GDNCore

如果只是说 FlashQLA 与本项目目标不完全一致，还不够。更关键的问题是：为什么 v0.4.33 必须启用自研 caovan GDNCore？

答案是：只有自研 Core 才能让我们真正控制 SM75 上影响最终 tokens/s 的完整推理链路。

4.1 GDNCore 让 prefill 从不可控上游路径变成可控路径

在早期版本中，GDN prefill 可能仍然依赖 vLLM 原生路径、FLA Triton kernel、外部 GDN kernel 或上游 autotuning 行为。实际使用中可能出现服务已经启动，但第一条真实请求长时间没有输出的情况。

这类问题往往不是模型错误，而是上游 GDN / FLA / Triton kernel 在请求阶段触发大量 JIT、profiling 或 autotuning。

caovan GDNCore 的第一层价值是：把 prefill 热路径接管到自己可控的实现中。

v0.4.33 通过 GDNCore real-prefill 使日志出现：

[Caovan GDNCore] ACTIVE REAL PREFILL

这说明 caovan GDNCore 已经不是 selftest 工具，而是进入真实服务 prefill 路径。

4.2 GDNCore 采用 SDF-GDN / segmented delta fusion packed-prefill interface

v0.4.33 的 GDNCore 不只是简单替换一个函数，而是围绕 GDN 递推结构重新组织 packed-prefill 计算路径。

它的核心思路可以概括为：

SDF-GDN
Segmented Delta Fusion
Packed Prefill Interface
Block-V Triton Kernel
cu_seqlens / packed token layout
chunk metadata bypass

这意味着 GDNCore 不是被动适配某个外部 kernel 的数据布局，而是主动围绕 GDN 数学结构和 vLLM serving 数据形态重建计算路径。

其中，blockv_packed 是 v0.4.33 的关键模式。它面向 packed token / cu_seqlens 形态，在真实 prefill 中使用自研 Triton kernel 接管计算。

4.3 GDNCore 不依赖 FlashQLA、TileLang 或外部 runtime CUDA extension

v0.4.33 的功能特性之一是依赖链收敛：

external_gdn_kernel_dependency=none
tilelang=not required
runtime_cuda_extension=not required

这对公开插件非常重要。它意味着用户不需要额外安装 FlashQLA、TileLang 或复杂的外部 CUDA extension 编译链。

这带来几个直接收益：

1. 安装步骤更简单；
2. 用户环境更可控；
3. 出错概率更低；
4. 版本兼容面更宽；
5. 后续调试责任更集中；
6. 插件可以独立迭代。

对于 2080 Ti / SM75 用户群体来说，这一点比“理论上某个外部 kernel 更快”更重要。

4.4 GDNCore 能与 AutoSpec / Elastic-KV / MTP 策略协同

caovan GDNCore 不是孤立 kernel，而是与插件整体调度策略协同工作。

v0.4.33 仍然保留：

AutoSpec
DynamicTP
AutoModelProfile
AutoMem
Elastic-KV
Runtime CUDA Compat
FlashInfer sampler guard
PIECEWISE CUDA Graph

其中 AutoSpec 负责在 2×SM75 场景下保持 MTP=3；AutoMem 和 Elastic-KV 负责控制显存水位，为 KV cache、MTP cache、Triton workspace、runtime buffer 等预留空间。

这说明 v0.4.33 的优化不是单点 kernel 优化，而是完整系统优化：

底层 kernel
+ vLLM serving
+ speculative decoding
+ 显存安全
+ 旧架构兼容
+ 用户部署体验

4.5 AcceptanceLock：GDNCore 不只优化 prefill，还保护 decode 接受率

v0.4.33 的重要概念是 AcceptanceLock Iota。

AcceptanceLock 的核心思想是：

在 MTP speculative decoding 中，draft acceptance rate 是第一性能指标之一。
不能为了减少 kernel launch 或追求更激进融合而破坏 acceptance。

v0.4.32 证明 single-launch decode fusion 并不是当前最优路线。它减少了 kernel launch，但降低了 acceptance，最终 tokens/s 下降。

因此 v0.4.33 恢复：

split-QK
+ FP16 materialization boundary
+ fused V/GDN
+ ordered state commit

这种路线看起来不如 single-launch 激进，但在实际 speculative decoding 中更稳。

这说明 caovan GDNCore 的优化目标比 FlashQLA 更贴近 serving decode：

不是只看单个 kernel benchmark；
而是看最终 tokens/s、accepted throughput 和用户真实输出速度。

5. v0.4.33 相比 v0.4.22 的主要技术更新

5.1 GDNCore 从“参考 / 安全接管”发展为 real-prefill 主路径

v0.4.22 阶段，GDNCore 还不是成熟主路径，更多是围绕安全接管、自动配置和外部参考路线逐步探索。

v0.4.33 则已经明确：

Caovan GDNCore Real Prefill AcceptanceLock Iota
gdncore_mode=blockv_packed
external_gdn_kernel=none
fallback=upstream-unless-strict

这标志着 GDNCore 从辅助角色变成核心研发路径。

5.2 从外部 kernel 参考转向自研 Triton kernel

v0.4.22 仍然较多受到 FlashQLA / FLA / FlashInfer / FlashAttention 等生态影响。

v0.4.33 则保留 Triton 作为 kernel 编写工具，但不再依赖 FlashQLA / TileLang / 外部 GDN runtime。这是一个重要差异：

v0.4.22：外部生态参考较强
v0.4.33：Caovan 自研 Core 路线明确

5.3 从“prefill 加速”扩展到“prefill + decode + acceptance”

v0.4.22 更偏向整体启动画像、MTP 注入、显存管理和外部 GDN 参考。

v0.4.33 则明确进入底层推理链路：

GDN real-prefill
+ split-QK decode path
+ fused V/GDN
+ AcceptanceLock
+ MTP=3 acceptance 保护

这说明项目优化目标从“让参数自动更合理”进入“改造真实计算路径”。

5.4 从 MTP 参数路线转向底层计算路径路线

早期测试中，MTP=4 可以提高速度，但在 2×2080 Ti 22G 上容易 OOM。因此 v0.4.33 明确拒绝把 MTP=4 作为阶段性主线。

v0.4.33 的原则是：

MTP=3 不变
显存压力不增加
通过底层 GDN / decode 路径提高效率

这比单纯拉高 speculative depth 更稳健。

5.5 依赖链更短，公开分发风险更低

v0.4.33 不依赖 FlashQLA、TileLang、外部 runtime CUDA extension。对普通用户来说，这意味着：

1. 安装失败概率更低；
2. 编译链更短；
3. 日志更容易解释；
4. 兼容性更容易维护；
5. 后续版本更容易迭代。

这也是 v0.4.33 能作为阶段性新版本的重要原因。

6. FlashQLA 与 Caovan GDNCore 的多维度对比

7. v0.4.33 的功能特性

7.1 自动启动画像

v0.4.33 继续保留自动启动画像能力：

AutoSpec
DynamicTP
AutoModelProfile
AutoMem
DoctorProfile
Runtime CUDA Compat
Elastic-KV

这些模块共同负责根据模型、GPU、TP、上下文长度、batch token、MTP 风险等信息自动生成安全启动参数。

7.2 GDN 接口兼容检测

v0.4.33 会检测 vLLM 内部 GDN 路径。如果 modular 路径不存在，会尝试 legacy GDN 路径。这样可以适配 vLLM 内部目录差异。

典型逻辑是：

尝试 modular qwen gdn path
失败后进入 legacy-gdn-linear-attn path
确认 GatedDeltaNetAttention signature
插件入口接管

这降低了 vLLM 版本变化带来的风险。

7.3 GDNCore real-prefill 接管

v0.4.33 默认启用：

gdncore_mode=blockv_packed

并通过 Caovan GDNCore 接管 real-prefill。它不再只是 selftest，而是进入真实服务路径。

7.4 SDF-GDN / segmented delta fusion packed-prefill interface

v0.4.33 的 GDNCore 采用 segmented delta fusion 思路，面向 packed prefill 形态，通过 cu_seqlens 等信息组织序列边界，并在必要时绕过上游 chunk metadata 的布局约束。

这使得 GDNCore 更贴近数学递推本身，而不是绑定某个外部 kernel 的布局假设。

7.5 AcceptanceLock decode path

v0.4.33 默认恢复 split-QK + fused V/GDN 路线，避免 v0.4.32 single-launch 路线导致的 draft acceptance 下降。

AcceptanceLock 的核心原则是：

保护 MTP=3 acceptance
保留 FP16 materialization 边界
保留 state commit 顺序
不盲目合并 kernel

7.6 MTP=3 稳定策略

v0.4.33 在 2×2080 Ti 22G 场景中继续保持 MTP=3。

原因是：

1. MTP=4 虽然可能提升速度；
2. 但 2×22G 上容易 OOM；
3. 长上下文下显存压力更大；
4. 公开插件不能把不稳定参数作为默认路线。

因此，v0.4.33 选择从底层计算路径优化，而不是靠 MTP=4 硬拉速度。

7.7 FlashInfer sampler guard

v0.4.33 继续在 SM75 上禁用不安全 sampler 路径，避免错误进入不适合 2080 Ti 的 FlashInfer / FlashAttention 路线。

8. v0.4.33 的理论基础

8.1 Serving 场景的性能指标不是单 kernel benchmark

在训练或 benchmark 场景中，单个 kernel 的 forward speedup 很重要。但在 vLLM serving 中，用户最终关心的是：

请求是否稳定
首 token 是否快
持续生成 tokens/s 是否高
OOM 风险是否低
多轮输出是否正常

因此，v0.4.33 的优化指标不是单个 prefill kernel 的绝对速度，而是完整链路表现。

8.2 Speculative decoding 中 acceptance 是核心指标

MTP speculative decoding 的最终收益取决于 draft token 被接受的比例。如果 acceptance 降低，draft throughput 再高也可能得不偿失。

因此，v0.4.33 采用 AcceptanceLock：

先保护 acceptance
再优化 kernel 几何

这也是 v0.4.33 相比 v0.4.32 的关键修正。

8.3 中间边界可能是性能稳定性的一部分

传统 GPU 优化容易追求 fusion，但 v0.4.32 说明：在 speculative decoding 中，某些中间边界不能随意删除。

这些边界包括：

Q/K conv 输出边界
FP16 materialization 边界
state commit 边界
token position 顺序
recurrent state index 映射

v0.4.33 的原则是：不破坏这些对 acceptance 有帮助的边界。

8.4 SM75 优化需要专门路线

SM75 不是 Hopper。2080 Ti 的最优路线不一定是新架构论文或新架构 kernel 的直接移植。

v0.4.33 的路线更务实：

少依赖
可安装
能跑真实服务
MTP=3 不 OOM
tokens/s 稳定
acceptance 高
后续可继续做 key-head grouped decode kernel

这也是自研 Core 的现实意义。

9. References 的重新定位

9.1 核心依赖 / Core Dependencies

[1] vLLM Project. vLLM: high-throughput LLM serving engine.
https://github.com/vllm-project/vllm

[2] 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

[3] PyTorch Contributors. PyTorch.
https://github.com/pytorch/pytorch

[4] Triton Contributors. Triton.
https://github.com/triton-lang/triton

[5] NVIDIA. CUDA Toolkit.
https://developer.nvidia.com/cuda-toolkit

9.2 生态参考 / Ecosystem References

[6] FlashInfer Team. FlashInfer: GPU kernels for LLM serving.
https://github.com/flashinfer-ai/flashinfer

[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

9.3 历史路线参考 / Historical References

[11] Qwen Team, Alibaba Group. FlashQLA: Flash Qwen Linear Attention.
https://github.com/QwenLM/FlashQLA
https://qwen.ai/blog?id=flashqla

说明：FlashQLA 曾为本项目早期理解 Qwen GDN Chunked Prefill 优化方向提供重要参考。它证明了 GDN prefill 存在较大的 kernel 优化空间，也展示了 TileLang fusion 在特定场景中的价值。但 v0.4.33 的当前主线已经转向 caovan 自研 GDNCore，因此 FlashQLA 不再作为当前版本的直接依赖或主实现依据。

[12] weicj. FlashQLA-SM70-SM75.
https://github.com/weicj/FlashQLA-SM70-SM75

说明：该项目对早期探索 FlashQLA 在 SM70 / SM75 上的可行性具有参考意义，但 v0.4.33 不再走 FlashQLA 移植路线。

[13] vLLM Project. FlashQLA integration discussion.
https://github.com/vllm-project/vllm/issues/43089

说明：该讨论对理解 vLLM 与 FlashQLA 集成的可能性有参考意义，但 v0.4.33 的路线不是集成 FlashQLA，而是通过 caovan GDNCore 接管 real-prefill。

9.4 特别感谢 / Special Thanks

特别感谢 @SPOTLITE / weicj 相关项目对 RTX 2080 Ti / SM75 vLLM 适配方向提供的公开探索和工程启发：

https://github.com/weicj/vLLM-2080Ti-Definitive
https://github.com/weicj/2080Ti-LLM-Toolbox
https://github.com/weicj/FlashQLA-SM70-SM75

这些项目对早期理解 2080 Ti / SM75 上的 vLLM 适配、FlashQLA 迁移、MTP 路线和工程化分发具有参考价值。caovan v0.4.33 在这些公开探索的基础上，进一步推进到自研 GDNCore real-prefill 和 AcceptanceLock decode path。

10. 结论

caovan vLLM SM75 Turbo3 v0.4.33 的意义，不是简单的版本升级，而是技术路线从“外部参考驱动”转向“自研 Core 驱动”。

FlashQLA 对 GDN Chunked Prefill 优化具有重要贡献。它展示了 TileLang fusion 在 Qwen Linear Attention / GDN 场景中的潜力，也为本项目早期理解 GDN prefill 提供了重要参考。但是，FlashQLA 的设计目标、硬件假设、依赖结构和优化重点，与 caovan v0.4.33 面向 2×RTX 2080 Ti 22G 的公开插件目标并不完全一致。

v0.4.33 的最终取舍是：

保留 vLLM 作为 serving 基座
保留 Triton 作为自研 kernel 工具
保留 FlashQLA 作为历史路线参考
不再依赖 FlashQLA / TileLang / 外部 GDN kernel
启用 caovan 自研 GDNCore real-prefill
固定 MTP=3，避免 MTP=4 OOM
通过 AcceptanceLock 保护 speculative decoding 接受率
继续向 key-head grouped decode kernel 演进

这条路线更加适合 2080 Ti / SM75 的真实约束，也更适合公开插件的长期维护。v0.4.33 因此可以作为一个阶段性新版本：它不追求“看起来最激进”的 kernel fusion，而是追求“真实服务中更稳定、更可控、更可复现”的推理加速路径。