vLLM与SGLang多模型统一API部署实战指南

1. 为什么需要多模型统一API部署在实际生产环境中我们经常会遇到需要同时部署多个AI模型的场景。比如一个智能客服系统可能需要同时支持问答、情感分析和文本摘要等多个功能每个功能背后可能对应不同的模型。如果每个模型都单独部署一套服务不仅管理起来麻烦还会造成资源浪费。我去年负责过一个电商推荐系统的升级项目最初就是给每个推荐模型商品推荐、搭配推荐、相似推荐都单独部署了服务。结果发现每个服务占用独立的GPU资源但实际利用率不到30%客户端需要维护多个API调用逻辑监控和日志分散在不同服务中排查问题特别费劲后来我们改用vLLMSGLang的统一API方案后资源利用率提升到75%以上运维成本降低了60%。这就是为什么现在越来越多的团队开始采用多模型统一部署方案。2. vLLM多模型部署方案2.1 基础架构设计vLLM本身不直接支持单端口多模型部署但我们可以通过一些架构设计来实现这个需求。目前主流的有两种方案多实例反向代理为每个模型启动独立的vLLM服务通过Nginx等反向代理做路由Ray集群动态路由使用Ray管理多个模型实例通过自定义API服务做动态调度我推荐小型项目用第一种方案中大型项目用第二种。下面详细说说具体实现。2.2 多实例Nginx方案这是最简单的实现方式适合模型数量少、变更不频繁的场景。具体步骤为每个模型启动独立服务# 启动模型1服务 python -m vllm.entrypoints.api_server --model model1 --port 8001 # 启动模型2服务 python -m vllm.entrypoints.api_server --model model2 --port 8002配置Nginx路由规则location /v1/completions { if ($arg_model model1) { proxy_pass http://localhost:8001; } if ($arg_model model2) { proxy_pass http://localhost:8002; } }我在一个客户项目中实测过这种方案3个7B模型在A100上并行运行吞吐量能达到120请求/秒。关键是要设置好--gpu-memory-utilization参数建议从0.7开始调整。2.3 Ray集群方案对于需要动态扩展的场景Ray是更好的选择。它的核心优势是支持动态加载/卸载模型自动负载均衡细粒度的GPU资源分配部署流程初始化Ray集群ray.init(num_gpus4)定义模型服务类ray.remote(num_gpus1) class ModelWorker: def __init__(self, model_name): self.llm LLM(modelmodel_name) def generate(self, prompt): return self.llm.generate(prompt)创建API服务from fastapi import FastAPI app FastAPI() model_pool { model1: ModelWorker.remote(model1), model2: ModelWorker.remote(model2) } app.post(/generate) async def generate(model: str, prompt: str): return await model_pool[model].generate.remote(prompt)这个方案我在多个生产环境部署过最复杂的场景是在8台A100服务器上管理12个不同模型峰值QPS能达到800。关键是要合理设置num_gpus参数确保不会出现资源争抢。3. SGLang多模型部署方案3.1 内置路由功能SGLang相比vLLM最大的优势是原生支持多模型路由不需要额外组件。它的架构设计非常巧妙路由服务负责请求分发和负载均衡每个模型运行在独立进程支持动态注册新模型部署示例# 启动路由服务 python -m sglang_router.launch_router --port 30000 # 启动模型服务 python -m sglang.launch_server --model-path model1 --port 30001 python -m sglang.launch_server --model-path model2 --port 30002客户端调用时只需要指定model参数response requests.post( http://localhost:30000/generate, json{model: model1, prompt: Hello} )3.2 高级路由策略SGLang支持多种智能路由策略这在复杂场景下特别有用基于显存的路由自动将请求路由到显存充足的节点会话亲和性相同会话的请求固定路由到同一实例优先级路由重要请求优先处理配置示例# 启动路由时添加策略参数 python -m sglang_router.launch_router \ --port 30000 \ --route-policy memory_aware \ --affinity-timeout 300我在一个在线教育项目中使用会话亲和性策略将同一学生的提问都路由到同一个模型实例使得对话上下文保持连贯用户体验提升明显。4. 生产环境最佳实践4.1 资源隔离方案多模型部署最怕的就是资源争抢我总结了几种隔离方案GPU隔离每个模型绑定特定GPUCUDA_VISIBLE_DEVICES0 python -m sglang.launch_server --model model1 CUDA_VISIBLE_DEVICES1 python -m sglang.launch_server --model model2显存预留通过--mem-fraction-static预留显存python -m vllm.entrypoints.api_server \ --model model1 \ --gpu-memory-utilization 0.7cgroups限制限制CPU和内存用量cgcreate -g cpu,memory:/model1 echo 100000 /sys/fs/cgroup/cpu/model1/cpu.cfs_quota_us4.2 性能优化技巧经过多个项目实践我总结出这些优化点批处理大小根据模型调整--max-batch-size# 小模型可以设大些 python -m vllm.entrypoints.api_server --max-batch-size 32 # 大模型要设小些 python -m vllm.entrypoints.api_server --max-batch-size 8KV缓存优化使用--block-size减少内存碎片python -m vllm.entrypoints.api_server \ --block-size 16 \ --enable-prefix-caching量化部署对响应速度要求高的场景用GPTQ量化from auto_gptq import AutoGPTQForCausalLM model AutoGPTQForCausalLM.from_quantized( model1, devicecuda:0, use_tritonTrue )4.3 监控与运维完善的监控是稳定运行的保障建议重点关注这些指标GPU指标利用率、显存、温度请求指标延迟、吞吐量、错误率模型指标缓存命中率、排队时长Prometheus配置示例scrape_configs: - job_name: vllm metrics_path: /metrics static_configs: - targets: [vllm-service:8000] - job_name: sglang metrics_path: /metrics static_configs: - targets: [sglang-router:30000]5. 方案对比与选型建议5.1 技术对比方案适用场景优点缺点vLLMNginx简单多模型部署实现简单兼容性好需维护多个实例vLLMRay大规模分布式推理资源利用率高扩展性强复杂度高SGLang路由快速轻量级多模型服务内置路由低延迟对显存管理要求高SGLang分布式超大规模模型部署支持多机多卡网络配置复杂5.2 选型指南根据我的经验可以按这个逻辑选择模型数量5直接用SGLang内置路由需要动态扩展选vLLMRay方案超长上下文vLLM的PagedAttention是首选多租户场景SGLang的隔离特性更合适最近一个金融客户的项目就是混合方案用vLLM部署长文本分析模型16k上下文用SGLang部署对话和分类模型通过统一网关对外提供服务运行半年多非常稳定。6. 常见问题解决在实际部署中遇到过不少坑这里分享几个典型案例显存不足问题# 错误信息 CUDA out of memory # 解决方案 python -m vllm.entrypoints.api_server \ --gpu-memory-utilization 0.8 \ --swap-space 16G路由失效问题# 现象 请求被错误路由到其他模型 # 检查步骤 1. 确认router日志中的model参数 2. 检查各模型实例的负载情况 3. 验证affinity配置性能下降问题# 排查方法 1. 用nvtop查看GPU利用率 2. 检查是否有其他进程占用资源 3. 调整--max-concurrent-requests参数最近还遇到一个有意思的案例客户反馈夜间延迟突然升高最后发现是保洁机器人碰到电源线导致GPU服务器降频。所以硬件环境也不能忽视。