已学完
💡 一句话解释： 传统方式是公交车必须等全车所有人都到站才开下一趟；连续批处理是有人到站马上下车、新人立刻上车！
# 传统静态 Batch 满篇 Padding 气泡 | vLLM 每次 step() 动态纳新与回收完成序列
烦恼：短句子全在陪长句子发呆
一人没走完，全车陪着等
办法：下车一个立刻补位一个，零等待
走一个进一个，永远不空座
解决了什么：在每个 Token 解码迭代级别调度请求，消灭所有静态 Padding 气泡，吞吐翻数倍。
代价是什么：每步都必须重新动态拼装 Batch 索引，对调度器开销与算子设计要求极高。
已学完
💡 一句话解释： 借鉴操作系统的虚拟内存：不要预留整条长显存，而是切成一个个 16-Token 的物理小格子，按需拼积木！
# 逻辑块到物理块映射：block_size=16, free_block_queue 双向链表管理
Logical Block 0,1,2 ➔ Block Table ➔ Physical GPU Pages [7, 42, 105]
烦恼：预先占满整条显存，大量浪费
盲猜最大长度，显存全虚耗
办法：页表映射，满 16 个字才领一个新块
物理页零碎拼装，严丝合缝
解决了什么：彻底消灭无法预估序列长度带来的内部显存碎片，并发容量直接提升 2~4 倍。
代价是什么：需要定制 GPU 核心算子（FlashAttention / Paged Kernel），无法直接用标准 PyTorch 连续张量。
已学完
💡 一句话解释： 当所有人都在疯长把显存挤爆时，调度器会暂时把倒霉的低优先级任务“请下台”腾空间，等有空再重算它！
# 显存块不足时：V1 采用 Recompute Preemption 释放低优先级 KV 块并重置回 WAITING
烦恼：所有人都不停，瞬间一同 OOM 崩溃
盲目硬抢，整船人一起沉
办法：请后排先回休息室，腾出显存
有序避让，大局永远稳健
解决了什么：在突发极限并发下通过主动驱逐低优先级任务，彻底免疫显存耗尽导致的服务器进程崩溃。
代价是什么：被驱逐的任务需要重新经历一次 Prefill 重算，拉长了被抢占请求的单次端到端延迟。
已学完
💡 一句话解释： 别让一个 32K 字的巨无霸 Prompt 把整张卡霸占 3 秒钟，切成小段跟别人吐字混着算！
# 设置 long_prefill_token_threshold 限制每步最大预填充 Token 数，与 Decode 完美混跑
烦恼：巨无霸插队，所有人吐字被定身
一个大块头，卡死全排队
办法：大石化碎冰，每步匀速嚼几块
细嚼慢咽，大家都能往前走
解决了什么：将大算力 Prefill 任务打碎，允许 Decode 穿插进行，消除流式吐字的间歇性突刺打嗝。
代价是什么：大文本自身到达首字的时间（TTFT）会被稍微拉长几个迭代周期。
已学完
💡 一句话解释： 每 16 个字打一个哈希指纹，所有请求共享前缀；发现指纹对得上，直接拿老显存块用！
# 16-token chunk 哈希链：BlockHash 存入 cached_block_hash_to_block 字典
烦恼：几千个用户带着相同长背景反复读
每个人进来，都把前言算一遍
办法：哈希指纹秒对暗号，公共块原地复用
指纹一验，直接跳到正文
解决了什么：在多轮对话与长系统提示词场景下，直接复用已算好的物理显存块，算力利用率翻倍。
代价是什么：被引用的块不可被驱逐释放，高频复用场景下会长期霸占物理显存槽位。
已学完
💡 一句话解释： Python 每次指挥 GPU 发射算子都有延迟，先在热身时把全套动作“录成宏”，以后一键硬件回放！
# 预先热身捕获常用 Batch Size：避免每次 forward pass 几百个 CPU Launch 开销
烦恼：CPU 啰嗦下令，GPU 算完干等
领导啰嗦指挥，工人闲得抠脚
办法：排练一次录成宏，一键通电触发
一键重放，硬件流水线狂飙
解决了什么：将多层数百次算子发射封装为单一硬件图执行，单步推理延迟立减 20%~40%。
代价是什么：要求张量内存地址与尺寸完全固定，短文本需填充到预捕获尺寸，增加了引擎初始化时间。
已学完
💡 一句话解释： 当模型必须输出严格 JSON 时，别在后面苦苦祈祷它别出错，用有限状态机每一步把非法词直接遮盖掉！
# Structured Output Manager：利用 XGrammar 等工具预构建词表掩码状态图
烦恼：模型瞎编乱写，吐出非法 JSON 废品
信马由缰，格式随时暴毙
办法：状态机护栏，违规道路全封闭
加装路障，只能走合规道路
解决了什么：在 Logits 阶段直接屏蔽语法非法词，实现 100% 保证 JSON/Regex 结构化输出。
代价是什么：复杂庞大的正则表达式或文法初始化构建 FSM 会占用额外内存与启动时间。
已学完
💡 一句话解释： Decode 阶段每吐一个字都要搬运一遍几百 GB 的大模型权重；让小草稿模型一口气猜 5 个字，大模型只看一眼批量审核！
# 内存受限的 GEMV ➔ 批处理算力受限的 GEMM，大幅拉升有效吐字吞吐
烦恼：大象漫步，每动一步都要搬座山
搬万斤砖，只垒一块瓦
办法：小鸟快速叼枝，大鹏一次过目
小弟先猜，大哥一次盖章
解决了什么：将单步串行访存瓶颈转化为矩阵并行验证，显著降低单请求生成延迟。
代价是什么：草稿模型需额外显存驻留，若猜中率低可能适得其反浪费算力。
已学完
💡 一句话解释： Prefill 是算力饕餮，Decode 是带宽吞噬者；把两张卡拆开各司其职，中间用高速网络飞速传 KV 账本！
# 算力卡专跑 Prefill ➔ RDMA 高速传 KV Cache ➔ 访存卡专跑 Decode 生成
烦恼：同居一室，算力与访存互相掐架
同吃一锅饭，互相扯后腿
办法：分工建站，专业算力与生成池解耦
分工包干，各自发挥极致
解决了什么：将计算密集型与带宽密集型两阶段硬件隔离，实现吞吐与首字时延双双登顶。
代价是什么：节点间跨机网络需极高规格 RDMA/InfiniBand 支持，且系统调度复杂度极高。
下一站
💡 一句话解释： 从单进程小作坊进化到全天候现代化大工厂：API 网关、调度引擎、多卡 Worker 各自独立进程，并发无上限！
# InprocClient (单进程) ➔ MultiProcExecutor ➔ DPLBAsyncMPClient (分布式数据并行与负载均衡)
烦恼：单进程一旦被 GIL 锁住全网瘫痪
一个前台忙，后台全停摆
办法：解耦多进程独立跑，网关异步调度
多进程分工，生产级无限扩展
解决了什么：将网络接入、引擎核心与多 GPU 运行器彻底拆分到独立进程，破除 Python GIL 束缚。
代价是什么：进程间通信（IPC）增加了共享内存与信号管道管理开销。