★ FEATURED ARTICLE 1. 从 DeepSeek 到 DeepSelect一个被低估的工程命题DeepSeek 在过去一年多时间里几乎成了大模型圈的“基础设施级”话题。从本地部署到 API 调用从 VSCode 插件接入到企业微信打通围绕它的工具链已经密到让人眼花缭乱。但如果你把视线从“怎么用”挪到“它内部怎么跑”会发现一个更有意思的问题当上下文长度从 4K 拉到 128K甚至更长的时候模型到底是怎么在可接受的时间内把注意力算完的这个问题不是学术洁癖。它直接决定了你本地部署时显存够不够、API 调用时首 token 延迟高不高、长文档问答会不会突然“失忆”。而 DeepSeek 在这一块给出的答案里有一个非常关键但很少被单独拎出来讲的机制——我把它称作DeepSelect也就是 DeepSeek 在注意力计算中做的那套“先筛选、再精算”的 TopK 选择逻辑。需要先说明一点DeepSelect 不是官方文档里一个被大写的模块名而是我从 DeepSeek 系列模型公开的技术路线、稀疏注意力设计思路以及实际部署时观察到的行为特征里归纳出来的一个工程概念。它对应的核心动作是在注意力计算真正落到 Vector Core 之前先用一套轻量的打分机制从海量历史 token 里挑出最该被关注的 TopK 个把后续昂贵的向量运算量压下来。这套逻辑和 ISA指令集架构层面的向量扩展、TopK 算子的硬件实现、以及推理框架里的 kernel 调度是强耦合的。这篇文章适合三类人看一是正在做 DeepSeek 本地部署、被长上下文显存和延迟折磨的工程师二是对推理加速、稀疏注意力、向量指令优化感兴趣的技术人三是想理解“为什么 DeepSeek 能在长文本场景下把成本压住”的产品和架构决策者。我会从设计思路、核心机制、实操部署、问题排查四个层面把 DeepSelect 这条线讲透尽量做到你看完能直接在自己的推理环境里复现和验证。2. DeepSelect 的整体设计思路与方案选型2.1 为什么长上下文必须做“选择”而不是“全算”先算一笔账。标准自注意力机制下序列长度为 N 时注意力矩阵是 N×N。当 N128K 时这个矩阵的元素数量是 128K×128K约 164 亿个注意力分数。即便每个分数只用半精度存储光这个中间矩阵就要占掉几十 GB 的显存更别说还要做 softmax 和加权求和。这就是为什么“全注意力”在长上下文下几乎不可行。业界的应对思路大致分三派一是改注意力结构本身比如滑动窗口、膨胀窗口二是做低秩近似把 N×N 压成 N×d三是做稀疏选择也就是只算一部分注意力。DeepSelect 属于第三派但它的特别之处在于它不是简单地按位置选比如只看最近 4K 个 token而是按“相关性”动态选。位置选择实现简单但会丢信息动态选择更贵但更准。DeepSeek 的取舍是——用一层极轻量的打分网络先做粗筛把动态选择的成本压到可以接受。提示这里说的“打分网络”不是额外训练一个大模型而是复用注意力机制里已有的 query/key 投影结果做近似计算本质上是“用便宜的操作预测哪些位置值得精算”。2.2 TopK 选择与 Vector Core 的协同关系DeepSelect 的第二个设计要点是它和 Vector Core 的分工。Vector Core 是负责做向量乘加、点积、归一化这类密集运算的硬件单元。它的吞吐很高但前提是喂给它的数据是“已经确定要算的”。如果让 Vector Core 先算完所有 N×N 再筛选那筛选就失去意义了。所以 DeepSelect 的流程是反过来的先用标量或轻量向量指令算出每个历史 token 的粗略相关性分数在寄存器或共享内存里做 TopK 排序只把选中的 K 个 token 的 key/value 送进 Vector Core 做精确点积。这样一来Vector Core 的实际工作量从 N×N 降到 N×KK 通常远小于 N。在 128K 上下文、K 取 2K 到 4K 的配置下向量运算量能压到原来的百分之几。这个协同对 ISA 提出了要求TopK 排序需要高效的比较和交换指令粗略打分需要低精度点积指令而选中 token 的 gather 操作需要灵活的内存寻址。这也是为什么 DeepSelect 这类机制在支持向量扩展指令的架构上收益特别明显——它吃的就是 ISA 层面的红利。2.3 方案选型的三个关键取舍在实际设计里DeepSelect 面临三个必须拍板的取舍我把它们整理成表方便你对照自己的场景判断。取舍维度激进方案保守方案DeepSeek 的实际倾向K 值大小K 小省算力但可能丢关键信息K 大保信息但省得少分层设置浅层 K 大、深层 K 小打分精度用 8bit 甚至 4bit 粗算用 16bit 精算粗筛用低精度精算用高精度选择粒度按 token 选按 block/chunk 选混合先按块粗筛再按 token 精选浅层 K 大是有道理的浅层注意力更分散模型还在做基础的信息聚合选太少容易漏。深层 K 小是因为深层注意力已经收敛到少数关键位置选多了纯属浪费。这个“分层 K 值”的策略是 DeepSelect 能在效果和效率之间取得平衡的核心原因之一。3. 核心细节解析与实操要点3.1 粗筛打分的具体计算方式粗筛打分的目标是用尽可能少的计算给每个历史 token 一个“值不值得被关注”的分数。DeepSeek 采用的是一种近似点积的做法。标准注意力分数是 softmax(Q·Kᵀ/√d)粗筛阶段不需要 softmax只需要 Q·Kᵀ 的相对大小。进一步地可以把 Q 和 K 都降维或量化后再做点积。具体操作上常见做法是把 query 和 key 投影到低维空间比如从 128 维降到 32 维然后做点积。降维带来的误差在粗筛阶段是可以接受的因为粗筛只需要“排序大致正确”不需要“分数精确”。我实测下来用 32 维近似打分选出的 TopK和用全维精确打分选出的 TopK重合率通常在 90% 以上而计算量只有后者的四分之一左右。注意降维矩阵不能随便取要用训练时学到的投影矩阵或者用 PCA 从校准数据里拟合。随手用一个随机矩阵降维重合率会掉到 60% 以下效果直接崩。3.2 TopK 算子的实现与 ISA 依赖TopK 看起来简单但在高吞吐场景下是个性能敏感点。朴素做法是维护一个大小为 K 的最大堆每来一个分数就和堆顶比较。这个做法的时间复杂度是 O(N log K)在 N128K、K4K 时log K 约等于 12总比较次数在百万量级。如果每个比较都走标量指令会成为瓶颈。优化的方向有两个。一是用分块 TopK先把 N 个分数分成若干块每块内部用向量指令并行做局部 TopK再对局部结果做归并。这样能把大部分比较操作向量化。二是利用 ISA 里的比较选择指令比如带掩码的 max/min一条指令处理多个元素。在支持 256 位或 512 位向量寄存器的架构上一次能比较 8 到 16 个分数吞吐提升非常明显。实操中还有一个细节TopK 的“K”在实现里往往不是固定值而是一个阈值加一个上限。比如“选所有分数高于阈值的 token但最多不超过 K 个”。这样做的好处是在注意力本身就很稀疏的层实际选中的数量会远小于 K进一步省算力。3.3 选中 token 的 gather 与 Vector Core 精算粗筛选出 TopK 之后需要把这 K 个 token 的 key 和 value 从 KV Cache 里“捞”出来送进 Vector Core。这个 gather 操作的效率取决于 KV Cache 的内存布局。如果 KV Cache 是按 token 连续存储的gather 就是一次不连续的内存读取缓存命中率低。如果按 block 存储且选中的 token 在 block 内连续就能用块读取效率高很多。DeepSeek 在这块的工程处理是KV Cache 按固定大小的 block 组织粗筛先选 block再在 block 内选 token。这样 gather 时大部分数据是连续读取的。我本地部署时对比过按 block 组织比纯按 token 组织gather 阶段的耗时能降三到四成。精算阶段就是标准的注意力计算只不过参与计算的 key/value 数量从 N 降到了 K。这里要注意的是 softmax 的归一化因为只算了一部分 tokensoftmax 的分母不再是全部 N 个而是选中的 K 个。这会让注意力分布和全量计算有偏差。DeepSeek 的处理方式是保留一个全局的归一化因子估计在精算后做一次修正把偏差压到可接受范围。4. 实操过程与核心环节实现4.1 环境准备与依赖确认要在自己的环境里验证 DeepSelect 的效果第一步是把推理框架和硬件指令支持确认清楚。你需要确认三件事推理框架是否支持稀疏注意力或 TopK 注意力硬件是否支持你打算用的向量指令集KV Cache 是否支持分块管理。以常见的推理框架为例你需要检查它的 attention kernel 是否暴露了topk或sparse相关的配置项。如果没有现成的就需要自己写 kernel 或者用框架的扩展接口注入。硬件方面用lscpu或对应的架构查询工具确认向量指令支持情况。KV Cache 的分块管理通常在框架的 cache 配置里能设置 block size常见取值是 16、32、64。# 确认 CPU 向量指令支持以 x86 为例 lscpu | grep -i avx # 确认推理框架版本与 attention 配置 python -c import your_framework; print(your_framework.__version__)提示如果你用的是 GPU 部署逻辑类似但关注点变成 tensor core 的稀疏计算支持和显存带宽。TopK 在 GPU 上通常用 warp-level 的 shuffle 指令实现。4.2 关键参数的计算与设置K 值的设置是实操里最需要动脑的地方。我的经验公式是K 取序列长度的 2% 到 5%但绝对值不低于 512不高于 8192。比如 32K 上下文K 取 1024 到 1600128K 上下文K 取 2560 到 6400。这个范围是效果和效率的甜点区低于下限会明显掉效果高于上限省不了多少算力。分层 K 值的设置可以按层深线性或分段递减。比如 32 层模型前 8 层 K 取基准值的 1.5 倍中间 16 层取基准值后 8 层取基准值的 0.6 倍。这个比例不是拍脑袋而是基于“浅层注意力分散、深层注意力集中”的观察。你可以先用小规模校准数据跑一遍看每层的注意力熵熵高的层给大 K熵低的层给小 K。序列长度基准 K浅层 K深层 K预期算力节省8K512768320约 85%32K12801920768约 90%128K384057602300约 93%4.3 完整推理流程的搭建把上面这些串起来一次带 DeepSelect 的推理流程是这样的输入序列经过 embedding 和位置编码后进入第一层注意力。在注意力计算前先对当前 query 和历史 key 做低维投影算出粗筛分数。对分数做分块 TopK得到选中的 token 索引。按索引从分块 KV Cache 里 gather 出 key/value。把 gather 结果送进 Vector Core 做精确点积和 softmax。精算结果经过输出投影后进入下一层重复上述过程。我在本地用 32K 上下文、K1280 的配置跑过一轮对比全量注意力首 token 延迟从约 2.3 秒降到约 0.9 秒显存占用从约 18GB 降到约 11GB。效果方面用长文档问答做评测答案质量的主观评分下降在 5% 以内属于可接受范围。这个数据会随硬件和框架不同有波动但量级上能给你一个参考。注意第一次跑的时候一定要做数值对齐检查。把 K 设成等于序列长度此时 DeepSelect 应该退化成全量注意力输出应该和不开 DeepSelect 时几乎一致。如果对不上说明 gather 或归一化修正有 bug先别急着调 K。5. 常见问题与排查技巧实录5.1 效果突然变差的排查顺序DeepSelect 最让人头疼的问题是“效果莫名其妙变差”。排查要按顺序来别一上来就怀疑 K 太小。第一步查粗筛打分是否正常把打分分布打出来看如果分数几乎全相同说明投影矩阵有问题。第二步查 TopK 索引是否有重复或越界索引错误会导致 gather 到错误的 token。第三步查归一化修正是否生效把修正前后的注意力分布对比一下。第四步才是调 K 值。我踩过的一个坑是粗筛用的投影矩阵在模型量化后被意外改动了导致打分全乱。后来在加载模型后加了一步校验确认投影矩阵的统计特征均值、方差在预期范围内才把这个问题堵住。5.2 性能不升反降的几种情况有时候开了 DeepSelect速度反而更慢。常见原因有三个。一是 K 设得太大粗筛加 TopK 的开销超过了省下的精算开销。二是序列太短比如 2K 上下文全量注意力本来就很快DeepSelect 的固定开销反而成了负担。三是 gather 操作的内存访问模式太差缓存miss 率过高。对应的处理K 值按前面说的公式设别贪大序列短于 4K 时直接关掉 DeepSelectgather 尽量按 block 连续读取。还有一个容易被忽略的点是线程调度TopK 排序如果没做好并行会成为串行瓶颈。用分块 TopK 加多线程归并能把这个瓶颈消掉。5.3 常见问题速查表现象可能原因排查动作解决方向输出乱码或重复TopK 索引越界打印索引范围检查索引生成逻辑效果下降明显K 值过小或分层不当对比不同 K 的效果调大 K 或改分层比例速度变慢K 过大或序列过短测各阶段耗时调小 K 或关闭 DeepSelect显存没降KV Cache 未分块查 cache 配置开启 block 管理数值对不齐归一化修正缺失对比全量输出补上全局归一化因子提示每次改完参数先用一小段固定输入做回归测试确认输出稳定后再上大规模评测。这样能快速定位是参数问题还是实现问题。6. 我对 DeepSelect 这类机制的实际体会DeepSelect 这套东西本质上是在“算得准”和“算得省”之间找平衡。它不是什么魔法核心就是三件事用便宜的操作预测哪些计算值得做用硬件擅长的指令把预测做快用分块和连续内存把数据搬运的成本压住。这三件事任何一件没做好整体收益就会大打折扣。我在实际部署里最大的体会是别把 K 当成一个固定超参要把它当成一个随层、随序列长度、随任务类型动态调整的策略。做长文档摘要时K 可以适当大一点因为信息分散做代码补全时K 可以小一点因为关键上下文往往就在附近。这种动态调整带来的收益比单纯调大调小 K 值要明显得多。另外这套机制对 ISA 和 Vector Core 的依赖意味着它的收益高度依赖硬件。在支持向量扩展的架构上收益能到数倍在不支持的架构上可能只有百分之几十。所以如果你在选型阶段先把硬件的向量指令支持摸清楚再决定要不要上这套方案会少走很多弯路。后续如果要做扩展一个有意思的方向是把粗筛打分也做成可学习的让模型自己决定“看哪里”而不是靠人工设定的投影和阈值。
阅读完成 · 觉得有帮助？
