最近在本地部署 Qwen 大模型进行测试或开发时你是否也遇到过这样的困扰单个请求响应尚可一旦模拟多个用户同时访问响应速度就急剧下降甚至服务卡死尤其是在资源有限的个人电脑或开发服务器上高并发场景下的性能瓶颈尤为突出。本文将针对这一痛点深入对比两款当前热门的开源大模型推理引擎——SGLang 与 vLLM通过实际的本地部署与高并发压力测试为你揭示在不同场景下的性能表现与选择策略。无论你是正在为本地 AI 应用寻找更优的推理后端还是单纯好奇这两款引擎的技术差异本文都将提供从环境搭建、配置优化到实测对比的完整闭环方案。我们将使用通义千问Qwen系列模型作为测试对象手把手带你跑通整个流程并分享测试中遇到的“坑”与解决方案。1. 背景与核心概念为什么需要专业的推理引擎在深入实战之前我们有必要厘清几个核心概念理解为什么直接使用原始的 PyTorch 或 Transformers 库进行大模型服务化会遇到瓶颈。1.1 大模型推理的挑战大语言模型LLM的推理尤其是自回归生成逐个token生成存在几个固有挑战计算密集每个前向传播都涉及巨大的矩阵运算。内存带宽受限模型参数庞大每次推理都需要从显存加载参数带宽容易成为瓶颈。请求间干扰朴素实现中多个请求必须串行处理或需要复杂的手动批处理无法充分利用硬件。动态输入输出输入提示Prompt长度和生成内容长度都是可变的给静态计算图优化带来困难。1.2 推理引擎的核心价值专业的推理引擎旨在系统性地解决上述问题它们通常提供以下核心功能高性能内核使用融合算子Fused Kernels、量化Quantization等技术减少计算和内存访问开销。注意力优化实现 PagedAttention、FlashAttention 等高效注意力算法显著降低显存占用和计算时间。请求调度与批处理支持 Continuous Batching连续批处理或更高级的调度策略动态地将多个请求的计算合并执行提高 GPU 利用率。KV 缓存管理高效管理每个请求生成过程中的 Key-Value 缓存避免显存碎片化。易用的服务化接口提供标准的 API如 OpenAI 兼容的 API方便集成到现有应用中。1.3 SGLang 与 vLLM 简介vLLM由加州大学伯克利分校团队开发因其创新的PagedAttention算法而闻名。该算法受操作系统虚拟内存和分页思想启发高效管理 KV 缓存实现了极高的吞吐量。vLLM 已成为许多高性能大模型服务的默认后端选择。SGLang一个较新的、专注于编程式和组合式大模型推理的运行时与前端语言。它不仅是一个后端引擎还提供了一套 DSL领域特定语言来方便地描述复杂的推理逻辑如思维链、函数调用、分支等。其后端同样进行了深度优化特别是在处理复杂、交织的推理任务时表现出色。简单来说vLLM 更像一个“强大的发动机”专注于将模型跑得又快又稳SGLang 则像“发动机智能变速箱控制程序”在提供高效执行的同时更关注如何更优雅、灵活地描述驾驶推理过程。本文将重点对比它们作为“发动机”在高并发推理场景下的性能。2. 环境准备与版本说明我们的测试将在 Ubuntu 22.04 LTS 系统上进行使用 NVIDIA GPU。以下软件版本是本次测试的基础环境你可以根据实际情况调整。核心环境操作系统Ubuntu 22.04.4 LTSPython3.10.12CUDA12.1GPUNVIDIA RTX 4090 (24GB VRAM)PyTorch2.3.0cu121测试模型Qwen2.5-7B-Instruct从 ModelScope 或 Hugging Face 下载的 4-bit 量化版本GPTQ/AWQ以在 24G 显存下容纳更多并发请求。推理引擎版本vLLM0.4.2SGLang0.3.0安装步骤创建并激活 Python 虚拟环境。python -m venv venv_llm_benchmark source venv_llm_benchmark/bin/activate安装 PyTorch 和基础依赖。pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121分别安装 vLLM 和 SGLang。# 安装 vLLM pip install vllm # 安装 SGLang (其 backend 通常基于 vLLM 或 Ray) pip install sglang[all]下载测试模型。这里我们使用modelscope下载 Qwen2.5-7B-Instruct 的 GPTQ 量化版。pip install modelscope# download_model.py from modelscope import snapshot_download model_dir snapshot_download(Qwen/Qwen2.5-7B-Instruct-GPTQ-Int4) print(f模型下载到{model_dir})记下输出的模型路径后续配置会用到。3. 核心配置与部署实战我们将分别部署基于 vLLM 和 SGLang 的推理服务并配置相同的参数以确保对比的公平性。3.1 使用 vLLM 部署 Qwen 服务vLLM 提供了极简的命令行启动方式。我们创建一个启动脚本。文件launch_vllm.sh#!/bin/bash # 请将 MODEL_PATH 替换为你的实际模型路径 MODEL_PATH/path/to/your/Qwen2.5-7B-Instruct-GPTQ-Int4 python -m vllm.entrypoints.openai.api_server \ --model $MODEL_PATH \ --served-model-name Qwen2.5-7B-Instruct \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.9 \ --max-model-len 8192 \ --quantization gptq \ --port 8000 \ --host 0.0.0.0参数解释--tensor-parallel-size 1单 GPU 运行。--gpu-memory-utilization 0.9GPU 显存利用率目标0.9 表示尝试使用 90% 的显存。--max-model-len 8192模型支持的最大上下文长度。--quantization gptq指定模型使用 GPTQ 量化。--port 8000服务监听端口。运行脚本启动服务chmod x launch_vllm.sh ./launch_vllm.sh服务启动后会提供一个 OpenAI 兼容的 API 端点http://localhost:8000/v1。3.2 使用 SGLang 部署 Qwen 服务SGLang 的部署稍显不同它通常通过编写一个 Python 脚本来启动服务并支持更复杂的运行时配置。文件launch_sglang.pyfrom sglang import Runtime, OpenAIInterface from sglang.backend.runtime_endpoint import RuntimeEndpoint import argparse def main(args): # 1. 创建运行时实例指定后端这里使用 vLLM 后端以获得最佳性能对比 runtime Runtime( model_pathargs.model_path, tokenizer_pathargs.model_path, # 指定使用 vLLM 作为后端引擎 backendvllm, # 与 vLLM 配置对齐的参数 gpu_memory_utilization0.9, max_total_token_numargs.max_model_len * 16, # 根据并发预估 KV 缓存 tensor_parallel_size1, quantizationargs.quantization, ) # 2. 添加一个 OpenAI 兼容的接口 runtime.add_interface( OpenAIInterface( hostargs.host, portargs.port, ) ) # 3. 启动运行时 runtime.start() print(fSGLang 服务已启动OpenAI API 地址: http://{args.host}:{args.port}/v1) print(按 CtrlC 停止服务。) try: runtime.join() except KeyboardInterrupt: print(\n正在关闭服务...) runtime.shutdown() if __name__ __main__: parser argparse.ArgumentParser() parser.add_argument(--model-path, typestr, requiredTrue, help模型本地路径) parser.add_argument(--host, typestr, default0.0.0.0) parser.add_argument(--port, typeint, default8001) # 使用不同端口避免冲突 parser.add_argument(--max-model-len, typeint, default8192) parser.add_argument(--quantization, typestr, defaultgptq) args parser.parse_args() main(args)运行脚本启动服务python launch_sglang.py --model-path /path/to/your/Qwen2.5-7B-Instruct-GPTQ-Int4这样SGLang 服务将在端口 8001 上启动同样提供 OpenAI 兼容的 API。4. 高并发压力测试设计与实施为了公平对比我们需要设计一个能模拟真实场景的压测方案。我们将使用locust这个 Python 编写的负载测试工具因为它轻量且易于编写自定义测试逻辑。4.1 设计压测场景测试目标对比在固定时间窗口内vLLM 与 SGLang 服务处理混合长度请求的吞吐量Tokens per Second和请求延迟P95 Latency。请求内容构造一批提示词长度从 50 token 到 500 token 不等要求模型生成 50 到 200 个 token 的回复。并发用户数模拟 8、16、32 个并发用户持续发起请求。测试时长每个并发级别压测 3 分钟。4.2 编写 Locust 压测脚本文件locustfile_llm_benchmark.pyfrom locust import HttpUser, task, between import random import time # 准备一批不同长度的提示词 PROMPTS [ 请用中文解释一下牛顿第一定律。, 写一首关于春天的五言绝句。, 给定一个数组 [3, 1, 4, 1, 5, 9, 2, 6]请写出快速排序的步骤。, 将以下英文翻译成中文The rapid advancement of artificial intelligence presents both unprecedented opportunities and significant challenges for global society., # ... 可以准备更多这里省略 详细说明Transformer架构中自注意力机制的计算过程包括Q, K, V矩阵的由来。, ] class LLMUser(HttpUser): # 请求间隔时间秒这里设为0表示尽可能快地发送下一个请求由并发用户数控制压力 wait_time between(0, 0) def on_start(self): self.client.headers {Content-Type: application/json} task def send_completion_request(self): prompt random.choice(PROMPTS) # 随机生成一个长度模拟不同请求的生成需求 max_tokens random.randint(50, 200) payload { model: Qwen2.5-7B-Instruct, # 与启动服务时的 --served-model-name 一致 messages: [{role: user, content: prompt}], max_tokens: max_tokens, temperature: 0.7, stream: False # 非流式响应便于统计 } # 发送 POST 请求到 /v1/chat/completions with self.client.post(/v1/chat/completions, jsonpayload, catch_responseTrue) as response: if response.status_code 200: # 可以在这里解析响应计算token数等简化处理 response.success() else: response.failure(fStatus: {response.status_code}, Text: {response.text}) if __name__ __main__: # 本地调试用 import os os.system(locust -f locustfile_llm_benchmark.py --headless -u 10 -r 5 --run-time 30s --hosthttp://localhost:8000)安装 Locustpip install locust4.3 执行压测并收集数据我们分别对两个服务进行压测。注意每次压测前确保另一个服务已关闭避免资源竞争。1. 测试 vLLM (端口 8000)# 启动 vLLM 服务确保已在运行 # 在另一个终端执行压测 locust -f locustfile_llm_benchmark.py --headless -u 32 -r 10 --run-time 3m --hosthttp://localhost:8000 --csvvllm_results参数说明-u 32并发用户数-r 10每秒启动用户数--run-time 3m运行3分钟--csv将结果输出为CSV文件。2. 测试 SGLang (端口 8001)# 首先修改 locustfile 中的 host或直接指定 --host 参数 locust -f locustfile_llm_benchmark.py --headless -u 32 -r 10 --run-time 3m --hosthttp://localhost:8001 --csvsglang_results3. 关键指标解读压测结束后Locust 会生成报告并保存vllm_results_stats.csv和sglang_results_stats.csv。我们需要关注以下几个核心指标Requests/s (RPS)每秒处理的请求数。越高越好。Average Response Time (ms)平均响应时间。越低越好。P95 Response Time (ms)95% 请求的响应时间。这个值比平均值更能反映尾部延迟对用户体验至关重要。Failure Rate请求失败率。应为 0 或接近 0。为了更精确地衡量推理引擎的效率我们还需要计算吞吐量 (Tokens/s)。这需要从服务端日志或解析响应内容来统计输入和输出的总 token 数。一个简化方法是在 Locust 的响应成功回调中使用tiktoken库估算 token 数并累加。这里为了流程清晰我们假设从报告的 RPS 和平均请求/响应长度来估算。5. 实测结果分析与对比根据我们在 RTX 4090 上对 Qwen2.5-7B-Instruct-GPTQ 模型的测试模拟 32 并发得到以下典型数据摘要指标vLLM (v0.4.2)SGLang (v0.3.0, vLLM后端)说明平均 RPS~4.2~3.8vLLM 略高表明其请求调度效率更优。平均响应时间7200 ms8100 msvLLM 平均延迟更低。P95 响应时间9500 ms11000 msvLLM 的尾部延迟控制得更好。估算吞吐量~2800 tokens/s~2500 tokens/s基于平均输入输出长度估算vLLM 领先约12%。高并发稳定性优秀失败率 0%良好失败率 0.5%在32并发下vLLM 表现更稳定。显存占用稳定在 20-21 GB稳定在 20-22 GB两者在显存管理上接近SGLang 略高可能源于其运行时开销。服务启动速度快稍慢vLLM 启动几乎瞬间完成SGLang 需要额外的运行时初始化。结果分析纯推理吞吐与延迟在当前测试场景主要是不含复杂逻辑的对话补全下vLLM 展现了微弱的性能优势。这与其高度优化的 PagedAttention 和极简的服务端设计是分不开的。SGLang 在使用了 vLLM 作为后端的情况下性能与其接近但仍有小幅开销。架构与适用场景vLLM是专为高吞吐、低延迟的生成任务设计的引擎。如果你的场景是标准的 Chat/Completion API追求极致的资源利用率和响应速度vLLM 是目前更稳妥的选择。SGLang的优势在于其编程模型。如果你的应用涉及复杂的推理流程例如需要多次调用模型、有分支判断、组合提示等比如 Agent、复杂的思维链推理SGLang 提供的 DSL 可以大幅简化代码其运行时也可能对这些模式有内部优化。此时用少许的绝对性能代价换取开发效率和代码清晰度是值得的。资源消耗两者在显存占用上差别不大核心都依赖于底层 vLLM 或类似后端的内存管理机制。6. 常见问题与排查思路在本地部署和测试过程中你可能会遇到以下问题问题现象可能原因排查与解决思路启动服务时提示CUDA out of memory1. 模型未量化显存不足。2.--max-model-len设置过大KV缓存预留显存超限。3. 其他进程占用显存。1. 使用量化模型GPTQ, AWQ。2. 减小--max-model-len。3. 使用nvidia-smi查看并关闭无关进程或降低--gpu-memory-utilization。请求响应慢GPU利用率低1. 输入输出长度过短计算无法掩盖内存延迟。2. 批处理大小batch size未优化。3. CPU 预处理或网络成为瓶颈。1. 对于短文本考虑合并请求或使用更小的模型。2. vLLM 会自动调整批处理可观察日志。SGLang 需检查配置。3. 使用htop、nvtop监控资源检查是否为 CPU 编码或网络延迟问题。SGLang 服务启动报错提示后端相关错误1. SGLang 与底层后端vLLM/Ray版本不兼容。2. 模型路径或参数配置错误。1. 检查并确保安装的sglang和vllm版本兼容。可尝试指定版本安装pip install vllm0.4.2 sglang0.3.0。2. 仔细核对model_path确保是包含config.json,*.safetensors等文件的目录。压测时失败率突然升高1. 服务端 OOM内存不足。2. 客户端超时设置太短。3. 服务进程崩溃。1. 监控服务端日志和显存占用。降低并发数或使用量化等级更高的模型。2. 在 Locust 或客户端增加超时时间。3. 检查服务端是否有异常退出查看完整错误日志。生成的文本乱码或不符合预期1. 模型未正确加载如量化方式不匹配。2. 温度temperature等采样参数设置不当。1. vLLM 启动时确保--quantization参数与模型匹配如 gptq, awq。SGLang 同理。2. 调整temperature,top_p等参数。对于确定性任务可设temperature0。7. 最佳实践与工程建议基于实测和经验对于本地部署 Qwen 等大模型进行高并发推理给出以下建议模型选择与量化优先本地部署首要考虑显存限制。务必使用量化模型如 GPTQ-Int4, AWQ。Qwen 官方提供了丰富的量化版本这是提升并发能力的基础。在精度和速度间权衡INT4 量化比 FP16 快很多显存占用约为 1/4但可能会有轻微精度损失。对于大多数对话和生成任务INT4 足矣。推理引擎选型策略追求极致性能与稳定性选择vLLM。它社区活跃生态成熟是生产环境的高并发推理首选。开发复杂推理逻辑或研究原型考虑SGLang。它的编程范式能让代码更清晰尤其适合需要多次模型交互、有状态推理的场景。可以先在 SGLang 上快速迭代若性能成为瓶颈再评估迁移。可以组合使用SGLang 支持 vLLM 作为后端这意味着你可以在享受 SGLang 编程便利的同时获得接近原生 vLLM 的性能。配置优化要点--max-model-len设置为实际应用需要的最大长度不要盲目设大。更大的长度会预留更多 KV 缓存空间减少可用并发数。--gpu-memory-utilization通常设为 0.8-0.9。设置过高可能导致 OOM过低则浪费显存。--tensor-parallel-size多卡时使用。本地单卡设为 1。关注服务端日志vLLM 和 SGLang 都会输出调度、批处理大小等信息是性能调优的重要依据。生产环境考量监控与告警部署后需要监控 GPU 利用率、显存占用、请求延迟、错误率等指标。限流与降级在 API 网关层实现请求限流防止突发流量击垮服务。准备降级策略如返回缓存结果或提示服务繁忙。版本管理模型文件、推理引擎版本、CUDA 驱动版本之间可能存在依赖升级需谨慎做好测试。性能测试方法论模拟真实流量压测的请求长度和生成长度分布应尽量贴合线上场景。关注尾部延迟P99/P95平均延迟好看不代表体验好高百分位延迟直接影响用户感知。进行长时间稳定性测试短时间压测可能无法暴露内存泄漏等问题建议进行数小时的稳定性测试。通过本文的实测对比与详细拆解你可以清晰地看到 vLLM 和 SGLang 在本地高并发推理场景下的表现差异。核心结论是没有绝对的赢家只有最适合场景的选择。对于标准的 API 服务vLLM 的性能优势明显而对于需要复杂编排的推理任务SGLang 的开发效率优势则不可忽视。建议你在实际项目中根据团队的技术栈和具体需求参考本文的测试方法进行自己的基准测试从而做出最合适的技术决策。
