为什么是 SGLang：Frontend Language 与 Runtime 心智模型#

它解决什么问题#

很多人第一次接触 SGLang，会先把它归类成一个“高性能推理服务框架”。这个理解并不算错，但不完整。因为从上游 README 和 public API 看，SGLang 同时把自己呈现成两类东西：一类是对外服务的运行时入口，另一类是直接被程序调用的 language-level API。

这个双重形态，正是本章要先讲清楚的问题。如果不先把它讲清楚，读者后面看到 sglang serve、python -m sglang.launch_server、Engine(...)、Runtime(...)、gen(...)、user(...)、assistant(...) 这些入口时，很容易把它们当成风格不同但本质相同的调用方式，而忽略它们其实落在不同抽象层。

为什么说它不只是一个 serving engine#

事实层面，上游 README 当前把 “Backend Tutorial” 与 “Frontend Tutorial” 分开列出；而 python/sglang/__init__.py 则同时导出 function、gen、system、user、assistant 这类语言层 API，以及 RuntimeEndpoint、ServerArgs、Engine 这类运行时入口。这说明 public surface 本身就已经分成了“描述生成流程的语言层”与“承载执行的运行时层”。

推断层面，这意味着 SGLang 的核心价值不只在“跑得快”，还在“把 prompt program、structured generation 与 runtime execution 接到一套统一表面上”。第一版在这里不会展开所有机制细节，但会先把这套双层心智模型钉住：语言层负责描述，运行时层负责承载，服务层负责暴露。

这套心智模型如何帮助后续阅读#

有了这个框架，后面的章节角色会清楚很多。2.1 一次请求如何穿过 SGLang 讲的是请求如何进入系统并跨过这些层之间的 handoff；3.1 Serving 层与 SRT 分层 讲的是这些层各自负责什么，不负责什么。

同时，这套心智模型也约束了我们后面对源码的阅读方式。比如 python/sglang/lang/api.py 更适合被当作语言层入口来读，而 python/sglang/launch_server.py 与 python/sglang/srt/entrypoints/* 更适合被当作服务化入口与运行时入口来读。把这些入口混在一起，会让读者失去方向感。

本章对应哪些代码路径#

本章第一版的事实锚点主要有三类。第一类是上游 README 中的公开入口，它告诉我们项目如何向外介绍自己。第二类是 python/sglang/__init__.py，它把 public APIs 按 import surface 暴露出来。第三类是 python/sglang/lang/api.py，这里能直接看到 gen(...) 已经承载 regex、json_schema 等约束生成参数。

这些事实并不足以推出全部架构细节，所以本章不会对内部实现做过强断言。更稳妥的做法是，把它们当成“外部形态的证据”，用来解释为什么本书不能只从 srt 目录出发，而必须先给 frontend language 与 runtime model 一个独立位置。