00 EIGHTEEN LEDGERS
不要先问“哪个框架最快”，先问哪本账正在爆
同一个模型可以在离线批处理里吞吐极高，却在聊天服务中首字很慢；可以靠缓存服务 400K 代码前缀，也可能因为亲和路由把一台机器压成热点。只有把十八本账分开，系统名才有意义。
先理解 KV、MLA、KDA 和上下文状态。
PREREQUISITE / 08大规模训练系统并行、通信和 MoE 放置在推理端仍然存在。
PREREQUISITE / 09数值精度与稳定性量化节省的是哪类字节，要从数值格式开始。
请求形状
输入、输出、并发与复用到底长什么样？聊天、代码 Agent、离线批处理和 1M context 的最优系统不相同。
体验契约
用户在等首字，还是在等完整答案？TTFT、TPOT、E2E、deadline 与可用性要分别记录。
权重
模型本体怎样装进设备？精度、分片、复制、offload、专家放置与 runtime workspace。
增长状态
每多一个 Token，要多存什么？标准 KV、压缩 latent、线性注意力状态与混合缓存。
内存分配
空间够，为什么仍会 OOM？连续块、内部碎片、生命周期、共享与 copy-on-write。
预填充
长 prompt 怎样变成可复用状态？通常算力密集；长度、chunk、缓存命中与排队共同决定首字。
逐步生成
一个 Token 为什么也很贵？通常受权重与状态读带宽限制；batch 能摊权重，却增加竞争。
批处理
不同长度请求怎样同车？静态、连续、iteration-level 与 token-budget scheduling。
复用
哪些旧计算可以安全命中？前缀哈希、page 对齐、版本、租户隔离、淘汰与失效。
算子
理论 FLOPs 为何不是实测延迟？IO、融合、shape、量化布局、通信与硬件利用率。
推测
能否用便宜猜测减少串行步数？验收率、draft 成本、并行验证与回滚必须同账。
精度
少几个 bit 省在哪里，又伤在哪里？权重、激活、KV 与通信不是同一个量化对象。
并行
一份请求跨多少设备？TP、PP、DP、EP、CP 的通信、冗余与尾延迟不同。
专家
激活参数少，为何部署仍然难？所有权重仍需放置，路由造成 all-to-all、热点与小 batch GEMM。
网络
拆开阶段后，要搬多少状态？P/D 解耦、远端缓存和专家通信把网络变成一等资源。
路由
送到空闲实例，还是有缓存的实例？负载、缓存亲和、数据局部性与租户边界需要共同优化。
故障
缓存或 worker 消失时，状态还可信吗？pin、复制、原子失效、重算、降级和幂等必须定义。
经济
便宜究竟按什么分母？每 Token 成本之外还要看 SLO goodput、利用率、功耗与拒绝率。
推理服务是一间状态工厂：prefill 把 prompt 制造成可复用状态，decode 反复读取权重与状态产生下一个 Token，调度器则在 SLO 前提下决定谁先占用哪种资源。
先把单请求变得可预测
MQA · Clockwork减少增长状态；用可预测执行与集中调度替代黑盒式服务。
批处理进入 iteration 粒度
Orca · ZeRO-Inference · Petals请求完成即可补位；权重 offload 与分布式协作拓宽部署边界。
少走串行步数、少搬字节
Speculative Decoding · FlexGen · GPTQ · SmoothQuant推测、offload 与量化成为三条互补主线。
KV Cache 成为显式系统对象
vLLM · PagedAttention · SGLang · Prompt Cachepage、前缀树和结构化语言运行时把状态复用提升为核心抽象。
按阶段、上下文与 SLO 拆服务
Splitwise · DistServe · Sarathi · Mooncakeprefill、decode、缓存与网络开始独立扩容和调度。
Kernel、压缩与推测共同优化
FlashInfer · QServe · KVQuant · EAGLE-3性能来自算法、数据布局、精度和运行时的协同，不是单点技巧。
开放前沿模型反向定义系统
DeepSeek V2→V4 · Kimi K2→K3MLA/KDA、MoE、FP8/FP4、分离服务与混合状态缓存一起设计。
01 REQUEST STACK
用户看到一个回答，机房里经过七层
API 网关只负责把请求送进来。真正决定成本的是：怎样排队、是否命中前缀、由谁做 prefill、状态放在哪里、谁做 decode、每步调用哪些 kernel，以及流式输出能否按时送回。
鉴权、限流、模型 / 租户选择
失败不是 GPU 慢，而是入口排队。SLO、token budget、优先级
决定请求何时成为 active。前缀 hash、page、版本与租户
命中必须同时语义有效与状态可用。批量处理 prompt，生成状态
常见情形偏 compute-bound，但不是定律。HBM / DRAM / SSD / remote KV
容量、带宽、复制和失效都入账。逐步采样、draft、verify
常见情形偏 memory-bandwidth-bound。首字、字间与最终状态
用户体验由最慢分位数而非均值决定。线上延迟
用户满意
有效复用
单位 goodput 最便宜
02 METRICS
把“快”拆成五个彼此冲突的指标
Time To First Token
入口排队、cache lookup、prefill、首轮调度与网络返回之和。长 prompt 首先打在这里。
Time Per Output Token
流式输出相邻 Token 的间隔。decode 抖动会让回答“卡顿”。
End-to-End Latency
从请求进入到完整输出结束，受输出长度强烈影响。
Tokens / second
系统总产出；若大量请求违约，峰值吞吐依然可能很漂亮。
SLO-qualified throughput
同时满足 TTFT / TPOT 等约束的完成量，才可用于容量与成本决策。
餐厅一小时做 300 道菜是吞吐；其中 280 道在承诺时间内送到，才是 goodput。为了第 301 道菜让所有桌都迟到，不叫优化。
03 REQUEST CLOCK
一次生成包含两种完全不同的计算节奏
一次并行处理很多输入位置
- 矩阵更大，通常更容易吃满算力
- 长 prompt 延长 TTFT
- 产物是后续可复用的状态
- 可切成 chunk 与 decode 交错
每一步只有新位置，循环很多次
- 反复读取权重与历史状态
- batch 增大能摊权重读取
- TPOT 决定流式体验
- 推测解码试图减少串行轮数
“prefill 算力受限、decode 带宽受限”是常见硬件与 shape 下的工作区间，不是所有模型、batch、长度与 kernel 都成立的物理定律。
04 WEIGHT MEMORY
权重是进门票，不是全部显存
当模型跨卡时，还要选择复制还是分片。复制提高数据并行容量，却让每个副本承担全部权重； tensor parallel 分片矩阵，却在层内频繁通信；pipeline parallel 减少单卡权重，却引入阶段气泡和请求微批约束。
05 KV CACHE MATH
上下文不是抽象长度，它是一笔逐 Token 增长的字节债
请求数翻倍，状态近似翻倍
上下文翻倍，增长状态翻倍
每个注意力层各存一份
两组历史张量
MQA / GQA 直接减少此项
每个位置每个头的宽度
FP16=2，INT8=1，4-bit≈0.5
最常见的错误是只算一个请求，或把模型参数精度当成 KV 精度。W4 不自动等于 KV4； 量化权重后留下的空间，也可能很快被长上下文和高并发吃完。
06 STATE ARCHITECTURES
“KV Cache”已经不是一种统一形状
每个 Q 头一组 K/V
表达直接，增长状态最大；decode 需要读更多历史字节。
状态 ∝ Hq × T多个 Q 头共享 K/V
以更少 KV heads 换容量与带宽，成为服务友好设计。
状态 ∝ Hkv × T，Hkv ≪ Hq缓存低维 latent
通过低秩压缩与解耦 RoPE，避免保存完整每头 K/V。
仍随 T 增长，但每位置更小固定 recurrent state
线性注意力用门控 Delta Rule 更新有限状态；局部精确回忆仍需混合 MLA。
核心 recurrent state 不随 T 线性增长不能把 MLA 的 latent 或 KDA 的 recurrent matrix 硬塞进标准 Hkv 公式并称为精确值。先确认状态对象，再谈字节。
07 PAGEDATTENTION
vLLM 的关键不是“少算注意力”，而是让状态不必连续居住
为最大长度预留、不同寿命请求离开后留下洞；连续扩容困难。
逻辑 block 映射到非连续物理 page；前缀可引用共享 page，写入时 copy-on-write。
请求每增长一个 block 才取新 page，不必按最大长度预留。
请求结束可逐 page 回收，避免必须寻找大连续区域。
并行采样和共同前缀可以引用同一物理 page。
PagedAttention 解决的是内存管理和共享，不会降低 Transformer 本身的理论 FLOPs； “近零浪费”也不等于绝对零，最后一个 block 仍有内部碎片，page table 和 kernel 也有开销。
08 PREFILL
长 prompt 是一项可排队、可缓存、可切片的生产任务
长度、模态与 padding 决定实际输入。
每层同时处理大量位置，通常更容易利用算力。
状态写入 HBM 或缓存层，供 decode 和后续请求读取。
首字延迟不是单纯的 prefill kernel 时间：请求可能在 admission、batch 形成、cache lookup、 page 分配与队列中停留。长 prompt 若一次占满调度迭代，还会让已经在流式输出的请求停止前进。
09 DECODE
每次只写一个新 Token，却要反复搬动整个模型与历史
batch 内请求共同摊一次矩阵权重访问。
attention 访问此前 K/V 或其他 recurrent state。
logits、约束、采样与停止条件。
decode 的“算术强度”常较低：每个新位置对应的计算量有限，却需读大量字节。增加 batch 可以提升权重重用，但 batch 过大又会增加排队、KV 容量和 TPOT。系统优化目标因此是一个带 SLO 的工作点，而非无限扩大 batch。
10 CONTINUOUS BATCHING
静态 batch 等最慢者；连续 batch 在每一步补位
整批一起开始，一起结束
短请求完成后留下空槽，直到最长请求结束。
每次 decode 迭代重新组批
完成即补新请求，显著提高 slot 利用率；调度开销和公平性仍需管理。
continuous batching 不是把所有请求简单堆在一起。一个服务迭代可能包含 decode token、 新请求 prefill、被抢占请求恢复和 cache transfer；真正的调度单位越来越接近“token budget + 状态资源”。
11 CHUNKED PREFILL
把 128K prompt 切开，给流式请求留出呼吸
Sarathi-Serve 的核心直觉是把大 prefill 切成 chunk，与 decode 组合成更均匀的迭代。 chunk 太大仍会 stall，太小则增加调度和 kernel 开销；它改善阶段干扰，不保证所有 workload 都降低 TTFT。
12 KERNELS
算法写下 FLOPs，kernel 决定字节怎么走
定义数学工作与可利用结构。
决定能否连续访问、复用和向量化。
融合操作，安排 warp、共享内存与异步流水。
为不同长度和并发选择实际实现。
最终受容量、带宽、指令和拓扑约束。
FlashMLA · DeepGEMM · DeepEP
分别覆盖 MLA attention、低精度 GEMM 与 MoE dispatch/combine。开源 kernel 让“模型架构如何要求系统实现”变得可检查，而不只是论文里的吞吐数字。
13 PREFIX CACHE
命中不是一个布尔值，而是一段有效状态的证明
模型 / adapter / tokenizer / 精度 / 内容 hash / 租户。
到底命中多少有效 Token，不是“有相似 prompt”。
page 在哪台 worker、哪层内存，搬运是否比重算便宜。
版本、过期、故障、写入和 copy-on-write 的原子语义。
缓存节省 prefill compute，却消耗容量、索引、网络与路由自由度。SGLang 的 RadixAttention、Prompt Cache、Hydragen、ChunkAttention、Preble 分别从程序结构、共享计算和分布式调度推进这条主线。
14 PREFILL / DECODE DISAGGREGATION
把两种节奏拆开扩容，但必须付状态搬运费
长 prompt、宽矩阵、cache creation
持续小步、batch、streaming SLO
Splitwise 把 prompt 与 token generation 放到适配的机器；DistServe 以 goodput 与独立扩容为中心； Mooncake 更进一步把 KVCache 作为存算分离系统的中心。拆分消除资源干扰，却新增 KV transfer、跨池排队和故障协调。
15 QUANTIZATION
“4-bit 模型”至少漏掉三本精度账
Weights
GPTQ · AWQ · weight-only省权重容量和读取；是否加速取决于反量化融合与低精度 GEMM。
Activations
SmoothQuant · W8A8 · FP8离群值、累加精度和校准影响 tensor core 路径。
Growing state
KVQuant · KIVI · QServe长上下文直接获益；key/value、近期 / 远期状态可采用不同策略。
Communication
dispatch · cache transfer量化网络载荷可能省带宽，却增加转换和误差边界。
DeepSeek-V3 将 FP8 训练 / 推理和 MLA、MoE 一起设计；K3 从 SFT 进入 MXFP4/MXFP8 QAT， 并保持非专家模块更高精度。QAT 是让模型适应目标数值路径，不等于所有层都用同一格式。
16 SPECULATIVE DECODING
目标模型一次验多步，减少最昂贵的串行轮数
小模型、额外 heads、feature predictor、检索或自推测产生候选。
目标模型并行计算候选位置，并按算法逐项验收。
提交被接受前缀，再从目标分布纠正；状态必须可回滚。
Vanilla speculative sampling 用独立小模型；Medusa 在主模型上加多步 heads；EAGLE 在 feature 层预测，EAGLE-2 动态构树，EAGLE-3 融合多层特征。速度取决于验收率、草稿成本、验证 shape 和状态回滚，草稿越长并不总越快。
17 PARALLELISM
放不下是一类问题，放得下但通信太多是另一类
完整副本服务不同请求。扩吞吐自然，但每份权重都占容量。
层内矩阵跨卡，减少单卡权重；每层都有 collective。
不同层跨阶段，降低单卡容量；气泡和逐 Token 流水复杂。
MoE 专家跨设备，激活按路由 all-to-all。
长序列状态或计算跨设备，交换边界与聚合结果。
服务并行还要考虑请求级容错：TP 组中一张卡失败可能使整个 replica 失效；DP 副本则较易摘除。最少 GPU 数、最优 GPU 数和可容错 GPU 数不是同一个答案。
18 MOE INFERENCE
激活参数少，不等于只需要存激活专家
全部专家仍需放在 GPU、主存或分层存储中。
Token dispatch / combine 带来 all-to-all 与拓扑敏感性。
输入分布让少数专家拥挤；均值负载掩盖尾部。
单专家 batch 过小，理论低 FLOPs 仍可能 memory-bound。
DeepSeek-V3 的部署报告把 prefill 与 decode 设成完全不同的 EP 规模，并使用冗余专家；DeepEP 则为 dispatch / combine 提供高吞吐与低延迟路径。模型路由和网络拓扑必须共同设计。
19 SCHEDULING & SLO
调度器不是把 GPU 塞满，而是在过载时决定谁不被伤害
平均并发阈值看不见请求长度：1 个 1M 请求和 1 个 1K 请求都被计为“1”。 token-budget admission 将预期 prefill、KV 和 decode 工作纳入预算；过载时拒绝或延后长任务，可能提高短请求 goodput。
保护短请求、优先付费租户、保证老请求不饿死、为长 Agent 保留配额，都是不同策略；不能只用系统吞吐替用户做决定。
20 FLEET & FAILURE
单机优化完成后，路由、热点和故障成为主问题
减少排队，却可能放弃已有 400K 前缀。
避免 prefill，却可能把热门 repo 挤到单点。
多副本增加成本；不复制则故障时重算和违约。
Llumnix 通过请求迁移重平衡实例；Preble 联合考虑前缀复用与负载；Mooncake / MemServe 把状态放进独立缓存层。真实系统还必须定义 pin、复制中读写、版本升级、原子失效和 secondary re-prefill。
21 DEEPSEEK LINEAGE
DeepSeek 的低成本服务不是一项技巧，而是四代共同设计
MLA + DeepSeekMoE
从模型结构上减少每 Token KV 和激活计算。
STATE ARCHITECTUREFP8 + system co-design
训练、MoE 路由、专家通信与 P/D 部署一起设计。
FULL STACKSparse attention
长上下文继续压缩 attention 工作，服务与推理训练协同。
LONG CONTEXTHeterogeneous state
CSA / HCA / SWA 把增长状态按功能与介质分层。
STATE HIERARCHY架构降成本 × 数值降字节 × kernel 提利用率 × 服务分阶段
只复制 MLA 或只换 FP8，都不等于复制 DeepSeek 的整体经济性。
22 DEEPSEEK V2 → V3
先压每 Token 状态，再把 MoE 推理摊到两种集群
低秩 latent 代替完整每头 K/V
把增长缓存从“每个 KV 头的完整向量”压缩成共享 latent，并把 RoPE 部分解耦。
细粒度专家与 shared experts
总容量增加而每 Token 只激活部分专家；服务端承担专家放置与通信。
FP8 与累加控制
减少权重、激活与通信字节，并以配方和 kernel 守住稳定性。
无 auxiliary-loss 负载均衡
模型训练中的路由平衡直接影响线上专家热点与硬件利用率。
TP4 · SP / DP8 · EP32 · 32 redundant experts
TP4 · SP / DP80 · EP320；单专家 batch 通常 ≤256，偏 memory-bound
23 DEEPSEEK V3.2 → V4
从压缩 KV 走到异构状态缓存
只选择与当前 query 相关的一部分历史。
用不同粒度保留全局记忆与可检索摘要。
为局部精确依赖保留有限窗口。
冷状态可下沉，容量变大但访问和失败路径更复杂。
这些是报告内特定配置的估算比例，不是任意工作负载的端到端延迟或成本倍数。磁盘缓存将容量收益换成 IO、预取与尾延迟风险。
V4 还报告了组件级 FP4 selector：特定选择器实验中 2× 加速、99.7% recall。它描述一个组件，不应写成“V4 整体 2× 且精度 99.7%”。
24 KIMI LINEAGE
Kimi 的主线是把超长 Agent 历史变成可管理的状态系统
KVCache-centric
prefill、decode 与缓存池分离，围绕长上下文复用组织系统。
DISAGGREGATIONAgentic workload
长工具轨迹与代码前缀让缓存、调度和稳定流式输出更重要。
WORKLOADKDA state
以 Gated Delta Rule 形成固定 recurrent state，降低长度增长债。
ARCHITECTUREHybrid serving
KDA + Gated MLA、page cache、speculation、affinity 与 admission 联动。
FULL STACK25 MOONCAKE
把 KVCache 从 GPU 附属品提升为分布式基础设施
生成 KV，并写入分布式缓存。
以带宽、容量和热度管理状态。
读取状态并持续生成。
两者分母和条件不同，不能合并成“Mooncake 普遍 5.25×”。论文的核心贡献是体系结构与调度方法，不是一个脱离 workload 的营销倍数。
26 K3 HYBRID STATE CACHE
69 个 KDA 固定状态，与 24 个 MLA 增长缓存一起管理
KDA 用固定 recurrent state 处理远距离历史，MLA 保留随上下文增长的精确注意力缓存。 因为两者生命周期与回滚语义不同，K3 不能只复用传统 KV page manager。
报告示例中的物理管理粒度。
更细粒度索引内容匹配。
内容匹配长度不自动等于有效状态长度。
按 hash block 对齐后可安全复用的示例。
报告还定义并发 pin、copy 与原子 invalidation：复制中不能回收源页，失效后不能继续向路由器宣称命中。这里的难点是分布式状态一致性，不只是 hash 查表。
27 K3 SPECULATION & ADMISSION
草稿、回滚、缓存亲和与预算准入共同守住长 Agent
MTP → EAGLE-3 style
预训练 MTP 初始化 draft；feature fusion 读取第 1、第 4 和最终 AttnRes，训练时展开 7 步。
Loss with acceptance mass
LLK = −log Σ min(p, q) 直接鼓励草稿分布与目标分布重叠。
Replay accepted state
KDA 不为每条草稿复制完整 recurrent state；缓存投影输入，按被接受前缀重放更新。
Affinity + budget
优先路由到已有状态的实例，同时用 token budget 防止超长任务淹没短请求。
缓存价值来自迭代式 Agent 反复使用巨型 repo 状态；如果路由丢失亲和性，就会为很小增量重复付出巨大 prefill。
K3 的 QAT 从 SFT 阶段进入 MXFP4 / MXFP8，非专家模块保留更高精度。这里再次说明：模型架构、draft、数值路径、cache manager 与 admission policy 是一套系统，而非五个独立“加速插件”。
28 INTERACTIVE LAB
现在让系统亲手失败一次
四个实验分别管理容量、阶段干扰、串行轮数与集群状态。先使用默认 K3 / 长上下文场景，再故意把每项推到失败区。
INTERACTIVE / SERVING CONTROL ROOM
别只背系统名：亲手管四本推理账
每个实验都公开公式、假设与证据边界。它们是可复算的教学模型，不是 GPU benchmark，也不会把论文中的特定集群结果外推成普遍性能。
80 GB 到底装了什么？
先付权重，再付随请求增长的状态；分页只能减少浪费，不能让真实 KV 消失。
KVBytes = B × T × L × 2 × Hkv × Dh × bytes“2”来自 K 与 V。MLA / KDA 的状态结构不同，必须另立口径，不能只改一个名字。
未计 scale、元数据与 runtime workspace
单请求每新增一个位置
指定上下文长度的增长状态
权重 + 全部活动请求 KV
能装下，但还没给 kernel workspace 留余量
这里只有最后一个 block 的内部浪费；PagedAttention 还会改善非连续分配与共享。
选 K3 会切换为“增长状态等效估算”，同时保留固定 KDA 状态未公开的边界。
首字慢，和字间慢，不是同一种慢
观察调度策略怎样改变 TTFT、TPOT、吞吐与 goodput；均为相对教学模拟。
一次处理许多 prompt Token；长输入会推迟第一次输出。
每步只生成少量 Token，却反复读取权重与历史状态。
排队 + prefill + 调度
相邻输出 Token 间隔
完成的 output tokens/s
同时满足 TTFT / TPOT SLO
—
最优策略会随工作负载和网络变化，不存在脱离 SLO 的单一冠军。
以静态批为归一化基线，展示方向性取舍。
草稿越长，为什么可能反而越慢？
速度取决于验收率、草稿成本和并行验证成本；“一次猜七步”不是免费得到七个 Token。
E[tokens] = 1 + a + … + aᵏ精确采样算法使用目标分布与草稿分布的重叠质量；独立常数 a 只是帮助建立直觉。
一次 target verification 的期望产出
相对逐 Token target 解码
算过但未被接受的候选
低验收率会把草稿计算变成纯开销
K3 的 KDA rollback 会缓存投影输入并重放已接受状态；这里没有把回滚成本假装成零。
缓存命中以后，系统问题才刚开始
亲和路由提高复用，却可能制造热点；预算准入保护短请求，却会主动拒绝一部分长请求。
命中缓存而无需重新计算的 Token
亲和性收益对应的热点代价
admitted / rejected per 100
—
故障时不能把已失效 page 当成命中；需要原子失效后重新 prefill。
这里的命中率、负载和准入曲线是教学模型，不是 K3 线上集群披露值。
29 AUDIT CHECKLIST
看到任何“吞吐提升 X 倍”，先跑完这十四问
prompt / output 长度分布、并发、突发、前缀复用和租户隔离是否来自真实 trace？
TTFT、TPOT、E2E、deadline、可用性和拒绝率是否分别定义了分位数？
报告的是峰值吞吐、完成吞吐，还是满足 SLO 的 goodput？
参数量、精度、scale / metadata、workspace、复制和 offload 是否都入账？
MHA/GQA/MLA/KDA 的状态公式、精度、page 与回滚口径是否明确？
静态 / 连续 batch、token budget、chunk、抢占和 fairness 如何交互？
key、page 边界、版本、命中有效长度、淘汰、租户隔离与失效怎样定义？
P/D 分离后的 KV 传输字节、网络、放置、重试和失效成本是否入账？
W/A/KV/通信分别多少 bit？校准、QAT、fallback 与任务退化怎样测？
草稿长度、验收率、draft / verify / rollback 成本和分布正确性是否同时披露？
总权重放置、激活专家、all-to-all、热点、冗余专家与小 batch GEMM 是否入账？
worker、缓存、网络和路由故障下，是重试、重算、降级还是拒绝？状态是否原子失效？
硬件、软件版本、精度、模型、请求分布、SLO 与功耗是否相同？
作者报告值、教学估算、内部线上数与可复现实测是否用不同标签？
保留硬件、模型、工作负载、SLO 和分母，不跨场景外推。
公开脚本、commit、环境与误差，才可作为可比较证据。
公开公式与假设，用于量纲推理，不冒充 benchmark。
↳ PRIMARY-SOURCE CHAIN
62 个节点：从 MQA 到 Kimi K3
每个链接都指向论文、会议页或官方实现。历史顺序用于建立因果脉络，不代表后出的系统在所有工作负载上都更优。
让多个 query heads 共享 K/V，直接减少 decode 状态读取。
模型内张量并行成为超大 Transformer 推理放置的基础坐标。
以可预测执行、集中调度和模型缓存控制服务延迟。
分片状态的思想延伸到超大模型训练与服务。
把稀疏专家推理的并行、通信与延迟作为联合问题。
用 IO-aware tiling 减少 HBM 往返，而不是近似注意力。
把巨量权重从 GPU 卸载并以带宽感知方式分层取用。
iteration-level scheduling 与 selective batching 形成连续批处理主线。
跨互联网协作服务大模型，展示异构和不可靠网络边界。
混合精度处理 outlier，让超大模型 8-bit 推理更稳健。
逐层二阶近似的 post-training weight quantization。
把激活离群难度迁移到权重，实现 W8A8。
用便宜草稿与目标模型验收，保持目标分布不变。
独立建立保分布的推测采样与验收机制。
把统计复用与模型并行放置用于突发式服务。
GPU、CPU、磁盘三层 offload 与线性规划式策略搜索。
以抢占和跳级队列降低 autoregressive 服务尾延迟。
树状草稿与并行验证拓展推测解码。
保护少量显著权重的激活感知 weight-only 量化。
以 heavy-hitter oracle 选择性保留 KV。
改善 work partitioning，减少非矩阵乘法开销。
把 KV Cache 分页，支持近零外部碎片与共享。
用 attention sinks 保持有限缓存下的流式长序列。
压缩 KV 的网络传输以加速上下文加载。
用模块化 prompt schema 复用中间状态。
从检索到的历史 n-gram 构造免训练草稿。
拆分 prompt 与 token generation 阶段，按资源特征放置。
RadixAttention 与结构化生成运行时复用共享前缀。
以 goodput 为目标分离 prefill / decode 并独立扩容。
在目标模型上增加多步预测 heads，减少独立 draft 开销。
在 feature 层自回归预测并结合 token，提高草稿准确率。
按通道 key、按 token value 与 outlier 分离量化 KV。
真实服务 trace 揭示突发、长度与模型混合的工作负载。
非对称 2-bit KV 量化并保留近期 residual。
用 Jacobi 迭代并行发现、验证 n-gram，无需 draft model。
共享前缀请求分解注意力，提升跨序列复用。
以前缀树组织 KV chunk 并共享计算。
chunked prefill 与 stall-free batching 缓和阶段干扰。
训练早退层作为自推测草稿，并由后续层验证。
从 observation window 选择重要位置压缩长 prompt KV。
MLA 将增长 KV 压到 latent 表示，DeepSeekMoE 降低激活计算。
W4A8KV4 与硬件友好 kernel 的联合推理系统。
融合独立缓存的文本块，并选择性重算跨块依赖。
按层分配递减 KV 预算。
跨实例实时迁移请求以重平衡和避障。
以 page 级查询感知稀疏选择减少长上下文 decode 读量。
用上下文置信度动态调整草稿树。
把分离 KV 缓存池与弹性服务连接成存算分离架构。
提前预测关键 KV 并从 CPU 选择性加载。
在分布式 prompt 服务中联合前缀复用与负载。
以 KVCache-centric disaggregated architecture 服务长上下文。
面向 Hopper 异步、低精度与 warp specialization 优化 attention。
FP8、MLA、MoE 与无损负载均衡共同改变部署形状。
为多形态 LLM serving 提供可组合 attention / sampling kernel。
直接预测 token，并融合低中高层特征增强草稿。
DeepSeek 官方 MoE dispatch / combine 通信库。
DeepSeek 官方 FP8 / low-precision GEMM kernel 库。
DeepSeek 官方面向 MLA decode / prefill 的高效 kernel。
KDA 以门控 Delta Rule 形成固定大小 recurrent state。
稀疏注意力、长上下文与推理训练继续压低服务成本。
CSA/HCA/SWA 与异构状态缓存把上下文状态进一步分层。
69 KDA + 24 Gated MLA、page cache、EAGLE-3 draft 与预算准入联合设计。