在将大型语言模型投入生产环境时，推理引擎构成了核心的底层支撑，包括OpenAI和Claude等服务均依赖此类系统。对于开发者而言，理解提示词处理、请求批处理和GPU资源管理等底层机制至关重要，它直接影响系统设计决策。本文将通过分析Nano-vLLM——一个精简但功能完备的vLLM实现——来剖析这些内部工作原理，该项目由DeepSeek技术报告的贡献者开发。
Nano-vLLM虽然代码量极少（约1,200行Python），却实现了前缀缓存、张量并行和CUDA图编译等生产级优化，其性能基准测试显示与完整的vLLM相当。第一部分重点关注系统的工程架构，即请求如何流经管道以及调度决策的制定过程，暂将模型计算视为黑盒。这使得研究人员能够专注于推理引擎的设计哲学，而非陷入对多种模型架构和硬件后端的支持细节中。
LLM生成流程的入口在于调用LLM类的generate方法，接收提示词数组和采样参数后返回文本。在这一简单接口背后，系统首先通过特定于模型的Tokenizer将自然语言提示词转换为内部数据结构——序列，即Token ID的可变长度数组。这个序列随后成为贯穿后续系统处理的核心工作单元。
系统的核心设计采用了生产者-消费者模式，调度器（Scheduler）位于中心位置，实现了关键的解耦。addrequest方法作为生产者，负责将提示词转化为序列并放入调度器的队列中。随后，一个独立的步骤循环作为消费者，从调度器中提取序列批次进行计算，这种机制允许系统累积多个请求以实现计算效率的提升。
批处理是提升吞吐量的关键，因为它能够分摊GPU计算中存在的固定开销，如CUDA Kernel初始化和CPU/GPU间的数据传输。然而，批处理带来了吞吐量与延迟之间的权衡：更大的批次提高了整体吞吐量，却可能增加单个请求的延迟，因为批次必须等待最慢的序列完成。
LLM推理被清晰地划分为预填充（Prefill）和解码（Decode）两个阶段。预填充阶段集中处理所有输入Token以建立模型的初始状态，此时用户尚未看到任何输出；解码阶段则逐个生成Token，每个新Token的生成都依赖于其前序所有Token的结果。调度器必须区分这两个阶段，因为它们的计算特征截然不同。
调度器负责决定处理哪些序列以及处理顺序，它维护着等待队列和运行队列。新序列首先进入等待队列，并在Block Manager分配资源后转移至运行队列。当资源不足以容纳KV缓存的增长时，调度器会采取抢占策略，将运行中的序列移回等待队列前端，从而确保资源释放后能够快速恢复执行。
内存管理的核心创新在于Block Manager，它将可变长度的序列抽象为固定大小的“块”（Block，默认256个Token）。Block Manager在CPU内存中维护元数据，通过对每个块的内容进行哈希并维护映射关系，实现了前缀缓存。如果新序列的某个块哈希值已存在，系统便通过增加引用计数来复用该块，无需重新计算，这在处理共享系统提示词的场景中尤其有效。
