在 15.1–17.4 节中，我们已经拆解了 GPU 的硬件架构、CUDA 软件栈以及 FlashAttention 等加速原理。当你准备把这些技术落地为一整 rack（机柜）甚至一整间机房时，第一个必须回答的战略问题是：这台算力中心到底是用来“炼丹”的，还是用来“迎客”的？
训练与推理对硬件、网络、存储、调度的需求几乎截然相反。把训练集群当推理用，会造成 80% 的带宽与互联能力闲置；把推理集群当训练用，则会让 All-Reduce 通信直接把 PCIe 总线堵死，模型永远练不出来。本节把三种定位的差异摊开来讲，帮你避开“一机两用”的美好幻想。
一、训练集群：为“算力密度与通信效率”而生
训练集群的核心使命只有一个——在最短时间内，让千亿级参数完成一次收敛。这决定了它从地板到天花板的每一处设计都指向“极限性能”和“零中断”。
硬件画像：
- GPU 选型：几乎锁定数据中心级旗舰卡，如 NVIDIA H100/H800、A100/A800，或国产等效算力卡。消费级显卡（如 RTX 4090）因缺乏 NVLink 和 RDMA 支持，仅能在极小规模的科研场景中凑数，无法进入生产级训练集群。
- 显存需求极端：训练时单卡不仅要存模型参数，还要存优化器状态（AdamW 需要 2 倍参数量的显存）、梯度、激活值。以 FP16 混合精度训练 70B 模型为例，3D 并行（数据+张量+流水线）下对显存的贪婪程度，直接决定了你必须选择 80GB 显存版本而非 40GB 版本。
- 网络是命脉：训练过程中，梯度同步（All-Reduce）和激活值交换（张量并行时）会产生巨大的东西向流量。InfiniBand NDR（400Gbps）或至少 HDR（200Gbps）是标配，NVLink/NVSwitch 负责卡间高速互联。网络成本通常占训练集群总投入的 20%–35%，这笔钱省不得。
- 存储要扛得住突发写：训练每隔几十分钟就要写一次 Checkpoint（几百 GB 到数 TB），并行文件系统（Lustre、GPFS、JuiceFS）配合全闪存或 NVMe-oF 是底线配置。慢一步，就意味着 GPU 空等。
使用模式：
- 独占式、长周期：一次训练任务数天到数月，任务启动后希望 100% 独占节点，拒绝被抢占。
- 对延迟不敏感，对带宽极度敏感：单次迭代内部的通信延迟容忍度相对较高，但通信带宽不足会直接拉低 MFU（模型算力利用率），让昂贵的 GPU 大把时间花在等网络上。
二、推理集群：为“成本效率与并发弹性”而生
推理集群面对的是真实的用户流量，核心 KPI 不是“多久练完模型”，而是“每生成百万 Token 花多少电费”以及“用户问完多久能收到第一个字”。
硬件画像：
- GPU 选型多样化：不必须 H100。L40S、A10、L4 甚至 RTX 4090（在合规前提下）都是推理性价比极高的选择。只有当单模型实例过大（如 70B+ 模型需要多卡张量并行）时，才需要 A100/H100 这种旗舰卡。
- 显存优化优先于算力：推理阶段没有优化器状态和梯度，显存主要用于存放模型权重和 KV-Cache。INT8/INT4 量化、AWQ/GPTQ 压缩、PagedAttention（vLLM）等技术，本质都是在“显存容量”上做文章，争取在更便宜的卡上塞进更大的模型。
- 网络可以“降配”：推理的东西向流量（卡间通信）仅在多卡并行推理时才显著。大多数情况下，25G/100G 以太网或 RoCEv2 即可满足；南北向流量（用户请求/响应）可通过常规的负载均衡承接。
- 存储极简：启动时一次性加载模型权重到显存，运行时几乎不碰存储。对象存储（S3/OSS）或本地 SSD 足够，完全不需要训练集群那种昂贵的并行文件系统。
使用模式：
- 7×24 在线，潮汐波动：白天流量高、夜间流量低，需要自动扩缩容（Auto-scaling）。
- 对延迟极度敏感：首 Token 延迟（TTFT）和每 Token 生成时间（TPOT）直接决定用户体验。推理集群的优化重心是调度框架（vLLM、TensorRT-LLM、TGI）和批次策略（Continuous Batching），而非 raw 算力。
成本结构差异：
训练集群是 CAPEX（资本性支出）游戏，买卡的钱占大头；推理集群是 OPEX（运营性支出）游戏，电费、带宽费和运维人力会随着用户量线性攀升。选型时，训练集群看“每美元能买多少 TFLOPS”，推理集群看“每瓦特能吞吐多少 Token”。
三、混合集群：理想丰满，现实骨感
很多中小型团队或企业研究院会问：能不能白天做推理、夜间做训练，或者把训练节点空闲时腾给推理用？
技术上可行，但工程上极易踩坑。混合部署通常有两条路径：
路径 A：逻辑混合（同一套节点既跑训练又跑推理）
- 致命问题：训练任务一旦启动，会吃满 GPU 计算单元和显存带宽，并产生密集的 RDMA 通信；此时若同一节点上还跑着推理服务，推理延迟会剧烈抖动，甚至触发超时。
- 调度噩梦：训练常用 Slurm（面向 HPC 的批处理调度），推理常用 Kubernetes（面向微服务的弹性调度），两者的资源粒度（整卡 vs 碎片显存）、任务优先级、网络隔离策略完全不同。强行融合，往往导致两边都调不好。
- 结论：除非你的模型很小（< 13B）且只是做 LoRA 微调，否则不建议逻辑混合。
路径 B：物理分区混合（同一机房，不同网络/不同机柜）
- 可行方案：机房内划出 训练区（高功率机柜 + IB 网络 + 并行存储）和 推理区（标准机柜 + 以太网/RoCE + 对象存储），通过上层统一门户做任务分发，但底层资源严格物理隔离。
- 适用场景：预算有限、场地有限，但业务同时涉及自研基座和行业落地。物理分区能在供电、散热、布线层面复用机房，同时避免网络争抢。
四、选型决策速查表
| 评估维度 | 训练集群 | 推理集群 | 混合集群（物理分区） |
|---------|---------|---------|-------------------|
| 核心目标 | 最快收敛、最高 MFU | 最低 TTPT、最高并发 | 资源复用、成本平衡 |
| GPU 选型 | H100/H800/A100 | L40S/A10/L4/H100 | 分区选型 |
| 卡间互联 | NVLink + IB NDR/HDR | PCIe Switch / 可选 NVLink | 训练区 IB，推理区 RoCE |
| 单柜功率 | 40kW–80kW+ | 15kW–30kW | 分区设计，混合供电 |
| 网络成本占比 | 20%–35% | 5%–10% | 15%–25% |
| 存储系统 | Lustre/GPFS/JuiceFS | 对象存储 / 本地 SSD | 分层存储，训练区并行文件系统 |
| 调度系统 | Slurm / 自研调度 | Kubernetes + KubeRay | 统一 Portal，底层双调度 |
| 弹性扩缩容 | 低（独占整卡，数月不动） | 高（按 QPS 自动扩缩） | 推理区高弹性，训练区固定 |
| 主要成本 | 硬件采购（CAPEX） | 电费与运维（OPEX） | 两者兼顾 |
五、给不同角色的落地建议
大模型创业公司 / 云服务商：
坚决物理分离。训练集群买 H100 + IB，推理集群买 L40S 或采用云/租的方式。混合调度的研发人力成本和故障损失，远高于省下的那点硬件折旧费。
传统行业企业（金融、制造、医疗）：
通常不需要自研千亿基座，以行业微调和内部应用为主。建议采用轻量混合方案：用 A100/L40S 做 LoRA/QLoRA 微调，同时部署 vLLM 做内部推理。网络不需要 IB，100G RoCE 足够，调度用 Kubernetes + GPU Operator 即可。
高校与科研院所：
经费以科研训练为主，推理仅是内部展示。建议训练优先，推理直接复用训练集群的非满负荷节点，无需为推理单独建设高规格网络。但要在 Slurm 中设置低优先级队列，避免推理任务干扰关键训练作业。
六、小结
训练集群是赛道，追求极限推背感和零故障完赛；推理集群是公交系统，追求载客量和准点率；混合集群则是试图把超跑改成网约车，改装费往往比再买一辆还贵。
在 18.3 节中，我们将进一步把“定位”翻译成“规模”——几十卡、百卡、千卡级集群，在训练与推理两种定位下，硬件拓扑、供电散热和成本结构会发生怎样的质变，以及你该如何根据实际业务量级做渐进式扩容规划。