1. 从单卡到集群先想清楚你卡在哪很多团队聊起大模型部署第一反应就是“上集群”仿佛单机跑不动是必然的多机分布式才是正经方案。但我在实际项目里见过太多反例有的场景单张消费级显卡加量化就能扛住线上流量非要兴师动众搭一套多机推理集群最后活没干多少光运维和排查网络就把人耗干了也有的团队在单机上已经压到极限却连瓶颈在哪都没测明白就匆忙引入分布式推理结果吞吐没提上去延迟反而翻倍。所以聊演进路径之前必须先明确一个很俗但很关键的判断依据你当前到底卡在显存容量卡在算力吞吐还是卡在并发访问量。单机部署最容易踩的坑是“模型能跑起来就以为及格了”。我见过不少同学用一张 24GB 显存的卡加载 7B 模型量化一下、推理几句生成速度感觉还行就放到测试环境给前端联调。结果一旦模拟真实并发显存被多路请求撑爆系统直接 OOM。更隐蔽的是很多模型部署框架默认会把整张卡的一个大块显存预留下来比如你用 vLLM 或 TensorRT-LLM它会提前申请一整块显存池。如果机器本身只有 24GB模型权重加 KV cache 就可能把空间吃满而你的业务并发还没真正打进来。这时候不是“要不要上集群”的问题而是连单机资源利用率都还没摸清。我习惯的做法是任何模型部署前先跑一个单请求压测再跑多并发压测记录显存峰值、单 token 延迟、吞吐量三个指标。单请求压测能看出模型推理本身的耗时包括 prefill 和 decode 两个阶段多并发压测才能看出显存、算力、调度三者的真实短板。很多时候你会发现显存还有富余但吞吐已经上不去那就是算力饱和显存突然爆掉那就是并发管理出了问题。搞清楚这些再决定要不要走向多机集群。1.1 单机部署的隐藏成本不是只有一张显卡的事单机部署听起来简单其实就是把模型权重加载到显存然后跑一个推理服务。但实际落地时隐藏成本会跳出来咬你。首先是 CPU 内存与显存之间的加载瓶颈。一个 13B 模型用 FP16 存储光权重就有 26GB如果从机械硬盘加载启动过程可能超过 10 分钟就算用固态也远远慢于容器重启时间。你需要考虑要不要做模型热加载或者至少提前把权重缓存到系统内存里。其次是推理引擎的选型。PyTorch 原生推理在单机单卡上往往只发挥了 30% 左右的 GPU 算力如果用 vLLM 或者 TensorRT-LLM通过 PagedAttention、算子融合、连续批处理这些优化同一个模型的单卡吞吐能提升几倍甚至一个数量级。我遇到过一个很典型的案例某个内容平台要在内部上线一个文档问答助手最初基于 Transformers 库直接写推理接口单张 A10 显卡上并发进来 8 个请求就开始超时。后来换成 vLLM同一张卡扛到 40 并发单 token 延迟只多了 20%但吞吐提升了 5 倍。这个改动只花了半天根本不涉及集群。所以单机部署的重点不是“能不能跑”而是“用多低的成本让它高效跑”。连续批处理这个机制尤其关键它会在推理过程中动态收集等待中的请求把不同生成进度的序列拼到一个或多个 step 里计算GPU 就不会在等待某个长尾请求时闲着。如果你连这个优化都没开启就急着上集群大概率会带着一个很低效的底座把问题放大到整个集群。1.2 用数据和公式判断“下一步应该去哪”我建议自己做一个非常简单的容灾预估。打开任务管理器或者nvidia-smi先看当前单卡并发满载时达到的吞吐量 T_0再算一下未来业务峰值需要的目标吞吐 T_target。如果 T_target 只是 T_0 的两三倍优先考虑优化单卡、换更强的卡或者加一卡做数据并行如果 T_target 超出十倍的量级才轮到认真设计集群方案。算力不是线性的多机分布式推理因为通信开销、调度损耗效率通常很难做到 90% 以上你加两台机器往往得不到两倍吞吐能拿到 1.6 倍就已经不错了。集群和单机的另一个分界线是模型大小与显存的关系。如果你手里的模型权重加上推理状态已经超越单张顶级卡而你又不想牺牲太多量化精度那就必须考虑多卡切分。这里有个很实用的经验公式推荐显存大小大概是模型参数量乘以 2再乘以一个安全系数 1.2 到 1.4预留 KV cache 和中间激活值的空间。以 70B 模型为例FP16 权重就是 140GB加上推理过程中的动态内存单卡基本无解只能走向多卡或多机。把这些数据都摆到桌面上以后再谈演进路径就不会被“别人都在搞集群”这种话带着走。你心里要有一本账单机是低成本试错的好起点但也是暴露一切资源瓶颈的最好放大镜。跳过单机直接做集群等于跳过了理解业务的阶段。2. 单机多卡部署的核心是把并行策略选对当单卡确实扛不住的时候第一步不是上多机而是在一台机器里插多张卡。单机多卡技术成熟度高通信走 NVLink 或 PCIe比跨机走以太网要可靠得多延迟也低一个数量级。很多团队在单机多卡阶段就能解决大部分问题不一定需要走到“集群”这个级别。但多卡并行不是简单把模型塞进去里面有四种常见的并行策略数据并行、张量并行、流水线并行以及它们之间的组合。每一种的适用范围和代价都不同选错策略会直接导致显卡利用率低。数据并行是最容易理解的方式每张卡放一份完整的模型副本把进来的请求切分成多批分发给不同卡同时处理。它的优点是实现简单扩容也直观缺点是显存浪费严重而且如果模型本身已经大到单卡放不下数据并行就没法用。数据并行更偏“并发扩展”适合场景是模型不大但请求量大的情况。在多机场景里它往往作为最基本的扩展维度存在配合负载均衡器按卡分发。在实际部署中我见过不少人一上来就开数据并行把请求均匀分发到 4 张卡上但没有考虑批次大小对每张卡的压力。结果显存占用太高每张卡的 batch 只能开得很小反而因为频繁的 kernel 启动开销导致整体吞吐不如单卡加连续批处理。所以数据并行也不是“无脑加卡就提速”你得用小批量压测来找到单卡最优 batch再乘以卡数才是合理预期。2.1 张量并行把一个大矩阵拆成几块张量并行也叫层内并行核心是把一个 Transformer 层中的权重矩阵切分成多块分给不同的 GPU让它们在计算前向时协同完成同一个矩阵乘法。以多头注意力为例可以把 Q、K、V 的线性层按列切分到两张卡上每张卡只计算一半的维度算完再做拼接MLP 部分则按行切分再用 AllReduce 把部分结果合并。这个切分直接决定了每张卡需要的显存变小但通信量也变大了。因为每一层的前向计算都要在卡之间同步中间结果所以张量并行的通信极其频繁。在单机内走 NVLink 还勉强能接受如果跨机走普通万兆以太网通信开销会直接把计算收益吃掉。这也是为什么很多人调张量并行在单机 4 卡上发现提升明显一扩到两台机器 8 卡反而性能倒退。我自己的经验是张量并行尽量只在单机内使用不要轻易跨机如果非要跨机必须保证机间网络有 RDMA 或高速 InfiniBand否则就选流水线并行来减少通信频率。在引擎层面vLLM 和 TensorRT-LLM 都支持张量并行启动时通过tensor_parallel_size参数控制切分数量。但这里有个坑张量并行维度不一定要等于卡数比如你有 8 卡可以先用 2 卡张量并行把显存问题解决再用 4 组 2 卡做数据并行而不是 8 卡全部张量并行。这样既控制了通信开销又保留了扩展空间。一种常见的组合是“张量并行 × 数据并行”但我建议先跑一个小测试矩阵对比 2 度张量并行加 4 度数据并行与 8 度张量并行之间的吞吐差异。实测中前者往往在中等规模下更稳。2.2 流水线并行减少通信但小心气泡如果说张量并行解决的是“单层放不下”流水线并行解决的则是“整层数太多”。它的思路是把模型的层分成多个阶段每个 GPU 负责其中一段连续层数据按顺序流过各个阶段。这样一来各卡之间只需要在层与层的边界传递中间激活值通信频率远低于张量并行。但也出现了一个新问题流水线气泡。简单说当一个 batch 在第一阶段计算时后面几个阶段的 GPU 只能等着利用率就会下降。工程上常用 micro-batching 来填平气泡把一个大 batch 切得更细让前一个 micro-batch 在前一阶段算完时后一个 micro-batch 紧跟着进入形成流水线。流水线越深micro-batch 数量越多气泡占比就越小。我实际调的时候micro-batch 数量和阶段数的关系可以参考当 micro-batch 数量等于阶段数时气泡率达到理论上的最低点附近继续增加 micro-batch 虽然还能再压一点但会增大调度的复杂度和显存压力。所以很多框架默认把 batch 切成多个小份逐级流动。流水线并行还有一个容易踩的坑是负载不均衡。不同层的计算量其实不一样尤其是 embedding、注意力层、 FFN前向耗时差别很大。如果你只是机械地按“每卡 N 层”切分很可能某张卡成为瓶颈其他卡空闲等待。比较好的做法是先对模型做 profiling统计每一层的前向耗时再按总耗时均匀分配层段。这一步我一般在离线环境做用真实业务数据集跑一个 epoch看各层时间占比最后把耗时接近的层归到一个 stage。2.3 单机多卡部署的具体操作流程假设你有一台 8 卡的训练/推理服务器想部署一个 70B 模型。第一步用nvidia-smi确认卡间拓扑是 NVLink 全互联还是 PCIe 交换机。查询拓扑可以用nvidia-smi topo -m重点看每对 GPU 之间的连接类型。如果 P2P 链路是 NVLink可以做张量并行如果全是 PCIe张量并行通信会比较吃亏优先考虑流水线并行加数据并行。第二步选择一个推理框架并进行环境初始化。以 vLLM 为例安装完成以后启动服务的方式是这样python -m vllm.entrypoints.openai.api_server \ --model /data/models/llama-70b \ --tensor-parallel-size 4 \ --pipeline-parallel-size 2 \ --max-model-len 4096 \ --gpu-memory-utilization 0.92tensor-parallel-size 4表示 4 卡做张量并行pipeline-parallel-size 2表示另外 2 个 stage 做流水线并行合起来 8 卡。如果你的框架还不支持流水线并行也可以先用tensor-parallel-size 8全张量并行然后观察通信是否成为瓶颈。启动后用nvidia-smi看每张卡的显存占用正常应该很接近如果某张卡明显偏低说明权重切分不均或者某个 stage 没有加载全部层。第三步压测。不要一上来就测极端并发先固定 batch size 跑几个请求确认功能无误再用脚本逐步增加并发数。我自己写压测会用 Python 的asyncio和aiohttp模拟真实请求流。下面这段脚本可以快速测出吞吐和平均延迟import asyncio, aiohttp, time, statistics async def send_one(session, url, prompt): payload {model: deploy-test, prompt: prompt, max_tokens: 128} start time.perf_counter() async with session.post(url, jsonpayload) as resp: await resp.text() return time.perf_counter() - start async def main(): url http://localhost:8000/v1/completions concurrency 32 prompts [你好请介绍一下你自己] * concurrency async with aiohttp.ClientSession() as session: tasks [send_one(session, url, p) for p in prompts] latencies await asyncio.gather(*tasks) print(avg latency:, statistics.mean(latencies), qps:, concurrency / sum(latencies)) asyncio.run(main())这一步能清楚看到平均延迟和吞吐量。多卡并行如果调得好吞吐应该比单卡有明显提升如果提升低于 1.5 倍说明通信开销已经压过计算收益需要回头调整并行策略。3. 从多机集群部署要跨过的三道坎走到多机这一步意味着单机的显存和算力已经彻底不够用了或者你需要横向扩容来应对不可预测的并发峰值。但多机集群不是把单机部署复制到几台机器它牵扯到更复杂的网络拓扑、分布式调度和容错机制。我在实际项目里看到很多团队从单机跳到集群最不适应的不是模型本身而是“一个请求到底怎么被分发、怎么聚合结果”这件事。它不像单机多卡那样靠 NVLink 就能无缝协作跨机通信需要显式的框架来管理。第一道坎是网络。多机推理的服务质量几乎被网络延迟和带宽锁死。模型推理本身是计算密集型的但分布式推理需要在节点间传递中间激活值、梯度或 KV cache。机器越多通信模式越复杂。我做过一个实验两台机器之间用普通千兆交换机跑张量并行结果吞吐比单机 2 卡还低 30%换成 25G 网口之后吞吐才反超单机。原因就在于每层 Transformer 的前向都要做 AllReduce千兆网络把 GPU 卡在等待上。所以集群部署前先确认机器间是万兆起步最好有 RDMA并且用ib_write_bw或iperf3测一下实际带宽别信网卡标称值。第二道坎是框架选型。不同框架对多机支持差别很大。比如 vLLM 虽然已经支持多机推理但早期版本更多是为单机高吞吐设计多机张量并行的通信实现不一定能充分利用高速网络TensorRT-LLM 在多机支持上也有自己的限制需要仔细看文档。还有专门做分布式推理的框架比如针对超大规模模型的跨节点推理方案它们会对数据并行、张量并行、流水线并行做自动组合。我的建议是如果团队没有太多分布式开发经验优先选择生态成熟、社区活跃的方案哪怕多花一点机器成本如果团队有底层通信能力再根据模型结构自己做定制切分。第三道坎是配置一致性。多机集群的每台机器上驱动、CUDA 版本、推理框架版本必须完全一致。这个听起来简单实际上是最容易出问题的地方。我曾经排查过一个诡异的线上问题12 台机器里有 1 台 A100 偶尔出现illegal memory access最后发现是这台机器上的一个小版本驱动与其他机器不同导致 CUDA context 初始化异常。后来我们把所有机器的驱动和容器镜像锁成同一版本问题就消失了。3.1 多机部署的网络拓扑与通信策略多机集群通常会有一个主节点负责接收请求、分发任务工作节点负责推理。主节点也可以同时承担推理任务。如果模型切分到多个节点上每个请求都需要把 prompt 广播到所有相关节点然后每层前向都要做跨机同步最后再汇总生成结果。因此机器数量不是越多越好而是要找到一个最优并行度组合。以两张 A100 的机器为例假设你有 4 台总共 8 卡。如果要部署一个 70B 模型你可以把tensor_parallel_size设置为 4只在这 4 卡之间做张量并行并且尽量选在同一台机器里的卡避免跨机然后data_parallel_size设置为 2即在两台机器之间做数据并行每个数据并行副本内部使用 4 卡张量并行。这样跨机的通信只发生在请求分发和结果汇总阶段频率低网络压力小。很多框架里还会有一个 prefill 和 decode 解耦的选项。对于长 prompt 场景prefill 阶段的计算量很大但中间结果不需要频繁跨机通信而 decode 阶段每个 step 都要同步对网络延迟更敏感。如果集群里不同机器的网络性能有差异可以尝试把 prefill 和 decode 调度到不同节点上。但这套玩法比较复杂需要自己对框架内核做改造普通团队不建议硬上。3.2 配置文件的真实案例一个 8 卡集群的 yaml 片段为了让思路落地我分享一个模拟项目里的配置片段。这个项目是一个内部的代码生成助手模型是 13B 量级但并发峰值很高所以选了 3 台机器每台 2 张 A100。推理框架用 vLLM 的集群模式通过 Ray 作为底层调度器。启动前先在每台机器上写好相同的模型路径然后启动 Ray head 节点再启动 worker 节点。vLLM 的分布式启动命令大概是# 主节点 ray start --head --port6379 --num-gpus2 # 工作节点 ray start --address主节点IP:6379 --num-gpus2然后运行python -m vllm.entrypoints.openai.api_server \ --model /data/models/codegen-13b \ --tensor-parallel-size 2 \ --data-parallel-size 3 \ --max-model-len 8192 \ --gpu-memory-utilization 0.90这里的tensor-parallel-size 2表示每个数据并行副本内部有 2 张卡张量并行>