1. 从单模型Demo到多模型并发生产环境部署的真实门槛很多人第一次接触大模型推理部署都是在单卡上跑一个7B或14B的模型用默认配置启动服务发几条请求测试一下觉得“不过如此”。但一旦进入生产环境面对的是DeepSeek-R1这类推理模型和Qwen3这类通用对话模型同时在线、几十路并发请求、不同长度的输入输出、以及7x24小时的稳定性要求情况就完全不一样了。我最近刚完成了一个多模型混合部署的项目把DeepSeek-R1-Distill-Qwen-14B和Qwen3-14B两个模型放在同一套推理服务里对外提供API过程中踩的坑几乎覆盖了从显存分配到调度策略的每一个环节。这篇文章不打算复述官方文档里那些基础安装步骤而是聚焦于“多模型并发”这个场景下那些文档不会告诉你、但生产环境一定会遇到的问题。适合已经跑通过单模型部署、准备上多模型或者已经被并发问题折磨过的朋友。我会把每个坑的排查过程、根因分析和最终解决方案完整展开包括具体的配置参数、显存计算和调度策略调整。先说一个最直观的结论多模型部署的核心矛盾不是“能不能跑起来”而是“显存怎么分、请求怎么调度、故障怎么隔离”。这三个问题任何一个处理不好都会导致服务在压力下崩溃或者响应时间飙升。下面我按照实际部署的时间线把每个阶段遇到的问题和解决思路逐一拆解。2. 显存分配的博弈为什么两个14B模型不能简单各占一半2.1 显存占用的真实构成远比想象复杂很多人第一反应是两个14B的模型FP16精度下每个大约28GB权重两张80GB的卡各放一个剩下24GB做KV Cache应该够了吧实际跑起来你会发现显存占用远不止权重那么简单。vLLM在启动时会预分配一大块显存用于KV Cache这个预分配的量由gpu_memory_utilization参数控制。默认值是0.9意味着vLLM会尝试占用90%的显存。如果你在一张卡上部署两个模型每个模型都设0.9那第二个模型启动时就会直接OOM。更隐蔽的是即使你设置了合理的utilizationCUDA上下文、通信缓冲区、临时激活值这些开销加起来每个模型实例至少还要吃掉2-4GB。我实测下来一个14B模型在FP16下权重占28GBCUDA上下文和框架开销约3GB如果gpu_memory_utilization0.85在80GB卡上实际可用于KV Cache的显存大约是80×0.85-28-337GB。两个模型如果共享一张卡每个只能分到约18GB做KV Cache这对于长序列并发来说非常紧张。2.2 张量并行的粒度选择与显存碎片另一个容易被忽略的问题是张量并行TP的粒度。如果你用TP2来跑一个14B模型权重会被切分到两张卡上每张卡占14GB。听起来省了显存但TP带来的通信开销在并发场景下会显著增加延迟。而且当你有两个模型时如果模型A用TP2占了两张卡模型B就没法用这两张卡了除非你做更细粒度的切分。我的建议是对于14B级别的模型单卡部署优先不要轻易上TP。单卡80GB足够放下一个14B模型加上可观的KV Cache。两张卡分别部署两个模型通过API网关做请求路由这样故障隔离也更好——一个模型挂了不影响另一个。但这里有个坑如果你用的是A100 40GB或者更小的卡单卡放不下14B模型那就必须用TP。这时候两个模型都想要TP2就需要4张卡。如果只有2张卡就得考虑量化或者换更小的模型。显存规划一定要在部署前算清楚不要等启动时报OOM再回头改。2.3 量化方案的取舍GPTQ、AWQ还是FP8当显存不够时量化是最直接的出路。vLLM支持GPTQ、AWQ和FP8三种主流量化格式。我分别试过这三种方案说下实际感受。GPTQ是最成熟的社区模型多但推理速度在vLLM下不如AWQ而且GPTQ的校准过程对中文模型有时会出现精度损失。AWQ在vLLM上的推理效率更好显存占用也更低14B模型AWQ量化后大约占8-9GB一张40GB卡就能轻松放下还能留出充足的KV Cache。FP8是H100/H200的原生支持精度损失最小但需要硬件支持而且不是所有模型都有现成的FP8权重。注意量化后的模型在长序列推理时精度损失会被放大。如果你的场景涉及复杂的数学推理或代码生成建议先做一轮精度对比测试确认量化后的输出质量可接受再上生产。我最终的选择是DeepSeek-R1用AWQ量化部署在单张40GB卡上Qwen3用FP16部署在另一张80GB卡上。这样既保证了推理模型的精度又控制了显存占用。两个模型通过不同的端口暴露服务上层用Nginx做负载均衡和路由。3. 调度器的隐形陷阱连续批处理不是万能药3.1 连续批处理在混合负载下的表现vLLM的核心卖点之一是连续批处理Continuous Batching它能在请求级别动态合并批次大幅提升吞吐。但在多模型场景下这个机制会带来一些意想不到的问题。最典型的是长短请求混合导致的队头阻塞。假设DeepSeek-R1正在处理一个需要生成2048个token的推理请求同时来了一个只需要生成50个token的Qwen3对话请求。如果这两个请求被调度到同一个批次里Qwen3的请求必须等DeepSeek-R1的长请求完成才能返回。虽然vLLM的连续批处理允许新请求加入正在运行的批次但已完成请求的释放和显存回收并不是即时的长请求会持续占用KV Cache导致后续短请求的可用显存减少。我实测发现当并发请求中长请求占比超过30%时短请求的P99延迟会从200ms飙升到2s以上。解决方案是为不同模型设置不同的调度参数或者干脆把长短请求路由到不同的模型实例。3.2 max_num_seqs和max_num_batched_tokens的调优vLLM有两个关键调度参数max_num_seqs控制同时处理的序列数max_num_batched_tokens控制一个批次的最大token数。默认值分别是256和2048不同版本可能不同。在多模型并发场景下这两个参数需要根据模型特性和硬件配置精细调整。对于DeepSeek-R1这种推理模型输入通常较长问题描述思维链输出也长建议把max_num_batched_tokens设大一些比如4096或8192让更多token能在一个批次里处理。但max_num_seqs要适当降低比如64或128避免太多长序列同时占用显存。对于Qwen3这种对话模型输入输出相对较短可以把max_num_seqs设高一些比如256max_num_batched_tokens保持2048或4096。这样能最大化吞吐。这里有个经验公式KV Cache总大小 ≈ max_num_seqs × 平均序列长度 × 每token的KV占用。每token的KV占用取决于模型层数、隐藏维度和精度。以14B模型为例FP16下每token大约占0.5MB。如果你有37GB的KV Cache空间平均序列长度512那么max_num_seqs最多能设到37×1024/0.5/512≈148。设得再高就会在运行时触发抢占导致请求被中断重排。3.3 抢占与重计算的代价当显存不足时vLLM会触发抢占Preemption把一些正在运行的序列换出等显存够了再换入。换出的序列需要重新计算KV Cache这个代价非常高。我在日志里看到大量“Preemption occurred”警告时就知道调度参数设得太激进了。抢占的根因通常是max_num_seqs设得过高或者gpu_memory_utilization设得过高导致KV Cache实际可用空间不足。解决方法是降低max_num_seqs或者降低gpu_memory_utilization给系统留更多余量。我一般会把gpu_memory_utilization设在0.85-0.88之间不要贴着0.9跑留出一些缓冲应对突发流量。4. 多模型路由与故障隔离别让一个模型拖垮整个服务4.1 API网关的路由策略设计两个模型部署好之后对外需要一个统一入口。我用的是Nginx做反向代理根据请求路径或者请求体里的model字段做路由。这里有个细节vLLM的OpenAI兼容API默认不校验model字段你发什么model它都用当前加载的模型处理。所以路由必须在网关层做不能依赖vLLM自己判断。Nginx配置里用map指令根据请求体中的model字段做分流或者更简单的方式是用不同的路径前缀比如/v1/deepseek/chat/completions和/v1/qwen/chat/completions。路径前缀的方式性能更好因为不需要解析请求体。但路径前缀有个问题如果你的客户端用的是OpenAI SDK它默认请求/v1/chat/completions不会带模型前缀。这时候就需要在网关层解析请求体根据model字段重写路径。Nginx原生不支持JSON解析需要用到OpenResty或者Lua模块。如果不想引入额外依赖也可以在客户端做适配让不同模型用不同的base_url。4.2 健康检查与自动摘除生产环境必须要有健康检查机制。vLLM提供了/health端点返回200表示服务正常。但这个端点只检查进程是否存活不检查模型是否真的能推理。我遇到过一种情况vLLM进程还在/health返回200但实际推理请求全部超时因为GPU出现了ECC错误导致计算卡死。更可靠的健康检查方式是发一个真实的推理请求比如固定输入“你好”检查是否能在超时时间内返回。Nginx的health_check模块或者上游的负载均衡器可以配置这种主动健康检查。一旦某个模型实例连续失败就自动从上游摘除避免请求被路由到故障节点。故障隔离的另一个层面是资源隔离。两个模型如果跑在同一台机器上一个模型的内存泄漏或者GPU异常会影响另一个。如果条件允许尽量把不同模型部署在不同的物理机或者容器里通过资源限制cgroup隔离CPU和内存。GPU层面虽然不好做硬隔离但可以通过MPSMulti-Process Service或者MIGMulti-Instance GPU做一定程度的隔离。不过MIG对显存的切分是固定的灵活性较差适合确定性强的场景。4.3 超时与重试的边界多模型服务中超时设置非常关键。DeepSeek-R1的推理请求可能需要30秒甚至更久才能返回完整结果而Qwen3的对话请求通常几秒内就能完成。如果统一设一个超时时间要么DeepSeek-R1被误杀要么Qwen3的故障请求拖太久。我的做法是按模型设置不同的超时时间DeepSeek-R1设120秒Qwen3设30秒。重试策略也要区分推理模型的请求通常不可重试因为每次生成结果可能不同对话模型可以有限重试。重试次数建议不超过2次并且要加退避策略避免重试风暴把服务打垮。还有一个容易忽略的点流式请求的超时处理。如果客户端用stream模式超时应该按“两个chunk之间的间隔”来算而不是整个请求的时长。vLLM的流式输出在生成第一个token后后续token的间隔通常很短但如果模型卡住间隔会变大。网关层需要配置proxy_read_timeout来覆盖这个间隔。5. 压测中暴露的并发问题与调优实录5.1 压测工具的选择与场景设计我用的是Locust做压测因为它支持自定义的请求模式和动态调整并发数。压测场景设计了三种纯DeepSeek-R1请求、纯Qwen3请求、以及两者混合。每种场景分别测试低并发10路、中并发50路和高并发200路。压测数据用的是真实业务日志里采样的问题输入长度从50token到2000token不等输出长度从20token到1500token不等。这样才能模拟真实负载而不是用固定长度的假数据。第一轮压测就暴露了问题纯Qwen3场景下50路并发时P99延迟约800ms可以接受。但混合场景下同样50路并发Qwen3的P99延迟直接跳到5s以上。查看vLLM日志发现大量抢占记录原因是DeepSeek-R1的长请求占用了大量KV Cache导致Qwen3的请求被频繁换出换入。5.2 从日志中定位瓶颈的完整链路排查这个问题的过程值得详细说下。首先看vLLM的metrics端点/metrics里面有vllm:num_requests_running、vllm:num_requests_waiting、vllm:gpu_cache_usage_perc等关键指标。混合场景下gpu_cache_usage_perc持续在95%以上num_requests_waiting不断累积说明KV Cache严重不足。然后看调度日志发现Preemption频繁出现而且被抢占的多数是Qwen3的短序列。这是因为vLLM的调度器默认采用FCFS先来先服务长序列先到就先占住显存短序列后来只能被挤出去。解决方案分两步第一给两个模型分别设置独立的vLLM实例不要试图在一个实例里加载两个模型。vLLM本身不支持多模型加载所谓的“多模型”其实是启动多个vLLM进程每个进程加载一个模型。第二调整调度参数把Qwen3实例的max_num_seqs从256降到128gpu_memory_utilization从0.9降到0.85给KV Cache留更多余量。DeepSeek-R1实例的max_num_seqs设为64max_num_batched_tokens设为8192优先保证长序列的连续性。调整后重新压测混合场景下Qwen3的P99延迟降到1.2sDeepSeek-R1的P99延迟约8s推理模型本身延迟就高整体吞吐提升了约40%。5.3 批处理大小与延迟的权衡曲线调优过程中我画了一条批处理大小与延迟的关系曲线。对于Qwen3当max_num_seqs从64增加到128时吞吐提升明显P99延迟从1.5s降到1.2s。但从128增加到256时吞吐几乎不再提升P99延迟反而升到2s以上因为显存压力导致抢占增加。最佳工作点通常在吞吐开始 plateau 而延迟开始上升的拐点附近。这个拐点因模型、硬件和请求分布而异必须通过压测找到。我的经验是先用默认参数跑一轮记录吞吐和延迟然后逐步增加max_num_seqs每次增加50%观察指标变化当P99延迟开始明显上升时回退到上一个值。对于DeepSeek-R1由于输出长度不可控推理链长度差异大max_num_seqs要设得更保守。我最终设的是48再高就会频繁触发抢占。同时把max_num_batched_tokens设到8192让长序列能在一个批次里尽量多处理减少批次切换开销。6. 那些文档不会告诉你的运维细节6.1 模型加载时间的优化vLLM启动时加载模型权重需要时间14B模型FP16大约需要2-3分钟AWQ量化模型约1分钟。如果服务重启这段时间服务不可用。生产环境需要预热机制在流量低谷期主动重启或者滚动更新避免在高峰期重启。另外vLLM支持从本地磁盘加载模型比从网络存储加载快很多。如果用的是Kubernetes可以把模型文件放在hostPath或者本地PV里避免每次启动都从远端拉取。我还试过用--load-format参数指定加载格式safetensors比pt快一些但差异不大。6.2 日志轮转与磁盘空间vLLM的日志量不小尤其是开启debug级别后每个请求都会打多条日志。生产环境一定要配置日志轮转否则磁盘很快会被写满。我用的是logrotate按天切割保留7天压缩存储。还有一个坑vLLM的日志默认输出到stdout如果用Docker或者Kubernetes需要配置日志驱动把stdout收集到集中式日志系统。否则容器重启后日志就丢了排查问题时会很被动。6.3 GPU温度与降频的隐蔽影响这个坑比较隐蔽GPU温度过高时会自动降频导致推理速度下降。我在压测时发现持续高负载跑30分钟后Qwen3的吞吐下降了约15%。用nvidia-smi查看发现GPU温度到了85度触发了降频。解决方案是改善散热或者在调度层面做负载均衡把请求分散到多张卡上避免单卡持续满载。如果机房温度可控把环境温度调低几度也能明显改善。另外nvidia-smi -pl可以限制GPU功耗虽然会降低峰值性能但能保持频率稳定避免降频带来的抖动。6.4 版本升级的兼容性风险vLLM迭代很快新版本可能引入性能提升但也可能改变默认行为。我有一次升级后发现max_num_batched_tokens的默认值从2048变成了4096导致显存占用增加原本稳定的配置开始出现OOM。升级前一定要在测试环境验证重点检查默认参数是否变化、API是否有breaking change、量化格式是否兼容。升级后先跑一轮压测对比升级前后的吞吐和延迟指标确认没有退化再上生产。如果用的是Docker镜像建议固定版本号不要用latest标签。7. 多模型并发部署的检查清单与个人体会经过这个项目我整理了一份部署前的检查清单每次上新模型或者调整配置时都会过一遍显存预算是否算清楚权重框架开销KV Cache缓冲每一项都要有数。gpu_memory_utilization是否留了余量建议0.85-0.88不要贴0.9。max_num_seqs和max_num_batched_tokens是否根据模型特性调过推理模型和对话模型的配置应该不同。健康检查是否覆盖了真实推理不要只依赖/health端点。超时和重试策略是否按模型区分推理模型和对话模型的超时应该不同。日志轮转和磁盘监控是否配置避免磁盘写满导致服务崩溃。GPU温度和频率是否监控降频会悄悄吃掉你的性能。版本升级是否有回滚方案固定版本号升级前先压测。最后分享一个我在实际操作中的体会多模型部署的复杂度不在于模型本身而在于资源竞争和故障传播。两个模型跑在同一台机器上共享GPU、内存、网络和磁盘IO任何一个资源出现瓶颈都会影响另一个。所以如果条件允许尽量做物理隔离或者容器级隔离把故障域缩小。如果必须共享那就要在调度层面做好隔离和限流宁可牺牲一点吞吐也要保证稳定性。生产环境里稳定性的优先级永远高于峰值性能。