mini-sglang：用最小代码看懂大模型推理引擎

Mini-SGLang 是一款轻量易读的推理框架（仅约 5000 行 Python 代码），通过基数缓存、分块预填充、重叠调度、张量并行，以及 FlashAttention/FlashInfer 内核等优化方案，实现大语言模型的高速运行与服务部署。该框架依赖 CUDA 环境，支持源码快速安装，可启动兼容 OpenAI 规范的 API 或交互式终端，适配单 / 多 GPU 部署，能以低延迟、可扩展吞吐量完成模型（如通义千问、Llama 系列）的测试与落地。核心优势：提供透明可修改的引擎，助力研发、基准测试或生产环境下，快速落地高效的大语言模型推理服务。

为什么“看不懂”大模型推理系统？

• model.generate() 掩盖了 90% 的复杂度

• vLLM / SGLang 源码动辄上万行

• 初学者常见误区：

  • 以为推理就是一次 forward
  • 不理解 KV Cache 的意义
  • 不知道 scheduler 在调度什么

问题不在你，而在缺少“中间层示例”

mini-sglang 是什么？

• 一个 教学用 / 最小实现（minimal implementation） 的 LLM 推理引擎

• 来自 sgl-project

• 目标不是性能，而是：

  • 可读
  • 可追踪
  • 能一行行对上“概念 → 代码”

可以把它理解为：
SGLang / vLLM 的“骨架版说明书”

它解决的核心问题是什么？

mini-sglang 重点回答三个问题：

1. 推理为什么要分 prefill 和 decode？
2. KV Cache 到底缓存了什么？
3. 多请求时，推理系统如何调度？

LLM 推理的真实流程

Prefill：一次性吃下 prompt

• 输入整段 prompt
• 构建初始 KV Cache
• 成本高，但只做一次

Decode：逐 token 生成

• 每次只生成 1 个 token
• 复用历史 KV
• 性能瓶颈集中在这里

mini-sglang 把这两步明确拆开，这是理解一切的关键。

KV Cache：性能核心？

KV Cache 会发生什么？

• 每生成一个 token
• 都要重新算全部历史 attention
• 复杂度爆炸

mini-sglang 中 KV Cache 的位置

• Cache 如何创建
• 如何在 decode 中被不断追加
• 如何与 token 生成循环绑定

👉 看完你会明白：

LLM 推理本质是“状态 + 循环”

调度器（Scheduler）：从单请求到服务端

单请求模型的局限

• 只能串行
• GPU 利用率低

mini-sglang 的最小调度思想

• 多请求排队
• prefill / decode 交错执行
• 用最少代码展示“服务端思维”

虽然简化，但思想是完整的

“推理引擎 ≠ 模型”？

mini-sglang 非常直观地揭示：

• 模型只是一个 forward()

• 真正复杂的是：

  • 状态管理
  • token 循环
  • cache 生命周期
  • 请求调度

大模型工程，本质是系统工程

mini-sglang 与 vLLM / SGLang 的关系

项目	定位
mini-sglang	教学 / 结构理解
SGLang	DSL + 完整推理框架
vLLM	高性能工业实现

先看 mini-sglang，再看 vLLM，难度会下降一个量级

Github：https://github.com/sgl-project/mini-sglang
油管：https://youtu.be/6fWDo812hsY