SGLang:为多人提供本地 LLM 服务 utilisateurs
SGLang 是为多个用户同时使用而设计的推理服务器:它通过 uv 安装,一条命令即可启动并在端口 30000 上提供服务,其在负载下的吞吐量得益于 RadixAttention(前缀缓存)和请求的连续调度。它需要较新的 CUDA GPU,因此适合作为共享服务器工具,而不是单用户个人电脑上 Ollama 的替代品。
SGLang 是由 LMSYS 社区开发的推理服务器框架,旨在同时处理多个请求时提供高吞吐量、低延迟的服务。本指南介绍其安装方法、RadixAttention 的工作原理、需要了解的并发调节手段,以及如何根据实际需要服务的用户数量,在 SGLang、vLLM 和 Ollama 之间作出选择。
#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 日。
#安装并启动服务器
在工作场所部署本地 AI:GDPR、AI 法案、多用户架构、成本、供管理层参考的说明材料。
- 在线空间,终身可用
- PDF + 文件
- 30 天内退款
官方文档推荐使用 uv 进行安装,其速度优于传统的 pip。由于 SGLang 的部分依赖项仅在 PyPI 上提供预发布版本,因此必须使用 --prerelease=allow 标志。
对于服务器部署,在 Docker 容器中启动仍是最具可复现性的方式,API 默认使用 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、零开销 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 安装路径不同。
#每次请求的内存开销
“为多个用户提供服务”具体意味着:显存用量不仅随模型大小变化,也会随活跃请求数量增加。由 --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.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 标签,以免在重新部署时出现未预期的行为变更。
- 在生产环境中部署 vLLM
- vLLM:是什么,适合谁,何时使用?
- llama.cpp 与 vLLM、Exllama 对比
- 来源:SGLang 官方文档
- 来源:SGLang 仓库官方 README 文件
- 来源:服务器参数参考
SGLang会替代Ollama吗?+
运行 SGLang 是否需要 GPU?+
RadixAttention 对所有请求的加速效果都一样吗?+
使用SGLang为多个用户服务时,应优先调整哪个参数?+
SGLang 是否能在仅支持 CUDA 12 的旧款 GPU 上运行?+
单次请求的 KV 缓存占用多少 GPU 内存?+
如何保障暴露在网络上的SGLang服务器的安全?+
有反馈、发现了错误,或想补充说明?请告诉我们,让这份指南对每个人都更有帮助。