真实面经题目 · 原创解析
这题考的是稀疏注意力在推理引擎里的真实性能取舍。dense mask 在数学上能表达稀疏模式，但计算和访存仍接近 dense attention；而稀疏索引或稀疏块能让 kernel 只读取和计算被选中的 KV cache，从而节省显存带宽、减少无效 FLOPs，并更适合 vLLM 这类分页 KV 和 Triton 块级并行实现。
我会先区分“逻辑上 mask 掉”和“物理上不算”。dense mask 的做法是在完整 QK 矩阵或完整 token 范围上计算，然后把不需要的位置加上负无穷或置零。它容易实现，也方便复用 dense attention kernel，但问题是 GPU 仍然读取大量 K/V、做大量 QK 计算、产生或隐式处理完整 score 区域，显存带宽和算力并没有真正按稀疏比例下降。KV Cache sparse 计算的目标通常是只关注部分历史 token，例如局部窗口、重要 token、检索选中的 token 或固定稀疏模式，所以更自然的实现是维护稀疏索引或稀疏块：索引记录每个 query 需要访问哪些 token 或哪些 KV block，kernel 只 gather 这些 K/V 并计算对应 attention；块级稀疏则把 token 按 block 组织，适配 paged KV cache、连续内存访问和 Triton 的 block program。相比逐 token 索引，稀疏块牺牲一点精细度，但内存访问更规整、并行粒度更好、元数据更少，也更容易和 vLLM 的 block table 对齐。取舍是：dense mask 简单稳定但省不了核心成本；稀疏索引更精确但 gather 和元数据开销大；稀疏块更适合 GPU 吞吐但可能多算块内无用 token。工程上要用端到端指标验证，包括 TTFT、decode latency、带宽、occupancy、block 命中率、稀疏率、精度损失和不同序列长度下的拐点。
dense mask 可以表达哪些 token 不参与 attention，但很多实现仍然按完整长度读取 K/V、计算 QK score，并在 softmax 前应用 mask。这样数学结果是稀疏的，物理执行却接近 dense。对于长上下文 decode，真正瓶颈往往是 KV cache 读取和 attention 访存，dense mask 很难把成本按有效 token 数降下来。
稀疏索引会记录每个 query 或每个请求需要访问的历史 token 位置，例如最近窗口、重要 token、检索命中 token 或压缩策略保留 token。kernel 根据索引 gather K/V，只计算这些位置的 score 和加权求和。它的优势是精细、节省无效计算；代价是索引元数据、非连续访存和 gather 开销。
vLLM 这类推理引擎常把 KV cache 按 block/page 管理，请求的逻辑 token 映射到物理块。块级稀疏直接选择要访问的 KV block，Triton kernel 可以按 block 做并行和内存加载，访问更规整，metadata 更小，也更容易复用 block table。缺点是块内可能包含少量不需要的 token，会多算一点。
Triton kernel 通常以 program/block 为基本并行单元，适合处理规则 tile。稀疏块可以让每个 program 处理一个或多个选中 KV block，加载 K/V 时更容易 coalescing，并控制 shared SRAM 或寄存器使用。逐 token 稀疏虽然更精确，但索引分散会造成内存访问不连续、warp 分歧和调度开销。
稀疏 attention 不是只把几个 K/V 加起来，还要在选中集合上做数值稳定的 softmax。块级或分段计算时，需要维护每个 query 的 max、sum exp 和累积输出，确保跨多个稀疏块的归一化正确。dense mask 复用成熟 softmax 简单一些，而稀疏 kernel 要自己保证数值稳定和边界处理。
稀疏实现只有在跳过的 K/V 足够多时才划算。如果上下文不长、稀疏率不高、索引很碎，gather、metadata、kernel launch 和分支开销可能抵消收益。长上下文 decode、注意力集中在少量块、或 KV 读取成为瓶颈时，稀疏索引和稀疏块才更容易胜过 dense mask。
选择哪些 token 或 block 本身会影响模型质量。局部窗口、重 token、检索 token、sink token 或动态 top-k 策略都可能带来不同精度损失。工程评估不能只看 kernel benchmark，还要看困惑度、任务成功率、长上下文问答、召回依赖问题和生成稳定性。
vLLM/Triton 中的优化要放回调度器、paged KV、continuous batching 和不同 batch 形态下看。需要测 TTFT、decode token latency、吞吐、显存带宽、SM occupancy、KV block 命中率、索引构建成本和不同长度下的拐点。单个 kernel 更快不代表整个推理服务更快。
因为很多 dense attention kernel 仍然按完整序列加载 K/V、计算 score，再把不需要的位置 mask 掉。mask 改变的是结果参与 softmax 的逻辑，不一定改变底层的访存和矩阵计算量。
如果稀疏模式非常细粒度、保留 token 分散，索引更精确；如果希望 GPU 访存规整、metadata 少、和 paged KV 对齐，块更合适。实践中常按 block 选，再在块内做少量 mask，平衡效率和精度。
因为一个 block 里可能只有部分 token 真正需要，但为了连续加载和并行效率，会把整个块读入并计算。它用少量块内冗余换取更好的内存合并、并行粒度和更低索引开销。
不能对每个块单独 softmax 后简单相加，因为全局归一化会错。需要在所有选中 token 或 block 上维护全局 max 和 sum exp，分块累积输出时做数值稳定的在线 softmax。
短序列、稀疏率低、索引很碎、batch 很小、metadata 构建昂贵或 kernel 访存不合并时，稀疏的额外开销可能超过跳过计算的收益。此时成熟 dense kernel 加 mask 可能更快。
要同时做数值对齐和任务评测。数值上比较 dense baseline 与 sparse 输出差异；任务上看困惑度、长上下文问答、检索依赖问题、代码或推理样例和生成稳定性，并按不同稀疏率和上下文长度分桶分析。
