Substantial design overlap with LiteTopK: request for public acknowledgment and citation

# Substantial design overlap with LiteTopK: request for public acknowledgment and citation

Hi DeepSelect maintainers,

We are the authors of [LiteTopK](https://arxiv.org/abs/2607.11976v1). After reviewing DeepSelect’s implementation and algorithm documentation, we are concerned about the substantial overlap with the streaming threshold-filtering component of our earlier work, without a corresponding acknowledgment or citation.

The paper was submitted to arXiv on July 13, 2026, and its first version already linked to our [public implementation](https://github.com/Heisenberg-Yin/LiteTopK). DeepSelect’s [README](https://github.com/deepseek-ai/DeepSelect/blob/0f03b68748b304863fdf0181a11458d04ae533a9/README.md#L5-L8) dates its v1.0.0 release to September 10, 2026.

**We also contacted the DeepSeek team about LiteTopK in August 2026.** Despite this prior contact, the subsequently published DeepSelect deep-dive blog ([English](https://github.com/deepseek-ai/DeepSelect/blob/0f03b68748b304863fdf0181a11458d04ae533a9/docs/DeepSelect-deep-dive.md) / [Chinese](https://github.com/deepseek-ai/DeepSelect/blob/0f03b68748b304863fdf0181a11458d04ae533a9/docs/DeepSelect-deep-dive.zh.md)) does not mention or cite LiteTopK, while presenting DeepSelect as a new TopK algorithm. We ask that you address this omission in both the blog and the repository documentation.

**Before DeepSelect’s release, LiteTopK was already undergoing public review, integration, and adaptation across the inference ecosystem:**

- **vLLM:** Our [PR #48726](https://github.com/vllm-project/vllm/pull/48726), opened on July 15, 2026, introduced LiteTopK for upstream integration and has received substantive public review.
- **SGLang / Ant Group:** [PR #32094](https://github.com/sgl-project/sglang/pull/32094), opened on July 22 by [yuan-luo of Ant Group](https://github.com/yuan-luo), explicitly states that it is adapted from our vLLM PR and credits LiteTopK. The author also [confirmed adding Heisenberg-Yin as a co-author and marking the source](https://github.com/sgl-project/sglang/pull/32094#issuecomment-5133244904). This is a concrete example of another developer extending our implementation while preserving attribution.
- **Zhipu AI:** On July 23, Qinhua Sun, identifying himself as a member of Zhipu AI’s official GLM Infra team, [publicly reported experimenting with LiteTopK integration into SGLang](https://github.com/Heisenberg-Yin/LiteTopK/issues/2), observing promising results in GLM-5.2 inference and seeking further technical discussion with us.
- **AMD:** AMD contributor AMD-yanfeiwang submitted [ROCm/AITER FP4 LiteTopK PR #5309](https://github.com/ROCm/aiter/pull/5309) on September 7 and [FP8 LiteTopK PR #5348](https://github.com/ROCm/aiter/pull/5348) on September 8. Both explicitly cite our repository as the original implementation. The associated [SGLang integration PR #38303](https://github.com/sgl-project/sglang/pull/38303) also documents implementation and testing on AMD MI355X hardware.

These records show that developers from **vLLM, SGLang, Zhipu AI, AMD, and Ant Group had already engaged with LiteTopK and begun integration or adaptation work before DeepSelect’s public release**. The linked PRs document ongoing development and remain open as of September 11, 2026.

We made our code and paper publicly available and welcome DeepSeek directly using and building on our work. We also expect the relevant prior contributions to be clearly acknowledged.

The overlap we would like you to address is concrete:

1. **A sample–filter–select workflow, with an initial threshold derived from a subset of the input.** LiteTopK explicitly describes this framework in [Sections 3.1–3.2](https://arxiv.org/html/2607.11976v1#S3): use a sample to initialize a conservative threshold, filter candidates during processing, and perform exact selection on the reduced candidate set. DeepSelect’s actual implementation also has a distinct initialization stage: it first processes an [initial window of up to 32 KiB](https://github.com/deepseek-ai/DeepSelect/blob/0f03b68748b304863fdf0181a11458d04ae533a9/csrc/cuda_kernels/common_parts.cuh#L311-L323), comprising the tail and the first permuted segments, and [selects its initial top-k before scanning the remaining segments](https://github.com/deepseek-ai/DeepSelect/blob/0f03b68748b304863fdf0181a11458d04ae533a9/csrc/cuda_kernels/common_parts.cuh#L1133-L1136). It then [sets the filtering threshold from that initial selection](https://github.com/deepseek-ai/DeepSelect/blob/0f03b68748b304863fdf0181a11458d04ae533a9/csrc/cuda_kernels/common_parts.cuh#L1270-L1307). At the workflow level, this initial subset serves the sampling/bootstrap role, followed by filtering and repeated candidate selection. Our comparison concerns that shared structure; the two implementations choose and use their initial subsets differently.
2. **Filtering candidates during processing with a progressively tightened threshold.** LiteTopK describes this workflow in [Sections 3.1–3.2](https://arxiv.org/html/2607.11976v1#S3). Its implementation [refreshes a histogram-derived gate](https://github.com/Heisenberg-Yin/LiteTopK/blob/cd277d6773fd01635aed4596ca0eb4047f16032c/kernels/b200/dsa/sm100_dsa_litetopk.cuh#L1203-L1251) and [applies that gate as scores are produced](https://github.com/Heisenberg-Yin/LiteTopK/blob/cd277d6773fd01635aed4596ca0eb4047f16032c/kernels/b200/dsa/sm100_dsa_litetopk.cuh#L1463-L1485). DeepSelect likewise filters against a current threshold and [updates that threshold after candidate reconstruction](https://github.com/deepseek-ai/DeepSelect/blob/0f03b68748b304863fdf0181a11458d04ae533a9/csrc/cuda_kernels/common_parts.cuh#L1502-L1509).
3. **Retaining only promising candidates and concentrating selection work on the reduced set.** LiteTopK [stages passing candidates in shared memory](https://github.com/Heisenberg-Yin/LiteTopK/blob/cd277d6773fd01635aed4596ca0eb4047f16032c/kernels/b200/dsa/sm100_dsa_litetopk.cuh#L1523-L1559), with subsequent candidate emission and final selection. DeepSelect [stores threshold-passing candidates](https://github.com/deepseek-ai/DeepSelect/blob/0f03b68748b304863fdf0181a11458d04ae533a9/csrc/cuda_kernels/common_parts.cuh#L1395-L1488) and [reselects from retained and incoming candidates](https://github.com/deepseek-ai/DeepSelect/blob/0f03b68748b304863fdf0181a11458d04ae533a9/csrc/cuda_kernels/common_parts.cuh#L1320-L1375). The shared principle is to reduce candidate traffic and exact-selection work through online filtering.

In particular, the [algorithm documentation](https://github.com/deepseek-ai/DeepSelect/blob/0f03b68748b304863fdf0181a11458d04ae533a9/docs/DeepSelect-deep-dive.md#L3) introduces a “new TopK algorithm” without discussing LiteTopK.

We would kindly ask for:

1. **Clarify DeepSelect’s relationship to LiteTopK.** Please explain whether and how LiteTopK’s paper or code informed DeepSelect’s development, including any design influence, code reuse, or adaptation.

2. **Publicly acknowledge LiteTopK’s prior contributions.** Please add a clear acknowledgment in the README, crediting the original authors and linking to our paper and repository.

3. **Reflect the implementation’s origins in the kernel’s name.** Based on the similarities documented above, we believe the relevant TopK kernel is derived from or adapted from LiteTopK’s implementation. We therefore request that it be named and documented as a **LiteTopK-derived TopK kernel**, with the original authors and source clearly credited. If the relationship is limited to design influence without implementation reuse, please explain that distinction and explicitly acknowledge the influence in the kernel documentation.

4. **Update the English and Chinese deep-dive blog and algorithm documentation.** Please add a substantive discussion of LiteTopK as prior work, identify the shared ideas and implementation differences, and distinguish DeepSelect’s own contributions from those previously introduced by LiteTopK.

We would appreciate a response here and a visible update to the repository documentation. We welcome reuse and further development, and ask that the public record give LiteTopK appropriate credit.

Best,
Ziqi