权重能共享，上下文状态仍要付成本
本页问题
KV 本体估算为 M=2LTh_KVd_headb。指定配置每 token 为 128 KiB，8192 个已缓存 token 为 1 GiB，八份互不共享的同长请求为 8 GiB。长输入、长输出与并发分别增加不同工作，容量、首 token 等待和逐 token 延迟应分开判断。
RC-V2/b0 · 指定配置，再说每token成本
给缓存计量之前，先把配置说清：三十二层、每层八组 K/V、每组一百二十八维，BF16 每数两个字节。每个 token 要保存 K 与 V 两份，乘上层数、组数、维度和字节数，得到一百二十八 KiB。这个量来自指定配置，不是所有八十亿参数模型的固定规格。
教师备课：指图与模拟问答
指图与推进 · 不朗读指规格行与128KiB/token，分别指K/V两份和存储精度。
本态来源与条件
指定配置的教学算例：32 层、8 KV 组、128 维、BF16；二进制 KiB / GiB
RC-V2/b1 · 长度和独立请求进入账本
如果输入与已经进入缓存的生成部分合计八千一百九十二 token，KV 本体约一 GiB；八个不共享上下文的同长请求就是八 GiB。权重可以共用一份，当前状态却各自对应不同请求。这里用二进制 KiB/GiB，和前面训练账本的十进制 GB 分开。
教师备课：指图与模拟问答
指图与推进 · 不朗读指8192→1GiB，再指共享权重与8份独立KV。
本态来源与条件
指定配置的教学算例：32 层、8 KV 组、128 维、BF16；二进制 KiB / GiB
RC-V2/b2 · 把慢拆成三个问题
所以要把“慢”拆开。长输入增加 prefill 计算与历史状态；长输出增加顺序 decode 轮次，并继续增长 KV；高并发还叠加排队与容量压力。同一请求可能同时遇到几种压力，先定位增加了哪类工作。执行安排帮助计算完成，却没有给原 A/B 记录补出任何新测量。
进一步解释
深入材料按作用对象分组：分页改变 KV 物理分配；精确前缀共享减少兼容的重复状态与计算；连续批在生成轮间接纳请求；prefill/decode 分离分别配置阶段资源并支付状态交接成本。这些不是每个请求必经的顺序技术栈。
教师备课：指图与模拟问答
指图与推进 · 不朗读指长输入、长输出、并发三列，分别对照prefill、decode和容量/排队。
本态来源与条件
指定配置的教学算例：32 层、8 KV 组、128 维、BF16；二进制 KiB / GiB
接下来
系统帮助执行，却不能补出未测事实。
补充推导、边界与来源
进一步阅读
条件与来源
以下从计算对象、条件与原始证据继续展开。
原 N54：一个请求的当前记忆，可以占到多少空间？
本课指定教学配置为 L=32 层、每层 h_KV=8 组、每组维度 d_head=128，每数 BF16 占 b=2 bytes。KV 的常用存储估算为 $M_{KV}=2LTh_{KV}d_{head}b$，T 是已经进入缓存的输入与生成 token 总长度。首项 2 表示 K 与 V 两份，最后的 b 表示每数存储字节。
每 token：2×32×8×128×2=131072 bytes=128 KiB。8192 token：1073741824 bytes=1 GiB；32768 token=4 GiB。8 个互不共享、各长 8192 token 的请求共需 8 GiB KV。权重可以共享，当前上下文状态不能任意合并。
KiB=2¹⁰ bytes，GiB=2³⁰ bytes；与训练账本的十进制 GB 分开。GQA 是这种减少实际 KV 头/组数的一类架构安排，但本配置不是所有 8B 模型的固定规格。
原 KV 容量页 · 完整服务主题 · PagedAttention §2。
原 N55：逻辑上连续，物理上可以按块长出来
把逻辑序列按 B 个 token 一块组织，长度 T 需 ceil(T/B) 个块。图示 B=4、T=6，因此用两块：逻辑0保存1–4，逻辑1保存5–6，末块空2槽。生成到7、8时补满第二块；第9个需要第三块，末块空3槽。
块表把逻辑0、1、2分别映射到物理7、1、5；读写按逻辑顺序定位，物理块无需连续。它不改变 token 的因果顺序，也不是完全零浪费；尾块仍有内部空余。请求完成可以释放独占块，共享块须检查引用计数；写入共享尾块时，具体实现还需写时复制等安排。
PagedAttention/vLLM 在请求缓存的分配与访问层面工作，FlashAttention 在注意力算子的中间量存取层面工作，两者可以配合。
原分页图与说明 · 服务主题 · PagedAttention §4.3 / Fig.6，物理 p6。
原 N56：相同前缀，可以接出两条不同的后续
按 N54 的128 KiB/token配置，两个请求各含4096 token共同前缀与2048 token独立尾部。未共享时两份6144 token共12288 token，即1.5 GiB；共享一份前缀后总量4096+2×2048=8192 token，即1 GiB。
精确前缀复用要求同模型、相同 token 序列和兼容的位置及计算条件。文本含义相似不保证 K/V 相同；前文或前缀某个 token 改变后，从改变位置起的后续状态需要重新判断，不能把全段旧缓存当作可原样复用。共同前缀之前未改变且条件兼容的部分仍可独立核对。
两个尾部各有自己的状态和生成路径。共享节省重复 KV，也可能省重复 prefill，但不表示两条请求的全部计算合并。旧材料中的三请求2.25→1.25 GiB是另一构造，与原 N56 材料两请求1.5→1 GiB分开。
前缀匹配与 RadixAttention / SGLang · 服务主题 · PagedAttention §4.4，物理 p7–8。
原 N57：A 已经答完，C 为什么还在等待？
R_A、R_B、R_C 是服务请求标识，与实验方案A/B无关。三个请求需要的生成轮数分别为2、4、2，且为隔离接纳规则，假设入场 prefill 已完成；每轮可安排两个示意生成槽。
固定整批策略：前两轮R_A/R_B并行，R_A结束后其独占状态可释放，但R_C要等R_B整批结束，所以第3/4轮一个槽空闲，第5/6轮R_C才生成。图中的槽表示调度机会，不是GPU为每请求永久划定的物理位置。
没有给每轮规定相同实测毫秒，也没有测量GPU吞吐，因此不能直接将轮数作硬件加速比。
原批处理演示 · PagedAttention §2.3，物理 p3。
原 N58：每轮接纳新请求，把空出来的机会用上
连续批处理在生成轮次间调整活跃请求集合。此例保持N57的请求长度不变：前两轮R_A/R_B共同执行，R_A完成后第三轮R_C补入，R_B不中断；第四轮R_B/R_C均完成。总生成工作量不变，R_C比固定整批少等两轮。
六轮变四轮是调度构造，不是实测1.5倍GPU加速。真实轮耗时受活跃批量、输入处理、内存访问、算子及设备影响。新请求接纳还需要prefill准备、KV容量、延迟目标满足条件，不能只看是否有空格。
评估实际系统时区分排队时间、首token延迟、逐token延迟与吞吐；提高吞吐的安排可能增加个别请求等待。
原调度页 · 完整服务正文 · PagedAttention §2.3 / §4.5。
原 N59：输入很长、输出很长、人很多，是三种不同压力
长输入、长输出与高并发不是同一个问题。长输入增加prefill计算与状态；长输出增加顺序decode轮次并持续增长KV；高并发叠加排队、批次安排和容量压力。
在同设备上，大块prefill工作可能干扰正在decode的请求。P/D分离把两类阶段安排到不同资源，prefill结束后交接K/V等必要状态，decode继续产生输出。它允许分别配置与调度资源，也增加状态传输、模型驻留和协调成本，效果依赖输入/输出分布、请求量、设备及互联。不能因图被分成两栏就断言更快。
首token等待与后续逐token延迟应同时考察。Dynamo、LMCache、Mooncake等组件按实际职责在既有正文展开，不组成每次请求必须依次安装的技术栈。
本页证据与条件
指定配置的教学算例：32 层、8 KV 组、128 维、BF16；二进制 KiB / GiB