一、分布式推理概述：为什么需要分布式推理、分布式推理的挑战、推理与训练的区别
大家好，我是这门课的主讲人。今天咱们聊聊分布式推理的入门话题。
说实话，我刚开始接触大模型时，也觉得单机跑推理挺香的。一台A100，装个模型，调个API，完事。但后来项目越做越大，模型参数从几十亿涨到几百亿，甚至上千亿，单机根本扛不住。嗯，这时候分布式推理就成了绕不开的坎。
1.1 为什么需要分布式推理
先问个问题：你见过千亿参数模型在单张GPU上跑推理吗？我见过，结果是OOM（内存溢出）。
说白了，原因就三个字：装不下。
- 显存瓶颈：一个175B的GPT-3模型，光参数就要350GB（FP16）。单张A100才80GB，差得远呢。
- 算力瓶颈：单卡算力再强，也扛不住高并发。你想想看，一个在线服务每秒要处理上千次请求，单卡根本忙不过来。
- 延迟要求：很多场景要求毫秒级响应。单机串行处理，延迟会随着请求量线性增长，这谁受得了？
核心结论：分布式推理不是锦上添花，而是刚需。当模型参数超过单卡显存，或者QPS超过单卡处理能力时，分布式就是唯一出路。
我在项目中遇到过最典型的场景：一个金融风控系统，需要实时调用千亿参数模型做信用评估。单机推理延迟超过5秒，根本没法用。后来改成分布式推理，延迟降到200毫秒以内。嗯，这就是差距。
1.2 分布式推理的挑战
分布式推理听起来很美好，但落地时坑不少。我踩过的坑，今天先给你提个醒。
1.2.1 通信开销
分布式推理的本质是「分而治之」。模型切到多张卡上，每张卡算一部分，最后汇总结果。但问题来了：卡之间要频繁通信。
我曾经做过一个实验：把模型切成8份，放在8张卡上。结果发现，通信时间占了总推理时间的40%。你想想看，这效率多低。
避坑指南：我曾经在项目里盲目追求「切得更细」，结果通信开销反而拖垮了性能。后来我学乖了——切分粒度要和通信带宽匹配。带宽够大，可以切细点；带宽有限，就少切几块。
1.2.2 负载均衡
分布式系统最怕「木桶效应」——某张卡算得快，另一张卡算得慢，整体性能被最慢的那张卡拖死。
为什么会这样？因为模型各层的计算量不一样。比如Attention层和FFN层，计算密度差异很大。如果切分不均匀，就会出现「忙的忙死，闲的闲死」。
1.2.3 容错与一致性
分布式环境下，节点故障是常态。一张卡挂了，整个推理服务就崩了？那可不行。
我建议你在设计系统时，一定要考虑冗余部署和故障转移。说白了，就是多备几份，坏了自动切换。
1.3 推理与训练的区别
很多人觉得推理和训练差不多，无非是前向传播嘛。其实差别大了去了。我整理了一张表，你看一眼就明白了。
| 对比维度 | 训练 | 推理 |
|---|---|---|
| 目标 | 更新参数，降低loss | 快速生成结果 |
| 计算模式 | 前向+反向，计算量大 | 只有前向，计算量小 |
| 精度要求 | FP32/FP16混合精度 | INT8/FP16量化，精度可牺牲 |
| 延迟敏感 | 不敏感，批处理为主 | 非常敏感，要求毫秒级 |
| 显存需求 | 参数+梯度+优化器状态 | 只有参数+中间激活 |
| 分布式策略 | 数据并行+模型并行+流水线并行 | 模型并行+张量并行为主 |
你看，训练时我们关心的是「能不能收敛」，推理时关心的是「能不能快」。这是本质区别。
举个例子：训练时可以用大batch size，因为梯度更新不着急。但推理时，你等不起。用户点一下按钮，你让他等10秒？那产品就凉了。
1.4 分布式推理的核心架构
说了这么多，咱们用一张图来总结分布式推理的整体架构。这是我个人习惯——先看全局，再抠细节。
这张图展示了分布式推理的基本流程：用户请求进来，先经过负载均衡层，然后分发到不同的推理节点。每个节点内部可能有多张GPU，通过张量并行或流水线并行协同工作。最后结果聚合，返回给用户。
注意：负载均衡层不是简单的「轮询」。我曾经踩过坑——用轮询策略，结果某个节点因为显存不足频繁OOM。后来改成基于资源使用率的动态调度，才稳定下来。
1.5 小结
今天咱们聊了分布式推理的「为什么」和「是什么」。
- 为什么需要：模型太大、并发太高、延迟太严，单机搞不定。
- 挑战在哪：通信开销、负载均衡、容错一致性，每个都是硬骨头。
- 和训练的区别：训练求收敛，推理求快。策略、精度、延迟要求完全不同。
我个人觉得，分布式推理最核心的思维是「权衡」。你要在切分粒度、通信开销、计算效率之间找到平衡点。没有银弹，只有因地制宜。
下一章咱们会深入讲具体的分布式推理策略——张量并行、流水线并行、数据并行，到底怎么选、怎么配。到时候我会拿实际项目中的配置案例来拆解。
公众号:蓝海资料掘金营，微信deep3321