需求拆解：从业务话术到端口和带宽
"我们要建个 AI 集群"这句话里没有一个可采购的数字。这节讲怎么问出来。
学完这节你能做到
- 用一份清单把模糊需求问成可计算的参数
- 区分必须独立成网与可以共用的流量类型
- 识别报价单里最容易被漏掉的项
那句话里没有一个可采购的数字
需求方给你的往往是这个：
我们要建一个 AI 训练集群，性能要好，网络别成为瓶颈。
三句话，零个可用参数。这一节讲怎么把它问成能算的东西——因为后面两节的计算器， 输入全都来自这一步。
要问清的六件事
| # | 问什么 | 决定了什么 |
|---|---|---|
| 1 | 规模：多少台服务器、每台什么配置 | 端口总数、交换机台数 |
| 2 | 增长：一年后多少台、三年后多少台 | 预留多少端口与地址 |
| 3 | 流量类型：东西向还是南北向、大包还是小包 | 收敛比、要不要无损 |
| 4 | 可用性：能停多久、单点是否可接受 | 冗余方案、双上行、备件 |
| 5 | 预算：总预算与分期方式 | 选型档次、一次到位还是分期 |
| 6 | 机房条件：机柜、功率、走线距离、已有网络 | 光模块类型、拓扑可行性 |
六件事里第 2 和第 6 最容易被跳过，也最容易让项目返工。
第 1 件：规模要问到端口粒度
"20 台服务器"是不够的。要问到：
每台服务器：
业务网卡 2 × 25G（双上行冗余）
存储网卡 2 × 100G
计算网卡 8 × 400G（GPU 节点）
管理网口 1 × 1G
BMC 带外口 1 × 1G
一台 GPU 节点是 14 个端口，不是 1 个。20 台就是 280 个端口，分属四张不同的网。 这一步算错，后面全错。
把它做成表格让需求方确认，比来回口头沟通高效得多：
| 网络 | 每节点端口数 | 速率 | 节点数 | 端口总数 | 备注 |
|---|---|---|---|---|---|
| 业务网 | 2 | 25G | 20 | 40 | 双上行到不同 leaf |
| 存储网 | 2 | 100G | 20 | 40 | 存储侧要 1:1 |
| 计算网 | 8 | 400G | 20 | 160 | rail-optimized |
| 带内管理 | 1 | 1G | 20 | 20 | |
| 带外（BMC） | 1 | 1G | 20 | 20 | 独立交换机 |
签字确认这张表，再往下算。数字变了就重新签。
第 2 件：增长决定预留
这是最容易埋雷的一项，因为它的代价延迟出现：
| 划小了 | 后果 |
|---|---|
| 端口没预留 | 扩容要加交换机，可能触发拓扑升级（两层变三层） |
| Pod CIDR 划小 | 节点数被写死，用尽后新节点 Pod 起不来（K8s 网络模型） |
| Service CIDR 划小 | 基本改不了，只能重建集群 |
| 地址段不连续 | 后期扩容拿到零散网段，路由与 ACL 全变复杂 |
问法要具体："一年后会到多少台？三年内的上限是多少？" 拿不到答案就按当前规模的 2 到 3 倍做地址与端口预留—— 地址预留是零成本的，端口预留只是选大一档的交换机。
第 3 件：流量类型决定架构
同样 20 台机器，流量形态不同，方案能差一倍价钱：
| 流量特征 | 典型业务 | 收敛比 | 要无损吗 |
|---|---|---|---|
| 南北向为主、小包 | Web、微服务 | 3:1 可接受 | 不需要 |
| 东西向大流量 | 分布式存储、数据加载 | 1:1 | 不需要（TCP 够用） |
| 东西向全员满速 | AI 训练的 AllReduce | 1:1 | 需要（RDMA） |
| 混合 | 通用平台 | 按最苛刻的那类算 | 分网隔离 |
关键问题只有一个：有没有 AllReduce 这类全员同时满速的通信？ 有就必须无损 + 1:1 + rail-optimized（成本高一个档）；没有就用普通以太网。
第 4 件：可用性要问到"能停多久"
抽象的"高可用"没法设计。要问：
单台交换机故障，能接受影响多少台服务器、多长时间？
→ 不能有影响 → 双上行 + 双 leaf + MLAG（端口翻倍）
→ 影响半个机架 → 单上行，接受故障域
整网故障能接受多久？
→ 分钟级 → 需要备件在库、有值班流程
→ 小时级 → 靠厂商服务响应
这几个答案直接决定：leaf 是否成对、要不要 MLAG、备件数量、以及是否需要 带外管理网（业务网挂了还能进得去）。
第 6 件：机房条件是硬约束
设计再漂亮，机房放不下就是废纸：
| 条件 | 影响 |
|---|---|
| 单机柜功率 | GPU 节点单台可能 10 kW 以上，一个机柜放不了几台 |
| 机柜数量与相邻关系 | 决定用 DAC（几米内、便宜）还是 AOC/光模块 |
| 走线距离 | 超过 DAC 长度就必须换光，成本差好几倍 |
| 已有网络 | 能不能开 BGP、有没有空闲 VLAN、地址段谁分配 |
| 上电与制冷 | 影响交付节奏，往往比设备到货更慢 |
同样一条 400G 链路：
| 方式 | 距离 | 相对成本 |
|---|---|---|
| DAC 铜缆 | 1–3 米 | 最低 |
| AOC 有源光缆 | 3–30 米 | 中 |
| 光模块 + 光纤 | 30 米以上 | 最高（两端各一个模块） |
所以"把强东西向通信的节点放进同一个机架"不只是性能优化， 也是省钱——同机架内能用 DAC。
规划时一定要拿到机柜平面图，而不是只有一个服务器数量。
四张网：先分清再算
以太网和计算网各有一节专门算账。这里先把边界划清——它们是四套独立的网络：
| 网络 | 承载 | 关键要求 | 参考 |
|---|---|---|---|
| 业务网 | 客户端访问、Pod 通信 | 按流量形态定收敛比 | 以太网规划 |
| 存储网 | 读写数据与检查点 | 存储侧 1:1，节点侧可轻度收敛 | 同上 |
| 计算网 | GPU 集合通信 | 1:1 + rail-optimized + 无损 | Rail 布线账 |
| 带外管理网 | BMC、交换机管理口、PDU | 物理隔离，业务挂了还能用 | 独立设备 |
新人最常见的两个错误：把存储网和业务网合并（恢复流量会打爆业务）， 以及忘记带外网（真出事时进不去机器）。
常被漏掉的采购项
按被漏掉的频率排序：
- 光模块——每根线两端各一个，总价常与交换机同一量级
- DAC/AOC 线缆——按实际距离核算，别按最短算
- 备件——光模块按 5% 备，交换机至少一台冷备
- 带外管理交换机——它不在"业务网"的清单里
- MLAG peer-link 端口——成对 leaf 之间要占 2 个口
- UFM 节点与它的机位（IB 场景）——SuperPOD 参考架构 里一个 SU 空出一台机位就是给它
- 上架与布线人力——几百根线的工时不是零
交付物：一页能评审的规划表
问清之后，产出应该是一页纸，让所有人在同一组数字上讨论：
【规模】 20 台 GPU 节点（8×H200），一年内到 40 台
【端口】 业务 40 × 25G ／ 存储 40 × 100G ／ 计算 160 × 400G ／ 管理 40 × 1G
【流量】 AllReduce 为主 → 计算网无损 1:1 rail-optimized
【可用性】 单交换机故障不影响业务；备件在库
【机房】 4 个相邻机柜，单柜 12 kW，柜内 DAC、跨柜 AOC
【地址】 Pod CIDR 10.244.0.0/16（每节点 /24，上限 256 节点）
Service CIDR 10.96.0.0/12；LB 池 172.18.15.200-210
【结论】 计算网 8 leaf + 4 spine（QM9700）；业务网 2 leaf + 2 spine
线缆 252 + 256 根；光模块按两端计 + 5% 备件
【风险】 单柜功率上限只够放 5 台，40 台需要 8 个柜位——需机房确认
最后那一行最有价值：把已知的风险显式写出来， 而不是等上架时才发现。
检查点
需求方说「20 台 GPU 服务器」。为什么这个数字不足以开始算网络？
判断计算网要不要做无损 + 1:1 + rail-optimized，关键问题是什么？
下面哪些项最容易在报价单里被漏掉？（多选）
这节课的落点
- 六件事：规模、增长、流量类型、可用性、预算、机房条件；第 2 和第 6 最容易漏
- 规模要问到端口粒度：一台 GPU 节点是十几个端口、四张网
- 增长决定预留；Pod CIDR 与 Service CIDR 是一次性决定，拿不到数字就按 2–3 倍预留
- 流量类型的分水岭：有没有 AllReduce——有就无损 + 1:1 + rail-optimized
- 可用性要问到"能停多久、能影响多少台"，才能决定双上行与备件
- 机房条件是硬约束：距离决定线材，线材是笔真钱；一定要拿机柜平面图
- 四张网分开算，别合并存储与业务网，别忘带外网
- 交付物是一页可评审的规划表，最后一行显式写出已知风险