前沿模型团队越来越少把“选 TPU 还是选 GPU”当作一次性的基础设施决策。Mirendil 与 Google Cloud 的合作体现了另一种路径：在同一套端到端训练体系中同时使用 Google TPU 和 NVIDIA 加速计算平台，并将预训练、后训练及大规模强化学习等负载，匹配给更合适的硬件与集群环境。
Mirendil 已经上线 TPU v5P 集群，NVIDIA 加速计算系统也将陆续投入使用。合作的重点不只是增加芯片数量，而是从计算、存储、网络到控制平面共同设计，并通过 Gemini Enterprise Agent Platform 中的托管训练集群简化 TPU 与 GPU 环境的供给和管理。
训练链路不再只有一个“主集群”
一个模型从预训练走到可用的后训练版本，通常会跨越多种计算形态：大规模数据并行训练、检查点保存与恢复、偏好优化、奖励建模、在线或离线强化学习、批量评估，以及大量小规模实验。
这些任务在资源画像上差异很大：
- 预训练往往追求稳定、长时间运行的大规模吞吐，数据、网络和检查点系统必须持续跟上计算速度。
- 后训练包含更多实验分支和频繁迭代，任务规模可能变化很快，对调度弹性和环境复现的要求更高。
- 大规模强化学习会同时拉起采样、推理、奖励计算和策略更新等环节，集群不只是运行一个训练脚本，而是在维持一条持续反馈的数据生产线。
因此，混合 TPU 与 GPU 的价值不应被理解为“同一任务两边都跑一次”。更实际的目标是按工作负载、软件栈成熟度、供应情况和调度时延来放置任务，并且保留以后调整的空间。
双加速器策略的核心是可迁移的训练接口
同时管理 TPU 和 GPU 时，真正容易失控的不是设备类型，而是训练作业对底层环境的隐式依赖。例如，数据目录、镜像、分布式参数、检查点路径和监控标签如果各自硬编码，迁移一个实验就会变成重写工程。
可以把“实验定义”和“硬件落点”拆开：训练代码只接收标准化配置，调度层通过资源标签决定任务进入 TPU 或 GPU 队列。下面的 Kubernetes Job 是一个可改造的示例，假设集群已经提供了名为 accelerator 的节点标签，并且训练镜像能够根据环境变量选择对应后端。
apiVersion: batch/v1
kind: Job
metadata:
name: posttrain-gpu-run
labels:
workload-stage: post-training
spec:
backoffLimit: 1
template:
metadata:
labels:
workload-stage: post-training
spec:
restartPolicy: Never
nodeSelector:
accelerator: nvidia-gpu
containers:
- name: trainer
image: us-docker.pkg.dev/PROJECT/train/posttrain:latest
command:
- python
- -m
- trainer.run
args:
- --config
- gs://MODEL_BUCKET/configs/posttrain.yaml
- --checkpoint-dir
- gs://MODEL_BUCKET/checkpoints/run-042
env:
- name: TRAINING_BACKEND
value: gpu
- name: EXPERIMENT_ID
value: posttrain-042
resources:
limits:
nvidia.com/gpu: "8"
要将同一类作业投递到 TPU 队列，可以保留命令、配置地址和检查点协议，只替换调度约束与后端变量。具体的 TPU 资源声明取决于所使用的 GKE、训练平台和 TPU 集群配置；不要把上例中的 GPU 资源字段直接复制到 TPU 环境。
nodeSelector:
accelerator: tpu-v5p
# 由平台或队列配置决定 TPU slice、拓扑和资源请求
这类边界清晰的定义有一个直接收益：研究人员提交的是可复现实验，平台团队管理的是容量、拓扑、镜像准入和排队策略，双方不必在每个训练任务里重复协调基础设施细节。
托管训练集群解决的是控制面复杂度
Mirendil 与 Google Cloud 还围绕 Gemini Enterprise Agent Platform 中的托管训练集群展开协作，用于精简 TPU 和 GPU 环境的配置与管理。对需要持续运行训练和评估流水线的团队来说，控制面能力往往和算力本身同样关键。
一个可用的控制面至少需要解决几件事：
- 为不同阶段提供可预测的资源队列，避免短实验挤占长训练任务。
- 统一身份、网络、存储访问和镜像来源，减少环境差异导致的失败。
- 记录数据版本、代码提交、配置、硬件类型与检查点关系，支持结果回溯。
- 把失败重试、容量变更和任务状态暴露为可观察事件，而不是散落在脚本日志中。
对于强化学习尤其如此。采样端、推理端和训练端的吞吐不匹配时，昂贵的加速器可能在等待数据，或者大量样本在队列中失去时效性。平台层应当能够按阶段监控积压，并据此调整资源配额。
可以这样实践：为训练阶段建立硬件放置规则
在落地之前，不必先建立一张复杂的“TPU 对 GPU 性能对比表”。更有价值的是为每类作业建立可验证的放置假设，然后用统一指标持续修正。
下面是一份可作为团队配置起点的简化清单：
workloads:
pretraining:
preferred_accelerator: tpu
metrics:
- tokens_per_second
- checkpoint_write_seconds
- accelerator_utilization
post_training:
preferred_accelerator: gpu
metrics:
- steps_per_hour
- experiment_queue_seconds
- eval_pass_rate
reinforcement_learning:
preferred_accelerator: mixed
metrics:
- samples_per_second
- learner_idle_seconds
- policy_lag_steps
portability_requirements:
checkpoint_format: versioned
dataset_uri_scheme: object-storage
experiment_metadata: required
container_image: pinned-by-digest
这不是对硬件能力的普遍结论，而是一套运营假设。团队应当把 tokens_per_second、单位有效训练成本、排队时间、恢复时间和实验成功率一起看。仅用单卡或单芯片吞吐做决策，常常会忽略网络、存储、排队和人工运维带来的总时延。
采用混合算力前，先把研究循环量化
Mirendil 的目标是用新的 AI 系统加速并扩大 AI 研发本身。其背后的关键问题不是“模型一次训练能跑多快”，而是研究循环能否更快地完成设计实验、评估结果和继续迭代。
计划采用混合 TPU/GPU 架构的团队，可以先检查四项基础能力：
- 训练与评估是否使用版本化配置和可恢复检查点。
- 数据、镜像和实验元数据是否能被两个环境一致访问。
- 作业队列是否按预训练、后训练、推理和 RL 阶段隔离并度量等待时间。
- 是否有足够的端到端指标来判断一次硬件迁移究竟缩短了研究周期，还是只提高了局部吞吐。
当这些基础具备后，TPU 与 GPU 的组合才会从采购或容量选择，变成一套能持续服务研究迭代的计算策略。