1. 从“调度”视角看SGLang为什么它不只是另一个推理框架最近在社区里看到不少关于SGLang的讨论尤其是它在大模型推理性能上的表现经常被拿来和vLLM、TGI这些老牌框架做对比。很多人第一眼看到SGLang可能会觉得它又是一个“优化KV Cache”、“实现PagedAttention”的推理加速框架。但如果你真的去翻看它的源码特别是runtime目录下的核心逻辑你会发现它的野心和设计哲学远不止于此。SGLang最核心的贡献在我看来是提出并实现了一套面向“结构化生成”的、声明式与执行式分离的运行时调度系统。它试图回答一个问题当大模型的生成任务不再是简单的“输入-输出”而是包含了复杂控制流如分支、循环、函数调用和外部工具交互的“程序”时我们该如何高效地调度和运行它简单来说SGLang把大模型推理从一个“黑盒函数调用”变成了一个可被精细编排和优化的“数据流程序”。用户用Python写的是声明式的“程序逻辑”比如先生成一个大纲再根据大纲的每一点展开期间可能调用搜索引擎而SGLang的运行时负责将这个逻辑编译成高效的、可并行、可缓存的底层操作序列。这种“调度器”的视角是理解其源码的关键。2. 核心架构拆解三层设计如何实现声明与执行分离SGLang的源码结构清晰地反映了它的三层设计思想。我们主要关注sglang/backend和sglang/runtime这两个包。2.1 声明层sglang.lang与sglang.lang.interpreter这是用户直接接触的接口层。它提供了一套类Python的DSL领域特定语言让你可以像写普通程序一样描述生成任务。# 一个简化的SGLang程序示例 sgl.function def multi_step_qa(session, question): # 步骤1思考 with sgl.user(): session f问题{question}\n让我们一步步思考。 with sgl.assistant(): reasoning sgl.gen(reasoning, max_tokens200, stop\n\n) # 步骤2基于思考生成最终答案 with sgl.user(): session f基于以上思考请给出最终答案。 with sgl.assistant(): answer sgl.gen(answer, max_tokens100) return reasoning, answerinterpreter模块的核心是一个访问者模式驱动的解释器。当你调用这个被sgl.function装饰的函数时它并不会立即执行模型推理。相反解释器会遍历整个AST抽象语法树将sgl.gen(),sgl.select()等原语以及with sgl.user():这样的控制块转换成一个中间表示IR。这个IR是一个由Node组成的计算图。每个Node代表一个原子操作比如“在当前位置生成文本”、“从几个选项中选择一个”、“跳转到某个标签”。源码中node.py里定义了各种Node的子类如Generate、Select、Fork、Join等。关键设计这一层完全与后端模型解耦。它只关心“要做什么”不关心“怎么做”。这为后续的优化如操作融合、并行调度提供了巨大的灵活性。2.2 编译与优化层sglang.runtime这是SGLang的“大脑”也是源码中最精妙的部分。它的核心职责是将声明层产生的计算图IR编译成可以在后端高效执行的指令序列。主要流程如下图分析与优化runtime会接收一个Node图。首先进行一系列图优化Pass。例如操作融合将连续的、无依赖的Generate节点如果它们的采样参数相同融合成一个减少内核启动开销和RPC通信次数。这在fusion_pass.py中有体现。确定性分支提前对于Select节点如果其选项不依赖模型生成比如是静态字符串编译器可以在编译期就决定走哪条分支从而剪枝掉整个未被选择的分支。公共子表达式消除识别出图中完全相同的子图例如同一段提示词被多个分支使用安排它们只计算一次结果复用。指令生成与调度优化后的图会被转换成一系列Instruction对象。这些指令是后端执行引擎能理解的最小单位。sglang/runtime/instruction.py中定义了丰富的指令类型如Init初始化一个推理会话。Extend向会话中添加一段确定的文本提示词。Decode执行一步自回归解码生成一个token。Fork复制当前会话状态用于并行探索不同分支。Join等待多个分支完成并可能合并结果。Return返回结果。调度器scheduler负责管理这些指令的执行顺序和资源分配。它维护着一个就绪指令队列并考虑后端引擎的负载、内存情况尤其是GPU KV Cache的页表状态决定何时派发哪个指令。这里借鉴了操作系统中进程调度的思想但调度对象是模型推理的“微操作”。2.3 后端执行层sglang.backend这一层是“肌肉”负责实际执行调度器派发的指令并与底层模型推理引擎如vLLM、NVIDIA TensorRT-LLM或原生的Hugging Face Transformers交互。SGLang采用了后端抽象的设计backend目录下有不同的实现。rpc_client.py/rpc_server.py这是默认且推荐的生产模式。一个独立的SGLang Server进程使用vLLM作为推理引擎负责实际的计算。客户端你的Python程序通过RPC与服务器通信发送指令接收token。这种分离使得计算资源管理、多租户、弹性伸缩变得容易。transformers.py一个简单的本地后端直接调用Transformers库用于调试和小规模测试。后端接收到Decode指令后会调用底层引擎的generate或decode函数。但关键在于SGLang的后端不是简单包装一个generate调用。它需要管理会话状态每个用户会话对应一个唯一的session_id后端需要维护其KV Cache、当前token位置等信息。实现指令语义例如处理Fork指令时需要深度复制当前会话的KV Cache或通过引用计数管理PagedAttention中的物理块创建出独立的分支上下文。与调度器协同执行完一个指令如生成完指定数量的token后需要通知调度器触发后续就绪指令的执行。3. 性能之源深入runtime核心调度机制理解了架构我们再深入runtime看几个关键的调度机制是如何实现的。3.1 异步流式生成与“抢占式”调度在传统的同步生成中一个gen(max_tokens100)调用会阻塞直到100个token全部生成完毕。SGLang通过异步和流式设计打破了这一点。# 用户代码可以非阻塞地获取部分结果 future my_sglang_func.run_async(...) for partial_result in future.stream(): print(partial_result) # 可以实时看到生成的token在源码中Future对象代表一个异步执行的任务。调度器在派发一个Decode指令后不会等待它完成全部max_tokens而是会在生成每一个token后就检查是否有更高优先级的任务比如另一个用户的短查询需要插队。这类似于CPU的“时间片轮转”。实现这一点的核心是runtime与backend的协作协议。后端每生成一个token就通过回调或事件通知runtime。runtime的调度器收到通知后可以将已生成的token通过stream通道发送给客户端。检查当前任务的max_tokens或stop条件是否满足。如果满足则标记该指令完成并激活该任务的下一个指令。执行调度决策如果当前任务的时间片用尽或是有更高优先级任务在等待调度器可以挂起当前任务的Decode指令保存其解码状态转而执行其他任务的指令。等下次轮到它时再恢复执行。这种细粒度的调度极大地提高了系统在混合负载长短请求交错下的吞吐量和响应速度。3.2 结构化生成与状态管理SGLang支持复杂的控制流如循环和递归。例如你可以写一个函数让它递归地分解问题直到满足某个条件。运行时如何管理这些嵌套调用产生的无数会话状态源码中的Session和State对象是关键。每个独立的执行上下文例如一个函数调用或一个Fork出的分支都有一个State。State中包含了text当前已生成的文本。meta_info各种元数据如当前在计算图中的位置一个程序计数器PC。backend_state一个指向后端引擎中对应KV Cache等资源的句柄。当发生Fork时调度器会创建一个新的State对象。对于后端状态如果是基于PagedAttention的后端如vLLMFork可能只是增加一些物理内存块的引用计数而不是真正的数据拷贝这非常高效。Join操作则可能需要比较多个分支State的结果选择一个并清理掉其他分支的状态。对于递归调用runtime会维护一个调用栈。每个新的递归层级对应一个新的State。这保证了即使是在复杂的逻辑中每个执行点的上下文都是隔离和清晰的。3.3 缓存与记忆化RadixAttention的实现SGLang论文中重点宣传的RadixAttention前缀缓存其核心思想在源码runtime/cache.py中体现。它本质上是一个前缀树Trie。键是提示词的token ID序列。值是计算该提示词对应的KV Cache在内存中的位置或标识符。当一个新的请求到来其提示词是[A, B, C, D]时系统会沿着前缀树查找匹配到[A, B, C]发现缓存中存在。那么只需要为[D]这个新后缀计算KV Cache并将其拼接到[A, B, C]缓存的后面。在runtime层面当解释器处理到一段确定的提示词比如with sgl.user():块里的静态文本时它会生成一个Extend指令。调度器在执行这个Extend指令前会先查询缓存系统。如果命中则指令会变成一个非常轻量的“绑定缓存”操作如果未命中才需要真正调用后端引擎进行计算并插入新缓存。实操心得RadixAttention的收益极度依赖工作负载。如果你的应用场景是大量共享相同系统提示词或长上下文文档前缀的对话它的提升是惊人的可能减少80%的重复计算。但如果每个请求的提示词都完全不同缓存命中率为零那么维护前缀树本身还会带来一点开销。在部署时需要监控缓存命中率这个指标。4. 与vLLM/TGI的深度对比不是替代是增强很多人问有了vLLM这么高效的PagedAttention和吞吐量优化为什么还需要SGLang从源码分析可以看出它们解决的是不同层面的问题。特性vLLM / TGISGLang核心目标单个生成请求的极致吞吐量与高内存利用率。通过PagedAttention解决KV Cache内存碎片化通过连续批处理提高GPU利用率。复杂、结构化生成任务的高效编排与执行。将复杂逻辑编译成可优化调度的微操作流。抽象层级相对较低。提供generate()API输入提示词和参数输出完整结果。控制流需要用户在外部代码中实现。较高。提供声明式DSL将控制流分支、循环、函数调用作为一等公民内置于生成过程中。优化重点注意力计算、内存管理、批处理调度。操作间依赖分析、计算图优化、跨请求的细粒度交错调度、前缀缓存。关系SGLang可以作为vLLM的调度器。SGLang的RPC后端通常连接vLLM作为其推理引擎。SGLang处理复杂的程序逻辑和高级调度vLLM负责底层高效的单步解码和内存管理。一个生动的类比vLLM像是一个极其高效的“印刷厂”它擅长快速、大批量地印刷固定内容的纸张生成token。而SGLang像是一个“出版社总编室”它负责策划一本书的章节结构大纲生成、决定哪些部分可以并行撰写分支、检查初稿并决定是否重写某个章节循环/条件判断甚至协调外部插画师工具调用。总编室SGLang将复杂的出版计划分解成一个个具体的印刷任务指令然后高效地派发给印刷厂vLLM去执行。5. 源码导读与实践建议如果你想深入研究SGLang源码我建议按以下路径从入口开始从sglang/lang/__init__.py看起找到function装饰器和run/run_batch方法。看一个简单的程序是如何被装饰、转换成中间表示的。追踪解释器进入sglang/lang/interpreter重点关注visit_Generate、visit_Fork等方法理解如何将Python AST转换成Node图。深入运行时核心阅读sglang/runtime/core.py中的Runtime类。它是连接编译器将图变成指令和后端的枢纽。看它的schedule方法是如何工作的。分析一个后端以backend/rpc_client.py为例看_request_worker线程是如何不断从运行时获取指令通过RPC发送给服务器并处理返回的token流的。调试一个小程序写一个最简单的包含gen和select的SGLang函数打开调试日志观察Node图、Instruction序列的生成和执行过程。这是理解其工作流最直观的方式。部署与调优建议后端选择生产环境强烈推荐使用SGLang Server vLLM的RPC模式。这能获得最好的性能和资源隔离。缓存配置根据你的前缀共享程度合理设置RadixAttention缓存的大小--radix-attention-size。太大浪费内存太小影响命中率。监控指标除了传统的吞吐量、延迟关注SGLang特有的指标如指令队列长度反映调度压力、缓存命中率、分支Fork/Join的频率等这些能帮你发现结构化生成中的瓶颈。模式匹配SGLang的gen函数支持regex参数用于强制输出格式。这在后端是通过在采样后对logits进行掩码实现的。如果正则表达式非常复杂可能会增加少量开销但对于确保输出格式正确、减少后处理代码至关重要。SGLang代表了大模型应用开发的一个趋势从简单的提示工程走向提示编程。它的源码为我们展示了一个将复杂、动态的生成逻辑进行系统化编排和优化的完整蓝图。虽然目前它在生态和稳定性上可能还不如vLLM成熟但其设计思想无疑为构建下一代大模型应用基础设施指明了方向。