登录注册

资源 / 技术指南

让每个结论都带着依据。

发布评测、做技术选型或交接部署前，用这份清单核对材料。勾选仅帮助当前页面自查，不代表系统自动验证。

勾选状态仅保留在当前页面，刷新后重置；不会上传。

实验身份与输入

读者应能够识别是哪一次实验，而不是只有一个漂亮的结论。

记录数据来源、版本、筛选范围、采样限制与重复任务处理；区分业务数据和公开基准。

保存来源划分或哈希划分日志，并注明相关参数。采用来源划分时，不将未生效的哈希参数描述为实际划分。

记录 pool fingerprint、checkpoint_id、编码器版本、Stage 1 的训练权重 λ；非零时保留 flat_row_rate。

比较与结论

一条“更好”的结论应同时说明比谁好、按什么衡量、哪些条件下成立。

写明参考策略，区分 oracle 等边界；核对模型使用分布，避免把单模型选择包装成多模型路由收益。

在差异旁保留置信区间、符号检验和正确性阈值。区间跨零时说明无法区分；不删除失败切片。

写明成本来源与计费范围，保留成本前沿和未定义值。不把离线质量结果扩展为延迟、容量或跨领域承诺。

计时与可复现材料

测量值只有和测量边界放在一起才有意义。

记录实际加载设备、精度、输入长度、候选数、预热及采样方式；分开冷启动、完整决策和模型生成。

保留原始 JSON、Markdown 与成本扫描文件，使用报告格式化工具，避免重新输入数字或丢失边界标记。

提供命令、环境版本、输入准备方法与报告位置；明确哪些步骤访问网络，哪些步骤会调用计费供应商。

从评测转向部署时

这是另一组验收条件，不能用离线评测替代。

确定访问权限、密钥轮换、监控、备份恢复、升级回退和运维责任；把验证记录随配置一起交接。

按约定任务验证质量、并发、延迟、失败和预算行为；未测试的功能与环境保留为待验证范围。

继续阅读

回到评测方法与证据

4ROUTER / 系统研究

交付前的系统检查

把算子、KV 容量和缓存复用列入交付清单，避免把论文里的机制直接写成平台承诺。

NOTE / 01GEMM / KERNELS

从算子到服务：cuBLAS 与 cuDNN

先识别限制执行的资源，再选择算子实现。

模型的一次前向传播会被拆成矩阵乘、归一化、激活、数据重排与通信。优化的对象不是一个笼统的“GPU 利用率”，而是给定形状、精度和内存布局下的执行路径。本笔记连接库级选择、Roofline 分析与服务级验证。

FIG. 01GEMM / KERNELS
分块矩阵乘与结果累加示意图，未表示实测比例或具体引擎布局。

GEMM 的形状是问题的一部分

线性投影可以表示为 Y = XW。批内参与计算的 token 数会改变矩阵的行维度，因而 prefill 与 decode 不应只用同一组大矩阵测试代替。cuBLAS 提供 BLAS 运算；cuBLASLt 进一步暴露矩阵布局、计算类型、算法候选和 workspace 等选择。评估候选算法时，需要把调优开销与重复执行的收益分开记录。 [1]

融合改变数据移动，不只改变调用次数

cuDNN 的图接口可以表达运算及其依赖，由执行计划选择受支持的实现；SDPA 属于可融合的典型路径。减少中间张量写回可能降低显存流量，但一个融合算子能否使用，还取决于精度、mask、张量形状、布局和具体版本。不能把“使用 cuDNN”当作整个推理框架自动融合的证据。 [2]

用 Roofline 提出可检验的瓶颈假设

算术强度用 FLOPs 除以移动的字节数描述。低强度路径可能先受内存带宽限制，大矩阵路径可能接近计算限制；启动开销、同步和通信则可能落在这个简化模型之外。因此，先测单算子，再看时间线上的空隙，最后验证完整请求。峰值 FLOPs 不是服务吞吐的预测值。 [3]

模型与记号

P ≤ min(P_peak, BW × I) I = FLOPs / bytes

P 是可达运算速率，BW 是对应内存层级的带宽，I 是该层级的算术强度。它是性能上界模型；没有包含排队、通信和调度。

如何设计实验

  1. 固定输入契约

    记录 M/N/K、批量、精度、转置、stride、对齐和 workspace。选择来自真实模型的形状，而不只挑选整齐的大矩阵。

  2. 分别测量执行与正确性

    使用设备侧计时并明确同步边界，预热后记录分布；与参考实现比较误差，同时检查异常值和边界形状。

  3. 回到完整服务

    保持模型与流量相同，检查端到端延迟、吞吐、峰值显存和错误率。若单算子收益没有传递到服务，检查调度与数据搬运。

参考文献

  1. NVIDIA · cuBLAS / cuBLASLt documentation
  2. NVIDIA · cuDNN graph API
  3. NVIDIA · Matrix multiplication performance
NOTE / 02ATTENTION / MEMORY

FlashAttention 与 PagedAttention：不同层的内存问题

一个优化读写路径，一个组织持久状态。

Attention 的数学表达、算子的显存访问以及 KV cache 的分配是三个不同层次。FlashAttention 关注计算时的数据移动；PagedAttention 让随序列增长的 KV 状态按块寻址。理解二者的边界，比把它们当作互相替代的开关更重要。

FIG. 01ATTENTION / MEMORY

逻辑 token 块

A₀A₁A₂A₃
A₁B₀A₀A₃B₁A₂

物理 KV 块

物理 KV 块示意图，未表示实测比例或具体引擎布局。

FlashAttention：避免物化完整中间矩阵

标准 attention 可以写成 softmax(QKᵀ / √d + M)V。直接实现可能把很大的注意力中间量写回 HBM。FlashAttention 采用分块与在线 softmax，将局部计算留在更快的片上存储中，减少 HBM 读写；它在数学上计算精确 attention，而不是通过稀疏近似删除注意力连接。浮点计算仍需检查数值容差。 [1]

PagedAttention：逻辑连续，物理分块

生成过程中的序列长度会变化。为每条序列预留一整段最大长度空间会浪费容量；PagedAttention 用块表将逻辑 token 块映射到物理 KV 块，attention kernel 按映射访问。共享状态还需要引用管理和写时复制等机制。分页降低分配与复制浪费，并不消除 KV 数据本身。 [2]

兼容组合需要落到后端实现

Flash-style 分块与 paged KV 寻址可以在实现中结合；cuDNN 的 SDPA 文档也列出了 paged attention 的支持条件。但具体后端是否支持某种 head dimension、精度、mask 或 GQA 布局，需要逐项核对。算法名称相同，不等于每条运行路径与每个版本都相同。 [3]

模型与记号

O = softmax(QKᵀ / √d + M)V

Q、K、V 是查询、键和值；d 是每个查询/键头的维度，M 表示 mask 或加性偏置。分页改变存储寻址；分块改变执行顺序与数据移动。

如何设计实验

  1. 分开两个消融维度

    比较 attention 后端时保持缓存分配策略不变；比较分页策略时保持模型、输入分布与内核条件一致。

  2. 观察容量与吞吐的联系

    记录实际分配块、尾块占用、可容纳请求与抢占；再测相同延迟约束下的有效吞吐，避免只报告空闲显存。

  3. 保留正确性与边界测试

    覆盖不同序列长度、非整块尾部、共享前缀与长输出。保留基准输出对照及峰值显存。

参考文献

  1. Dao et al. · FlashAttention · arXiv:2205.14135
  2. Kwon et al. · PagedAttention · arXiv:2309.06180
  3. NVIDIA · cuDNN SDPA support matrix
  4. vLLM · Paged attention kernel design
NOTE / 05TIERS / TRANSFER

LMCache：把 KV 状态放进存储层级

少算一次 prefill，要先付一次状态访问的成本。

当可复用上下文超过 GPU 常驻容量，问题从“有没有缓存”变成“缓存在哪里、何时搬运、是否值得搬运”。LMCache 为推理引擎提供 KV 存储与传输连接，将复用扩展到 CPU、磁盘和远端层级。它改变的是状态的生命周期和位置。

FIG. 01TIERS / TRANSFER
TIER 00GPU · HBM
TIER 01CPU · DRAM
TIER 02NVMe / Remote
状态按层存储，按需载入示意图，未表示实测比例或具体引擎布局。

连接器与存储层分工

推理引擎负责模型执行；LMCache 的连接与存储组件负责 KV 的存取和移动。分层架构允许把较冷状态放到容量更大的层级，但从存储命中到 GPU 可使用之间仍有搬运路径。集成版本、块粒度和数据布局会影响这个边界，不能只按后端名称判断兼容。 [1]

复用是否划算取决于临界点

一次命中需要查找、读取、传输以及必要的布局转换。当这些开销小于重新 prefill 的代价时，复用才有单请求收益。异步预取可能隐藏部分开销，但会占用带宽和缓冲区。应测有效传输带宽与排队，不能把链路标称速率直接代入服务承诺。 [2]

上下文复用与 P/D 分离不是同一目标

上下文缓存跨请求保存已有状态；prefill/decode 分离则把同一请求的两个阶段放在不同执行实例，中间需要传递 KV。二者可以组合，但成功缓存历史前缀并不证明跨实例传输或故障恢复已验证。每条传输路径都应有命中、未命中、超时和回退的可观测记录。 [2]

模型与记号

T_lookup + T_read + T_transfer + T_reformat < T_prefill_saved

这是不考虑重叠时的复用判据，不是吞吐预测。并发传输会竞争带宽；采用流水线时，应测量关键路径而不是机械相加。

如何设计实验

  1. 分别测试各缓存状态

    区分 GPU 热、CPU 热、磁盘热、远端热与完全冷的请求。记录模型、序列长度、缓存层级、命中字节与重算范围。

  2. 把数据移动放进 trace

    记录查找、读入、设备搬运和等待时间，并观察 pinned memory、NUMA、PCIe 或网络竞争；同时保留 TTFT。

  3. 验证失败回退与清理

    模拟对象缺失、容量耗尽、后端不可达和版本不兼容，验证重算或明确失败；制定租户隔离、保留与删除策略。

参考文献

  1. LMCache · Versioned architecture overview
  2. LMCache technical report · arXiv:2510.09665
  3. LMCache · Current documentation and integration guidance

机制图为原创示意；公式用于解释或容量建模。论文与官方文档中的结果不等同于 4Router 实测。