DeepSeek 在 GitHub 发布 DeepSelect v1.0.0，一套面向稀疏注意力和采样流程的高性能 TopK CUDA 内核。项目宣称在特定基准下对比 torch.topk 可实现约 2 至 20 倍加速，但实际收益依赖输入类型、批量、词表规模和硬件环境，需独立复测。
DeepSeek 于 2026 年 9 月 10 日在 GitHub 公开了 DeepSelect v1.0.0。这是一套面向 DeepSeek 稀疏注意力（DeepSeek Sparse Attention，DSA）和采样流程的高性能 TopK CUDA 内核实现，而不是一次新的基础模型发布。
在 DeepSelect 官方代码仓库中，DeepSeek 将项目描述为 DSA 所使用的 TopK 内核，以及采样器相关 TopK 工作负载的实现。项目 README 声称，在特定测试条件下，DeepSelect 相对于原生 PyTorch torch.topk 可实现约 2 至 20 倍加速。该数字来自项目方自己的基准测试，实际效果取决于输入数据类型、批量大小、词表规模和 TopK 参数，不能直接视为所有环境下的通用结论。
公开的是计算基础设施，而非新模型
DeepSelect 的初始发布提交是 GitHub 上的 v1.0.0 提交，提交日期为 9 月 10 日。README 称，这套内核服务于 DeepSeek V3.2、V4 和 V4.1 等模型所使用的 DSA 相关工作负载，同时也覆盖采样器中的 TopK 操作。
这一定位需要与模型发布区分开来。代码仓库说明的是底层算子和接口已经公开，并不意味着新的 DeepSeek 基础模型在同一天发布，也不能单凭仓库中出现 V4 或 V4.1 的表述，推导出这些模型的完整规格、训练状态或商业部署情况。
DeepSeek 此前已经将 DSA 用于长上下文效率优化。DeepSeek 对 V3.2-Exp 的官方说明将 DSA 描述为一种面向长上下文的细粒度稀疏注意力机制；相关技术报告则把 Lightning Indexer 和 TopK 选择作为这一计算路径的重要组成部分。简单来说，系统先从较大的候选集合中筛选更值得计算的部分，再对有限候选执行更完整的注意力运算，从而减少不必要的计算和内存访问。
TopK 内核位于稀疏注意力的关键位置
TopK 操作的任务，是从一组分数或 logits 中找出排名靠前的若干项。在稀疏注意力中，它可以帮助索引器选择需要进一步处理的 token；在生成模型采样中，它也可以用于从词表中筛选候选 token。
这类操作通常并不以大量浮点乘法为主要特征，性能更多受到显存带宽、数据搬运、排序或选择策略，以及 CUDA 内核调度方式的影响。DeepSelect README 因此使用有效内存带宽来报告性能比，而不是使用 FLOPS 作为指标。
项目方表示，TopK 的最佳算法并不固定：输入是 BF16 还是 FP32、批量大小是多少、词表有多大，以及需要返回多少个候选项，都会改变最快实现。当前公开实现重点覆盖 BF16 和 FP32 场景，并针对小 TopK 值进行优化；README 说明，支持的 TopK 最大值为 4096，超过这一范围的输入不在当前支持范围内。
在 BF16 场景下，项目说明同时考虑了较小和较大的批量，以及不同规模的词表。FP32 示例则主要针对约 128K 规模的词表。项目还建议，在不需要排序时关闭 sorted_index，在不需要返回候选值时使用 return_value=False，以减少额外开销。这些选项意味着，所谓“2 至 20 倍”并不是一个脱离参数设置的固定倍率。
PyTorch 接口与 CUDA 环境要求
DeepSelect 提供 PyTorch 接口。官方示例展示了在 CUDA 设备上创建 BF16 或 FP32 张量，并调用 deep_select.topk 返回候选值和索引。用户还可以指定索引类型、是否排序，以及是否返回候选值。
不过，接口有明确的内存布局要求。输入张量的最后一维需要连续，行步长必须满足项目规定的字节对齐条件；输出张量也有相应的步长约束。对于不满足对齐要求的输入，用户需要通过填充等方式进行处理。README 还展示了可变长度行的 end 参数，用于让不同批次的行在同一次调用中使用不同的有效范围。
项目提供 NaN 检查功能。按照文档，默认设置下如果发现 NaN，内核会触发 CUDA 的 trap()；长度小于或等于 TopK 的行则不会进行 NaN 检查。这些设计更接近面向大规模推理系统的底层库，而不是面向普通 Python 用户的即插即用组件。
仓库采用 MIT 许可证。安装说明包括 Git 子模块初始化和通过 pip 构建安装，实际使用仍需要兼容的 CUDA、PyTorch、GPU 架构和编译环境。换言之，代码公开降低了研究和集成门槛，但不等于在任意 GPU 上都能直接获得 README 中的性能收益。
DeepSeek 正在把稀疏化推进到软件栈底层
DeepSelect 的意义不只在于一个独立的 TopK 实现。它显示出，围绕稀疏注意力的竞争正在从模型架构和论文描述延伸到具体的 GPU 内核、内存访问和采样路径。
在 AIFlux 此前关于 DeepSeek 公开 DeepGEMM 26/09 更新的报道中，DeepSeek 同样把稀疏索引、MoE 路由、融合计算和运行时编译等底层组件作为公开更新的重点。两者共同指向一个趋势：模型效率不仅取决于参数规模或注意力公式，也取决于这些公式能否在特定 GPU 和分布式系统上高效执行。
这一趋势也与 DeepSeek V4.1-Flash 的发布形成了软件和模型层面的对应关系。V4.1-Flash 的公开资料把长上下文、稀疏激活和推理成本作为重点；DeepSelect 则针对其中更细的候选选择环节提供专门内核。不过，底层内核的局部加速并不自动等于端到端服务成本按相同比例下降，真实收益还会受到显存容量、卡间互联、批处理方式、编译开销和上层框架调度的影响。
性能数字仍需独立复测
目前能够确认的是，DeepSelect 已作为 DeepSeek 官方 GitHub 仓库的 v1.0.0 代码公开，项目明确面向 DSA 和采样流程，并提供了 BF16、FP32、可变长度行和 NaN 检查等功能。官方 README 也给出了与 torch.topk 的性能对比图和测试方法。
尚不能确认的是，这些性能数字在不同 GPU 型号、CUDA 版本、PyTorch 版本、输入形状和上层模型服务中的稳定表现。TopK 的加速幅度高度依赖工作负载，项目方的基准结果也不等同于独立第三方复测。
下一步值得关注的是，DeepSelect 是否会被更多推理框架和开源模型实现集成，以及社区能否在统一硬件和统一参数下复现其性能范围。如果这些结果得到独立验证，这类内核可能为长上下文模型和高吞吐采样提供更具体的工程收益；在此之前，2 至 20 倍更适合被理解为项目方在特定测试条件下给出的性能区间，而不是普遍适用的承诺。
来源：DeepSelect 官方 GitHub 仓库；DeepSelect v1.0.0 初始发布提交；DeepSeek V3.2-Exp 官方说明。