SGLang 项目调研

调研日期：2026-09-17。本文先建立项目定位、核心概念与实验路线，依据官方资料整理；尚未在本机安装 SGLang、加载模型或进行性能测试。具体模型和硬件支持需以实际使用版本为准。

1. 项目定位

SGLang 是面向大语言模型和多模态模型的高性能推理服务框架，项目采用 Apache-2.0 许可证。调研时应重点关注请求如何调度、KV Cache 如何管理，以及模型执行如何适配不同硬件。官方仓库

官方文档列出的主要方向包括 RadixAttention、前缀缓存、多 GPU 并行以及兼容 OpenAI 风格的服务接口。能启动某个模型并不代表该模型在任意设备、量化方式及并行配置下都可用，实际部署需要核对组合条件。官方文档

与本站的 Faiss 调研相比，两者处在应用的不同环节：Faiss 负责向量近邻检索，SGLang 负责模型推理服务。一个 RAG 应用可以先检索资料，再将资料组织成提示词交给推理服务生成答案。

2. 先理解请求生命周期

下面是便于理解的概念流程，不是某个版本的精确函数调用链：

客户端请求
  → 接口解析与分词
  → 请求排队和调度
  → 检查可复用的前缀缓存
  → Prefill：处理尚未计算的输入部分
  → Decode：逐步生成输出 token
  → 反分词与流式返回

阅读推理系统时，可以先区分两类工作：Prefill 处理输入序列并建立后续生成需要的状态，Decode 利用已有状态逐步生成。实际调度与计算可能交错进行，不能将图中的顺序理解为所有请求必须各自独占设备执行。

原始 SGLang 论文将系统分为前端语言和运行时：前端表达生成与控制流程，运行时优化执行。阅读早期文章时，要区分其中的编程接口与当前推理服务接口。SGLang 论文

3. 核心调研点：前缀复用

RadixAttention 的重要思路是组织并复用共享前缀的 KV Cache，减少重复计算。它复用的是模型计算状态，不能等同于直接缓存并返回整条回答。原始论文

例如，应用设计中可能存在以下提示词：

请求 A：[相同系统提示词][相同背景资料][问题 A]
请求 B：[相同系统提示词][相同背景资料][问题 B]

这类共享前缀值得做缓存收益实验，但实际命中受 token 序列、模型配置、缓存生命周期和调度影响。不能仅凭两段文本看起来相似就认定一定命中。

本文建议分别测量冷缓存与热缓存，并增加“完全不共享前缀”的对照组，避免将高复用场景的收益推广到所有请求。

4. 最小服务调用示例

以下仅作为阅读与后续复现入口，本次未执行。运行前应按目标硬件的官方安装说明配置独立环境，并准备模型权重和足够的设备内存。

启动本地服务：

python3 -m sglang.launch_server \
  --model-path Qwen/Qwen2.5-0.5B-Instruct \
  --host 127.0.0.1 \
  --port 30000

待模型加载完成后发送请求：

curl http://127.0.0.1:30000/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "Qwen/Qwen2.5-0.5B-Instruct",
    "messages": [
      {"role": "user", "content": "用三句话解释 KV Cache。"}
    ],
    "temperature": 0,
    "max_tokens": 128,
    "stream": false
  }'

这里的 30000 是模型服务端口，与本站 MkDocs 的 8000 端口不同。启动后可通过 http://127.0.0.1:30000/docs 查看该运行版本的接口定义。命令形式和聊天接口用法参考官方请求教程。

5. 后续源码阅读路线

建议围绕一个请求逐层追踪，而不是从目录名猜测所有模块的行为：

阶段	要回答的问题
服务入口	启动参数如何传递，HTTP 请求如何变成内部请求？
分词与请求管理	token 化在哪里发生，取消与超时如何处理？
调度	什么请求进入同一批次，如何处理资源不足？
KV Cache	缓存如何匹配、分配、引用和回收？
模型执行	Prefill 与 Decode 怎样进入模型和 attention 实现？
输出	采样、停止条件、反分词和流式响应如何衔接？

正式源码导读应先固定 release 或 commit，再记录具体路径、类和调用链。当前文章提供的是阅读问题清单，不声称已经核对上述模块的实现细节。

6. 实验计划

下面是建议的首轮实验，不是已有性能结论。

维度	建议控制项
模型	固定模型、权重版本、精度与 tokenizer
输入与输出	分别覆盖短输入、长输入及不同生成长度
并发	从单请求逐步增加，观察饱和点
缓存	无共享、共享前缀冷启动、共享前缀热启动
硬件	记录设备型号、数量、显存及软件版本
服务配置	固定并记录并行方式、调度和缓存相关选项

至少记录首 token 延迟（TTFT）、相邻输出 token 的时间间隔、请求总延迟、输出 token 吞吐、峰值内存、失败率和超时率。延迟同时看中位数与尾部，吞吐需要注明统计窗口和是否包含输入 token。

选型时建议比较“满足相同延迟目标时的吞吐”，并使用相同模型、请求分布与生成条件。官方特定环境的加速数据不能直接作为本机或业务场景的预期。

7. 下一步

源码阅读可继续看 SGLang 源码结构与 API 详细导读，其中固定 v0.5.2 梳理了目录、请求调用链、调度器和 KV Cache。

先确定目标模型、硬件和使用场景，再开展一次可复现的服务启动与请求验证；随后结合源码导读，补充调度器和 KV Cache 的运行跟踪专题。这样可以将项目概念、真实调用链和测量结果逐步对应起来。