1. 从“请求”到“生成”理解推理服务的核心脉络当我们谈论一个现代的大语言模型推理服务时比如 Nano-vLLM其核心挑战往往不在于模型本身的一次前向传播而在于如何高效、稳定地管理海量并发、长度不一的用户请求。想象一下你正在运营一个在线问答服务每秒有成千上万个问题涌入每个问题的答案长度未知有的可能只需要几个词有的则需要生成一篇短文。服务器资源主要是GPU显存和算力是有限的如何让这些请求“排好队”、“不打架”并且能最快地得到响应这就是推理服务框架要解决的根本问题。Nano-vLLM 作为 vLLM 的一个轻量化、高性能实现其精髓就在于设计了一套精巧的请求调度与执行机制。而这一切的基石便是Sequence 状态机。它不是一个抽象的概念而是一个实实在在的、驱动着每个用户请求从诞生到结束的“生命引擎”。理解了这个状态机就相当于拿到了打开高性能推理服务黑盒的钥匙。你会明白为什么你的请求有时会等待为什么服务能同时处理多个长短不一的序列以及框架是如何在吞吐量和延迟之间寻找最佳平衡点的。本文将深入 Nano-vLLM 的源码聚焦于 Sequence 状态机与请求的完整生命周期。我们将抛开复杂的分布式和高级优化从最核心的单机调度逻辑入手拆解一个请求是如何被接收、调度、执行直至返回的。这对于任何想要深入理解推理服务底层原理或是有意进行二次开发的工程师来说都是至关重要的一课。2. Sequence请求的具象化与状态定义在 Nano-vLLM 中用户的每一个推理请求例如“写一首关于春天的诗”并不会被直接丢给模型。它首先会被封装成一个Sequence对象。这个对象是请求在系统内部的核心表示它携带了请求的所有元信息并随着处理的推进在不同的状态间流转。2.1 Sequence 的核心数据结构一个Sequence对象通常包含以下关键字段我们可以通过一个表格来快速理解字段名类型描述seq_idint/str序列的唯一标识符用于在系统中追踪该请求。prompt_token_idsList[int]用户输入Prompt经过分词器Tokenizer转换后的 token ID 列表。这是生成的“起点”。output_token_idsList[int]动态增长的列表用于存放模型已生成的所有 token ID。初始为空。statusSequenceStatus核心字段表示序列当前所处的状态如WAITING,RUNNING,FINISHED等。block_tablesDict[int, List[int]]物理块表。由于 vLLM 使用 PagedAttention 内存管理它记录了该序列的逻辑块如第0块、第1块对应在 GPU KV Cache 中的物理块位置。这是实现高效内存复用的关键。remaining_decode_stepsint预估该序列还需要多少步解码才能完成例如达到最大长度或被停止词终止。用于调度决策。注意block_tables是理解 vLLM 系列高性能的关键。传统方法为每个序列预留固定长度的 KV Cache导致内存碎片和浪费。PagedAttention 将 KV Cache 划分为固定大小的“块”Block不同序列可以共享这些块。block_tables就像一个“页表”告诉系统“我这个序列的第0个逻辑块实际数据存放在物理块号5的位置上。”2.2 SequenceStatus 状态枚举生命周期的阶段划分状态机由SequenceStatus这个枚举类定义。虽然具体状态名可能因版本略有差异但其核心生命周期通常包含以下几个阶段WAITING (等待)请求刚被系统接收完成了初步的封装创建了Sequence对象但尚未被调度器选中执行。它正在等待可用的计算资源主要是GPU上的槽位。RUNNING (运行中)该序列已被调度器选中其对应的 token 正在或即将在本轮模型前向传播中被计算。这是序列的“活跃”阶段。SWAPPED (已换出)这是一个高级状态在内存压力极大时出现。序列的 KV Cache 被从快速的 GPU 显存转移到了较慢的 CPU 内存或磁盘上以腾出空间给更高优先级的序列。当资源空闲时它需要被“换入”才能回到WAITING或RUNNING状态。FINISHED (已完成)序列的生成过程已结束。结束原因可能是a) 生成了停止词eosb) 达到了预设的最大生成长度c) 用户主动取消了请求。此时output_token_ids就是最终结果可以被返回给用户。CANCELLED (已取消)用户端主动终止了请求。系统需要释放该序列占用的所有资源内存块。这个状态枚举定义了Sequence对象status字段所有可能的取值状态之间的转换由调度器Scheduler和核心执行引擎Worker协同控制构成了完整的生命周期。3. 请求生命周期的全景图一次完整的旅程让我们跟随一个用户请求走完它在 Nano-vLLM 中的完整生命周期。这个过程清晰地展示了状态机是如何被驱动的。3.1 阶段一接收与初始化 (WAITING)当服务端通过 HTTP 或 gRPC 接口收到一个推理请求时生命周期开始。请求解析框架解析请求体获取prompt文本、生成长度参数max_tokens、停止词等。Tokenization调用分词器Tokenizer将prompt文本转换为prompt_token_ids。创建 Sequence系统生成一个唯一的seq_id并以prompt_token_ids和其他参数为输入实例化一个Sequence对象。此时它的status被初始化为SequenceStatus.WAITINGoutput_token_ids为空列表。加入调度队列新创建的Sequence对象被添加到调度器Scheduler的等待队列中。至此请求的“纸上”准备工作完成进入排队状态。3.2 阶段二调度与执行 (WAITING - RUNNING - ...)这是最核心的循环阶段由调度器周期性触发。调度决策调度器如FCFS-先来先服务或更复杂的Continuous Batching策略从其等待队列中根据策略选择一组Sequence进入本轮执行。选择的标准通常考虑公平性、优先级以及最重要的——当前 GPU 显存中剩余的物理块是否足够容纳这些序列的 KV Cache。状态转换与资源分配被选中的Sequence其状态从WAITING更新为RUNNING。同时调度器为这些序列分配或确认它们所需的物理块更新block_tables。如果某个序列是从SWAPPED状态恢复的这里还会涉及将 KV Cache 从 CPU 换回 GPU 的操作。构造模型输入Worker 将所有RUNNING状态的Sequence的当前 token 组织起来。对于每个序列输入是它下一个待生成的 token对于刚开始的序列就是prompt的最后一个 token 或一个特殊的开始符。这些 token 被拼接成一个一维的input_tokens张量。同时系统会根据每个序列的block_tables生成对应的block_tables张量和context_lens上下文长度等元信息供 PagedAttention 内核使用。内核执行将input_tokens和 KV Cache 的元信息输入模型执行一次前向传播解码。这里的关键是调用高度优化的 PagedAttention 算子它能根据block_tables像查页表一样高效地从分散的物理块中 gather 出每个序列所需的 K, V 向量并进行注意力计算。采样与更新得到每个序列下一个 token 的 logits 后根据设定的采样策略如贪婪采样、top-p采样选择出最终的next_token_id。将这个next_token_id追加到对应Sequence的output_token_ids列表中。状态再评估检查每个RUNNING的序列如果next_token_id是停止词或output_token_ids长度达到max_tokens则将其状态标记为FINISHED。否则它将继续保持RUNNING状态等待下一轮调度。同时系统会为这个新生成的 token 在 KV Cache 中分配一个新的逻辑块可能需要分配新的物理块并更新block_tables。3.3 阶段三完成与清理 (RUNNING - FINISHED)结果封存对于状态变为FINISHED的Sequence其完整的output_token_ids即为生成结果。Worker 或一个专门的输出处理器会将其转换回文本字符串。资源释放这是至关重要的一步直接关系到系统的长期稳定性和内存利用率。系统必须将该Sequence所占用的所有物理块记录在block_tables中标记为“空闲”以便分配给后续的序列。在 Nano-vLLM/vLLM 中这通常由块管理器BlockManager负责。结果返回将生成的文本通过网络接口返回给客户端。对象销毁Sequence对象本身可以从管理器中移除其生命周期正式结束。3.4 异常路径取消与换出取消 (CANCELLED)用户可以在请求过程中发送取消指令。系统会将该Sequence的状态立即置为CANCELLED并触发与FINISHED类似的资源释放流程然后丢弃该对象。换出 (SWAPPED)在支持 CPU/GPU 异构存储的配置下当 GPU 显存紧张且某个Sequence优先级较低或已长时间未执行时调度器可能决定将其状态从RUNNING或WAITING改为SWAPPED。触发将它的 KV Cache 从 GPU 复制到 CPU 内存并释放 GPU 上的物理块。当资源允许时再将其换回。整个生命周期可以用一个简化的状态转换图来概括注意此处为描述性文字非图表“WAITING” 在调度时变为 “RUNNING”“RUNNING” 在生成完成后变为 “FINISHED”或在资源紧张时变为 “SWAPPED”“SWAPPED” 在资源空闲时可被换回 “WAITING”在任何状态都可能因用户取消而直接变为 “CANCELLED”。4. 源码透视状态转换的关键代码节点让我们深入到 Nano-vLLM 的源码层面看看这些状态转换具体发生在哪里。我们以类似伪代码的形式展示核心逻辑。1. 调度器中的状态转换 (scheduler.py或类似文件)class Scheduler: def schedule(self) - SchedulingDecision: # 决策哪些序列本次运行 running_seqs: List[Sequence] [] for seq in self.waiting_queue: if self._can_allocate(seq): # 检查是否有足够内存块 seq.status SequenceStatus.RUNNING # WAITING - RUNNING self._allocate_blocks(seq) # 分配物理块 running_seqs.append(seq) else: break # 内存不足停止调度 # 可能还有从 SWAPPED 恢复的逻辑 for seq in self.swapped_queue: if self._can_allocate(seq): seq.status SequenceStatus.WAITING # SWAPPED - WAITING (或直接 RUNNING) self.waiting_queue.append(seq) return SchedulingDecision(running_seqs, ...)这里清晰地展示了调度器如何将序列从WAITING队列中取出在资源满足的条件下将其状态改为RUNNING并分配资源。2. Worker执行后的状态再评估 (worker.py或engine.py):class Worker: def execute_model(self, running_seqs: List[Sequence], ...) - List[SequenceOutput]: # ... 执行模型前向传播得到 next_tokens ... finished_seqs: List[Sequence] [] for seq, next_token in zip(running_seqs, next_tokens): seq.output_token_ids.append(next_token) # 检查终止条件 if self._check_stopping_criteria(seq, next_token): seq.status SequenceStatus.FINISHED # RUNNING - FINISHED finished_seqs.append(seq) else: # 未结束为下一个token准备KV Cache空间 self._append_slot(seq) # 处理已完成的序列 for seq in finished_seqs: self.block_manager.free(seq) # 释放内存块 self._send_response(seq) # 发送响应 # ...在执行完模型后Worker 会遍历所有运行的序列检查生成是否应结束。如果结束则立即更新状态为FINISHED并触发资源释放和结果回传。3. 块管理器的释放逻辑 (block_manager.py):class BlockManager: def free(self, sequence: Sequence): # 遍历该序列block_tables中的所有物理块号 for physical_block_number in sequence.get_all_physical_blocks(): self.free_block(physical_block_number) # 将块标记为空闲 sequence.block_tables.clear() # 清空序列的块表资源清理是状态机闭环的关键。当序列FINISHED或CANCELLED时必须立即、彻底地释放其占用的所有物理块否则会导致内存泄漏系统可用内存会越来越少最终崩溃。5. 实战中的状态机调试与问题排查理解状态机不仅有助于读源码更能直接指导我们调试和优化推理服务。场景一请求堆积延迟飙升现象客户端请求响应时间很长监控发现大量请求处于WAITING状态。排查思路检查调度策略是否是简单的 FCFS 导致长序列阻塞了后面所有请求考虑是否需引入基于剩余解码步数的预emptive调度。分析内存瓶颈WAITING队列过长根本原因往往是 GPU 显存KV Cache 空间不足。使用监控工具查看block_manager的物理块利用率。如果接近100%说明内存是瓶颈。查看序列长度是否出现了超长上下文Long Context的请求单个这样的请求会占用大量块挤占其他请求的资源。可能需要设置单请求最大长度限制。行动根据排查结果可以调整调度参数、扩容 GPU 显存、或对输入进行长度裁剪。场景二GPU利用率低但吞吐量上不去现象nvidia-smi显示 GPU-Util 不高但服务吞吐量Tokens/s远低于预期。排查思路检查SWAPPED状态序列如果系统配置了交换Swap大量序列处于SWAPPED状态意味着频繁的 CPU-GPU 数据拷贝这会带来巨大的开销严重拖慢整体速度。监控swapped_queue的大小。分析每次调度的序列数调度器每次选择的RUNNING序列数量Batch Size是否过小过小的 Batch Size 无法充分“榨干”GPU 的并行计算能力。但 Batch Size 过大又可能导致内存不足OOM。需要找到一个平衡点。审视FINISHED序列的清理延迟资源释放是否及时如果FINISHED序列的块没有立即释放会虚占内存导致后续WAITING序列无法被调度GPU 出现空转。行动禁用或优化交换策略调整调度器的批量大小参数确保资源释放是同步且立即执行的。场景三生成结果不完整或提前截断现象返回的文本突然结束不符合停止词规则也未达到最大长度。排查思路确认状态转换逻辑仔细检查_check_stopping_criteria函数。是否是停止词列表Stop Tokens设置有问题或者最大长度Max Tokens的计算逻辑有误是否包含了Prompt的长度。检查异常处理在模型前向传播或采样过程中是否发生了未处理的异常导致序列被强制标记为FINISHED或CANCELLED查看日志中是否有错误信息。排查资源强制回收在极端内存压力下某些实现可能会强制终止Kill最老的或占用最大的序列来保全系统这可能导致生成意外结束。行动修复停止词或长度计算逻辑增强异常处理的健壮性优化内存管理策略避免强制回收。通过将线上问题映射到Sequence状态机的异常流转上我们可以快速定位问题根因从系统层面而不仅仅是模型层面去思考和解决问题。