人工智能实战：单卡GPU不够用怎么办？大模型多GPU推理（数据并行 vs Tensor并行）完整工程方案与性能对比
人工智能实战：单卡GPU不够用怎么办？大模型多GPU推理（数据并行 vs Tensor并行）完整工程方案与性能对比
一、问题场景：不是慢，是“卡在单机上限”
在完成以下优化之后：
✔ vLLM 高并发推理 ✔ 队列 + 回压机制 ✔ 显存控制（KV Cache / max_tokens）系统在中等负载下表现稳定：
QPS：15~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）
换更强GPU（A10 → 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_DEVICES=0python-mvllm.entrypoints.openai.api_server\--port8001\--modelQwen/Qwen2.5-0.5B-Instruct# GPU 1CUDA_VISIBLE_DEVICES=1python-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.py
fromlocustimportHttpUser,taskclassUser(HttpUser):@taskdeftest(self):self.client.post("/chat",json={"prompt":"解释多GPU推理"})十、性能对比（核心）
| 方案 | QPS | 延迟 |
|---|---|---|
| 单卡 | 20 | 1.2s |
| 双卡（DP） | 38 | 1.3s |
| 双卡（TP） | 22 | 1.8s |
👉 关键结论：
Data Parallel 提升吞吐 Tensor Parallel 提升容量十一、踩坑记录（真实经验）
🚨 坑1：多实例抢显存
忘记设置 CUDA_VISIBLE_DEVICES🚨 坑2：负载不均衡
某个GPU被打满，另一个空闲解决：
加权轮询 or least_conn🚨 坑3：Tensor并行反而更慢
原因：
通信开销 > 计算收益🚨 坑4：显存足够但仍然慢
原因：
KV Cache冲突十二、工程设计建议（收藏）
多GPU选择策略
要并发 → Data Parallel 要大模型 → Tensor Parallel 要稳定 → 多实例 + 队列推荐组合
vLLM + Data Parallel + 队列调度十三、最终结论
👉 单GPU优化的终点是：
算力上限👉 多GPU系统的核心能力是：
如何分配请求👉 最重要一句话：
多GPU不是为了“更快”，而是为了“更稳”十四、后续优化方向
1. GPU池调度（多节点） 2. Kubernetes GPU调度 3. 动态扩容 4. 跨机通信优化 5. 多模型路由👉 如果你已经遇到：
GPU满载 QPS上不去 延迟开始波动那么下一步不是调参数，而是：
扩展你的算力架构