人工智能实战：单卡GPU不够用怎么办？大模型多GPU推理（数据并行 vs Tensor并行）完整工程方案与性能对比

人工智能实战单卡GPU不够用怎么办大模型多GPU推理数据并行 vs Tensor并行完整工程方案与性能对比一、问题场景不是慢是“卡在单机上限”在完成以下优化之后✔ vLLM 高并发推理 ✔ 队列 回压机制 ✔ 显存控制KV Cache / max_tokens系统在中等负载下表现稳定QPS15~20 平均延迟1.2s GPU利用率85%但很快遇到新的瓶颈 业务增长后的问题1. 用户量上涨QPS需求达到 50 2. 单卡 GPU 利用率已经接近100% 3. 再优化参数几乎没有收益 4. 延迟开始缓慢上升 关键结论系统已经触达“单卡上限”二、为什么“优化已经没用”很多人会继续尝试调temperature 调max_tokens 调batch但这些属于微调优化当系统达到GPU利用率 ≈ 100%意味着算力已经被吃满 此时唯一正确方向扩展算力Scale Out / Scale Up三、扩展GPU的三种方式1️⃣ 垂直扩展Scale Up换更强GPUA10 → A100 → H100缺点成本极高 不可持续2️⃣ 数据并行Data Parallel多个GPU分别处理不同请求3️⃣ Tensor并行Model Parallel一个模型拆到多个GPU上运行 这篇重点如何选 Data Parallel vs Tensor Parallel四、数据并行Data Parallel核心思想每个GPU一份完整模型 请求分发到不同GPU架构请求1 → GPU1 请求2 → GPU2 请求3 → GPU3优点实现简单 扩展性强 适合高并发缺点显存浪费每卡一份模型五、Tensor并行Model Parallel核心思想一个模型拆分到多个GPU执行流程GPU1计算一部分 GPU2计算另一部分 合并结果优点可以跑超大模型7B、13B缺点通信开销大 延迟增加 实现复杂六、什么时候用哪种场景判断非常关键模型小 3B → Data Parallel 模型中等3B~13B → Data Parallel 优先 模型超大13B → Tensor Parallel 实战建议优先 Data Parallel除非显存不够七、方案一多实例 负载均衡推荐架构Client ↓ Nginx / LB ↓ vLLM实例多 ↓ 不同GPU1. 启动多个 vLLM 实例# GPU 0CUDA_VISIBLE_DEVICES0python-mvllm.entrypoints.openai.api_server\--port8001\--modelQwen/Qwen2.5-0.5B-Instruct# GPU 1CUDA_VISIBLE_DEVICES1python-mvllm.entrypoints.openai.api_server\--port8002\--modelQwen/Qwen2.5-0.5B-Instruct2. Nginx负载均衡upstream llm_backend { server 127.0.0.1:8001; server 127.0.0.1:8002; } server { listen 9000; location / { proxy_pass http://llm_backend; } }八、方案二vLLM 内置 Tensor Parallel启动方式python-mvllm.entrypoints.openai.api_server\--modelQwen/Qwen2.5-7B\--tensor-parallel-size2要求多GPU同机 NVLink更佳九、压测验证关键locustfile.pyfromlocustimportHttpUser,taskclassUser(HttpUser):taskdeftest(self):self.client.post(/chat,json{prompt:解释多GPU推理})十、性能对比核心方案QPS延迟单卡201.2s双卡DP381.3s双卡TP221.8s 关键结论Data Parallel 提升吞吐 Tensor Parallel 提升容量十一、踩坑记录真实经验 坑1多实例抢显存忘记设置 CUDA_VISIBLE_DEVICES 坑2负载不均衡某个GPU被打满另一个空闲解决加权轮询 or least_conn 坑3Tensor并行反而更慢原因通信开销 计算收益 坑4显存足够但仍然慢原因KV Cache冲突十二、工程设计建议收藏多GPU选择策略要并发 → Data Parallel 要大模型 → Tensor Parallel 要稳定 → 多实例 队列推荐组合vLLM Data Parallel 队列调度十三、最终结论 单GPU优化的终点是算力上限 多GPU系统的核心能力是如何分配请求 最重要一句话多GPU不是为了“更快”而是为了“更稳”十四、后续优化方向1. GPU池调度多节点 2. Kubernetes GPU调度 3. 动态扩容 4. 跨机通信优化 5. 多模型路由 如果你已经遇到GPU满载 QPS上不去 延迟开始波动那么下一步不是调参数而是扩展你的算力架构