先说一个我这几年被问到最多的问题“我的推理服务单卡快扛不住了是不是该上多 GPU”每次听到这话我第一反应都是反问一句“你确定瓶颈在 GPU 上吗”不是抬杠是真的见过太多人一遇到卡顿、OOM、并发上不去就急着加卡结果加了卡性能也没好到哪去钱倒是花了不少。这篇文章就把“什么时候该上多 GPU、怎么上、上了之后会踩什么坑”这件事一次讲透。适合正在做 AI 推理服务部署的后端开发、算法工程、运维同学也适合那些用 ComfyUI、llama.cpp、vLLM 跑模型但被显存和并发搞得焦头烂额的个人开发者。先说结论上多 GPU 不是一道“性能不够就加卡”的算术题而是一道“瓶颈判断 架构选型 成本权衡”的综合题。判断错了加多少卡都是白搭。1. 什么时候算“真的不够了”四个可量化的判断信号我见过太多人把“显存不够”和“需要多 GPU”直接画等号这是最常见的误区。显存不够只是表象背后可能是批处理策略不对、模型精度浪费、推理框架没调优甚至只是代码里一个device参数写死了。所以我一般会按下面四个维度来体检全部测完再决定要不要加卡。1.1 显存维度算清楚你到底缺的是显存还是算力先看一个基础的显存估算公式这个我在无数场合强调过但每次还是有人拿错大模型推理时显存占用 模型权重 激活值 KV Cache 框架运行时开销。拿 7B 模型来说FP16 精度下权重就占 14GB 左右这还没算激活值和 KV Cache。你拿一张 24GB 的 4090 或者 16GB 的 V100 去跑权重大头一占剩下的空间可能只够塞几个并发请求的上下文。如果模型升到 70BFP16 权重直接 140GB单卡根本放不下——这种时候“多 GPU”不是优化选项是必选项。但有一种情况特别容易误判你只是想把单 batch 的序列长度拉长或者想塞更多并发请求。这时候缺的其实是 KV Cache 的管理能力而不是物理卡的数量。vLLM 的 PagedAttention、TensorRT-LLM 的 KV Cache 复用都能在单卡上大幅提高显存利用率。我见过有人用 vLLM 优化后单卡 4090 从同时跑 4 个请求提升到 20 多个完全没加卡。所以判断的第一步永远是先把你现有的推理框架压榨干净再说。怎么判断显存真的告急看三个硬指标单请求响应正常但并发一上来就频繁 OOM 或无限排队batch size 一旦调到 8 以上直接显存溢出但不是因为模型权重而是 KV Cache 撑爆用nvidia-smi盯显存发现模型加载后剩余显存不到 20%满足任意两条说明你的显存确实到了物理瓶颈。但如果只是个别请求超时或者 GPU 利用率忽高忽低那先别急着加卡大概率是调度和排队策略的问题。1.2 性能维度延迟和吞吐哪个先崩的显存没爆但服务还是慢这时候要看性能曲线。我习惯把指标拆成两个首 Token 延迟TTFT和生成吞吐 tokens/s。这两个指标崩掉的含义完全不同。首 Token 延迟高说明 Prefill预填充阶段算力不够或者模型太大导致计算密度上不去。这时候加一张卡做张量并行把一个大矩阵拆到两张卡上算能明显把首 Token 延迟压下来。我实测过一个 13B 模型单卡 4090 首 Token 延迟大概 800ms切成双卡张量并行后降到 450ms 左右效果立竿见影。生成吞吐上不去得看 GPU 利用率。如果单卡利用率长期在 95% 以上且 tokens/s 已经逼近理论峰值说明算力真的吃满了。这时候加卡要加“数据并行”也就是同一个模型复制多份每张卡独立处理不同请求负载均衡地分发。如果利用率只有 50% 却还很慢那就是 CPU 预处理、GPU 拷贝、调度器锁竞争之类的瓶颈加卡只会让情况更糟。1.3 成本维度加卡的账其实很好算做技术的人容易忽略成本这件事但实际做决策时它往往是最终拍板因素。我习惯用“单 Token 成本”来算账每月总成本 显卡租用/折旧成本 电费 运维人力成本。每月总 Token 数 日均请求数 × 平均输出长度 × 30。两者一除得到单 Token 成本。如果加卡后单 Token 成本下降说明加卡是划算的如果持平甚至变高就得换个思路。举例来说一张 A100 80G 按月租大概 1.2 万左右跑 7B 模型大概能支撑 200 并发换成两张 A100 做张量并行同样的 7B 模型并发能力提升可能只有 20%但成本翻倍这种加卡就是纯亏。反过来如果模型是 70B 级别单卡根本跑不起来那两卡张量并行就是唯一解谈不上划不划算。1.4 架构维度单实例放不下和撑不住是两回事这是最容易被忽略的一点。我把它分成两种情况一种是模型本身就大于单卡显存比如 70B 模型 FP16 是 140GB单卡物理上就放不下这叫“放不下”另一种是模型能放下但并发一高延迟就超 SLO这叫“撑不住”。“放不下”必须纵向扩展走模型并行/张量并行把一个大模型拆到多卡上。“撑不住”应该横向扩展走数据并行多卡各跑一个副本配合负载均衡。这两种情况解决方案完全不同。我见过有人把“撑不住”的问题用张量并行去解结果两张卡都在算同一个请求并发能力几乎没变纯属钱多烧的。提示先把“放不下”和“撑不住”定义清楚再谈多 GPU 方案。判断标准很简单——单卡能加载模型但不满足并发/延迟就是撑不住单卡加载模型直接 OOM就是放不下。2. 多 GPU 推理的三种架构选型不是堆卡就行确认要上多 GPU 之后真正的技术活才开始。很多人以为多卡就是把模型扔到多张卡上跑其实没那么简单。多 GPU 推理主要分三种并行策略每种解决不同的问题也各有各的代价。2.1 数据并行最省事但治不了“放不下”数据并行是最容易理解的一种每张卡上放一个完整的模型副本请求分发到不同卡上独立处理。它解决的是“撑不住”的问题——单卡能跑但并发不够那就复制 N 份水平扩展。实现方式也很简单vLLM 里设置--tensor-parallel-size 1再用一个负载均衡器把请求分发到多个 vLLM 实例就行或者用 Ray Serve、KServe 这类框架来编排。Pytorch 里也可以用DistributedDataParallel但纯推理场景其实不太需要 DDP 那套梯度同步机制直接用多进程 请求分发更轻量。数据并行最大的坑是显存浪费。每张卡都要存一份完整的权重如果模型 14GB8 张卡就得 112GB 显存来存同一份参数。不过现在很多推理框架做了优化比如 vLLM 支持在数据并行时共享权重多卡只存一份模型参数能省下大量显存。但这个功能目前支持还有限生产环境用的时候要仔细看文档。实操心得如果是 7B、13B 这类中小模型并发扛不住优先考虑数据并行。单卡一个副本前面挂负载均衡比折腾张量并行省心太多。我自己跑过最稳的方案是 Nginx 轮询 多个 vLLM 实例改造成本几乎为零。2.2 张量并行解决“一张卡放不下大模型”的关键方案张量并行Tensor Parallelism是把一个 Transformer 层的权重矩阵切分成多份分别放在不同卡上计算时多卡协作完成同一层的前向传播。它解决的是“放不下”的问题——不是模型太大而是单卡显存放不下整个权重。具体怎么切以 Transformer 的 Attention 和 FFN 为例。Attention 里有 QKV 三个权重矩阵可以按头head切分一个头放一张卡每张卡只负责算自己的头最后把结果拼起来。FFN 里通常有两个线性层第一层叫 down projection按列切分第二层叫 up projection按行切分需要一次 AllReduce 汇总。每层 Transformer 做完通常需要两次跨卡通信。这两次通信是张量并行最主要的性能开销。这意味着什么意味着卡间通信带宽决定张量并行的天花板。NVLink 的带宽在 600GB/s 以上PCIe 4.0 x16 只有约 32GB/s差了一个数量级。如果你只是租了两张云主机拼多卡走的是 PCIe 互联那张量并行后的通信开销可能直接吃掉并行带来的收益。所以做张量并行前先确认卡间是不是 NVLink 互联。业界主流的做法是单机 8 卡内做张量并行因为单机内 NVLink 全互联通信开销小跨机走 RDMA 网络延迟高、带宽有限一般不推荐把张量并行跨机做。vLLM 里设置--tensor-parallel-size 2就是启用两卡张量并行。TensorRT-LLM 里也能通过--tp_size配置底层原理一样。注意张量并行每增加一张卡能承载的模型规模线性增长但通信开销也在涨。超过 4 卡后收益增长会明显放缓。如果模型需要 8 卡以上才能放下建议先考虑量化或者模型剪枝而不是硬堆卡。2.3 流水线并行大模型的最后一根稻草流水线并行Pipeline Parallelism是把 Transformer 的不同层放在不同卡上第 1 到第 N 层在卡 A第 N1 到第 2N 层在卡 B数据像流水线一样从一张卡流到下一张卡。它解决的同样是“放不下”但更适合那种“张量切不动”的场景。为啥不全都用张量并行因为张量并行是“每层都要跨卡通信”层数一多通信次数线性增长通信开销变得不可接受。流水线并行是“层间通信”一层算完把中间结果传给下一层就行通信频率低得多。但流水线并行有个著名的问题叫“气泡”bubble想象一条流水线上第 1 个 batch 在卡 A 算第一层时卡 B 是空闲的等第 1 个 batch 到卡 B 了卡 A 又开始算第 2 个 batch中间总有卡闲着。气泡率一高整体吞吐可能还不如单卡。所以实际部署中流水线并行很少单独用通常是张量并行 流水线并行混合比如 2 卡张量并行 × 2 组流水线。这样既有张量并行的显存分摊能力又有流水线并行的通信优势。vLLM 里对应的是--tensor-parallel-size 2 --pipeline-parallel-size 2。我在实际项目中跑过 70B 模型4 卡配置用 2TP 2PP吞吐比纯 4 卡张量并行稳定不少。三种并行策略的适用场景我整理了一张表方便对比并行方式解决的核心问题卡间通信依赖适用场景典型配置数据并行并发量不够低几乎无模型单卡能放下并发需扩展多实例 Nginx/Ray Serve张量并行单卡放不下大模型高NVLink 必须70B 大模型单机推理vLLM tp_size2/4流水线并行层数太深张量切分通信过多中单机内即可超大模型单机多卡tp pp 混合配置专家并行MoE 模型专家分散中高Mixtral 等 MoE 架构模型vLLM 自动调度3. 实操落地从选框架到调参数的一次完整部署架构选型只是理论正确真正落地时你会发现一堆细节问题。这部分写写我实际部署多 GPU 推理服务时踩过的坑和验证过有效的配置。3.1 推理框架到底选哪个vLLM、TensorRT-LLM 还是 llama.cpp多 GPU 推理不是把模型扔到卡上就能跑还得靠推理框架来调度显存、管理并发、优化计算图。不同框架的多卡支持程度和配置方式差异很大。vLLM 是目前社区最活跃的推理框架PagedAttention 把显存利用做到了极致对多卡支持也很成熟。配置方式是在启动命令里指定--tensor-parallel-size和--pipeline-parallel-size参数。它最大的优势是开箱即用HuggingFace 生态的模型基本都能直接加载社区踩坑资料也最多。缺点是官方对 MoE 模型的多卡调度支持还在迭代中有些量化格式兼容性一般。TensorRT-LLM 是 NVIDIA 官方出品的推理框架基于 TensorRT 做极致优化性能通常比 vLLM 高 20%-30%尤其是对 FP8 量化和多卡通信做了专门调优。但配置繁琐得多需要把模型转换成 TensorRT 引擎格式转换过程经常遇到算子不兼容的问题。适合那种已经稳定运行、追求极致性能的生产环境不适合频繁换模型的场景。llama.cpp 一般被认为是“本地跑模型”的工具但它的多 GPU 支持其实相当实用。通过设置--split-mode layer可以将不同层分配到不同 GPU--split-mode row则是按行切分权重。实测在 MacBook 多 GPU 和消费级双卡环境下llama.cpp 的稳定性比 vLLM 好毕竟它的 CPU 回退机制成熟得多。缺点是并发和吞吐优化不如 vLLM。ComfyUI 用户可能更关心多 GPU 的显存管理。ComfyUI 的多 GPU 方案本质上是给不同节点分配不同设备比如检测模型放 GPU 0放大模型放 GPU 1。这样两个模型可以并行跑显存占用也能分散到两张卡上。实际配的时候在节点的device参数里直接指定就行。比如class MyNode: def __init__(self): self.device torch.device(cuda:1 if torch.cuda.is_available() else cpu)这里需要特别提醒ComfyUI 的多 GPU 不是“一张卡跑一个模型副本”而是“不同模型放不同卡”。如果你跑的是视频生成这类大模型单卡放不下ComfyUI 本身并不擅长这种场景得靠自定义节点配合张量并行来实现。3.2 关键参数详解这些配置决定多卡性能选定框架后参数配置直接决定多卡效果。我在 vLLM 里最常用的几个参数按重要性排序gpu_memory_utilization是最容易被忽视的参数它控制框架最多能占用多少显存默认 0.9意味着要预留 10% 给 CUDA context 和其他开销。多卡环境下这个值要设置得保守一些比如 0.85因为多卡间的通信缓冲也要占显存。设太高容易在并发高峰时 OOM设太低则浪费显存。max_num_seqs决定并发序列数。很多人以为设得越大越好其实不然。每增加一个序列KV Cache 占用就多一份如果超过显存容量vLLM 会做 swap 或者 preemption反而拖慢整体吞吐。我的经验是先看单序列最大长度需要的 KV Cache再反推max_num_seqs。比如 7B 模型单序列 2048 token 的 KV Cache 大概在 200MB 左右24GB 显存减去 14GB 权重和 2GB 开销大概剩余 8GB那max_num_seqs设为 30-40 比较合理。enforce_eager这个参数如果是False默认vLLM 会用 CUDA Graph 加速首次推理时有预热时间如果设成True跳过图捕获首次推理更快但整体吞吐略降。多卡环境下这个参数的影响会被放大因为图捕获需要更多显存做缓存。如果内存紧张建议直接开enforce_eagerTrue。max_model_len控制最大上下文长度也会直接影响 KV Cache 预留大小。实操心得多卡环境调参遵循“先小后大”的原则。先用最小配置单请求、短上下文跑通确认显存基线再逐步加并发、加长度每一步都观察显存和延迟变化。千万不要一开始就把所有参数拉满多卡环境下的 OOM 排错难度比单卡高一个量级。PyTorch 生态下如果你只是想快速把模型塞进多卡HuggingFace Transformers 提供了最简单的入口from transformers import AutoModelForCausalLM model AutoModelForCausalLM.from_pretrained( meta-llama/Llama-2-7b-chat-hf, device_mapauto, # 自动分配到可用 GPU torch_dtypetorch.float16, )device_mapauto在加速库accelerate的支撑下会按显存大小自动切分模型把不同的层分配到不同 GPU 上。这种方法对 7B-13B 模型特别省事十几行代码就完成多卡部署。但要注意自动切分不一定最优切分方案可能产生较多的跨卡数据传输。想精确控制就手动指定device_map的层到卡映射关系。3.3 实际部署过程一个 13B 模型双卡部署的记录这里记录一个我最近的部署实例环境是双卡 4090NVLink 桥接跑 13B 模型目标是支撑 50 并发且单请求首 Token 延迟低于 600ms。第一步先排查单卡是否真的到瓶颈。单卡 4090 加载 13B FP16 模型需要约 26GB 显存单卡 24GB 实际放不下所以“放不下”的情况命中必须上多卡。这就直接排除了数据并行方案因为数据并行要求单卡能放下完整模型。于是选择张量并行。第二步确定切分方式。双卡 4090 有 NVLink通信带宽足够使用 tp_size2。启动命令如下python -m vllm.entrypoints.openai.api_server \ --model /path/to/model \ --tensor-parallel-size 2 \ --gpu-memory-utilization 0.85 \ --max-model-len 4096 \ --enforce-eager第三步压测验证。用脚本模拟 50 并发请求看首 Token 延迟和 tokens/s。import asyncio from openai import AsyncOpenAI client AsyncOpenAI(base_urlhttp://localhost:8000/v1, api_keyEMPTY) async def send_one(prompt): start time.time() resp await client.chat.completions.create( modeldefault, messages[{role: user, content: prompt}], max_tokens200, ) return time.time() - start, resp.choices[0].message.content async def main(): tasks [send_one(讲个笑话) for _ in range(50)] results await asyncio.gather(*tasks) latencies [r[0] for r in results] print(fP50: {sorted(latencies)[25]:.2f}s, P95: {sorted(latencies)[47]:.2f}s) asyncio.run(main())实测结果单卡 4090 OOM 无法加载双卡 tp_size2 首次部署后P50 延迟 380msP95 680ms吞吐约 350 tokens/s满足需求。但中间也踩了好几个坑下面详细说。4. 踩坑实录多 GPU 部署的典型问题排查多 GPU 环境比单卡复杂得多问题的表现也更隐蔽。我把实际遇到的典型问题整理成速查表每个都附上排查思路和解决方案。这部分指标可能比较枯燥但都是真金白银换来的经验。4.1 多 GPU 常见问题速查表先给一张总表方便遇到问题时快速检索现象根因快速排查方式解决方案GPU 0 满载GPU 1 利用率 0代码里device写死成cuda:0nvidia-smi观察各卡利用率检查模型和数据加载的 device 分配双卡后吞吐不升反降卡间走 PCIe通信成为瓶颈nvidia-smi topo -m查看卡间拓扑换 NVLink 互联或改用数据并行显存看着够但 OOM显存碎片化或 CUDA context 占用重启进程后 OOM 消失则碎片化开启 PagedAttention降低gpu-memory-utilization模型加载到一半卡住跨卡时 NCCL 初始化失败看 NCCL 报错日志检查网卡和 NCCL 版本设置NCCL_DEBUGINFO推理结果错误或不一致张量并行切分方案与模型结构不匹配单卡跑同一请求对比结果检查框架版本确认模型格式兼容多卡启动报显存不足但单卡没问题每张卡的 CUDA context 独立占用显存看启动日志中每个进程的显存分配调低gpu-memory-utilization预留 context 开销GPU 间通信失败报gpu crash dump triggered显存访问越界或驱动不稳定查看系统 dmesg 日志更新驱动检查是否有超频/温度过高问题4.2 排查实操三个真实案例第一个案例是前文说的双卡部署启动后 A 卡利用率 100%B 卡只有 5%。排查过程很简单nvidia-smi看进程发现模型的参数全被加载到 GPU 0GPU 1 只参与了极少量的张量并行通信。继续深挖发现是模型 checkpoint 格式问题——模型本身是单卡训练后保存的张量并行的切分逻辑没被正确触发。解决方案是改用 vLLM 的llm LLM(model..., tensor_parallel_size2)接口让 vLLM 接管切分。第二个案例是双卡吞吐反而比单卡低。排查时先确认卡间拓扑nvidia-smi topo -m显示两张卡走 PCIe 而不是 NVLink通信带宽受限。张量并行的每层两次 AllReduce 全部走 PCIe延迟高到完全抵消并行收益。当时没有物理 NVLink 桥最终方案是改成数据并行——反正模型 13B 正好能塞进 24GB 单卡数据并行靠负载均衡提升并发比张量并行省事且稳定。第三个案例更隐蔽是显存看着还有 6GB 空闲但 OOM。排查时先看nvidia-smi注意到已用显存超过 80%vLLM 报的是 CUDA OOM 而非普通申请失败。经分析是 vLLM 的 KV Cache 预留策略和gpu-memory-utilization参数冲突gpu_memory_utilization0.9意味着 vLLM 认为 90% 显存可全权使用但其他进程比如监控代理、CUDA context占用了剩余 10% 之外的显存碰撞导致 OOM。调成 0.85 后问题消失。4.3 运维与监控多 GPU 环境的三条防线多 GPU 服务一旦上线监控就变成刚需。我的建议是至少做三层监控。第一层是硬件级监控。nvidia-smi是基础但要推送到时序数据库建议用dcgmiNVIDIA Data Center GPU Manager能采集更细的指标比如 GPU 温度、功耗、NVLink 带宽利用率、ECC 错误计数。自定义 Prometheus exporter 也可以社区有nvidia_gpu_exporter可以用多卡环境下记得给每张卡打上 index 标签否则指标串了会让你排查问题查到怀疑人生。第二层是推理框架级监控。vLLM 内置了 Prometheus metrics暴露了vllm:num_requests_running、vllm:num_requests_waiting、vllm:gpu_cache_usage_perc这些关键指标。gpu_cache_usage_perc尤为重要超过 0.9 就说明 KV Cache 快满了要么扩容要么调低并发。多卡环境下要分别看每个 rank 的指标因为张量并行的多卡共享同一批请求一张卡缓存满了整组都会遭殃。第三层是业务级监控。延迟、QPS、错误率这些指标必须和 GPU 指标关联起来看。我习惯在 Grafana 里建一个仪表盘左侧放延迟曲线右侧放 GPU 利用率和显存顶部放 KV Cache 使用率三个维度放一起一眼就能定位瓶颈。注意NVIDIA 驱动版本是硬约束。多卡场景对驱动的稳定性要求远高于单卡。我踩过的坑是 CUDA 11.8 的驱动跑新出的 PyTorch 2.3 一直报错升级到 535 系列驱动后问题解决。生产环境选择驱动版本一定要看官方兼容性矩阵不要贪新。5. 什么时候“不用上多 GPU”三个值得重新考虑的替代方案这篇文章的主题是“什么时候该上多 GPU”但我还是要花一整节讲“什么时候不该上”。因为在实际工作中我见过太多其实不需要上多 GPU 的场景最后靠其他方案把成本打下来了一半。5.1 量化四两拨千斤的显存救星模型量化是目前性价比最高的显存优化手段。FP16 转 INT8 直接减半显存转 INT4 可以减到四分之一。7B 模型 FP16 是 14GBINT4 后只需约 4GB一张消费级显卡就能跑起来。70B 模型 FP16 是 140GBINT4 后降到 35GB 左右一张 80G 的 A100 甚至都能勉强放下根本不需要双卡。但量化不是没有代价。量化后模型精度会有一定损失尤其是 INT4 在复杂推理任务上可能出现明显的质量下降。实测经验是7B 模型 INT8 量化后质量损失几乎感知不到INT4 在通用对话场景也能接受但如果做代码生成、数学推理建议还是保留 FP16 或 INT8。多 GPU 部署时也可以考虑混合精度策略——关键层保留高精度非关键层走低精度。5.2 推理优化有时候问题出在框架而不是硬件前面提到 vLLM 的 PagedAttention 和连续批处理continuous batching这两项技术可以说是近年来推理优化最大的突破。PagedAttention 类似操作系统的虚拟内存管理把 KV Cache 切分成固定大小的块按需分配不再要求物理连续大幅减少显存碎片和浪费。连续批处理则是“动态 batching”不需要等整个 batch 全部生成完再处理下一批而是每生成一个 token 就把完成的序列移出、插入新序列让 GPU 时刻保持高利用率。这两项技术叠加在单卡上就能把吞吐提升数倍。所以如果你还在用最原始的model.generate()逐请求处理先别急着加卡换个框架可能就解决了。这也是我在判断“该不该上多 GPU”时最先排除的因素。5.3 弹性推理和无服务器架构把成本摊到每个请求如果业务流量有明显波峰波谷比如白天高并发、晚上低并发那固定扩容多 GPU 其实非常浪费。这种情况下用弹性推理服务比如 KServe Knative或者主流的 Serverless GPU 平台按请求量动态伸缩实例数量可能比固定多卡便宜得多。这类方案的思路是底层并不限制单实例只能用单卡而是通过水平扩容多副本来吸收流量高峰时多起几个实例低谷时缩到零。如果单个模型实例需要多卡也可以结合前面说的张量并行但建议把这个“多卡组”做成弹性单元而不是常驻。运维复杂度会上升但成本优化的空间也很大。不要为了“用多 GPU”而上多 GPU。先问自己量化试过了吗推理框架换了吗弹性伸缩考虑了吗这三个方案都没解决你的问题再来动多 GPU 的念头。这是我从无数次成本复盘里总结出来的原则扛住了不少老板的质疑。5.4 最后分享一个小技巧上线前多花半小时做容量规划这套规划方法虽然不花什么成本但能帮你省下非常多的后续麻烦。上线前先做三件事第一用压测工具比如 Locust、k6或者简单的 AsyncOpenAI 脚本测出单卡实际能支撑的最大并发和 P95 延迟第二根据业务预估峰值流量计算出需要的总并发数第三把这个总并发数除以单卡并发数得出理论卡数再乘 1.3-1.5 的冗余系数这就是你真正需要上几张卡的答案。踩过几次坑之后我现在每接一个新项目都会照这个流程走一遍极少再出现“上线第一天就因为并发预估不足而加急扩容”的尴尬。算力容量这件事最贵的是事后补救最便宜的是事前规划这话放在多 GPU 场景里再合适不过。
多GPU推理实战指南：从瓶颈判断到并行架构选型与避坑
先说一个我这几年被问到最多的问题“我的推理服务单卡快扛不住了是不是该上多 GPU”每次听到这话我第一反应都是反问一句“你确定瓶颈在 GPU 上吗”不是抬杠是真的见过太多人一遇到卡顿、OOM、并发上不去就急着加卡结果加了卡性能也没好到哪去钱倒是花了不少。这篇文章就把“什么时候该上多 GPU、怎么上、上了之后会踩什么坑”这件事一次讲透。适合正在做 AI 推理服务部署的后端开发、算法工程、运维同学也适合那些用 ComfyUI、llama.cpp、vLLM 跑模型但被显存和并发搞得焦头烂额的个人开发者。先说结论上多 GPU 不是一道“性能不够就加卡”的算术题而是一道“瓶颈判断 架构选型 成本权衡”的综合题。判断错了加多少卡都是白搭。1. 什么时候算“真的不够了”四个可量化的判断信号我见过太多人把“显存不够”和“需要多 GPU”直接画等号这是最常见的误区。显存不够只是表象背后可能是批处理策略不对、模型精度浪费、推理框架没调优甚至只是代码里一个device参数写死了。所以我一般会按下面四个维度来体检全部测完再决定要不要加卡。1.1 显存维度算清楚你到底缺的是显存还是算力先看一个基础的显存估算公式这个我在无数场合强调过但每次还是有人拿错大模型推理时显存占用 模型权重 激活值 KV Cache 框架运行时开销。拿 7B 模型来说FP16 精度下权重就占 14GB 左右这还没算激活值和 KV Cache。你拿一张 24GB 的 4090 或者 16GB 的 V100 去跑权重大头一占剩下的空间可能只够塞几个并发请求的上下文。如果模型升到 70BFP16 权重直接 140GB单卡根本放不下——这种时候“多 GPU”不是优化选项是必选项。但有一种情况特别容易误判你只是想把单 batch 的序列长度拉长或者想塞更多并发请求。这时候缺的其实是 KV Cache 的管理能力而不是物理卡的数量。vLLM 的 PagedAttention、TensorRT-LLM 的 KV Cache 复用都能在单卡上大幅提高显存利用率。我见过有人用 vLLM 优化后单卡 4090 从同时跑 4 个请求提升到 20 多个完全没加卡。所以判断的第一步永远是先把你现有的推理框架压榨干净再说。怎么判断显存真的告急看三个硬指标单请求响应正常但并发一上来就频繁 OOM 或无限排队batch size 一旦调到 8 以上直接显存溢出但不是因为模型权重而是 KV Cache 撑爆用nvidia-smi盯显存发现模型加载后剩余显存不到 20%满足任意两条说明你的显存确实到了物理瓶颈。但如果只是个别请求超时或者 GPU 利用率忽高忽低那先别急着加卡大概率是调度和排队策略的问题。1.2 性能维度延迟和吞吐哪个先崩的显存没爆但服务还是慢这时候要看性能曲线。我习惯把指标拆成两个首 Token 延迟TTFT和生成吞吐 tokens/s。这两个指标崩掉的含义完全不同。首 Token 延迟高说明 Prefill预填充阶段算力不够或者模型太大导致计算密度上不去。这时候加一张卡做张量并行把一个大矩阵拆到两张卡上算能明显把首 Token 延迟压下来。我实测过一个 13B 模型单卡 4090 首 Token 延迟大概 800ms切成双卡张量并行后降到 450ms 左右效果立竿见影。生成吞吐上不去得看 GPU 利用率。如果单卡利用率长期在 95% 以上且 tokens/s 已经逼近理论峰值说明算力真的吃满了。这时候加卡要加“数据并行”也就是同一个模型复制多份每张卡独立处理不同请求负载均衡地分发。如果利用率只有 50% 却还很慢那就是 CPU 预处理、GPU 拷贝、调度器锁竞争之类的瓶颈加卡只会让情况更糟。1.3 成本维度加卡的账其实很好算做技术的人容易忽略成本这件事但实际做决策时它往往是最终拍板因素。我习惯用“单 Token 成本”来算账每月总成本 显卡租用/折旧成本 电费 运维人力成本。每月总 Token 数 日均请求数 × 平均输出长度 × 30。两者一除得到单 Token 成本。如果加卡后单 Token 成本下降说明加卡是划算的如果持平甚至变高就得换个思路。举例来说一张 A100 80G 按月租大概 1.2 万左右跑 7B 模型大概能支撑 200 并发换成两张 A100 做张量并行同样的 7B 模型并发能力提升可能只有 20%但成本翻倍这种加卡就是纯亏。反过来如果模型是 70B 级别单卡根本跑不起来那两卡张量并行就是唯一解谈不上划不划算。1.4 架构维度单实例放不下和撑不住是两回事这是最容易被忽略的一点。我把它分成两种情况一种是模型本身就大于单卡显存比如 70B 模型 FP16 是 140GB单卡物理上就放不下这叫“放不下”另一种是模型能放下但并发一高延迟就超 SLO这叫“撑不住”。“放不下”必须纵向扩展走模型并行/张量并行把一个大模型拆到多卡上。“撑不住”应该横向扩展走数据并行多卡各跑一个副本配合负载均衡。这两种情况解决方案完全不同。我见过有人把“撑不住”的问题用张量并行去解结果两张卡都在算同一个请求并发能力几乎没变纯属钱多烧的。提示先把“放不下”和“撑不住”定义清楚再谈多 GPU 方案。判断标准很简单——单卡能加载模型但不满足并发/延迟就是撑不住单卡加载模型直接 OOM就是放不下。2. 多 GPU 推理的三种架构选型不是堆卡就行确认要上多 GPU 之后真正的技术活才开始。很多人以为多卡就是把模型扔到多张卡上跑其实没那么简单。多 GPU 推理主要分三种并行策略每种解决不同的问题也各有各的代价。2.1 数据并行最省事但治不了“放不下”数据并行是最容易理解的一种每张卡上放一个完整的模型副本请求分发到不同卡上独立处理。它解决的是“撑不住”的问题——单卡能跑但并发不够那就复制 N 份水平扩展。实现方式也很简单vLLM 里设置--tensor-parallel-size 1再用一个负载均衡器把请求分发到多个 vLLM 实例就行或者用 Ray Serve、KServe 这类框架来编排。Pytorch 里也可以用DistributedDataParallel但纯推理场景其实不太需要 DDP 那套梯度同步机制直接用多进程 请求分发更轻量。数据并行最大的坑是显存浪费。每张卡都要存一份完整的权重如果模型 14GB8 张卡就得 112GB 显存来存同一份参数。不过现在很多推理框架做了优化比如 vLLM 支持在数据并行时共享权重多卡只存一份模型参数能省下大量显存。但这个功能目前支持还有限生产环境用的时候要仔细看文档。实操心得如果是 7B、13B 这类中小模型并发扛不住优先考虑数据并行。单卡一个副本前面挂负载均衡比折腾张量并行省心太多。我自己跑过最稳的方案是 Nginx 轮询 多个 vLLM 实例改造成本几乎为零。2.2 张量并行解决“一张卡放不下大模型”的关键方案张量并行Tensor Parallelism是把一个 Transformer 层的权重矩阵切分成多份分别放在不同卡上计算时多卡协作完成同一层的前向传播。它解决的是“放不下”的问题——不是模型太大而是单卡显存放不下整个权重。具体怎么切以 Transformer 的 Attention 和 FFN 为例。Attention 里有 QKV 三个权重矩阵可以按头head切分一个头放一张卡每张卡只负责算自己的头最后把结果拼起来。FFN 里通常有两个线性层第一层叫 down projection按列切分第二层叫 up projection按行切分需要一次 AllReduce 汇总。每层 Transformer 做完通常需要两次跨卡通信。这两次通信是张量并行最主要的性能开销。这意味着什么意味着卡间通信带宽决定张量并行的天花板。NVLink 的带宽在 600GB/s 以上PCIe 4.0 x16 只有约 32GB/s差了一个数量级。如果你只是租了两张云主机拼多卡走的是 PCIe 互联那张量并行后的通信开销可能直接吃掉并行带来的收益。所以做张量并行前先确认卡间是不是 NVLink 互联。业界主流的做法是单机 8 卡内做张量并行因为单机内 NVLink 全互联通信开销小跨机走 RDMA 网络延迟高、带宽有限一般不推荐把张量并行跨机做。vLLM 里设置--tensor-parallel-size 2就是启用两卡张量并行。TensorRT-LLM 里也能通过--tp_size配置底层原理一样。注意张量并行每增加一张卡能承载的模型规模线性增长但通信开销也在涨。超过 4 卡后收益增长会明显放缓。如果模型需要 8 卡以上才能放下建议先考虑量化或者模型剪枝而不是硬堆卡。2.3 流水线并行大模型的最后一根稻草流水线并行Pipeline Parallelism是把 Transformer 的不同层放在不同卡上第 1 到第 N 层在卡 A第 N1 到第 2N 层在卡 B数据像流水线一样从一张卡流到下一张卡。它解决的同样是“放不下”但更适合那种“张量切不动”的场景。为啥不全都用张量并行因为张量并行是“每层都要跨卡通信”层数一多通信次数线性增长通信开销变得不可接受。流水线并行是“层间通信”一层算完把中间结果传给下一层就行通信频率低得多。但流水线并行有个著名的问题叫“气泡”bubble想象一条流水线上第 1 个 batch 在卡 A 算第一层时卡 B 是空闲的等第 1 个 batch 到卡 B 了卡 A 又开始算第 2 个 batch中间总有卡闲着。气泡率一高整体吞吐可能还不如单卡。所以实际部署中流水线并行很少单独用通常是张量并行 流水线并行混合比如 2 卡张量并行 × 2 组流水线。这样既有张量并行的显存分摊能力又有流水线并行的通信优势。vLLM 里对应的是--tensor-parallel-size 2 --pipeline-parallel-size 2。我在实际项目中跑过 70B 模型4 卡配置用 2TP 2PP吞吐比纯 4 卡张量并行稳定不少。三种并行策略的适用场景我整理了一张表方便对比并行方式解决的核心问题卡间通信依赖适用场景典型配置数据并行并发量不够低几乎无模型单卡能放下并发需扩展多实例 Nginx/Ray Serve张量并行单卡放不下大模型高NVLink 必须70B 大模型单机推理vLLM tp_size2/4流水线并行层数太深张量切分通信过多中单机内即可超大模型单机多卡tp pp 混合配置专家并行MoE 模型专家分散中高Mixtral 等 MoE 架构模型vLLM 自动调度3. 实操落地从选框架到调参数的一次完整部署架构选型只是理论正确真正落地时你会发现一堆细节问题。这部分写写我实际部署多 GPU 推理服务时踩过的坑和验证过有效的配置。3.1 推理框架到底选哪个vLLM、TensorRT-LLM 还是 llama.cpp多 GPU 推理不是把模型扔到卡上就能跑还得靠推理框架来调度显存、管理并发、优化计算图。不同框架的多卡支持程度和配置方式差异很大。vLLM 是目前社区最活跃的推理框架PagedAttention 把显存利用做到了极致对多卡支持也很成熟。配置方式是在启动命令里指定--tensor-parallel-size和--pipeline-parallel-size参数。它最大的优势是开箱即用HuggingFace 生态的模型基本都能直接加载社区踩坑资料也最多。缺点是官方对 MoE 模型的多卡调度支持还在迭代中有些量化格式兼容性一般。TensorRT-LLM 是 NVIDIA 官方出品的推理框架基于 TensorRT 做极致优化性能通常比 vLLM 高 20%-30%尤其是对 FP8 量化和多卡通信做了专门调优。但配置繁琐得多需要把模型转换成 TensorRT 引擎格式转换过程经常遇到算子不兼容的问题。适合那种已经稳定运行、追求极致性能的生产环境不适合频繁换模型的场景。llama.cpp 一般被认为是“本地跑模型”的工具但它的多 GPU 支持其实相当实用。通过设置--split-mode layer可以将不同层分配到不同 GPU--split-mode row则是按行切分权重。实测在 MacBook 多 GPU 和消费级双卡环境下llama.cpp 的稳定性比 vLLM 好毕竟它的 CPU 回退机制成熟得多。缺点是并发和吞吐优化不如 vLLM。ComfyUI 用户可能更关心多 GPU 的显存管理。ComfyUI 的多 GPU 方案本质上是给不同节点分配不同设备比如检测模型放 GPU 0放大模型放 GPU 1。这样两个模型可以并行跑显存占用也能分散到两张卡上。实际配的时候在节点的device参数里直接指定就行。比如class MyNode: def __init__(self): self.device torch.device(cuda:1 if torch.cuda.is_available() else cpu)这里需要特别提醒ComfyUI 的多 GPU 不是“一张卡跑一个模型副本”而是“不同模型放不同卡”。如果你跑的是视频生成这类大模型单卡放不下ComfyUI 本身并不擅长这种场景得靠自定义节点配合张量并行来实现。3.2 关键参数详解这些配置决定多卡性能选定框架后参数配置直接决定多卡效果。我在 vLLM 里最常用的几个参数按重要性排序gpu_memory_utilization是最容易被忽视的参数它控制框架最多能占用多少显存默认 0.9意味着要预留 10% 给 CUDA context 和其他开销。多卡环境下这个值要设置得保守一些比如 0.85因为多卡间的通信缓冲也要占显存。设太高容易在并发高峰时 OOM设太低则浪费显存。max_num_seqs决定并发序列数。很多人以为设得越大越好其实不然。每增加一个序列KV Cache 占用就多一份如果超过显存容量vLLM 会做 swap 或者 preemption反而拖慢整体吞吐。我的经验是先看单序列最大长度需要的 KV Cache再反推max_num_seqs。比如 7B 模型单序列 2048 token 的 KV Cache 大概在 200MB 左右24GB 显存减去 14GB 权重和 2GB 开销大概剩余 8GB那max_num_seqs设为 30-40 比较合理。enforce_eager这个参数如果是False默认vLLM 会用 CUDA Graph 加速首次推理时有预热时间如果设成True跳过图捕获首次推理更快但整体吞吐略降。多卡环境下这个参数的影响会被放大因为图捕获需要更多显存做缓存。如果内存紧张建议直接开enforce_eagerTrue。max_model_len控制最大上下文长度也会直接影响 KV Cache 预留大小。实操心得多卡环境调参遵循“先小后大”的原则。先用最小配置单请求、短上下文跑通确认显存基线再逐步加并发、加长度每一步都观察显存和延迟变化。千万不要一开始就把所有参数拉满多卡环境下的 OOM 排错难度比单卡高一个量级。PyTorch 生态下如果你只是想快速把模型塞进多卡HuggingFace Transformers 提供了最简单的入口from transformers import AutoModelForCausalLM model AutoModelForCausalLM.from_pretrained( meta-llama/Llama-2-7b-chat-hf, device_mapauto, # 自动分配到可用 GPU torch_dtypetorch.float16, )device_mapauto在加速库accelerate的支撑下会按显存大小自动切分模型把不同的层分配到不同 GPU 上。这种方法对 7B-13B 模型特别省事十几行代码就完成多卡部署。但要注意自动切分不一定最优切分方案可能产生较多的跨卡数据传输。想精确控制就手动指定device_map的层到卡映射关系。3.3 实际部署过程一个 13B 模型双卡部署的记录这里记录一个我最近的部署实例环境是双卡 4090NVLink 桥接跑 13B 模型目标是支撑 50 并发且单请求首 Token 延迟低于 600ms。第一步先排查单卡是否真的到瓶颈。单卡 4090 加载 13B FP16 模型需要约 26GB 显存单卡 24GB 实际放不下所以“放不下”的情况命中必须上多卡。这就直接排除了数据并行方案因为数据并行要求单卡能放下完整模型。于是选择张量并行。第二步确定切分方式。双卡 4090 有 NVLink通信带宽足够使用 tp_size2。启动命令如下python -m vllm.entrypoints.openai.api_server \ --model /path/to/model \ --tensor-parallel-size 2 \ --gpu-memory-utilization 0.85 \ --max-model-len 4096 \ --enforce-eager第三步压测验证。用脚本模拟 50 并发请求看首 Token 延迟和 tokens/s。import asyncio from openai import AsyncOpenAI client AsyncOpenAI(base_urlhttp://localhost:8000/v1, api_keyEMPTY) async def send_one(prompt): start time.time() resp await client.chat.completions.create( modeldefault, messages[{role: user, content: prompt}], max_tokens200, ) return time.time() - start, resp.choices[0].message.content async def main(): tasks [send_one(讲个笑话) for _ in range(50)] results await asyncio.gather(*tasks) latencies [r[0] for r in results] print(fP50: {sorted(latencies)[25]:.2f}s, P95: {sorted(latencies)[47]:.2f}s) asyncio.run(main())实测结果单卡 4090 OOM 无法加载双卡 tp_size2 首次部署后P50 延迟 380msP95 680ms吞吐约 350 tokens/s满足需求。但中间也踩了好几个坑下面详细说。4. 踩坑实录多 GPU 部署的典型问题排查多 GPU 环境比单卡复杂得多问题的表现也更隐蔽。我把实际遇到的典型问题整理成速查表每个都附上排查思路和解决方案。这部分指标可能比较枯燥但都是真金白银换来的经验。4.1 多 GPU 常见问题速查表先给一张总表方便遇到问题时快速检索现象根因快速排查方式解决方案GPU 0 满载GPU 1 利用率 0代码里device写死成cuda:0nvidia-smi观察各卡利用率检查模型和数据加载的 device 分配双卡后吞吐不升反降卡间走 PCIe通信成为瓶颈nvidia-smi topo -m查看卡间拓扑换 NVLink 互联或改用数据并行显存看着够但 OOM显存碎片化或 CUDA context 占用重启进程后 OOM 消失则碎片化开启 PagedAttention降低gpu-memory-utilization模型加载到一半卡住跨卡时 NCCL 初始化失败看 NCCL 报错日志检查网卡和 NCCL 版本设置NCCL_DEBUGINFO推理结果错误或不一致张量并行切分方案与模型结构不匹配单卡跑同一请求对比结果检查框架版本确认模型格式兼容多卡启动报显存不足但单卡没问题每张卡的 CUDA context 独立占用显存看启动日志中每个进程的显存分配调低gpu-memory-utilization预留 context 开销GPU 间通信失败报gpu crash dump triggered显存访问越界或驱动不稳定查看系统 dmesg 日志更新驱动检查是否有超频/温度过高问题4.2 排查实操三个真实案例第一个案例是前文说的双卡部署启动后 A 卡利用率 100%B 卡只有 5%。排查过程很简单nvidia-smi看进程发现模型的参数全被加载到 GPU 0GPU 1 只参与了极少量的张量并行通信。继续深挖发现是模型 checkpoint 格式问题——模型本身是单卡训练后保存的张量并行的切分逻辑没被正确触发。解决方案是改用 vLLM 的llm LLM(model..., tensor_parallel_size2)接口让 vLLM 接管切分。第二个案例是双卡吞吐反而比单卡低。排查时先确认卡间拓扑nvidia-smi topo -m显示两张卡走 PCIe 而不是 NVLink通信带宽受限。张量并行的每层两次 AllReduce 全部走 PCIe延迟高到完全抵消并行收益。当时没有物理 NVLink 桥最终方案是改成数据并行——反正模型 13B 正好能塞进 24GB 单卡数据并行靠负载均衡提升并发比张量并行省事且稳定。第三个案例更隐蔽是显存看着还有 6GB 空闲但 OOM。排查时先看nvidia-smi注意到已用显存超过 80%vLLM 报的是 CUDA OOM 而非普通申请失败。经分析是 vLLM 的 KV Cache 预留策略和gpu-memory-utilization参数冲突gpu_memory_utilization0.9意味着 vLLM 认为 90% 显存可全权使用但其他进程比如监控代理、CUDA context占用了剩余 10% 之外的显存碰撞导致 OOM。调成 0.85 后问题消失。4.3 运维与监控多 GPU 环境的三条防线多 GPU 服务一旦上线监控就变成刚需。我的建议是至少做三层监控。第一层是硬件级监控。nvidia-smi是基础但要推送到时序数据库建议用dcgmiNVIDIA Data Center GPU Manager能采集更细的指标比如 GPU 温度、功耗、NVLink 带宽利用率、ECC 错误计数。自定义 Prometheus exporter 也可以社区有nvidia_gpu_exporter可以用多卡环境下记得给每张卡打上 index 标签否则指标串了会让你排查问题查到怀疑人生。第二层是推理框架级监控。vLLM 内置了 Prometheus metrics暴露了vllm:num_requests_running、vllm:num_requests_waiting、vllm:gpu_cache_usage_perc这些关键指标。gpu_cache_usage_perc尤为重要超过 0.9 就说明 KV Cache 快满了要么扩容要么调低并发。多卡环境下要分别看每个 rank 的指标因为张量并行的多卡共享同一批请求一张卡缓存满了整组都会遭殃。第三层是业务级监控。延迟、QPS、错误率这些指标必须和 GPU 指标关联起来看。我习惯在 Grafana 里建一个仪表盘左侧放延迟曲线右侧放 GPU 利用率和显存顶部放 KV Cache 使用率三个维度放一起一眼就能定位瓶颈。注意NVIDIA 驱动版本是硬约束。多卡场景对驱动的稳定性要求远高于单卡。我踩过的坑是 CUDA 11.8 的驱动跑新出的 PyTorch 2.3 一直报错升级到 535 系列驱动后问题解决。生产环境选择驱动版本一定要看官方兼容性矩阵不要贪新。5. 什么时候“不用上多 GPU”三个值得重新考虑的替代方案这篇文章的主题是“什么时候该上多 GPU”但我还是要花一整节讲“什么时候不该上”。因为在实际工作中我见过太多其实不需要上多 GPU 的场景最后靠其他方案把成本打下来了一半。5.1 量化四两拨千斤的显存救星模型量化是目前性价比最高的显存优化手段。FP16 转 INT8 直接减半显存转 INT4 可以减到四分之一。7B 模型 FP16 是 14GBINT4 后只需约 4GB一张消费级显卡就能跑起来。70B 模型 FP16 是 140GBINT4 后降到 35GB 左右一张 80G 的 A100 甚至都能勉强放下根本不需要双卡。但量化不是没有代价。量化后模型精度会有一定损失尤其是 INT4 在复杂推理任务上可能出现明显的质量下降。实测经验是7B 模型 INT8 量化后质量损失几乎感知不到INT4 在通用对话场景也能接受但如果做代码生成、数学推理建议还是保留 FP16 或 INT8。多 GPU 部署时也可以考虑混合精度策略——关键层保留高精度非关键层走低精度。5.2 推理优化有时候问题出在框架而不是硬件前面提到 vLLM 的 PagedAttention 和连续批处理continuous batching这两项技术可以说是近年来推理优化最大的突破。PagedAttention 类似操作系统的虚拟内存管理把 KV Cache 切分成固定大小的块按需分配不再要求物理连续大幅减少显存碎片和浪费。连续批处理则是“动态 batching”不需要等整个 batch 全部生成完再处理下一批而是每生成一个 token 就把完成的序列移出、插入新序列让 GPU 时刻保持高利用率。这两项技术叠加在单卡上就能把吞吐提升数倍。所以如果你还在用最原始的model.generate()逐请求处理先别急着加卡换个框架可能就解决了。这也是我在判断“该不该上多 GPU”时最先排除的因素。5.3 弹性推理和无服务器架构把成本摊到每个请求如果业务流量有明显波峰波谷比如白天高并发、晚上低并发那固定扩容多 GPU 其实非常浪费。这种情况下用弹性推理服务比如 KServe Knative或者主流的 Serverless GPU 平台按请求量动态伸缩实例数量可能比固定多卡便宜得多。这类方案的思路是底层并不限制单实例只能用单卡而是通过水平扩容多副本来吸收流量高峰时多起几个实例低谷时缩到零。如果单个模型实例需要多卡也可以结合前面说的张量并行但建议把这个“多卡组”做成弹性单元而不是常驻。运维复杂度会上升但成本优化的空间也很大。不要为了“用多 GPU”而上多 GPU。先问自己量化试过了吗推理框架换了吗弹性伸缩考虑了吗这三个方案都没解决你的问题再来动多 GPU 的念头。这是我从无数次成本复盘里总结出来的原则扛住了不少老板的质疑。5.4 最后分享一个小技巧上线前多花半小时做容量规划这套规划方法虽然不花什么成本但能帮你省下非常多的后续麻烦。上线前先做三件事第一用压测工具比如 Locust、k6或者简单的 AsyncOpenAI 脚本测出单卡实际能支撑的最大并发和 P95 延迟第二根据业务预估峰值流量计算出需要的总并发数第三把这个总并发数除以单卡并发数得出理论卡数再乘 1.3-1.5 的冗余系数这就是你真正需要上几张卡的答案。踩过几次坑之后我现在每接一个新项目都会照这个流程走一遍极少再出现“上线第一天就因为并发预估不足而加急扩容”的尴尬。算力容量这件事最贵的是事后补救最便宜的是事前规划这话放在多 GPU 场景里再合适不过。