已关闭
[Requirement|需求建议]: 新增TurboQuant4bit算子 #4391
shenxiaolong188创建于 7月28日关闭于 8月11日
7月28日 将 yolic 设为负责人
yuning_chen
7月28日 评论：
7月28日 评论：
收到需求建议，欢迎您参加 ops-nn sig 例会评审并申报相关议题，最近的例会议题申报及会议时间可见：https://etherpad-cann.meeting.osinfra.cn/p/sig-ops-nn
7月28日 添加了label：wait-feedback
7月29日 将 shenxiaolong188 设为负责人
liubo75
7月30日 评论：
7月30日 评论：
需求上最好能明确下TurboQuant 算法里面实现的融合算子是包括哪些计算的，标注下计算公式。
另外看这里描述没有A5环境，为啥前面有吞吐提升的实际性能，这种性能数据是通过什么方式获取采集的也帮忙补充说明下。
Cchen-weipeng12
8月4日 关联了pull request：[WIP]feat(TurboQuantCompressLatent): 新增MLA KV latent的TurboQuant 4bit压缩算子AscendC实现
8月4日 关联了pull request：[WIP]feat(TurboQuantCompressLatent): 新增MLA KV latent的TurboQuant 4bit压缩算子AscendC实现
CANN-robot
8月6日 评论：
8月6日 评论：
您好，为了更准确地定位和解决问题，我们需要您提供上述提到的相关信息。如果 14 天内没有进一步更新，我们将暂时关闭此 Issue。感谢您的理解与配合。
8月11日 关闭了 issue
8月11日 添加了label：resolved
Thanks for sending an requirement! Please fill in the following template to help quickly solve your problem.
Backgroud（背景信息）
1）背景：
针对客户在AI Coding等场景下，对GLM5.1高并发、长序列的需求启动了相关的难题攻关；TurboQuant 是 Google ICLR2026 提出、专门针对 LLM 动态 KV Cache 的向量量化压缩算法，核心解决长上下文推理显存爆炸问题，已成为VLLM的标配；我们系统分析了TurboQuant 4bit算法的原理，开发了相关的昇腾融合算子，并基于A2做了性能精度测试，TQ 4-bit 压缩腾出 KV 显存，换得更高并发与聚合吞吐。
2）测试结果：
端到端收益（GLM5.1 W4A8 8卡A2），精度无损（与KV BF16比）的情况下，减少2.19倍KV cache显存占用，TTFT提速1.41倍，吞吐增加77%，并发翻倍（1→2）， 输出吞吐 +26%（20.61→25.97 tok/s），支持GLM5.2 A3单机16卡 1M 2并发。
3）关键事项澄清：
目前无A5环境，未做相关测评，未来可以基于TQ压缩以及其他量化压缩方法，辅助产品线提升产品竞争力；rope和 indexer的kv cache进行量化，当前是4bit量化，没有尝试3bit 2bit量化，后续可以继续研究；
Origin（信息来源）
南航、美的、移动等多个客户在AI coding等场景下，都提出了对长序列高并发的支持。
Benefit / Necessity （价值/作用）
满足多个客户在AI coding、合同审核、标书文档等长序列高并发的场景需求
Design（设计方案）