SGLang 私有化部署实战：本地部署、Docker 部署、能力体验-散宜生的个人博客

如果说 vLLM 更像一台高性能推理引擎，那 SGLang 在很多场景里更像是在引擎之上加了一层“智能驾驶舱”。

它的重点不只是把模型跑得快，还在于：

更适合多步骤推理
更适合长上下文复用
更适合工具调用和复杂任务编排
更适合把模型从“聊天接口”推进到“复杂 AI 应用”

这也是为什么在很多团队的实践里，vLLM 和 SGLang 并不是简单替代关系，而更像是两条偏重点不同的路线：

vLLM 更适合“把模型做成正式 API”
SGLang 更适合“把模型变成更复杂的执行框架”

所以这一篇不会把 SGLang 写成“另一个和 vLLM 一样的部署教程”，而是会重点回答三个问题：

SGLang 到底适合什么场景
本地和 Docker 两条部署路径怎么选
启动之后，应该怎么验证它真的具备 API 能力和应用承接能力

为了延续前面系列的实战风格，下面仍然尽量保持：

先讲为什么要做
再给命令
关键地方补输出
告诉你什么样才算真的成功

文中的模型路径、SGLang 版本、端口号、镜像版本和返回内容基于课程环境整理，与你实际环境不同是正常现象。
重点是部署逻辑和验证链路。

摘要

如果你只想先拿结论，可以先记住这三点：

SGLang 不是简单的“另一个推理服务”，它更强调复杂任务编排和高效执行
本地部署适合理解它和 CUDA、PyTorch、模型之间的关系，Docker 部署适合快速复现和减少宿主机污染
不管走哪条路径，最后都要至少验证三件事：服务已启动、/v1/models 可访问、/v1/chat/completions 可返回结果

这一篇的核心验收点有四个：

python -m sglang.launch_server ... 启动后日志里出现 Application startup complete
curl http://localhost:30000/v1/models 能返回模型列表
curl http://localhost:30000/v1/chat/completions 能返回结构化 JSON
如果接入 Open WebUI，浏览器里已经可以通过 SGLang 后端发起对话

系列导航

这是“大模型私有化部署实践”系列的第八篇。当前系列顺序如下：

如果说前两篇框架实战解决的是“如何把模型变成标准推理 API”，这一篇更想解决的是：

当你开始需要更复杂的推理流程和任务编排能力时，SGLang 到底值不值得上，以及怎么把它真正跑起来。

1. 为什么 SGLang 不是“另一个 vLLM”

很多人第一次听到 SGLang 时，会下意识把它理解成另一个推理服务框架。
这并不完全错，但如果只停留在这个层面，就会低估它真正的价值。

1.1 SGLang 更像“智能加速器”

课程里对它的一个形象比喻非常好：

如果 vLLM 是高性能发动机，那 SGLang 更像一个能规划复杂路线、还能在重复路段复用记忆的智能驾驶舱。

它的几个核心特点很适合快速抓住重点：

支持多步骤任务编排
支持工具调用和复杂流程控制
通过 RadixAttention 等机制提升重复上下文场景效率
在长文档问答、多轮对话、复杂代理场景下更有优势

1.2 那么 vLLM 和 SGLang 到底怎么选

这一点其实不用太神秘化。

如果你的目标是：

快速做成标准 API
强调高吞吐和服务稳定性
偏基础聊天和生成服务

那 vLLM 往往更直接。

如果你的目标是：

做复杂 AI 应用
做多步骤推理
做长文档问答、RAG、工具调用
希望在重复上下文场景下更高效

那 SGLang 往往更值得尝试。

用一句话概括就是：

vLLM 更像“标准引擎”，SGLang 更像“面向复杂应用的执行框架”。

2. 开始之前，还是先确认底层环境已经打通

和 vLLM 一样，SGLang 本身也建立在 GPU、驱动、CUDA 和 PyTorch 这些基础之上。

在真正装 SGLang 前，建议先确认：

nvidia-smi
nvcc --version
python -c "import torch; print(torch.cuda.is_available()); print(torch.cuda.device_count())"

至少应该能看到类似结果：

True
1

如果这里都还没通过，建议先回到第 2 篇，而不是继续往上装 SGLang。

3. 本地部署路径：最适合理解 SGLang 的运行链路

本地部署的最大价值，在于它最容易让你看清楚：

SGLang 到底是怎么起服务的
模型路径和运行参数怎么对应
启动日志到底在告诉你什么

3.1 准备 Miniconda 环境

课程里的本地路径仍然使用 Miniconda 来做环境隔离。
如果你已经在第 6 篇装过 Miniconda，可以直接复用；如果没有，可以按下面方式准备：

mkdir -p ~/miniconda3
wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh -O ~/miniconda3/Miniconda3-latest-Linux-x86_64.sh
bash ~/miniconda3/Miniconda3-latest-Linux-x86_64.sh -b -u -p ~/miniconda3
~/miniconda3/bin/conda init bash
source ~/.bashrc

课程里的典型输出会出现：

PREFIX=/root/miniconda3
Unpacking bootstrapper...
Installing base environment...
installation finished.

3.2 创建 SGLang 专用环境

课程里使用的是 Python 3.11：

conda create --name SGLang python=3.11 -y
conda activate SGLang
python --version

预期输出类似：

Python 3.11.x

3.3 安装 PyTorch 和 SGLang

在课程环境里，CUDA 12.4 对应 PyTorch wheel 先装好，再装 SGLang：

wget https://download.pytorch.org/whl/cu124/torch-2.6.0%2Bcu124-cp310-cp310-linux_x86_64.whl
pip install torch-2.6.0+cu124-cp310-cp310-linux_x86_64.whl
pip install --upgrade pip
pip install "sglang[all]>=0.4.5" --find-links https://flashinfer.ai/whl/cu124/torch2.5/flashinfer-python

这里有一个关键点值得强调：

sglang[all] 不是普通安装，而是把大部分高级依赖一起装上

这对第一次体验 SGLang 很有帮助，因为可以少踩很多“功能依赖没装齐”的坑。

3.4 准备模型目录

课程环境里模型目录仍然类似：

/data/ModelScope/Deepseek-Qwen

先确认目录存在：

ls /data/ModelScope
ls /data/ModelScope/Deepseek-Qwen

4. 用本地方式启动 SGLang

和 vLLM 不同，SGLang 的启动命令会更明确地体现它自己的服务入口。

4.1 启动服务

一个典型启动方式如下：

python -m sglang.launch_server \
  --model-path /data/ModelScope/Deepseek-Qwen \
  --host 0.0.0.0 \
  --port 30000

有些环境里也会出现 8123 作为底层监听端口，但课程最终对外验证使用的是 30000 这一套 OpenAI 兼容入口。
为了和后面的接口验证保持一致，这里建议以你实际开放的 API 端口为准。

4.2 正常启动时日志长什么样

课程里的典型日志片段非常有代表性：

[2026-01-22 18:23:27] INFO:     Started server process [216762]
[2026-01-22 18:23:27] INFO:     Waiting for application startup.
[2026-01-22 18:23:27] INFO:     Application startup complete.
[2026-01-22 18:23:27] INFO:     Uvicorn running on http://0.0.0.0:8123
[2026-01-22 18:23:29] The server is fired up and ready to roll!

这里最重要的信号有三个：

Application startup complete
Uvicorn running on ...
The server is fired up and ready to roll!

只要这几个关键信号都出现了，通常说明服务本身已经真的起来了。

4.3 日志里那些看起来很“重”的信息意味着什么

课程日志里还有很多类似下面的内容：

KV Cache is allocated.
Capture cuda graph begin.
Capture cuda graph end.

这些并不是异常，反而通常是服务在初始化 GPU 推理相关资源。
对第一次接触的人来说，容易误以为“卡住了”，其实很多时候是在做正常启动准备。

5. 本地能力验证：不要只看进程，要看 API

和 vLLM 一样，SGLang 的关键也不是“进程在不在”，而是“API 到底能不能用”。

5.1 先看模型列表接口

课程里的第一个验证命令是：

curl http://localhost:30000/v1/models

客户端的典型输出类似：

{
  "object": "list",
  "data": [
    {
      "id": "Deepseek-Qwen",
      "object": "model",
      "created": 1769077761,
      "owned_by": "sglang",
      "root": "Deepseek-Qwen",
      "parent": null,
      "max_model_len": 131072
    }
  ]
}

这一步很有价值，因为它直接告诉你：

服务起来了
模型已经被识别
OpenAI 风格接口已经可调用

5.2 再测聊天接口

课程里的非流式测试命令类似：

curl http://localhost:30000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "/data/ModelScope/Deepseek-Qwen",
    "messages": [{"role": "user", "content": "你好"}],
    "temperature": 0,
    "max_tokens": 100
  }'

客户端的典型输出类似：

{
  "id":"9ba9dfc4c8c84bc38dec2b36d1afcaf0",
  "object":"chat.completion",
  "created":1769077909,
  "model":"/data/ModelScope/Deepseek-Qwen",
  "choices":[
    {
      "index":0,
      "message":{
        "role":"assistant",
        "content":"你好！很高兴见到你，有什么我可以帮忙的吗？"
      },
      "finish_reason":"stop"
    }
  ]
}

5.3 测一下流式响应

课程里还给了流式测试方式：

curl http://localhost:30000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer sk-dummy-key" \
  -d '{
    "model": "/data/ModelScope/Deepseek-Qwen",
    "messages": [{"role": "user", "content": "用100字简单介绍北京"}],
    "temperature": 0,
    "max_tokens": 200,
    "stream": true
  }'

只要你能持续收到返回分片，就说明流式能力也是通的。

6. 本地接入 Open WebUI：把能力变成可交互界面

如果你想更直观体验 SGLang 的后端能力，最直接的方式就是接 Open WebUI。

6.1 安装 Open WebUI

在同一个 Conda 环境里，课程里的步骤是：

conda activate SGLang
pip install open-webui
export HF_ENDPOINT=https://hf-mirror.com
apt-get update && apt-get install -y ffmpeg

6.2 启动 Open WebUI 并指向 SGLang

OPENAI_API_BASE_URL=http://localhost:30000/v1 \
OPENAI_API_KEY=sk-dummy-key \
open-webui serve --host 0.0.0.0 --port 8080

这里最关键的环境变量是：

OPENAI_API_BASE_URL=http://localhost:30000/v1

它告诉 Open WebUI：底层要连接的是 SGLang 暴露出来的 OpenAI 兼容接口。

6.3 验证点

只要浏览器访问：

http://<your-host>:8080

并且界面里能真正对话成功，就说明这条链路已经打通了：

Open WebUI -> SGLang -> DeepSeek 模型

7. Docker 路径：更适合快速复现和减少宿主机污染

当你已经理解了本地路径之后，Docker 会成为更实用的一条路。
原因和 vLLM 那篇几乎一样：

环境更容易固化
迁移更容易
不需要把大量 Python 依赖直接堆在宿主机

7.1 先确认 Docker 和 GPU 运行时正常

在真正跑 SGLang 镜像前，课程里先用标准 CUDA 镜像测试 GPU 透传：

docker run --rm --gpus all nvidia/cuda:12.1.1-base-ubuntu22.04 nvidia-smi

课程里的典型输出类似：

Fri Jan 16 04:41:22 2026
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 580.95.05              Driver Version: 580.95.05      CUDA Version: 13.0     |
|  0   NVIDIA A10                      Off | 00000000:00:03.0 Off  |                    0 |
+-----------------------------------------------------------------------------------------+

只要这一步不通，就先不要继续怀疑 SGLang 本身，先回头检查 Docker 和 NVIDIA Container Toolkit。

7.2 拉镜像并启动容器

课程里的最直接做法是：

docker pull lmsysorg/sglang:latest
docker save lmsysorg/sglang:latest | gzip > sglang_latest.tar.gz
docker load -i sglang_latest.tar.gz

启动命令如下：

docker run --gpus all -p 8123:8123 \
  -v /data/ModelScope/Deepseek-Qwen:/model \
  lmsysorg/sglang:latest \
  python -m sglang.launch_server --model-path /model --host 0.0.0.0 --port 8123

这里最关键的参数有：

--gpus all：允许容器访问宿主机所有 GPU
-p 8123:8123：把容器内服务端口映射到宿主机
-v /data/ModelScope/Deepseek-Qwen:/model：把宿主机模型目录挂进容器

7.3 Docker 路线下要重点看什么

至少先看这两类信息：

docker ps
docker logs <container-id-or-name> --tail 50

如果容器启动后立刻退出，先别急着怀疑模型问题，优先看日志。

8. Docker Compose 路径：方便把 SGLang 和 Open WebUI 一起跑

课程里还给了一条更适合组合体验的路线：
直接用 docker-compose 同时编排 SGLang 和 Open WebUI。

8.1 安装 Docker Compose

wget https://github.com/docker/compose/releases/download/v2.32.1/docker-compose-linux-x86_64
chmod +x docker-compose-linux-x86_64
mv docker-compose-linux-x86_64 /usr/local/bin/docker-compose
docker-compose version

8.2 一个典型的 Compose 思路

课程里的结构是：

一个 sglang-backend
一个 open-webui

开头大致类似：

version: '3.8'
services:
  sglang-backend:
    image: lmsysorg/sglang:latest
    container_name: sglang_backend
    runtime: nvidia
    environment:
      - NVIDIA_VISIBLE_DEVICES=all

对你来说，更重要的不是逐字照抄，而是理解这条路线的价值：

SGLang 提供后端推理服务
Open WebUI 提供交互界面
两者通过容器网络连起来

8.3 Compose 路线适合什么场景

它特别适合：

单机演示环境
快速复现实验
内部验证复杂对话和能力体验

9. SGLang 的能力体验，重点应该看什么

SGLang 真正有价值的地方，不只是“能返回一句话”，而是它更适合复杂推理和多步骤场景。

不过在起步阶段，最实用的体验方式还是先把下面三件事做扎实：

9.1 模型列表接口通

这说明：

服务起来了
模型被识别了
OpenAI 风格接口已经可用

9.2 聊天接口通

这说明：

模型推理链路通了
请求和响应格式已经可供应用对接

9.3 Open WebUI 能连上

这说明：

不是只有后端 API 可用
你已经具备把它当成应用后端使用的基础条件

10. GPU 运维动作，SGLang 这条路特别值得养成习惯

课程里专门补了一块 GPU 运维内容，这一点非常有价值。

因为 SGLang 这类复杂推理框架在反复实验时，很容易出现“服务没问题，但显存没清干净”的情况。

10.1 看 GPU 上到底是谁在占资源

nvidia-smi | grep -A 10 "Processes"

10.2 清理残留进程

kill -9 <PID>
pkill -f sglang
pkill -f python

10.3 清理 PyTorch 缓存

python -c "import torch; torch.cuda.empty_cache()"

10.4 观察 GPU 利用率

在 Docker Compose 场景里，课程里还给了一个很实用的查看方式：

watch -n 1 nvidia-smi

或者一次性查看：

nvidia-smi --query-gpu=index,name,utilization.gpu,memory.used,memory.total --format=csv

课程里的典型输出类似：

index, name, utilization.gpu [%], memory.used [MiB], memory.total [MiB]
0, NVIDIA A10, 0 %, 22509 MiB, 24564 MiB
1, NVIDIA A10, 0 %, 22509 MiB, 24564 MiB

这类输出对排查“服务起来了但显存异常”非常有帮助。

11. 本地和 Docker，两条路径到底先用哪个

这和 vLLM 那篇的判断逻辑很像，但侧重点稍有不同。

11.1 本地路径更适合什么

本地路径更适合：

理解 SGLang 本身的定位
看清启动日志和能力特征
排查模型、CUDA、PyTorch 这一层的问题

11.2 Docker 路径更适合什么

Docker 路径更适合：

快速复现
单机演示
避免宿主机环境污染
更容易把 Open WebUI 一起串起来

如果用一句话概括：

本地路径帮助你吃透 SGLang，Docker 路径帮助你更轻松地把它展示出来。

12. 最常见的几类问题，通常卡在这几个地方

12.1 服务日志很多，看起来像卡住了

尤其是第一次启动时，SGLang 可能会输出大量 GPU 初始化日志。
这不一定是异常，重点要看有没有这些信号：

Application startup complete
Uvicorn running on ...
The server is fired up and ready to roll!

12.2 `/v1/models` 通了，但聊天接口不通

这通常说明：

服务启动了
但模型推理链路可能还没完全稳定

优先检查：

模型路径是否正确
显存是否充足
请求里的 model 字段是否和实际加载模型一致

12.3 容器启动了，但性能很差

这时候优先怀疑的通常不是 SGLang 本身，而是：

GPU 透传没生效
容器实际跑在 CPU 路径上
--gpus all 或运行时配置有问题

先回到最基础的验证：

docker run --rm --gpus all nvidia/cuda:12.1.1-base-ubuntu22.04 nvidia-smi

12.4 Open WebUI 能打开，但模型对话失败

优先检查：

OPENAI_API_BASE_URL 是否正确指向 SGLang 的 /v1
OPENAI_API_KEY 是否和服务要求一致
curl http://localhost:30000/v1/models 是否本身已经正常

13. 结语：SGLang 更像是通往复杂 AI 应用的一步

把这篇走完之后，你会很明显地感受到一件事：

SGLang 和 vLLM 的差异，不是在“能不能起服务”这一层，而是在“你想让模型承接多复杂的任务”这一层。

到这里为止，这一篇解决的是：

SGLang 为什么值得单独写一条路线
本地和 Docker 两种方式怎么跑通
如何通过模型接口、聊天接口和 Open WebUI 做能力体验

如果再往前走一步，问题就会从“单机上怎么跑通”升级为：

怎么把它放进 K8S
怎么接上存储和入口
怎么把 GPU 运维和服务暴露都平台化

下一篇文章，我们就继续沿着这条路往前走：
把 SGLang 部署到 K8S，接上 Open WebUI、Gateway 和 GPU 运维链路，形成一套真正可对外使用的集群服务。

SGLang 私有化部署实战：本地部署、Docker 部署、能力体验

摘要

系列导航

1. 为什么 SGLang 不是“另一个 vLLM”

1.1 SGLang 更像“智能加速器”

1.2 那么 vLLM 和 SGLang 到底怎么选

2. 开始之前，还是先确认底层环境已经打通

3. 本地部署路径：最适合理解 SGLang 的运行链路

3.1 准备 Miniconda 环境

3.2 创建 SGLang 专用环境

3.3 安装 PyTorch 和 SGLang

3.4 准备模型目录

4. 用本地方式启动 SGLang

4.1 启动服务

4.2 正常启动时日志长什么样

4.3 日志里那些看起来很“重”的信息意味着什么

5. 本地能力验证：不要只看进程，要看 API

5.1 先看模型列表接口

5.2 再测聊天接口

5.3 测一下流式响应

6. 本地接入 Open WebUI：把能力变成可交互界面

6.1 安装 Open WebUI

6.2 启动 Open WebUI 并指向 SGLang

6.3 验证点

7. Docker 路径：更适合快速复现和减少宿主机污染

7.1 先确认 Docker 和 GPU 运行时正常

7.2 拉镜像并启动容器

7.3 Docker 路线下要重点看什么

8. Docker Compose 路径：方便把 SGLang 和 Open WebUI 一起跑

8.1 安装 Docker Compose

8.2 一个典型的 Compose 思路

8.3 Compose 路线适合什么场景

9. SGLang 的能力体验，重点应该看什么

9.1 模型列表接口通

9.2 聊天接口通

9.3 Open WebUI 能连上

10. GPU 运维动作，SGLang 这条路特别值得养成习惯

10.1 看 GPU 上到底是谁在占资源

10.2 清理残留进程

10.3 清理 PyTorch 缓存

10.4 观察 GPU 利用率

11. 本地和 Docker，两条路径到底先用哪个

11.1 本地路径更适合什么

11.2 Docker 路径更适合什么

12. 最常见的几类问题，通常卡在这几个地方

12.1 服务日志很多，看起来像卡住了

12.2 /v1/models 通了，但聊天接口不通

12.3 容器启动了，但性能很差

12.4 Open WebUI 能打开，但模型对话失败

13. 结语：SGLang 更像是通往复杂 AI 应用的一步

评论区

12.2 `/v1/models` 通了，但聊天接口不通