高级 12 分钟部署

SGLang:为多人提供本地 LLM 服务 utilisateurs

直接回答

SGLang 是为多个用户同时使用而设计的推理服务器:它通过 uv 安装,一条命令即可启动并在端口 30000 上提供服务,其在负载下的吞吐量得益于 RadixAttention(前缀缓存)和请求的连续调度。它需要较新的 CUDA GPU,因此适合作为共享服务器工具,而不是单用户个人电脑上 Ollama 的替代品。

SGLang 是由 LMSYS 社区开发的推理服务器框架,旨在同时处理多个请求时提供高吞吐量、低延迟的服务。本指南介绍其安装方法、RadixAttention 的工作原理、需要了解的并发调节手段,以及如何根据实际需要服务的用户数量,在 SGLang、vLLM 和 Ollama 之间作出选择。

作者: Mohamed Meguedmi·更新于 2026-09-28·已在 Windows、macOS 和 Linux 上测试

#SGLang 能做什么

SGLang 是一个高性能的 LLM 和多模态模型服务框架,专为单 GPU 到大规模分布式集群的低延迟、高吞吐量推理而设计。该项目声称在全球超过 40 万块 GPU 上实现每日万亿级 token 的生产部署,并由非营利性开源组织 LMSYS 提供托管。

SGLang 兼容 OpenAI 和 Hugging Face 的 API,支持多种模型(Llama、Qwen、DeepSeek、GLM、Mistral、Gemma)和硬件(NVIDIA GPU、AMD GPU、Intel Xeon CPU、Google TPU、Ascend NPU)。截至 2026 年 9 月 28 日,最新版本为 v0.5.20,发布于 2026 年 9 月 18 日。

i
SGLang并非Ollama的直接替代方案
SGLang 面向在服务器硬件上为多个用户提供服务的场景。它甚至提供与 Ollama 客户端兼容的 API,以方便迁移现有工具,但它既不会安装 Ollama,也不会替代 Ollama 本身。

#安装并启动服务器

企业本地 AI 套件

在工作场所部署本地 AI:GDPR、AI 法案、多用户架构、成本、供管理层参考的说明材料。

  • 在线空间,终身可用
  • PDF + 文件
  • 30 天内退款

官方文档推荐使用 uv 进行安装,其速度优于传统的 pip。由于 SGLang 的部分依赖项仅在 PyPI 上提供预发布版本,因此必须使用 --prerelease=allow 标志。

安装
pip install --upgrade pip
pip install uv
uv pip install --prerelease=allow sglang

对于服务器部署,在 Docker 容器中启动仍是最具可复现性的方式,API 默认使用 30000 端口。

Docker
docker run --gpus all \
    --shm-size 32g \
    -p 30000:30000 \
    -v ~/.cache/huggingface:/root/.cache/huggingface \
    --env "HF_TOKEN=<secret>" \
    --ipc=host \
    lmsysorg/sglang:latest \
    python3 -m sglang.launch_server --model-path meta-llama/Llama-3.1-8B-Instruct --host 0.0.0.0 --port 30000

文档明确指出,SGLang 现在要求 CUDA 13:自 PyTorch 2.14 不再发布 CUDA 12.9 构建版本以来,CUDA 12 的镜像和 wheel 安装包(cu129)已被移除,而 0.5.19 仍是最后一个提供 CUDA 12 支持路径的版本。因此,在较旧硬件上部署时,必须锁定该版本,或在更新前检查 GPU 驱动。

#RadixAttention与前缀缓存

SGLang 承诺的吞吐量提升,其核心是 RadixAttention:已经计算过的序列前缀(共享的系统提示词、多轮对话的开头)会被组织到基数树中,并在不同请求之间复用,而不是每次调用都重新计算。项目在 2024 年 1 月的最初公告中声称,这一机制可使推理速度最高达到原来的 5 倍——这是项目当时在自身测试平台上公布的数据,并非近期在您的硬件上进行的独立测量结果。

这种性能提升主要有利于共享前缀的场景:多个用户使用同一系统提示发起查询,智能体在每轮交互中重新读取同一上下文,或在少样本提示中使用相同的示例。完全没有共同前缀的请求流(问题完全独立,且没有历史记录)从 RadixAttention 中获得的收益则要小得多。

→
惊讶梯度
RadixAttention 的性能提升直接取决于请求之间共享前缀 token 的比例。如果每个用户都有独立且不同的长系统提示,即使启用了该功能,也会大幅损失缓存的优势。

运行时结合了 RadixAttention、零开销 CPU 调度器、预填充与解码分离(prefill-decode)、推测解码、请求的连续调度(continuous batching)以及分页注意力(paged attention)——这是多种优化技术的组合,而非单一机制。

#调整并发数和内存

三个启动参数决定 SGLang 如何同时处理多个用户的请求。--mem-fraction-static 设置为模型权重和 KV 缓存预留的显存比例;文档建议在出现显存不足错误时降低该比例,否则该比例会根据可用显存自动计算。

需了解的并发参数
参数角色
--max-running-requests同时处理的最大请求数量(默认无限制)
--max-queued-requests等待处理的请求数量上限
--schedule-policy请求调度策略:默认为fcfs(先到先服务),或lpm、random、dfs-weight、lof、priority、routing-key
--chunked-prefill-size将预填充过程分割为片段,以避免长请求阻塞其他请求

未对 --max-running-requests 设置明确限制,SGLang 接受的请求数量由 KV 缓存的内存容量决定,高负载下可能导致单次请求延迟升高,而非优雅地拒绝新连接。在向真实多用户开放服务前,应首先设置一个与可用 VRAM 相匹配的明确限制。

#何时选择SGLang而非vLLM或Ollama

三个工具满足不同的需求。Ollama 面向单用户个人使用,强调操作简便;SGLang 和 vLLM 则针对多用户 GPU 服务器服务场景,采用相似理念(前缀缓存、连续批处理),但各自拥有独立的历史发展和生态系统。

单用户,个人电脑
Ollama 或 llama.cpp 仍更容易安装,也更容易在消费级 CPU 或 GPU 上运行,无需配置网络服务。
多个用户,已存在基于vLLM的系统
继续使用vLLM可避免迁移;我们专门的指南涵盖了其在生产环境中的部署。
多用户使用,共享前缀时优先考虑吞吐量
具备 RadixAttention 的 SGLang 是很合适的候选方案——前提是您拥有兼容的 CUDA GPU。
希望兼容 Ollama 客户端,但不安装 Ollama
SGLang 提供与 Ollama CLI 和 Ollama Python 库兼容的 API,因此可以复用现有脚本,而无需运行 Ollama 服务器本身。

如果想更全面地了解推理架构(llama.cpp、vLLM、Exllama),本站的后端对比文章详细介绍了各种取舍,讨论范围不限于 SGLang。

#硬件带来的限制

SGLang 的快速入门指南明确指出:Linux 是推荐平台,在 Linux 上采用标准安装方式的前提是配备支持 CUDA sm80 或更高计算能力的 NVIDIA GPU(A10、A100、L4、L40S、H100)。此外,该项目表示还支持更广泛的硬件——AMD GPU(MI355、MI300)、Intel Xeon CPU、Google TPU、Ascend NPU——但需采用各自专用的安装方式,这些方式与主要的 NVIDIA GPU 安装路径不同。

!
默认并不是面向纯 CPU 运行的工具
与 llama.cpp 或 Ollama 不同,SGLang 的设计并未优先考虑在没有独立 GPU 的情况下运行。在 Mac 上,或在没有较新 NVIDIA 显卡的 PC 上,Ollama 或 LM Studio 仍是默认选择;SGLang 在面向多用户的专用 GPU 服务器上最能体现其价值。

#每次请求的内存开销

“为多个用户提供服务”具体意味着:显存用量不仅随模型大小变化,也会随活跃请求数量增加。由 --mem-fraction-static 和 --max-total-tokens 管理的 KV 缓存,会针对每个请求中已经生成的每个 token,在每一层注意力中存储两个向量(键和值)。通用公式为:每个 token 的字节数 = 2 × 层数 × KV 注意力头数 × 每个头的维度 × 每个值的字节数(FP16/BF16 为 2,FP8 为 1)。

以接近 Llama-3.1-8B-Instruct 的架构为例(32 层,分组查询注意力中有 8 个 KV 头,每个头的维度为 128):在 FP16 下,每个 token 占用 2 × 32 × 8 × 128 × 2 = 131 072 字节,约合每个 token 128 KB。对于上下文共计 8 192 个 token 的请求(提示与回复合计),仅这一请求的 KV 缓存就占用约 1 GB 显存——这还没有计入模型权重。在一块显存为 24 GB 的 GPU 上,如果约 16 GB 已预留给 Q4 模型权重和运行时的基础开销,那么剩余空间在这一上下文长度下只能容纳少数几个同时处于活动状态的请求。这也解释了为什么需要明确设置 --max-running-requests 上限:否则可能出现性能退化,而不是有序地拒绝新的连接。

→
仅供数量级参考,并非实测值
该计算是基于模型架构的理论估算,而非在实际 SGLang 部署中测得的数值:模型实际支持的并发请求数量还取决于加载的模型、实际上下文长度以及 --mem-fraction-static 参数。

#安全与可观测性

默认情况下,通过 sglang.launch_server 启动的 SGLang API 不要求身份验证:任何能访问 30000 端口的人都可以发送请求。--api-key 选项设置服务器要求调用方提供的密钥,其兼容 OpenAI 的端点也要求该密钥;如果不设置密钥,将服务器暴露在 localhost 或可信内部网络之外,就等于向外开放推理访问,也让他人能够产生相应的 GPU 费用。

生产环境监控中,启用 --enable-metrics 选项(默认关闭)可将Prometheus格式的指标发布至 /metrics 接口,暴露请求速率、推理延迟、token生成速度以及缓存效率等数据,便于定期抓取,而非仅通过日志推测服务器状态。

#故障排除:症状、原因、修复方法

多用户服务中的常见症状
问题表现可能原因修正
启动时出现内存不足错误(out of memory)--mem-fraction-static 自动计算出的值相对于实际可用显存过高按照官方文档的建议,显式调低 --mem-fraction-static 参数的值
在高负载下延迟急剧上升且无错误--max-running-requests 未设上限:只要 KV 缓存容量允许,服务器就会继续接受请求根据可用 VRAM 和上述每请求成本计算,调整 --max-running-requests 参数
更新后安装或启动失败升级到了要求 CUDA 13 的版本,但驱动程序仍停留在 CUDA 12将版本固定为 0.5.19(最后一个支持 CUDA 12 的版本),或先更新 GPU 驱动,再更新 SGLang
可从网络访问且没有访问控制的服务器未定义密钥:--api-key 默认为空在将服务器暴露到非可信网络之前,请先设置 --api-key

#限制与注意事项

RadixAttention 的介绍中至今仍出现的“速度最高提升至原来的 5 倍”这一数字,源自该项目于 2024 年 1 月首次公布时的说明:它体现的是这一机制在当时测试平台上的提升,并不保证近期使用不同模型和 GPU 的部署也能获得同样的收益。实际部署所需的资源取决于请求之间的前缀共享率、所选模型以及使用的 GPU——应使用自己的实际流量进行测量,而不是根据最初的公告推断。

必须升级到CUDA 13(版本0.5.19是最后支持CUDA 12的版本),在升级到较新版本前,需检查GPU驱动和已安装的CUDA版本,否则在仍使用CUDA 12的服务器上可能导致安装失败。

对于生产环境部署,项目的发布节奏也值得关注:SGLang 大约每两到三周发布一个次要版本(2026 年 9 月 18 日的 v0.5.20,9 月 5 日的 v0.5.19,8 月 22 日的 v0.5.18),这要求在 Docker 镜像中固定特定版本,而不是在生产服务中跟踪 latest 标签,以免在重新部署时出现未预期的行为变更。

常见问题
SGLang会替代Ollama吗?+
不,这是两个不同的工具。Ollama 面向工作站上的个人单用户使用,上手门槛很低;SGLang 面向利用服务器 GPU 同时为多个用户提供服务的场景,需要更深入的配置。SGLang 甚至提供与 Ollama 客户端兼容的 API,而后端实际上并不运行 Ollama——这便于复用现有脚本,无需迁移整套工具链。
运行 SGLang 是否需要 GPU?+
官方快速入门指南要求 Linux 下的标准运行方式使用支持 CUDA sm80 或更高架构的 NVIDIA GPU(A10、A100、L4、L40S、H100)。AMD、Intel Xeon、TPU 或 NPU 也各有独立的运行方式,但 SGLang 的设计并非优先面向个人电脑上仅使用 CPU 的场景:这种情况下,Ollama 或 llama.cpp 仍更合适。
RadixAttention 对所有请求的加速效果都一样吗?+
不会。收益取决于各请求之间共享的前缀 token 数量:多个用户共用的系统提示词,或每轮对话都会复用的对话历史,都能从中大幅受益。完全独立、彼此没有任何共同前缀的请求,受益则小得多,即使服务器上的这一机制仍然启用。
使用SGLang为多个用户服务时,应优先调整哪个参数?+
--max-running-requests,用于设定明确的请求上限,与可用VRAM及每个活跃请求的KV缓存开销相匹配。若不设置此限制,SGLang会持续接受请求,只要KV缓存允许,这在高负载下可能导致请求延迟增加,而非优雅地拒绝额外连接。
SGLang 是否能在仅支持 CUDA 12 的旧款 GPU 上运行?+
不支持较新版本。SGLang 现在要求 CUDA 13;版本 0.5.19 是最后一个支持 CUDA 12 的版本:若服务器仍使用 CUDA 12 驱动,必须保持该版本或更新 GPU 驱动,否则无法安装更晚版本的 SGLang,安装将失败。
单次请求的 KV 缓存占用多少 GPU 内存?+
这取决于具体模型和上下文长度,但可大致估算:对于接近 Llama-3.1-8B(32 层,8 个 KV 头)的架构,8192 个 token 的上下文在 FP16 下约需 1 GB 显存,尚未计算模型权重。转为 FP8 时,该数值将减半。
如何保障暴露在网络上的SGLang服务器的安全?+
设置 --api-key 以在所有请求(包括兼容OpenAI的端点)中强制令牌认证;若不启用此选项,服务器将对访问端口30000的任何人开放。单独启用 --enable-metrics 可通过Prometheus监控吞吐量和延迟,避免将可观测性与访问控制混淆。

这份指南对您有帮助吗?

有反馈、发现了错误,或想补充说明?请告诉我们,让这份指南对每个人都更有帮助。