
![image.png](https://developer.qcloudimg.com/http-save/yehe-9261324/0d1b59e43e4db790387f86df413c45ba.png)
----

## 一、64K Token的丛林战


老李最近被一个问题折磨了三个月：

公司正在把核心客服系统升级成AI驱动——接入DeepSeek-V3做长文档理解，合同审核、工单溯源、会议纪要摘取，

场景一个比一个"长"。

结果上线后，P99延迟爆了。日志一拉，GPU利用率正常，卡在哪儿？

**卡在Attention的索引阶段。**

老李盯着火焰图，发现每一层Transformer推理，都要对所有历史Token做一次全量扫描来决定"关注谁"。输入8K还好，到了64K，这个索引开销直接把推理链路压成了线性瓶颈。

这不是老李一个人的问题。这是**整个行业在长上下文赛道上撞到的同一堵墙**。


----

## 二、敌情分析：现有稀疏注意力的阿喀琉斯之踵


>"知己知彼，百战不殆。"——孙子兵法


### DSA（DeepSeek Sparse Attention）的设计逻辑


DeepSeek提出的DSA是目前工程落地最广的稀疏注意力方案。

它的核心思路是：**不是所有Token都值得关注，只算top-k个最相关的**。

用一个轻量Indexer给每个Query对全部历史Key打分，选出高分子集，再只在这个子集上做完整Attention计算。

Sparse Attention本身的计算量是可控的。

**但Indexer本身是O(n)的**——每一层、每一个Query，都要扫一遍整个前缀序列。

```
上下文长度  →  Indexer开销
8K         →  可接受
32K        →  开始吃力
64K+       →  成为瓶颈
128K       →  灾难
```
这就是老李日志里看到的真相：Sparse Attention没救到他，

因为**索引器本身就是那只拖后腿的脚**。


----

## 三、HISA：先派侦察兵，再出精锐部队


>"善战者，求之于势，不责于人。"


![image.png](https://developer.qcloudimg.com/http-save/yehe-9261324/ac9bf2411e81c228162980d56aca3fb5.png)

——孙子兵法HISA（Hierarchical Indexed Sparse Attention）的设计哲学极其朴素：

**用两次小代价换掉一次大代价**。


**第一段：侦察兵（Block-Level Coarse Filtering）**
把历史序列按固定窗口切成若干Block，对每个Block做池化得到一个代表向量，快速打分，直接砍掉大量不相关区域。不求精确，只求快速排除。

**第二段：精锐（Token-Level Refinement）**
仅在通过初筛的候选Block内，才运行原有的token级Indexer精确选取top-k Token。

关键结论：**最终输出的稀疏模式与DSA完全一致**，下游Sparse MLA算子无感知，不需要重新训练。


----

## 四、用数字说话：HISA的价值几何？


>"数之所生，物之所成也。"——管子


论文在DeepSeek-V3.2和GLM-5上的实测结果：


|对比维度|DSA（基线）|Block-Sparse|HISA|
|:-:|:-:|:-:|:-:|
|64K上下文索引速度|1×|2-3×（精度损失明显）|**2-4×**|
|精度保持（NIAH）|基准|显著下降|**几乎持平**|
|需要重新训练|—|否|**否**|
|替换成本|—|高（模式不同）|**即插即用**|

对老李的业务翻译成人话：


- 同样64K合同文本，推理延迟从800ms降到约250ms

- P99从超时边缘拉回到正常SLA

- 不用重新做昂贵的微调，存量模型直接受益


----


## 五、这个技术用在哪个环节？主流大模型适配情况


>"工欲善其事，必先利其器。"——论语


![image.png](https://developer.qcloudimg.com/http-save/yehe-9261324/48cf213b75f6c96fcced1a991ec1d255.png)


**三大主流模型的适配情况**：

![image.png](https://developer.qcloudimg.com/http-save/yehe-9261324/86d7d7ce097606c0b1bfb6fbd5a84679.png)

HISA的作用位置是**每层Transformer的Attention索引阶段**，不改变权重，不改变输出格式，对上下游完全透明。对于Claude、GPT-4o这类MHA架构，若开放Indexer替换接口，同样可以引入类似分层思路——核心理念是通用的。


----

## 六、洞见三条：对架构师真正有用的


>"博学之，审问之，慎思之，明辨之，笃行之。"——中庸


**洞见一：瓶颈永远在你没注意到的地方**

当所有人都在优化Attention计算本身（FlashAttention、MLA、GQA……），HISA的团队发现真正的瓶颈其实是Indexer这个"配角"。老李的问题也一样——GPU不是瓶颈，索引逻辑才是。**架构优化的第一步不是加速，而是找对目标**。在AI规约编程大行其道、人人都在堆算力的今天，这个教训尤其珍贵。

**洞见二："两段式过滤"是一种通用模式**

先粗筛再精排，这个模式出现在：搜索引擎（召回→排序）、数据库查询优化器（统计信息裁剪→精确执行）、推荐系统（粗排→精排）。HISA只是把这个模式带进了Transformer的内部。**凡是O(n)扫描的地方，问一下：能不能先做一个O(n/k)的粗筛？** 这是可以直接复用到你系统里的思维框架。

**洞见三：即插即用才是工程价值的分水岭**

学术界有太多"需要重新训练才能用"的好方案，但工程上几乎没人落地。HISA能在不改变训练的前提下直接替换，是它最核心的工程价值。**在AI系统设计上，"zero-shot可替换"的组件才有生命力**——这对做AI中间件、AI平台的架构师来说，是一条硬标准。


----

## 七、对架构师的两个真正可落地的启发


>"纸上得来终觉浅，绝知此事要躬行。"——陆游


### 启发一：给你的AI推理链路加一层"分层索引代理"


无论你接的是DeepSeek还是其他大模型API，64K以上的长文本场景，在调用前先做一层**分段相关性预筛选**：把文档切成chunk，先用轻量embedding模型（如BGE-M3）做块级粗筛，再把高分chunk送入大模型做精读。这是HISA思想的工程近似实现，不需要动模型本身，今天就能做。

![image.png](https://developer.qcloudimg.com/http-save/yehe-9261324/6778587182008016149105b2a3ac4547.png)

**预期收益**：在RAG类场景，大模型实际处理的Token量减少60-80%，成本和延迟同步下降。

### 启发二：把"索引瓶颈分析"纳入你的AI系统性能基线


下次AI系统上线前，老李式的问题可以提前规避。建立基线：分别测4K/16K/32K/64K下，**Indexer/Retriever阶段**占整体推理时延的比例。一旦超过30%，就是预警信号。用HISA的思路（分层过滤）或工程近似（分段召回）优先治这个环节，而不是盲目扩GPU。


|上下文长度|Indexer占比预警线|建议动作|
|:-:|:-:|:-:|
|≤16K|<10%|正常|
|32K|10-25%|观察|
|64K|>30%|立即优化|
|128K+|>50%|架构重构|


----

## 八、行动号召：别等论文落地，今天就能干的三件事


>"天下难事，必作于易；天下大事，必作于细。"——老子


老李读完这篇论文，当晚就拉了个小组。他说："这不是学术玩具，这是我们线上问题的答案。"

**方法论总结**：
![image.png](https://developer.qcloudimg.com/http-save/yehe-9261324/4cc947677e685a462e053f13a5fea408.png)

**今天就能干的三件事**：


1. **测一下**：在你的AI系统里，把64K输入的各阶段耗时打出来，找Indexer/Retriever的占比

2. **试一下**：在RAG管道里加一层轻量粗筛（用embedding相似度做块级过滤），对比前后延迟

3. **看一下**：关注DeepSeek-V3后续版本，HISA极有可能进入官方支持，第一时间评估升级价值





公司正在把核心客服系统升级成AI驱动——接入DeepSeek-V3做长文档理解，合同审核、工单溯源、会议纪要摘取，

HISA长文本推理优化思考

我们不缺算力，我们缺的是对瓶颈的敬畏。

架构师

人工智能

架构设计

算法

HISA分层索引技术突破64K上下文处理瓶颈，显著降低AI推理延迟。采用先粗筛再精排策略，在不改变模型权重前提下实现2-4倍加速，尤其适合合同审核、工单溯源等长文本场景。该技术已适配主流大模型，即插即用无需重新训练，为AI系统性能优化提供新思路。

中间件

数据库

4核4G3M云服务器 新用户低至38元/年！

2026采购季 | AI焕新·智启新局

message-queue-catalog

tencentdb-catalog

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

HISA长文本推理优化思考-腾讯云开发者社区-腾讯云

HISA长文本推理优化思考

HISA长文本推理优化思考

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐