光交换（OCS）
电控光路重构实现可变拓扑，及其在 Google TPU 集群中的大规模混合部署
核心要点：
- OCS = Optical Circuit Switching，电控改变光路连接关系重构逻辑拓扑
- 3D MEMS 是当前唯一量产大端口技术，重配 10-25 ms，端口 100-320
- 光路直通无 O-E-O，每 bit 能耗低约 10×
- Google TPU v4 是最大规模 AI 部署 （48 OCS, 4096 chips, Job 调度时重配）
- Google Jupiter 用 OCS 支持网络跨代渐进升级
- RotorNet / Opera / SIRIUS 是激进学术方案，未生产
- 限制：重配延迟 / 无统计复用 / 端口密度低
为什么需要可重构拓扑？
不同工作负载需要不同拓扑特征，固定布线只能选一种权衡：
| 工作负载 | 理想拓扑特征 |
|---|---|
| TP AllReduce | 节点内高带宽全互联 |
| DP AllReduce | 跨节点高割集 |
| EP AllToAll | 全局均匀带宽 |
| PP P2P | 特定节点对之间高带宽 |
@tbl-topo-ocs-workload 工作负载与理想拓扑
OCS 核心思路：保持物理光纤布线不变，通过改变光路连接关系来重构逻辑拓扑，让带宽跟随需求流动。
光路交换 vs 包交换有什么本质差异？
光路是端到端直通电路，包交换是逐跳查表转发：
| 特性 | 包交换 | 光路交换 (OCS) |
|---|---|---|
| 数据单元 | 报文 (packet) | 光路电路 (circuit) |
| 转发方式 | 每跳 O-E-O （光→电→光），查表 | 端到端光路直通，无电转换 |
| 缓冲 | 每跳排队 | 无缓冲，电路建立后零排队 |
| 带宽分配 | 统计复用 | 独占波长 （电路独占整路） |
| 切换速度 | 逐包 （纳秒级） | 逐电路 （微秒-毫秒级） |
@tbl-topo-ocs-vs-pkt OCS vs 包交换
O-E-O 转换：传统交换机每端口都有 SerDes，将光转电查转发表再转回光发出。这个过程耗功耗 （每端口数瓦） + 引入延迟 （~100-300 ns/跳）。
OCS 优势：光路建立后数据以光速通过不经任何电子器件 — 无 SerDes 功耗、无转发延迟、无排队。每 bit 能耗低约 10×。
OCS 代价：切换光路需时间 （重配延迟），切换期间路径不可用。光路独占 — 无统计复用，没有数据传输时带宽也不能被其他流量借用。
物理技术：3D MEMS 和其他
核心问题：3D MEMS 的工作原理是什么？有哪些替代光交换技术、各自的端口数、重配时间和商用现状？
3D MEMS 是当前唯一量产大端口 OCS：
OCS 内部有两个二维微镜阵列 (input + output)，每面微镜 (~1mm) 可两轴偏转改变光束方向。输入光纤光束经 input 镜反射到 output 镜再聚焦到输出光纤 — 改变镜面角度即改变端口连接。所有镜面可同时偏转，一次重配改变所有端口。
参数：重配 10-25 ms （镜面机械运动 + 稳定，物理限制），端口 100-320。量产厂商：Calient （被 Lumentum 收购）、Polatis （被 Huber+Suhner 收购）。Google TPU v4 用 Palomar OCS （W 型光路：两组 MEMS + Dichroic Mirror 分离监控光和数据光）[1][2][3]。
其他 OCS 技术：
| 技术 | 重配时间 | 端口规模 | 成熟度 | 原理 |
|---|---|---|---|---|
| 3D MEMS | ~10-25 ms | 100-320 | 量产 | 微镜机械偏转 |
| 压电驱动 | ~10 μs | 数十 | 实验室 | 压电形变改光路 |
| 硅光集成 | <10 μs | 数十 | 研究 | Mach-Zehnder 干涉仪阵列 |
| 液晶 (LCOS) | ~ms | 数百 | 电信级 | 液晶相位调制 |
@tbl-topo-ocs-tech OCS 技术对比
趋势：硅光集成 OCS 有望把重配压到微秒级，同时降本 （与电子芯片同工艺）。但端口规模和插损 （光信号损耗） 仍是挑战。
Google TPU v4 OCS 怎么用？
48 台 Palomar OCS 连接 64 个 4×4×4 cube (4096 chips)，Job 调度时重配 Torus 形状[4]。
物理架构：
- 基本构建块：4×4×4 3D Torus cube，64 个 TPU 通过 ICI 直连
- Cube 外露面：每 cube 6 个面各有 16 个 ICI 端口，连接相邻 cube 对应面
- OCS 层：48 台 Palomar OCS （3D MEMS，每台 136 端口：128 数据 + 8 备用）
- SuperPod: 64 cube = 4,096 TPU
OCS 作用：决定哪个 cube 的哪个面连接到哪个 cube 的哪个面。改变 OCS 配置可组合成不同形状 Torus (@tbl-topo-ocs-tpu):
| OCS 配置 | 逻辑拓扑 | 适用场景 |
|---|---|---|
| 配置 A | 4×4×256 Torus | PP （长维度适合流水线） |
| 配置 B | 8×8×64 Torus | DP （较均匀三维） |
| 配置 C | 4×16×64 Torus | 混合策略 |
| 配置 D | 两个独立 2,048-chip Torus | 多租户 |
@tbl-topo-ocs-tpu TPU v4 OCS 配置示例
关键工程约束：
- 重配时机：Job 调度时 （分钟级），不是通信过程中。训练期间拓扑保持静态
- 重配开销：MEMS 10 ms + 链路重训练数秒。远大于 AllReduce 间隔 (~ms)，不能用于实时流量工程
- 故障处理：cube 故障时 OCS 重配旁路，剩余 cube 重组为较小 Torus，不影响其他逻辑集群
OCS vs 固定布线的价值：不用 OCS 时改 Torus 形状必须重新人工插拔光缆 （小时级）。OCS 用毫秒级电控重配替代人工，使拓扑成为软件可配置资源。
RotorNet：无控制平面的确定性轮转
核心问题：RotorNet 如何用确定性轮转替代 OCS 控制回路、省掉了什么复杂度？
让 OCS 按固定时间表轮转所有可能的端口配对[5]。
核心问题：传统 OCS 需要"感知流量 → 计算最优 → 下发重配"控制回路。回路本身引入延迟和复杂度，流量估计不准时配置不理想。
RotorNet 方案：完全放弃流量感知。$N$ 端口 OCS 所有完美匹配有 $N-1$ 种，按固定周期 $\Delta t$ 依次切换：
0~Δt: 匹配 1 — ToR₀↔ToR₁, ToR₂↔ToR₃, ...
Δt~2Δt: 匹配 2 — ToR₀↔ToR₂, ToR₁↔ToR₃, ...
2Δt~3Δt: 匹配 3 — ToR₀↔ToR₃, ToR₁↔ToR₂, ...
...
(N-2)Δt~(N-1)Δt: 匹配 N-1 (完整轮转)
天然公平：一个完整轮转内每对 ToR 恰好被配对一次，获得等量带宽。不需要任何流量感知或控制平面决策 — 公平性由数学结构保证。
$\Delta t$ 权衡:
- 太小 （接近重配时间）：大部分时间在切换，有效带宽低
- 太大：每对 ToR 等待轮到自己的时间长，延迟高
- 典型值：数百微秒到毫秒
代价：无法按需分配带宽。ToR₀ 和 ToR₁ 有大量流量而其他对没有时，RotorNet 仍平均分配 — 大量带宽浪费在空闲对上。这是"无控制平面"的本质代价。
Opera: Rotor + 电子混合
核心问题：Opera 如何混合 Rotor（大流量）和电子交换（小流量）两种路径、解决了什么问题？
双层：大流量走 Rotor，小流量走 Electrical[6]:
- Rotor 层 (OCS)：多台 Rotor 处理大流量 (bulk transfer)。大流量可等待轮到自己的 matching 时段全速传输
- Electrical 层 （传统包交换）：少量低 radix 包交换机处理延迟敏感的小流量。小流量不能等 Rotor 轮转，需立即转发
流量分流：发送端按流量大小决定走哪层 — 大于阈值排队等 Rotor，小于阈值立即走 Electrical。
效果：用少量包交换机 （低成本） 处理延迟敏感流量，大量 Rotor （低成本高带宽） 处理吞吐敏感流量。整体成本远低于全包交换网络，兼顾吞吐和尾延迟。
SIRIUS: ToR-to-ToR OCS 替代 Clos 中间层
核心问题：SIRIUS 如何用 OCS 直连 ToR 省去 Agg 和 Spine 交换机、代价是什么？
OCS 直接连接 ToR，省去 Agg 和 Spine 两层电子交换机[7]:
传统 Clos: ToR ── Agg 交换机 ── Spine 交换机 ── Agg 交换机 ── ToR
SIRIUS: ToR ── OCS ── ToR (光路直通)
关键成果：
- 网络成本仅为等价非阻塞电子 Clos 的 ~28%
- 功耗降低 74-77%
- 割集带宽接近全割集
控制平面：通过流量矩阵估计 + 整数线性规划 (ILP) 求解最优 OCS 配置，重配周期秒级 — 匹配数据中心流量矩阵变化频率。
Google Jupiter Evolving: OCS 做网络升级工具
核心问题：Google Jupiter 如何用 OCS 实现网络代际升级而不更换全部交换机、工程价值在哪？
OCS 在 Jupiter 不是性能工具，而是运维工具[8]。
问题：数据中心网络需跨代升级 (100G → 400G) 不能停机。传统 Clos 的 Spine 固定连接所有 Agg Block，升级需同时替换所有 Spine。
方案：Spine 层用 OCS，新旧设备通过 OCS 灵活互联。升级时逐步替换 Block，OCS 动态调整连接，新旧 Block 共存。
本质：将固定布线变为可编程连接，支持不停机渐进式升级。
各方案对比
核心问题：RotorNet/Opera/SIRIUS/Jupiter/TPU v4 OCS 五种方案在 OCS 类型、重配时间、触发机制、规模和状态上如何横比？
| 方案 | OCS 技术 | 重配时间 | 重配触发 | 规模 | 状态 |
|---|---|---|---|---|---|
| TPU v4 | 3D MEMS | ~10 ms | Job 调度 （分钟） | 48 OCS, 4,096 chips | 生产 |
| Jupiter | 3D MEMS | ~10 ms | 网络升级 （天） | 生产网络 | 生产 |
| SIRIUS | MEMS | ~ms | 流量矩阵变化 （秒） | 研究原型 | 论文 |
| RotorNet | Rotor | 固定周期 | 无需触发 （轮转） | 研究原型 | 论文 |
| Opera | Rotor + 电子 | 固定周期 | 无需触发 | 研究原型 | 论文 |
@tbl-topo-ocs-schemes OCS 方案对比
拓扑可塑性的工程价值
核心问题：OCS 可重构拓扑在带宽升级、故障隔离、多租户隔离三个维度各自的工程价值是什么？
| 属性 | 静态拓扑 | OCS 可重构 |
|---|---|---|
| 拓扑变更 | 人工插拔 （小时） | 电控重配 （毫秒） |
| 多租户 | 逻辑隔离 (VLAN/VRF) | 物理隔离 （不同光路） |
| 故障恢复 | 路由协议收敛 （秒） | OCS 旁路 （毫秒） |
| 容量规划 | 设计时固定 | 运行时可调 |
@tbl-topo-ocs-vs-static OCS vs 静态拓扑
重配时间决定适用粒度
核心问题：OCS 重配时间（10ms → 数分钟）如何决定了它能服务哪一层级的流量变化？
OCS 能否用于某场景取决于重配时间 vs 流量变化周期 (@tbl-topo-ocs-granularity):
| 场景 | 流量变化周期 | MEMS (~10 ms) | 硅光 (~10 μs) |
|---|---|---|---|
| TP AllReduce | <1 ms | 不可行 | 边界 |
| DP AllReduce | 10-100 ms | 边界 | 可行 |
| EP AllToAll | 秒级稳定 | 可行 | 可行 |
| Job 调度 | 分钟级 | 最佳 (TPU v4) | 最佳 |
| 网络升级 | 天级 | 最佳 (Jupiter) | 最佳 |
@tbl-topo-ocs-granularity 重配时间适用粒度
当前 MEMS 10 ms 重配限制 OCS 在"Job 调度级"工具。真正 demand-aware 实时流量工程需硅光 OCS 把重配压到微秒级。
适用场景与局限
核心问题：OCS 适合和不适合哪些并行策略和部署场景？
适用：
- 多租户 AI 集群 （TPU v4 模式）
- 故障频繁的大规模部署 （毫秒级旁路）
- 流量可预测且变化缓慢 （EP AllToAll 秒-分钟级稳定）
- 网络跨代升级 （Jupiter 模式）
- 功耗敏感 （光路直通低 10×）
局限：
- MEMS ~10 ms 重配对微秒级通信慢 4 个数量级
- 电路独占无统计复用，流量与配置不匹配时大量带宽浪费
- MEMS 最大 ~320 端口，远低于电子交换机数千
- demand-aware 方案控制平面复杂 （流量估计 + 配置求解 + 无中断切换）
- 缺乏缓冲，电路切换瞬间 in-flight 数据需上层协议处理
- 单台 OCS ~$50K-100K，端口单价高于电子
实际部署
核心问题：OCS 在真实集群中有哪些代表性部署案例、各自的 OCS 类型和规模？
| 系统 | OCS 位置 | 技术 | 规模 | 重配场景 |
|---|---|---|---|---|
| Google TPU v4 | Cube 间 ICI | 3D MEMS (Palomar) | 48 OCS （136 端口），4,096 chips | Job 调度重配 Torus 形状 |
| Google Jupiter | 数据中心 Spine | 3D MEMS | 生产网络 | 跨代设备混合互联 |
@tbl-topo-ocs-deploy OCS 实际部署
当前工程现实：OCS 在 AI 集群中以"拓扑配置工具"为主 （TPU v4 模式），而非实时流量工程手段。学术界 RotorNet / Opera / SIRIUS 方案展示更激进用法，但均未进入生产。
Takeaway
| 知识点 | 核心结论 |
|---|---|
| 核心价值 | 拓扑成为软件可配置资源 |
| 物理技术 | 3D MEMS 是唯一量产大端口，10-25 ms 重配 |
| 能耗优势 | 光路直通无 O-E-O，每 bit 低 10× |
| TPU v4 | 48 OCS + 64 cube + 4096 chips，Job 调度重配 |
| Jupiter | OCS 做网络升级工具，新旧设备渐进替换 |
| 学术激进方案 | RotorNet （无控制平面轮转） / Opera （混合） / SIRIUS （替代 Clos 中间层） |
| 当前瓶颈 | 重配 10 ms 限制为 Job 调度级，需硅光降至 μs 级 |
参考资料
- MEMS OXC Architecture (NTT/Bell Labs). https://opticalpassive.wordpress.com/2019/06/24/mems-oxc/
- MEMS Optical Switch: Working Principle. https://opticalpassive.wordpress.com/2021/04/08/the-working-principle-and-application-of-mems-optical-switch/
- Google Palomar OCS Architecture. https://www.fibermall.com/blog/unveiling-google-tpu-architecture.htm
- Jouppi N. et al., TPU v4, ISCA 2023. https://doi.org/10.1145/3579371.3589350
- Mellette W. et al., RotorNet: A Scalable, Low-complexity, Optical Datacenter Network, SIGCOMM 2017. https://doi.org/10.1145/3098822.3098838
- Mellette W. et al., Expanding across time to deliver bandwidth efficiency and low latency, NSDI 2020. https://www.usenix.org/conference/nsdi20/presentation/mellette
- Ballani H. et al., SIRIUS: A Flat Datacenter Network with Nanosecond Optical Switching, SIGCOMM 2020. https://doi.org/10.1145/3387514.3406221
- Singh A. et al., Jupiter Evolving, SIGCOMM 2022. https://doi.org/10.1145/3544216.3544265