尧图网页设计 
双路RTX 3090 vLLM跑Qwen2.5-14B这套组合在我自己机器上已经稳定跑了三个多月。今天不整虚的把从硬件选型、环境安装、模型启动到参数调优的全过程连同踩过的坑一起梳理出来。如果你正准备用消费级显卡低成本部署一个本地大模型服务这篇应该能帮你少走不少弯路。先说结论双RTX 3090跑Qwen2.5-14B不仅能跑而且跑得相当舒服。配合vLLM做推理加速单机就能提供兼容OpenAI格式的API服务支持并发请求、动态batch、大上下文窗口在很多私有化场景下完全不虚云端API。最关键的是这套方案的硬件成本比买一块A100便宜一个量级二手市场上两张3090的价格通常在万元上下实际推理吞吐却能做到接近专业卡七八成的水平。下面我按自己的实操顺序一步步讲。1. 为什么是“双 RTX 3090 Qwen2.5-14B vLLM”这个组合很多朋友一上来就问“为什么不是单卡”或者“为什么不用4090”。这里面的选择逻辑其实很清晰核心就是显存、带宽和成本三件事。我挨个拆开说。1.1 先算一笔显存账大模型部署第一步就是看显存够不够装下模型权重。Qwen2.5-14B这个模型参数量是14B也就是140亿参数。如果用BF16半精度加载每个参数占2字节那么光权重文件就需要大约28GB显存。一张RTX 3090的显存是24GB单卡根本装不下完整的BF16精度模型。这就是为什么“双3090”这个方案会出现在桌面上两张卡合计48GB显存扣掉28GB权重还能剩下近20GB给推理过程中的KV Cache、激活值和其他临时变量。有朋友会问那我把模型量化成INT4/INT8不就能单卡跑了吗确实可以比如用AWQ或GPTQ量化到4bit模型权重能压到10GB以内。但量化是有代价的精度会掉尤其在数学推理、代码生成这类对输出质量敏感的任务上量化的损失是可以直观感受到的。而双卡BF16方案不需要牺牲精度显存还余量充足这是它最核心的优势。显存计算这个事我做了个简单的表方便大家对照部署方案权重显存占用剩余可用于KV Cache说明单卡3090 INT4量化约10GB约14GB精度有损失长上下文易OOM双卡3090 BF16约28GB约20GB无损精度余量充足单卡A100 80G BF16约28GB约52GB余量最大但硬件成本极高双卡3090 AWQ量化约14GB约34GB精度少量损失可支持超长上下文另外还要提醒一句模型加载不是只算权重那么简单。实际推理过程中显存还会被CUDA context、推理框架自身缓存、中间激活值占用。所以“24GB显存 能装24GB的模型”是个常见误解我给的建议是至少预留20%显存给这些额外开销。1.2 vLLM 到底解决了什么问题模型能装进显存只是第一步真正让这套方案变得实用的是推理引擎。如果直接用HuggingFace Transformers做推理一张3090跑14B模型生成速度大概只有每秒几个token聊个天都要等半天完全不具备实用性。vLLM的核心价值就在于把推理速度提升了数倍甚至一个量级。vLLM有两个关键技术PagedAttention和Continuous Batching。PagedAttention借鉴了操作系统虚拟内存的思路把KV Cache分割成固定大小的块按需分配不再要求物理上连续这能把显存利用率提升到接近极限变相增加了可处理的上下文长度和并发请求数。Continuous Batching则解决了传统推理中“同批次请求必须等最慢的那个完成才能一起释放”的问题它允许一个请求结束后立即插入新的请求让GPU始终满负荷运转整体吞吐能提高好几倍。在实际测试中双3090跑Qwen2.5-14B用vLLM部署后单请求生成速度能达到每秒20到30个token并发请求增多时总吞吐还能继续上升。这个体验已经比较接近生产可用的状态支撑一个小团队内部使用完全足够。1.3 这套组合适合谁又不适合谁这套方案针对的场景很明确预算有限但需要本地私有化部署大模型的个人开发者、小型团队、科研课题组或者对数据安全要求高、模型输出不能离开内网环境的企业。双3090的优势是上手门槛低、生态成熟、驱动稳定二手市场货源也充足。但它也有不适合的场景。如果你需要的是每天上百万次请求的高并发生产环境3090的PCIe通信瓶颈会开始拖后腿而且多张卡长期满载的散热和电费也是不小的开销。如果模型参数量超过30B甚至70B双3090的48GB显存就会非常捉襟见肘得考虑量化或者四卡方案。一句话总结14B到32B这个范围内的模型双3090是性价比很能打的区间但更大模型就不是这套方案该管的了。2. 部署前的环境准备环境准备这块看着简单实际有一堆隐藏坑。我装过好几遍把最稳妥的路径整理出来照着走基本不会出幺蛾子。2.1 硬件清单与系统要求除了两张RTX 3090还有几个硬件配件容易被忽略但它们恰恰决定了整套系统能否稳定运行。电源是第一个重点。RTX 3090满载功耗在350W左右两张卡就是700W加上CPU、主板、硬盘整机峰值功耗轻松超过1000W。建议直接上一线品牌的1000W金牌甚至1200W白金电源千万别在电源上省钱。我自己最开始用的是850W电源一跑高并发负载就重启排查了很久才发现是电源过载保护换了1200W之后再没出现过。第二个容易被忽略的是机箱散热。3090的发热量非常大双卡紧挨着安装时上排卡的进风会被下排卡的背板挡住导致温度飙升。我的做法是用PCIe延长线把两张卡分开安装虽然麻烦但温度能低10摄氏度以上。如果没有延长线至少保证机箱有足够的前进风和后出风风道。内存方面建议64GB起步最好128GB。加载模型时权重文件要先经过CPU内存再写入显存内存不足会导致启动失败或频繁使用swap系统卡成幻灯片。硬盘建议NVMe SSD因为模型启动时要把约30GB的权重文件读入内存机械硬盘读这个量级需要好几分钟NVMe SSD十几秒就完成。2.2 CUDA、PyTorch 与 vLLM 安装软件环境推荐用Anaconda或Miniconda管理Python环境避免污染系统自带的Python。vLLM目前推荐Python 3.10到3.12版本CUDA Toolkit用12.1以上。下面是我验证过的一套组合conda create -n vllm python3.10 conda activate vllm pip install torch --index-url https://download.pytorch.org/whl/cu121 pip install vllm这里有个关键点先装PyTorch再装vLLM。因为vLLM安装时会检测当前环境中的PyTorch版本和CUDA版本如果先装了vLLM再装PyTorch很可能会出现版本匹配错乱。另外不要用conda直接安装vllmconda源上的版本更新速度比PyPI慢很多直接用pip装最新版体验最好。装完后可以用下面这个命令验证环境是否正常python -c import torch, vllm; print(torch.__version__, vllm.__version__)如果爆出CUDA相关的错误大概率是PyTorch的CUDA版本跟驱动不匹配用nvidia-smi查看驱动支持的CUDA版本如果驱动版本太旧就需要更新驱动。这里特别提醒3090用户一个重点RTX 3090是Ampere架构支持BF16但不支持FP8。有些教程会说在3090上开FP8能提升速度千万别照抄FP8是Hopper架构才开始支持的3090上会直接报错或者回退到低精度。这也是为什么我前面强调BF16精度方案它才是3090最佳精度选项。2.3 模型文件准备模型可以从HuggingFace的Qwen官方仓库下载Qwen2.5-14B-Instruct推荐用Git LFS或者写个简单的下载脚本。如果网络连接官方仓库比较慢也可以从国内镜像源下载具体地址根据你的实际情况选择。下载完成后建议用ModelScope的CLI或者huggingface_hub先确认一下目录结构正常的模型目录应该包含这些文件Qwen2.5-14B-Instruct/ ├── config.json ├── generation_config.json ├── model-00001-of-00007.safetensors ├── model-00002-of-00007.safetensors ├── ... ├── model-00007-of-00007.safetensors ├── tokenizer.json └── tokenizer_config.json如果没有tokenizer.jsonvLLM启动时会自动尝试下载补充但我建议提前检查好避免启动到一半时卡在下载环节。Safetensors文件数量因模型分片设置可能不同只要文件完整就行。下载时避免粗心模型文件和tokenizer文件都建议放在同一个目录下vLLM启动时会从这个目录读取全部配置。我第一次部署时只下载了safetensors权重文件漏掉了tokenizer_config.json结果启动时报错提示“tokenizer config not found”把文件补上就好了。3. 双卡部署 Qwen2.5-14B 实操记录环境准备好之后进入到真正的部署环节。vLLM的启动命令不算复杂关键是搞清楚每个参数的含义能根据自己的显存和场景灵活调整。3.1 启动命令与参数逐项拆解先把完整启动命令放在前面然后我逐个参数解释python -m vllm.entrypoints.openai.api_server \ --model /data/models/Qwen2.5-14B-Instruct \ --tensor-parallel-size 2 \ --gpu-memory-utilization 0.92 \ --max-model-len 32768 \ --port 8000如果想要更简洁也可以用vLLM提供的统一命令入口vllm serve /data/models/Qwen2.5-14B-Instruct \ --tensor-parallel-size 2 \ --gpu-memory-utilization 0.92 \ --max-model-len 32768这两个命令本质是一样的前者走的是Python模块调用后者走的是可执行脚本入口推荐直接用第二种命令更简短。下面拆解每个参数--tensor-parallel-size 2是本次部署最核心的参数。它的含义是把模型权重切分到两张GPU上并行推理。vLLM会调用NCCL在多卡之间做通信同步对用户来说完全透明。需要注意这个值必须能被实际可用的GPU数量整除如果系统里还有其他进程占了GPU可能会出现找不到卡的问题可以配合CUDA_VISIBLE_DEVICES来指定CUDA_VISIBLE_DEVICES0,1 vllm serve /data/models/Qwen2.5-14B-Instruct \ --tensor-parallel-size 2 \ --gpu-memory-utilization 0.92 \ --max-model-len 32768这样只把0号和1号卡暴露给vLLM避免其他进程干扰。--gpu-memory-utilization 0.92表示vLLM最多可以使用单卡92%的显存剩余8%留给CUDA context和显示输出等用途。这个值可以按需调高到0.95但我不建议再往上加否则容易触发OOM后把CUDA context搞崩整个进程都要重启。--max-model-len 32768是允许的最大上下文长度。Qwen2.5-14B官方支持到128K以上但实际能开多大取决于你的显存余量。上下文越长KV Cache占用的显存就越大需要根据自己的场景在“长上下文”和“并发能力”之间取舍。32768是我测试下来双3090上一个很平衡的配置能覆盖绝大多数业务场景而且并发吞吐也还不错。启动成功后终端会打印类似这样的日志说明服务已经就绪INFO: Started server process [12345] INFO: Waiting for model to be loaded... INFO: Model loaded in 67.3s INFO: Uvicorn running on http://0.0.0.0:8000看到Uvicorn running这行输出时就可以开始调用接口了。3.2 多卡并行与显存分配验证服务启动后不要急着发请求先确认两张卡都真正干活了。用nvidia-smi看一下显存占用情况正常情况下两张卡的显存占用应该非常接近各占20GB左右。我第一次部署时遇到过一个迷惑现象服务能正常启动但GPU 1的显存占用只有几百MBGPU 0却顶着23GB。后来排查发现是因为我启动命令里没有指定GPU资源vLLM默认可能把两个rank分配到了同一张物理卡上或者CUDA_VISIBLE_DEVICES设置错了导致Tensor Parallelism没生效。还有一次是模型文件在加载时因为缓存原因第二张卡的分配被强制推迟了重启之后恢复正常。建议用下面的命令持续观察显存变化watch -n 1 nvidia-smi如果两张卡占用明显不平衡优先检查CUDA_VISIBLE_DEVICES和--tensor-parallel-size这两个配置。设置成CUDA_VISIBLE_DEVICES0,1 --tensor-parallel-size 2之后在绝大多数情况下两张卡会稳定负载均衡。3.3 用 OpenAI 接口完成一次对话测试vLLM启动后提供的是OpenAI兼容的REST API这意味着你用OpenAI SDK就能直接对接很多现有工程代码改个base_url就能用迁移成本极低。先在命令行里发一个简单的请求验证服务curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: /data/models/Qwen2.5-14B-Instruct, messages: [{role: user, content: 用一句话介绍什么是大语言模型}], max_tokens: 256, temperature: 0.7 }注意请求体中的model参数填的是你启动时传入的模型路径因为本地服务没有模型注册表它会把传入的model当作一个标识字符串并不会去校验收到的值是否匹配。如果你希望model参数显得更简洁可以在启动时用--served-model-name给模型起个别名vllm serve /data/models/Qwen2.5-14B-Instruct \ --tensor-parallel-size 2 \ --served-model-name qwen14b这样请求时model参数就只需要写qwen14b。命令行测试没问题后再用Python的openai库发一次请求模拟实际业务场景from openai import OpenAI client OpenAI( base_urlhttp://localhost:8000/v1, api_keyEMPTY, ) resp client.chat.completions.create( modelqwen14b, messages[ {role: system, content: 你是一个技术助手回答尽量简洁准确。}, {role: user, content: 请写一段Python代码用FastAPI实现一个最简单的HTTP服务。}, ], max_tokens1024, temperature0.7, ) print(resp.choices[0].message.content)第一次请求会有一个短暂的预热过程因为vLLM要构建CUDA graph和显存缓存几秒内响应之后的请求延迟会稳定下来。如果设置的是流式输出还能把stream参数设为true体验打字机式的逐token输出效果。4. 性能观测与调优方向部署成功只是开始真正的好戏在调优。vLLM默认参数就能工作但想要把双3090的潜力全部压榨出来还需要结合实际情况去做调整。4.1 如何看吞吐和延迟vLLM服务在启动日志和请求日志里会自动输出性能指标核心关注这几个数据Throughput每秒生成的token数是衡量推理引擎整体效率最直观的指标。E2E Latency端到端延迟即从请求发起到完整响应返回的总耗时。TTFTTime to First Token首token延迟即用户发出请求后多长时间收到第一个token。流式输出场景下这个指标比总延迟更重要它决定了用户的“卡顿感”。ITLInter-Token Latency相邻两个token生成的时间间隔约等于单token生成速度。在双3090上Qwen2.5-14B的常见表现大致如下指标典型值单请求典型值并发8请求TTFT300-600ms1-2s单token生成速度20-35 token/s60-90 token/s总吞吐端到端延迟512 token输出15-25s8-15s部分请求这里没有绝对的数因为延迟跟上下文长度、batch大小、是否命中cache都有关系。但我建议你在收到服务日志时多留意一下如果单请求的速度掉到10 token/s以下基本说明某个环节出了问题优先排查显存是否被KV Cache挤爆以及是否还有其他进程在抢占GPU算力。4.2 针对 3090 的实用调优点vLLM参数里还有几个值得尝试的调优项我按优先级排序--max-num-seqs控制最大并发batch数。默认值通常是256看起来很大但它还要跟显存和上下文长度做平衡。如果你的实际并发请求很少不需要调但如果你跑的是知识库问答这类短query场景可以适当提高这个值来提升吞吐。我一般用64到128短文本问答场景下很稳定。--max-model-len刚才说过它直接决定KV Cache上限。如果你的业务不需要超长上下文把32768改成16384或8192会明显提升并发能力。每减少一半上下文长度相当于多出一大块显存给KV Cache能支撑更多并发请求同时运行。我测试过16384长度下并发能力比32768高出接近50%这笔账很划算。--enforce-eager这个参数建议默认不要动。vLLM默认会用CUDA graph优化推理路径把很多小操作提前编译成图形减少kernel启动开销。在3090上CUDA graph能带来可观的加速。只有在显存极度紧张或者遇到CUDA graph编译失败的情况下才考虑用--enforce-eager关闭它。还有一个跟硬件相关的点需要额外说明。双3090之间如果没有NVLink桥接Tensor Parallelism的通信走的是PCIe通道带宽大概在25GB/s左右和NVLink的600GB/s完全不是一个量级。不过vLLM的TP实现基本会通过batch切分来掩盖一部分通信开销所以实际影响没有理论值那么吓人。我给的建议是如果主板支持两张卡分别跑在PCIe 4.0 x16速率那就能让通信带宽保持在最佳状态。可以用下面的命令检查PCIe链路状态lspci -vv | grep -A20 NVIDIA如果发现第二张卡跑在x8甚至x4速率上优先检查插槽位置和BIOS设置。PCIe带宽不足在长上下文场景下会明显拖慢TP的同步速度这是双卡方案里最容易被忽略的硬件瓶颈。5. 避坑清单双 3090 部署的常见问题这部分是全文最值钱的章节。我把自己踩过的坑、群里朋友踩过的坑全部整理成一份可以直接对照排查的清单。5.1 硬件与显存相关的坑坑一电源功率不足导致满载时直接重启这是我在双3090方案上遇到的第一个大坑。表现是单开一张卡跑模型完全正常两张卡同时高负载推理一段时间后整机突然断电重启。排查了系统日志、显卡驱动、温度最后发现是电源过载保护触发。换了大功率电源后问题彻底消失。这个坑在二手3090方案里非常常见因为很多人的电源是之前单卡配置时买的功率余量不够。坑二散热不足导致温度墙降频3090满载功耗高双卡叠放时间长了温度很容易超过85摄氏度显卡会自动降频推理速度断崖式下跌。用nvidia-smi观察核心温度和功耗nvidia-smi -q -d TEMPERATURE如果温度长期超过82摄氏度就需要考虑加强机箱风道或者用延长线分开安装。运行环境散热做不好性能能掉三成。坑三显存OOM导致整个服务崩溃给--gpu-memory-utilization设置过高值时vLLM会在运行时因为显存不足触发OOM而且OOM后CUDA状态可能整个被污染必须重启服务才能恢复。比较好的策略是先留出安全余量在0.90到0.94之间调试。如果确实需要更大上下文长度优先压缩--max-model-len不要硬拉显存利用率上限。5.2 软件与模型相关的坑坑一PyTorch和vLLM的CUDA版本不一致这个问题在重装环境时经常出现。症状是import torch正常但import vllm后立刻segmentation fault或者报找不到某个CUDA库。解决办法是严格按照我前面说的先装PyTorch再装vLLM并且确认两个包都指向同一个CUDA主版本。用conda list和pip list检查关键包的版本避免混装。坑二模型路径与tokenizer路径不一致如果模型目录文件不完整vLLM会尝试从网上补齐tokenizer文件这时不仅启动速度慢还可能因为网络问题直接卡死。启动前务必检查tokenizer.json、tokenizer_config.json、config.json等核心文件是否就位。另外模型路径不要放在中文目录或带空格目录下有些依赖库对路径解析不友好会突然报一些奇怪的找不到文件错误。坑三Tensor并行时出现NCCL超时启动时如果日志卡在NCCL初始化阶段最终报错“NCCL error: socket connect failed”通常是多卡之间的PCIe通信链路有问题或者是其他进程占用了GPU导致rank之间无法建连。先关掉占用GPU的进程再用CUDA_VISIBLE_DEVICES显式指定两张卡。如果依然报错重启机器基本能解决因为NCCL重建通信链路的能力有时候会被积累的socket连接残留影响。5.3 长期运行的稳定性建议服务部署完不是终点长期稳定运行才是目标。我整理几个自己已经养成的习惯给GPU温度设置告警。可以用nvidia-smi的查询循环搭配简单的脚本也可以直接用已有的监控工具温度超过阈值时发告警避免显卡因为长期高温而加速老化。对vLLM服务做systemd守护让它在意外退出后自动重启。毕竟本地部署的服务不可能像云平台那样配备专人看护一个简单的自动重启机制能省很多事。定期检查显存碎片化和模型加载情况。vLLM的调度器一般会做好显存管理但如果运行时间特别长还是建议每隔一两周重启一次服务释放可能积累的资源占用。vLLM在Profile里也提供了详细的请求和token统计合理利用这些信息能提前预判并发压力。最后再分享一个小技巧如果需要在多机或者跨网络访问这个服务vLLM默认监听在127.0.0.1上可通过--host参数指定监听网卡地址比如vllm serve /data/models/Qwen2.5-14B-Instruct \ --tensor-parallel-size 2 \ --host 0.0.0.0 \ --port 8000把host设为0.0.0.0之后局域网内其他机器就能直接通过宿主机IP访问这个API服务配合OpenAI SDK使用起来跟在云端调用一样方便。不过要注意做好访问控制毕竟内网服务也不希望被随意调用。这套双3090 vLLM Qwen2.5-14B的方案我自己在内部知识库问答、代码辅助、文档摘要几个场景下用得很顺手稳定性也经历了长时间验证。如果你正在评估本地部署大模型这个组合确实值得一试。实际操作中如果碰到什么新坑欢迎多交流我踩过的路你已经可以少踩一遍了。 双RTX 3090 + vLLM 部署 Qwen2.5-14B 低成本私有化推理实践
双路RTX 3090 vLLM跑Qwen2.5-14B这套组合在我自己机器上已经稳定跑了三个多月。今天不整虚的把从硬件选型、环境安装、模型启动到参数调优的全过程连同踩过的坑一起梳理出来。如果你正准备用消费级显卡低成本部署一个本地大模型服务这篇应该能帮你少走不少弯路。先说结论双RTX 3090跑Qwen2.5-14B不仅能跑而且跑得相当舒服。配合vLLM做推理加速单机就能提供兼容OpenAI格式的API服务支持并发请求、动态batch、大上下文窗口在很多私有化场景下完全不虚云端API。最关键的是这套方案的硬件成本比买一块A100便宜一个量级二手市场上两张3090的价格通常在万元上下实际推理吞吐却能做到接近专业卡七八成的水平。下面我按自己的实操顺序一步步讲。1. 为什么是“双 RTX 3090 Qwen2.5-14B vLLM”这个组合很多朋友一上来就问“为什么不是单卡”或者“为什么不用4090”。这里面的选择逻辑其实很清晰核心就是显存、带宽和成本三件事。我挨个拆开说。1.1 先算一笔显存账大模型部署第一步就是看显存够不够装下模型权重。Qwen2.5-14B这个模型参数量是14B也就是140亿参数。如果用BF16半精度加载每个参数占2字节那么光权重文件就需要大约28GB显存。一张RTX 3090的显存是24GB单卡根本装不下完整的BF16精度模型。这就是为什么“双3090”这个方案会出现在桌面上两张卡合计48GB显存扣掉28GB权重还能剩下近20GB给推理过程中的KV Cache、激活值和其他临时变量。有朋友会问那我把模型量化成INT4/INT8不就能单卡跑了吗确实可以比如用AWQ或GPTQ量化到4bit模型权重能压到10GB以内。但量化是有代价的精度会掉尤其在数学推理、代码生成这类对输出质量敏感的任务上量化的损失是可以直观感受到的。而双卡BF16方案不需要牺牲精度显存还余量充足这是它最核心的优势。显存计算这个事我做了个简单的表方便大家对照部署方案权重显存占用剩余可用于KV Cache说明单卡3090 INT4量化约10GB约14GB精度有损失长上下文易OOM双卡3090 BF16约28GB约20GB无损精度余量充足单卡A100 80G BF16约28GB约52GB余量最大但硬件成本极高双卡3090 AWQ量化约14GB约34GB精度少量损失可支持超长上下文另外还要提醒一句模型加载不是只算权重那么简单。实际推理过程中显存还会被CUDA context、推理框架自身缓存、中间激活值占用。所以“24GB显存 能装24GB的模型”是个常见误解我给的建议是至少预留20%显存给这些额外开销。1.2 vLLM 到底解决了什么问题模型能装进显存只是第一步真正让这套方案变得实用的是推理引擎。如果直接用HuggingFace Transformers做推理一张3090跑14B模型生成速度大概只有每秒几个token聊个天都要等半天完全不具备实用性。vLLM的核心价值就在于把推理速度提升了数倍甚至一个量级。vLLM有两个关键技术PagedAttention和Continuous Batching。PagedAttention借鉴了操作系统虚拟内存的思路把KV Cache分割成固定大小的块按需分配不再要求物理上连续这能把显存利用率提升到接近极限变相增加了可处理的上下文长度和并发请求数。Continuous Batching则解决了传统推理中“同批次请求必须等最慢的那个完成才能一起释放”的问题它允许一个请求结束后立即插入新的请求让GPU始终满负荷运转整体吞吐能提高好几倍。在实际测试中双3090跑Qwen2.5-14B用vLLM部署后单请求生成速度能达到每秒20到30个token并发请求增多时总吞吐还能继续上升。这个体验已经比较接近生产可用的状态支撑一个小团队内部使用完全足够。1.3 这套组合适合谁又不适合谁这套方案针对的场景很明确预算有限但需要本地私有化部署大模型的个人开发者、小型团队、科研课题组或者对数据安全要求高、模型输出不能离开内网环境的企业。双3090的优势是上手门槛低、生态成熟、驱动稳定二手市场货源也充足。但它也有不适合的场景。如果你需要的是每天上百万次请求的高并发生产环境3090的PCIe通信瓶颈会开始拖后腿而且多张卡长期满载的散热和电费也是不小的开销。如果模型参数量超过30B甚至70B双3090的48GB显存就会非常捉襟见肘得考虑量化或者四卡方案。一句话总结14B到32B这个范围内的模型双3090是性价比很能打的区间但更大模型就不是这套方案该管的了。2. 部署前的环境准备环境准备这块看着简单实际有一堆隐藏坑。我装过好几遍把最稳妥的路径整理出来照着走基本不会出幺蛾子。2.1 硬件清单与系统要求除了两张RTX 3090还有几个硬件配件容易被忽略但它们恰恰决定了整套系统能否稳定运行。电源是第一个重点。RTX 3090满载功耗在350W左右两张卡就是700W加上CPU、主板、硬盘整机峰值功耗轻松超过1000W。建议直接上一线品牌的1000W金牌甚至1200W白金电源千万别在电源上省钱。我自己最开始用的是850W电源一跑高并发负载就重启排查了很久才发现是电源过载保护换了1200W之后再没出现过。第二个容易被忽略的是机箱散热。3090的发热量非常大双卡紧挨着安装时上排卡的进风会被下排卡的背板挡住导致温度飙升。我的做法是用PCIe延长线把两张卡分开安装虽然麻烦但温度能低10摄氏度以上。如果没有延长线至少保证机箱有足够的前进风和后出风风道。内存方面建议64GB起步最好128GB。加载模型时权重文件要先经过CPU内存再写入显存内存不足会导致启动失败或频繁使用swap系统卡成幻灯片。硬盘建议NVMe SSD因为模型启动时要把约30GB的权重文件读入内存机械硬盘读这个量级需要好几分钟NVMe SSD十几秒就完成。2.2 CUDA、PyTorch 与 vLLM 安装软件环境推荐用Anaconda或Miniconda管理Python环境避免污染系统自带的Python。vLLM目前推荐Python 3.10到3.12版本CUDA Toolkit用12.1以上。下面是我验证过的一套组合conda create -n vllm python3.10 conda activate vllm pip install torch --index-url https://download.pytorch.org/whl/cu121 pip install vllm这里有个关键点先装PyTorch再装vLLM。因为vLLM安装时会检测当前环境中的PyTorch版本和CUDA版本如果先装了vLLM再装PyTorch很可能会出现版本匹配错乱。另外不要用conda直接安装vllmconda源上的版本更新速度比PyPI慢很多直接用pip装最新版体验最好。装完后可以用下面这个命令验证环境是否正常python -c import torch, vllm; print(torch.__version__, vllm.__version__)如果爆出CUDA相关的错误大概率是PyTorch的CUDA版本跟驱动不匹配用nvidia-smi查看驱动支持的CUDA版本如果驱动版本太旧就需要更新驱动。这里特别提醒3090用户一个重点RTX 3090是Ampere架构支持BF16但不支持FP8。有些教程会说在3090上开FP8能提升速度千万别照抄FP8是Hopper架构才开始支持的3090上会直接报错或者回退到低精度。这也是为什么我前面强调BF16精度方案它才是3090最佳精度选项。2.3 模型文件准备模型可以从HuggingFace的Qwen官方仓库下载Qwen2.5-14B-Instruct推荐用Git LFS或者写个简单的下载脚本。如果网络连接官方仓库比较慢也可以从国内镜像源下载具体地址根据你的实际情况选择。下载完成后建议用ModelScope的CLI或者huggingface_hub先确认一下目录结构正常的模型目录应该包含这些文件Qwen2.5-14B-Instruct/ ├── config.json ├── generation_config.json ├── model-00001-of-00007.safetensors ├── model-00002-of-00007.safetensors ├── ... ├── model-00007-of-00007.safetensors ├── tokenizer.json └── tokenizer_config.json如果没有tokenizer.jsonvLLM启动时会自动尝试下载补充但我建议提前检查好避免启动到一半时卡在下载环节。Safetensors文件数量因模型分片设置可能不同只要文件完整就行。下载时避免粗心模型文件和tokenizer文件都建议放在同一个目录下vLLM启动时会从这个目录读取全部配置。我第一次部署时只下载了safetensors权重文件漏掉了tokenizer_config.json结果启动时报错提示“tokenizer config not found”把文件补上就好了。3. 双卡部署 Qwen2.5-14B 实操记录环境准备好之后进入到真正的部署环节。vLLM的启动命令不算复杂关键是搞清楚每个参数的含义能根据自己的显存和场景灵活调整。3.1 启动命令与参数逐项拆解先把完整启动命令放在前面然后我逐个参数解释python -m vllm.entrypoints.openai.api_server \ --model /data/models/Qwen2.5-14B-Instruct \ --tensor-parallel-size 2 \ --gpu-memory-utilization 0.92 \ --max-model-len 32768 \ --port 8000如果想要更简洁也可以用vLLM提供的统一命令入口vllm serve /data/models/Qwen2.5-14B-Instruct \ --tensor-parallel-size 2 \ --gpu-memory-utilization 0.92 \ --max-model-len 32768这两个命令本质是一样的前者走的是Python模块调用后者走的是可执行脚本入口推荐直接用第二种命令更简短。下面拆解每个参数--tensor-parallel-size 2是本次部署最核心的参数。它的含义是把模型权重切分到两张GPU上并行推理。vLLM会调用NCCL在多卡之间做通信同步对用户来说完全透明。需要注意这个值必须能被实际可用的GPU数量整除如果系统里还有其他进程占了GPU可能会出现找不到卡的问题可以配合CUDA_VISIBLE_DEVICES来指定CUDA_VISIBLE_DEVICES0,1 vllm serve /data/models/Qwen2.5-14B-Instruct \ --tensor-parallel-size 2 \ --gpu-memory-utilization 0.92 \ --max-model-len 32768这样只把0号和1号卡暴露给vLLM避免其他进程干扰。--gpu-memory-utilization 0.92表示vLLM最多可以使用单卡92%的显存剩余8%留给CUDA context和显示输出等用途。这个值可以按需调高到0.95但我不建议再往上加否则容易触发OOM后把CUDA context搞崩整个进程都要重启。--max-model-len 32768是允许的最大上下文长度。Qwen2.5-14B官方支持到128K以上但实际能开多大取决于你的显存余量。上下文越长KV Cache占用的显存就越大需要根据自己的场景在“长上下文”和“并发能力”之间取舍。32768是我测试下来双3090上一个很平衡的配置能覆盖绝大多数业务场景而且并发吞吐也还不错。启动成功后终端会打印类似这样的日志说明服务已经就绪INFO: Started server process [12345] INFO: Waiting for model to be loaded... INFO: Model loaded in 67.3s INFO: Uvicorn running on http://0.0.0.0:8000看到Uvicorn running这行输出时就可以开始调用接口了。3.2 多卡并行与显存分配验证服务启动后不要急着发请求先确认两张卡都真正干活了。用nvidia-smi看一下显存占用情况正常情况下两张卡的显存占用应该非常接近各占20GB左右。我第一次部署时遇到过一个迷惑现象服务能正常启动但GPU 1的显存占用只有几百MBGPU 0却顶着23GB。后来排查发现是因为我启动命令里没有指定GPU资源vLLM默认可能把两个rank分配到了同一张物理卡上或者CUDA_VISIBLE_DEVICES设置错了导致Tensor Parallelism没生效。还有一次是模型文件在加载时因为缓存原因第二张卡的分配被强制推迟了重启之后恢复正常。建议用下面的命令持续观察显存变化watch -n 1 nvidia-smi如果两张卡占用明显不平衡优先检查CUDA_VISIBLE_DEVICES和--tensor-parallel-size这两个配置。设置成CUDA_VISIBLE_DEVICES0,1 --tensor-parallel-size 2之后在绝大多数情况下两张卡会稳定负载均衡。3.3 用 OpenAI 接口完成一次对话测试vLLM启动后提供的是OpenAI兼容的REST API这意味着你用OpenAI SDK就能直接对接很多现有工程代码改个base_url就能用迁移成本极低。先在命令行里发一个简单的请求验证服务curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: /data/models/Qwen2.5-14B-Instruct, messages: [{role: user, content: 用一句话介绍什么是大语言模型}], max_tokens: 256, temperature: 0.7 }注意请求体中的model参数填的是你启动时传入的模型路径因为本地服务没有模型注册表它会把传入的model当作一个标识字符串并不会去校验收到的值是否匹配。如果你希望model参数显得更简洁可以在启动时用--served-model-name给模型起个别名vllm serve /data/models/Qwen2.5-14B-Instruct \ --tensor-parallel-size 2 \ --served-model-name qwen14b这样请求时model参数就只需要写qwen14b。命令行测试没问题后再用Python的openai库发一次请求模拟实际业务场景from openai import OpenAI client OpenAI( base_urlhttp://localhost:8000/v1, api_keyEMPTY, ) resp client.chat.completions.create( modelqwen14b, messages[ {role: system, content: 你是一个技术助手回答尽量简洁准确。}, {role: user, content: 请写一段Python代码用FastAPI实现一个最简单的HTTP服务。}, ], max_tokens1024, temperature0.7, ) print(resp.choices[0].message.content)第一次请求会有一个短暂的预热过程因为vLLM要构建CUDA graph和显存缓存几秒内响应之后的请求延迟会稳定下来。如果设置的是流式输出还能把stream参数设为true体验打字机式的逐token输出效果。4. 性能观测与调优方向部署成功只是开始真正的好戏在调优。vLLM默认参数就能工作但想要把双3090的潜力全部压榨出来还需要结合实际情况去做调整。4.1 如何看吞吐和延迟vLLM服务在启动日志和请求日志里会自动输出性能指标核心关注这几个数据Throughput每秒生成的token数是衡量推理引擎整体效率最直观的指标。E2E Latency端到端延迟即从请求发起到完整响应返回的总耗时。TTFTTime to First Token首token延迟即用户发出请求后多长时间收到第一个token。流式输出场景下这个指标比总延迟更重要它决定了用户的“卡顿感”。ITLInter-Token Latency相邻两个token生成的时间间隔约等于单token生成速度。在双3090上Qwen2.5-14B的常见表现大致如下指标典型值单请求典型值并发8请求TTFT300-600ms1-2s单token生成速度20-35 token/s60-90 token/s总吞吐端到端延迟512 token输出15-25s8-15s部分请求这里没有绝对的数因为延迟跟上下文长度、batch大小、是否命中cache都有关系。但我建议你在收到服务日志时多留意一下如果单请求的速度掉到10 token/s以下基本说明某个环节出了问题优先排查显存是否被KV Cache挤爆以及是否还有其他进程在抢占GPU算力。4.2 针对 3090 的实用调优点vLLM参数里还有几个值得尝试的调优项我按优先级排序--max-num-seqs控制最大并发batch数。默认值通常是256看起来很大但它还要跟显存和上下文长度做平衡。如果你的实际并发请求很少不需要调但如果你跑的是知识库问答这类短query场景可以适当提高这个值来提升吞吐。我一般用64到128短文本问答场景下很稳定。--max-model-len刚才说过它直接决定KV Cache上限。如果你的业务不需要超长上下文把32768改成16384或8192会明显提升并发能力。每减少一半上下文长度相当于多出一大块显存给KV Cache能支撑更多并发请求同时运行。我测试过16384长度下并发能力比32768高出接近50%这笔账很划算。--enforce-eager这个参数建议默认不要动。vLLM默认会用CUDA graph优化推理路径把很多小操作提前编译成图形减少kernel启动开销。在3090上CUDA graph能带来可观的加速。只有在显存极度紧张或者遇到CUDA graph编译失败的情况下才考虑用--enforce-eager关闭它。还有一个跟硬件相关的点需要额外说明。双3090之间如果没有NVLink桥接Tensor Parallelism的通信走的是PCIe通道带宽大概在25GB/s左右和NVLink的600GB/s完全不是一个量级。不过vLLM的TP实现基本会通过batch切分来掩盖一部分通信开销所以实际影响没有理论值那么吓人。我给的建议是如果主板支持两张卡分别跑在PCIe 4.0 x16速率那就能让通信带宽保持在最佳状态。可以用下面的命令检查PCIe链路状态lspci -vv | grep -A20 NVIDIA如果发现第二张卡跑在x8甚至x4速率上优先检查插槽位置和BIOS设置。PCIe带宽不足在长上下文场景下会明显拖慢TP的同步速度这是双卡方案里最容易被忽略的硬件瓶颈。5. 避坑清单双 3090 部署的常见问题这部分是全文最值钱的章节。我把自己踩过的坑、群里朋友踩过的坑全部整理成一份可以直接对照排查的清单。5.1 硬件与显存相关的坑坑一电源功率不足导致满载时直接重启这是我在双3090方案上遇到的第一个大坑。表现是单开一张卡跑模型完全正常两张卡同时高负载推理一段时间后整机突然断电重启。排查了系统日志、显卡驱动、温度最后发现是电源过载保护触发。换了大功率电源后问题彻底消失。这个坑在二手3090方案里非常常见因为很多人的电源是之前单卡配置时买的功率余量不够。坑二散热不足导致温度墙降频3090满载功耗高双卡叠放时间长了温度很容易超过85摄氏度显卡会自动降频推理速度断崖式下跌。用nvidia-smi观察核心温度和功耗nvidia-smi -q -d TEMPERATURE如果温度长期超过82摄氏度就需要考虑加强机箱风道或者用延长线分开安装。运行环境散热做不好性能能掉三成。坑三显存OOM导致整个服务崩溃给--gpu-memory-utilization设置过高值时vLLM会在运行时因为显存不足触发OOM而且OOM后CUDA状态可能整个被污染必须重启服务才能恢复。比较好的策略是先留出安全余量在0.90到0.94之间调试。如果确实需要更大上下文长度优先压缩--max-model-len不要硬拉显存利用率上限。5.2 软件与模型相关的坑坑一PyTorch和vLLM的CUDA版本不一致这个问题在重装环境时经常出现。症状是import torch正常但import vllm后立刻segmentation fault或者报找不到某个CUDA库。解决办法是严格按照我前面说的先装PyTorch再装vLLM并且确认两个包都指向同一个CUDA主版本。用conda list和pip list检查关键包的版本避免混装。坑二模型路径与tokenizer路径不一致如果模型目录文件不完整vLLM会尝试从网上补齐tokenizer文件这时不仅启动速度慢还可能因为网络问题直接卡死。启动前务必检查tokenizer.json、tokenizer_config.json、config.json等核心文件是否就位。另外模型路径不要放在中文目录或带空格目录下有些依赖库对路径解析不友好会突然报一些奇怪的找不到文件错误。坑三Tensor并行时出现NCCL超时启动时如果日志卡在NCCL初始化阶段最终报错“NCCL error: socket connect failed”通常是多卡之间的PCIe通信链路有问题或者是其他进程占用了GPU导致rank之间无法建连。先关掉占用GPU的进程再用CUDA_VISIBLE_DEVICES显式指定两张卡。如果依然报错重启机器基本能解决因为NCCL重建通信链路的能力有时候会被积累的socket连接残留影响。5.3 长期运行的稳定性建议服务部署完不是终点长期稳定运行才是目标。我整理几个自己已经养成的习惯给GPU温度设置告警。可以用nvidia-smi的查询循环搭配简单的脚本也可以直接用已有的监控工具温度超过阈值时发告警避免显卡因为长期高温而加速老化。对vLLM服务做systemd守护让它在意外退出后自动重启。毕竟本地部署的服务不可能像云平台那样配备专人看护一个简单的自动重启机制能省很多事。定期检查显存碎片化和模型加载情况。vLLM的调度器一般会做好显存管理但如果运行时间特别长还是建议每隔一两周重启一次服务释放可能积累的资源占用。vLLM在Profile里也提供了详细的请求和token统计合理利用这些信息能提前预判并发压力。最后再分享一个小技巧如果需要在多机或者跨网络访问这个服务vLLM默认监听在127.0.0.1上可通过--host参数指定监听网卡地址比如vllm serve /data/models/Qwen2.5-14B-Instruct \ --tensor-parallel-size 2 \ --host 0.0.0.0 \ --port 8000把host设为0.0.0.0之后局域网内其他机器就能直接通过宿主机IP访问这个API服务配合OpenAI SDK使用起来跟在云端调用一样方便。不过要注意做好访问控制毕竟内网服务也不希望被随意调用。这套双3090 vLLM Qwen2.5-14B的方案我自己在内部知识库问答、代码辅助、文档摘要几个场景下用得很顺手稳定性也经历了长时间验证。如果你正在评估本地部署大模型这个组合确实值得一试。实际操作中如果碰到什么新坑欢迎多交流我踩过的路你已经可以少踩一遍了。