企业官网建设流程全解析

先说一个我这几年被问到最多的问题：“我的推理服务单卡快扛不住了，是不是该上多 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 去跑，权重大头一占，剩下的空间可能只够塞几个并发请求的上下文。如果模型升到 70B，FP16 权重直接 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 那套梯度同步机制，直接用多进程 + 请求分发更轻量。

数据并行最大的坑是显存浪费。每张卡都要存一份完整的权重，如果模型 14GB，8 张卡就得 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，第 N+1 到第 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 卡张量并行稳定不少。

三种并行策略的适用场景我整理了一张表，方便对比：

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_eager=True。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_map="auto", # 自动分配到可用 GPU torch_dtype=torch.float16, )

device_map="auto"在加速库（accelerate）的支撑下，会按显存大小自动切分模型，把不同的层分配到不同 GPU 上。这种方法对 7B-13B 模型特别省事，十几行代码就完成多卡部署。但要注意，自动切分不一定最优，切分方案可能产生较多的跨卡数据传输。想精确控制，就手动指定device_map的层到卡映射关系。

3.3 实际部署过程：一个 13B 模型双卡部署的记录

这里记录一个我最近的部署实例，环境是双卡 4090，NVLink 桥接，跑 13B 模型，目标是支撑 50 并发且单请求首 Token 延迟低于 600ms。

第一步，先排查单卡是否真的到瓶颈。单卡 4090 加载 13B FP16 模型需要约 26GB 显存，单卡 24GB 实际放不下，所以“放不下”的情况命中，必须上多卡。这就直接排除了数据并行方案，因为数据并行要求单卡能放下完整模型。于是选择张量并行。

第二步，确定切分方式。双卡 4090 有 NVLink，通信带宽足够，使用 tp_size=2。启动命令如下：

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_url="http://localhost:8000/v1", api_key="EMPTY") async def send_one(prompt): start = time.time() resp = await client.chat.completions.create( model="default", messages=[{"role": "user", "content": prompt}], max_tokens=200, ) 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(f"P50: {sorted(latencies)[25]:.2f}s, P95: {sorted(latencies)[47]:.2f}s") asyncio.run(main())

实测结果：单卡 4090 OOM 无法加载，双卡 tp_size=2 首次部署后，P50 延迟 380ms，P95 680ms，吞吐约 350 tokens/s，满足需求。但中间也踩了好几个坑，下面详细说。

4. 踩坑实录：多 GPU 部署的典型问题排查

多 GPU 环境比单卡复杂得多，问题的表现也更隐蔽。我把实际遇到的典型问题整理成速查表，每个都附上排查思路和解决方案。这部分指标可能比较枯燥，但都是真金白银换来的经验。

4.1 多 GPU 常见问题速查表

先给一张总表，方便遇到问题时快速检索：

4.2 排查实操：三个真实案例

第一个案例是前文说的双卡部署，启动后 A 卡利用率 100%，B 卡只有 5%。排查过程很简单：nvidia-smi看进程，发现模型的参数全被加载到 GPU 0，GPU 1 只参与了极少量的张量并行通信。继续深挖，发现是模型 checkpoint 格式问题——模型本身是单卡训练后保存的，张量并行的切分逻辑没被正确触发。解决方案是改用 vLLM 的llm = LLM(model=..., tensor_parallel_size=2)接口，让 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_utilization=0.9意味着 vLLM 认为 90% 显存可全权使用，但其他进程（比如监控代理、CUDA context）占用了剩余 10% 之外的显存，碰撞导致 OOM。调成 0.85 后问题消失。

4.3 运维与监控：多 GPU 环境的三条防线

多 GPU 服务一旦上线，监控就变成刚需。我的建议是至少做三层监控。

第一层是硬件级监控。nvidia-smi是基础，但要推送到时序数据库，建议用dcgmi（NVIDIA 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 是 14GB，INT4 后只需约 4GB，一张消费级显卡就能跑起来。70B 模型 FP16 是 140GB，INT4 后降到 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 场景里，再合适不过。