补入当前动态视图问题，官方 FLUX 条件与局部代码改写仍保留。
修正范围：比日报九月反馈更新，但不夸大为性能回退。
持续追踪
TorchTPU：复用 PyTorch，仍要重排计算与通信
新增当前动态视图 issue：维护者确认支持有限，仍在进行；没有据此否定官方特定 FLUX 优化。
修正范围：旧稿使用九月 0.1.1 易用性报告；本次补入十月当前问题，且明确未作 TPU 实机测试。
查看依据
gpu004 CPU 属性检查路径复现，mkhanna15 回应动态形状与视图支持限制。 · 整步编译、通信重排、FLUX 设置与数值检查。TorchTPU 把 TPU 变成 PyTorch 的原生设备后端，10 月 20 日公开的代码与优化说明降低了尝试另一种训练硬件的门槛。但“原有模型能运行”和“训练足够快”之间仍有一段工程工作。逐算子执行适合检查正确性；性能来自让编译器看到更完整的计算、通信与内存使用。
Google 的 TorchTitan 适配案例把这个过程讲得很具体。传统分片训练会在模块钩子里发起通信，容易把计算图切碎；SimpleFSDP 把参数汇集和梯度分片表达成图中的张量操作，编译器才能安排通信与计算重叠。Graph Trainer 再连接前向、损失与反向。融合输出投影和损失计算，可避免把完整词表分数写入显存，省出的空间又让更大批次成为可能。
官方 FLUX.1 案例在 TPU v6e-8、bf16、每批三张 1024×1024 图像的条件下，把单步时间从 11.49 秒降到 2.78 秒；作者称最终吞吐约为同硬件 JAX 实现的 99%。结果包含三处模型代码改写及成套优化，不能当成只换设备名的普遍收益。改变归约和编译选项后，作者仍检查损失与梯度，避免速度改善掩盖数值变化。
本次补查的 issue #5674 比早期易用性反馈更接近当前限制：gpu004 报告动态形状重编译时，切片视图的存储偏移处理失败；其复现只走 CPU 属性检查，未运行 TPU。维护者确认动态视图支持仍在推进。这支持小步迁移、保留正确性基线的建议，尚不能量化所有模型的迁移成本。
查看依据
信息来源：Google Developers · TorchTitan 优化说明 · Google / Meta · TorchTPU 仓库 · gpu004 与维护者 · 动态视图 issue #5674TorchTPU 在10月20日开放源码，把 TPU 变成 PyTorch 的原生设备后端。开发者可以保留熟悉的模型定义和设备接口，先用逐算子执行的 eager 模式检查正确性，再通过编译取得性能。Google 同日发布的 TorchTitan 适配说明更有参考价值：能运行现有代码只是入口，高效分布式训练还要让编译器看见计算与通信的关系。
传统 GPU 路径中的 FSDP2 依靠模块钩子发起集合通信，再用流和事件安排重叠。这些动作落在编译区域外时，会把 TPU 的计算图切碎。SimpleFSDP 把参数分片表达为图中的张量重分布：取权重时用 all-gather 汇集各设备的参数片段，反向传播中用 reduce-scatter 合并梯度并重新分片。通信于是与矩阵乘法同处一张图，XLA 才能依据数据依赖提前取权重、交叠计算和通信。
Graph Trainer 再把前向、损失与反向合成整步图；Pallas 内核用于注意力、专家矩阵乘法以及融合输出投影和交叉熵。最后一项不把完整词表的未归一化分数（logits） 写到高带宽显存，释放的空间可用来增大批次。大模型还需要按层循环或拆分图，控制编译规模并卸载激活，不能简单地把“图越大越好”贯彻到底。
官方 FLUX.1 案例在 TPU v6e-8、bf16、每批三张1024×1024图像的设置下，逐步把单步时间从11.49秒降到2.78秒；作者称最终吞吐约为同硬件 JAX MaxDiffusion 的99%。这是成套优化后的特定模型结果，包含三处模型代码局部改写，不能解释成所有 PyTorch 模型只改设备名就自动达到相同性能。